I love this iPhone app. What a great example of thinking outside the box and coming up with a really functional UI! The video demo is very compelling. But after using the app for a few weeks, I’ve gained an even greater appreciation for the application.
http://danbricklin.com/log/2009_12_05.htm#notetaker
http://www.softwaregarden.com/products/notetaker/
http://www.boston.com/business/technology/innoeco/2009/12/dan_bricklin_from_killer_app_t.html
What a great design!
Here’s an interesting thought about how movies portray technology incorrectly:
http://www.useit.com/alertbox/film-ui-bloopers.html
What? Hollywood got it wrong?!? What!?!
“A well balanced user interface … doesn’t cater to the beginner or to the expert, but rather devotes the bulk of its effort to satisfying the perpetual intermediate. At the same time, it avoids offending either of its smaller constituencies, recognizing that they are both vital.”
– Alan Cooper & Robert Reimann, About Face 2.0
Has developer productivity improved in the last ten years? We have much better tools now than we did ten years ago. We understand more about development processes, methodologies, and even developer psyche. But do we get more done?
In 2007, Joe Developer can drag a widget onto a canvas in his whiz bang IDE and in the blink of an eye one thousand lines of code are generated. He must be more productive than he was in 1997, right? I don’t know. I’m not so sure that Joe actually delivers more functionality.
Tools may have increased in power, but expectations have increased as well. Users expect more from their applications. A web application with rudimentary forms to submit data just doesn’t pass muster anymore. As user interfaces become more fancified (that’s the technical term), user expectations change and I wonder if potential productivity improvements are lost. I wonder if development tools are making gains in the wrong places. And when I say “the wrong places,” I really mean “not in the area of productivity”. In other words, rather than giving us tools to more quickly get things done, we get more layers, more options, more features, more…stuff. I don’t actually think that better interfaces are a bad thing. But sometimes it seems that tool vendors are focused on delivering more eye candy and are not helping us deliver better, more solid code in a shorter time.
In 2007, we are doing a lot of great stuff. I’m just not sure we’re any better at dealing with the fundamental complexity involved in building software.
I have been reading Object-Oriented Design by Peter Coad and Edward Yourdon. I was surprised to find a chapter about “Designing the Human Interaction Component”—surprised because user interface design and OO design aren’t usually covered in the same contexts. Anyway, some good criteria are given for good UI design:
Consistency. Use consistent terms, consistent steps, and consistent actions.
Few steps. … Minimize the time needed to get meaningful results…
No “dead air”. … meaningful, timely feedback is a must.
Closure. Use small steps, leading to a well-defined action.
Undo. Humans make mistakes. And humans are used to undoing—at least some of them…
No memory In “human RAM”. … Program the computer, not the person. …
Time and effort to learn. Keep it short. …
Pleasure and appeal (look and feel). Humans use software that is fun to use. Humans will tolerate other software, but only if and while they must.
- From page 63 of Object-Oriented Design by Coad and Yourdon.
A good friend of mine pointed out this amazing presentation to me:
http://www.ted.com/index.php/talks/view/id/92
It makes static graphs and charts seem old and stale, doesn’t it?
“When good tools support creative activities, the activities can induce a state of ‘flow’ in the user. This is a state of full absorption in the activity, during which time distorts, other distractions fall away, and the person can remain engaged for hours—the enjoyment of the activity is its own reward. Artists, athletes, and programmers all know this state.” (page 14)
I recently finished reading Jenifer Tidwell’s excellent book: Designing Interfaces: Patterns for Effective Interaction Design. I think this is the first user interface book I’ve read that uses the concept of patterns to describe principles of user interface and human computer interaction.
The first chapter of the book deals with human behavior, or patterns of what users do. I found that chapter particularly interesting. They are as follows:
“Safe Exploration: ‘Let me explore without getting lost or getting into trouble.’
Instant Gratification: ‘I want to accomplish something now, not later.’
Satisficing: ‘This is good enough. I don’t want to spend more time learning to do it better.’
Changes in Midstream: ‘I changed my mind about what I was doing.’
Deferred Choices: ‘I don’t want to answer that now; just let me finish!’
Incremental Construction: ‘Let me change this. That doesn’t look right; let me change it again. That’s better.’
Habituation: ‘That gesture works everywhere else; why doesn’t it work here, too?’
Spatial Memory: ‘I swear that button was here a minute ago. Where did it go?’
Prospective Memory: ‘I’m putting this here to remind myself to deal with it later.’
Streamlined Repetition: ‘I have to repeat this how many times?’
Keyboard Only: ‘Please don’t make me use the mouse.’
Other People’s Advice: ‘What did everyone else say about this?’”
The rest of the book is user interface patterns. There is a lot of good advice in the book, and it is well illustrated. Some of it seems pretty obvious, but nonetheless it can be helpful having it in this well organized format.
I have just finished reading Don’t Make Me Think: A Common Sense Approach to Web Usability by Steve Krug. Here are some quotes from the book:
“‘Don’t make me think!’ I’ve been telling people for years that this is my first law of usability. And the more Web pages I look at, the more convinced I became. It’s the overriding principle—the ultimate tie breaker when deciding whether something works or doesn’t in a Web design.” (page 11)
“Faced with the fact that your users are whizzing by, there are five important things you can do to make sure they see—and understand—as much of your site as possible:
- Create a clear visual hierarchy on each page
- Take advantage of conventions
- Break pages up into clearly defined areas
- Make it obvious what’s clickable
- Minimize noise.” (page 31)
“I’ve come to think that what really counts is not the number of clicks it takes me to get to what I want (although there are limits), but rather how hard each click is—the amount of thought required, and the amount of uncertainty about whether I’m making the right choice.” (page 41)
“Get rid of half the words on each page, then get rid of half of what’s left. –Krug’s Third Law of Usability” (page 45)
“The problem is there are no simple ‘right’ answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed and tested.” (page 128)
“Where debates about what people like waste time and drain the team’s energy, testing tends to defuse arguments and break impasses by moving the discussion away from the realm of what’s right or wrong and into the realm of what works or doesn’t work.” (page 129)
There’s a lot of really simple, but helpful advice in this book. I’d highly recommend it to anyone involved in building web sites.
“For most of us, it doesn’t matter to us whether we understand how things work, as long as we can use them. It’s not for lack of intelligence, but for lack of caring. In the great scheme of things, it’s just not important to us. Web developers often have a particularly hard time understanding—or even believing—that people might feel this way, since they themselves are usually keenly interested in how things work.”
- Steve Krug in Don’t Make Me Think, (page 28)
My wife has been telling me for a while that other people are not like me. I think she’s right. And I now believe that most people don’t really want to figure out how things work. But as is so well expressed in the above quote, I don’t understand why. It is much easier to figure out how software works than to figure out how people work.