← Back to team overview

unity-design team mailing list archive

Re: Some impressions about the current status of Unity


On 27. feb. 2012 12:25, Adrian Maier wrote:

I probably wouldn't even notice that every Friday ,    the Poker is
shown the first in the list of frequently used apps.  And that in the
rest of the days it's the 10th  in the list.

It seems you're still thinking about it as browsing menus. You shouldn't. You should expect the system to understand what you want to do, and present you with a very short list of relevant options. If you want to play poker on a Friday afternoon, then you should expect poker to be readily available in the list of expected actions.

Of course, sometimes you'll do unexpected things, and that's when you'll look for ways to accomplish the task at hand. You might break your leg and have to stay home from your work as a ski instructor, for instance. So you'll play poker a Thursday morning instead of Friday afternoon. In that case, you'll have to find the poker application. That will still be easy. But the things you do regularly, at certain times or events, should be extremely fast and easy. Possibly even semi-automatically. If someone throws me their keys, I catch them. They expect this of me, and I will automatically respond. Why should computers be any different?

I don't fully understand why are you mentioning that there will be a
"large" number of  web applications .   It would be simply one lens
full of links to the user's  preferred web applications  (actually
websites...) .   These can be maybe 10-20 ,  not thousands .   It's
hard to see what is the big novelty here :   in 10.04   it is already
possible to create an app launcher that starts firefox with a specific

Then you should still have to do manual work, such as creating bookmarks, create desktop-files, etc? That sounds nasty. I want my computer to do that stuff. I have better things to do than to create links and launchers and then maintaining them.

Hopefully there is no intention to have in the Dash a huge list of all
the websites that exist in the world , right  ?!

No, only the relevant ones of course. What makes them relevant? We'll get to that.

So the idea would be to have the user's recently accessed websites
presented inside Dash?   This sounds handy if  done right  :   if
it's dynamic it would need a clever algorithm for ignoring the
irrelevant urls .

Anything you've used is relevant as long as it's still available. The only question is how relevant it is. That depends on how often you use it, why you use it, how you use it, when, where, with whom, etc. Availability is part of the Zeitgeist metadata.

When talking about backup it is dangerous to confuse the access
frequency with the importance of a file .

If you choose never to use a file, never to backup a file, it isn't referenced in any way... How can it be dangerous to provide that information to the user? It reduces the chance that the user forgets to backup a file, but it also highlights files that aren't actually useful anymore.

To me, semantic data access is the exact opposite of chaos. It is clarity
and easy access across all kinds of data sources.
I could  get used to a "semantic"  way for accessing the applications.

Imagine that  :
-  there are 400 files ,    tagged with 20 different tags

Yes, but we're not talking about old-school tags. They're not just words or other meaningless text. They're semantic structures of information. As an example, consider the following one tag:

user: Adrian
did: open
      url: http://blablabla
      available: yes
      type: image
        mime type: blabla
      description: mockup to make browsing easier
    in: Firefox
    by: clicking on a link
      in: Thunderbird
because: it was mentioned
  by: Josh Strawbridge
  in: email thread
    people in thread: list of all participants
    title: 'Some impress...'
    as a reply to: blabla
      from: Jo-Erlend Schinstad
when: time and date
who were nearby: list of people in the room
where: your GPS location when this happened.

Of course, that's not how it looks in reality, but it is in principle how it works. Tags are nested pieces of semantic meta data. They're stored as list of historical events. Firefox, for instance, is not just a text tag. It is an entity of the type "web browser", which belongs to another entity, which is "application", etc. The file is also not just a name, and the tag is not just text. It is semantic metadata that the system can understand. Of course, you can add pure text labels as well to improve your own personal access.

Explaining Zeitgeist is beyond the scope here, but I'll urge you to read about it, because it's very interesting. You can find documentation for the metadata model itself here: http://zeitgeist-project.com/docs/0.7.1/datamodel.html

-  searching works perfectly ,   bla bla

Yes, but we're not searching in the traditional sense. That is, searching is not simply a matter of entering text. It's really more about contextual awareness than searching. For instance, let's say you have an external harddisk that you only use for backups. You only take backups once a month, so it'll never be among your most frequently used applications. When you do want to take a backup, obviously, you want the backup application to be easily available. This is where you would assume that the "frequent applications" method would break, since there are so many applications you use more frequently. But frequent applications work very nicely, because in this _specific context_, the backup application is _the_ most frequently used application.

The context begins when you connect your harddisk. It ends when you disconnect it. Not just any harddisk, mind you. This context is connected to your backup disk and only that. But it is a "child context" of connecting an external harddisk, which itself is a child context of a new data source becoming available. This can happen for a large number of reasons, such as connecting to the internet or your company intranet.

