Bring Back Idiomatic Design (2023)
essays.johnloeber.com483 points by phil294 15 hours ago
483 points by phil294 15 hours ago
In text boxes in some applications, enter submits the entered text, and ctrl-enter forces a newline (not at my computer, but I think Slack does this). In others, it's the other way around (pretty sure GitHub does this for comments).
I don't know how we got here and I don't know how to fix it, but "bring back idiomatic design" doesn't help when we don't have enough idioms. I'm not even sure if those two behaviors are wrong to be inconsistent: you're probably more likely to want fancier formatting in a PR review comment than a chat message. But as a user, it's frustrating to have to keep track of which is which.
Decades ago, Return and Enter were two different keys for that reason: Return to insert a line break, Enter to submit your input.
Given the reduction to a single key, the traditional GUI rule is that Enter in a multiline/multi-paragraph input doesn’t submit like it does in other contexts, but inserts a line break (or paragraph break), while Ctrl+Enter submits.
Chat apps, where single-paragraph content is the typical case, tend to reverse this. Good apps make this configurable.
Before that, page-mode terminals used <Return> to move to first field on a subsequent line (like a line-based <Tab>) and sent the page only on <Enter> or <Fn-key>. This made for quick navigation w/ zero ambiguity.
Microsoft teams: not as bad as people say, except for this situation.
I have accidentally sent so many messages trying to get to a new line.
Carriage return and line feed go way back. Tty stands for teletype. A computer was the job description of a person.
It’s turtles all the way down.
What lower turtles were there? My impression was that teletypes were the first proper keyboard-based interfaces.
The telegraph was keybased - only one key so I can't call it a keyboard, but in other ways it is what you are asking about.
don't get me started on backspace vs delete...
not just that ... plenty of web apps (and maybe desktop native ones too, though I don't notice it as much there) use "smart-delete" - if the cursor has a character after it, the delete key deletes it, but if not, it operates like backspace (which ought to be labelled "delete prev").
Teams does both - normally it’s Enter to submit and Shift+Enter for a new line, but when you open the formatting tools it switches. They at least do have a message indicating which key combo inputs a new line, but it still gets me on occasion.
I have a very mild jolt of anxiety every time I want to enter a new line in Teams or Slack, wondering if it will send a half completed message I will need to edit after the recipient has seen the half completed message, or it will enter a new line like I want it to.
The behavior also changes if you start editing a numbered or unordered list. Maybe that enters the "formatting tools" mode you mention?
If you're worried about this, consider a copy and paste from notepad.
Note the "very mild" jolt, not quite enough to rise to the level of switching to Notepad (or Emacs in my case).
Teams is insane. You want a new entry in a bulleted list? Hit the enter key. If you dare.
I had managed to be on Slack exclusively for at least 10 years. Recent acquisition has me using Teams and it's hilarious to see for the first time what people have been complaining about. I thought surely people are exaggerating. No, no they are not.
It only took a couple weeks for me to figure out that I would have to compose longer messages somewhere else and then paste them into Teams.
Unfortunately, some markdown renders differently when copied in vs when typed directly in teams.
Teams also respects some standard markdown, like italics, but not others…like bold.
MS is amazing in their ability to fuck shit up for no apparent reason. Like making a media player that doesn’t use space for play pause…
Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.
The Signal desktop app does both too, I guess, but in a way that actually makes sense. Enter sends a message since IMs tend to be short one-liners. Shift-Enter inserts a line break.
But if you click an arrow on the top of the text box, it expands to more than half of the height of the window, and now Enter does a line break and Shift-Enter sends. Which makes a lot of sense because now you're in "message composer" / "word processor" mode.
In Slack it can get even worse.
If you turn on Markdown formatting, shift+enter adds a new line, unless you’re in a multi-line code block started with three backticks, and then enter adds a new line and shift+enter sends the message.
I can see why someone thought this was a good idea, but it’s just not.
It’s kind of modal editing. Your 99% is enter to send because it’s a chat program. You’re sending mostly quick messages where adding a chorded input to send is just adding extra work to that mode.
When you enter a code block, that assumption changes. You are now in a “long text” mode where the assumptions are shifted where you are more likely want to insert a new line than to send the message.
I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context. Pressing tab in a table or spreadsheet will navigate cells instead of inserting a tab character. Pressing arrow keys may navigate cells instead of characters in the cell. Pressing enter will navigate to the cell below, not the first column of the next row. It’s optimized for its primary use case.
I think if the mode change was more explicit it’d maybe be a better experience. Right now it is largely guessing what behavior someone wants based off the context of their message but if that mismatches the users expectations it’s always going to feel clumsy. A toggle or indicator with a keyboard shortcut. Can stick the advanced options inside the settings somewhere if a power user wants to tinker.
> I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context.
I don't have a spreadsheet software nearby, but I remember the cell is highlighted different if you're in insert mode or navigation mode. Just like the status line in Vim let's you know which mode you're in.
Nice solution for this might be:
Ctrl+Enter: Always submits
Shift+Enter: Always newline (if supported)
Enter: Reasonable default, depending on context
This is a lot of pain.
It is very easy to fix. Add button somewhere around text box. Which turns it into multiline text edit control, increases its height. Now <Enter> works as line feed and to submit the text user have to click "send" button. Most of chat messages are not multi-line, but few are and for them, proper edit UI is essential.
I, personally, just use separate text editor like Gnome Text Edit to compose my message and then Ctrl+C/Ctrl+V to send it.
Thats funny because I thought it was shift-enter that creates a newline in a field where an enter submits. Just shows the fractured nature of this whole thing.
I've found Shift+Enter to do this pretty reliably across systems whatever they've chosen Enter / Ctrl+Enter to do.
It even works inside bullet points to add separate lines as part of the same bullet.
This is my thinking. Ctrl-Enter is usually "submit the form this input is a part of" in my experience, especially if you're in a multilinear text input (or textarea).
I've seen Enter, Shift-Enter, Ctrl-Enter, and Alt-Enter, (and on macOS, Cmd-Enter and Option-Enter), depending on the application. Total circus. I think this is actually a weakness of the standard keyboard: Keyboards should at the very least separate "submit form / enter" from "newline / carriage return" with different physical keys, but good luck changing that one, given the strong legacy of combining these functions.
Today I’m thoroughly confident that if I sit in front of an AI chatbot/TUI/whatever. I will invariably fail at knowing which key combo sends the input and which enters a new line. It’s maddening.
I don’t understand why we ever let plain Enter send a prompt out.
Slack requires shift+enter to create a new-line, while in JIRA shift+enter creates a new-line instead of new paragraph, creates all sorts of confusing layout issues, and because the difference is invisible, it's hard to to figure out where/when you've made this mistake of using shift+enter instead of just enter.
Nearly drove me insane, until I developed separate muscle memory between the two apps/sites.
PSA: CJK input frameworks(IMEs) use both Space and Enter for doing Hanzi/Kanji. Naively rigging Enter in JS to send causes wrong homonyms and/or raw phonetic scripts to get sent. There are few ways to resolve this issue, of which the easiest is to just leave Enter to the operating system.
For Slack at least you have the option to change that back to use Enter for new line (which is what I do), but other software is not that generous. I think Grafana introduced yet another way, Shift-Enter to submit, that I alway mix up.
Sometimes it's shift enter too! I am having a hard time keeping this straight between applications.
macOS is slightly more consistent among apps that use system controls, but the more custom the app, or the more React Native or Electron it is, the less predictable it is
Infuriatingly, some apps try to be smart — only one line, return submits; more than one line, return is a new line, and command-return submits; but command-return on just one line beeps an error.
Years of muscle memory are useless, so now I’m reaching for the mouse when I need to be clear about my intent
So much is solved when developers just use the provided UI controls, so much well-studied and carefully implemented behavior comes for free
Using provided UI controls is consistent with how today's apps behave on mobile:
- For single-line text fields, pressing enter is an alias for submitting the form. - For multi-line text fields, pressing enter inserts a new line. There is no shortcut for submitting the form.
In mobile chat apps, the enter key inserts a new line, so you have to press the non-keyboard submit button to send a message. In mobile browser address bars, since they are single-line text fields, the enter key becomes a submit button on the virtual keyboard.
Anything which supports multi-line input shouldn't submit on enter it should submit on button press so anyone can use it instantly without learning or remembering anything.
Then make it easier for users to learn that they can enter more quickly with control+enter which you can advertise via tooltip or adjacent text.
Better that 100% find it trivially usable even if only 75% learn they can do it faster
That isn’t workable for chat apps, at the very least on mobile. And that’s the most-used text entry interface that users nowadays grow up with. So I think you need to make an exception for such applications.
Mobile makes this much easier actually, send can be a different button on the UI than the newline button on the touch keyboard without having to teach this to users. That's exactly how my phone is currently configured at least.
I don’t understand what difference you are seeing. On the desktop you would have a UI button as well, and likewise a key on the keyboard.
The difference I’m referring to is that Ctrl+Enter is arguably acceptable on the desktop, but has no equivalent on touch keyboards on mobile.
Regarding the UI button, the way many people chat they would consider it too much friction to have to tap a button above the keyboard for every send — more friction than Ctrl+Enter is on the desktop,
No one uses the UI button to send a message on the desktop though. Everyone just presses Return to send, which is the most common need, and then once in a while realise they need to enter a newline without sending, for which there isn't a button so they need to learn how.
Mobile doesn't necessarily have this issue because it can show the send button and the newline button at the same time and they're equally accessible.
Regarding your edit:
> they would consider it too much friction to have to tap a button above the keyboard for every send
My finger travels almost the same distance from the home row to hit the send button above the upper right corner of the keyboard as the newline button on the lower right. I've been doing this for ages.
Actually, I do. Or at least I do in very similar situations where for some reason there is no keyboard shortcut to submit from the input field, so I press Tab (which moves the keyboard focus to the submit button next to the text field) and then press Return or Space to press the UI button.
Regarding on mobile, I’m familiar with chat apps that require a UI button press to send, and consider it unnecessary friction. It’s a larger mental leap to have to leave the keyboard.
> It’s a larger mental leap to have to leave the keyboard.
I find this interesting! I've never considered myself "leaving the keyboard" on the phone as if I were task switching. When I'm done typing I flow directly to the send button and let the keyboard go. The fact that the button is above the keyboard makes no difference to me as long as it stays accessible.
This one has bitten me plenty of times, but the solution is what slack does: write underneath what you are supposed to do.
Apart from a chat interface, when should enter ever submit your text?
A single-line text box that has no possibility of multi-line text (so, not a chat interface), such as search, an address bar, something that's obviously "submit one item" (e.g. "submit a word"), etc.
In a multiline text box, enter should NOT submit the form. Chat interfaces violate this rule and it results in lots of premature chat submissions.
In single-text-input contexts, like search fields and the browser address field, and things like Save As dialogs. It’s the general expectation for dialogs with an OK or default button, just like Escape cancels the dialog.
The new idiom:
You are right, of course this is your account name! Do you want me to be keep you logged-in?
> _
Most software is not designed by intelligent and thoughtful people anymore. It is designed by hastily promoted middle manager PM/Product type people who, as has been mentioned elsewhere, simply were not around when thoughtful human interface design was borderline mandatory for efficiency’s sake.
There is incompetence and there is also malevolence in the encouragement of dark patterns by the revenue side of the business.
It’s amazing how many blank stares I get when I, as mobile engineer, tell stakeholders that we shouldn’t just implement some random interface idea they thought up in the shower and we instead need design input!
“But why can’t you just do it?” Because I recognise the importance of consistent UX and an IA that can actually be followed.
Just like developers, (proper) designers solve problems, an we need to stop asking them for faster bikes.
> “But why can’t you just do it?”
The answer should be "because users will hate it and use a competing product that's better designed".
A shame that it isn't actually true any more.
An underrated senior engineer skill is saving stakeholders from their own worst impulses.
Too many people think being good at designing a UI primarily means knowing where to put something on a page.
There's a time and a place for it. If you already know exactly what the program needs to do, then sure, design a user interface. If you are still exploring the design space then it's better to try things out as quickly as possible even if the ui is rough.
The latter is an interesting mindset to advocate for. In almost every other engineering discipline, this would be frowned upon. I suspect wisdom could be gained by not discounting better forethought to be honest.
However, I really wonder how formula 1 teams manage their engineering concepts and driver UI/UX. They do some crazy experimental things, and they have high budgets, but they're often pulling off high-risk ideas on the very edge of feasibility. Every subtle iteration requires driver testing and feedback. I really wonder what processes they use to tie it all together. I suspect that they think about this quite diligently and dare I say even somewhat rigidly. I think it quite likely that the culture that led to the intense and detailed way they look at process for pit-stops and stuff carries over to the rest of their design processes, versioning, and iteration/testing.
Racing like in Formula 1 is extremely different from normal product design: each Formula 1 car has a user base of exactly 1: the driver that is going to use it. Not even the cars from the same team are identical for that reason. The driver can basically dictate the UX design because there is never any friction with other users.
Also, turnaround times from idea to final product can be insane at that level. These teams often have to accomplish in days what normally takes months. But they can pull it off by having every step of the design and manufacturing process in house.
There exist other ways to do the research. „Try things out“ is often not just a signal of „we don‘t know what to do“, but also a signal of „we have no idea how to properly measure the outcomes of things we try“.
But that’s the point, no? Prototyping is useful but beyond a proof of concept, you still need a suitable user interface. I have no problems if there’s a rationale behind UI changes, but often we have stakeholders telling us to do something inconsistent just so their pet project can be presented to the user. That’s not design.
This is reductionist and myopic. I've personally been through building forms online and it's hell to try to find consensus on perhaps the most common forms used online.
Let's take a credit card form:
- Do I let the user copy and paste values in?
- Do I let them use IE6?
- Do I need to test for the user using an esotoric browser (Brave) with an esoteric password manager (KeePassXC)?
- Do I make it accessible for someone's OpenClaw bot to use it?
- Do I make it inaccessible to a nefarious actor who uses OpenClaw to use it?
I could go on...
Balancing accessibility and usability is hard.[0]
[0] Steve Yegge's platform rant - https://gist.github.com/chitchcock/1281611
This is the kind of thinking that takes a normal credit card form and makes it so weird that auto fill doesn't work.
All you need to do is use standard HTML form elements. None of those questions are even relevant, just excuses to increase complexity and make things harder for everyone.
Today I accidentally transposed the first two digits on my CC number.
The form programmer had done some super stupid validation that didn't allow me to edit it directly. Every change moves the cursor to the end of the input. More than 16 characters could not be typed.
Any person who codes that PoS should have their software license revoked and never be allowed in the industry again. Far better to use a plain text input than all the effort used to make users lives hell.
Why would you ever disable paste? It can only make it more likely that the user will make a mistake (and hate you for making the form harder to fill out).
The thing that winds me up about credit card input is that it won't let me enter it as it is written on my card, in groups of four digits.
The same applies to fields that expect telephone numbers. They should all accept arbitrary amounts of white-space.
If you don't allow me to paste a card number in I might well not buy from you.
Funny, I'd assume we'd got consensus on that one.
- Anyone who recommends disabling paste as a security feature is a fraud
- Doing UA sniffing is always a mistake
- If the user's browser doesn't support `autocomplete="cc-number"` then they're already used to it not working, you don't need to care about it
- You should always make your form as accessible as possible regardless of if the user is a robot or visually impaired
- Making your website intentionally inaccessible may be a federal crime in the USA as the ADA doesn't care what you think about openclaw.
Yeah most of these "issues" are surely caused by programmers trying to be too smart. The dumbest possible solution which messes around with the input at little as possible is almost always the best solution. Which implies the browser-provided elements are the best because they have probably been designed and validated more than you can do.
If I use an app and it fucks around with the cursor: instant hatred. It's just so annoying. And if you can't get basic human interaction done well in 2026, what else is messed up in your app?
Also, in the 2010s a lot of old guard UX designers got circulated out in favor of designers who either had backgrounds in other mediums (e.g. print) or were generalists with little understanding of user interfaces or technical capabilities. This didn't help matters.
UX is often done by graphic designers IME. They aren't the worst people to do it (generally better than developers), but not the best neither.
I'm in this comment and I don't like it
For real though, when UX became an actual official discipline wasn't too long before a lot of the arse fell out of graphic design and a load of them moved over. A lot of people from newer generations of UX/UI people are possibly worse, often just rolling out conventions wholesale with little thought. Hiding behind design systems and clutching Figma files like they're pearls.
Contrary to what the author says, actual idioms are more common than ever before. They've just cherry picked older examples. He's talking about an era of software where one of the Windows media player skins was a giant green head (No shade, I loved that guy) the real issue is in the superficial changes and the aforementioned lack of consideration when rolling them out
> Most software is not designed by intelligent and thoughtful people anymore.
Eh nostalgia/survivorship bias. Not saying that you're wrong about the shift to shoving it out door for a PM, but "nerd who is adamant THEIR layout is the only one" wasn't exactly the heyday of software design either.
I'm still of the opinion most people should get more comfortable with layers and smaller keyboards, but I've also met the linux nerds who swear the world NEEDS insert.
Yep, there's some bad incentives and some rushed work, but calling it mostly incompetence or malice kind of ignores how much the underlying system has changed
Cybernetic natural selection should take care of this over time, but the rate of random mutations in software systems is much higher than in biological systems. Would be interested in modeling the equilibrium dynamics of this
Software is now media, not tooling. Media tends to come with a lot of baked in perverse incentives.
>It is designed by hastily promoted middle manager PM/Product type people
As someone in the middle of arguing about API design and service boundaries in a complex system with a product manager right now, who has redesigned our full system's architecture and release roadmap himself, I wish it weren't true.
[flagged]
Would it be better to bring this up in the retro? We're getting sidetracked here. We could set up a meeting with the stakeholders.
As the author identifies, the idioms come from the use of system frameworks that steer you towards idiomatic implementations.
The system UI frameworks are tremendously detailed and handle so many corner cases you'd never think of. They allow you to graduate into being a power user over time.
Windows has Win32, and it was easier to use its controls than rolling your own custom ones. (Shame they left the UI side of win32 to rot)
macOS has AppKit, which enforces a ton. You can't change the height of a native button, for example.
iOS has UIKit, similar deal.
The web has nothing. You gotta roll your own, and it'll be half-baked at best. And since building for modern desktop platforms is horrible, the framework-less web is being used there too.
The author may have identified that "the idioms come from the use of system frameworks", but they absolutely got wrong just about everything about why apps are not consistent on the web (e.g. I was baffled by their reasons listed under "this lack of homogeneity is for two reasons" section).
First, what he calls "the desktop era" wasn't so much a desktop era as a Windows era - Windows ran the vast majority of desktops (and furthermore, there were plenty of inconsistencies between Windows and Mac). So, as you point out regarding the Win32 API, developers had essentially one way to do things, or at least the far easiest way to do things. Developers weren't so much "following design idioms" as "doing what is easy to do on Windows".
The web started out as a document sharing system, and it only gradually and organically turned over to an app system. There was simply no single default, "easiest" way to do things (and despite that, I remember when it seemed like the web converged all at once onto Bootstrap, because it became the easiest and most "standard" way to do things).
In other words, I totally agree with you. You can have all the "standard idioms" that you want, but unless you have a single company providing and writing easy to use, default frameworks, you'll always have lots of different ways of doing things.
Well, and worse, Windows was itself a hive of inconsistency. The most obvious example of UI consistency failing as an idea was that Microsoft's own teams didn't care about it at all. People my age always have rose tinted glasses about this. Even the screenshot of Word the author chose is telling because Office rolled its own widget toolkit. No other Windows apps had menus that looked like that, with the stripe down the left hand side, or that kind of redundant menu-duplicating sidebar. They made many other apps that ignored or duplicated core UI paradigms too. Visual Studio, Encarta, Windows Media Player... the list went on and on.
The Windows I remember was in some ways actually less consistent than what we have now. It was common for apps to be themeable, to use weirdly shaped windows, to have very different icon themes or button colors, etc. Every app developer wanted to have a strong brand, which meant not using the default UI choices. And Microsoft's UI guidelines weren't strong enough to generate consistency - even basic things like where the settings window could be found weren't consistent. Sometimes it was Edit > Preferences. Sometimes File > Settings. Sometimes zooming was under View, sometimes under Window.
The big problem with the web and the newer web-derived mobile paradigms is the conflation between theme and widget library, under the name "design system". The native desktop era was relatively good at keeping these concepts separated but the web isn't, the result is a morass of very low effort and crappy widgets that often fail at the subtle details MS/Apple got right. And browsers can't help because every other year designers decide that the basic behaviors of e.g. text fields needs to change in ways that wouldn't be supported by the browser's own widgets.
“Brand” and “branding” is arguably the most important thing -not- mentioned in the article. The commercial incentives to differentiate are powerful enough to kick a lot of UX out of the way.
Now that all we do is “experience” a “journey,” it’s more about the user doing what the app wants instead of the other way around
> First, what he calls "the desktop era" wasn't so much a desktop era as a Windows era - Windows ran the vast majority of desktops (and furthermore, there were plenty of inconsistencies between Windows and Mac).
That's overemphasising the differences considerably: on the whole Windows really did copy the Macintosh UI with great attention to detail and considerable faithfulness, the fact that MS had its own PARC people notwithstanding. MS was among other things an early, successful and enthusiastic Macintosh ISV, and it was led by people who were appropriately impressed by the Mac:
> This Mac influence would show up even when Gates expressed dissatisfaction at Windows’ early development. The Microsoft CEO would complain: “That’s not what a Mac does. I want Mac on the PC, I want a Mac on the PC”.
https://books.openbookpublishers.com/10.11647/obp.0184/ch6.x... It probably wouldn't be exaggerating all that wildly to say that '80s-'90s Microsoft was at the core of its mentality a Mac ISV, a good and quite orthodox Mac ISV, with a DOS cash-cow and big ambitions. (It's probably also not a coincidence that pre-8 Windows diverges more freely from the Mac model on the desktop and filesystem UI side than in regards to the application user interface.) And where Windows did diverge from the Mac those differences often ended up being integrated into the Macintosh side of the "desktop era": viz. the right-click context menu and (to a lesser extent) the old, 1990s Office toolbar. And MS wasn't the only important application-software house which came to Windows development with a Mac sensibility (or a Mac OS codebase).
I partially agree with you, but additionally there's a whole set of employees who would be clearly redundant in any given company if that company decided to just use a simple, idiomatic, off the shelf UI system. Or even to implement one but without attempting to reinvent well understood patterns.
One reason so many single-person products are so nice is because that single developer didn't have the time and resources to try to re-think how buttons or drop downs or tabs should work. Instead, they just followed existing patterns.
Meanwhile when you have 3 designers and 5 engineers, with the natural ratio of figma sketch-to-production ready implementation being at least an order of magnitude, the only way to justify the design headcount is to make shit complicated.
But every company I worked at in the past 10 years or so eventually coalesced around a singular "design system" managed by one person or a small core team. But that just goes back to my original point - every company had their own design system, and there is not a single, industry-wide set of "rails".
The bigger issue I see with "got to keep lots of designers employed" problem is the series of pointless, trend-following redesigns you'd see all the time. That said, I've seen many design departments get absolutely slaughtered at a lot of web/SaaS companies in the past 3 years. A lot of the issue designers were working on in the web and mobile for the 25 years prior are now essentially "solved problems", and so, except for the integration of AI (where I've seen nearly every company just add a chat box and that AI star icon), it looks like there is a lot less to do.
Conventions already existed in DOS (CUA) and MacOS. The point is, every operating system had its user interface conventions, and there was a strong move from at least the mid-1980s to roughly the mid-2000s that applications should conform to the respective OS conventions. The cross-platform aspect of the web and then of mobile destroyed that.
Yeah the author conveniently ignores the fact that the UX of Mac apps was radically different to that of PC apps, so it’s not that designers/developers were somehow more enlightened back then, it’s just that they were “on rails”
> Developers weren't so much "following design idioms" as "doing what is easy to do on Windows".
Most people only uses one computer. Inconsistency between platforms have no bearing on users. But inconsistency of applications on one platform is a nightmare for training. And accessibility suffers.
I don't disagree, but my point was about the author's incorrect diagnosis of the reason (and solution) for the problem, not that the problem doesn't exist.
As a sibling commenter put it, previously developers had "rails" that were governed by MS and Apple. The very nature of the web means no such rails exist, and saying "hey guys, let's all get back to design idioms!" is not going to fix the problem.
The web did have HTML and CSS, but as the author notes those have been bypassed for Web Assembly and other technologies.
Date picker and credit card entry should always always always use the default HTML controls and the browser and OS should provide the appropriate widget for every single web page. For credit cards especially the Safari implementation could tie in to the iOS Apple Wallet or Apply Pay and Android could provide the Google equivalent. This allows the platform to enforce both security policy and convenience without every developer in the world trying to get those exactly right in a non-standard way.
That’s not the only reasons. When you are used to how your operating system does things consistently, as a developer you naturally want your application to also behave like you’re used to in that environment.
This eroded on the web, because a web page was a bit of a different “boxed” environment, and completely broke down with the rise of mobile, because the desktop conventions didn’t directly translate to touch and small screens, and (this goes back to your point) the developers of mobile OSs introduced equivalent conventions only half-heartedly.
For example, long-press could have been a consistent idiom for what right-click used to be on desktop, but that wasn’t done initially and later was never consistently promoted, competing with Share menus, ellipsis menus and whatnot.
> The web has nothing. You gotta roll your own, and it'll be half-baked at best. And since building for modern desktop platforms is horrible, the framework-less web is being used there too.
This feels like the root cause to me as well. Or more specifically, the web does have idioms, the problem is that those idioms are still stuck in 1980 and assume the web is a collection of science papers with hyperlinks and the occasional image, data table and submittable form.
This is where the "favourites" list and the ability to select any text on a web pages came from.
Web apps not only have to build an application UI completely from scratch, they also have to do it on top of a document UI that "wants" to do something completely different.
Modern browsers have toned down those idioms and essentially made it "easier to fight them", but didn't remove or improve them.
"The Web" has evolved into a pretty bad UI API. I kind of wish that the web stuck to documents with hyperlinks, and something else emerged as a cross-platform application SDK. Combining them both into HTTP/CSS/JS was a mistake IMO.
> You can't change the height of a native button, for example.
You can definitely do so, it's just not obvious or straightforward in many contexts.
The web was designed for interactive documents,not desktop applications. The layout engine was inspired by typesetting (floating, block) and lot of components only make sense for text (<i>, <span>, <strong>,...). There's also no allowance for dynamic data (virtualization of lists) and custom components (canvas and svgs are not great in that regard).
> building for modern desktop platforms is horrible, the framework-less web is being used there too.
I think it's more related to PM wanting to "brand" their product and developers optimizing things for themselves (in the short term), not for their users.
<button>Click me</button>
> There are hundreds of ways that different websites ask you to pick dates
Ugh, date pickers. So many of these violently throw up when I try to do the obvious thing: type in the damn date. Instead they force me to click through their inane menu, as if the designer wanted to force me into a showcase of their work. Let your power users type. Just call your user’s attention back to the field if they accidentally typed 03/142/026.
No no, I find that having to click back through almost 40 years’ worth of months to get to my birthday allows for a nice pause to consider the fleeting and ever-accelerating nature of life.
You can usually click the year and then pick that first. But the fact that so many people don't instantly get that shows how poorly designed it is.
> You can usually click the year and then pick that first.
Even then, clicking the year will often lead to a tiny one-page list of 10 years, which you can either page back in or click the decade to get shown a list of decades to pick from. So: click 2026, click 2020s, click 19XXs, click a year, click a month, click a birthday.
Such an interface makes at least some sense for "pick a date in the near future". When I'm booking an airline flight, I usually appreciate having a calendar interface that lets me pick a range for the departure and return dates. But it makes no sense for a birthday.
Is 03/04/2026 March 4th or the 3rd of April?
If you have an international audience that’s going to mess someone up.
Better yet require YYYY-MM-DD.
<input type="date"> is automatically formatted based on the user's locale.
Input type=date also just saves the day, month and year with no timezone information, which makes sense since the widget doesn't show any and context determines if the date should be in the user's timezone or a fixed timezone (like an event start date or a flight departure). But if you don't immediately convert that date to an ISO date and instead save it to the DB as yyyymmdd, you're in for a world of hurt trying to display date/times throughout the site. I inherited a project like this and have spent countless hours wrestling with nightmare timezone issues.
This is still a partial solution as the user needs to know that their locale is being used and know how their locale is configured to understand the format. This is most problematic on shared computers or kiosks, especially when traveling.
I don't even know my locale.
Is is the device display language, the keyboard input language, my geo location, my browser language, my legal location, my browser-preferred website language, the language I set last time, the language of the domain (looking at amazon.co.uk), the language that was auto-selected last time for me on mobile or... something else entirely?
I mean, once in a different country, you either experience the locale shock once then adapt, or you've seen it before and kind of know what to expect.
And for the rest of the users who have no idea about locales, using whatever locale they have on their computer might be technically incorrect for some of them, but at least they're somewhat used to that incorrectness already, as it's likely been their locale for a while and will remain so.
> And for the rest of the users who have no idea about locales, using whatever locale they have on their computer might be technically incorrect for some of them, but at least they're somewhat used to that incorrectness already, as it's likely been their locale for a while and will remain so.
Not really. A lot of computers are set to US locale (probably because it's the default) and the user just has no idea why some programs have dates in some crazy middle-out format and avoids those programs.
A partial solution is to put DD/MM/YYYY (or the appropriate format) as the input placeholder. You could also display the format as a tooltip when the input field is focused. IMO this is better than dealing with date pickers.
Or:
- Use localization context to show the right order for the user
- Display context to the user that makes obvious what the order is
- Show the month name during/immediately after input so the user can verify
> Better yet require YYYY-MM-DD
This is the equivalent of requiring all your text to be in Esperanto because dealing with separate languages is a pain.
"Normal" people never use YYYY-MM-DD format. The real world has actual complexity, tough, and the reason you see so many bugs and problems around localization is not that there aren't good APIs to deal with it, it's that it's often an after thought, doesn't always provide economic payoff, and any individual developer is usually focused on making sure it "looks good" I'm whatever locale they're familiar with.
I've seen some that had a drop-down for the month name. But since it was native, I could type the month name and my browser selected the right one.
As they type it, start displaying what it is. If, as you type "03/", it says "March", and that's not what you want, you now know what format it wants.
(And yes, always accept YYYY-MM-DD format, please.)
Ah, the MS Word experience:
User enters German date "1. April"
MS Word: new ordered list with item "April"
User furiously hits delete key.
Date pickers are the absolute worst. It blows my mind we don't have a clean standard by now.
The best is when a site uses the exact same date picker for birthdate as for some date in the future. Yes, I'd love to click backward 50 years to get to my birthdate. Thank you for reminding me how old I am.
Relatedly, scrolling time pickers are also a toss up on mobile. Sometimes a single swipe on the minutes gets you from 12:00pm to 11:50am, sometimes it doesn’t.
I wish the analog clock picker where two quick taps set the hours and minutes (and one more tap for am/pm) was more common.
I hate how scrolling through a list of years to enter my birthday forces me to confront my mortality
I hate how websites that are trying to verify my age make me scroll through 13, 18, or 21 years that I could not legitmately select if I want to use the site.
There's a small rental car company I use sometimes whos date picker is meant for phones and you have to "grab" the wheel and push it up / down do get to your date
UX has really gone downhill. This is particularly true of banking websites.
Also, the trend of hiding scrollbars, huge wasted spaces, making buttons look really flat, confusing icons, confusing ways of using drop downs rather than using the select/option html controls etc have all made the whole experience far inferior to where desktop UI was even decades ago
Hiding scrollbars is a deeply annoying trend. I don't understand the rationale. Because someone thought it looks aesthetically cooler?
mobile first philosophies is my guess.
...curious who decided seeing scrollbars wasn't useful on mobile though. it's very useful knowing where i am in a long scrolling thing.
i think material ui kicked design in the face in a broad multiple-industry-capturing way. it's gotta be the worst design language to interface with and it just unreasonably requires effort to navigate around gcp and lots of other google tooling. i'm glad it feels dated now and people are moving away to input boxes that are enclosed in, you know, a box... but i cannot stand what it brought to ux/ui.
> Every single button is clearly visually a button and says exactly what it does. And each one has a little underline to indicate its keyboard shortcut. Isn’t that nice?
Something not mentioned here (that came from the Mac world as I understand it): everywhere that the text ends with an ellipsis, choosing that action will lead to further UI prompts. The actions not written this way can complete immediately when you click the button, as they already have enough information.
> Prefer words to icons. Use only icons that are universally understood.
Underrated. Except for dyslexic people, and the most obvious icon forms, I am pretty sure most people are just better and faster at recognising single words at a glance than icons.
I'm somewhat dubious about that for icons with actual recognizable pictures, but a lot of icon attempts today are stylized to death, with just a line, bent and broken in a couple places and maybe if you're lucky juxtaposed with the occasional dot. If there's no text description even on mouseover (or touchscreen, with no cursor...) discovery is more or less trial and error (or perhaps more akin to Russian Roulette if the permissions involve being able to do real damage). Scratch your head and hope there are existing support questions searchable about what on Earth the programmer could have meant to convey...
...except for HN "unvote"/"undown" feedback which is especially unfortunate due to the shared prefix. Every time I upvote something I squint at the unvote/undown to make sure I didn't misclick.
I'm still shocked that the links are so dang close together on mobile. You don't even need the proverbial fat fingers.
I am pretty sure icons are easier and faster to recognize, except when you make them (too) small. In particular, they probably are easier in the long run, as long as they don't change position. But in a context where things change or you need a lot of buttons, words probably win.
This is why you need both. Icons are faster to recognize, but words tell you what the icons need. So you need the words at first to discover the icons, then the icons serve as valuable tools for scanning and quickly locating the click target that you are looking for.
> This is why you need both. Icons are faster to recognize, but words tell you what the icons need. So you need the words at first to discover the icons, then the icons serve as valuable tools for scanning and quickly locating the click target that you are looking for.
Only if there are few icons. If every item in that menu in the screenshot of Windows had an icon, and all icons were monochrome only, you'd never quickly find the one you want.
The reason icons in menu items work is because they are distinctive and sparse.
That's what I tend to do too, but sometimes space requirements win.
But of course, a good design is adapted to its user: frequent/infrequent is an important dimension, as is the time willing to learn the UI. E.g., many (semi) pro audio and video tools have a huge number of options, and they're all hidden under colorful little thingies and short-cuts.
Space is important there, because you want as many tracks and Vu meters and whatever on your screen as possible. Their users are interested in getting the most out of them, so they learn it, and it pays off.
The solution to this kind of problem is standards.
For most of the history of computation, things were moving too fast for anyone to really worry about standardization. Computing environments were also somewhat Balkanized. Standard keyboard shortcuts, for just one example, weren't. They still aren't. e.g. If you fingers are accustomed to hitting Ctrl-C to copy on most computers, they'll hit Fn-C on a Apple keyboard, which isn't Copy.
Today, things are moving slower and web interfaces have largely taken over. Your choice of OS mostly just affects how you get into a browser or some other cross-platform program... and what keys you hit for Copy and Paste.
Now would be a reasonable point in the history of computation for us to seriously consider standards. I'm not talking about licenses, inspectors, and litigation if you get it wrong. I'm just talking about some organization publishing standards that say, "This is how you build a standard login form. These are the features it should have. This is how they should be laid out. These are the icons to use or not use. These are the what keyboard shortcuts should be implemented." The idea is that people who sit down and start building a common bit of interface, instead of picking and choosing others to copy, should have a clear and simple set of standards to follow.
And yes, Apple needs to fix their #$%@ing keyboards.
Guys, I found out about this technology called Cascading Style Sheets recently and I think it's the missing piece we've been looking for. It lets you declaratively specify layout in a composable, hierarchical system based on something called the Document Object Model in a way that minimizes both clientside and serverside processing, based on these things called "stylesheets".
The best part is, it's super easy to customize them, read others for inspiration or to see how they did something, or even ship multiple per site to deal with different user preferences. Through this "forms" api, and little-known browser features like url-fragments, target/attribute selector, and style combinators, plus "the checkbox hack" you can build extremely responsive UIs out of it by "cascading" UI updates through your site! When do you think they're going to add it to next.js?
I'm tentatively calling this new UI paradigm "no-framework" or "no package manager", not sure yet https://i.imgur.com/OEMPJA8.png
> Cascading Style Sheets recently and I think it's the missing piece we've been looking for. It lets you declaratively specify layout in a composable, hierarchical system based on something called the Document Object Model in a way that minimizes both clientside and serverside processing, based on these things called "stylesheets"
I tried that and it was an absolute nightmare. There was no way to tell where a given style is used from, or even if it's used at all, and if the DOM hierarchy changes then your styles all change randomly (with, again, no way to tell what changed or where or why). Also "minimizes clientside processing" is a myth, I don't know what the implementation is but it ends up being slower and heavier than normal. Who ever thought this was a good idea?
> There was no way to tell where a given style is used from, or even if it's used at all
It's pretty easy. Open the inspector, select an element and you will find all the styles that apply. If you didn't try to be fancy and use weird build tools, you will also get the name of the file and the line number (and maybe navigation to the line itself). In Firefox, there's even a live editor for the selected element and the CSS file.
> if the DOM hierarchy changes then your styles all change randomly
Also styles are semantics like:
- The default appearance of links should be: ...
- All links in the article section should also be: ...
- The links inside a blockquote should also be: ...
- If a link has a class 'popup' it should be: ...
- The link identified as 'login' should be: ...
There's a section on MDN about how to ensure those rules are applied in the wanted order[1].
This way, your styles shouldn't need updates that often unless you change the semantics of your DOM.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Casc...
> Open the inspector, select an element and you will find all the styles that apply.
That tells me which styles apply to an element. You also need the converse - find which elements a given style applies to - and there's no way to do that AFAIK. It's very hard to ever delete even completely unused styles, because there is no way to tell (in the general case) whether a given style is used at all.
> This way, your styles shouldn't need updates that often unless you change the semantics of your DOM.
In my experience the DOM doesn't have semantics, or to the extent that it does, they change all the time.
> You also need the converse - find which elements a given style applies to - and there's no way to do that AFAIK.
I've never needed to do this, because I pay attention to my DOM structure and from CSS selectors can figure where a style applies. But I've just checked and the search bar for Firefox Inspector supports css selectors.
> In my experience the DOM doesn't have semantics, or to the extent that it does, they change all the time.
The DOM semantics are those of a hyper linked documents|forms. Take a page and think about what each elements means and their relations to each order. They will form a hierarchy with some generic components replicated. The due to how CSS is applied, you go from generic to specific elements, using the semantic structure to do the targeting
As an example, the structure of HN's reply page is
page
header
logo + Title
body
comment_box
upvote_button + comment_metadata
comment_text
textbox // reply text
button // reply
You should talk the people behind the vanillajs framework, this sounds like it might work well over there.
One trend that I can’t stand currently is the obsession with keyboard shortcuts everywhere even to the point of overriding browser defaults. Cmd+F focusing on the site’s search input instead of letting me search in the page with the browser’s search functionality (looking at you github and Linear).
I generally don’t need any fancy keyboard shortcuts on a website. I have a mouse, I can just click around.
To the opposite, I'm a heavy user of keyboard shortcuts everywhere they exist. OTOH taking over the browser shortcuts, and especially the search, is something that I very much dislike.
I'm ok with them as long as they're not overriding what I have saved in my muscle memory (cmd+F for search, tab to change the focused element, cmd+L to go to the navbar, and a few others).
I think the user should be able to customize/disable those as much as possible if you do provide them.
We've lost some common features:
* Undo & redo
* Help files & context sensitive F1
* Hints on mouse hover
* Keyboard shortcuts & shortcut customisation
* Main menus
* Files & directories
* ESC to close/back
* Drag n drop
Revelation features when they first became common. Now mostly gone on mobile and websites.
Lately I've occasionally been running into round check boxes that look like radio buttons. Why????
UX want to put their own spin on things. I’ve noticed this repeatedly.
UX has gotten from something with a cause to being the cause for something
In 20 years of front-end web development I've never encountered a designer willing to use standard form controls. I assume they exist.
iOS decided square checkboxes were ugly, and design patterns are flowing from mobile->desktop these days.
I think Apple does stuff like this because a) they can get away with it and b) they know countless competitors who can't get away with it will blindly follow their shitty new design paradigm.
Much of this is foisted upon us by visual designers who wandered into product design. It's a category error the profession has never quite corrected. (maybe more controversially, it's caused by having anyone with the word "designer" in their title on a project that doesn't need such a person - this category is larger than anyone thinks)
Interesting that Apple is praised.
> that a link? Maybe!
When Apple transitioned from skeuomorphic to flat design this was a huge issue. It was difficult to determine what was a button on iOS and whether you tapped it (and the removal of loading gifs across platforms further aggravated problems like double submits).
Another absurdity with iOS is the number of ways you can gesture. It started simply, now it is complex to the point where the OS can confuse one gesture for another.
I have a lot of gripes with Apple's various design decisions over the years, but they're at least consistent across their apps, which is the point of TFA.
Mystery gesture navigation is also now on by default and terrible on Android, too. It's awful with children or older folks (or even me!) who trigger it by accident all the time. Some of it I was able to disable on my children's iPads. It's still frustrating that easy to accidentally trigger but impossible to discover gestures are the default and also frustrating that we have the very last iPad generation with a button.
PWA dudes that all want to use some variant of shadcn or whatever same but different flavor of what is effectively the same design language are the more critically dangerous influences on design in my eyes than say apple. apple is highly opinionated on their design frameworks and that, at least, brings consistency. even if it's a dumb change, at least you can expect it everywhere
I think that the best UI design language is somewhere between "flat" and "skeuomorphic". I want neither a UI with notes apps that have Moleskine leather and vellum paper textures, nor the Android 12-like vague shapes of current-day macOS. The Windows 9x, and even more so, its predecessor NEXTSTEP, look and feel was perfect. Widgets had depth and definition, were still abstract but readily identifiable to the eye.
At some point UX became a synonym of manipulating users into doing things, and I wonder if it can ever go back.
It might have started in an innocent way, all those A/B tests about call-to-action button color, etc. But it became a full scale race between products and product managers (Whose landing page is best at converting users?, etc.) and somewhere in this race we just lost the sense of why UX exists. Product success is measured in conversion rates, net promoter score, bounce rates, etc. (all pretty much short-term metrics, by the way), and are optimized with disregard to the end-user experience. I mean, what was originally meant by UX. It is now completely turned on its head.
Like I said, I wonder if there is way back of if we are stuck in the rat race. The question is how to quit it.
Yall remember https://en.wikipedia.org/wiki/Mystery_meat_navigation? Back in 2004-ish era, there was an explosion of very creative interaction methods due to flash and browser performance improvements, and general hardware improvements which led to "mystery meat navigation" and the community's pushback.
Since then, the "idiomatic design" seems to have been completely lost.
Is this what the hamburger button is made of?
I mean, your guess is as good as mine as to what options the corresponding menu will actually contain, so....
I reference Jakob's Law at least once a week, which says users use not your site most of the time. So if it works like most other sites then users will intuitively understand it. And if you do something different users will struggle to learn it.
button is clearly visually a button
I had the pleasure of using a web app a few years ago that somehow managed to have buttons that looked like buttons, buttons that looked like static text, static text that looked like static text, and static text that looked like buttons, all on the same page. It was very memorable and extremely confusing to use.
Checkboxes are square,
Radiobuttons are round,
Beware those who dare
To switch them aroundI like how it became uncool about 10 years ago for buttons to provide any feedback that they've been pressed. Thanks Tim Apple!
designers are creatives and will always believe the visual elements of a design need to be updated, refreshed, modernized etc.. then we get flavour of the month nand new trends in visual language and ui design that things must be updated to.
As soon as UI design became a creative visual thing rather than a functional thing , everything started to go crazy in UI land..
That is because they know the users. Users are very sensitive to this: if the outside wasn't changed then the internals cannot be much improved. You see this with cars, cars need a new design otherwise customer will think nothing much changed. Customer will usually buy newer over better because they think newer must have improvements, and styling signals new. Same with computers, all the disappointments when apple releases a new macbook without changing the exterior....
> You can enter ALT+F to open the File menu, then hit N
Some developers raised on Macs don't understand the need for this behaviour in the Windows version of their software. Most do, but it's frustrating when the windows version of a multi platform framework doesn't afford for this.
Also the arrival of windows 8 which put controls and buttons at top and bottom of the screen was a big step backwards in consistency. Mobile interfaces (Android) still do this and it slows down interactions.
I’m not sure the core thesis is correct for two reasons. I’ve been around the block a few times now and I don’t think I’ve ever lived in an era where people were like “the current state of design is awesome”. There are always rose-tinted think pieces with some dubious stats about how things are awesome in the past.
Secondly, idiomatic is good if it matches your mental model. However, what does idiomatic mean in the context of billions of people coming from various computing starting point. Just as a simple thought exercise, how do you design idiomatically for people who are most familiar with Windows era computers and people who start with touchscreens, both generations who are still alive today?
>using GMail is nothing like using GSuites is nothing like using Google Docs
G Suite (no s) was the old name for Google Workspace. Google Workspace includes GMail, Google Docs, Google Sheets, Google Calendar, etc., so it doesn't really make sense to say that Google Workspace has a different UX than Google Docs, if Google Docs is part of Google Workspace.
Disclosure: I work at Google, but not one of the listed products.
If GSuites was a typo for GSites (e.g., informal for Google Sites classic), then the sentence in TFA could work.
IDK if such was the intent, of course.
The number of JavaScript dropdown replacements that don't work correctly with the keyboard is stunning. It always amazes me how many forms fail at this basic usability aspect. The browser has homogeneous form controls built in, just use them!
This needs to be built into figma and taught to product managers. FE devs are telling each other this all the time (mentioned in every single FE conference), but most of the time
- they don't get to make this decision - they fail when pushing back - Hacker News eventually blames the FE dev
i've seen this critiqued as ugly by people who didn't want to use daisyui's original dropdown which just deferred to the built in controls. now in daisyui's latest release there is an additional dropdown that you can style, because utility is a second rate citizen in design
> You don’t want to have to remember to use CTRL + Shift + C in certain circumstances or right-click → copy in others, that’d be annoying.
laughs in linux wouldn’t that be nice.
I’m a decade+ linux power user and I still do insane things like pipe outputs into vim so I can copy paste without having to remember tmux copy paste modes when I have vertical panes open.
Terminal UX existed before the CUA guidelines from IBM. People complains about Ctrl + Shift + C behavior when it exists only in one category of application, terminal emulators.
This is why Apple gave Macs a command key in 1984. Control is for sending control cides; command is for issuing commands!
The behavior science also changed a lot of things. People study behavior, patterns, what can sell more, what looks more intuitive. If something looks a bit different from the others, it will sell better. If something look the same way as the previous one, why should the client buy it? The client needs to see a difference, it can be only a little bit more flashy, but it must be different. 20 years, later, this is the result.
Especially now, in the AI era, where each person can make a relatively working app from the sofa, without any knowledge of UI/UX principles.
One of my pet peeves is that increasingly frequently, pressing Enter to submit a web form doesn’t even universally work anymore. Instead you have to tab to the submit button, and (depending on the web page) have to press Space or Enter to actuate it.
Another annoyance is that many web forms (and desktop apps based on web tech) don’t automatically place the keyboard focus in an input field anymore when first displayed. This is also an antipattern on mobile, that even on screens that only have one or two text inputs, and where the previous action clearly expressed that you want to perform a step that requires entering something, you first have to tap on the input field for the keyboard to appear, so that you can start entering the requested information.
> One of my pet peeves is that increasingly frequently, pressing Enter to submit a web form doesn’t even universally work anymore. Instead you have to tab to the submit button, and (depending on the web page), have to press Space or Enter to actuate it.
The other day I used Safari on a newly setup macOS machine for the first time in probably a decade. Of course wanted to browse HN, and eventually wanted to write a comment. Wrote a bunch of stuff, and by muscle memory, hit tab then enter.
Guess what happened instead of "submitted the comment"? Tab on macOS Safari apparently jumps up to the addressbar (???), and then of course you press Enter so it reloads the page, and everything you wrote disappears. I'm gonna admit, I did the same time just minutes later again, then I gave up using Safari for any sort of browsing and downloaded Firefox instead.
I would argue that behavior is idiomatic for macOS but not idiomatic for web browsers. Keyboard navigation of all elements has never been the default in macOS. Tab moves between input fields, but without turning on other settings, almost never moved between other elements because macOS was a mouse first OS from its earliest days. Web browsers often broke this convention, but Safari has from day one not used tab for full keyboard navigation by default.
And this highlights something that I think the author glosses over a little but is part of why idioms break for a lot of web applications. A lot of the keyboard commands we're used to issue commands to the OS and so their idioms are generally defined by the idioms of the OS. A web application, by nature of being an application within an application, has to try to intercept or override those commands. It's the same problem that linux (and windows) face with key commands shared by their terminals and their GUIs. Is "ctrl-c" copy or interrupt? Depends on what has focus right now, and both are "idiomatic" for their particular environments. macOS neatly sidesteps this for terminals because "ctrl-c" was never used for copy, it was always "cmd-c".
Incidentally, what you're looking for in Safari is either "Press Tab to highlight each item on a webpage" setting in the Advanced settings tab. By default with that off, you would use "opt-Tab" to navigate to all elements.
System Settings -> Keyboard -> and toggle Keyboard navigation.
I'm not sure why this isn't the default, but this allows for UI navigation via keyboard on macOS, including Safari.
> Another annoyance is that many web forms (and desktop apps based on web tech) don’t automatically place the keyboard focus in an input field anymore when first displayed
Well, the keyboard takes up so much space. IMO it's important to view the form and the context of the inputs before you start typing.
Is it really consensus in the UX world that it's an antipattern?
My health provider recently changed their homepage UI to have a human 'profile' icon to mean "register", a lock icon to sign-in, and 'box-arrow-in-right" to logout. No tooltips
> Suppose you’re logging into a website, and it asks: “do you want to stay logged in?”
Then the website has made its first mistake, and should delete that checkbox entirely, because the correct answer is always "yes". If you don't want to be logged in, either hit the logout button, or use private browsing. It is not the responsibility of individual websites to deal with this.
My hope is that since tools like Google Stitch have made fancy looking design free that it will become obvious how functionally worthless fancy looking design always was. It used to signal that a site paid a lot of money and was therefore legitimate. Now it signals nothing.
This is a good point, but there's usually a long tail on transitions like this.
But I'm not convinced the old consistency was purely a design victory... it was also a result of heavy constraints
This kinda hurt. The world is in a rush to be the ASAP, so nobodys interest is to do design good, it needs to be fast. And now we have this sh*tshow.
With some irony, one thing Substack doesn't afford is zooming in to images on mobile.
Firefox on Android can override this via a toggle in the Accessibility settings. Maybe other browsers have something similar?
The web needs a HIG.
All of these people who keep saying that webapps can replace desktop applications were simply never desktop power users. They don’t know what they don’t know.
Yeah it would be nice if the web accessibility guidelines also focused on actually using the thing normally. For example: offsetting the scrollbar from the right edge of the screen by 1px should be punishable by death.
I think HIG means "Human Interface Guidelines" here. Seems to be an Apple thing.
I wish more people would avoid or at least introduce abbreviations that may be unfamiliar to the audience.
Microsoft had one too: WIG!
There are quite a number of them: <https://en.wikipedia.org/wiki/Human_interface_guidelines#Exa...>
And while we're at it, stop with the popups and notifications.
I don't care about the new features in a browser update. Ideally, nothing at all has changed.
I don't want a "tour" of the software I just installed. I, presumably, installed it to do something, and I just want to do that thing.
I don't want to have to select a preference for how a specific action is performed in your software. If it's not what I expected, I will learn it.
And for the love of GOD, nobody wants to subscribe to your newsletter.
I actually might want to subscribe to your newsletter, provided I read & enjoy your article. So why does the pop-up always interrupt me before the page has even finished loading?
If you inset an unobtrusive newsletter button 60% of the way through the article, perhaps I'll actually click it (or, more realistically, follow your RSS feed).
Not sure how you can put the genie back in the bottle, every app wants to have its own design so how can you enforce them to all obey the same design principles? You simply can't.
Shows a picture of Office 2000 and says "The visuals feel a little ugly and dated: it’s blocky, the font isn’t great, and the colors are dull."
Are you serious? Nothing has come close to it. Yeah we have higher resolution screens, but everything else is much less legible and accessible than that screenshot.
Day-to-day usability doesn't bring much "wow" factor to a sales pitch.
Am I the only one who doesn't know what that "Keep me signed in" checkbox is for? I mean, I was a web developer for many years and I rarely encountered this checkbox in the wild, don't remember implementing it even once. I mean the choice itself is very ambiguous. It is supposed to mean that the login session will only live for the duration of the current browser session if I uncheck it. But for a user (and for me too) that does not mean much, what is the duration of the session if my browser runs open for weeks, what if we are on mobile where tabs never close and tabs and history is basically the same thing (UX-wise). If I decide to uncheck it for security reasons (for example when I'm on someone else's device) I want to at least know when exactly or after what action the session will be cleared out, and as a user I have zero awareness or control there.
I don't advocate for removal of this checkbox but I would at least re-consider if that pattern is truly a common knowledge or not :)
I've never seen one that actually works. It seems like whether or not I check them, the next time I log into [every site] I have to re log in.
Really? I don't think I've ever seen one that doesn't work. What sites are you using where you encounter this? Have you checked your cookie settings?
It's basically the expiration date on the cookie that keeps you logged in. Very common on forums and the like, and some even let you select how long you want the session to last.
This is a really huge and a fundamental flaw in AI-driven design. AI-driven design is completely inconsistent. If you re-ran an AI generated layout, even with the same prompt, the output for a user interface will look completely different between two runs.
You can steer it towards reusable components, though.
Find a run you like, and build off that.
You definitely need to filter if you use AI. Looking at all the vibe-coded creations that are showing up these days has changed my mind from "AI-generated code is bad" to "the one using the AI is doing a bad job of it".
I ended up writing a linter/validator that checks the AI-generated code for everything, including user interface style guidelines and preferences (not necessarily for hard errors)
UIs are inconsistent even in the same app. Nevermind plugins or suites. It would be great if menus were customizable so you could plug in your own template.
I prefer to avoid customizing apps. I want to be able to sit down at a fresh install (or someone else's) and not spend time learning their preferences.
When someone asks me for a checkbox so they can have my app work their way instead and everyone else can do theirs, the hair stands up on the back of my neck. The check boxes are hard to discover unless you put them front and center, in which case they remain there forever serving no purpose.
I would rather redesign the entire interface, either to find the right answer that works for everyone, or to learn what makes one class of users different from another. The check box is a mode, and nodes are to be avoided if I possibly can.
I realize that this puts me at odds with a whole class of users who want to make their box do their thing. It's your box and you should do what you want. And I really love style sheets for that. Rather than cobbling together my own set of possible preferences you should have something Turing complete. Go nuts with it.
I think most non-Linux users haven't made a fresh install in 5-10 years. Preferences files and apps get transferred when you buy a new computer or update your os.
I was pleased how much was passed over from my last phone. I got the same brand so it's not surprising, but wow it is so much better than The Good Old Days (tm).
I remember the old days being surprisingly smooth. There was some verizon tool that transferred all my contacts from the dumb phone to my first smart phone.
Hell, I'd be happy if, when I started reading text, the websites would just let me keep reading text rather than popping up an interminable number of ads, video, alert/app/notification options, etc.
I mean, you know that if they can't do that, any other idioms from last century are right out the window as well.
> The visuals feel a little ugly and dated
It's... beautiful.
That windows 2000/win 95 interface was peak windows design.
Apple was doing a pretty good job until whatever happened with v 26.
On the web, the rise of component libraries and consistent theming is promising.
... and please stop doing paralax...
I had to laugh when I read this:
> Avoid JavaScript reimplementations of HTML basics, e.g. React Button components instead of styled <button> elements.
I've been hearing that for the entire Internet era yet people continue to reinvent scrollbars, text boxes, buttons, checkboxes and, well, every input element. And I don't know why.
What this article is really talking about is conventions not idioms (IMHO). You see a button and you know how it works. A standard button will behave in predictable ways across devices and support accessibility and not require loading third-party JS libraries.
Also:
> Notwithstanding that, there are fashion cycles in visual design. We had skeuomorphic design in the late 2000s and early 2010s, material design in the mid 2010s, those colorful 2D vector illustrations in the late 2010s, etc.
I'm glad the author brought this up. Flat design (often called "material design" as it is here) has usability issues and this has been discussed a lot eg [1].
The concept here is called affordances [2], which is where the presentation of a UI element suggests how it's used, like being pressed or grabbed or dragged. Flat design and other kinds of minimalism tend to hide affordances.
It seems like this is a fundamental flaw in human nature that crops up everywhere: people feel like they have to do something different because it's different, not because it's better. It's almost like people have this need to make their mark. I see this all the time in game sequels that ruin what was liked by the original, like they're trying to keep it "fresh".
Worked at Figma for 5 years. The author uses Figma as an example, but I think misses the point. They're so close though. Note these quotes:
> Both are very well-designed from first principles, but do not conform to what other interfaces the user might be familiar with
> The lack of homogeneous interfaces means that I spend most of my digital time not in a state of productive flow
There are generally two types of apps - general apps and professional tools. While I highly agree with the author that general apps should align with trends, from a pure time-spent PoV Figma is a professional tool. The design editor in particular is designed for users who are in it every day for multiple hours a day. In this scenario, small delays in common actions stack up significantly.
I'll use the Variables project in Figma as an example (mainly because that was my baby while I was there). Variables were used on the order of magnitude of billions. An increase in 1s in the time it took to pick a variable was a net loss of around 100 human years in aggregate. We could have used more standardized patterns for picking them (ie illustrator's palette approach), or unified patterns for picking them (making styles and variables the same thing), but in the end we picked slightly different behavior because at the end of the day it was faster.
In the end it's about minimizing friction of an experience. Sometimes minimizing friction for one audience impacts another - in the case of Figma minimizing it for pro users increased the friction for casual users, but that's the nature of pro tools. Blender shouldn't try and adopt idiomatic patterns - it doesn't make sense for it, as it would negatively impact their core audience despite lowering friction for casual users. You have to look at net friction as a whole.
Good point, I think in case of Figma the idiomatic design was set by Sketch and other UI design apps, which in itself was a step away from the idiomatic design established by Photoshop.
(2023)
Idiomatic design will never come back. The reason being companies believe (correctly) that they design language is part of their brand. The uniqueness is, basically, the point.
That was one of the problem with the original Material framework: every app looked too similar making it hard to distinguish one from another. Google was concerned about people associating bad third party app with itself.
They added more customizability in Material 2 (or was it 3?), but yeah at that point some of the damage was done.
See also:
> The easiest programs to use are those that demand the least new learning from the user — or, to put it another way, the easiest programs to use are those that most effectively connect to the user's pre-existing knowledge.
The Art of Unix Programming
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
Now we’re blaming React for bad UX?
[dead]
"Avoid JavaScript reimplementations of HTML basics, e.g. React Button components instead of styled <button> elements."
Tell me you know nothing about web development without saying you know nothing about web dev ...
1. React is an irrelevant implementation detail. You can have a plain HTML button in a button component, or you can have an image or whatever else. React has nothing to do with the design choices.
2. React is also how you get consistent design across a major web app. Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color? It'd be awful! React components (with CSS classes) are a way for a site like Amazon to make all their buttons orange (although I don't actually know if Amazon uses React specifically). But again, whether they look and act like standard buttons comes down to Amazon's design choices ... not whether their tech stack includes React or not.
Look idiomatic design is incredibly important to web design. One of the most popular web design/usability books, Don't Make Me Think, is all about idiomatic design!
But ultimately it's a design choice, which has very little, if anything at all, to do with which development tools you use.
> Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color? It'd be awful!
As it happens, this is how it was for years and years, actually, for most of the existence of the Web. The basic appearance of form elements used to be un-styleable, locked to the OS UI-appearance, for general usability concerns.
> React is also how you get consistent design across a major web app. Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color? It'd be awful! React components (with CSS classes) are a way for a site like Amazon to make all their buttons orange (although I don't actually know if Amazon uses React specifically).
I don't understand this point specifically. I make all buttons on a site have the same theme without needing a framework, library or build-step!
Why is React (or any other framework) needed? I mean, you say specifically "React is also how you get consistent design across a major web app.", but that ain't true.
It depends on the type of site/app you are building. If you are building a basic website (not a web application), or a simple application, you don't need React (or a similar framework like Vue or Angular). You might not even need Javascript at all.
However, as you build more complex and interactive applications, you need "framework", like React. It's essential to simply handle the complexity of such applications. You will not find a major web app that is built with out a framework (or if it is, the owners will essentially have to create their own framework).
When you're using such tools, they are how you enforce consistent UI. Take Tailwind, the hugely popular CSS framework (I believe its #1). They have nothing to do with Javascript ... but even they willl tell you (https://v3.tailwindcss.com/docs/reusing-styles#extracting-co...):
"If you need to reuse some styles across multiple files, the best strategy is to create a component if you’re using a front-end framework like React, Svelte, or Vue ..."
The author is completely mistaken in thinking React ... or even that layer of web technology at all (the development layer) ... has anything to do with what he is complaining about. It has everything to do with design choices, which are almost completely separate from which framework a site picks.
I am not convinced that, when using a framework (React, etc), the best way to enforce consistent UI is via the framework.
A button should be styled independent of the framework. That's how you will get consistency. Same with every other non-component element.
The use of the component framework should be to consistently style non-primitive style elements (all the standard HTML elements).
What value is there in using React/whatever in styling buttons, links, paragraphs, headings, various inputs, etc? Today, in 2026, even menus, tabs, etc are done with nothing more than primitive elements; what value does React bring to the consistency of menus that you don't already have?
Design is more than styling, it is also behaviour and state, which is what react helps you encapsulate in a component.
>>> Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color? It'd be awful!
Speaking as a user not a developer, it'd be lovely.
> Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color?
Not a webdev, but can't you just use CSS on the <button> element for that?
Yes you can, on a small/simple site. But on a serious web application sticking to plain HTML/CSS will be far too limiting, in many ways.
There's a reason why 99.9% of web apps use JavaScript, and with it a tool (framework) like React, Astro, Angular, or Vue. And if you're using such tools, you use them (eg. you use React "components") to create a consistent UI across the site.
But again, which tool you use to develop a site has very little to do with what design choices you make. A React dev with no designer to guide him might pick the most popular date picker component for React, and have the React community influence design that way, but ... A) if everyone picks the most popular tool, it becomes more idiomatic (it's not doing this that creates divergence), and B) if there is a human designer, they can pick from 20+ date picker libraries AND they can ask the dev team to further customize them.
It's designers (or developers playing at being designers) that result in wacky new UI that's not idiomatic. It has (almost) nothing to do with React and that layer of tooling, and if anything those tools lead to more idiomatic design.
> Tell me you know nothing about web development without saying you know nothing about web dev
This Twitterism really bugs me.
You took the time to write a really detailed response (much appreciated, you convinced me). There’s no need to explicitly dunk on the OP. Though if you really want to be a little mean (a little bit is fair imo), I think it should be closer to level of creativity of the rest of your comment. Call them ignorant and say you can’t take them seriously or something. The twitterism wouldn’t really stand on its own as a comment.
Sorry for the nitpicky rant.
I think that's a fair criticism.
It bugs me that the author is "dunking on" React without knowledge on the matter (React is the tool you use to enforce consistent UI on a site; it has almost nothing at all to do with a design decision to have inconsistent UI). So I guess I "dunked on him" in response.
But ... too wrongs don't make a right. I'd remove the un-needed smarminess, if it wasn't already too late to edit.