[HN Gopher] Interface ergonomics: automation isn't just about ti...
___________________________________________________________________
Interface ergonomics: automation isn't just about time saved
Author : makuto
Score : 58 points
Date : 2021-10-13 01:05 UTC (1 days ago)
(HTM) web link (macoy.me)
(TXT) w3m dump (macoy.me)
| intrepidhero wrote:
| > Cakelisp was a revelation because it was my chance to escape
| from these limitations. I had to pay my time in order to make
| something I consider better, but it was absolutely worth it. I
| was now in charge of the interface. I shaped the language, the
| language didn't shape me.
|
| We are tool makers, making tools that we use in tool making so
| that the act of making tools for our tools is more enjoyable.
| caseyross wrote:
| > Automation not only saves you time, it changes what you do.
|
| This bears repeating. When you automate a task, you often push it
| over a "breakpoint" where it suddenly makes certain things
| profitable in terms of effort. For example, say you fill up a
| water bottle and place it within arm's reach, instead of running
| to the tap every time you're thirsty. You save maybe 10 seconds
| per sip, but the real win is that you can now consider behaviors
| like "drink water every 5 minutes" that previously you would have
| considered too much effort.
| mumblemumble wrote:
| In the software development realm, the biggest spot I see
| automation paying off is when it fosters consistency.
|
| To take an example from operations: To me (admittedly speaking
| from the developer side of things), the overwhelming benefit of
| containerization has nothing to do with elasticity or scaling
| or really any of the marketing buzzwords. The real benefit is
| that Docker and friends encourage presenting a much more
| consistent management surface to the operations team. In the
| short run, this is just the price of automation. In the long
| run, this greatly reduces the mental burden of understanding
| how all the individual pieces are configured and deployed.
|
| Most of that was never anything but incidental complexity. I
| doubt that ops's job has actually become any easier over the
| past 20 years. But, even so, if they're spending less time just
| shaving yaks, that suggests that a greater proportion of what
| they're doing is genuinely valuable.
| bravetraveler wrote:
| As someone in operations, totally this. Consistency is the
| biggest thing.
|
| I've worked with plenty of wizards that can figure
| anything/everything out, but these deviations have a hidden
| cost.
|
| The farm of resources no longer behaves like cattle, it's all
| pets - with their own identities, personalities, etc.
|
| Containers abstract most of this away, a simple runtime and
| any host can be just like another with a tiny amount of
| automation.
|
| We get things like scale from this, but if it 'works on your
| machine' but not ours, we're no further.
| [deleted]
| d0gbread wrote:
| As a UX practitioner with engineering experience, I'm happy to
| see an article like this, but also a bit disheartened that in
| 2021 it's still a revelation for many that frustration,
| satisfaction, and cognitive load are key considerations in
| prioritization in addition to raw efficiency.
| bluGill wrote:
| How can you live? I took two classes in UX in college 20 years
| ago. I still can't walk into a kitchen without cursing the bad
| UX of the stove.
| kwhitefoot wrote:
| Are you implying that all stoves in all kitchens are bad? At
| least that's what it looks like you are saying.
| bluGill wrote:
| Almost without exception. There is no way of knowing
| without careful study which burner will turn on when you
| turn a knob. (generally you know the side, but not
| front/back) Every time I move I need to figure out a
| different stove, and so I'm often turning on the wrong
| burner because I have the wrong habit. Most people think
| "opps, I'm stupid again" when that happens, but I have
| enough UX background to know that the real problem is the
| UX is terrible.
| sapsan wrote:
| Sounds similar to the consequences of reading Don Norman's
| <<The Design of Everyday Things>>...
| bluGill wrote:
| That book was part of my classes
| tolmasky wrote:
| Something that seemed somewhat implicit in this article, but
| never fully stated, is that it also increases _the quality_ of
| the work, or in other words, decreases the probability of bugs
| and errors. Every time you do a manual process, you introduce the
| possibility for a lot of human error. That 's where a lot of the
| "willingness" vs. "unwillingness" comes in (aside from just the
| "time" aspect, or partially as a _cause_ of the "time" aspect).
| The more boring the task, the more likely you are to sleepwalk
| through it and not be thorough in checking things. This leads to
| bugs, and can either (ideally) increase the time of the task
| since they immediately surface and then you are "shaken awake"
| and have to dig around for what you mistyped, or in the worst
| case, go in undetected. Like everything computers do, and kind of
| the whole point of programming, a script can go into the task
| with the same "willingness" every time. That weird edge case you
| found when you did the task the first time when it was still
| interesting can get coded in and checked for. Future weird bugs
| can then be trivially added to the automation script vs. just
| noted as a "WARNING" in a README that will never get read. If
| there's no existing tool, then the activation energy to create
| that tool just to account for that weird thing that happened that
| one time is always beyond the "fuck it, let's just make a note"
| boundary. As such, it's best to just bite the bullet in the
| beginning. The unfortunate thing is that this is really a
| indictment of our workflows in general. Much of what we do is so
| close to programming as it is, it sucks that "putting it into a
| literal program" can be such a chore (and it very much is).
| lmilcin wrote:
| Another important is that automation can solve the problem of
| passing the knowledge (on how to do something).
|
| This happens when the person that uses the automation no longer
| needs to learn how to do the task.
|
| Teaching people is actually extremely expensive even if you
| forget about reliability of entire process.
|
| People have limited ability to learn stuff. So being able to
| automate certain tasks not only allows people to do more in
| less time or do it better, it can actually allow doing more
| things that the person would ever be able to learn, without
| need of learning.
| solarmist wrote:
| Not only that, but they can use the automation (assuming it
| was written for others to read) to teach themselves if
| needed/desired.
| jonjlee wrote:
| >This is an example of an unethical interface. One week of
| programmer time would have easily saved multiple weeks of
| designer time...
|
| >When developing things which have a human interacting with it,
| you should consider how much you value your life time, and have
| empathy for your users' life time.
|
| Well articulated. Outside of software and technology, people have
| to use software tools that they have little control over - tools
| assigned for their job. When authors take the time to understand
| how their tools are used, it can have a profound impact on the
| daily work for a huge number of people.
|
| For example, I interact my electronic medical records system
| between 2-5+ hours each day. To write a document requires 15
| mouse clicks, with a 1+ second load time after each click. It's
| painful. I would use the author's words to describe this as an
| unethical interface. If the devs who wrote this software had to
| use it for their daily work, I imagine that they would demand new
| tools or leave in frustration. But for us, as users without a
| choice, it contributes to dissatisfaction at work and ultimately
| to burn-out.
| solarmist wrote:
| Hmmm, not sure I agree. They might just think this is how it is
| (in "their" industry). Like the elementary school teacher who
| thinks math is hard.
|
| Often those devs have subpar development environments too and
| don't know to look for better or does not have the skills/time
| to up level themselves.
| ajuc wrote:
| Another thing is - automation is documentation. It might just be
| three 1-line bash commands that you have as muscle memory that
| you do once a week - so there's no time save.
|
| But automation will save you a lot of time and stress if you had
| long vacations or worked on a different project for half a year.
| Suddenly the muscle memory isn't there and you have to learn the
| hard way AGAIN if it's not automated.
| Jensson wrote:
| As you make something cheaper demand for it goes up. Easy to
| forget about it when you try to calculate the value of
| automation. I'd say in most cases automation pays off if you do
| it properly, not to do the intended task but to do all the
| unintended tasks, reusing the automation code for later, reducing
| errors from manual work and opens up doors for new product design
| paths in the future.
|
| This assumes that you actually own the product, if you don't own
| the product and just have a job to do then why bother about
| saving time, so in this case you should still automate it because
| automation is more fun.
| hinkley wrote:
| We had a build process that took half an hour, so people only
| ran it a couple times a day. I cut it to fifteen minutes,
| saving half an hour a day per person.
|
| Then I cut it to 7 minutes, saving an additional 40 minutes,
| because everyone was now running the build 4-5 times a day.
|
| What I really saved was wasting each other's time and goodwill
| by reducing the frequency and severity of people checking in
| broken code that blocked everyone else. Because they were
| expected to test more often, and they made smaller commits
| because it wasn't so painful.
| mjw1007 wrote:
| Right, so we have a number of advantages of automation that
| aren't captured in a simplistic time calculation like the "Is
| It Worth the Time?" XKCD:
|
| - if you can do something more quickly you might also choose to
| do it more often
|
| - automation can reduce human errors
|
| - once something is fully automated it can be used as a
| building block in a larger piece of automation
|
| I can think of one more:
|
| - automation can make it easier to hand over work to someone
| else, or increase the number of people who are able to do it
|
| But also one disadvantage:
|
| - automating something can lose a human "sanity check" (for
| example, you could generate reports full of missing data and
| maybe nobody will notice for a while)
|
| Any more?
| Jensson wrote:
| > - automating something can lose a human "sanity check" (for
| example, you could generate reports full of missing data and
| maybe nobody will notice for a while)
|
| Yeah, you shouldn't automate things that you don't know how
| to automate. Don't use ML for automation for example.
___________________________________________________________________
(page generated 2021-10-14 23:02 UTC)