Nautilus Journal

People have a hard time dealing with their everyday files, as well as looking for old files from projects which they have completed. Here are some of the problems:

People hit "File/Save", they type a more or less useful filename, and they don't notice where the file got saved. Programs have different policies for which folders they pick by default. Some always use ~/Documents, some others use the latest folder you used, etc. If you save a file in one program ("save attachment") and need to open it in another one ("insert picture"), it is very unlikely that both programs will default to the same folders in their file dialogs. This causes people to lose their files, as they don't know where the software decided to put them and have no obvious way of finding out.

People normally do not understand hierarchical file systems. Computers like deep, static hierarchies, while people prefer ad-hoc piles of related stuff (just look at your desk and bookshelves). However, people appreciate tools which let them have ordered views of their data based on different criteria: files that they created during a certain period of time, all files related to a project, files they shared with certain friends.

Notes on design and implementation

File management is a very large problem with many implications (infrastructure, user interface, collaboration, revision control, searching, tagging, metadata, etc.). It would be impossible to design everything in advance, or to reimplement big chunks of the desktop in one step.

The ideas in this document are presented in order, so that by implementing the first of them we will have a good test-bed for future ideas and implementations. We will try to implement the low-hanging fruit first, even if we need to tweak the appearance and behavior in the future. We will try to solve some of people's problems as soon as possible, instead of making them wait for years for the "perfect" design and implementation.

In short: this is an evolutionary process of design and implementation, not an global redesign/rewrite.

The journal

People have a reasonably accurate idea of when they last worked on something, or they can easily jog their memory to remember: "oh, I worked on my dissertation a day after watching Batman with my friends, so that must have been two Fridays ago".

Just like computers, people keep a working set of data, or things that they did within a more or less continuous period of time. You work on texts and images while writing a paper; then when the paper is done, you may not touch those files again until you refer to them later. During the time you are creating the paper, you consult web sites, write mails to colleagues, have IM conversations possibly related to your work, etc. It is useful to keep a log of the things that you do while you work on a project, and the computer is perfectly capable of keeping this log for you.

Here is a rough sketch of such a journal:

Timeline and views

By default, the journal shows a timeline with all your work: files you worked on, IM conversations you had, emails you wrote, web pages you visited. To aid your memory, you can also write notes by hand within the journal ("went to the library and checked out Book A and Book B", "phoned my mom about the house budget").

The journal will need different views. The default view should show a reasonably small period of time, such as "last week up to today", as it is likely that people will find their latest work there. They can scroll back in time to find older files, or switch to a view which shows them a larger range of time: monthly view, yearly view, flat chronological list, etc.

Easy access to the journal

The journal may become the main way in which people access most of their everyday files (e.g. not archived files). So, we need to provide easy, ubiquitous access to it. You should not have to move windows away to access the journal.

The mockup above puts the journal in a tab which slides out from the edge of the screen. We can make tabs be hidden by default, so that they do not obstruct the edges of other windows. However, the tabs should slide out when the mouse moves to the edge of the screen (the window manager can use an InputOnly window to capture this condition).

Tabs can be easily implemented with window manager hints, and made available to any program, as described in this slide.

Filtering and metadata

It may be useful to filter the journal to only show certain kinds of things. Filter by tag (only items related to Dissertation), by data type (only images, only IM conversations), by source (only files that were emailed to me).

As we start implementing a metadata framework (see below), the journal will be enhanced to display richer information.

Important items

People may have particularly important items in the journal that they don't want to lose in the scrollback. To help with this, the journal lets you "star" items; when you mark an item by clicking on its star, the item always appears in a persistent column to the side of the journal (similar to Tomboy's pinned notes).

Creating new documents

People can directly create new documents from the journal. This is equivalent to you grabbing your paper notebook, opening it on the first available blank page, and drafting something: you create something, but you don't immediately select an appropriate place to put it yet. If you decide later that your draft is important enough to keep it in a special place, you will likely tear that page away from your notebook, and put it in a folder or stack of papers related to a particular project. In the computer's journal, this would mean dragging a file from the journal into a particular folder. By default, files created from the journal don't live in any folder in particular (we can simply use ~/Documents or ~/Temporary-holding-area or whatever). Files which you move to a specific place still show up in the Journal, but they now have an "official place" which you selected for them.

Implementation notes

In the beginning, the journal can simply show the information from the Recent Files store.

The journal is pluggable so that applications like web browsers and IM clients can provide their own items for inclusion in the journal.

Existing work

Nautilus with journal view - look for the document-centric branch in the Git repository.
OLPC journal
Nemo - a time-based file manager for GNOME
Karl Lattimer's mockup and blog post
Documents in Evolution - Dave Richards's hack to turn the recent-files store into an .ics file.