Hacker News Reader

Comment by mholt | Hacker News Reader

The flat UI trend baffles me. The removal of text from icons and buttons baffles me.

For example, in Windows 11 I spent close to a minute looking for "Rename" in the right-click menu in Windows Explorer. Turns out it's not there! It's been removed out of the flow of the list and put in the top of the right-click menu, behind a small, picture-only icon that I've never seen before.

MacOS is guilty of this too: Buttons along the top of native apps like Finder don't have text anymore, the buttons are flat without borders, and the icons are thin lines. How is anyone supposed to know what they do??

In most UIs (Apple and Android in particular), I can't tell when one of those on-off switches is ON or OFF. Is the dark side ON or OFF? Maybe the light side is ON. Oh, it's the opposite when Dark Mode is enabled; great.

Bring back text. Bring back nice buttons.

View on HN

This is why I have reverted to the CLI whenever possible.

There's something deeply assuring knowing that I don't have to relearn my whole workflow every few months when the trends change. ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent.

All I want is to get work done the way I want, and I've found the CLI is increasingly the path of least resistance.

> ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent.

Those command-line tools don't have any "engagement" opportunities nor are there bloated teams of product managers & designers having to justify their salaries by reworking them for no good reason.

I regret to inform you that the latest release of `find` has been renamed to [magnifying glass emoji].

For example,

    # Find directories the old way.
    find . -type d

    # The cool new way!
    [magnifying glass emoji] . -[keyboard] [folder emoji]

Edit: HN appears to strip emojis, so my new edited comment doesn't pack the same punch.

I look forward to hieroglyphic CLI interfaces, where we compute like it's 2600 BC.

At 2600 BC hieroglyphs already included symbols used for phonetic spelling, so hieroglyphs are not the way to go if you want to get rid of spelled out words unless you ban the subset that can be directly mapped to greek letters[1]. Otherwise it just ends up a fancy font.

[1]https://youtu.be/NIxn9auks24?t=2009

That literally every ancient civilization went from pictures to words as fast as they could should say something about modern icon only design.

You jest, but I'm not sure that is a bad idea. bash/zsh seem happy with emojis as function/alias names, and I can input emojis easy enough. In fact some emojis are easier to type in my chosen layout than the string necessary to disambiguate completion for some commands.

Thanks for the idea, and I'll redirect co-worker scorn at U+1F984 for `git push` towards you ;)

Edit to add: Using emoji for commands/arguments is actually quite workable with global aliases or custom zle widgets in zsh, and moderately workable by using $INPUTRC to specify text replacements for readline if you're a bash user.

Had a developer change some config file names to emoji based file names. Boss thought his computer was broken when he took a look at some output txt file. He wasn't amused even though it was April 1.

similar c++ proposal from April 1998: https://www.stroustrup.com/whitespace98.pdf

> ls, grep, find, ps, htop will always be what they are.

SystemD screwed with a few that I'm still discovering one by one. "cron", "shutdown" is no longer in the default debian path, I think ulimit was another one.

But at least I don't wake up one morning with the whole interface rearranged.