Since you always start the backup application within minutes of connecting that harddisk, the system adds your backup application to the list of most accessible applications. You open the dash and start the first application in the list, because the system knows it's the application you're most likely to want to use right now. In this case, you're searching for applications by connecting a specific harddisk, not by entering text. Starting the backup application is always done whenever you connect your backup disk, which is why in this context, backup is the most frequently used application and the most expected action.

As a positive side effect, this also means you'll be reminded by your system that the backup disk is still connected, because backup is in the list of expected actions, which it will never be when the backup disk is not connected.

-  however at some point i'll want to review what's available ( copy
the important files on an usb stick  , cleanup , delete what is
unneeded,  etc)

Yes, for instance "delete all files regarding client x because the account was closed". This would delete entries from your database, stop new invoices from being sent, remove the client from your announcement mailinglist, update your project timeframes, etc. It will not delete anything from your historical database, because the events did occur. But the deletions are stored as events, and the deleted data is marked as no longer available.

-  at that point i'll  hit the problem of redundancy :   the same file
will appears in multiple tags

Tags are unique and files are not in tags. It it tags who points to files. The same file should never, ever be listed twice in the same context.

-  if  want to see everything ,  i'll have a huge list of
dis-organized 400 files .
-  if i look at  the contents of each tag , it would become difficult
to keep track of all those files that appear in multiple places

Files will never be disorganized. That should never even be possible, except in the case of data disaster. The reason files can be disorganized now, is because you have to manually organize them in hierarchies, which you have to use when locating the files – and you are not perfect. The computer, however, performs the exact same action a billion times without getting bored, loose focus or forget previous decisions. The question is how the computer should know what to do. It was never possible before. It is possible now. Any file only exist once and in reality a file never exists in two places. Deduplication should be done at the filesystem level, and not all filesystems supports that yet, but we'll get there. But that's only relevant with regard to copies, not references.

It is not possible if the files are moved into a new kind of storage .
   This route is bad.

If you move a file, then the metadata is updated. This already works quite nicely in many instances. Because moving a file is also an action that affects that file, so the move itself is remembered. Why, how, when, where, etc, is also remembered. For instance, Transmission might tell Zeitgeist that the file was moved from your temporary directory to your downloads directory because you reached your upload/download ratio goal. That information is available to all applications. So, when you click the icon in the Dash, it will open the file from the new location.

If you move a file to a website, the same thing happens, except maybe it'll be opened using your default web browser instead.

That's true :    actually there is no tags system currently available
in Ubuntu .     So discussing about tags is just an assumption about a
future feature that might exist or not.

That's not true. As I told you before, we have Zeitgeist. It's an advanced and mature history-based tag system, and has been in use for quite some time now. It's just that the user-visible tools to actually display data from it hasn't started to appear until now.

When mentioning sync problem I was having in mind situations like :
-  on an external disk  there is a collection of photos . Everything
is tagged and searching works nicely  .

- if  i rename a directory  from command line ,    I expect that the
semantic desktop would loose track of that particular directory .

- assuming that the tags is stored on the computer ,  all the tags
will be unavailable when attaching the external disk to another pc  (a
laptop that is running the same Ubuntu version) .

- it is also very useful to preserve the tags

As I explained above, the semantic desktop wouldn't loose track, whether the file was renamed, moved to another harddisk or uploaded to a website. Yes, it is true that a computer that has no experience with you, will not understand your intentions. Synchronizing Zeitgeist must be made very easy. The cool thing is that Zeitgeist could store which computer you use to do what, so that even if the databases are identical on two computers, the results are different. It will never display applications that aren't available, for instance. However, it might remind you to install applications you frequently use.

Tags are always preserved. They're actually never changed or updated. When something happens, you add a new tag to the meta data history.

This is why the metadata belongs to the filesystem  when talking about
external devices .
Perhaps external drives could carry a subset of the metadata ,  that
get synchronized when the device is attached to a computer.

That depends on how external the data source is. Web servers are data sources too, but you can't add meta data to their internal file systems. You can add meta data to your Zeitgeist database, regardless of where the data is located. This is why the meta data does _not_ belong to the file system.

We've drifted fairly far away from the main discussion here. But I think understanding why we're not using hierarchical navigation depends on the knowledge of how the semantic desktop works. If you're interested in these things, as you seem to be, you really should read more about it. It's seriously awesome.

I recommend that we end this thread now, and focus on specific issues. You may wish to join #Zeitgeist on Freenode is you're interested in learning more about it.

Jo-Erlend Schinstad

Follow ups