Seams

And not only is it so well written, but details one of my biggest fears. “Buy n Large knows best.” Terrifying. @adactio

@ShaneHudson Oh, pshaw! You’re too kind.

Seams

Every extension is also an amputation. Thoughts on seamlessness in technology design by @adactio http://adactio.com/journal/6786/

@adactio yes, I’ve read your article. Agree with some of the points. Still think it’s not as bad as you put it for average users.

@adactio Chrome, Safari and FF have been greying out URLs past the domain for a few versions, and no one batted an eyelid.

@adactio what of URL shorteners, the URL equivalent of mystery meat? I would rather see the full URL, but I don’t think it’s disastrous.

@hornetweb You honestly don’t see the difference between “greying out” and “removing completely”?

remysharp.com/2014/05/04/on-…

@hornetweb URL shorteners are the QR codes of the web. Pointless, obfuscating, machine-centric pieces of shit.

archiveteam.org/index.php?titl…

#webdevelopment clagnut timoarnall Yes!adactio.com/journal/6786 — Jeremy Keith (adactio) September 7, 2016

#webdevelopment owencm Here we go again… adactio.com/journal/6786 — Jeremy Keith (adactio) October 2, 2016

Buy n large knows best. Patronizing, overbearing #google

twitter.com/adactio/status…

wow. Hadn’t seen this piece, extremely prophetic. Lots to think about here.

Given that Google Search are beginning to remove URLs from search results (not even showing domain names!), this thing I wrote five years ago might be worth revisiting: Seams. adactio.com/journal/6786 adactio.com/notes/16063

This is so annoying! Why does @google do this?! 😡

Jeremy Keith adactio.com/journal/6786 reminds that improvements in the user interfaces can lead to a situation where tool replaces essential parts of thinking. When people no longer have to think what they are doing (or can’t see the process), a lot of other issues are created.

Good to re-read this. Great reminder how UX can turn evil.

I haven’t seen Google results with hidden URLs yet. That’s horrifying

I use the urls in search results all the time, I’m sad to hear they might be removing them.

Duck duck go everybody. duckduckgo.com

Web browser usability: “Hiding information away makes me less able to make decisions: it makes me a less informed user. Putting less information in the location bar makes the location bar less useful and thus there’s less point paying any attention to it.” adactio.com/journal/6786

For many years now, the rallying cry of digital designers has been epitomised by the title of Steve Krug’s terrific book, Don’t Make Me Think. But what happens when that rallying cry is taken too far? What happens when it stops being “don’t make think while I’m trying to complete a task” to simply “don’t make me think” full stop? — Jeremy Keith, “Seams”

Steve Krug’s book “Don’t Make Me Think” is a wonderful book. Unfortunately, I’ve often seen its contents narrowly distilled to a slogan revered as the great commandment of software design: don’t make people think.

Have you heard of the the cognitive reflection test? It’s a test “designed to measure a person’s tendency to override an incorrect ‘gut’ response and engage in further reflection to find a correct answer.” More from Wikipedia:

According to Frederick, there are two general types of cognitive activity called “system 1” and “system 2” (these terms have been first used by Daniel Kahneman). System 1 is executed quickly without reflection, while system 2 requires conscious thought and effort. The cognitive reflection test has three questions that each have an obvious but incorrect response given by system 1. The correct response requires the activation of system 2. For system 2 to be activated, a person must note that their first answer is incorrect, which requires reflection on their own cognition

Here are the three questions from the test:

1. A bat and a ball cost $1.10 in total. The bat costs $1.00 more than the ball. How much does the ball cost?
2. If it takes 5 machines 5 minutes to make 5 widgets, how long would it take 100 machines to make 100 widgets?
3. In a lake, there is a patch of lily pads. Every day, the patch doubles in size. If it takes 48 days for the patch to cover the entire lake, how long would it take for the patch to cover half of the lake?

The intuitive answers are:

1. 10 cents
2. 100 minutes
3. 24 days

The correct answers are:

1. 5 cents
2. 5 minutes
3. 47 days.

