So now that GNOME 3 is out, and I am excited about the future progress of the “Finding and Reminding” feature. My design philosophy is that design should be an evolutionary process with multiple prototypes tested for effectiveness along the way, not a “design everything upfront” process.
Along with Federico Mena and Siegfried Gevatter, and Akshaj Gupta working with us as a SoC student, we have been working on rapid prototypes of our own “Finding and Reminding” ideas and also have been working on cleaning up of those prototypes.
We will refocus our work to assist the GNOME Shell team once their designs are complete. Until then I would like to invite people to play with my branch on gitorious (https://gitorious.org/gnome-shell-zeitgeist/gnome-shell-zeitgeist/commits/desktop)
This branch adds 3 new features to GNOME-Shell:
- Jumplists: (Right clicking on an app in the dash or the IconGrid opens a menu with the 4 Recently used files with the applications)
- Search: (Searching now looks in Zeitgeist for all your most used documents mathcing your strings… This can be done via Tracker too and I have a zeitgeist-extension that pulls the search results from Tracker and sorts them via zeitgeist)
- Library Tab: A vague implementation of the design ideas from the gnome wiki
To test it you will need the latest Zeitgeist packages from from your distribution or get the source code from:
- Engine: https://launchpad.net/zeitgeist (the main engine)
- Datahub: https://launchpad.net/zeitgeist-datahub (the main logger)
- FTS-Extension: http://bazaar.launchpad.net/~zeitgeist-extensions/zeitgeist-extensions/trunk/download/head:/fts.py-20100602085111-i21bh1p60phaak4f-2/fts.py (place it in .local/share/zeitgeist/extensions)
- Extra Loggers: If you want to log some extra stuff you can download other loggers from http://bazaar.launchpad.net/~zeitgeist-dataproviders/zeitgeist-dataproviders/trunk/files
Some nice ideas worth experimenting would be to replace some Zeitgeist stuff with Tracker stuff and test… I already started with some Zeitgeist extensions that make this possible.
This work is in no way what you should expect from the “Finding and Reminding” stuff that is being designed. With a lot of luck there might be some stuff pulled into the main design. But it would be nice to have feedback.
Play with it, tell me what’s bothering you, or what you like at #gnome-shell-experiments on gimpnet (irc.gimp.org).
Let’s encourage prototypes and testing. While prototypes does not mean the code will be used, it is a good way to have a more agile development and interactive design process, that could help out the GNOME Shell designers with their decisions.
If you’ve got ideas on how to improve GNOME shell’s ability to “Find and Remind”, send us your sketches, mockups, and ideas and we’ll work with you to develop rapid prototypes and test your ideas and theories.
You can post them on http://live.gnome.org/GnomeShell/Experiments or drop by #gnome-shell-experiments



Nice ideas, but I’d like to offer a quick thought about the library thing.
In practice the idea of cataloguing by type falls down fairly quickly with increasing complexity. While I have a load of files I consider my “music library”, there are also lots of audio files I will never want to see here, files I won’t ever import into rhythmbox, for example.
What I have instead is various libraries, or to use more traditional terms, various collections within my one library. Some of these collections may be inferred automatically, but most are personal to me, and require me to supply information explicitly.
The easiest example would be a dev project. In my mind one project may contain source, docs, designs, videos, etc, and intermingling any of these files with anything from outside the project is rarely of much value.
The actual files in this collection are probably mostly grouped together in some folders, but I would often like to reference things in other collections also. For example I might want to bring in some documentation from my “tech refs” collection, without copying in any files, so a collection is more than just file system organisation.
So, where is all this leading? A task focused UI is a fantastic thing, but the important thing to remember is the user is the one who knows what the task is. If I am a light PC user, I might be doing the same task every day (“write a letter, listen to some music, talk to friends, …”). If I use the PC for serious work, I have many distinct tasks, and my shell won’t know what they are until I tell it.
By “collections”, I’m therefore really defining the part of my library that I am working in to a perform a task. In a perfect world I would also add applications to this collection, perhaps particular friends lists, lists of bookmarks, etc.
I really like what you have so far, but what I’d like to say is: I think we probably want more of it
Phil this is awesome feedback,
How do you see collections set? Automatically (Most used together) or Statically (Tagging)?
In the Journal I don’t display your library I display what you listened to or opened
not random stuff
Does the Library/”Desktop” tab prefer/prioritize/show folders from ~/Desktop first (i.e. for compatibility with fallback mode and out of tradition), or is it purely dynamic from zg?
hey John…
Its purely dynamic from zeitgeist… It can be replaced with Tracker… I am working on that for experimenting
Ah, well, I’m with you on the multiple prototypes thing for finding the best answer to that. The easiest way to build the collections would be by defining that one user task = one collection (at least initially.) By asking the user what they are working on, you build a collection around it.
Some things I would experiment with, for discovery:
* File level “associate with (current) task” option (effectively a tag)
* Dir level “associate with (current) task” option (a recursive tag)
* Autotagging, based on what is used when user is known to be working on a task.
And for use:
* Selecting current task at overview level (tricky, because multiple tasks at once shouldn’t be precluded)
* Filtering overview by current task.
* Explicit tasks per workspace (which is tricky, as workspace is below overview level, but it is the overview where you probably most need to know which task is current)
* Marking/colour coding windows/workspaces by task they belong to.
* Quick task switching: diving out of a task into another, freezing the current state.
* A default, neutral task, where friends, music etc. lives, allowing a light user to ignore complexity they don’t need.
So I definitely know no magic bullet. I’m sure the answer is in finding a workflow that is general enough that people will naturally adjust to it, but specific enough for machine understanding of what the user is doing. But then, that pretty much just describes what we always have to do…
Jump lists looks cool, and I really can’t wait to have zeitgeist integrated in Gnome 3, linking together files I use often simultaneously, ask me if I want to use a new desktop when I work on a file that has no link with the current open app, easily find related files. I thought that this was the goal of Gnome 3, and I think I would like it.
About the “Applications” and “Library” tabs, I still have one request, please change the UI! Why do applications look to big? I have a screen with a decent resolution, please display more than 6×5 apps, in addition they aren’t event sorted like they were with Gnome 2, I think that this is bothering me a little.
I still use a terminal to start my apps 90% of the time, or I have some as favorites on the left, but as soon as I open the “Application” tab it’s a pain to find something. The search entry is my savior here.
And I don’t really like having tabs, I would like applications on the left like in previous versions/mockups (not sure what it was), maybe pushing windows on the right when listing them if needed, but keeping them on screen.
I belive that a smoother user experience would be nice, if everything were linked and worked nicely together.
Keep up the good work, we’ll get there!
I love the jumplist. However, I do not want to show my files by using the shell search. When you are presenting something you don’t want to show your private datas to your audience. There is no way to avoid that in the shell right now. Open a program by searching for it and you show everyone your holiday pictures where you are wearing a swimming short instead of your fancy suit you are wearing right now.
Your zeitgeist experiments do not make that behaviour worse but it doesn’t help you either. I think we need a way to turn our search backends off or some kind of a private mode for beamer presentations.
Yeah, I love the jumplist function. Great idea!
Here’s my thought about the “Library”: Isn’t there already a solution for it? It was called “Places” and was introduced in Gnome 2. Prenamed directories in your home directory can help you organize your stuff. For e.g. when I get a new CD, I rip it and put it in my “Music” directory. Or if I downloaded some files, I know that I can find them in the “Downloads” directory (Firefox does this by default).
Sure, it’s still not as complex as Phil’s task based idea. But for the “light PC user” it’ll work 70% of the time. And for the 30% that we are missing, it would be pretty cool to work from that perspective and take the places idea to the next level. Postprocess what the user has actually sorted before. Make him/her see the last tracks he added to his “Music” place, or what movies he/she downloaded last night. Or on which project he currently works on (maybe create a “Projects” place?). You’ll never be able to sort that kind of stuff automatically by computers, because only a human being can understand the context between different files, because he created the different contexts for them only in his mind. You sure can try to collect various informations about a file (like opening dates or linked programs), but you’ll not be able to find out what context the user had in mind, when he/she saved them on their hard drive. What you can do is giving him/her different views on his/her contexts and therefor helping him organize his work.
Start from a whole new perspective is always a great idea, but it’s also important to see the potentials of already good ideas and make them even greater.
I think you may have started something really big right now.
This kind of rapid prototyping based on all the awesome tools available and on the scale of a DE is pretty powerful.
Thanks for the great work.
@Flo, by default when you hook up a second display (e.g. a projector) you get an extended desktop and not mirror mode. Your audience won’t see anything but your wallpaper until you drag something over there.
@tuXXX, perhaps instead of just smaller icons for the icon grid what might work is different views like Nautilus has; big/small icon, list, detail, etc
@Seif, I’d like to see the finding and reminding extended from documents to applications. i.e. the dash show your most frequently used applications rather than a manually maintained favourite list. If not in the dash then in the default view for the application grid; “favourites”.
I think using only zg for search may trick the user that a document not in zg doesn’t exist… I think the search should use tracker since that is supposed to know about all the users documents, then use zg for determining the sort order… most used first or something like that.
But I see in the comments above that you are playing around with tracker too… this looks very promising.
Tracker + Zg in gnome-shell would just rock!
Seif,
You should also add help so that if people are looking for help on a certain topic they would be able to search for it easy just like in spotlight. I didn’t see that in your screenshot.
Otherwise, pretty nifty.. I’d love to show this off tomorrow at my GNOME 3 talk as a future thing.
@tuXXX: The Big Icons are desgined by the GNOME Shell team. I also don’ t really like it. Will update my branch with the necessary changes soon enough. As for the Dash itself on the left, I will see what I can hack but i always thought it used too much real estate… Thanks for the comments
@Flo: Have a look at the http://seilo.geekyogre.com/2011/04/the-crazy-zeitgeist-week/ … We covered the case where you can blacklist things from appearing in Zeitgeist searches. This means it will work with Shell too in the case they want to use Zeitgeist.
@Sven: I will add the old Places Menu to the tab for testing. But I think browsing through directories is a Nautilus Job. Currently each category (Music/Documents/etc..) in the Library shows you a chronological “Activity” of these files instead of a static browsing (which is nautilus domain). I am not sure that crossing domain of usage of the Shell with Nautilus is a good idea. The idea of Library is to make it easier for people to not have to go through browsing files. I know some people who don’t understand the concept of Folders…
@Leif: I am working on populating the Dash with most used apps too. But thanks for sharing the same idea
@Mattias: Tracker is awesome but sadly it does not cover all files on your desktop. If you have any files outside the standard XDG directories it wont get detected (You have to tell tracker to ass a specific Folder to indexing process). Other than that it will find everything. Zeitgeist on the other hand indexes anything you touch. An example where both kinda fail is the following. Imagine extracting tar of the Linux kernel in the documents folder. You will end up with thousands of files there that tracker will index. But are you really interested in all these files. Do you want them all to appear in you next search. You never really touched them. Yet ignoring them completely like Zeitgeist does is also no good solution. Also because Zeitgeist only indexes what you touch it does not need a disk crawler. I am working on an extension for zeitgeist that makes the best out of both worlds. Stay tuned.
@Sri: good idea. I will ask some designers where to put that.
Thanks for the comments all keep it coming
Seif, If I unpack a tar I might be interested in finding those files… but I also may not be interested in all the include files in the kernel… so that is why I think that tracker with zg fixing the sort order is the best solution. So that the files I have touched is shown first, but I also can find other files.
And the tracker only searches xdg directories is not optimal… but isn’t that due to limitations in inotify? Tracker cant just set a monitor on $HOME, but need to allocate a filehandle for every single directory it needs to monitor. But I see your point. So I look forward to your both worlds solutions…
\Seif
Nice. Thank you for the information.
\Leif
I wasn’t aware of that. However, I also do not want to show my private files to everyone behind me at work or public. The Zeitgeist-feature Seif mentioned is perfect for my case. My current approach is a little bit crappy: I’m simply not allowing applications to modify my recently-used.xbel. I also know a couple of people (read: 3) who are also using the same trick to avoid the tracking in common since gnome 2.0.
Feedback:
“Library” does not represent the dynamic nature of list of recently used files. If I think about a “Library” I have a collection of important files in mind. A Library contains all available informations/files on certain topics – a library is complete, extensive and requires appropriate tools to find specific information.
The current concept, however, propose mainly the history of recently used files. A better name is required to reflect the concept for newbies.
I would be great if the provided information could be enhance. For example by the date of last usage and optionally the place where the file is saved. This would enhance the usability enormously since it would be easier to identify files with certainty. The filename is often not sufficient to identify the required file.
Truncated filenames affect usability badly. The big icons are currently not very useful.
Kepp up the good work!
Files are often given context by the directory they are held in, this is especially important when multiple copies of files exist (eg. different versions). This information is lost in all the mock ups I’ve seen. Have any ways of iincluding directory information been thought about at all?
I second what Phil said about the classifications in the library view. “Music”, to me, is anything in the ~/Music folder – not just random audio files elsewhere (e.g under ~/Downloads). More than that, I have very little interest in the ~/Music folder from a file-management point of view, since all my interaction with those files is through applications like Rhythmbox or Banshee. So any audio files I do care about in the shell are almost certainly not “Music”.is all I’ve got.
I’d also note that I don’t want the desktop showing me every file I happen to have looked at. Partly because it might be confidential (personal vs work related stuff on a laptop), and partly because it’s just plain noise, files I opened once, and don’t plan on opening again. If I look at a couple of hundred files a day (e.g browsing the photos that just came off my camera), that pretty much destroys the value of the “recent files” list.
Seif: I would it should be possible to identify coherent code projects; especially ones that constitute, say, a single git repository. I have a ~/local directory which contains a ton of git and svn checkouts of upstream projects, and I’d think a smart tracker/zeitgeist should be able to recognize each of those and treat them as a coherent project.
One thing I found myself telling people a lot at LFNW is that I want the overview search box to work more or less like Firefox’s awesome bar does for me for web stuff. I never bother bookmarking anything any more; the awesome bar finds it for me, as long as I remember a bit of the URL or any word from the headline, which I almost always do. I’m sure this is hard on the backend, but I want the overview search box to be like that for my local system stuff. To give specific examples – I want to be able to hit start, type ‘jlaska irc’, and get recent conversations I had with jlaska on IRC. I want to hit start and type Nirvana and have a list of Nirvana albums show up that I can start playing in Rhythmbox. I basically want to be able to start any typical desktop operation with a quick keyword. Also, a golden unicorn!
I really like the ideas you are suggesting, but at the same time I agree with those who would like to avoid adding new shell tabs in favour of keeping things simple. If everyone just added a new shell tab for their Really Important Feature, we’d end up wading through the same oceans of menus that made finding anything in GNOME 2 such a chore. We can do better than that!
Perhaps, as Adam suggests, it would be possible to integrate Zeitgeist features into the search bar? This could be done ‘awesome bar’ style, or maybe through a little drop-down menu that lets you filter results by category (e.g. Today, Yesterday, Pictures, etc.), with the ability to add user-defined categories? You could also have the option to specify the category in the search query itself, e.g. ‘cat:lastweek’.
Re. ‘real’ folders/directories: I think it’s important to remember that folders/directories are just a metaphor in themselves. Grouping bunches of files together under a ‘folder’ is one way of organising stuff; grouping by recent activity, or by tag, or by task, are other, equally valid ways of doing the same thing. Granted, the folder metaphor has become integral to many workflows – this is why I have hundreds of files on my computer called ‘config’. But this isn’t always going to be the best or most useful way of organising stuff. A file needn’t intrinsically ‘belong’ to a directory any more than it belongs to a time, or a place, or a task. So while I agree that at the moment it would sometimes be useful to see directory structure (for example, when editing config files!), I’d like us to get to the point where the user is free to choose whether to imagine his or her files as organised by folder/directory, time, tag, task, or anything else we can think of, and where s/he is free to switch between different ways of imagining depending on what is most relevant to what s/he wants to actually do, without losing any useful information. People aren’t neatly organised into fixed hierarchical categories – they occupy multiple categories at multiple moments, depending on context, choices and circumstances. Why can’t their files be the same?
Ok, utopianist rant over