melodysium

openness without sacrificing usability

a friend shared this article, and it sparked some thoughts and critiques:

We Made Technology Easy to Use - That was a mistake.

i recommend you read the article before this post, it'll make more sense.

usability is still important

the article neglects to mention more about the downsides of "low usability", enough that it hurts its later points about openness. I think that technologies which don't require systems thinking to interact with them are a very good thing for accessibility. i.e. jyn.dev post: operators, not users and programmers.

I very often reach for systems thinking, but I believe most people don't, and shouldn't have to. if a technology requires systems thinking to interact with, you get divides like users/programmers, you get implicit discrimination, you get a means of exclusion.

the article briefly acknowledges that "usability principles have indeed transformed the world for the better in many ways, and to an incredible degree." but then for the rest of the article it comes across as holding the attitude that "usability should not be a constraint". usability will always be a constraint. it's the thesis of the 80/20 rule. it's the fundamental factor impacting quality of life in limited_human_energy / cost_of_using_technology = human_capability. I wish the article more directly attacked the opacity of a tech rather than just saying "simplicity bad".

different goals for different purposes

the article also confuses technologies we use for task completion vs personal fulfillment.

at the end of the article, it lists examples of people reaching for creative / technical / physical interactions, implicitly suggested as "what we should be doing instead". examples include:

  • IKEA furniture & "the IKEA effect"
  • film photography
  • self repair
  • "a complex vacuum coffeemaker, the complexity of which is its primary appeal."

a quote about that coffee-maker starts, “For the coffee-lover, [it] adds fun and pleasure to life". but I wouldn't call myself a coffee lover. I have an espresso machine which requires two button presses to get a shot of espresso, and I love it for its simplicity. as a professional computer toucher, I have some apps set to startup automatically, many extra icons on my menu bar, and a clock set to show seconds. I'm sure that coffee lover would rather have a default laptop than mine.

you can't take the design goals of a product for specialists and impose them on products for generalists. they're used for entirely different purposes!

openness, within the constraint of usability

I strongly agree with the article about making technologies open, but I wish it actually examined how to achieve openness while still maintaining usability. I think it should be reasonably easy to open up an interface, as long as it's an opt-in way which is unintrusive to a standard user's experience. I agree that there are many downsides of tucking away complexity (hidden influence, confusion for edge cases and power users, higher cost to tinker or adapt, internalized feelings of "i couldn't understand how this works"). but again, usability is still a constraint due to the massive accessibility and empowerment gained by letting the majority of people do a thing easily.

I like the article's mention of "seamful design". I agree that it's bad for systems to actively prevent exploring their internals for those who seek it out. I really wish the article examined "how can we pursue seamful design without sacrificing usability?" to me, that's the most interesting question. how do you balance "keep the interface simple" vs "let people explore other capabilities"? how do you avoid the problems of annoying popups saying "Let me guide you through our website's new interface!"? how do you balance "FYI, you can also use X to do Y..." with "X is unnecessarily cluttered and hard to navigate"?

I think these are steps in the right direction:

  • seamful design, as in the article - a simple interface, with support for the curious user who wants to learn or tinker with its internals. <detail> elements, hover text, interchangeable elements, re-sealable cases.
  • distinguishing different types of docs, like in the Divio Docs framework
  • better recognition and empowerment of product managers, UX designers, and documentation writers