[HN Gopher] The user is on their own
___________________________________________________________________
The user is on their own
Author : ColinWright
Score : 43 points
Date : 2024-05-02 08:27 UTC (1 days ago)
(HTM) web link (www.selfawaresoup.com)
(TXT) w3m dump (www.selfawaresoup.com)
| skybrian wrote:
| 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.
| mfuzzey wrote:
| 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.
| Aachen wrote:
| 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
| csours wrote:
| 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.
| avg_dev wrote:
| Interesting take.
|
| 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
| passion__desire wrote:
| 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"
| mfuzzey wrote:
| 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.
| klooney wrote:
| > 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.
| passion__desire wrote:
| 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.
| amatecha wrote:
| unfortunately that convo probably goes like this:
|
| person 1: "we should make official documentation videos"
|
| person 2: "nah, our users/community will create those for free
| for us"
| IAmPym wrote:
| 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.
| arp242 wrote:
| 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.
|
| [1]: Previous: https://news.ycombinator.com/item?id=39013418
| Animats wrote:
| 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.
| fuzzy2 wrote:
| 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.
| CoastalCoder wrote:
| > 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.
| petsfed wrote:
| 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.
| arp242 wrote:
| 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.
| beeboobaa3 wrote:
| Some people are just dense. It happens. Not everything needs to
| be designed to accommodate them.
| beeboobaa3 wrote:
| > 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.
| readyman wrote:
| > _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.
| Animats wrote:
| 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.
|
| [1] https://xkcd.com/2117/
|
| [2]
| https://www.volpe.dot.gov/sites/volpe.dot.gov/files/docs/Hum...
| pdonis wrote:
| _> what mathematicians call "obvious"_
|
| 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. "
| dheera wrote:
| > Yet even at this low level of complexity the device is not well
| understood by man of its users.
|
| It's also because the UI of that drill is shitty.
|
| They should write the words "TORQUE LIMIT (N*m)" next to that
| dial.
| groby_b wrote:
| 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.
| AlexandrB wrote:
| 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.
|
| https://diy.stackexchange.com/questions/22219/what-units-are...
| amatecha wrote:
| No judgement or anything, but there are a lot of typos in this
| post. A couple offhand , though there are more:
|
| "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"
| coreyp_1 wrote:
| Is this proof that it's not AI generated?
| internet2000 wrote:
| 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.
| Aachen wrote:
| 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?
| amatecha wrote:
| 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. :\
| bschmidt1 wrote:
| Kind of a tough read, felt a bit like dancing around a point or
| not quite getting to one. It seems like the author learned how to
| use a power drill recently then quizzed a random chat on how they
| work (something he didn't know 5 mins before), then concluded
| that the UX is not good based on those results. Might be just the
| wrong audience, both the author and those in the chatroom might
| not be the target customer of the power drill, and whoever the
| target customer is might prefer clear numbers on a dial like that
| - probably because of paradigms set forth in power tools.
|
| 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.
| marcosdumay wrote:
| > 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.
| scyzoryk_xyz wrote:
| Setting the poor drill example aside, as someone versed in
| video and audio editing software, I would point out that none
| of it is intuitive before you learn it.
|
| 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.
| ChrisMarshallNY wrote:
| 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.
| jameshart wrote:
| 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.
|
| Most power drills _come with instructions_.
| 1970-01-01 wrote:
| >"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.
| schoen wrote:
| Somewhat related could be Olia Lialina's essay "Turing-Complete
| User" (2012)
|
| 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.
| satisfice wrote:
| Intuitive mostly means that you already have the requisite
| knowledge and skill to operate the product.
|
| Things that weren't intuitive become intuitive after you gain
| enough knowledge and skill.
| zzo38computer wrote:
| 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.)
| Kharacternyk wrote:
| I've never before gone 4 levels of parentheses deep whilst
| reading text that isn't programming code.
| idle_zealot wrote:
| In both prose and code this level of nesting indicates that a
| reorganizing of ideas is in order.
| Karellen wrote:
| > The only "intuitive" interface is the nipple. After that it's
| all learned.
|
| -- Bruce Ediger (probably)
| synackrst wrote:
| 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.
| sonofhans wrote:
| Ooh, that slow start sounds nice -- what drill is it? My
| Festool saw also slow starts, and I love it, but I don't have
| their drill.
| petsfed wrote:
| 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.
| 4star3star wrote:
| 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.
| Terr_ wrote:
| > 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.
| Karellen wrote:
| I have used a power drill more than once before, but it doesn't
| have "the number setting" like the one in the picture does.
| (Instead it has a single toggle labelled "900" and "2400" - as
| well as the on/off trigger)
|
| To me, it's not even intuitive if I'm supposed to try and answer
| the question or not.
| sonofhans wrote:
| Bruce Tognazzini said, "The only intuitive interface is the
| nipple. Everything else is learned." After watching a premature
| baby struggle to breastfeed, Bruce was wrong -- there are no
| intuitive interfaces. Everything is learned.
|
| 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.
___________________________________________________________________
(page generated 2024-05-03 23:00 UTC)