Sunday, February 28, 2010

Nautilus in the stress field between design and function

So, there's been a lot of talk about Nautilus' present and future design. Especially Izo's article collects some interesting proposals for design enhancement that are in my opinion very well worth consideration. It does, however, also contain some points that make me feel a little uneasy.

Naturally, UI redesign comes not only with re-organisation and re-design of existing functionality, but also with omitting of unimportant components. Also naturally, the latter part is tricky to get right, because people don't like it when the functionality that they are habituated to use is suddenly gone, without any accessible replacement. I don't mean to say that UI reduction is impossible, but it's something that has to be considered carefully, according to the focus and target audience of the project. This is a hard process, because individuals or small groups don't necessarily cover all the use-cases that an application wants to address.

Izo seems to have a typical case of forgotten addressed use-cases in his review when he writes about the stop button:
"The stop button. More useful in web browsers, if you want to stop the web browser from loading a page, completely useless in a file manager, where file accessing times are considerably quicker than web browsing times. You simply never have an opportunity to stop the file manager from loading a page. It’s an old relic. I’ve never used the stop button."
That you have never used a stop button in a (network transparent!) file manager does not mean that it's "completely useless". Got the hint in the parentheses? Nautilus does indeed want to support network filesystems, be it NFS and friends or GIO/GVFS mounted stuff. Loading these is actually not too different to what you do with your browser. These can clearly be very slow, and that you didn't think of that just shows that you forgot an important use-case that Nautilus wants to support, because you have no personal use for it.

Now, I am not saying that the stop button is the best design for that. It most probably isn't. One could for example test if it could be combined with your proposal of the "refresh" button: Display the "refresh" symbol when the displayed location is fully loaded, and put a little stop symbol there while it's loading (this combination of stop/refresh has been proposed before in "Simplified Nautilus").

People are different, and have different ways to use applications. Many other proposals, for example, just assume that the sidebar is visible. You mean to save a little bit of screen space by omitting the small "Home" toolbar button, arguing that it's also accessible in the sidebar? Well, when I look around, a fair number of computer-novices that I see don't have the sidebar visible at all. When forcing it upon them, they actually loose a lot of screen estate, and have a lot more unwanted UI elements in their face. Combine that with the talk about removing the menu bar alltogether (and thus loosing the habituated easily accessible way to toggle the sidebar visibility), and you have a good potential to regress usability for a non-negligible part of your target audience. In the end, people don't open Nautilus to lay back and enjoy its look, but to get work done.

I am also not entirely convinced that it's so bad to have two toolbars. I mean, how much screen estate do you loose, in reality? For one thing, the toolbar covers less space than the sidepane. In browser mode, you typically don't have dozens of Nautilus windows on a single workspace (and as I said, the toolbar covers less space than the sidepane). On the other hand, even if you have reduced the number of toolbar buttons to six plus a wide-enough search window, as your mockups show, what's better: To use a few vertical pixels, or not to be able to see your current folder "Pictures from Patrick's wedding where aunt Maggie got really drunk"? Hard to say.


Split View - Curse or Blessing?

