Author’s Note: This entry is copied from an old (2008) post I made on Livejournal but never opened to general visitors. I think it’s still relevant as my computer hasn’t changed since I wrote it. ;-) Here on my public blog I hope it will get the traffic I robbed it of when I posted it as a restricted-to-friends entry on a private account.
(Update: The source is available for download at bottom of the entry.)
I must admit I always felt a little uncomfortable generating or referencing histograms. The enormous bias that might be introduced by changing the segment/bin size always nags in the back of my mind. True, thoughtfully constructed histograms with a fairly large sample set can be very illuminating, but the reader must trust the visualization architect completely or rebuild the graph from source data and verify that the parameters were well-chosen.
For those who have the same concerns will I outline a set of visualization techniques that are less susceptible to accidental/intentional bias. These visualizations are simple to implement, very spatially compact, easy to understand, and applicable to not only value distributions within a set but also representing clustering of events in time.
Enough talk, take a look at an example visualization:
Continue on for for an explanation and all the details…
As with most Apple products, the iPad is built from some of the best hardware widely available (depending on your criteria) and has been advertised exceptionally well. In spite of the deluge of predictions that it would change “everything,” there seems to be comparatively little deep effect on the tech industry. It feels more like a novelty—something to carry around in addition to ones usual load but not replacing anything. It could theoretically do so much, so why do people seem to select the “lesser” tools, even when an iPad is available?
I recently discovered the central flaw for my experiences with the iPad, which I believe also shapes many other users’ “enjoyable indifference” (for lack of a better description) to the iPad as a general tool.
Web browsers—despite their diversity of histories, intents, and development paradigms—largely mirror each other’s user interfaces with traditional drop-down menus (a.k.a “File” menus), either in the standard place or under a top/right corner button, an address/search bar just right of the main navigation button cluster, tabs either above or below it, and the view area below it. Aside from adding tabs and hiding the menu bar under a button, very little about the user interface has changed in well over a decade of web browsers, and that is unfortunate. Considering the enormous expansion of the web browser’s duties (desktop apps are starting to be replaced by online alternatives) and the time an average person uses them, filtering this experience through an architecture from fifteen years ago seems anachronistic.
Well, thanks to increasingly extensible and sophisticated browser core technologies, this situation can be easily remedied! I’ve developed a different user interface to complement my preferred hardware setup (both my work and home systems use tablet pointing devices instead of mice) and make controlling the browser less consciously involved. It’s built on open-source and freely extensible software, so in that spirit I am publishing everything needed to replicate (and, hopefully understand/enjoy) my setup here.
I’ve fixed some minor errors and expanded the languages covered by my RegEx quick reference chart originally posted here:
RegEx Reference Chart v1.0.
This new version is available in several formats (listed below). Just like the last, it is provided under the Creative Commons Attribution-Share Alike 3.0 License.
- PDF: Regular Expressions Quick-Reference/Comparison Chart, v2.0 (PDF)
- Postscript: Regular Expressions Quick-Reference/Comparison Chart, v2.0 (Postscript)
- DVI: Regular Expressions Quick-Reference/Comparison Chart, v2.0 (DVI)
- LaTeX source: Regular Expressions Quick-Reference/Comparison Chart, v2.0 (LaTeX source)
Corrections, suggestions, and general thoughts are always welcome—even a one-line replies to let me know this was useful.
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.