What’s interesting, Malcolm Gladwell points out in his book David and Goliath, is that there is an easy way to raise peoples’ grades on this test: make the test questions difficult to read.

The psychologists Adam Alter and Daniel Oppenheimer tried this a few years ago with a group of undergraduates at Princeton University. First they gave the CRT the normal way, and the students averaged 1.9 correct answers out of three. That’s pretty good, though it is well short of the 2.18 that MIT students averaged. Then Alter and Oppenheimer printed out the test questions in a font that was really hard to read—a 10 percent gray, 10-point italics Myriad Pro font…

Translated to digital, that would mean a question that looked roughly like this:

What happened when the questions received this kind of visual treatment?

The average score this time around [went up to] 2.45. Suddenly, the students were doing much better.

Wait, but I thought we were supposed to not make people think? Present things to people clearly and simply and they’ll do better. Why is the opposite happening here? The typographic treatment of the question made reading difficult. You likely had to squint, possibly even read some words (or the entire question) multiple times. Interacting with the question in this way required you to stop and think. It made you work. Gladwell comments on this interesting result of the study:

As Alter says, making the questions “disfluent” causes people to “think more deeply about whatever they come across. They’ll use more resources on it. They’ll process more deeply or think more carefully about what’s going on. If they have to overcome a hurdle, they’ll overcome it better when you force them to think a little harder.” Alter and Oppenheimer made the CRT more difficult. But that difficulty turned out to be desirable.

Look at that: purposefully making something more difficult turned out to be desirable.

A Product Example

A little while ago, I knew some folks building a product touted as an “anonymous job platform for your ideal next role”. I was able to get a sneak peak at using the app and one of the things that struck me was how difficult it was to use. Not “difficult” in a human/computer interaction kind of way, but rather in a critical thinking kind of way. It was hard because it required me to stop and think. It required introspection. I half-jokingly noted to the the designer in my feedback “I probably thought harder…when creating a profile than most any other time in my life.” He responded by saying, “We heard that same feedback…I’m loving that part of it. I think we’re gonna try to encourage that even more.”

What I found ingenious about the product was that it didn’t shy away from being difficult. Again, it’s not that the product was difficult to understand or the UI tricky to use. No. In fact, the UI and instructions were quite clear, helpful, even empathetic to the task at hand. There were moments of suggested pause, followed by probing questions meant to draw out the best kinds of thought, which would then power the product to deliver the best kinds of value.

After more use of the product, I wrote my feedback to one of the owners:

[To do this right] I realize that I’d really need to sit down and think about:

1. What do I want? And not just a general “what do I want out of life?” but a very precise set of details “I want to be doing this kind of work, on this kind of team, with this kind of business”…

[I think you’ve done a] really good job on the way the app makes me think. I found myself multiple times thinking “this is too hard. You people who made this app, you’re making me think too much!” But then an inner voice said “hey stupid, this stuff that’s hard, it’s for YOU. It’s for YOUR benefit. Are you telling me you don’t want to work hard for YOURSELF? You get what you put into it.” And then I was like “ok I’ll spend whatever amount of time this takes.”

Turns out, this “disfluency” I was picking up on was a kind of intentional friction by the product designers, one of whom responded to my feedback in this manner:

We’re hearing similar things from other folks. I’m a little scared we’re gonna lose people because it is difficult, but that might be OK? It’s the antithesis of most internet things these days. Instead of go-go-go, fast-fast, more-more, we’re asking [people] to slow down, take their time…[I think we’ll] reiterate as much as we can that…it’s OK that it’s hard.

Conclusion

Why am I writing all of this? I don’t know. I guess as a reminder to myself. “Hard things are hard”. Great software allows people to do the actual thinking of the task at hand. If computers really are a “bicycle for the mind” we should make sure we don’t remove what makes bicycles great: human-powered motion. Too often our propensity is to make software that turns bicycles into motorcycles: all that’s required of you is to twist your arm on the throttle and boom, automated motion.

The removal of all friction should’t be a goal. Making things easy and making things hard should be a design tool, employed to aid the end user towards their loftiest goals. As @dhh has stated

Instead of always chasing the erasure of friction, it’s worth thinking about how friction can help people

