Clay Barnes talks about HCI, the user experience, and whatever he’s in the mood for.
Vending machines provide an excellent and disappointingly universal study in overly complex interfaces. This brief post reflects on how the current designs are flawed, speculates on the forces behind the bad designs, and proposes a new design that overcomes current problems though an ultra-minimal interface.
I was in one of Roger Grice’s HCI courses here at RPI last week, and he showed us the “interface of the day,” which was an online simulation of an Etch A Sketch (Etch A Sketch is a trademark of the Ohio Art Company). His point was about the faithfulness it had to the classic Etch A Sketch experience despite being merely a flash application, but I think the original itself is more interesting.
When I have asked acquaintances to think back to when they last used an Etch A Sketch, no on yet has relayed feelings of limitation and frustration with the toy. However, most interface designers would offer a list of violated principles of usability were they shown the design of an Etch A Sketch without having ever seen it before.
The controls are unintuitive; each knob controls an independent axis of movement, but why should the rotation of one move the drawing point up while an identical manipulation of the other moves it right? Even after convincing oneself that the knobs’ respective domains of motion correspond to a particular pair of rotations, the system seems to fight every attempt at controlled, planned movement. Diagonals necessitate careful consideration before starting lest an all-too-easy direction error send the little line veering off in the wrong direction, and curves? Rare indeed are those who can draw so much as a circle, let alone handle the subtlety of anything harder. Practice with an Etch A Sketch seems to yield meager advance in skill at best, despite hours hunched over that little red-framed gray canvas. As a consequence, “art” made on the Etch a Sketch is invariably of amateurish—almost infantile—quality. Yet, it has enjoyed wild popularity and still entertains countless consumers every year. How can an interface so obviously and pervasively flawed accomplish this feat?
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.
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):
Frank Terbeck wrote a patch for cmus that adds support for Audioscrobbler/Last.fm. He doesn’t use/maintain it any more, and was kind enough to allow me to take it over for him. I’ve updated it to reflect the current changes to the cmus codebase. I plan to take some time this summer to get it ready for mainline cmus inclusion. Until then, it’s just a patchset.
Download link and useage after the jump.
I’ve had several requests for my “Regular Expressions Quick-Reference/Comparison Chart,” so I’m posting it here. At the moment, it covers the vim-, BRE- (used by ed, sed, and grep), ERE- (used by egrep, and sed -r), and perl- (used by perl (naturally!) and most copies of rename) flavors at the moment. This is still quite a work in progress—I’m considering adding another column (perhaps ruby?), and I’m sure there are at least one or two typos that I’ve let slip through. Please tell me if you find any errors at all, either through comment here or by email.
(The requisite preview thumbnail—click to see the 150dpi PNG version.)
After the jump, I’ve attached PDF, postscript, and closely-cropped PNG (150- and 300dpi) versions. I’ve also included my LaTeX source file. Enjoy!
The first release is current, last revised on 2008-04-23. (I will update this line as versions are released.)
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).
So, as proof that I still exist, I’m posting some scripts that I’ve used as of late. I’m sure they’re simplistic, flawed, and trivial to replicate. However, they’re what I needed, so I assume there are other people out there who could use them, too.
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)…
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.
All works on this site are licensed under the Creative Commons Attribution-ShareAlike 3.0 License.
By posting material you also grant these rights.