Hack Week 2010 — Client-side awesome
It is Hack Week this week, when all of Novell's
hackers work on whatever project they want for the whole week.
The infrastructure for Document-Centric GNOME
is coming along just fine. The Zeitgeist
hackers are kicking all sorts of ass with the engine and
the activity
journal — that's what lets you see your work
in a nice
timeline.
Another part of the document-centric vision is to allow
comfortable flow or
circulation through your files, which
is sorely missing right now.
Placeless documents
Let's say you open a document. It doesn't matter how
you open it — by double-clicking on it in
Nautilus, by clicking on an item in your
activity-journal's timeline, or by a File/Open command.
The document window you get is something like this:
This document window tells you the title or filename,
but it does not let you see where the document
is stored. It also does not let you access documents
which may be near the place where the original document
is stored.
The user interface does not give you any hints about the
place in which your document lives. Your
document is effectively placeless, you have no way to
orient yourself, and you have every reason to feel lost.
What would Christopher Alexander do?
A couple of months ago I wrote a little introduction
to the work of Christopher Alexander, the
architect behind the monumental book A Pattern Language
and others.
There are several patterns in
A Pattern Language that deal with how
you move from place to place and how
you orient yourself, either in the city
or in a building. To solve the problem of
disorientation and placeless documents, I think we can
grab ideas from these patterns:
Main
gateways. "Any part of a town - large
or small - which is to be identified by its inhabitants
as a precinct of some kind, will be reinforced, helped
in its distinctness, marked, and made more vivid, if the
paths which enter it are marked by gateways where they
cross the boundary. [...] Mark every boundary in the
city which has important human meaning - the boundary of
a building cluster, a neighborhood, a precinct - by
great gateways where the major entering paths cross the
boundary."
Circulation
realms. "Lay out very large buildings
and collections of small buildings so that one reaches a
given point inside by passing through a sequence of
realms, each marked by a gateway and becoming smaller
and smaller, as one passes from each one, through a
gateway, to the next. Choose the realms so that each one
can be easily named, so that you can tell a person where
to go, simply by telling him which realms to go
through."
The
flow through rooms. "The movement
between rooms is as important as the rooms themselves;
and its arrangement has as much effect on social
interaction in the rooms, as the interiors of the rooms.
[...] As far as possible, avoid the use of corridors and
passages. Instead, use public rooms and common rooms as
rooms for movement and for gathering. To do this, place
the common rooms to form a chain, or loop, so that it
becomes possible to walk from room to room [...]"
Circulation for your files
File managers like Nautilus let you navigate
down in the hierarchy of folders until you
reach an actual document. But once you open a document
window, you cannot navigate up to look
for related files, or even to see the folder in which
the document is stored. If you open the document with
something other than the file manager, you will have a
hard time knowing where the document is.
We can solve this by adding a "Show folder" button
to document windows, preferably so that it is close to
the document's name or filename.
When you click on that "Show folder" button, it
takes you to the document's parent folder. In turn, we
can make folder windows in the file manager similar,
with a "Show parent" button to go further up in the
hierarchy.
By adding a single button that is close to the
document's or folder's name, we can let you
navigate up in the hierarchy, just as
you can currently navigate down with
the file manager. This adds circulation and flow to
your files.
Name-able gateways
Every time that I click on a PDF link while I'm browsing the
web, the following happens:
-
The PDF gets downloaded and put somewhere.
Sometimes in /tmp, sometimes in
~/Downloads, depending on which button I
click in Firefox's "what do you want to do with this
file?" nag-window.
-
Evince opens up to show me the PDF. In a few
seconds I can tell if the PDF is something worth keeping.
-
If I decide to keep or delete the PDF, I cannot move
it easily to a good place or to the trash— I
have no way to visit the PDF's parent folder so that
I can drag it to another place. This would be
solved with the "Show folder" button described
above.
-
For some reason, PDFs always seem to have terrible
names: presentation.pdf,
2010.pdf, 10.1.1.55.8788.pdf. CiteSeer, I
am looking at you. And yet there is no easy way to
rename the document right there.
This also happens when someone sends me an email
attachment. They give it a crappy name, I want a better
one, but there's no easy way to do it right there.
In the mockup screenshots above, you can see that
windows for documents and folders actually let you
edit the filename right there. Instead
of having a static filename in the title bar, you
actually have a text entry that you can edit. If I
could rename 10.1.1.55.8788.pdf right from
Evince as I view the PDF for the first time, my
~/Downloads folder would be a much friendlier
place.
This is akin to having physical gateways with big name
tags. You always know where you are, and you always
know that you can go to a place nearby.
Client-side what?
Unfortunately, window managers don't let you customize a
window's title bars like that.
The valiant Cody Russell
has been working on the client-side-decorations
branch of GTK+. With this, you would be able to
have a toplevel window and decorate its frame yourself,
without the window manager's intervention.
Having control of a window's frame means that we can
stick a GtkEntry there for the rename-able filenames,
and a GtkButton for the "Show folder" action.
(Yes, this would also let programmers add all sorts of
crap to their windows, but apps will shitty UIs
will just kill themselves.)
However, having an application paint the window's frame
by itself also means that it should paint it
exactly in the same way the window manager
would, or the window will look out of place.
My Hack Week project is to rip the code from
Metacity/Mutter that reads a window manager's theme, and
paints the window frames, and make that code reusable
for GTK+. This way document windows would look exactly
like normal managed windows, but with the addition of
the few extra controls we need.