January 26, 2005

proxyicon

A Proxy File Widget

I seem to be becoming rather opinionated and very critical of my user interfaces. I'm not sure whether this is a good or a bad thing. The more opinionated I get about a subject the more I seek information with a slant and I tend to close my mind somewhat, which has got to be bad, although there's nothing like the ramblings of zealot to set me back on the straight. My experience with HCI is a little limited, I only know what I've read on the Internet so I may be way out with some of my assumptions. Taking that onboard; I've been playing around with a proxy file widget.

Both Gnome's HIG and OS X's HIG recommend using an SDI, where there is a one-to-one mapping between documents and windows. This enforces the desktop metaphor, the window effectively is the document. Document windows in OS X have a small proxy icon in the title bar which allows you to directly manipulate the document via drag and drop and also view the document's path and open any folder along the way. The applications in Gnome use a variety of interfaces; one which uses the SDI well is Eye of Gnome, the image viewer. My biggest frustration with Gnome's SDI however, is that the metaphor stops there, the document is shown in the window, but there is no way of manipulating the document, hell, you can't even tell which document you're looking at once it's open. This is really an aside though, venting a frustration, I wanted to draw attention to OS X's proxy icons. Below is a screen capture with the path pop-up menu.

The path pop-up menu of OS X's proxy icons shows the path to the current file with each menu item opening a Finder window at that location.

Nautilus, Gnome's file manager, contains a widget which provides the same functionality as the path pop-up menu that the proxy icon provides in OS X, allowing the user to jump up the folder hierarchy. It lives in the bottom left hand corner of every window and allows easy navigation up the filesystem. I don't think it's as good as OS X's—the icons aren't present and the top level is printed as the forward slash character (urgh). The biggest difference between the two is that OS X's is top-down with the folder is at the top of the hierarchy, whereas Nautilus's is bottom-up, we're at the bottom of the hierarchy. I suspect that these designs came about partly from the position of the menu, being on the top of the window in OS X and the bottom in Gnome, causing both menus to pop-up over the current window. That aside, I think I prefer OS X's top-down view, giving the document the most importance as the current focus.

A pop-up path menu is provided in the bottom left hand corner of corner of every window in Nautilus, similar to that in OS X.

OS X appears to strive to hide the semantics of paths. That is, I can't think of anywhere where a path is printed in the form /path/to/somewhere. If you didn't know beforehand, then from in everyday use you probably wouldn't be able to discern that the path separator was a forward slash "/". (Update: The Finder info window displays the path using a colon ":" as the separator, which previous Mac OS's used). When the path in to a file is displayed in Finder arrow graphics are used to represent the path and each folder has a proxy icon. I think this is a Good Thing. Gnome's HIG has a section which recommends providing direct manipulation and OS X's HIG infers this with its entire section on drag and drop (compared to the tiny section in Gnome's HIG mentioning drag and drop, which is pale in comparison). The proxy icons are a fantastic way of doing this, the icon is (at least an intermediate to) the document and allows direct manipulation.

All of that was a rather long winded way of saying that I've been toying with the idea of a little proxy file widget using PyGTK. The idea would be to use this instead of the normal /path/to/whereever/ text. I've made a little prototype which is shown below. Currently the code just shows the pop-up, the file is made up. Unlike the widget in Nautilus it's not a button as it's meant to actually represent the file. I'm not sure whether it's taking it too far by adding drag and drop or just to leave it popping up the path menu when clicked. One solution around this wouldd be to use a modifier key or the right mouse button for one or the other, but one thing I've learnt is that this is a complete cop-out solution—hiding functionality in a non-obvious way (which context menus actively encourage).

As I said at the beginning of this rant, I'm not very experienced at HCI design, I have no formal education in the subject, and while my widget may look pretty it could very well be crap from a HCI perspective.

0 Comments:

Post a Comment

<< Home