There have long been two largely competing camps when in the user interface design space: document-centric, and task-centric.
There have long been two largely competing camps when in the user interface design space:
- Those who believe everything should be document-centric
- Those who believe everything should be task-centric
In reality, neither is correct, and there’s a large crossover between the two. When your primary role is dealing with office documents and you spend all of your time word processing or spreadsheeting, the document and the task are mostly one and the same. The only divisive issue is whether you should employ some kind of MDI and, if you’re on Windows and work for Microsoft, what the “Close” button on a Window should do.
Tabbed interfaces put the cat amongst the pigeons for a while. Initially, everybody rushed to slap tabbed interfaces on just about everything, appropriate or not. Fortunately, that trend has reversed somewhat and things are a little more sensible. The rules for “when to provide tabs” boil down to:
- If the user is likely to want to focus on one particular document;
- and will want to switch rapidly between documents;
- and is significantly more likely to want to do that than to have documents side-by-side
…then tabs are your answer. Web browsers: people switch between different pages on a regular basis, but don’t need to see two side-by-side all that often (and when they do, a tab can be promoted to a separate window easily enough). Same with many programmer’s editors (although TextMate’s approach of one-window-per-project with tabs for files within that project works well as a context-focussing device for me).
There’s a third class of application which isn’t catered for all that well, though: applications primarily concerned with the collation and simultaneous presentation of information from a variety of sources. We see it a lot in web applications, where you have some kind of “dashboard” which can host a multitude of widgets and feeds. The paradigm is useful, because if you’re primarily concerned with monitoring information, rather than producing it, it’s rare that you’ll be monitoring a single kind of information from a single source. We don’t see this much in desktop applications, though, because concocting a sufficiently flexible user interface for this that doesn’t jar horribly with existing conventions is hard: one oft-cited reason for why the Bloomberg Terminal’s interface looks somewhat unfriendly and unintuitive is the sheer amount of information which can be presented at once. How would you present Wordpress’s or Google Analytics’s dashboards in a desktop application?
One approach the same as that employed by iGoogle or Netvibes, and other similar services: you (the user) stick widgets on a canvas, and they sort of get arranged in something resembling a workable fashion, and you can drag and drop to re-arrange them. The problem with this approach is that you’re pretty much throwing any pre-existing UI guidelines out of the window: you’re effectively implementing a form of MDI, though one which is usually less free-form than those in days of yore. Because multiple-windows-in-a-parent MDI has fallen out of favour, most guidelines nowadays say little more than “don’t do that”, and they certainly don’t endorse rolling your own child window chrome and behaviours.
I’ve been toying with the idea of implementing a skeleton application for this, and so my mind turned to the user interface. My idea is of an extensible application which doesn’t do a lot on its own except provide a “workspace” for information sources: plug-ins would provide and present the actual information, in much the same way that widgets perform the same on iGoogle or the Mac OS X Dashboard. I want consistency, though. I don’t want this as-yet-unnamed application to look like the ugly stepsister compared to the other applications on my desktop; I don’t want a freeform canvas akin to the Mac OS X Dashboard, because I’d likely spend all of my time re-arranging the widgets (or whatever they may be called) to make the best use of available space. The application should do that for me.
The next logical step, therefore, is one of tiled panels. We see this a lot already: we have sidebars, status bars, toolbars. We don’t see the middle-ground a lot, though, where the host application is flexible enough to allow a arbitrary “widgets”, but strives for UI consistency and seamlessly tiles and arranges those widgets.
I’ve yet to figure out how this should actually work though: the closest I’ve come is something similar to the HTML table-sizing model, where a grid of sorts is created, but the grid isn’t evenly-spaced. If you put two widgets side-by-side, they’ll snap to each other, and you’ll effectively create two columns (based upon the width of those two widgets—which you should be able to alter). If you then place a widget below one of those two, it will take on the width of the widget directly above it. I could see a situation where it’d be advantageous to allow widgets to span rows or columns, though—perhaps that could be accomplished by dragging and edge with a modifier key held down (option+drag causes just that widget to be resized, rather than the whole row/column, and it snaps to the nearest boundary if one already exists, or creates one where it’s dropped if not).
Implementing that would be hard, though.