Designing "Finding and Reminding"

[Federico Mena Quintero <federico gnome org>]

One of the big tasks for Gnome 3.2 is the "Finding and Reminding"
idea.  This has been sketched out for gnome-shell here:

http://live.gnome.org/ThreePointOne/Features/FindingAndReminding

In summary, Finding and Reminding is about having a good way for users
to do their daily work.  People manage various files, web sites,
and conversations.  They receive files, edit some of them or create
new files, send the files around... they may research something on the
web, talk to a friend or colleague about it over IM or VOIP or
whatever, and generally use a combination of tools to achieve their
work.  People need their "working set" of data; they need to refer to
previous work; they need reminders of what to do later.

This is well-documented in the HCI literature - in fact, "Finding and
Reminding" is the title of a well-known paper, by Nardi and Barreau,
that explores the kinds of interactions that people have with their
work, and the kinds of behavior people adopt:

No filers - They don't file anything.  They try to survive in the soup
of data.

Spring cleaners - They try to organize things when the system seems to
be breaking down, or when it already has.  They frequently fail.

Frequent filers - They try to keep things organized and in order, but
this is a tremendous amount of work.  However, things fall away from
their view (think of the story of Little Miss Tidy - she kept
everything in a cute little box, but then she had so many boxes that
she didn't remember which box contained what).

Jon McCann came up with the terminology "grip / trip / slip" for
categories of information
(http://blogs.gnome.org/mccann/2010/04/07/the-grip-the-trip-and-the-slip/):

Grip - Things which you need frequently must be "at hand" - easy to
reach, easy to grasp.

Trip - You should be able to "trip" into useful things easily and
frequently, as opposed to tripping with useless debris all the time.

Slip - Things which become useless or obsolete over time should fade
away from your view - they shouldn't persist in your everyday view of
things, as they would clutter your vision.

>From an ergonomic-thermodynamic point of view, or in other words, the
universal maximum-laziness principle, we can restate those concepts
like this:

Grip - I have better things to do than to be searching for the same
data everyday.  Just give it to me whenever I need it.

Trip - I am too busy/lazy to maintain post-its of things that I may
find useful.  Useful things should just materialize near me.

Slip - I am too busy to clean up after myself, especially when the
computer lets me accrete so much crap.  It should clean up for me.

Let me start by saying that NO SYSTEM IN PRODUCTION has a solution to
this problem.  Unfortunately we cannot just copy a solution from
elsewhere, because there isn't one.  So, we need to accept that we
don't know what the end result will look like, and we need to accept
that we'll need to do a healthy amount of experimentation, guided by
careful judgment.

The solution has various parts:

1. We add a time-based view of the user's work - a "journal", or
"history", or whatever you want to call it.  In it we present files
that you have used, conversations you have had, web pages you have
visited, etc.  

By now everyone is familiar with my old GUADEC presentation - 
http://people.gnome.org/~federico/docs/2008-GUADEC/html/index.html ,
the Zeitgeist and gnome-activity-journal efforts, and similar.

For the journal to have good "grip", it must be easily-accessible from
wherever you are working.  Both the current mockup and the
implementation create a third item in the shell's overview, next to
Windows and Applications - but this is not "grippy" enough.  It's too
far removed from the desktop.  This is easy to solve; I'll talk about
this later.

We can start to have "trip" by presenting items from your to-do list
right in the journal, as those items have due dates, anyway.  Also, we
can let you mark files so that you'll be reminded about them later (in
Getting Things Done's parlance, this means having a "tickler file"
right in the journal).  Think of right-clicking on a PDF, and being
able to say, "remind me to read this PDF in two weeks, because my
homework about it is due in three weeks".

"Slip" comes about naturally from the time-based view.  Items which
you no longer use will automatically "scroll away" in the timeline.
Items which you reuse will appear in your recent dates again.

2. We add channels of circulation to apps that let you work with data,
so that you can navigate your things more easily.  Right now you can
open files from the file manager, but not all apps let you open the
file manager to show you the file you are editing.  See
http://people.gnome.org/~federico/news-2010-08.html#19 for how Evince
was fixed in this fashion.

In an identical way, we can start adding "Open in file manager"
commands to other apps.  EOG, Gedit, and LibreOffice come to mind.
I'm sure you can think of hundreds of examples :)

In a related way, we can see what other kinds of connections would be
useful to have in various apps.  Clicking on a contact should
definitely give you a list of files that you've shared with that
person.  One should probably be able to list all the files that you've
sent to someone else at some point, as in "people ask me for the same
stuff frequently; show it for me so I can fulfill the next request
easily".

3. We begin to see the interactions between the items above, and start
designing how to further improve the behaviors across the shell and
apps.


Now, (1) and (2) are things which we can do in the immediate future.
The journal is particularly interesting - it should give us something
that no other shipping platform has, and it should immediately give us
interesting feedback from users.  After that, we can see how to
integrate more sophisticated concepts:

* The "reminding" part.  Seth Nickell called it a task pooper -
http://blogs.gnome.org/seth/2010/02/26/let-the-wild-rumpus-begin/ .
The "Getting Things Done" people call a similar concept a "tickler
file".  The idea is that you put stuff in time buckets in the future
(today, next week, next month) and you get reminded when the time
comes.  We'll have to fine-tune the interactions; this has to be as
simple as dragging a file and dropping it in a pooper-like bucket (and
probably writing a description of *what* to do with the file).

* Making the journal a really user-writable journal.  Write notes in
there, annotate files and journal entries.

* Present related files to the ones that you selected (Zeitgeist
already has the data-mining smarts to do this).

* Group items by tasks or projects.  This may be about tagging
a-la-emblems, or something else.


Who is implementing this?

The infrastructure for the journal is of course the Zeitgeist engine
and its data loggers.

Akshay Gupta recently mailed this list; he is my Summer of Code
student who will be working on gnome-shell's journal.  Seif Lotfy and
myself are working with him on this.

Although I'm sure I'll make Akshay modify some apps to add the "Open
in file manager" command, it would be very helpful if people could do
this with their own apps.  Feel free to mail me for details.


The design itself

Here is where we are asking for help from the cadre of designers and
the gnome-shell maintainers.  From the experience with
gnome-activity-journal, we already know about some things that work
well, and some that don't, in a time-based journal of the user's work.

* Big Fat Eraser - this is a mode in the journal where you simply
click on things to delete them.  "Oops, no, I didn't want this web
page logged".  "Oops, no, I visited that file but it wasn't the one I
wanted".  For that you turn on the Eraser, and click away.

* A column-per-day view as in my original presentation - this is just
too sparse, and plays badly with scrollwheels.  The linear view (even
if it is on a rectangular grid) is much better and fluid.

* Web pages.  There are just too many of them in a single day!
Gnome-activity-journal helped here by grouping them in an expandable
item, "N web pages", rather than showing all the crap you visited
during a day.  An alternative would be to add an explicit "log this
page" button to Firefox, or something.

One of the things we need to think of soon is the immediacy of the
journal.  Having "Windows / Applications / Past Activities" in the
shell's Overview is just too clunky.  Seif posted to the list with his
idea to move those three actions to the shell's top panel, thus
replacing the "Activities" button.  I quite like that idea; it removes
one level of indirection from the things you do the most, and it gives
you present (windows), past activities (the work you did, the journal)
and future activities which you might do (applications), *right there*
in the main panel.

Another thing is the "grip" of the journal.  Making it a full-screen
thing within the Overview means that you can't easily drag a file from
the
journal into a running window:  you can't save a file from oowriter,
open an Evolution mail composer, and drag your file from the journal
into the composer to make an attachment.  If we had the "Past
activities" button right in the top panel (or somewhere as a
first-level object within the desktop), then we could perhaps pull it
down a bit so that it doesn't obscure your mail window, and then you
could drag the file from there.  Note that this is similar to what I
had in my GUADEC presentation - keep the journal very close at hand,
and don't make it use the whole screen.

Feedback is welcome!

  Federico