I recently read an article by Eric Bailey where he calls attention to how libraries and frameworks create their own conventions and patterns that are distinct from their standardized equivalents.

He references an example on Twitter where someone noted you can use the <details> element to “create a native HTML accordion,” to which someone responded: “this works without Bootstrap? 🤯”

What’s the problem here? From Eric:

the problem that arises from this situation is that it teaches people to think and work framework-first. When that happens, the hard-won, baked-in interoperability and, importantly, accessibility of the [web] platform is thrown away. It’s a compounding problem, as well: The more people don’t use the elements made available to us, the more the notion exists that they’re irrelevant.

This is a great insight that I’d like to explore more.

Libraries and frameworks try to fix, or at least fill the gaps, where platform APIs are lacking. Because they fill gaps, that’s a kind of tacit acknowledgement that native web APIs aren’t sufficient.

Having modern browser APIs lag behind modern libraries and frameworks is how we’ve chosen to build for the web. I think it’s worth explicitly acknowledging the downsides to that approach, one being: because web APIs don’t always provide what people need, they’re more likely to use a framework. This leads people to think “framework-first” as they build, which means they tend to think “platform-last”.

Eric continues:

This is a moment of weird friction on the web. The platform continues to shift from a document-based model to an application-based one…

In treating HTML like a compile target, I wonder if we’re turning people who are HTML-literate into the equivalent of engineers who can program in Assembly.

This resonates for more than HTML. It increasingly feels like all web languages—HTML, CSS, and JS—are compile targets.

HTML is a compile target from authoring in WYSIWYGs, Markdown, or some other raw data source compiled through templating.

CSS is a compile target from authoring in Sass or Less. Or it requires some build tool or processing to work on your project, like PostCSS or Webpack. Or you can avoid cascading style sheets altogether and compose styles in JavaScript.

JS is a compile target for almost anything these days. You can author in next generation ECMAScript and compile. Or author in a JS superset like TypeScript and compile. Or author in a different language altogether like Ruby and compile. And I haven’t even got to compiling framework-specific syntax yet, like JSX for React or SFCs (single file components) for Vue.

And we have’t even arrived at WASM yet.

It’s ironic that one of the early signals of pride and craft for building on the web was “handcrafted” HTML and CSS, something altogether now replaced by the cryptic output of machines.

Christian Hielman covers ground on this whole topic in his article about teaching HTML and CSS:

The information [about] what an HTML document needs to even allow the browser do its thing isn’t exciting.

But it is important. Not teaching HTML by explaining what it means and does results in people re-inventing it.

We’ve all seen DIV/SPAN constructs that are, in essence, an anchor. And they fail to be keyboard accessible. Then people add some ARIA and a tabindex to make them accessible. Well, not really. It is more important to not flag an automated accessibility test fail than making it accessible.

His point being:

We keep getting back into the “add whatever is needed to get to the result quickly” mode. The mode we learned when we got introduced to HTML/CSS as a technology stack to paint on the web.

HTML often gets written as part of a transaction: write something, anything, and see a result. Use it to group words, hook into styles and interactions, or construct specific pieces of UI. This has almost nothing to do with communicating meaning and structure.

HTML often becomes scaffolding for building UI (for which few elements are needed) when it was designed to be markup for outlining the meaning and interactivity of content (for which many elements are needed). As Yehuda Katz noted on twitter:

HTML (especially when enhanced with ARIA) is humanity’s best effort to create a single set of portable semantics for the interaction patterns in computing.

Since frameworks and libraries live in a space designed for discovering and vetting browser API candidates—implicitly if not explicitly—then it follows that having transparent seams to the abstractions upon which they are built (HTML, CSS, and JS) would be logical. That might help people think more platform-first and framework-second.

In high school, I had a friend named Joe who owned a Honda Trail 110, a small motorcycle with enough history for its own Wikipedia page.

It didn’t go very fast (40MPH tops if you’re going downhill) but Joe rode that thing to school every day — or at least he tried, it often broke down on the way.