cron is in /usr/sbin (and is a daemon, not a command you'd ever run manually); shutdown is in /sbin; and ulimit is a shell builtin, not a standalone executable at all.

If I had to guess, I'd say that /sbin and /usr/sbin aren't on your $PATH for some reason. systemd is unlikely to be the culprit.

sometimes even cli tools go away. eg: ifconfig

They still exist on BSD! But yes it has gone away on Linux.

Huh Til that ifconfig is deprecated. I still use it periodically, but my work laptop is on 18.04

It can be restored with the `net-tools` package, thankfully. That's among my first installs on a Linux box. Never quite got into `ip addr show` when I've most of the ifconfig flags memorised from use.

Which may contradict my previous point slightly, but at least it is easy to put the system back into a state I want and the system will maintain this state.

This. Material design relies on the browser hint to inform you the mouse/pointer has moved to an active element. Viewed with no focus on an active element, how are you meant to tell which pane of flat colour is a pressable, actionable element?

It looks great in print. It doesn't respect the modality of use for an online world.

I'm tempted to think we have to go to browser vendors and ask them to make <blink> happen..

This resonates so much with me .. especially the On/Off buttons where designers show off how cool and smooth they can make them look, usability be damned. Dark patterns especially around opt-ins uses these type of controls very well putting a lit of mental load on us to opt-out.

I ended up reverting back to the old context menu. Those icons are annoying to parse and I have a tendency to look down each row as 20+ years of context menus has taught. And having so many options tucked an extra click away.

In macOS, you can actually right-click many header bars (like Finder) and choose "Icon and Text" instead of "Icon" for what shows.

I do this, but I do not want to do this.

Also it looks funky. The padding is messed up and the text doesn't fit.

There's also an accessibility setting (under the "Display" section) for "Show toolbar button shapes".

>> There's also an accessibility setting (under the "Display" section) for "Show toolbar button shapes".

Fascinating. Sounds like if you can't read the mind of the desinger you must have a disability. What a great attitude :-p

1. Accommodating disabled people is in no way an insult.

2. Being disabled is a normal fact of life, also not an insult.

3. Accessibility affordances are not only for disabled people. Lots of people who wouldn’t identify as disabled routinely and gladly use a wide variety of accessibility features.

4. Having difficulty identifying actionable elements like buttons isn’t about reading anyone’s mind, and it isn’t a universal difficulty regardless of their presentation. The ability to customize it so it’s easier for you is inherently an accessibility affordance.

5. It’s entirely possible this setting (along with several others under accessibility) may be more helpful when needed if they were available in another location, but it’s also possible that would make the experience more confusing, and quite possibly for more people—especially for disabled people.

6. People may benefit from this information—quite a few here based on other comments—and it doesn’t deserve this kind of negativity.

7. With all of that in mind, while I’m keeping this response direct, I took the last point as a prompt to edit some of my own negativity out of it. I had a strong negative reaction both because I think accessibility is a universal good and because I appreciate accessibility affordances which help me. But that’s not a reason for me to be a jerk either.

1. Accommodating disabled people is in no way an insult.

No, but treating non-disabled people as disabled could be. Just like offering help to some disabled people triggers them.

I was going to respond to these numbered points in turn, but that'd be silly. My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice. To put it under the accessibility options can (if we're even a tiny bit snarky) be seen as an insult - possibly to disabled people as well since it lumps a simple standard usability thing in with stuff designed for people with actual challenges.

It's also not cool for them to make critical UI cues an option when they also take away themes which are the ultimate option.

Ultimately they have given no valid reason to make so many things look the same when they used to be visually (and functionally) distinct.

Sorry for the trigger, I didn't mean any insult to anyone other than the UI designers.

> No, but treating non-disabled people as disabled could be. Just like offering help to some disabled people triggers them.

Putting this option in accessibility settings does no such thing. That assumption is what I take issue with, and what prompted all of my points above.

> My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice.

I disagree. I often find designs with fewer borders and shapes easier to use—that is, more accessible to me—_because_ there’s less information for me to visually process to find what I’m looking for.

That said, I’d be perfectly fine if they inverted the default… or even just asked on first install/startup, with a note on where you can change it later if you change your mind.

I read the parent as implying that it's the designer who is thinking of “disability” as a begrudged requirement that is afforded an out-of-the-way configuration option so as to not inflict the ugly affordances on the rest of the population.

That seems like the least charitable interpretation of the facts I can imagine. Nonetheless if it’s true, Apple doesn’t just wing it when someone goes rogue on full design language redesigns.

This is honestly a large part of why I enjoy keyboard shortcuts, like F2 to rename on Windows. But it’s of course also a low grade for their UI design because I like it for knowing how to reach it instantly. Unlike by using their user interface.

Reply on news.ycombinator.com