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 for Save mode

Startup state, unselected:

One recent-folder is selected:

Here there is no "collapsed" version of the file chooser; it always appears expanded, but the Save dialog starts with the Recently Used mode showing only folders. If the user hits Save without first selecting a folder, he gets a warning (probably in the space for the pathbar). When he selects a recent folder, its full path appears in the GtkPathBar. The user can browse to other places by using the shortcuts bar, as usual.

Old/discarded mockups

The idea was to show a collapsed Save dialog, with a list of recent folders, and a Browse button to see the full/expanded version of the dialog. We have an integrated version in the new mockups above.

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

• 593793 - show recently used folders in the file dialog

Comments and discussion

Milan Bouchet-Valat: about http://people.gnome.org/~federico/news-2011-06.html#choose-a-place I don't really like the idea of clicking yet another button to see the whole file chooser. Instead, I'd suggest you add recent folders in the Recents place of the sidebar, and show it by default. This makes the UI much less disruptive. And if user wants to save the file in a subfolder of a recent folder, he just needs to double-click on it, and it opens in the browse mode, without moving all widgets around: this case happens quite often, and is one of the reasons why the current combo box is a failure IMHO.

FedericoMenaQuintero: my hypothesis is that you bring up the whole file chooser *because* the combo box doesn't give you any useful options. Acquiring the correct folder the first time is cumbersome, and you have to do it over and over again unless you create a bookmark. If you got a list of genuinely useful folders from the beginning, you wouldn't need to expand the whole file chooser every time. I do agree that the recent folders should also be in the sidebar; see bug #642712 for that.

Milan Bouchet-Valat: I understand this hypothesis, and I really believe it's a good idea to rethink this part of the workflow. But while showing a list of recent folders is a big improvement, I see at least two reasons why this list should appear directly in the file choose instead of in a custom dialog:

1. You get more vertical space anyway with the full dialog, and it's likely needed if you want to avoid too much scrolling (e.g. show about 10 recently used folders, while in the mock-up you only can show 3 of them, far too little).
2. It's bad to have UIs change too much if we can avoid it. It will relatively often happen that the user needs to choose a non-recent folder: in that case, clicking on a button that completely transforms the dialog is bad, it forces you to adapt to the new dialog. Much nicer if he could just choose another place in the sidebar: people only have to know one dialog, they don't feel lost when clicking on that mysterious Browse button.

FedericoMenaQuintero: (Thanks for moving the discussion here!) About (1) - it's just a mockup; we can make the implementation show as many lines as we like by default

About (2) - "It will relatively often happen that the user needs to choose a non-recent folder" - I think this is precisely what will no longer happen. If you need a folder often, you'll have it there. If you need a random folder that you almost never visit, you can Browse. It's like caching; you can't help the case where you seek randomly. But for other cases, once you acquire a folder the first time (by creating a new project folder in the file manager, or by opening a file in a folder that you'll be using), it will stay there, as part of your recent-folders, until you do so many different things that it gets pushed away.

The problem with showing the full file chooser by default is more than just the clutter - it is that it *actually shows a selected folder*, so users *can* click Save without actually confirming that it's the correct folder they want. I definitely want to experiment with showing the collapsed version *with* the recent-folders by default. If it ends up being too cumbersome, we can retain the code to make the chooser remember its expanded/collapsed state.

Finally, maybe "Browse" should be called "Look for other folders" or something more explicit like that.

FedericoMenaQuintero: How about this? Please look at the two new mockups I posted above. There is no collapsed state now; the chooser starts up in Recent Folders, and the pathbar reflects whether there is a selection or not.

Milan Bouchet-Valat: Yeah, that's exactly what I had in mind. Thanks for creating the mock-up! I think the risk that people might click Save without choosing a folder is easily avoided if we disable the Save button until a folder is selected (and anyway we would show the recent folders list by default) - anyway, you have the same problem with you first mockup...

FedericoMenaQuintero: Perfect, so we have a winner now. I'll work on implementing this next week.

LuisMenina: If the goal is to encourage people to use the "recently used" feature, I have a few questions:

• do you think the items should be sorted by last access (more recent on the top), or alphabetically (to stay consistent with other displays)?
• a user would look at recently-used directories first, then personnal and bookmarked directories, and if the directory he wants is not there, he is left with the search and/or exploration of the filesystem. So shouldn't the items appear in this order on the left pane (most useful on the top)?

FedericoMenaQuintero: For the recent-folders list, it should definitely be sorted by last access - it is that way in the code now. For the shortcuts pane, I agree that it should have a different ordering than the current one. Jon made a very nice patch to improve the shortcuts. There are still some bugs in its behavior, but it's a great start. I think I'll polish this patch some time next week or so.

ØyvindKolås: Being able to ad-hoc define time and user dependent smart orderings of lists as this recently used folders list are among the usage scenarios that sourcerank is meant to deal with; could be a useful thing to try if last access doesn't do enough to put the most useful one on top.

BaptisteMilleMathias: Hi Federico, Regarding http://www.gnome.org/~federico/news-2011-07.html#01 , please don't use Infobar in the FileChooser, this is a total non-sense to add widget just to help people identify action to perform. This is perhaps there is something bad designed in the file choose, I don't any value adding crap on top of it.

FedericoMenaQuintero: Øyvind - interesting, thanks! To Baptiste: got any better ideas?

BaptisteMilleMathias: Better idea may be just to save it to the home folder. When I watch most people work with files I see they just open from the recent items menu in the application. They don't know about folders for the most part, except when they're looking for something they can't find in recent. Two other points: I thought Gnome 3 was moving away from forcing people to maitain a heirarchical organization of their files; Forcing them to choose a folder seems to work against that. Second, possibly unrelated anecdote, but interesting: I was helping the father in law with an email. He was working on it and hit save as draft, then when he wanted to keep working on it he was looking in nautilus, in his home folder, because when he saves attachements that's where they go. Cheers,AM

LuisMenina: I agree with Baptiste here... I also found that kinda awkward. Disabling the "save" button until a valid directory is selected might be enough... Likewise for the "search" item.

FedericoMenaQuintero: To Baptiste and Luis: I agree that a sensitized Save button that flames you with an error message is bad. It is going to take some work to make it possible to de-sensitize the Save button: the application creates that button, not the file chooser, and GtkFileChooserDialog right now has some heuristics to detect the "primary" button in the dialog. The GtkFileChooserEmbed internal API is so that the dialog can say, "ok, the primary button was pressed - now I'll ask the internal GtkFileChooserDefault whether the dialog can be confirmed/closed or whether it needs to stay up". Also, even with a de-sensitized button, I wonder how to tell the user that he much choose a location before the button will be enabled.

To Baptiste: While we absolutely want to move away from a strictly hierarchical organization for files, we don't have the infrastructure for this yet. I think the traditional filesystem still has merit: it is stable, all applications understand it, and having a way to organize your information is better than having none. Once we have an always-visible journal of your work, we can start to move away from "files need a place", and into "files can just go into the journal, and you can further organize them if you wish". And after *that*, we can look into semantic file management. Gnome-documents is adopting Tracker as a metadata store (which we lacked before), so we can use that metadata as the foundation for a semantic file manager like what Sebastian Faubel was proposing in his Organise Framework.