The New Interface Advocate

Error dialogs seem to rarely best their progenitors from decades ago. In fact, often the modern counterparts are worse—either they offer misleading oversimplifications or they are little more than graphical wrappers for some obscure error code optionally coupled with some half-baked developers’ notes. Obviously, redesigning error dialogs won’t automatically fix this problem, but other oversights couple therewith to plague the user experience with something goes awry.

First, cramming all the information into one paragraph tends to encourage content blindness. I have mindlessly clicked on dialogs without reading them simply because what information they might have held looked like too much work to parse, and I’m unusually cautions about clicking. The first change, then, is to separate the information:

• The top section contains a simple—but, critically, still accurate—explanation of the error that occurred.
• The middle contains details about exactly what caused the error, generally in greater technical detail than the top.
• The bottom section suggests solutions for the error.  If there are none, explain why, if solutions are known, list them, and if there isn’t enough information to tell, admit that.  Developers nearly always have access to a wealth of information about why things go wrong, so the last case needn’t happen often.

The most significant change is in the bottom section of the box. For solutions that can be handled automatically (such as converting formats, changing settings, loading a file, etc.), their explanations are marked as clickable, which then performs their respective suggestions.

A quick mock-up to demonstrate the design follows:

I’ve pulled together some drafts of my ideas for the design of the timeline portion of the Lumiera non-linear video editor (hopefully, the successor to Cinelerra).

The annotated version (explaining some of the finer points):

The un-annotated version (to show the sketch better):

Edit: I’ve updated this intro after discovering that I somehow replaced it with some unrevised notes from my initial outline. Oops.

I was reading an argument that progressive find is the best (and only proper) search design, I think in the comments of this article. I got to thinking about what makes progressive, and occasionally modal, search optimal for certain tasks. Each has distinct advantages. Progressive find is rapid, it provides instant indication of most typos, it completes upon minimum unique string, and it can show near matches on failure (specifically, longest common initial sequence).
Modal find, however, is less disorienting, and a failed search doesn’t leave user in at some random location within the document.

I’ve noticed other issues, too. In a misguided attempt to minimize disorienting motion, most software scrolls text only exactly far enough to expose the next match for the search term. This means that except when it is already visible, exactly half the context of the search term–either everything above or everything below—ends up hidden by the edge of the viewport. Additionally, many programs depend on awkward non-central keyboard keys for searching, including the totally arbitrary F3 key. This is a pain for anyone using a laptop with shrunk-and-shifted function keys, a Datahand, or a Happy Hacker (I currently use two of those three).

With all of this in mind, I thought of what sort of search design would marry all the advantages of both designs as well as fixing my big annoyances (half-context results).

Continue Reading »

Let’s see who can guess the two designs I’m referring to. Here’s a hint: they’re more psychological than technical—and if you say anything involving the words “GUI,” “CLI,” “mouse,” or “wizard,” you’re way off track.

The two designs are (drum roll)…

Continue Reading »

Since I said the mouse needed to be seriously re-examined as the primary device for interacting with the user-interface (see my previous entry), it’s only fair that I give an example of a better way to do it. In this entry I explore one possible way to minimally change the interface to almost remove the mouse entirely, without increasing the difficulty of learning how to use software.

Continue Reading »

Now, I am by no means hoping to abolish the mouse. Its price to performance ratio is unmatched, and the best alternative pointing device (the tablet) can’t be found for much less than an order of magnitude greater expense: hard to justify for the relatively small performance edge it offers. What I do wish to decry is the enormous reliance on the mouse to cover every possible user interface situation, failing to take advantage of other, better designs. Years of lazy design and low opinions of the user’s desire (even ability) to learn have left us with a constant testing of Fitts’ Law for such trivial tasks as saving, broken paradigms (what about a real-world button relates to replacing an old document irrevocably with the current one?), and a user experience that is more patronizing than productive.

Continue Reading »

Celebrating the release of Openbox 3.4, I’ve published my mouseless window management design. Of course, if you use firefox, OO.o, or the like, you’ll have to reach for the rat–that’s not my fault, though. :-D

(For those of you reading backward in time from my more recent entries calling for a more keyboard-centric user-interface, this is only one of numerous possible ways to manage window size/placement without a mouse, and not a particularly good one. It’s just what I’ve been using for a while and have gotten used to. Most problematically, it requires significant training to use.)

Continue Reading »

While Fitts’ Law has been studied extensively with mice, I recently came across an interesting whitepaper comparing mice, trackballs, and (my weapon of choice) tablets.

Continue Reading »