President Barack Obama, and two other presidents, have retaken their oaths of office, because of some mistake with their inauguration. That means a little over one in fifteen presidential oaths were botched. If that sounds high, it is. But only because people make mistakes.
That’s why, we must make our software so that people can recover after making a mistake.
In 1987, Alan kay said,
By the way, Sketchpad was the first system where it was discovered that the light pen was a very bad input device. The blood runs out of your hand in about 20 seconds, and leaves it numb. And in spite of that it’s been re-invented at least 90 times in the last 25 years.
Almost 50 years after Sketchpad, you can find a light pen at any computer store today. Today, these light pens are used to supplement more circulation-friendly input devices. Maybe that’s enough to solve the problems Sketchpad had.
Personally, I think the metaphor of a the pen is too blindingly strong. People love their pens, because they grew up with them. I don’t accept that they are the pinnacle of input. We can do better then copying a pointy stick filled with dye.
But I have my own biases and unique experiences. I am dysgraphic — I have trouble writing legibly by hand, and spelling. To me a pen is not something that feels good or puts me in the zone. It’s something that gets in the way of expressing my ideas. But fundamentally, isn’t every input device a barrier between your mind and the medium?
There’s a great comment thread on designing credit-card readers to be more obvious, over at uiandus.com.
And this one, from Chris Clark, sounded the most cost-effective and simple to me,
An idea: put the scanning mechanism into the main body of the machine (in this case, the left) and give the inactive side of the swiping channel a very low profile.
The channel should be deep enough that your card doesn’t spill out during a swipe, but shallow enough that you can see that the magnetic strip won’t be touching anything if you slide your card with the strip facing ‘out.’
If people work with the assumption that the magnetic strip must touch something to work, this design removes the perceived affordance of the ‘wrong’ side.
You could get the same effect by using clear plastic on just the “short” side. But I prefer Chris’ concept, because clear plastic will get dirty, scratched, and opaque, but empty space will stay empty.
There are lots of great comments, and I don’t know enough about building these things to know which plan would give the most bang for the buck in reality. So if this problem interests you read the blog and pick a winner for yourself.
(UPDATED 2009-02-12: I wanted to clarify why I’m ignoring the most obvious and right answer, of having a sensor in each side of the machine, so there wouldn’t be a wrong way to swipe the card. My understanding is that doing that would be too costly. If that isn’t the case, then I’m deeply disappointed in every credit-card reader I’ve used, and the cheap bastards who opted to save a few bucks to inconvenience all their customers.)
An Asian student in my laboratory was working on an application to visualize changes in computer software. She chose to represent deleted entities with the color green and new entities with red. I suggested to her that red is normally used for a warning, while green symbolizes renewal, so perhaps the reverse coding would be more appropriate. She protested, explaining that green symbolizes death in China, while red symbolizes luck and good fortune. The use of color codes to indicate meaning is highly culture-specific.
—Information Visualization, Second Edition: Perception for Design, page 16 (via Keith Lang)
I hypothesize that color-codings derived from nature and physics (for example more and less mapping to hotter and colder colors) would work across cultural divides. But maybe that’s just the science-worshiping American in me talking.
UPDATED 2009-02-02: There’s some very good commentary on this post. My hypothesis was wrong, or at very least missed the real difficulty of color coding. Also, it now appears the anecdote was not real culture shock, but a smart student defending their design with the first thing they could think of when it was suddenly challenged.
Adobe UI Gripes is a blog with screenshots of Adobe’s weird, non-standard interfaces. (Too much of) Adobe’s current Mac software is like Microsoft’s during the Word 6 period.
(Via Michael Tsai, Jonathan Rentzsch.)
If Adobe didn’t make, you know Photoshop etc. al., I would cut them more slack when it comes to their software’s face. It’s like a dermatologist with terrible acne. Graphic designers seem like exactly the types who would be bothered the most by a tool’s interface not being pixel perfect.
But I am impressed by what I’ve seen of Adobe Lightroom. They deserve UI props for that.
I highly recommend Bruce Schneier’s blog. Security involves thinking about what how things can go wrong, and that’s an excellent skill for any designer to have. Psychologically people are biased to remember catastrophically bad experiences, and can develop an adversarial relationship to something from just one bad experience, if it’s unpleasant enough. Minimizing unpleasantness can be more important then optimizing goodness, when trying to cultivate a good relationship with users.
Submit is always the wrong title for a button. Yet it’s still commonly used, even by people who should know better. I had “Submit Comment” buttons on my blog when I first published this.
Buttons should say what happens when they are pushed, in the vocabulary of the person pressing them. Technically a button might submit a form to a server, but what matters is the consequence of submitting the form.
For example,
this button should be called “Search” or “Find” or “See Matches” — something that describes what happens when it is pressed, or what the operator will see after pressing it.
“Submit” has negative connotations, and should be avoided. The first three example usages (in Mac OS X’s Dictionary.app) are all negative,
submit
verb
1 [ intrans. ] accept or yield to a superior force or to the authority or will of another person : the original settlers were forced to submit to Bulgarian rule.• ( submit oneself) consent to undergo a certain treatment : he submitted himself to a body search.
• [ trans. ] subject to a particular process, treatment, or condition : samples submitted to low pressure.
Say an apartment takes applications on their website. It would be pedantically correct to say “Submit Application”. But it is more respectful to say “Send Application”, or “Apply”. Pressing a “Submit” button implicitly says “I submit”. And that’s the wrong relationship for a user to have to an interface.
One reason so many buttons are labeled “Submit” is that the HTML code for making a button has the word “submit” in it. The code for is <input type="submit" value="This Button">.
If the keyword send was used to build buttons, I would argue that the web would be a slightly less intimidating place today. A button that demands you “send” something is better then a button that forces you to “submit”.
So perhaps, when choosing programming terms, we should pick the ones with the fewest negative connotations, since inevitably some of those words will bleed over into user-land. Even if programmer words stay in programmer-land, word-choice influences the way we think about things. Best not to encourage berating your users and customers.
Of course, you shouldn’t go overboard avoiding “ungood” words! There is no question that the most clear term should be used (even if it’s offensive). A better programming-vocabulary means better, less buggy, programs. And that’s better for users (no matter what they are called behind their back). But if possible, avoid disparaging words.
And never submit to the temptation of calling a button “Submit”. There’s always a more accurate, respectful name.
Alan Kay talking about GRaIL, Graphical Input Language, a system implemented in the late ’60s that was so far ahead of it’s time, it’s still pretty impressive today.
“I felt like I was sticking my hands right through the display and actually touching the information structures directly.”
I had no idea this sort of interface was done so early.
Every six seconds of improvement in speed of service amounts to typically a 1% increase in sales. And it has a dramatic impact on the bottom line.
–John Ludutsky, President of Phase Research, quoted on the “Fast Food Tech” episode of Modern Marvels, aired 2007-12-29 on the History Channel.
I wouldn’t expect things to be much different in the software world. The faster you get your burger bits the better.
UPDATED: 2009-02-05:
Apparently people want service much faster from software. Greg Linden reports,
Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
This conclusion may be surprising — people notice a half second delay? — but we had a similar experience at Amazon.com. In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
If the Mr Ludutsky’s figure is accurate, a 20% drop in fast-food revenue would require a two minute delay. Does this mean every second spent waiting on a computer is as bad as waiting 4 minutes in meatspace? I don’t know — I’m doing a lot of extrapolation from hearsay. But it’s something to consider.
Powered by WordPress
