The user is on their own
selfawaresoup.com
selfawaresoup.com
You aren't making a lathe for someone with no experience. Anyone who is a potential customer for a lathe has SOME experience, even if it's just enough to say "I want a lathe" and the amount of effort they will need to go through to onboard to using the lathe properly is directly proportional to the applicable mental models they have for similar tasks. This probably involves hand eye coordination and gestures along with physics and a bunch of other things to onboard quickly.
Intuition is about using the most fundamental mental models that your customer(s) should have and simplifying the connection of those to the new task.
So intuition is contextual. The main goal is to save the user time. The narrow goal is to make the product easier to learn compared to your competitors. The big problem is no matter WHAT you do, the mental model a user will use when they approach a new task for the first time is inevitably different than the one you did.
Or, "You are not your customer" or however you want to phrase it.
De-facto public infrastructure are things like banking, energy companies, stuff like that. "Public infrastructure" is perhaps not entirely the right term for this, but it is something more or less anyone is expected to be able to use, and where competition is often limited (or sometimes even non-existent).
Remember the UK Post Office scandal? While I strongly feel the main cause was not the software[1], one reason the cunts in charge manage to gaslight people for so long was because the software is so complex, difficult, and does suck.
[1]: Previous: https://news.ycombinator.com/item?id=39013418
But faced with a basic modern 3-axis CNC mill, they'd be totally lost.
I’ve had so many projects where we took users for fools. Boy did they fail.
Probably the #1 image I wish I could purge from my mind is that of a lathe accident. I saw the picture maybe 15 years ago, and I still remember it in horrifying detail.
Some tools really shouldn't be used until a person has had thorough safety training. The two that immediately come to mind are lathes and table saws.
Granted, power drills are moderately benign as these things go, but you can do a lot of damage to a work piece really fast if you select a tool or setting you're unfamiliar with. Which is why there manuals, books, videos, and classes to teach you.
Blogging about discoverability in the context of power tool interfaces is just peak software engineer naval gazing.
To my defense, I put a bit of wood between the metal and my hand to prevent drilling my hand but little did I know how the drill catches the steel on the very last part of the cut.
The others: very, very yes. Very yes. Jointers too. Jointers exist to show malice.
I don't remember hearing about any serious planer injuries (though I'm sure it happens), jointers on the other hand are more ornery than an alligator with all them teeth and no toothbrush.
I have a reasonably safe checklist and set practice for my jointer and I still don't trust the thing.
Drill, table saw, router, belt sander are all big no-nos.
Orbital sander is about the only power tool I'd be comfortable wearing gloves with.
Took me long enough to LEARN to wear gloves, now I have to unlearn it in specific cases :)
I have a bench grinder that I use to clean rust off various pieces of metal, and you'd better believe I wear gloves when using it. My reasoning is that the chance of accidentally touching the grinding wheel is high, and a glove will prevent most injuries, while the chance of the glove getting wound around the grinding wheel is near zero because it doesn't take much pressure to stop the wheel. Am I wrong?
No, today it is a lathe, tomorrow is capucino, the day after tomorrow is shit. See the evolution of GUI in Windows and Android.
I consider it similar to an audio engineer staring at a complex screen of panels, dials, scales - to a random person it wouldn't be intuitive at all, but to the target customer that's exactly how they are surfacing the important parts of their work to a control space.
By the way - the author ultimately did figure out how to use the drill, can't help but wonder if anyone in the chat had to use a drill for some reason, they would simply watch the same video and easily figure it out too - or more likely just turn it, see the difference and be like "Ah ok" without even understanding what torque is.
Article could use an ending or something definitive - this piece wants to be more insightful. Maybe a few more visuals to keep the reader close to the author's train of thought.
I expect most people that buy something like this would read the single-page manual that tells you what each control does. But they can't see the difference, because it's not visible.
All you know is that it evolved from what was intuitive to professionals at introduction. New trainees today never touch a roll of film or align clips, but they have to decipher it without the context.
And yeah article backed out of actually saying anything pointed. Which is a shame because one could really get into it about how pro software UI is a completely different ballgame from other types of UI. Priorities, aesthetic choices, expectations, user habits.
I actually had the opportunity and pleasure to participate in designing UI for a complex device, and some of the current web trends really clashed with the UI that our CAD engineers were pushing for. Our discovery process would regularly prove them wrong about what actually worked for users.
There are complex things that need to be complex no matter what. Important thing is not to call people stupid and blame them if they don’t get right away something that is obvious for you.
Annoying part or the other part of the problem is that there are people who disregard the complexity and would like to be an “audio engineer” and they believe that if only you explain them what buttons do, they can do your job.
There is a wall of knowledge one has to pass through to become an audio engineer or software engineer or else, it is not just clicking the right buttons or typing something on the keyboard.
One nowadays can get all the materials and have to learn on their own - but bashing newcomers should not be tolerated.
A user is not required to know what each button does, because in the first few minutes of using the app, they will press them and find out. Can't easily do that with a drill or a car, but an app has "back" and "undo" buttons.
A user is not required to understand every subtlety of a form, because they can click the "?" button in the corner and get more details. Can't easily build the manual into the side of the drill.
I hate apps that are frustrating and slow to use all the time just so that it can be "intuitive" the first time. The first time only happen once, please don't optimize only for that workflow, and let power users get through the app fast! Offer keyboard shortcuts! Let me customize toolbars and gestures, even if it means making the settings more than one page!
I don't know if this was the author's point or not. I am not sure which direction they were arguing after reading the article twice.
Not to mention they’ll send your habit down the pipe anyway with the next forced update, which contains “redesign for easier use”, which makes it less easy.
Looking at Windows settings: help screens - link to some article on internet, exploration - i really don't have time to learn every version of Settings, documentation - good luck with that.
I'm working on a legacy app that takes config from a spaghetti stack of files in 20 different places. This really lends itself to what I call "the fogbank effect" - you make a change and have no clue whether things got better or worse because you just get a different error message. You have no frame of reference for what the error message means. You are stuck in a fogbank. This effect is quite prominent for novice users/developers.
The whole post seems like giving up. It is possible to make things easier to understand in context.
> there’s a whole range of cases where people don’t have to know exactly how something is intended to be used in order to successfully finish a task
You're demonstrating being able to get a screw in with it without understanding what it does: it doesn't change the power supply at all, but I can see how you might accidentally use it somewhat correctly while applying this assumption. Isn't that basically what OP meant to demonstrate there?
I know exactly what the ring on a drill does. It limits the force of the bit and stops me from damaging the heads of screws. I have a vague idea of how it works mechanically but I can never remember what torque means.
It’s possible to know how to use something without knowing the actual mechanics that make it work.
On a physical level I know what it does and when to use it (all the way up for drill bits, really low for screws going into a soft material), but when I saw the questions I had no idea what the correct answer was.
I've always found drills to be extremely intuitive--it's four really simple physical binary things: squeeze the trigger to make it go, flip the switch on top to make it go faster, turn the dial to make it it stop before it goes too hard, and punch the toggle to make it go the other way. I wish software was that easy.
I was having a discussion about databases and SQL with some coworkers and I want to get a chance to argue for using that as opposed to an ORM that generates some generic query functions. I feel like doing it the “hard and unintuitive” way will require more work and also allow for much finer-grained control and the ability to tweak queries and get into the details of indexes and execution plans, which can be important at some points. And there is no worrying about the quality or correctness of generated code.
At the same time I have been largely impressed with the thought that as developers we need a continuing and life-long lesson in empathy. Ask a non-daily computer user, maybe a senior citizen, to start making appointments and dealing with logistics online and see the result. And what if the person in question cannot afford a cell phone? Or a smart one with a web browser built in? Are we to leave such people behind? And what of accessibility? Of literacy or language fluency?
These issues are - to me - all tied up. There are no easy answers and as with all practical things there will be decisions and tradeoffs made.
But I think it is definitely worth thinking about.
Here is another article with different ideas on the subject: https://news.ycombinator.com/item?id=35589176
I think the answer for people who do not have or for some reason cannot use computing devices is to provide places they can go and be assisted (we have those in France called "maisons de service").
I don't think you can design everything around the lowest common denominator (in terms of language or computer literacy) but you can provide ways of obtaining assistance for those that can't manage by themselves.
Although people are still very capable of writing terrible code.
The real, best reason to use an ORM is to piggyback on their migration management- the abject awful chaos of DIY migration tooling is difficult to describe.
There are advantages for using an ORM for queries. Its more concise (at least Django ORM, which is what I mostly use), it uses the same syntax as the rest of your code, and it returns an object. It works very well for simple queries but for more complex ones it does sometimes feel like I am fighting the ORM, and you do often have to look at the generated SQL too.
Most power drills come with instructions.
"Unless bot hare literally 100% automated" -> "Unless both are"
"I’d probably say somethings like" -> "something like"
"driven to deep into a pice of wood" -> "driven too deep into a piece of wood"
In software UX the only ways to make intuitive-seeming interfaces are to borrow successful patterns from elsewhere. Then humans who have learned those interfaces will have skills transfer to your interfaces. This is why Apple, Microsoft, Google all have such rich and deep interface guidelines. They’re trying to teach you, the designer/developer, how to communicate with their users that have been trained on those interfaces.
Of course people can think their way through new things, or trial and error, but that’s not what we mean by “intuitive.” Intuition is rapid pattern-matching, and it only works when the new patterns are close enough to the old.
I have no idea how or why that particular baby (I assume you mean a human one) struggled to breastfeed. However you literally mention "premature baby".
I'll give a counter example or 10:
I have seen quite a few nature documentaries that involved birth and suckling or similar initial care, without any sign of learning. Last week I watched a sperm whale calf being born and then searching for and latching on a teat within around a minute. That's in the ocean. The baby weighs about a tonne and mum weighs about 15. She will be moving around and so does the ocean. Despite all that the baby manages to swim, locate a nipple, feed, surface to breathe and so on with minimal assistance.
Humans have hands and can pick up their offspring and direct all operations.
A kangaroo joey has to climb up mum and find the pouch, climb in and find the nipple. I recall that mum licks a trail for it to follow (or perhaps I've gone all ChatGPT - I'm not a biologist)
A random Apple employee is perhaps not best placed to make comparisons between computer interfaces and the natural world, involving birth. The very fact that you can read this comment, almost certainly means that you, when you were a new born baby was able to find your mother's teat and you did it without any prompting.
> Bandwidth Restricted
> The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.
> Details:
> 451 Actioning this file would cause "www.selfawaresoup.com//notes/2024/05/01/the-user-is-on-their-own/" to exceed the per-day file actions limit of 80000 actions, try again later
> Temporarily Offline
> Internet Archive services are temporarily offline.
> Please check our Twitter feed for the latest information.
> We apologize for the inconvenience.
If you don’t care about user adoption (it’s for yourself or a captive audience), then you can have less polish and rely more on training, to an extent. But your tool will be compared with consumer software.
Note the "core part" though. Even professional tools that many people have to use occasionally (say tools to book professional travel) should be intuative because someone who uses it once or twice a year will forget complex things. But it's probably OK for a CAD program used by engineers as a main part of their job to have a steep learning curve.
> I’m not convinced that making interfaces so simple and “intuitive” that anyone can truly learn them on their own is even possible, maybe not even desirable since it encourages more of that kind of rugged individualism in computing
If your software gets the users the training they need, they might be much happier with it and recommend it to colleagues in the field or request it at a future workplace. They'll also know who to ask because they've made contact with experts already
A competing product where everything is made obvious, but also dumbed down and cumbersome in some ways because you are always treated like a beginner, may end up losing out if the training-required one gets their market placement right
There are useful and testable ways to think about usability. A good metric is, can you achieve the goal without backtracking? This is tested by making videos of people attempting the task and observing when they have to back up. Such user testing was common in the era of desktop applications which cost money to buy and had to keep customers happy. It is seldom seen in the era of webcrap.
Not having to backtrack is close to what mathematicians call "obvious". Differentation is obvious but integration is not.[1]
The avionics people work hard on this.[2] That's a rather long document which collects info from other sources. A few excerpts:
• The primary test for designation of color is:
- Red - Immediate action required
- Amber - Pilot action (other than immediate) required
- Green - Safe operation indicated.
- Other advisory lights - any color distinct from the above.
This has been a standard for industrial equipment and aircraft for a century.
• If the flightcrew’s only way to determine non-normal values is by monitoring display values presented on the display, the equipment should offer qualitative display formats. Qualitative display formats convey rate and trend information better than quantitative (e.g. digital) presentations.
• Controls whose functions are not obvious (they mean yoke, throttles, etc.) should be marked or identified so that a flightcrew member with little or no familiarity with the airplane is able to rapidly, accurately, and consistently identify their functions. All the abbreviations seen on cockpit controls are standardized. There's a list, and it's not that long.
• To avoid visual clutter, graphic elements should be included only if they add useful information content, reduce flightcrew access or interpretation time, or decrease the probability of interpretation error.
The section on "Menus", on page 156, is definitely worth reading. And following.
This stuff isn't a mysterious unknown. It's well-known and well documented in aerospace.
[2] https://www.volpe.dot.gov/sites/volpe.dot.gov/files/docs/Hum...
My favorite joke about this: a math professor starts the class by writing an equation on the board. Then he tells the class: "from this, it is obvious that--" and writes a second equation below the first.
Then the professor stops, wrinkles his forehead, and mutters, "Wait a minute, I may be wrong...". He thinks a few moments more, and then starts writing more equations. More and more equations. Equations covering the whole board. He does this for the rest of the class, and then just before the bell rings, he says "Aha! I was right after all! It is obvious that the second equation follows from the first."
I think it is helpful to include documentation; that will (hopefully, if the documentation is well written) make it easier to figure out, if the user reads the documentation. Devices and computer programs that do not have documentation are more difficult. Sometimes some of the functions can be figured out without too much difficulty. E.g. I have once figured out how to operate a radio scanner, even though most other people there could not figure it out, and I have never operated a radio scanner before. Perhaps if they read the documentation (if they had it; I didn't have it so maybe they didn't either) they would figure it out and I would also figure it out more easily. But having good documentation is better.
Certainly not intuitive, even if you're old enough to recall what a VCR is used for. Not any more intuitive if you labeled it "phono" instead of VCR.
I'm making this comment so late after the post that probably this won't be seen but I want to mention it because there's a nice corollary here about using things in the non-intuitive way:
Back in the heavily-DIY punk days, you could use a VCR as a cheap compressor -- a couple of orders of magnitude cheaper, but practically as effective.
As a nice additional feature, the drill slow starts and limits the top speed in lower torque settings.
I end up using the drill for small screws (generally on electronics) a lot more than one normally would, as the soft torque limit works fast enough to not strip screws or heads.
This feels like a "we need to better telegraph the 'sport' mode button next to the gear shift leers, so more 16 year olds know that there's a shortcut to squealing tires and losing traction". Put another way, one of the first things I was taught about using power tools is that if you don't know how to use something, don't touch it. Improving the "interface" on power tools to improve discoverability sort of misses the point here.
That's probably as good of an example of mismatched expectations in UI paradigms as I've ever seen. The buttons are pretty common, pretty obvious, and intuitive, but because the expectations were so different she just missed it.
Something similar sometimes happens with drivers not expecting cyclists: they will look to the left to see if something is coming, but their attention is geared towards "is there a car there?" and they will completely miss the cyclist or pedestrian right there in front view. The famous "people completely fail to see the person in gorilla costume" is another famous example of this.
---
I once ran a computer course for older people in the local community centre. This was over 20 years ago when (usually older) computer illiterate people were a bit more common (they still exist, but it's much rarer), and I found very little was "intuitive" for many of them. Windows showing a popup? Or even the taskbar in general? Yeah, good luck trying to explain window management.
https://en.wikipedia.org/wiki/A_moron_in_a_hurry
> A moron in a hurry is a phrase that has been used in legal cases, especially in the UK, involving trademark infringement and passing off. Where one party alleges that another (the defendant) has infringed their intellectual property rights by offering for sale a product that is confusably similar to their own, the court has to decide whether a reasonable person would be misled by the defendant's trademark or the get-up of their product. It has been held that "if only a moron in a hurry would be misled" the case is not made out.
In this context, yes, some UIs have to be usable by a moron in a hurry. Fire alarm? Gotta make it easy to use even if you get the occasional dipshit who pulls it for fun, because the alternative is tragic. That's why doors in public buildings have crash bars, the bars that go across the door that open it when someone crashes into them, because you have to assume eventually there will be a crowd of idiots in a hurry trying desperately to escape, and the crowd crush must open the door because otherwise it will kill people.
It's also because the UI of that drill is shitty.
They should write the words "TORQUE LIMIT (N*m)" next to that dial.
The people who have a mental model that allows them to understand what torque is and how it matters for drilling are the same people who will already know it's controlling torque, specifically torque of the head, controlled by a clutch mechanism. Nothing else makes sense.
And therein lies the problem of believing "good UI will solve everything". It will not give you an understanding of the problem domain. And an understanding of the problem domain will obviate many UI needs.
https://diy.stackexchange.com/questions/22219/what-units-are...
http://contemporary-home-computing.org/turing-complete-user/
(Sorry for the lack of HTTPS!)
I don't immediately know how to say whether the authors agree or disagree with each other.
I also agree with the comment that most people wanting to use a piece of software are very likely to have experience in the field and therefore things that aren't intuitive to a random person will be intuitive enough to them because of the domain. When we see a text box at top of a social media platform with placeholder text "what is in your mind.." we don't assume it's a note-taking app or a to-do list. We intuitively know what we put there will be published for the world to see, even though it might be the first time we are using that particular platform.
They used to come with plenty of documentation, and lots of third-party documentation too. A quick search for computer books reveals that the latter is still the case.
the computer skills of someone from 20 years ago will not easily transfer to the tasks someone who is new to computers faces today
Perhaps if by "computers" you mean "smartphones", then I agree, but the basics of how to use a mouse and keyboard haven't changed in 20 years. 20 years ago was the era of Windows XP, and many of its UI paradigms --- which are at least a decade older --- still apply today to Windows 11, although a lot of it has been unnecessarily obfuscated and destroyed by designers-gone-wild.
Incidentally, I once heard that part of the drill called the "norris".
We don't? We have dedicated F1 help button, onboarding tutorials and ultimately google? Yes, this is very insufficient, but that's true for the power drills as well, have you read those manuals? Tried to find one online?
(tangentially, using trick questions to gauge common understanding of UI isn't a great approach, this isn't SAT, it's easy to have the correct enough model "the number on the drill is more power" to work in practice, but mistakenly think this is represented as speed. Also, why do you need to know whether the torque is for the motor or the head? But there is enough space to put the word "torque" in the interface to make it more intuitive (and add a QR code to some awesome intuitive video guide))
Software that is very enjoyable to use as you gain more intimacy with it is Ableton, which is used for music production. When you first see it, you're likely to think it looks dated and not too sophisticated. However, as you grow in your knowledge of how to access various features, you come to appreciate that it has been designed exceptionally well. For software that someone will spend significant time using, the goal should be a low barrier to entry and a high skill ceiling.
Why can't we blame the complete lack of documentation? One cannot RTFM if they're never given it. Peeling off safety stickers and clicking buttons with trial and error does not count as documentation.
You can make a drill without the clutch/torque adjustment, and it will be simpler to use but less capable. Or using the car example, knowing how to manually select gears gives a greater level of control over the vehicle, but most modern drivers don't know/care enough to learn.
The trend is moving decisions/control away from the user. Precisely because it's easier to allow Apple or Google to make all the decisions, rather than learn, manage and maintain things. Users don't understand a CLI any more than they understand a manual transmission. If we want these things to exist, education must be in the mix.
There's a joke that goes "Unix is a very user friendly OS; it's just picky about its friends." And the truth behind that is that Unix -- what Stephenson called the Hole Hawg of operating systems -- works in a way that's fairly straightforward and understandable -- or it was for a 70s/80s OS. But like the industrial-strength drill it is very powerful and will do exactly as instructed -- even if that will harm you or your work if sufficient care is not exercised in its use.
So a lot of what we call "ease of use" comes in the form of guardrails that protect the ignorant from themselves -- like the torque setting on the drill -- or features which were designed for particular use cases and don't make much sense in the general case. My favorite example is the percent key on a calculator, which works in a way that completely violates my mathematician's intuition for percentages. Like I'd expect to be able to express 30% by typing 3, 0, % and getting 0.3. And on a scientific calculator that's exactly what you might get. But on a normie's calculator, the percent key works completely differently: it serves as a substitute for the = key, except it takes the second operand as a percentage of the first operand. It's good for calculating tax, tips, and discounts -- and almost nothing else. Like 6% sales tax on an item costing $15.87 would be 15.87 + 6 % . And a 15% discount on a $23.44 item would be 23.44 - 15 %.
If you want to be the next Apple, stop to think about the tasks you envision normies doing with your thing and build around those tasks, making them stupidly easy, at the expense of a cohesive general system design. Of course you may miss and become the next Rabbit, but big risks yield big rewards.
I dunno where I'm going with this. It seems I've become as rambly and incoherent as the original article.
This analogy didn't make sense to me the first time it played, and still doesn't here. Somebody who doesn't know how to operate a drill won't touch the clutch, and the clutch isn't there to avoid hurting the user's hands in the first place. It's there to avoid over-driving fasteners. It is a function for enabling somebody who does know what they're doing to work faster; you can prepare a fastener by keying in the clutch on the first couple before going on autopilot to drive screws to predictable depth without worrying about feathering the trigger or trashing the screw head from cam out.
I like your point, but to be fair, Apple is one of the absolute last companies I would accuse of having an incoherent system design philosophy.
If you can't even proofread your own writing, why would anybody waste their time reading it? Blocked the site so I don't make the same mistake again.
Things that weren’t intuitive become intuitive after you gain enough knowledge and skill.
The bit on the end of a tape measure is similarly designed and ignored.
To me, it's not even intuitive if I'm supposed to try and answer the question or not.
However:
> 3. Yes, it adjusts the torque of the head
Is not, in my opinion, a good answer.
I would suggest "Yes, it limits the torque of the drill.", or even "Yes, it limits the amount of torque the drill applies to the bit." I would also remove #1 (or consider both #1 and #3 to be correct). Many users would think that is what is happening, and, quite frankly, it doesn't matter whether or not they know what's going on, under the hood.
The user's mental model is really important; much more important (IMNSHO), than the mental model of the developer. Discovering and reinforcing user mental models is a really important part of UX design (In my experience). I have found that it is better that I adapt to the user's mental model, than it is to force them to adopt mine.
person 1: "we should make official documentation videos"
person 2: "nah, our users/community will create those for free for us"
Google seem to scarcely understand their own products, let alone know how to put across their functionality in a coherent way.
Another classic involves types of controls for a faucet, and the ambiguity around which operations mean more/less water versus changing the blend of a specific amount of water.
This is exactly what the adfarms (Facebook, Google, etc) want.
> I see a lot more value in community support, good documentation and accessible learning resources.
This is exactly what they don't want. This costs money.
I agree with the article, but unfortunately the incentives of the adfarms are not aligned with allowing users to learn for themselves. Gotta keep them engaged so they can look at ads instead, which means things must be brain dead simple.
That sort of experience is why I don't begrudge people paying "extra" for Apple products (and do so myself). Apple put the legwork in to actually try and document their products in a friendly way, and provide support to users who need it.
Figuring out features of Google products seems to require random web searches and YouTube videos, because they don't appear to care about their customers' outcomes more than a second after they've handed over their money. Apple just... has how to guides on their website. The end.
-- Bruce Ediger (probably)