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 > http://www.gnome.org/~seth/zuhanden-gnome3.pdf ] 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 view * 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 people. 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 http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding?action=AttachFile&do=get&target=desktop-view.png 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. Regards, Johannes _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list