More than 90% of people don’t know about CTRL- or CMD- F… http://t.co/wDhRUVa4IF
— Neil Williams (@neillyneil) December 2, 2013
My first computer came with a big solid manual. In fact it came with two, one for MS-DOS, the operating system, and one for BASIC. The first – and for a long time only – software package I had to run on it was Word Perfect, which came with another hefty manual. 
All three were ring binders, and together they took up a good stretch of scarce book shelf space. The ring binders went first. Then the paper got thinner, the covers floppier, and gradually the volumes got slimmer. They stopped attempting to be comprehensive and then stopped being printed altogether. Probably nobody much read them when they were there to be read. Now it’s probably more efficient to google the answer anyway, but that requires you to know the question to which you want an answer. But “I didn’t knew it could do that…” is not a question, it is the result of discovery, not a prompt for it. I wrote the last few paragraphs on a Nexus 7. A few weeks ago, it updated itself to the latest version of android. The font on the clock has changed. Some icons which used to turn blue now don’t. As for anything less obvious, I have no idea, and Google has not made the slightest attempt to tell me. But I have come across an article that tells me that some rather useful functionality which had been added in the previous release has now been removed again. Had I known it was there I would have been irritated at the loss of it. But as I didn’t know it was there in the first place, I am not in practice any worse off. Perhaps that’s because nobody takes any notice, even if they are told. One of the commenters on Charles Arthur’s article which prompted all this argued strongly that they – we – don’t:
I think that people’s unwillingness to take even a few minutes to learn some simple techniques shows how this won’t change time soon. Windows 8 shows people key functionality when first installed for example, but I’ve seen users simple click through it all without taking the slightest bit of notice. 2 minutes increased could have made their X years experience with the product much less stressful. Similarly, I released an App early this year that had a 30 second tutorial showing how best to navigate it and useful techniques to maximise your experience. 70% of the support requests and negative reviews are asking for things that are clearly included this tutorial (and honestly, it’s reasonably well done and very straightforward)!
Meanwhile, as I was starting to write this, Aral Balkan was setting up a new app with learning baked in to the design – though of course that doesn’t guarantee that the process is effective:
Love how Boxer uses an explicit control (the ‘Learn how’ button) to lead the user through the initial tutorial… pic.twitter.com/40O5vkeZm7
— Aral Balkan (@aral) December 8, 2013
I am frequently surprised how many people who spend their working lives working in Windows don’t know some very basic keyboard shortcuts, including ones I use many times a day. But smug though that lets me feel, I have no idea how much time I waste by not employing some equally basic shortcuts which I just don’t happen to know about. In the interest of research, I have just confirmed that it takes only a few seconds to find the definitive list (which is something I have never bothered to do before). And even if you do trouble to look, the resulting experience is not always a rich and rewarding one:
ALT+- (ALT+hyphen): Displays the Multiple Document Interface (MDI) child window’s System menu (from the MDI child window’s System menu, you can restore, move, resize, minimize, maximize, or close the child window)
If that makes immediate sense to you, you’re probably a power user so extreme that you are operating through telepathy rather than anything as mundane as a keyboard.
In an ideal world, you would get useful suggestions, related to the thing you were trying to do, that helped you do it but otherwise kept out of your way. That is, of course, what Microsoft tried to provide through what rapidly became the most derided and unpopular feature in Office, the ever helpful and ever irritating Clippy the paperclip.
Clippy is long gone, but serves to show just how much harder this is than it first appears. There are now many more subtle and less intrusive ways of providing help related to what a user is trying to do, but they still have two intrinsic weaknesses. They usually depend on the user recognising that they need help. And they invariably can’t help the user do something they don’t know can be done.
So that leaves us with two challenges. The first is the one which Neil started this post with: if better understanding of fairly basic tools could reduce frustration and improve efficiency, there would be great value in helping people move further along the spectrum from newbie to power user. Or to put it a different way, how do we introduce continuous improvement into the way we use our tools?
The second is the implications of all this for discontinuous change. If it’s hard enough to help people become more effective users of tools they are already familiar with, how much harder to move them from tools they know to start the learning curve afresh with new tools – which means there is a strong connection between this and the issues of usability and familiarity I wrote about last week.
The world would be a (very slightly) better place if more people knew the power of Ctrl-/Cmd-F. It would be (a great deal) better still if our tools were smart enough to teach us how to use them better.
The post RTFM appeared first on Public Strategist.
Some of the most important things in our lives – how to walk or maintain balance, how to chew food without choking, how to hold in your bowels and bladder, how to love, how to remember, how to raise a child – did not come with manuals, and are far more complex than the banal functions of any digital device or piece of software. So naturally, we balk at the prospect of having to read a manual to do some activity we want to be every bit as fluid in our daily lives as walking is. We got new phones at work, and the operating manual is 64 pages. All I want to do is hear my messages and make/receive the odd phonecall. I have no need for the fancy stuff and making me read through a manual to do even the basics is annoying.
I know we bandy about the term “usability” in design and human factors research. And truthfully, things that are not “user friendly” are often not unusable, but rather simply very burdensome to use. And part of what makes them feel burdensome is the amount of learning that needs to be engaged in prior to becoming usable. Often, that required learning stems from the properties of the device or software being antithetical to what one has already learned to do fluidly. That is, of course, part of the traditional resistance people had to switching over from one computer platform to another. I knew that people who had pledged their allegiance to Apple and MS-Word weren’t idiots, but as a sworn Wordperfect user since V3.0, everything I had learned to do fluidly was called something different, and organized differently, and worked differently than what I had grown accustomed to. Same thing when I got an Android-based tablet: where was everything? The burden of switching over was doubled by having to suppress and unlearn everything I had grown used to and could do every bit as fluidly as I needed to.
Documentation: Some 25 years ago, I attended a talk by world-class text-comprehension authority Walter Kintsch ( http://psych.colorado.edu/~wkintsch/ ), who made some interesting points about software documentation. He noted the perennial complaints people had about software documentation, but said that he had at that time reason to reconsult with some documentation for software he had obtained years earlier, and was surprised to find it was written much better than he remembered. The difficulty was, he said, because the documentation was written from the vantage point of an expert, and not a novice.
Some years later, I found myself teaching a college class of computer science students, and included a module on writing documentation. I noted KIntsch’s observations about the difficulty of tearing oneself away from the expert view and imaging the novice. As an exercise, I brought in a laptop and video projector, and told them we would collaboratively write “documentation” for something we all knew as well as most developers likely knew their own product. One year we wrote documentation for Monopoly and the next year it was Scrabble.
It was 90 sweaty hair-pulling minutes, and the struggle to keep them from racing ahead to the fancy stuff was ongoing. The question I had to keep asking them was “Does a beginner, who knows only the barest amount about board games in general, NEED or want to know that right now, or can it wait a little bit until it makes more sense to them and addresses something they would expect to be facing at that point?”. It was a constant tug of war between what the user didn’t even know they might want to know, and what the developer already knew and was eager to show because it was so darn “kewl”.
I too have felt the primal urge to tell people to RTFM (for the uninformed, the acronym stands for “Read the F-ing Manual!”). But truthfully, if the things the product could do were laid out in the order, and order of difficulty/complexity, that mapped onto what beginning users would want to know, no one would have had to give them those marchng orders, because they would have found it out already. When finding out about technology, one first has to proceed with an expectation that “It should be able to do this, so I wonder how I make it do that?”, and that expectation, in turn, is instigated by coming up to a choice-point where the preferred choice is to make it do this. If you didn’t know how or why that choice might be of value to you, why on earth would you ever bother to find out about it?
I usually expand the acronym to “Read The Fine Manual” with emphasis on *fine* that depends on the usefulness of said manual.
While Ctrl/Option+F are useful for finding items, I’m constantly amazed by the number of people that don’t use the below Fabulous Four:
Ctrl+A [Select All] / Ctrl+C [Copy] / Ctrl+V [Paste] / Ctrl+X [Cut]
Mark
I think there is a lot in what you say – and this post is in many ways a companion piece to one I wrote last week on exactly the issue of familiarity and usability. For some reason, that one didn’t get picked up here on Govloop, but you can read the original on my blog. Being simple may not be the same as being usable, and it is familiarity which often fills the gap. The thought you cite that documentation is written by the wrong people of course reinforces exactly that problem – it’s not just that the experts aren’t the users, but that they may be too unlike them to understand the gap.
So my calling the post ‘RTFM’ is not because I think it’s the right approach. On the contrary, I think it’s a terrible response to a request for help, precisely because manuals are rarely a good way of building explicit knowledge and converting it to tacit knowledge over time.
(and I have taken the liberty of copying your comment to the original post – I would like people who read the post there to see it too)
Thanks, Stefan. Honoured to be cross-linked. A couple of tangential observations:
1) The goals of designers vs users: My question to my class about “What does the beginner want/need to know right now?” applies to many more things than one might think. There is a move on afoot in my government to have a single centralized website for ALL government-provided services. At an abstract level, that seems like a sensible idea. Why leave it up to people to figure out which agency they need to contact for purpose X, particularly when the location of a given service may have changed since the last time they needed to use it, or perhaps the very name of the agency. So, the notion of “single-window” seems eminently sensible.
At the same time, if I go to agency X’s site, then my purposes are already somewhat narrowed down. A single window site has a HUGE search-space to figure out what it is I want/need. So the challenge of designing some sort of hierarchical “sieve” that can anticipate any sort of want/need, from any sort of user, from grumpy senior citizen to cabinet minister’s staffer, to industry rep, to public servant, to news reporter, without requiring the user to either have fore-knowledge, or requiring them to go through a lengthy series of steps before realizing they need to backtrack and begin again, is a pretty serious challenge. Not impossible, but one that will require considerable understanding of the mind-set of the client-base; something that is generally not the strong suit of the good folk in I.T. Plus, it will have to conform to all the accessibility requirements, which will impose limits on some of the tools available to stick more information on any single screen. Personally, I am not hopeful.
2) Manuals/Instructions: I have always been resentful of the entire series of books called “xxxx for Dummies” or “The Complete Idiot’s Guide to xxxxx”. They’ve expanded into many other areas these days, but the first ones were for software. What provokes my ire is that their very titles blame the victim. Someone writes what they believe to be documentation, but is thoroughly confusing and unusable for the novice, eliciting the need for something better written. The documentation user, however, believes the obstacle to learning to be themselves, not hopelessly inadequate and uninstructive documentation written for someone who already knows a great deal about the software. The “Dummies” title implies the learner is the weak link, not the writer. Hey, it’s not MY fault if you’re too stupid to understand this.
One of the classics in the field of human factors is Don Norman’s book “The Design of Everyday Things” (originally published as The Psychology of Everyday Things: http://www.amazon.ca/The-Design-Everyday-Things-Norman/dp/0465067107 ). One of its central theses is the importance of anticipating people’s tacit “maps” of things, where maps can also include the natural sequence with which actions are supposed to occur in. One of the more humorous, yet exasperating, examples in the book concerns the Sydney, AU subway system, recently installed when the book was written. The rider approaching the turnstile entrance would encounter two slots, one placed a little futher back by a few steps than the other. The first slot was for gathering your transfer, and the second slot was for putting your coins in. What? The transit system had to employ guards to stand in front of the turnstiles because people were shoving coins in the transfer slots and jamming them up. The flaw was in not anticipating the natural-sequence map of the user.
The new building our agency moved into last November has two public-access floors, another dozen floors of restricted access, and a high-falutin’ elevator to control that access. Before getting on the elevator, you swipe your ID card, and then enter the floor you wish to go to, at which point it tells you to take elevator A-H. There are only open/close/alarm buttons on the elevators themselves. Everything is done from the outside. True, they have placed placards on stands with the “directions” for elevator-use for folks coming in off the street, but why on earth would anyone consult them, after so many generations of press-a-button-in-the-lobby, wait-for-an-elevator, then tell it what floor you want to go to? I expect the security guards at the main entrance to spend much of their time explaining to confused newcomers about the placards with the instructions…that the newcomers didn’t think to look for when they came in. Spectacularly bad planning.
The upshot is that applications and devices should always start from the vantage point of what the user is likely to want and need and expect, in the order that they want/need/expect it. Whether one believes that order to be the most efficient is moot. If you diverge from that order, all putative efficiency is lost in the confusion one has now elicited in the user. None of that means there is no place for manuals, but it does mean one should plan as if there were no manual, and then construct a manual for those once-in-a-while things
Thanks again for more fascinating observations.
On single centralised websites, I am tempted to adapt Clay Shirky’s dictum and say that the fact that perhaps it shouldn’t work in theory doesn’t necessarily stop it working in practice. Here in the UK, we have gov.uk, with very similar work being done in New Zealand, which doesn’t, and can’t, entirely solve the problems of the complexity of government, but goes a long way in that direction, partly by avoiding reliance on sieve and relying much more on search both within the site and, critically, before people get there. The team doing it has a blog which goes into quite a lot of detail in how they do it and a set of design principles which is the foundation for their approach.
On your second point, I like the idea that “one should plan as if there were no manual” and share your views on lift design (or there’s this impassioned rant on the design flaws involved). And more generally, you are absolutely right that good design starts from the perspective of the users.
I like the gov.uk site. Clean, clean, clean. No fancy graphics, so 56kbd modem users aren’t penalized, and everything of relevance is plainly evident. All potentially technical terms translated or matched up with common-sense exemplars. Cascaded layers that dig a little deeper, and a little deeper. Nice. Usable.
I had to smile, reading about the elevator. Ours must have the same company behind it. It certainly generates the same elevator converstion. 🙂
The design principles link is an absolute keeper. Many thanks for that.