Minimalist Affordances: Making the Right Tradeoffs | Hacker News Reader

Minimalist Affordances: Making the Right Tradeoffs

lea.verou.me

93 pointsthm38 comments

I also have to point out that Stockholm syndrome is probably bullshit. From Wikipedia (https://en.wikipedia.org/wiki/Stockholm_syndrome#Stockholm_b...):

> According to accounts by Kristin Enmark, one of the hostages, the police were acting incompetently, with little care for the hostages' safety. This forced the hostages to negotiate for their lives and releases with the robbers on their own. In the process, the hostages saw the robbers behaving more rationally than the police negotiators and subsequently developed a deep distrust towards the latter. Enmark had criticized Bejerot specifically for endangering their lives by behaving aggressively and agitating the captors. She had criticized the police for pointing guns at the convicts while the hostages were in the line of fire, and she had told news outlets that one of the captors tried to protect the hostages from being caught in the crossfire. She was also critical of prime minister Olof Palme, as she had negotiated with the captors for freedom, but the prime minister told her that she would have to content herself with dying at her post rather than Palme giving in to the captors' demands. Ultimately, Enmark explained she was more afraid of the police, whose attitude seemed to be a much larger, direct threat to her life than the robbers.

I'm going to repeat this part for emphasis:

> the prime minister told her that she would have to content herself with dying at her post rather than Palme giving in to the captors' demands.

If someone told me I was going to have to become a martyr because it was unacceptable to let someone get away with a bank robbery, I would probably decide I liked the bank robber better, too.

Maybe the original story is bullshit, but there is something to the concept.

There are countless examples of people preferring something just because it's what they are accustomed with.

But that's not Stockholm Syndrome. It's more sunk-cost fallacy and inertia.

"better the devil you know than the devil you don't"

Thanks, that's much closer to the mentality of many people that are accused of having Stockholm syndrome: they value predictability above something with possibly unexpected results, that might be better or might be worse. The fact that they can't see that this is limiting them to never escape their situation is harder to see.

What's been bugging me recently is buttons and controls all over the titlebar. Sure, it looks snazzy, but what am I supoosed to grab when I want to move the window? That tiny 5 pixel space between all the extra stuff and minimize?

You grab it by the buttons I assume. If your pointer is slow, it doesn't move much and your click is fast, then it's a click, if your pointer is fast, moves a lot, and does the drag-release thing, then it moves the window.

Seems a very fragile solution

> You grab it by the buttons I assume.

At least on Mac, you'd assume wrong.

I don't have the slightest idea what "slow" and "fast" pointers are, but you can only drag the parts that aren't buttons.

It's genuinely annoying because every time you want to drag one of these windows, you have to carefully think about moving the pointer to a specific area that is draggable.

Of all of the terrible UI trends that have come into vogue over the past few years, this has to be be absolute worst.

You're supposed to use a proper window control and grab ~60% of your window area right at the center with some prefix (e.g., a Windows button) instead of precision-hunting for those pixels at the top

> There are several color models with a more human-centered design, such as HSL, LCH, OKLCH. Their coordinates are designed around how humans describe colors, such as hue for the main color (e.g. red, yellow, green, etc.), chroma/saturation to specify how intense the color is (e.g. 0 would be gray), and lightness to specify how light it is (e.g. white would be 100% and black would be 0%).

This is less convincing when you realize that HSL (for example) also uses numbers to describe hue, so you still have to memorize the order and positions of different hues. Is that a big deal? Nope, but it's not as perfectly human-friendly as the author makes it out to be.

> have to memorize the order and positions of different hues.

Almost everybody is familiar with the rainbow, and it's a physical real-world relatable concept. Even if you can't name the color order from memory, it's intuitive what changing the hue left or right does. Unlike RGB, where it's basically impossible (for regular people) to predict what changing one component will do to the final color.

Interesting -- I've never thought about 0 = red, 60 = yellow, 120 = green, 180 = cyan/aqua, 240 = blue, 300 = purple as being user-unfriendly (simply because RGB is so much worse), but you make a good point.

What if CSS allowed hue to be defined as positions between any 2 adjacent options out of the 6 primitives defined by 60° increments?

E.g. bright orange could be either of:

  hsl(50% red yellow, 100%, 50%)
  hsl(50% yellow red, 100%, 50%)

While bright red-orange would be either of:

  hsl(25% red yellow, 100%, 50%)
  hsl(75% yellow red, 100%, 50%)

There's probably a more intuitive syntax to describe "25% of the way from red to yellow" that I can't think of.

And I think I'd be in favor of just six primitives. Using 30° increments would allow orange, but none of the other five positions have obvious names at all.

The worst example of the Github problem shown here, in my opinion is illustrated by the changes that Apple has made to its window design over the last few versions of MacOS. Previously the top of a window, with all of its control was easily distinguishable. In today's incarnation - presumably in the cause of elegance and minimalism, it is really hard sometimes tio distinguish the top of the window chrome from its contents.

For me this becomes a problem when I'm working with a mess of overlapping windows. I cannoy tell you the number of times I've tried to click on a window, only to find that I've actually clicked the window behind and above it.

Irksome.

I really like the points about symbols to the end, but am not sure the Music notation hits the right note. The symbols - besides Quarter note - for a rest/not playing are intuitive to almost every learner. They are just so different, so square, so alien compared to the notes in melody, that you don't make the mistake of playing a rest note in general.

Yes, it's hard to learn the symbols that involve playing something (especially clefs and timing not being linear - see: https://www.youtube.com/watch?v=Eq3bUFgEcb4 for an amazing "documentary" on notation systems), but often finding the pitch/right note is the larger challenge (for beginners) than understanding the meaning of notes. Is this because we do not teach people to play songs with only one note, but many rhythms? I don't know.

But I do not think the point of affordances in notation is a great example, especially given all the alternatives (see the video above) which, although in some cases clearer (e.g. a instrument-morphic notation), struggle in other ways (too much space used, too unable to represent timing, not transferrable between instruments, etc).

The reality is also that our mind can adapt easily in such distinct systems as music notation to shifted realities. Sheet music for different instruments sometimes uses the same clefs, bars and all, but is several notes a part (eg... the music of Violin and Viola are notated differently, such that the notes of the respective instruments more or less span the whole bar without going too far above or below for the extreme notes of the instrument). Musicians usually have no trouble learning this abstract switch, even though the affordance, is just one symbol at the beginning of each bar - the groove of playing a different instrument adapts it. I know this does not seem the case for UI, which are perhaps just "too similar" to each other and merge and feel unnatural, or maybe the issue is that while using a new UI - like the github comment selector being expanded - other sites may keep the old UI and confuse our mental model of afforances - but for music, it's just not the problem I see modelled in the article...

> are intuitive to almost every learner

what intuition would a learner rely on to understand the difference between the 1 and 1/2? or 1/2 vs 1/8?

For notes, every visual element you add halves the duration

The rests are shaped similarly to their respective notes.

It is quite intuitive.

> halves the duration

There is already an argument in the article that you didn't address

> Yet absolutely nothing in their representation signifies this. Nothing in the depiction of ♩ indicates that it is longer than ♪, let alone that it is double the length.

Also, the elements are different (half adds vertical line, quarter - a filler, eighth horizontal lines), so you can't rely on any intuition, just memory. And this isn't true for stops, where even this simplest thing breaks down

Halving is a convention. Why is north up on maps? This is one single bit of information that defines the system.

You don’t need to discern what the relationship is because there is ONLY ONE relationship

The visual progression of the note types is designed to be high contrast up to a point; at some point you run out of space and you have to add flags.

It’s similar to the Chinese tally mark system. Every progression uses a different DIMENSION up to a point

Now you've gone from being unable to explain why you think there is intuition to just defending the lack thereof

> You don’t need to discern what the relationship is because there is ONLY ONE relationship

Of course you do, because what you care about is NOT discerning the relationship, but discerning the VALUES that relationship represent. So the convention isn't helpful, you still need to remember (without relying on intuition) what each mark represents

That's a pretty good rundown of the issues with affordances, in modern UX.

I will be forwarding this article to the designer for the app we're in the process of testing.

Surprisingly [not], a lot of the feedback has been that people don't know how to do very important things.

In my experience, graphic designers expect users to admire the UX, as opposed to use it.

There is "minimalist" and the "sweet spot", aka the reasonable spot.

For instance, in the "web context" (should be a good language here on HN):

For tons of online services, a noscript/basic (x)html is doing a good enough job, and that at a technical cost cosmically cheaper than Big Tech web engines (geeko/blink/webkit), not mentioning their beyond sanity SDK.

In general, you cannot talk about "minimalist" without talking about "bloat-ist". Ofc, Big Tech and its minions will fight that, since planned obsolescence and absurd and grotesque size and complexity are their bread and butter.

The musical notation is an especially brutal example of something bad that persists for ages

The hex colors are also awful, but even the newer HSL type of system doesn't go far enough to be convenient - the hue shouldn't be some magical wheel where you have to remember at whch exact point each color is located, you already remember rainbow letters from your childhood, those should be used (then you can add numbers to signify deviation from the pure hue)!

> Whether or not it’s not an A/B test, I’m really hoping that GitHub is collecting enough metrics so they can evaluate the impact of this design on user experience at scale

Why would you hope that if there isn't even an easy feedback mechanism? Metrics can't read your mind like that

P.S. Tangentially related, you can use your favorite editor with an extension like GhostText not to suffer a big part of the awfulness of all those text input forms with the added benefit that you are highly unlikely to ever lose your text again since if the web form misbehaves you'll still have a backup in the text editor temp buffer

> Usability and aesthetics usually go hand in hand.

Hold on right there. In my experience, the two are in tension. Here is a number of “prettifications” that made UI harder to use:

- removing the underline in menu items: prettier, but now we don’t know which key to press to open the menu.

- removing the frame around windows: prettier, but now I don’t know if I’ll be resizing the window or pressing the “hang up” button that goes right to the edge.

- window title bars that no longer change color when in focus: prettier, but now I don’t know which window has focus.

- buttons without a 3D effect or even a border at all: prettier but now we don’t know what is a button or not.

"Case in point: The new Github comment UI is beautiful. Look at how the text area smoothly blends with the tab, creating an irregular and visually interesting shape! ...

The new GitHub commenting UI, focused. Am I the only one that expected the focus outline to also follow the irregular shape?

However, I cannot for the life of me internalize that this is a text field that I can type in. Even after using it over a dozen times, I still have to do a double take every time (“Where is the comment field?!”, “Why is this read-only?”)."

User interfaces are not primarily works of visual art. They are beautiful only when they are functional.

> Usability and aesthetics usually go hand in hand. In fact, there is even what we call the “Aesthetic Usability Effect”: users perceive beautiful interfaces as easier to use and cut them more slack when it comes to minor usabiity issues.

This can be true, sure.

But the UI trends in software over the past few years have been so aggressively hostile to usability that I've come to associate pretty user interfaces with hard-to-use user interfaces.

> users perceive beautiful interfaces as easier to use

But what a one user regards as beautiful is regarded as ugly by another and they both disagree with the creator about how useful it is.

And some interfaces that outsiders regard as very ugly are beautiful in the sense that they are supremely useful to a skilled user.

Over the years that i worked on applications for designers we had to repeatedly explain to incoming computer science graduates that the user interface was deliberately crammed full of information, that it was no accident that the type size was the smallest that was readable. The users could glance at one screen and see without thinking about it that the design was good.

I am happy I am not the only person that got confused by GitHub recent UI change. I prefer my widgets more obvious.

The whole rising sun design motif in the header is pretty rough to see. In countries like Korea, it's viewed in a very negative way. It's like someone rocking a confederate flag around.

I thought it looked great. In fact, I was inspired enough to spend several minutes trying to figure out how the author had done it.

I feel like these particular examples don’t convince me.

The new GitHub UI seems better to me. It looks nicer. I like looking at things that look nice. And I think it’s obvious that you’re supposed to type in there.

Same deal with X. The interface is so simple, I’m not sure how you don’t understand that you’re supposed to type there. They’re using minimalism for an interface that was already minimalist, it seems like that makes sense.

> Another example, entirely outside of software, is music notation. You’ve likely learned it as a child, so it’s hard to remember what the learning experience was like, and if you regularly read music sheets, you may even believe it’s easy. But if we try to step back and examine it objectively, it’s highly unintuitive.

Music notation is an alphabet. You read music like you read a book. Similarly, in an alphabet, there's nothing signifies that B is after A, or K can't produce a sound by itself.

It's highly unintuitive, too, but we learn it.

Maybe we need a better alphabet, or maybe the article is a bit of a stretch. I don't know.

Well yes, that's exactly what the article says. The point is that these musical notation symbols have an objective, mathematical relationship, which could be mirrored in their graphical design ... But isn't. That's a missed opportunity.

They are very much mirrored in the design. The premise is incorrect.

Would you mind explaining, then, how the half rest, quarter rest, and eighth rest symbols indicate the temporal relationship they have with each other?

It’s pretty telling which symbols you chose. The relationship between half notes, quarter notes and eighth notes is obvious.

The rests are shaped similarly to their note counterparts. Eggs are bars; stems are sticks; flags are the same just facing different directions.

I confess I did choose the non-obvious symbols to illustrate the article's point that those symbols are non-obvious.

We agree that some of the symbols have clear visual relationships. The article suggests it would be nice if all of them had such relationships. Instead, we have what looks like a random agglomeration of symbols, of which a few happen to make sense.

Reply on news.ycombinator.com