-
Most systems naturally let you browse their data (files or other items) in a top-to-bottom fashion: from a folder to a file, from a blog to a particular post, from a photo album to an individual picture. However, not all of them let you navigate the other way, and this impedes circulation among your data: they make it hard to regain context when you are viewing a single item.
Consider a traditional, hierarchical file system. The conventional way of operating on a file is through various "paths":
- You find the file in your file manager, and launch it. This launches an application window that shows your file.
- You launch an application, and use its File/Open command to open a file.
- You run a program from the command line and pass it an argument for the file to operate on.
Here, the movement is downwards: you go from a global context (your whole desktop, or file system), to a local one (the contents of your file or document).
When a document lives in such a hierarchy, it is likely to be in a folder or other kind of grouping with related items: pictures that need to be included in a textual document, data files that you used to build a final report, other files with the same tag or category, etc. It is natural to want to see these related items because of their proximity to the document you are using.
Such a system needs to provide upward movement from the files back to the desktop or file system. A simple "Show in file manager" command, for example, solves this problem: it lets you "step back" from the file you are visiting to see its surrounding context.
For a hierarchical file system, the "Show in file manager" command would make the file manager show the folder in which the file lives, while at the same time highlighting the file so you can find it. From there you can of course perform common tasks like rename the file, copy it, delete it, etc. — actions which may be cumbersome to do from within the program or sub-view that you normally use to edit the file, precisely because it is not designed to give you the context you need.
For any other kind of grouping (not a hierarchical file system), there would be an immediate way to show the group(s) in which the file or data in question lives. Again, this puts the file in context with its siblings, and gives you an appropriate context for general commands which work on the file itself (and on any other such files), rather than the specific commands to operate on the file's contents. For example, an photo viewer with tags should let you go from the particular photo you are viewing, to the photos that also contain the same tags as your photo: there it makes sense to have commands like "make photo album", which do not make sense within a single photo.
Therefore:
When viewing a single file or item, provide an obvious way to visit its surrounding context — such as the folder in which a file lives, or the groups to which an item belongs. This way you get downward and upward circulation from groups to items, and from items back to groups.
Relevant bugs
-
The problem/discussion/solution shown above is another of the problems to be discussed in the Document-centric Gnome wiki page.
-
What if the file chooser in Save mode (not "Save As") starts like this:
That wouldn't let you hit the Save button if there is no selection. But as soon as you select a recent folder, the pathbar shows you its full location:
If you browse to another place from the shortcuts bar, the file chooser looks the same as usual. There isn't a collapsed/expanded state at all; the file chooser always stays the same size.
This is part of "Help the user choose a place to put a new file".
-
Help the user choose a place to put a new file
People often save files to the wrong place.
When people create a new document, they reach a point at which they need to save it for the first time — they have been taught that the computer will lose their work unless they save it. Choosing a meaningful filename is hard enough ("homework.doc"); choosing the appropriate location is necessary to keep the document filed in the right place (e.g. the right project-specific subfolder under the toplevel Documents directory).
Our Save dialog looks like this by default:
No one likes the name "untitled", so people are compelled to change it to something more meaningful.
However, non-technical users often ignore anything past the "Name" entry for the filename: they type the first reasonable filename that comes to mind, and then they hit Enter or the Save button immediately — they completely forget to pick an appropriate location for the file. Later, they struggle to find where they put the file. At this low level of proficiency, they may actually have trouble figuring out how to move the file to a better location, so the file remains in whatever folder it got created.
Different programs have different policies for picking the default folder to save in, and that policy is reflected in the default choice in the "Save in folder" combobox:
- A specific, toplevel folder like Documents or Downloads.
- The last folder that was used in that application during that session.
- The last folder that was used in that application ever.
In the first case of Documents or Downloads, those folders are not specific enough — the user may already have created a folder for a specific project, so showing a toplevel folder is not useful.
The second case is better only if the last folder the user chose was actually the correct one, if he did at all. The third case means that if the user runs the program a long time after he ran it last, then the Save dialog will start with a default location that has no apparent relation to the user's current work.
Thus, using a default folder is in general unpredictable and incorrect. Moreover, the "Save in folder" combo box actually hides the available options — one must open the combo to see the other choices — and it is only after seeing that one's choice is not there, that one might try to look in the "Browse for other folders" option.
At least that is the theory. However, once people open the full file list with the "Browse for other folders" option, subsequent uses of the file chooser will have that section expanded by default. The result is a Save dialog that is cluttered by default, thus making it harder to make a choice.
Instead of a combobox that is easy to miss, the Save dialog should present a very visible list of locations in which it is likely that the user will want to save his file. The dialog should make sure that the user has made a choice before the file is saved, to avoid the problem of confirming the Save dialog too early, before an appropriate location has been chosen.
Therefore:
In the Save dialog, show an explicit list of likely folders to save the file in, and don't let the user confirm the Save action until he has picked a folder. Give the user the option of creating a new folder if there isn't an appropriate one already. Give the user a chance to see what is already in the chosen folder, so that he can see the context where his file will live.
Mockups
Default view, collapsed file list
If the user hits the "Save" button or otherwise confirms the dialog without selecting a folder first, we show a warning like this and don't close the dialog. "Browse" opens the file list for the selected folder if there is one, or for any folder if there is no selection.
Expanded file list
When the user hits "Browse", the list of likely folders disappears and the traditional pathbar takes its place (ignore the misalignment in the mockup above; the "Save in folder" label and the pathbar are really in the same row). The rest of the shortcuts bar and file list appears below.
Other considerations
Once the user picks a folder and saves the file, both need to appear in subsequent uses of file pickers, as the user may need to refer to that same file or location again. The file is now part of the user's working set of data.
Relevant bugs
-
The problem/discussion/solution shown above is the first of the problems to be discussed in the Document-centric Gnome wiki page.
-
Mind-map of Document-centric Gnome
GtkFileChooser
Icon view - We have a lovely branch by Simo Kivimäki to add an icon view mode to GtkFileChooser. We are having some problems with GtkIconView and editable filenames for the "Create folder" command.
Shortcuts bar revamp - Jon McCann made some very nice patches to improve the look of the shortcuts bar, and other visual improvements for the file chooser. There are some problems (noted in the bug) that prevent this from being merged.
Big refactor/cleanup - The file chooser's code is messy. I'd like to clean it up gradually and pull out subwidgets that may be useful elsewhere - the shortcuts bar, the filename entry with completion, the path bar.
Show recent folders explicitly in Save dialog - The Save dialog has an easy-to-miss combobox with your shortcut folders. This needs to be replaced with a more prominent list of recent folders that are really useful.
Nautilus
GtkPlacesView - The shortcuts bar needs to be pulled out of GtkFileChooser and made usable for Nautilus as well. We need to examine what both implementations do differently, and what can be made common. In theory they should be the same, maybe with some extra actions for Nautilus.
D-Bus interface for "sendto" - Right now some apps add a "Send to..." command for documents that just calls nautilus-sendto(1). Maybe this should be based on D-Bus and standardized through XDG? Or maybe we should let the current activity around sharing documents take care of this?
D-Bus interface to show a file - This is for the "Show in file manager" command that I've been writing about. Akshay Gupta, my Summer of Code student, is implementing this.
Applications
Audit: Don't set a predetermined folder in the file chooser - Described in more detail here; apps are currently setting the startup folder for the file chooser when it would be better to let the chooser make that decision itself, or simply present the user with his recently-used folders.
Audit: GtkRecent use - It seems that not all apps use GtkRecent as thoroughly as they should. They need to log entries when the user opens a file through the command line or the menus, when the user saves a file in any fashion (Save command, Save Attachment, etc.), and in general when apps do any user-initiated interaction with files.
Zeitgeist
GtkRecent timestamps - GtkRecent is very dumb about dealing with timestamps in the files it logs, and is not really consistent with timestamps for creation/modification. Zeitgeist would like more details.
Also, this raises the question of whether we should deprecate GtkRecent and friends, and make apps just log directly to Zeitgeist — they would be able to provide much better information that way. (In the meantime, GtkRecent could itself log events to Zeitgeist, bypassing the need for Zeitgeist to monitor the recently-used.xbel file).
Dashboard for applications - You know the horrible "what do you want to create or open" dialog when Impress starts up? The Zeitgeist hackers produced a much nicer dashboard for Gedit, which could be used for other create-a-document apps as well.
Gnome-shell
Journal - The time-based journal, as a view of what you have done recently. Akshay Gupta, my Summer of Code student, is working on this.
_NET_WM_CURRENT_URI - If a window is showing a document, then it also has a window manager property that says the URI of the document. There are many details to be figured out (windows that show multiple URIs in tabs?), but there is a suspicion that this would be useful for several things (e.g. the shell can bring an already-existing document window to the front instead of launching it again).
Call for help
These are many, relatively fine-grained tasks. Help is much appreciated! Mail me for details.
-
One thing that bothers me about Apple's web page
Is the pervasive, reusable, photoshopped components.
Exhibit A:
Exhibit B:
If we take the pointing finger from the first image, rotate it, and scale it...
Also, note the identical, diagonal highlights on the glass surfaces (also, suitably rotated in the first image from this post, where a hand is holding the phone).
The fingers never reflect on the glass surfaces. They cast the faintest of shadows. The "Home" button is shaded uniformly.
Somewhere, someone has a very carefully crafted Photoshop image, with various layers to do the highlights, buttons, screen areas, body parts.
But it's all fake, I tell you. I can tell by the pixels.
-
“A master plan is a detailed design, and many projects consider critical their detailed designs. But a master plan is usually not possible, especially for extensive, long-lived software. Alexander writes:
It is simply not possible to fix today what the environment should be like [in the future], and then to steer the piecemeal process of development toward that fixed, imaginary world. (Alexander 1975)
This simply acknowledges that it is impossible to predict the circumstances of a long-lived program. But there is a more important point:
Master plans have two additional unhealthy characteristics. To begin with, the existence of a master plan alienates the users... After all, the very existence of a master plan means, by definition, that the members of the community can have little impact on the future shape of their community, because most of the important decisions have already been made. In a sense, under a master plan people are living with a frozen future, able to affect only relatively trivial details. When people lose the sense of responsibility for the environment they live in, and realize that they are merely cogs in someone else's machine, how can they feel any sense of identification with the community, or any sense of purpose there?
Second, neither the users nor the key decision makers can visualize the actual implications of the master plan. (Alexander 1975)
It should be clear that, in our context, a "user" is a programmer who is called upon to maintain or modify software; a user is not (necessarily) the person who uses the software.
[...]
Finally, if Alexander's lesson applies to software, it implies that a development project ought to have less of a plan in place than current thinking allows. This provides a mechanism for motivation and a sense of responsibility to those developers who later must work with the code.”
From Patterns of Software: Tales from the Software Community pp. 13, a beautiful book by the amazing Richard Gabriel (CC-licensed). He's the "Worse is better" guy, if you need a reference.
-
No, wait, master plans are right!
Isn't Joel Spolsky a big fan of Big Up-front Design?
I believe that on any non-trivial project (more than about 1 week of coding or more than 1 programmer), if you don't have a spec, you will always spend more time and create lower quality code. Here's why.
The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec -- describing how the program works in minute detail -- will force you to actually design the program.
How about that?
-
The ticket booth - is the master plan just a starting point?
Alexander's PhD dissertation, which was the basis for his book "Notes on the Synthesis of Form" from 1964, tried to mathematize design by defining it as a progression from a series of requirements to a final result, through an analysis of the forces that shaped the design.
Let me quote Richard Gabriel, when he describes the time when Alexander was trying to design a ticket booth based on his mathematical ideas.
“Alexander says [about the Quality Without A Name]:
It is a subtle kind of freedom from inner contradictions. (Alexander 1979)
This statement reflects the origins of his inquiry into the quality. It started in 1964 when he was doing a study for the [San Francisco] Bay Area Rapid Transit (BART) system based on the work reported in Notes on the Synthesis of Form (Alexander 1964), which in turn was based on his Ph.D. dissertation. One of the key ideas in this book was that in a good design there must be an underlying correspondence between the structure of the problem and the structure of the solution - good design proceeds by writing down the requirements, analyzing their interactions on the basis of potential misfits, producing a hierarchical decomposition of the parts, and piecing together a structure whose
structural hierarchy is the exact counterpart of the functional hierarchy established during the analysis of the program. (Alexander 1964)
Alexander was studying the system of forces surrounding a ticket booth, and he and his group had written down 390 requirements for what ought to be happening near it. Some of them pertained to such things as being there to get tickets, being able to get change, being able to move past people waiting in line to get tickets, and not having to wait too long for tickets. What he noticed, though, was that certain parts of the system were not subject to these requirements and that the system itself could become bogged down because these other forces - forces not subject to control by requirements - acted to come to their own balance within the system. For example, if one person stopped and another also stopped to talk with the first, congestion could build up that would defeat the mechanisms designed to keep traffic flow smooth. Of course there was a requirement that there not be congestion, but there was nothing the designers could do to prevent this by means of a designed mechanism.”
From Patterns of Software again, pp. 35.
As a programmer, does this sound familiar? You can make a beautiful, thorough design, that crumbles down when you actually build it because things emerge that you did not anticipate. This is not a failure of your design, but of something else! Richard Gabriel goes on:
“Alexander said this:
So it became clear that the free functioning of the system did not purely depend on meeting a set of requirements. It had to do, rather, with the system coming to terms with itself and being in balance with the forces that were generated internal to the system, not in accordance with some arbitrary set of requirements we stated. I was very puzzled by this because the general prevailing idea at the time [in 1964] was that essentially everything was based on goals. My whole analysis of requirements was certainly quite congruent with the operations research point of view that goals had to be stated and so on. What bothered me was that the correct analysis of the ticket booth could not be based purely on one’s goals, that there were realities emerging from the center of the system itself and that whether you succeeded or not had to do with whether you created a configuration that was stable with respect to these realities. ”
And that is the core of the problem: how do you create a configuration that is stable with the realities that emerge from itself as you build it?
More about this here, in my blog, and in my upcoming talk at the Desktop Summit, Software with the Quality that Has No Name — to which you are cordially invited.