Having the location bar embedded into the toolbar items also has another problem: It doesn't work well with the a split-view filebrowsing mode. This mode got some very harsh criticism at the recent designers hackfest that I stumbled upon by coincidence (strangely, this discussion didn't find its way to Nautilus communication channels yet). I wrote some comments on the corresponding blog posts, but I also want to write a small comment about that here on my own webspace, without the risk of being moderated (as seemed to have happened on other people's digital homes, which obviously found my remarks unpleasant).

First of all, I am disappointed by the way the criticism was expressed. The designers may very well have some valid points, but I wouldn't know, because they seem to actively refuse to answer my request to elaborate on their non-descriptive slating. Also, there are some remarks that make it look like they didn't even give it a fair try before condemning it.

A reccurring question was "why split-view", and the proposal to implement panes in the window manager instead. This is a valid question, and has in fact been discussed on the Nautilus mailing list. (Hint: In general, project mailing lists are a good place for both, to research design decisions and to ask the "why" question.)

Fact is, split-view filebrowsing is not trying to solve window manager shortcommings on the wrong level. Even if Metacity had snap today, this wouldn't be an alternative.

The key difference is the inherent connection between those two panes, which gives clear benefits. When you want to do file management (which is now becomming the key-focus of Nautilus), you often have to deal with two locations at the same time: The source, and the target. What split-view does is to display a "default target" right next to the source. That's why it makes sense to have 2 panels, but not 3 or 4.

This default target is accessible in the menu, via the "{Copy| Move} to other pane" items. Users that need to do heavy-duty file handling can assign keyboard shortcuts to those menu items, and move around files with a single button press.

The “default target” notation offers even more for advanced users, which can access both the source and the target pane in their Nautilus Scripts (and write for example a “diff these two directories” script with very little effort). This surely isn’t possible with a WM snap either.

Users with simpler needs aren’t really affected much by of all this. The only effect for them is that “extra pane” option in the view menu that they don’t wanna click.

I actually think that it is a very natural model to show source and target location when they are that fundamental to the typical action that the user wants to do with a given application. I find it much more intuitive than the clipboard copy/paste stuff that is generally accepted because people got used to this strange idea.

Photo © Adventures in Librarianship on flickr, cc-by-nc-sa

11 comments:

  1. I think the best solution for various issues of the UI interface would be to give more options to the user to tweak the UI. Many (if not most) apps nowadays - also GTK-based ones - allow the user to change the toolbar - Nautilus still does not.

    Firefox probably wouldn't be the success it has become if it wasn't for it's great expandability. With over 50 add-ons installed I've changed FF to the best browser I can imagine (nevermind speed-issues, that's another story). I changed the toolbars, tweaked the status-bar, made the menu-bar disappear, created a custom menu-button, even changed the context-menus (with ffchrome). My Firefox basically now resembles Chrome on the surface, but gives me a whole lotta more functions beneath.

    The only 3rd-party extensibility / modifications Nautilus allows are user-scripts and user-actions - which are useful but tend to clutter the context-menus. So here's my 20 cent:

    1. May the GNOME devs deliver Nautilus with whatever default config they deem balanced!

    2. But may they also add an plugin-interface for 3rd-plugins adding new functions (e.g. batch renaming, column-based browsing like in Dolphin or OSX finder) as well as already existing functions (like tabbed browsing, dual-panes, etc. pp.)!

    3. May the GNOME gods also add more options to configure the UI for advanced users (like custom toolbars, switching on/off options in the main-menu, customised context-menus etc. pp.)

    ReplyDelete
  2. @Anonymous:

    > Many (if not most) apps nowadays allow the user to
    > change the toolbar - Nautilus still does not.

    There's a toolbar editor in the making, but it takes time (lacking manpower).

    > The only 3rd-party extensibility / modifications
    > Nautilus allows are user-scripts and user-actions

    No, Nautilus Scripts are not the only way of extending. There is a plugin API for C and Python.

    ReplyDelete
  3. There must be something wrong with the plugin API that there are no plugins yet. Or maybe I am missing sth?

    ReplyDelete
  4. There are plugins for both, the C and the Python API. A few that spring to my mind are nautilus-open-terminal, nautilus-sendto, nautilus-gksu, nautilus-dropbox, nautilus-rabbitvcs, nautilus-actions (yes, this is a third-party extension itself). I'm sure you'll find more if you go looking for them.

    ReplyDelete
  5. The Izo article is clearly totally ignoring every use of Nautilus other than standard local filesystem browsing. Because *he* doesn't use Nautilus for network file access, he's decided no-one does so we can all use a carbon copy(*) of the OS X file manager instead. Not impressed.

    (*: no pun intended)

    As for combining the Stop and Reload buttons, it's been done before (eg. in old versions of Opera) and the results are poor. Invariably the Stop button mutates to Reload just at the moment you click on it, thus doing the exact opposite of what you want.

    ReplyDelete
  6. Hi, interesting. I'm not saying Copy To and Move To aren't without merit. But I think it's confusing to have both a "Copy" and a "Copy To" item that behave very differently; this is confusing for new users. Also, having these menu items on every file promotes the idea that they are the main way of moving and copying. They're not: as you point out, these menu items are intended only for "heavy duty file manipulating." So why have them there by default? I say, move this functionality into a plugin that can be installed optionally for those who need it. Having this seldom-used functionality enabled by default introduces too much clutter, and right now simplicity is one of the things that Nautilus really has going for it.

    ReplyDelete
  7. @bobince: Yeah, you're most probably right that combining stop and reload is not helpful either. The defensive formulation ("one could test if ...") was not a coincidence. ;-)

    @John Baptist:
    > But I think it's confusing to have both a
    > "Copy" and a "Copy To" item that behave very
    > differently; this is confusing for new users

    I don't agree. What can be clearer than "Copy to $WELL_KNOWN_LOCATION" ? I can't get any clearer. If anything, the Copy/Cut/Paste actions are confusing, because the Clipboard is a pretty abstract concept.

    ReplyDelete
  8. @bobince: The problem you raise with a combined Stop/Reload button was elegantly solved years ago by disabling the button briefly when the page finishes loading. Firefox does this in nightly builds. This could be done in Nautilus as well.

    ReplyDelete
  9. >Users that need to do heavy-duty file handling can assign keyboard shortcuts to those menu items, and move around files with a single button press.

    Im trying to find a solution on the web, to do exactly this, Does anybody know how this is accomplished? Thank you very much.

    ReplyDelete
  10. I arrived here looking for a shortcut to copy or move to the other pane in nautilus... I guess no answer here. I'll keep looking. If I find something, I'll post it here. Bye!

    ReplyDelete
  11. Assigning shortcuts to "copy/move to" works just like assigning shortcuts to other menu items in Nautilus, or many GTK+ applications in general: Make sure the theme setting "gtk-can-change-accels" is on (in former versions of GNOME, this can be done via gnome-appearance-properties -> interface tab, in recent versions without this tab it's the gconf key /desktop/gnome/interface/can_change_accels). Then assign a shortcut as described in http://library.gnome.org/users/user-guide/stable/prefs-appearance.html.en#prefs-menustoolbars

    ReplyDelete