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

Hi Owen!

> 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.

Saving an e-mail attachment is something I really would like to have
pinned because I always forget where I put it. Anyway, there may of
course be cases of things you don't like to pin but that is really
difficult to estimate before you have tried.

> 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.)

Yeah, of course I mean the UI of the activity journal (or similar, more
cleaned, whatever).

> 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
> ]

I am really not a good UI designer but I would feel that a possibility
to switch between a time-based view and a flatter ("recently used" view
wouldn't clutter the UI much and wouldn't clutter too much. Basically
the two uses cases that you described above:

* I just worked on a document and need to change it now => recently used
* Someone calls telling talking to me about something I did last
week/yesterday/half a year ago and I need to find it => time-based view

There might be the need to filter things a bit more (search box, files
only, activities (e.g. website, chat, etc.) only.

> Would would a soft dependency on Tracker mean?

Not a discussion I want to take. Time for distributors to step in...

> 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.

Sure, but IMHO it's useful in the overview (see below).

> 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"?

As far as I remember the design, the desktop was seen as a place to
temporary store stuff. At least that is how it's used by some/most

If we go with the pinning approach I would simply drop the desktop as
something physical and replace it by views that show what I would want
to see on the desktop. 

Compared with this mockup
we would have
* New (or Recent, I guess recent fits better) - flat view
* Frequent - flat view
* Calendar (sorry, I am sure there is a better description for it) -
something like activity-journal

Short note on whether to use zeitgeist and/or tracker: It doesn't matter
too much what we use. If tracker supports something like an
activity-journal later (which was indicated by the tracker developers) -
that's cool, we can use it then. But it currently doesn't and it doesn't
look like it would for 3.0. So I think it's reasonable to use zeitgeist
for it now, as it can do all of those things. If the backend is kept in
a way that it can be replaced we can do that once we have a better
technology. I know that there are some things that have to be sorted out
with zeitgeist to ship it with GNOME but I am sure that can be fixed
when there is a fixed plan to use it.

As you indicate above, tracker is probably mandatory anyway.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]