I’ve been using the Kindle app on my iPad to read How We Decide.
Like most apps, it’s easy to use without any instruction, which makes good sense, since a physical book doesn’t require instructions.
After using it for a while, I figured out how the gestures work. Tap the margins or swipe up/down to page forward and back, tap the text to pop the menu functions. Long tap a word to select it and pop its definition.
I suppose this is documented somewhere, but like most things, I didn’t read the documentation.
The cool thing is that when I figured out the gestures, I got a little buzz. My brain felt happy with itself. This is missing from documentation, since reading about how to use something isn’t as fun as actually using it.
Unfortunately, you have to provide some how-to content for your software, especially if you’re selling it.
People sometimes ask about documentation for Connect, and I used to think this was a failing with the interface, i.e. it wasn’t easy enough to walk up and use.
That may be the case, but I’ve come to believe that when people ask for general documentation (vs. specific how-to), they haven’t used Connect at all.
This indicates to me that: a) Connect doesn’t have an obvious purpose and b) these people don’t really want to use it.
So, it really doesn’t matter how good the documentation is because these folks are already looking for reasons to bail.
This is a circus of fail when you look at it because it means that Connect isn’t compelling or obviously useful, which ensures that it won’t get far with those with negative preconceptions.
Social networks have always suffered from these problems because they are only compelling as people use them.
Anyway, maybe a design principle to aim for is something like “walk up and, oh yeah”, instead of walk up and use.
Thoughts?
Actually there’s a 150 page manual for the iPad which lists out the gestures towards the end, see http://www.multilingualblog.com/?p=938. Bear in mind, the irony of listing these under an accessibility section if you suffer from a motor disability. And as for the cognitive load in remembering all these… ah, but that’s another project for me. Dunno about the Kindle app itself.But to respond to your point, I agree. There’s a lot of evidence out there that the real user assistance needs are for people already in the app – the affirmation and confirmation model – rather than the old step 1, 2, 3, 4 stuff: http://blogs.oracle.com/userassistance/2010/09/what_do_users_want_from_user_assistance_affirmation_and_confirmation.html The real issue is how or why users get to the app and start using it in the first place (other than being ordered to, like say a corporate travel website, ahem). No amount of documentation will persuade them to keep using something that’s not of value unless they’re forced to.
Well, documentation is required for legal purposes, but that doesn’t mean it matters or is any good. For the most part, I don’t read documentation.
The top-down model that persists within companies will always ruin good models from the consumer space bc it is inherently upside down, i.e. being required to use something creates a much difference experience. The viral model that E 2.0 has insisted will change the enterprise doesn’t hold water either bc power structures are in place to disrupt disruption.
That is somewhat of a generalization as far as doc is concerned, though I agree much of this is political. If you want an example of what IS possible, then just look at what Adobe have done in the community help space. Incredible. They harnessed the whole collective intelligence as assistance and curated it.
Thanks, I’ve heard Adobe does a good job.
The problem with packaged documentation is that the PMs who designed the software don’t necessarily want to document how to use it, and they’re totally biased, which creates biased doc.
Doc must follow expected use patterns, which causes frustration if the user is doing something different.
Anyway, it’s all moot if your user doesn’t really want to use your product, which is often the case in enterprises.
since a physical book doesn’t require instructions.
When your kid hits about 3rd grade you’ll discover you’ve simply forgotten you’ve been given instructions, as they start asking you about all the parts of the book they need to know for school, even though you taught them to read several years before. There’s quite a bit implicit in teaching to read.
Obviously wasn’t talking about reading 🙂 A book is intuitive. That’s what I meant.
And what I’m saying is, intuitive isn’t.
I rode motorcycles for many years. Most modern motorcycles have clutch and brake levers in standard places on the handlebars. With practice, you don’t even think about it – riding a different moto, you learn real fast how not to stall it out when starting. Small four-wheeler ATVs are the same. (ignoring bikes and atv’s with automatic transmissions or only one speed, of course)
Except.
I had one that had the clutch built into the foot gearshift, and two brake levers on the handlebars. Switching between that and a more usual one was amazingly difficult. Intuition out the window every time, if there were windows on motorcycles.
Try reading a book that has a right-to-left language interleaved with English translations sometime. Some people have no problem. Others continue to turn to the wrong page.
I’m not buying the comparison between operating a motor vehicle and reading a book. Even despite the left-right bias, someone could figure out the right-left aspect, and if not, forget intuition bc most likely s/he doesn’t speak that language.
Intuitive design doesn’t need to be learned. You learned how to operate a motorcycle. You didn’t walk up and ride. You don’t learn how to use a book. Even people who can’t read can “operate” a book.