On those cold, winter mornings in the desert you’d find Joe striding into school five minutes before the bell rang. He’d take off his helmet, revealing a face flush red from the cold, then take off his brown leather bomber jacket he’d found at a thirft store, stuff it all in his locker, and head to class with the faint whiff of oil and gasoline in his wake.

It was so damn cool.

It made me want a Honda trail bike but my parents didn’t approve of motorbikes.

Fast forward twenty years and my moment came.

Right before the pandemic hit, I came across a local ad where a guy was selling his 1978 Honda Trail CT90 (the “90” classification meant it was even weaker than the “110” Joe had).

With three little kids to care for, my wife shared the “motorcycles aren’t safe” hesitancy of my parents. But this bike that couldn’t go more than 35MPH, which meant I was relegated to the back roads of town and desert trails. Being gutless was a feature, not a bug.

So I bought it, a 1978 Honda Trail CT90 in mustard yellow.

Yup, that is not a typo: 1978. 44 years old (at the time of publishing) — older than me! And, all things considered, it was in fantastic shape. To be frank, if I’m in that good of shape when I reach that age, I’ll be happy.

But being in good shape was a relative term for its age. It came brimming with its own idiosyncratic problems, the first of which became apparent the day I bought it. After buying it and driving it home it failed to start back up, so I went to the internet to troubleshoot the issue.

(I must admit here that I knew — and still know — basically nothing about motorcycles, which made owning a bike older than myself a bit tricky given its penchant for breaking down and needing constant work.)

A few forum posts later, I had diagnosed the problem as a battery issue (turns out the CT90 requires battery to start while the CT110 can kickstart without one, who’d have thought?)

That ended up being the first of many electrical issues to come.

Another time my bike quit on me south of town, leaving me stranded on a desert road. I later gave my buddy Joe a call asking for help to diagnose the issue. “Sounds like you have a short,” he said. He recommended I look at the wiring, starting at the battery, and following it back to the source. “The wiring on that bike is so simple,” he said, “That it shouldn’t take long to cover the entirety of the wiring and find the issue.”

So I tried it. And I quickly discovered the issue: a spot in the wiring where the outer casing had worn off and the electrical wires were exposed, intermittently touching each other and causing a short.

The fix didn’t even require a trip to the auto parts store. I went inside, grabbed some black electrical tape, wrapped it around the exposed part of the wiring, and the bike started right up, no problem!

Being able to repair the problems on that bike with such little know-how or experience made me reflect on the simplicity and elegance of such a simple piece of engineering. Everything I needed to know on that bike I could inspect myself.

Cars

Cars of my past had engine bays open to inspection. When you popped the hood, they revealed their inner workings to you.

For example, here’s what the engine bay of my first car looked like:

But now-a-days, modern cars seem to encourage a hands-off approach. When you pop the hood, everything’s covered and hidden away, almost as if to say, “No need to go any further. Don’t bother concerning yourself with anything under here.”

I wonder if there’s a metaphor in here for websites? Are they following a similar arc?

In the beginning, the mechanisms of the web were more evidently surfaced by browsers for manipulation by end users — protocols, URLs, custom stylesheets, etc. — but those have increasingly been abstracted away such that you don’t have to even think about how the web works to use it. Here’s Jeremy Keith on the subject:

Making it harder to “view source” might seem like an inconsequential decision. Removing the ability to apply user stylesheets might seem like an inconsequential decision. Heck, even hiding the URL might seem like an inconsequential decision. But each one of those decisions has repercussions. And each one of those decisions reflects an underlying viewpoint.

Ah yes, “view source”, the website equivalent of popping the hood on a vehicle. At one point, the utility of “view source” on a website felt akin to troubleshooting my 1972 CT90: inspectable and decipherable, even if you didn’t know much.

But time has led it to become much more like popping the hood on a modern vehicle: the inner mechanisms remain hidden away beneath coverings that seem to speak, “This is too sophisticated to worry yourself with, best to consult a professional.”

Abstracting away URLs would be similar. As Devine notes, giving people power over the technology that rules their lives requires going beyond providing mere solutions and instead fostering the production of knowledge.

Like owning that CT90 did for me — or owning my own website has too.