Re: Finding and Reminding, tech issues, 3.0 and beyond

[Owen Taylor <otaylor redhat com>]

On Sat, 2010-04-10 at 09:10 +0200, Johannes Schmid wrote:
> Hi!
> 
> >   There are two basic approaches here - one is to avoid storing
> >   things on the Desktop. Instead of seeing the Desktop as a separate
> >   location in the file selector, you'd have a checkbox:
> >   
> >    [ ] Pin to Desktop
> >    
> >   (or whatever the designers come up with), and that would create
> >   a symlink to the desktop.
> >   
> >   The other approach is when expiring or archiving to move files
> >   from ~/Desktop to an archival location like ~/Documents.
> 
> The pinning should be done automatically and the files should stay in
> the place I saved them (e.g. a firefox download should end up in
> ~/Downloads and OO.o should default to ~/Documents. The recent files
> should be stored by pinning on the "Desktop".

What, if anything, gets pinned automatically is an interesting question
- there's a pretty strong case if I create a new word processing
document it should automatically get pinned. But if I save an email
attachment, probably not? If everything is pinned, that's pretty much
the same as pinning nothing. Pinning something to the desktop is making
a "todo" item - it's something that you think you'll need to attend to
in the future.

> > "Timeline view of files"
> > 
> >   For items that aren't on the desktop (the "slip") the default view
> >   is a chronological one with "yesterday", "last week", and so
> >   forth. So we need to be able to organize user's files this way.
> >   
> >   One approach is to keep track of user accesses and edits via
> >   Zeitgeist (or in simplifed form by ~/.recently-used.xbel)
> >   
> >   The other approach would be to treataccess/edit time a
> >   metadata property, and to use tracker to search over these
> >   properties.
> >   
> >   (Note that the timeline here only includes each item once,
> >   not once for each usage - I use "timeline" somewhat differently
> >   below)
> 
> Why would the timeline only include each items once? I really would like
> to see the activity journal here as it is so much more like people
> remember things.

I assume that by "the activity journal" you mean a UI like GNOME
Activity Journal, and not the current GNOME Activity Journal? (It
wouldn't really be possible, or at least at all easy, to to use a
separate pygtk program within the GNOME Shell Overview.)

Jon McCann is off enjoying the beaches of Mexico this week,
unfortunately for getting deep into the design side, perhaps some of the
other designers who participated in the discussions want to chime in.

My quick take on the issue is that its a question of density - the GNOME
Shell overview is meant to make as much as possible immediately
available to hand. Because repeats are shown, and because of the fixed
time organization, the "activity journal" presentation is quite low
density. This is even more the case when narrowing using cross-cutting
filters... if I only want to see the slide presentations, then the vast
majority of days in the last year will have no activity at all.

But certainly there are cases where using episodic memory, where drawing
the connection from one document to a related document is of great use.
I probably can find my slides from GCDS pretty easily with search (they
are called 'gcds.odp'), but how do I go from there to the SVG source of
the illustration 'shell-components.svg'?

If I could somehow pop from finding gcds.odp to a calendar/timeline view
of all the times I edited that file, then it would be easy to find the
SVG file. Ther are some interesting ideas there, and there are also
considerable design challenges (a simple one is that there is no way to
"select" items in the overview design - it's single click activation.
And anything you put into a right click menu might as well not be there
for most users.)

[ Obviously related: "Search by iterative date comparison" in
  http://www.gnome.org/~seth/zuhanden-gnome3.pdf ]
  
[...]

> > Not much yet - I think it will definitely be hard to implement
> > our ideas without something that looks a lot like Tracker, and 
> > since we have Tracker something that looks a lot like Tracker 
> > is most likely Tracker :-) Zeitgeist seems less centrally crucial, 
> > but there is a role for event logging here. 
> 
> Some of the more advanced search technologies really need tracker, I
> agree here. I am not sure if we want to depend on it hard for 3.0 but
> that can be discussed.

Would would a soft dependency on Tracker mean?

Having tracker-search-tool in the menus isn't the interesting thing. The
interesting thing is to be able to do deep integration into the shell.
You could have fallbacks similar to the current file search in GNOME
Shell - just restrict search and browsing to filenames in
~/.recently-used.xbel. But that's a really degraded experience. If we've
designed things with the assumption that you can search and browse
through all your files, but you are running without Tracker and it
actually is restricted to a subset of recently used files, it's not
going to work out well.

On the other hand, if there are reasons that Tracker isn't suitable to
make a hard dependency, then I'm not sure it makes sense as a soft
dependency. If we were talking about Tracker 0.6 rather than Tracker
0.8, would we want to offer users the choice that they can have good
search across their files, if they are willing to accept system
performance being horribly degraded in some circumstances?

(An obvious problem with a hard dependency on Tracker is that the GNOME
2.30 based distributions - Fedora 13, Ubuntu 10.04, etc. - are still
shipping tracker-0.6.9x. So, if we hard-depend on Tracker, people
developing and testing GNOME 2.31 components will need a newer version
of Tracker than shipped on their system - not a blocker, but a bit of a
nuisance.)

We have to design and build a single thing - that we want reviewers to
review, that we want users to use.

> But as said above I really want to have the activity journal available
> inside the shell as I think it is beside the shell another central point
> for 3.0

What the central points of 3.0 are have to be based on how they fit into
the overall vision. If an activity-journal like view makes sense in the
overview, then we should implement that and market it for 3.0, but we
shouldn't be forcing an activity-journal into the overview *just*
because it's something that has been discussed in the planning for 3.0.

So, if you want an activity-journal than there has to be design-side
engagement to figure out how it fits in. If it replaces the current
loosely chronological view in the mockups, how does it accomplish the
same tasks? How does it relate to the "Desktop"?

> Most important would be to come up with a plan what we have in 3.0 and
> what we might have in 3.2 as I doubt anything will be ready by the time
> 3.0 is released.

Certainly. I'm pretty confident we can do some interesting stuff for
3.0, but we clearly can't do everything for 3.0.

- Owen