Making things easy is a competitive advantage for consumer products, so it’s natural that many companies try to make their products more “intuitive.”
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.
Intuative for new users is often less efficient for experienced users so for many complex professional tools that will be a core part of the users' work it probably makes sense to go for the less intuative but more efficient tool and provide training.
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.
Also consider what they say in the last paragraph though:
> 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
Can I try it and see what will happen in a non-destructive way? How long does it take to try it? How apparent will the change be? How apparent are the configuration points?
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.
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.
I was watching debate between Robert Sapolsky and Daniel Dennett on free will. Robert pulled the rug out under Daniel's by saying, "Daniel is agreeing with me on the easy cases where it is easy to pin point a failure by a person to his brain tumour but the environment, both internal and external, always determine a person's behaviour in all cases and hence empathy must be extended to all people irrespective of whether we can explain it or not"
Using computers is now a basic necessity for life in modern societies, on par with reading and writing.
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.
Not really. You can still pay your bills with checks and file your taxes on paper and make doctor and dentist appointments by phone. Sure computers offer convenience but are not essential especially for a person who grew up without them.
> And there is no worrying about the quality or correctness of generated code.
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.
That is an argument for using an ORM (or similar) to define the schema. I agree it is probably the biggest single advantage.
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.
The last point is so relevant. There are no official Google video tutorials on how to use their apps or their services. Almost all of these are created by others in their native language. One would expect an official one from them.
Apple gets a lot of shit, but the one thing that they do exceptionally well is making things discoverable, putting their UIs in plain language (so e.g. something irreversibly destructive is specifically and clearly called out as such) and having abundant clear, well-written step by step instructions. Say what you like about them, but they put in the work to try and make their products approachable.
Google seem to scarcely understand their own products, let alone know how to put across their functionality in a coherent way.
At some point I need to write an article about this topic. I disagree with a lot of the conclusions about that article.
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.
A lot of software doesn't really follow the business/consumer model though, and is either outright public infrastructure or de-facto public infrastructure. Something like train ticket machines are a good example – I don't know what the current situation is because I haven't been there in years, but for a long time the train ticket machines on the Dutch/German border were a completely unusable mess of confusion. How can you mess something like this up so badly? I don't know, but they did. And then there are things like tax services, e-identity services, and all of that, much of which is far more complex, and easier to screw up.
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.
Some tools are very standardized. Basic modern lathes are all very similar to Maudsley's original precision lathe, which is in the Science Museum in London and worth a look. Someone who knew how to use Maudsley's original lathe would be able to use a modern non-CNC lathe with about five minutes of checking it out.
But faced with a basic modern 3-axis CNC mill, they'd be totally lost.
Haha, oh yes. Ever had a project where, at some point, the (key) users said “but Excel”? Well, you better listen to them. Sure it may be great for the layperson to edit a building’s layout visually. But know what? The expect just wants to enter the coordinates. In a grid, using only the keyboard.
I’ve had so many projects where we took users for fools. Boy did they fail.
> You aren't making a lathe for someone with no experience.
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.
I said it elsewhere, but one of the first things I learned about power tools, from my father, is that if you don't know how to use a tool or tool setting, you don't use it.
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.
Power drills are pretty benign to the operator as long as they know not to try to use the drill bit as a router or sander. I've seen plenty of people try to knock off an edge with the side of a bit. Sure it can be done, but its also a great way to have it jump and catch the side of your hand.
You can also easily break your wrist with some of the stronger ones that are available. I've also had one wind-up part of my work glove on accident. And the big plug-in drills are just terrifying in general, with how much rotational inertia they have. I won't touch those.
Easy to say, but working on a house framing/electric/plumbing project for 8+ hours I would rather have the gloves on. With a lathe or mill, of course I'm not gonna wear gloves.
Pretty benign until an idiot holds a small piece of sheet metal in one hand and drills it with the other. Guess how I know :)
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.
Planers aren't so bad once you get into power feeders, which can be gotten as cheap as $500 with a DW735. (Yeah you can get a power feeder for a table saw too; it's $500 and more like $1500 just for the feeder!)
The others: very, very yes. Very yes. Jointers too. Jointers exist to show malice.
Ah I mistyped there, jointers are actually what I meant rather than planers! I use hand planes when jointing boards and forget that power planers aren't that fancy.
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've had knots thrown back at me by my planer before. That was before I upgraded to the DW735 with those power feeders and a much deeper body to keep the cutters further away from the human, though.
I have a reasonably safe checklist and set practice for my jointer and I still don't trust the thing.
Even "standard" tools have dangers. I was wearing gloves to protect my hands and was using an impact driver to loosen a nut... and I tapped the trigger, tool ran, my glove wound around the socket and pulled my finger in. Hurt my finger, luckily didn't break/permanently damage it. Took a second. I wouldn't have predicted.
How do you prevent your bare hand from getting abraded when it accidentally brushes up against the sanding belt, drill bit, or other fast moving parts of the tool? Yes, I know, exercising caution is always a great idea, but accidents do happen, right?
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?
Few years back in was in a parking garage and the lady in front on me kept pressing on the screen to get her ticket, with increasing power and frustration. It wasn't a touch screen. There were buttons on the side.
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.
> 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.
> 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 and eliminates a lot of creative potential through locked-down apps and systems.
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.
> This is exactly what they don't want. This costs money.
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.
They're still just an american bigcorp with fascist tendencies that's going to fuck you. At least Google lets me run my own software on my own hardware without getting permission from anyone.
>Figuring out how to post a photo to Instagram should require very little cognitive thought while working out how to do your taxes by yourself, even if the process is really well-designed and optimized can take some time and work simply because there’s a lot more variables in that case. Unless bot hare literally 100% automated, these two things are just not going to be on the same level of required effort, no matter what.
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.
From the article: "I don’t have an clear actionable answer to these issues and this piece is more of a rant than anything" Not too helpful, then.
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.
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 am willing to bet that this change would achieve approximately nothing.
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.
I'm not sure there are relevant units here for most drills. Most drills just have numbers from 1-n regardless of how much torque they can put out. There are calibrated torque drivers out there that can limit to a specific torque, but most hand drills just seem to have a relative measure of torquiness.
The drill example isn't great at all. My immediate guess was that the higher numbers give the drill more power. How it does that (torque/speed/etc) is irrelevant, as long as it drives a screw that's not going in at a lower number. That's the job to be done.
The whole post seems like giving up. It is possible to make things easier to understand in context.
It seems to me you're precisely proving their point. The drill section starts with:
> 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?
One of the problems with the question was the answers you had to pick from.
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.
I had a similar reaction--I know exactly what that dial does, my reaction was "it determines how hard the drill will screw something in until the front part starts going tick-tick-tick."
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.
Today there is another top post on HN that's like "50 years of PC OSes" and that's the history I think about when I notice how poor and obtuse a lot of modern software is. It's been half a century and still we get totally convoluted and poorly-abstracted interfaces for the software we're either paying good money for, or generating good revenue for the vendor by using. I mean, the reason is obvious - "what's the shortest path to ship something that will do what we (or our users) want, and be profitable?" - but it's disappointing to see almost zero divergence from this apparent inevitability. :\",
This is a conversation close to my heart, and I'm glad to see it discussed.
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.
I do love the implicit assumption here that the only possible way to learn what the numbers on a power drill do is to either 1) guess, 2) be shown by an older sibling or similar, or 3) watch a video tutorial or something.
> 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
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.
>“a person using this thing should be able to work it out with reasonable effort”
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.
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 (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), and I have never operated a radio scanner before), but having good documentation is better.)
I love what you're doing with the parens but for those who find it difficult:
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.
To make things more complicated, I have a brushless drill where the clutch dial does actually adjust the torque of the motor -- torque limiting is done entirely in software, and the ring electrically sets the limit. Once you hit the torque limit, the drill gives a small amount of "force feedback" and cuts power to the motor until the trigger is pulled again.
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.
It's an old DeWalt from 2013 (!) - DCD995. I'd expect most of the high end brushless drills from the major tool manufactures to have this feature now, though. Check the manual for something like "electronic clutch" if you're looking at a model and not sure.
And that's all presupposing that your use of the drill is in the regime where motor torque matters. If you're consistently driving decking screws into pressure treated lumber, then you don't touch that dial EVER. There's probably a subset of professional power drill users, who have used such a drill every day for years, who don't really touch that setting.
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.
I would guess it's often better to make a slightly more complicated interface if that is what provides the best experience for an adept user. If you need the interface to satisfy the needs of a user from the first minute they experience it with no effort on their part to become more skilled, then you sacrifice a lot.
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.
> I asked people what the rotary dial on a power drill does.
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.
105 comments
[ 4.9 ms ] story [ 185 ms ] threadIf 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
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.
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.
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.
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.
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.
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.
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.
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.
[1] https://xkcd.com/2117/
[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."
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...
"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"
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.
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.
Most power drills come with instructions.
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.
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.
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.
Things that weren’t intuitive become intuitive after you gain enough knowledge and skill.
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.
-- Bruce Ediger (probably)
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.
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.
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.