Research Proving People Don't RTFM, Resent 'Over-Featured' Products, Wins Ig Nobel Prize (improbable.com) 101
An anonymous reader writes:
Thursday the humor magazine Annals of Improbable Research held their 28th annual ceremony recognizing the real (but unusual) scientific research papers "that make people laugh, then think." And winning this year's coveted Literature prize was a paper titled "Life Is Too Short to RTFM: How Users Relate to Documentation and Excess Features in Consumer Products," which concluded that most people really, truly don't read the manual, "and most do not use all the features of the products that they own and use regularly..."
"Over-featuring and being forced to consult manuals also appears to cause negative emotional experiences."
Another team measured "the frequency, motivation, and effects of shouting and cursing while driving an automobile," which won them the Ig Nobel Peace Prize. Other topics of research included self-colonoscopies, removing kidney stones with roller coasters, and (theoretical) cannibalism. "Acceptance speeches are limited to 60 seconds," reports Ars Technica, "strictly enforced by an eight-year-old girl nicknamed 'Miss Sweetie-Poo,' who will interrupt those who exceed the time limit by repeating, 'Please stop. I'm bored.' Until they stop."
You can watch the whole wacky ceremony on YouTube. The awards are presented by actual Nobel Prize laureates -- and at least one past winner of an Ig Nobel Prize later went on to win an actual Nobel Prize.
"Over-featuring and being forced to consult manuals also appears to cause negative emotional experiences."
Another team measured "the frequency, motivation, and effects of shouting and cursing while driving an automobile," which won them the Ig Nobel Peace Prize. Other topics of research included self-colonoscopies, removing kidney stones with roller coasters, and (theoretical) cannibalism. "Acceptance speeches are limited to 60 seconds," reports Ars Technica, "strictly enforced by an eight-year-old girl nicknamed 'Miss Sweetie-Poo,' who will interrupt those who exceed the time limit by repeating, 'Please stop. I'm bored.' Until they stop."
You can watch the whole wacky ceremony on YouTube. The awards are presented by actual Nobel Prize laureates -- and at least one past winner of an Ig Nobel Prize later went on to win an actual Nobel Prize.
sorry (Score:1)
TL:DR
Why bother... (Score:1)
The features and interface will all be different in 6 months anyways for 90% of software. Anything that survives was simple enough to figure out already anyways.
This is why (Score:2)
Several points, mostly directed at developers:
1) With online documentation, the manual can (and should!) be kept 100% up to date with the software. Further, if the documentation for a feature is generated at the same time the feature is added, and modified as things that affect that feature are added, this isn't all that difficult a task. There's no
Re: (Score:2)
2) Software that changes in such a way that it doesn't do what it did before the same way, or even at all, rendering previous learning by the customer useless, is bad â" extremely bad â" design.
This is not necessarily bad, if the new way is actually better. This is what Microsoft in particular hasn't figured out. They change stuff just to have it be different, without making it any better. They did it in 8, and they did it again in 10. 2000 and XP are largely identical and even 7 is comprehensible to someone who comes from one of them, and they are largely familiar to someone who came up from NT4. It was a valuable lesson, but they must have lost the staff which had learned it.
Re: (Score:2)
I strongly disagree. You want to provide a new thing, or even just a new way, then fine, do so. But don't break what was already there. I am all for offering users new things. Just as long as it doesn't break the old things. And really, there's no reason to.
Got a new UI, software feature, etc.? Fine. Provide a switch or other optional mechanism. Let the customer decide if they want to use it. If they don't, then the previous (whatever) should co
Re: (Score:2)
Change will occur one way or another. Your philosophy often results in writing new software that can do the new things the way potential customers want it.
Your company doesn't want to maintain two applications that perform similar functions. The old will not receive updates or support and will die. So is it better to softly nudge your customers with minor changes, or force them to learn the entirely new software which is quite different?
As your competitor, I know which one I would have you choose... so b
Re: (Score:2)
An actual customer is worth a lot more than a speculative potential customer. Don't annoy your existing customer base in the hope that one day, maybe, your new UI will attract more new customers.
Unless you're writing apps for some iThing, of course, then break everything randomly with each major update and your customers will beg you to hurt them more.
Re: (Score:2)
Your company doesn't want to maintain two applications that perform similar functions.
Why not? How much does it really cost to maintain an old application?
The old will not receive updates or support and will die.
Why? How much has the API to the underlying hardware changed? If not, what's breaking the old software?
Re: (Score:2)
Why not? How much does it really cost to maintain an old application?
More than it costs to maintain one.
The old will not receive updates or support and will die.
Why?
Because companies don't exist to waste money.
Re: (Score:2)
(Slashdot needs an edit function)
What I meant to say is, it costs more to maintain two applications than it costs to maintain one.
Re: (Score:2)
Something worth keeping in mind! (Score:3)
When you are architecting software, this is actually something you should keep in mind. If you keep things simple then people can actually use your software. However, if you complicate things because you're "smarter" than the users then you can congratulate yourself on that but you have failed the users despite your length documentation.
Re: (Score:2, Informative)
I have in the past rewritten a number of manuals nobody read. These generally were a mess, with misleading chapter and paragraph titles, information about some subjects was scattered all over the place, contradictory and incomplete. After I finished with it the structure was logical, titles were descriptive and designed to match questions people would have, information was complete, correct and not scattered around, and the size of the manual typically was about 1/4 of the original.
People still didn't read
Re: (Score:1)
Amen! I've had the same experience. Next I'll try pop-up manuals with bears and Power Rangers.
Re: (Score:1)
Here's the solution from nazis
http://www.alanhamby.com/tigerfibel.shtml
Re: (Score:2)
Here's the solution from nazis
http://www.alanhamby.com/tiger... [alanhamby.com]
One of the more entertaining manuals out there. I particularly enjoy the drawings of the lady keeping clean, and the guy shifting what appears to be a Benz SSK with index and thumb only. At the end of the book there's charts on how far the Tiger can be from a US or Soviet tank and hole it, while being impervious to the target's rounds. Those krauts sure knew how to build a tank!
I miss the old Japanese electronics manual, they had the most wonderful drawings of anthropomorphized things, like a cassette ha
Re: (Score:2, Insightful)
I do, or at least try to, read the manual. But then I'm a sysadmin. Even so, I typically don't read the entire thing because it's just too tedious, annoying, incomprehensible, or whatever. Most manuals suck giant balls through tiny straws. I try to get a general sense of the thing and fill in the needed-now blanks until it functions enough to make do, and maybe will get back to making it do more later. I typically notice soon enough when I need more power, at which point I'll re-check the manual and if unsa
UI for work flow, not reflecting the internals (Score:5, Insightful)
In my experience, applications that have enough different features an complexity to really be a problem often support doing several different tasks. Often it can be made much more usable by designing a UI around the distinct jobs one can do using the software, a UI based on workflow. I'm not going to say wizards exactly, but UI flows designed for specific tasks the user wants to accomplish.
The UI often represents the underlying underlying data rather than the tasks. You know for sure that you have this kind of UI if it has different sections for different kinds of objects. Of these different kinds of objects map to different table in your database, you definitely have a data-centric UI instead of a task-centric one.
My server backup software originally had a data-centric UI. It was basically alot like managing hosting accounts. It had a page for servers - listing, adding, removing, and editing them. It had a page for DNS names - adding, removing, and editing them. There were a couple other pages like that, for manahaing the objects in the application. That worked great for me. Users didn't like it.
We added another UI that started with this page:
Add a new server
Restore file or server
Manage billing
Other tasks
Clicking "add a new server" took the user through the steps of adding a new server - including any domain names related to that server. Clicking "restore a file or server" took them through the steps to do that. At each step, the only saw the options relevant to that step.
The task-centric model is a great way to manage complexity. The data-centric UI can also be useful at times, but it's inherently more difficult to learn and use in many cases. Some applications warrant having both options. We kept both for the server backup system. Customers used the task-centric, wizard-like UI for common tasks. For less-common tasks, the data-centric UI was more flexible.
MODES (Score:2)
Wizards are restrictive hand holding... but probably fine for simple things or dangerous things...
What you are looking for is MODES; which it sounds like you kind of found.
Easier to do on a webpage since each "page" lends itself to being it's own mode and the metaphor is there but well hidden. In an app, you don't see them that often these days they've largely been forgotten but also many apps are too simple to be forced into that situation. Plus the trend is now to copy old children's software. Some hi
Absolutely agreed. Code generator for data-centric (Score:2)
Absolutely agreed. Many years ago, I had built enough web UOs which tied to a database back end, thay i went ahead and built framework and template system to automate generating the data-centric one. With just a few customization rules added to the configuration table, I could have a decent view of the software's internal model competed within a couple hours. (Good generic CSS also helped with this.)
After creating the data-centric UI I a couple hours, we could then build the task-centric side for common wo
Re: (Score:2)
You need a manual though sometimes. Or often. I still don't know how to use my iPhone properly because it had literally no instructions that came with it. Not even something that pointed you to a web site to go to. I see a lot that someone will use their phone a certain way and others are surprised and ask "how did you do that?" On Android I was baffled what all the tiny status icons meant as well, as in what was ok and what was an error.
Manuals people, write them!
Re: (Score:2)
Re: (Score:2)
So why DID the people call? Because they wanted to talk to a human. They probably never put a floppy into their machine and as many people, where suddenly blind.
I've also found this to be true and I also find it to be one of the most frustrating human behaviors. Some people seem to be paralyzed by fear, unable to cope with uncertainty and thus demand someone hold their hand to walk them though the process. What makes it worse is that this isn't something they get over, it's a pattern of behavior.
80/20 rule (Score:5, Interesting)
Re: (Score:1)
That and OO having some ridiculous and very ancient bugs they apparently don't want to deal with. Since I write, all my favorites are in the Writer. Things like not being able to turn off that idiotic 'snap to cursor' that prevents you from scrolling down and reading text while leaving your cursor where you're editing, auto-capitalization correctly handling new lines, suddenly shifting into 'secret text' mode where you can't see anything you're currently typing, moving a page from one area in the document
Re: (Score:2)
Yeah, every time I use OO Writer I hit this shit. Paragraphs just randomly change format, and re-applying the style doesn't fix it. It's buggy as hell. MS Office has been going downhill for the last few releases. I don't know what to do.
Re: (Score:2)
Use flat text, or perhaps a simple "markdown" language. I've been avoiding MS Office formats for some time: they encourage spending far too much time on tuning a font size or colors, rather then on writing or organizing the ideas being expressed.
Boy that sucks (Score:1)
Re: (Score:2)
People hate to read like me (if too much). :P
Re: (Score:2)
I can relate. Back when I was a poor post-doc, I sold myself as a technical writer and wrote a bunch of manuals. Everything from software to machine tools. This was before everything was translated from Chinese.
I'm still something of a connoisseur of good manuals. Occasionally, I find an absolute gem, and it makes me want to write a thank you letter to the company.
Re:Boy that sucks (Score:2)
I'm still something of a connoisseur of good manuals.
Well, manuals are kinda like sex. When they're good, they're REALLY good. And when they're bad, they're better than nothing.
[not my joke. was originally about documentation I think. Don't know the attribution]
Re: (Score:3)
What consititutes "reading the manual"? If it means reading every word from front to back then "No". If it means "scanning it from front to back and reading the parts that I care about, then "Yes".
Re: (Score:2)
That's exactly what I do. Scan the ToC, jump to chapters of interest, read the introduction and how-to, read the rest of the chapter if it looks interesting or if I need a particular function, then on to the next chapter of interest.
The last manual I read - actually read - more than 50% was WordPerfect 5.1. Between that, and the little keyboard cheat sheets, I was a WordPerfect guru. That was one powerful program, and I'm sorry it's gone out of use. I still fire it up in DosBox once in a while for the nost
Re: (Score:2)
It depends. I read manpages. I searchtechnical references. I scantutorials.
Re: (Score:2)
It depends. I read manpages. I searchtechnical references. I scantutorials.
Also, I don't preview. I live on the edge, baby!
Re: (Score:1)
How do you get upset by reading about useful information?
Just like you get upset about reading a bad book . . . it's boring.
Manuals need to present hidden features as "Easter Eggs" that users can collect for points, fame and glory . . . and then use the points to buy more features.
Manuals need addictive "Game of Thrones"-like plots that induce users to binge read them . . . with fictional creepy creatures, intrigue and dubious wars over petty matters.
Manuals could offer an additional porn version with a "Game of Bones"-like plot.
Manuals need to have stuff tha
Re: (Score:2)
Except that most modern manuals _don't_ tell you details. That requires a repair manual or the debugging manual, which is rarely available to consumers.
Re: (Score:2)
A manual's not a novel. It should cascade through topic headings that lead you to the information you need.
Re: (Score:2)
There are manuals, then there are manuals (Score:5, Interesting)
There's nothing I hate more than trying to figure out what some dyslexic English as a Third Language moron created using Google Translate actually meant.
Then there are the manuals that contain proper English that repeat everything, except the answer you actually need.
I had bookshelves full of Microsoft, Oracle and Solaris manuals that (with the advent of reasonably good search engines) I quickly tossed into the recycling bin,
Re: (Score:3)
Then there are manuals that are full of cautions meant to absolve the vendor of legal liability if you do something incredibly stupid with their product, but don't actually help you use the product for its intended purpose.
WI TFM? (Score:2)
Usually, people who tell others to "RTFM" have no idea where TFM is, or if there even is a FM, or if TFM covers the F subject.
They just blurt it out as if they get a cracker every time they do.
BWAAACK
RTFM!
RTFM!
RTFM!
RTFM!
RTFM!
RTFM!
BWAAACK
Research like this is why software is crap (Score:5, Insightful)
Research like this is causing software to be increasingly dumbed down to a point where it is extremely difficult to use. In the past you could configure software to work in a way you found desirable and productive, but now all the sophisticated is being removed and you're forced to work the way the UX designers dictate. Take Firefox:
I could go on all day with Firefox, but dumbing down of the browser by removing features and options has turned it into a nightmare to use. The same is very much true of Windows 10 which is an absolute train wreck. I've found myself increasingly moving away from commercial software produced by UX designers to FOSS produced by programmers simply because I want software that works.
The thing is, it's not just technical users who hate what UX designers are doing to software, and casual users I speak to also hate the constant UI changes, the hiding of features and the removal of options. Now here we have some worthless 'intellectuals' being given a Nobel Prize for telling people to fuck up their software.
It's little wonder we're moving to a world where computes are becoming less sophisticated and turning into machines for running 'apps' that you can only get from a curated store that bans anything remotely useful. With the direction computing is headed, I think I'll just go and live in a cave.
Re: Research like this is why software is crap (Score:2)
God forbid software becomes something more than 1-2% of the population can use.
Re: Research like this is why software is crap (Score:2)
Re: Research like this is why software is crap (Score:2)
Re:Research like this is why software is crap (Score:5, Interesting)
I bought my mum a Chromebook because Windows and Firefox were confusing for her. She's not a novice, she actually had training in Windows and Office, but there is still a lot of crap that she can't handle.
So there is utility in being simple. What we need is apps that have a simple mode and a power user mode. Considering how flexible the Firefox UI is supposed to be it seems like they missed an opportunity there.
Re: (Score:2)
I bought my mum a Chromebook because Windows and Firefox were confusing for her.
That's just an argument in favor of what the GP was talking about, hiding complexity but keeping it available. about:config is a great example of that working. A lot of functionality in Firefox in particular should not just be hidden, but also moved into addons. A prime example is developer tools. I do NOT need that stuff 99% of the time, and I regularly bring it up by fat-fingering. If it were an addon I could disable, that wouldn't happen without me having to dick with settings. I shudder to think of what
Re: (Score:2)
Congratulations on not only not reading TFA, but missing the point of the headline: IGNobel Prize.
And congratulations for not getting the point the research paper made.
We found that manuals are not read by the majority of people, and most do not use all the features of the products that they own and use regularly. Men are more likely to do both than women, and younger people are less likely to use manuals than middle-aged and older ones. More educated people are also less likely to read manuals. Over-featuring and being forced to consult manuals also appears to cause negative emotional experiences. Implications of these findings are discussed.
The paper does not advocate for the sort of UI stupidity you describe!
Re: (Score:2)
It does, by associating the 'negative emotional experience' of reading a manual (aka learning) with so-called "over-featuring", whatever "over" is supposed to mean. Of course reading a manual is unpleasant, for the same reason studying anything is unpleasant - e.g. engineers study advanced calculus (which tends to create a 'negative emotional experience') because it helps them later do useful things like build bridges that don't collapse.
Likewise, studying a user manual (unpleasant learning/studying) helps
Re: (Score:2)
The paper describes something that happens in the real world: features going unused because the users don't read the documentation and/or the software makes it look too complicated. Wishing this phenomenon would go away doesn't work.
The recommendations at the end of the paper are worth checking out.
We are not suggesting that designers avoid including additional features completely or that all mention of features should be excluded from product promotion, but it is about finding the right balance and the correct features for the product.
All too often, programmers add features to a program haphazardly, making documenting those features a pain in the ass.
The answer to that is not to remove those features or to hide them under a hamburger menu, and
Intuitive UI (Score:5, Insightful)
Yes, well... Is it a surprise when they've tossed all that we've learned about UI making?
Clickable objects are no longer clearly marked as such. Different kinds of content are no longer clearly distinguished from one another. Contectual information on mouse-over or right click or even F1 is hit and miss, but usually miss.
And be honest, how often do you go "What kind of moron from Bizarro Land would name this function that and put it there??!!".
Or lists... on one frame, it's exportable on the second it's sortable and on the third you can do multi-selection. But not one of them can do all three.
Not to forget that if whatever you are using happens to have multi-platform apps, GUIs or whatever, you can bet your ass they won't have been developed by the same team. So you not only need to handle each and every single app with a lot of TLC for them to even remotely do what you want, you'll have to learn to do it differently on your MacOS laptop, on your Android phone and on your Windows desktop. If you're especially lucky, the online interface will behave differently depending on the browser too.
And let's be exceptionally frank here, writing a good manual is an artform few have ever mastered. 90% of my use cases I find my answers on some message board online and certainly not in a manual.
OR, as it's the case with our current backup software, the manual is easily 1000 pages. Now, if I were tasked solely with pampering our backup software, you could argue that that is doable and you'd be right. But I also have to pamper the storage environment (with several products, of course), the Cisco UCS, SAN infrastructure and Vmware Virtualization as a cherry on top.
And in order to not kill motherfuckers daily, I strictly adhere to my 8 hour work days, except for emergencies and maintenance tasks that cannot be done on hours.
So imagine this new-fangled dohicky coming along expecting me to forego everything I thought I knew about gadgets and do it their way now because reasons. Yeaaah, no. Go fuck yourself, would you kindly?
Re: (Score:3)
A lot of this is "design" as artistic expression rather than design as functional communication. And I suspect it's not people who are trained as designers but product managers with delusions of artistic ability. Or its marketers obscuring function with emotional messages that crowd out function.
Microsoft is particularly guilty of marketing communication trumping function. Microsoft Office's interface was pretty much as good as it needed to be by the mid 90s, with the exception of bug and security fixes
Re: Who (Score:2)
If it's well designed, nobody.
The problem you often see, though, is that a simple, well designed, useful program will slowly, over time, "evolve" into a bloated mess full of "features" which you never use with a UI that makes it difficult to actually find what you're looking for.
As a bonus, if it's an "app", it will also get bogged down with advertisements to help pay for all these new "features" which nobody wanted.
I don't RTFM and hate over-featured apps. Why? (Score:2)
I don't RTFM ever (only did to learn how a programming language works and the language needed to code in it).
GUIs are normally built foolproof (read the icon pop-up title and you'll know what it does). Puntually, I search for a very very specific question.
So, I don't RTFM and still I'm able to work with the programs.
I DO HATE over-featured apps. Seriously, I DON'T NEED an e-mail app that also searchs the web and can track my next flying. It's a f*cking E-MAIL APP.
If I wanted a SUISSE-KNIFE APP, I would have
To the article's point (Score:4, Interesting)
Re: (Score:2)
IoT is a solution to a problem, just not the consumer's problem. It is a solution to the manufacturer's problem of gathering as much information on the consumer as possible so that they can make money on whatever they sold you *and* make money selling that information. A lot of IoT and smart devices now are practically sold at a loss from a hardware perspective just so they can tap into that revenue stream.
Canon and Kyocera, I'm looking at you (Score:3)
Canon and Kyocera have to have some of the most egregious manuals out there. Canon in particular will start with a section (let's say how to input an IP address into a printer), but in addition to the few steps to do this, they will have 5-6 extraneous, and completely unnecessary sub-sections which point to something else but don't make it clear if you need to follow those steps.
Or worse, they'll point you to another section somewhere else in the manual, even though you're at the part where logically, that part comes next.
It is quite obvious the people making manuals don't work with the software/hardware but rely on the engineers to tell them what to write. And engineers don't know what to write because to them it all makes sense since they work with the software/hardware.
As an aside, my credit union's telephone banking has become essentially unusable since they changed systems. Based on the hoops one now has to jump through, it is quite clear the software developers have never used a phone tree. Without exaggeration, every option pressed leads to a voice telling you, "Okay, let's do X" or "Wait while I do X".
This explains why manuals are so poorly done. The people don't have a clue what they're doing.
Re: (Score:1)
Re: Connections (Score:3)
Wipe his ass.
As an acolyte of the BoFH... (Score:2)
If you have to read a manual to use it... (Score:2)
it wasn't built right.
Take cars, for example. They are highly complex machines. Yes, there's a manual. But when you go rent a car, do you first read the manual? No! Why would you? The controls are easy enough to use that you can figure them out. You only need the manual if you really need to take it apart and fix something.
Software and gadgets shouldn't be any different.