It's one of the main things I learned when working as tech support and I talked with users all day. Nobody reads anything.
Or maybe those who do read the docs require less tech support.
The Miller Principle (2007)
51–60 of 63 posts
Re: The Miller Principle (2007)
#52I read this entire post and all the comments this disproving the Miller principle
This principle applies to the following: - User documentation - Specifications - Code comments - Any text on a user interface - Any email longer than one line Not blog posts or comments. Ironic
If you read closely, you’ll see that there is no claim that this would be an exhaustive list rather than an exemplifying one, and the principle itself unambiguously states “anything”.
Re: The Miller Principle (2007)
#53Re: The Miller Principle (2007)
#54A customer contacts me and says 'I have an error'. After several emails I manage to get them to send me a screenshot of the error. The error message describes the exact problem and what to do about in one short sentence. I type pretty much exactly the error message text into my reply. This solves their problem. I think they see 'error' or 'warning' and they don't even read the rest of the sentence. Extraordinary. But it has happened more than once.
Re: The Miller Principle (2007)
#55Probably true. Also probably true: people have read enough of the things he listed and concluded that they wasted their time. I remember trying Linux in the RTFM days, and let me tell you, those were some terrible documents even when they did talk about the problem.
Re: The Miller Principle (2007)
#56Except now LLMs read everything.
Re: The Miller Principle (2007)
#57For fun, I recently rebuilt a little text adventure some friends and I had built in the early 2000s. Originally written in QBasic, I translated it line by line in Go, and set it up as a little SSH server. For posterity, I didn't want to change anything about the actual game itself but knew beforehand that the commands were difficult to figure out organically. To try and help modern players, I added an introductory he…
I wonder how different the outcome would be if the idiom used was not help but "instructions", as in, what portion of users did not want to admit they needed assistance?
I'm not refuting the fact that people seldom read, but this seems like an interesting additional vector to explore.
Re: The Miller Principle (2007)
#58A customer contacts me and says 'I have an error'. After several emails I manage to get them to send me a screenshot of the error. The error message describes the exact problem and what to do about in one short sentence. I type pretty much exactly the error message text into my reply. This solves their problem. I think they see 'error' or 'warning' and they don't even read the rest of the sentence. Extraordinary. But…
They were taught not to read errors because they encountered thousands of errors (in other software) that were less helpful than that one.
Most people have an adversarial relationship with software: it is just the pile of broken glass they have to crawl through on the way to getting their task done. This understanding is reinforced and becomes more entrenched with each next paper cut.
Re: The Miller Principle (2007)
#59For fun, I recently rebuilt a little text adventure some friends and I had built in the early 2000s. Originally written in QBasic, I translated it line by line in Go, and set it up as a little SSH server. For posterity, I didn't want to change anything about the actual game itself but knew beforehand that the commands were difficult to figure out organically. To try and help modern players, I added an introductory he…
> They'd just type tens of invalid commands, get frustrated and quit.
Is that like the "players" who send HTTP requests to my mail server?
Re: The Miller Principle (2007)
#60I didn't read the article, but ...