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.
It's because enter does different things at different times in the exact same text box.
Write a code snippet/block text. Does [enter] insert a newline, exit the block, or send the message?
What about in a bulleted or numbered list?
And my 2 biggest pet peeves with MS Teams:
1. trying to edit the first letter in a `preformat block`. It's not possible. It will either exit the block or go to the second letter.
2. Consistency with bold/italics. Bold a selection of text. Then backspace once. Are you going to write bold or normal? What does ctrl-B do? Anytime you backspace into a bolded section, it will convert your editing back to bold, and you cannot disable bold.
I have a very small Kevin Bacon number to the "guy who runs Teams". The message from them is "please use the built-in feedback tool to tell us about these things".
I also sent a LOT of Slack messages prematurely for the same reason. Used to it now, though. The more an interface emphasises the single-line nature of a text input, the better. Multi-line should never submit on enter, single-line always should.
“A teleprinter (teletypewriter, teletype or TTY) is an electromechanical device used to send and receive typed messages through various communications channels
[…]
Initially, from 1887 at the earliest, teleprinters were used in telegraphy. Electrical telegraphy had been developed decades earlier in the late 1830s and 1840s, then using simpler Morse key equipment and telegraph operators
[…]
With the development of early computers in the 1950s, teleprinters were adapted to allow typed data to be sent to a computer”
Mechanical typewriters have different physical mechanisms to feed forward a line or make the carriage return. I think it doesn't turtle much further back than that.
Well around the time of the first typewriters (late 19th century) there where mechanical typesetters, automating the laborious task of typesetting for the printing press. Of course the mechanics of printing where different but as far as I know this is the source of the "keyboard with buttons" type interface for producing literature.
Pianos have keys. And some telegraphs were outfitted with piano-like keyboards with one key per letter. Wikipedia has some pictures in the printing telegraph article [1]. So there is arguably a clear lineage from pianos to the modern computer keyboard.
Pianos however don't really have a concept of advancing the line or sending a recorded message.
Now I am searching to see if there were models of player pianos intended to punch tape.
I have never really thought about it but a player piano sort of implies it can only play the roll. If pressed I would guess that player piano rolls were cut by hand. I mean, I am sure they had tools to help them and probably fully automatic duplication machines. but did anyone play the piano to get a piano roll? or was it more like transcribing sheet music?
here were pianos that could punch a roll, but they were rare - AFAIK there were one offs that the company who made rolls used. The better rolls labels "as played by [someone famous in 1920]" were played on such a system. Once in a while those rolls were used directly in a performance, but the most common use was an expert would use that as the master and then correct all the errors because the transcription system wasn't very accurate (I'm not sure in what way, only that the companies always had an editor make adjustments before selling those roll)
Some of them are on exhibit in a museum - but with a sign saying something like "this will never be restored because it exposes the user to poisonous mercury." If you want to know more join the Musical Box society (I'm a member), or one of the other international clubs for people who collect this type of thing (I know of several but since I'm not a member I can't remember the full name)
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").
Some older Apple keyboards had their backspace button labelled “delete” which to me made it sound like that was the “del” button and not the backspace button.
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?
Your advice beautifully reinforces OP's case.
We now have to use auxiliary apps with more predictable behaviour because designers made such a mess of things.
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.
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.
I would say it mirrors common behavior in the Web, which in turn was largely influenced by old desktop software: Enter in a `<textarea>` inserts a line break, while enter in an `<input>` submits the surrounding form (or does nothing). It is an established idiom after all, many apps just get it wrong.
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.
I have a suspicion — it has to do with instant messaging clients. The idea being that you want to type short one-line messages and send them as quickly as possible in most cases, but in a rarer case when you do want a line break, that's Ctrl+Enter or Shift+Enter. Probably the first one where I personally encountered "enter is send" is ICQ, but I'm sure it's older than that, I would be surprised if no IRC clients did that.
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.
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.
Yeah this is insane. Maybe most users of chat bots are just sending one line prompts but I find that hard to believe users of Claude code are doing that more often than sending multi-line prompts.
I think this one is easy to explain: it's a clash between chat idioms and forum idioms. Chats since IRC have had Enter=Send because messages were supposed to be single line, while web forums have had multiline text editors from the start so Ctrl+Enter=Send made the most sense. As the two merged, confusion and conflict was inevitable.
We can easily fix this by just letting everyone choose, but no one wants to make configurable UX.
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.
I think this is just doing things differently, not fixing them - and IMO not for the better either.
I've been playing with making a chatbot with llama.cpp and FLTK[0] and FLTK's default behavior is actually to add a newline in the multiline editor when pressing Enter even if a 'Return button' is in the form (Return buttons are buttons activated when you press Enter or Return though Return is also handled kinda differently). And i have a big Submit 'Return button' there.
And TBH it annoyed me a LOT that i have to move the mouse and press the button to submit or that Enter adds newlines instead of submitting so that i explicitly added code so that pressing Enter is not handled by the editor (letting the Return button submit the input) and pressing Shift+Enter is what adds the newline (Ctrl+Enter also works, this comes from FLTK's behavior, but i've been used to Shift+Enter myself).
Which is basically how pretty much every chat interface (be it AI chatbot or something like Discord or whatever) that i've used in recent times works. And TBH it makes sense to me that the simplest/easiest shortcut (Enter) is what does the most common thing (send text) in a chat interface whereas the more involved shortcut (Shift+Enter or Ctrl+Enter) is used for the exceptional/less common case. In such an interface, the multiline editing is there as an exception (for when you want to paste some stuff and even then often Ctrl+V by itself can be enough), but most interactions are going to be single line submissions (often wordwrapped to look like multiple lines but still a single line).
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.
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.
Win32 standard multiline edit controls use Ctrl+Enter to insert a newline (instead of pushing the default button or "submit" action on a dialog), so that may be where the idiom came from.
For me, Enter to send and Ctrl+Enter for newline is the norm in an IM application, while longer and more asynchronous communication (like this textbox on HN for commenting, or a forum post, or an email client) implies that Enter inserts a newline and something more substantial (Alt+S is common, or Tab,Enter to move to and press the submit button) submits.
> and ctrl-enter forces a newline (not at my computer, but I think Slack does this)
Slack also has the option to invert this in settings. I always have it inverted, so that I can freely type multiline messages, and require the more intentional ctrl-enter to actually send.
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.
> - 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.
Web browsers have been like that by default for ages in text input (single line) vs textarea (multi line). Since way before smartphones even existed.
Regardless, many chat apps on the computer have what look like a multi line textarea but it will be anyone’s guess whether Enter will add a newline or submit in any particular one of them.
> Infuriatingly, some apps try to be smart — only one line, return submits
Tbf, this is almost certainly what the vast majority of people want, most of the time, from chat apps like Slack. It would be much more frustrating to have to click a button after each thought.
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.
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.
I can kinda understand why ChatGPT and other chat bots do it. It's a chat interface. Most people chat with single line prompts.
Next door and social media apps, to answer your question, I'm sure a PM somewhere was able to prove that engagement increased if we let people share their thoughts immediately, and the PM got a tidy bonus because of this.
I would be OK if they put a checkbox next to the text input that let me choose whether enter sends or line breaks. I would be OK even if that lived in session storage, to remove the friction of a new Db column. Just give us the option!
It's even worse on some websites. For example, Grok sends on enter. Even on mobile. Where you can't even press ctrl+enter, because mobile software keyboards don't have a control key. So you can't include line breaks at all when talking to Grok. You can merely accidentally send a message prematurely. (Maybe they have fixed it by now.)
>"bring back idiomatic design" doesn't help when we don't have enough idioms
One must always research and find the dominant or most applicable idioms for whatever they're doing. Are you building a command line tool? For which platform? What other similar tools are you basing its design on? You have to check yourself and see whether your software conforms to the idioms of the platforms, communities, etc that you're targeting.
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 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.
for this reason I use shift+enter. I'm blind and not sure if it starts a new paragraph or is just a paragraph break, but works well enough in my experience.
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.
It should be, but it isn’t. Hence the reason “why can’t you just do what we asked” can often be followed by “then we will find someone who will” in the end.
Pushback is valuable until it becomes obstinance.
If we all somehow had their same crystal ball to know for certain that “stupid shower ideas” won’t work because a specific developer thinks they are bad, there wouldn’t be much need for R&D ever again. I suspect this developer doesn’t have one either, or I’d certainly like to buy it.
Those people generally are not eager for feedback especially if it's even remotely perceived as negative or some kind of gatekeeping.
The only way to avoid getting furious about this is to deeply understand that you can't require people to be properly self-aware, especially because many many people that checks the expert boxes are very incompetent or inadequate, so they when the come up with their half bake ideas, they delegate the other to deliver contrarian proofs. It's exhausting.
Yeah you don't walk into the job doing it. But once your position is secure and you've built some stuff to where you can make changes in 5 minutes that might take someone else a day, then you can start pushing back on craziness.
There's also an art to how you do it. It's important to build up trust that you won't tell the client something is impossible or really hard just because you don't want to do it. You try to explain to them how much complexity this is going to add, how that will make it harder to add new features in the future, and most importantly offer some alternatives that get them 90% of what they're trying to do. Most clients will appreciate that approach IME, especially if you've already thrilled them a few times.
This is one of the reasons I'm not so worried about Claude taking my job in the immediate future. But I am still extremely worried about the industry as a whole and by extension the future of the middle class.
Yeah I agree. I've worked with my boss in various capacities for the last ten years. When he says "can we do X" my answer is always like "we can do anything, the question is does the company want to allocate Y resources to get X done." Claude, being a yes-man, will always say "you're absolutely right!" to any idea you throw at it, not knowing (and, perhaps more crucially, not caring) if it's the right fit for your product/business.
I think part of the problem is that many engineers don't stick around long enough to build that rapport, which isn't a problem of AI in itself but is certainly exacerbated by it.
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“.
I'm the lead for an internal tool for a non-technical team. We iterate so quickly that the team we're building it for was like "can you guys stop changing things so quickly? We can't keep up with where anything is." which was a fair assessment.
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.
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.
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
Feels like somebody has read their Marshall McLuhan :) I recently started reading Understanding Media, and every chapter delivers at least one mind-melting moment; something he draws attention to and/or frames in some way.
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
That would happen in a free market, but software is intentionally not a free market thanks to copyright/patent laws. In software, lock-in effects dominate. People will continue using bad software because it's necessary to interoperate with bad software other people are using. There's a coordination problem where everybody would be better off if they collectively switched to better software, but any individual is worse off if they're the first to switch.
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?
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).
I have an AutoHotkey that just takes whatever is in my clipboard and sends it through as individual virtual keystrokes, specifically for defeating paste-disabled form fields.
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.
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?
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
> 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.
>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.
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).
It doesn't matter that different platforms have different standards, as long as applications on any given platform are mostly consistent.
I don't care if your app looks different on Windows, because I'm on a Mac. I care that it behaves like a Mac application, and the muscle memory I have from all my other Mac apps also works on yours.
If you say that too loud, the “but my brands unique UI supersedes your functional requirements” people will emerge, screeching, from the woodwork!
I can’t prove it, but I just know they’re the ones who live their lives one NPS score at a time, and must think that we operate our software, being thankful for every custom animation that they force us to sit through on their otherwise broken and unimportant software.
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.
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.
> 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.
As a designer, the issue I see is that desktop design requires knowledge and experience of the native toolkits.
This makes desktop the hardest platform to design (well) for.
For example, on macOS you need to know about where the customisation points are in NSMenu, you need to know a little about the responder chain etc.
Most designers only have web or mobile experience, and the nuances of the desktop get lost, even at th design stage. You end up with a custom and shallow system that is weird in the context of the OS.
You also end up with stuff like no context menus, weird hover states (hand cursors anyone?), weird font and UI sizing (why are Spotify's UI elements literally twice the size of native controls? The saving grace of it being an Electron app is that I can zoom out 3 steps to make the UI size sane). I digress...
> 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.
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”
> 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.
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 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.
Perhaps the situation has changed since I last tried.
It used to be, in AppKit, that a normal NSButton could have its size class changed (small, regular etc.) but you couldn't set the height without subclassing and doing the background drawing yourself!
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.
Is how you do it on the web. The problem is that it means you app will not look as good as others and that it will look different on different platforms.
> 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.
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.
And even when they let you type it in, sometimes it turns out that the website was made by Americans and so expects the bonkers date format of MM/DD/YYYY.
A good example of appropriate use of a calendar interface on a flight booking website is Aviasales. They show flight prices for each day right there, so if your travel dates are flexible, you know when it's cheaper by just looking at it! This should be a standard feature.
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.
That can get messy and confusing if the user's locale is different from the language of the web page.
When I write in English, I of course also want to edit dates and numbers using English conventions. But instead, I am forced to use decimal comma and day/month order because those are the default locale for Swedish, which is my default locale.
I have never encountered an OS that doesn't work that way.
On the web you'll often don't know: it could be anything.
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.
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?
Exactly. Under Windows, this isn't even consistent across applications. I'm in France, with the location set to France, using English display language and "English (Europe)" formatting. This means that the expected date is DD/MM/YYYY. It's what shows up in the taskbar, for example. But many applications seem to do this based on language, so I sometimes get MM/DD/YYYY.
I don't normally run Windows, so I can't check right now, but I think it's mostly "modern" applications that mess this up. Like the MS Store, Teams (obviously).
the only locale i know about is the windows one that's hidden in some menu that i had to set to japan to get some random application to run, and now all of my backslashes look like yen symbols :P
... maybe i won't get mm/dd/yyyy now!
I think modern browsers are actually quite good here. They show a template in the form TT.MM.JJJJ for me (so the German equivalent of MM/DD/YYYY, with the usual order and separator in German). I can just type the date, including the dots if I want (they're just ignored; there would be extra points for moving me to the next component when typing "2.", but the world's not perfect). If I'm confused about the format, or want to see a calendar view, I can click on the calendar icon (also accessible via tab) and select a date there.
For normal date inputs, I really don't think there is a good reason to use anything else. (Possible exceptions I can think of: Selecting date ranges and/or showing extra data about the dates (like daily prices).)
No, modern browsers are horrible at this as they are often ignoring your settings (at least Chrome and Edge on Windows do). They are basing the format entirely on the language instead of the date format configured in your Windows settings. Safari on iOS seems to not have this issue though as far as I can tell.
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.
Well, the issue is when the applications look at the wrong configuration to set this up.
Think about traveling to a different country for a limited time. I want my location, time zone, etc to be set to where I am. I traveled across the US a few years ago, and I would rather not have to mentally follow in which time zone I was. Heck, I don't even know where the limits are. Bonus points for DST happening on a different date than in Europe, and extra bonus for there being no DST in Arizona, except for Navajo Nation? I remember signs saying it was illegal to carry alcohol, but I don't recall anything about time zones.
But as a European, I don't want my date to suddenly appear in US format; I'm only there for a few weeks.
> 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.
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.
And Sweden. And probably lots of other countries too.
It's a world standard, and there are very few places that use hyphens in dates that are not ISO dates.
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.
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 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
Thank you so much for writing this. I'm also from the desktop era and I can't STAND all the reinvention going on, or the fact that I have to move the mouse all over the screen or randomly stab my phone with my finger to find out what I can interact with.
I'm working on a GUI app and a web app in concert right now. They work in the same niche, but at different levels (one is desktop-level management, the other is enterprise-level management). I stepped back and developed a unified design language (Tela Design Language, or TDL) which has saved my sanity and made the apps actually usable again.
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
For group chats in Microsoft Teams with more than seven participants, if you click on "View and add participants" (an icon with two people and a plus sign) you see a list of seven participants. At first I didn't know that you could scroll in this list.
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.
> 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...
It varies, some applications - the ones that people spend their workday in - have specific iconography that is domain specific for that application.
A difference needs to be made between general public applications and domain specific employee applications. SAP is a great example of this. Of domain specific icons I mean, not of good UX design.
...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 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 not true. Just today for example, in android at least, I went to whatsapp, selected a chat with long tap, I want to archive the chat. I have a download like button. Apparently that is the archive button. I had no idea.
If it was the opening to the alternate dimension, I wouldn't still know. If it was something harmful like backup and delete, I wouldnt know. I just took the plunge and hoped it wasn't gonna be harmful. Luckily it was archive.
These kind of stupid things are there now in their calling screen and other places. Absolutely ridiculous and hard for me. Now imagine my parents who are 60+!!
Easier has more than one dimension (speed, error rate, recall, precision, cognitive load), but the baseline for generic statements is not one particular, very rare task. That's anecdote.
And in this case, the statement was about recognition, not intuition. Otherwise there are counter arguments: there are enough words in UIs which do not have an intuitive meaning either. "New" would be one. New what? File and folder are others, especially with decreasing awareness of the file system under young generations.
I'd say that you recognized the button fast enough, but the wrong function was attached to it. It's as if they would have had a menu item called "Download" which would archive.
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.
It's a little interesting that they would pick Office 2000 as an example, since Office 97 and onwards do not use standard OS widgets -- it reimplements and draws them itself*.
The menu bar in Office 2000 does not look like the standard OS menu bar, for instance. The colors, icons and spacing are non-standard. This is only slightly jarring, because it's pretty well done, but it's still inconsistent with every other app.
This was kind of the beginning of the end for Windows consistency -- when even Microsoft thought that their own toolkit and UX standards were insufficient for their flagship application. Things have only become worse since then.
* This becomes very obvious when you run Office 97 on NT 3.51, which generally looks like Windows 3.1, but since Office 97 renders itself and does not care about OS widgets, it looks like this: http://toastytech.com/guis/nt351word.png
This is funny because Teams on Windows uses its custom notifications instead of the system ones. But running it in a browser under Linux, I get my native notifications!
> 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.
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.
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.
And yet, Microsoft is still doing their own thing. It's a shame they didn't follow through with, and / or the industry didn't follow along with, Windows Phone because it was a pretty unique design.
Google / Material Design also does their own thing still.
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 around
Keyboard focus and focus indication on browsers is fundamentally broken.
We often notice when focus is buggy. But there are many many hidden/unobvious edge cases.
Previously I created a fix for the worst focusing issues on browsers by creating a fully custom framework (before modern HTML help with popovers/dialogs/overlays/viewports/anchors). No other framework at the time managed Internet Explorer's quirks very well (we served businesses who mostly used that browser).
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.
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.
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)
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.
> It's pretty easy. Open the inspector, select an element and you will find all the styles that apply.
Of course it's not easy, 80% of that list will be some garbage like global variables I would only need when I actually see them in a style value, not all the time.
The names are often unintuitive, and search is primitive anyway, so that's of little help. And the values are just as bad, with --vars() and !important needless verbosity in this aborted attempt of a programming language
Then there is this potentiality more useful "Computed" styles tab, but even for the most primitive property: Width, it often fails and is not able to click-to-find where the style is coming from
> Also styles are semantics like:
That's another myth. You style could just be. ReactComponentModel.ReactComponentSubmodel.hkjgsrtio.VeryImportantToIncludeHash.List.BipBop.Sub
What do you dump the other 99% of the poor designs and papercuts on?
But at any rate, shifting blame doesn't help you make a hard system easy by citing a broken tool
> 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
This and the structure of the other pages will give you an insight on how to target the relevant elements.
> A table is a grid. Lot of UI toolkits have a grid container
Sure. As long as the end result is the same grid, it shouldn't matter. But in a CSS world you switch your table for grid-layout divs (or vice versa) and suddenly one corner case thing that is in one grid cell somewhere in your app gets its styling flipped.
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.
What do you think about search override on some dysfunctional modern forums that can't display more than 3 replies, so if you used the built in browser search you wouldn't be able to find anything in a discussion?
But also, Vivaldi is awesome here is allowing you to block overrides for specific shortcuts so you Ctrl F is always yours
> dysfunctional modern forums that can't display more than 3 replies,
I assume that's overzealous virtualization/infinite scroll pagination? I don't have a solution, I think fundamentally we're building a workaround for a workaround and the root cause for the performance issues should be fixed. Somehow, HN is able to show a lot of comments per page and page loads are always O(100ms). I'm wondering what kind of sorcery they're using to achieve this.
But if you have to deal with this in your codebase, my instinct is still not to hijack the native Cmd+F, even if it only searches what's inside your viewport. You can expose some other command for full custom search (Cmd+K seems to be the standard, I think VSCode made that popular).
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
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....
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?
The Mac desktop era before its iOS-ification was, in fact, awesome. It was a triumph of consistency. The UI guidelines were excellent. Nearly every application worked in predictable ways. I appreciated it at the time and I miss it terribly.
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.
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.
Isn't the Macintosh desktop (with Cmd as the modifier for standard shortcuts) older than Windows and Linux desktops? So historically, it's not Apple that deviated but the others?
(I did not do an extensive search into this, so there might be Ctrl-based standard shortcuts that predate Apple.)
Apple moved the Ctrl key around at least a couple times. On the Apple II it was next to the A key, the same as it was on the Xerox Star. The CMD key was a later addition.
At this point, I'd say let history be history. It'd be better to standardize on what most people are using.
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.
> 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.
There are too many issues with those designs of the old, so instead of going regressing into them let’s instead progress towards the fantasy of universal user-centric configuration!
Who do I need 50 different “save” icons in different apps when I could set just one and have instant “idiomatic” recognition anywhere? I could even ditch the text because it’s one of the top 10 commonly used icons that require no text. Oh, and the web apps would also use it in their menus…
Or not, I never need this icon in the first place since I always use a shortcut, so one config change, and now not a single app has the icon!
Can I have “Close” menu use X as an accelerator shortcut everywhere instead of C, and let it work on Windows and Mac and Linux?
Can I not waste the most ergonomic thumb modifier key Alt to open menus I rarely use? And if I waste it, can I also have it working on a Mac, where it would have the same physical position, ie, Cmd?
> Study and follow HTML/CSS idioms whenever possible. For example, a link should be underlined, colorful, pointer on mouseover, and written as an <a> tag.
Moreover, if you change the color, you should also change the color of visited links, otherwise they will be the same color. And ideally, you should use a shade of blue for links, and purple for visited links.
The examples chosen are particularly interesting to me.
In particular Microsoft Word 2000 was panned at the time for not following native conventions. Its inputs, buttons, and File/Edit menus actually do not match the underlying OS.
Do developers who came from Photoshop or Fireworks days actually like Figma? Maybe it's just down to how our designers are using it but I find pawing around a giant 2 dimensional document awkward as hell versus just opening a well named PSD in a folder.
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.
> 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.
Are mobile native apps "idiomatic" then? Speaking of uis made with native frameworks of a specific platform. They surely share some patterns, especially on navigation, top bar, button bar, etc but it's been the death of design and ux. You can't use any app with one hand alone, everything is flat. I share the sentiment that some basic elements should behave the same, like inputs, but I miss the day where we experimented with uis, especially with early internet and flash. Sure many of these looked bad and were horrible to use, but in some ways each one had some character. We basically stopped doing any ui innovation on both the web and native desktop/mobile platforms and that's sad to me
>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.
- "Not-Boxes": Negatively formulated text (disable... / don't...)
- "Button-Checkboxes": Checkboxes with verbs that trigger actions
- "Radio-Checkboxes": Radios that are actually checkboxes (not mutually exclusive)
- "Toggle-Checkboxes": Checkboxes that are actually toggle buttons and can't decided wheter the text should show the current state or the state that will happen when you click.
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.
> 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?
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.
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).
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.
In the Windows 2000 era, you didn't need a product tour or a tooltip onboarding flow because the UI was self-documenting. If a feature existed, it was in the menu bar. If a shortcut existed, it was underlined.
Today, we’ve replaced functional density with clean whitespace. We hide essential features under hamburger menus and invisible long-presses to make the UI look good in a Dribbble shot, then we wonder why we have to spend millions on UX research to see if users can find the Settings button.
We’ve moved from User Interfaces to User Puzzles. We’re essentially forcing every user to learn a new language for every single app they open. It’s a massive, collective drain on global productivity, all for the sake of brand identity.
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
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.
You're confusing it with something else. You don't have to have the same things. But there are basic understanding for UI like how certain elements should work. People might tolerate cos its not on their hands. But the moment they can, they'll make sure to not use it.
This also means more support tickets and internal escalations. Just like how you should drive predictably on road to avoid maximum accidents, predictable UI's are important for maximum productivity. People will use it more. And when they move to another software and don't get the same, they will talk sh*t about it. They will tell people how a certain software is soooo good.
ClickUp for example is the most disastrous UI I've used in recent history. If you get angry while using software, you've done your job poorly. When someone discussed about ClickUp, I immediately shut it down. It's the same reason why people disliked Jira. AWS console Etc. They might tolerate for a while. But they will jump ship at the first opportunity. So can't figure out how it is a feature.
I am basing it on what I have heard normal users say. The easiest thing is what they are used to. People mostly use UIs that are not idiomatic. Websites vary wildly, lots of mobile apps do not stick to conventions, and even some desktops apps do not. For example, what else uses a ribbon menu like MS Office? Most people switch between desktop and mobile. Some people like an app to be consistent across platforms - which means breaking with platform conventions.
People do tolerate AWS Console though. Jira seems to be widely used.
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.
Developing a VB app in the 90's was simple; just drag'n'drop components around the place and boom, you're done. There were very little design choices to make, and most of those were about accessibility rather than style. It had to look like a Windows app, and that was it. A developer could (and we did) slap together screens in minutes, and while they would never win any prizes for best-looking application UI, they were instantly usable by users because they all shared a consistent UX.
Making a web app means following a Figma thing where a designer tried a new experiment with some new thing they read about last week, and it kinda looks OK as a static screen design, but has huge problems as a User Interface because users don't understand it (and that's not even considering accessibility). And as a developer it's a pain in the arse to implement; lots of work to work around the standard way of things working because the designer thinks it looks good.
My personal bugbear on this is scroll bars: just leave the fucking scroll bar alone. No, it's not "pretty", but it tells me how far down the page I am and it's useful. Removing it is actively making my life worse. You are spending effort making my life worse. Stop doing that.
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 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)
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 :)
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.
> 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".
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.
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.
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.
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 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.
"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.
> 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?
Serious question: I have one response for fellow web dev, and another (that would be pedantically explanatory, and maybe even offense to a web dev) for a non-web dev.
> Design is more than styling, it is also behaviour and state,
Maybe I need an example of this for buttons: what behaviour on buttons should be consistent? What about state - what state on buttons should be consistent?
The core value of front-end JavaScript frameworks is state management. You don't need to use a framework, but the need to manage complex application state doesn't go away.
Take this example: when a checkout button on an ecommerce website/application is triggered, the button should reflect that state and prevent re-triggering the same action so the button has to be disabled, then ideally a loading state has to be shown. When that action fails, an error may need to be displayed. Ideally you would use native DOM states first, ARIA states may be used if no native DOM states can be used, and if that's not enough then custom data states may be necessary.
Styling should be reacting to application state, preventing impossible states and bugs to create predictable UIs. Thus, styling is also a state management concern. UI=fn(state).
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.
> 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.
Why do I care about their choice of a screaming color for my buttons?
> same Windows button gray
We don't need to go the other extreme, can there be no middle ground of letting users pick between the boring gray and the bright orange?
You know, a good system could even offer you a choice of palette that takes the website color into account...
> Can you imagine if every button on every site was the same Windows button gray color, regardless of the site's color?
Imagine how cool would it be if we had a pure, logical language where we could set properties in a page based on the properties of the objects around it!
> 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.
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.
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.
It's because enter does different things at different times in the exact same text box.
Write a code snippet/block text. Does [enter] insert a newline, exit the block, or send the message?
What about in a bulleted or numbered list?
And my 2 biggest pet peeves with MS Teams:
1. trying to edit the first letter in a `preformat block`. It's not possible. It will either exit the block or go to the second letter.
2. Consistency with bold/italics. Bold a selection of text. Then backspace once. Are you going to write bold or normal? What does ctrl-B do? Anytime you backspace into a bolded section, it will convert your editing back to bold, and you cannot disable bold.
I have a very small Kevin Bacon number to the "guy who runs Teams". The message from them is "please use the built-in feedback tool to tell us about these things".
I also sent a LOT of Slack messages prematurely for the same reason. Used to it now, though. The more an interface emphasises the single-line nature of a text input, the better. Multi-line should never submit on enter, single-line always should.
Same, but it's configurable in slack so now I have it configured the Enter inserts a line break and Cmd+Enter submits the message
while I haven't changed it, it seems that you configure that behavior in the current version of Teams (Settings > Chats and channels)
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.
> My impression was that teletypes were the first proper keyboard-based interfaces.
They (about) were, AFAIK, but using them with computers wasn’t their first usage.
https://en.wikipedia.org/wiki/Teleprinter:
“A teleprinter (teletypewriter, teletype or TTY) is an electromechanical device used to send and receive typed messages through various communications channels
[…]
Initially, from 1887 at the earliest, teleprinters were used in telegraphy. Electrical telegraphy had been developed decades earlier in the late 1830s and 1840s, then using simpler Morse key equipment and telegraph operators
[…]
With the development of early computers in the 1950s, teleprinters were adapted to allow typed data to be sent to a computer”
Even for that, there was prior art. https://en.wikipedia.org/wiki/Printing_telegraph, which used a piano-style keyboard.
The Linotype also is quite old. https://en.wikipedia.org/wiki/Linotype_machine:
“The Linotype machine operator types text on a 90-character keyboard.
[…]
In July, 1886, the first commercially used Linotype was installed in the printing office of the New York Tribune.”
Mechanical typewriters have different physical mechanisms to feed forward a line or make the carriage return. I think it doesn't turtle much further back than that.
Well around the time of the first typewriters (late 19th century) there where mechanical typesetters, automating the laborious task of typesetting for the printing press. Of course the mechanics of printing where different but as far as I know this is the source of the "keyboard with buttons" type interface for producing literature.
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.
Pianos have keys. And some telegraphs were outfitted with piano-like keyboards with one key per letter. Wikipedia has some pictures in the printing telegraph article [1]. So there is arguably a clear lineage from pianos to the modern computer keyboard.
Pianos however don't really have a concept of advancing the line or sending a recorded message.
1: https://en.wikipedia.org/wiki/Printing_telegraph
player pianos existed with the concept of advancing are recorded messages. I forgot about them until you metioned them. The music box goes way back
Now I am searching to see if there were models of player pianos intended to punch tape.
I have never really thought about it but a player piano sort of implies it can only play the roll. If pressed I would guess that player piano rolls were cut by hand. I mean, I am sure they had tools to help them and probably fully automatic duplication machines. but did anyone play the piano to get a piano roll? or was it more like transcribing sheet music?
here were pianos that could punch a roll, but they were rare - AFAIK there were one offs that the company who made rolls used. The better rolls labels "as played by [someone famous in 1920]" were played on such a system. Once in a while those rolls were used directly in a performance, but the most common use was an expert would use that as the master and then correct all the errors because the transcription system wasn't very accurate (I'm not sure in what way, only that the companies always had an editor make adjustments before selling those roll)
Some of them are on exhibit in a museum - but with a sign saying something like "this will never be restored because it exposes the user to poisonous mercury." If you want to know more join the Musical Box society (I'm a member), or one of the other international clubs for people who collect this type of thing (I know of several but since I'm not a member I can't remember the full name)
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").
I haven’t happened to have seen that - which web apps do it?
Hmm, at this point I think I might be imagining it ... I'll let you know if I can find it ...
Some older Apple keyboards had their backspace button labelled “delete” which to me made it sound like that was the “del” button and not the backspace button.
That was the convention on many older computing platforms.
A "Backspace" key on a typewriter did not actually delete: It merely moved the typing position back one space.
^H^H^H^H^?^?^?
That evil laughter from a disobedient tty. :(
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.
Your advice beautifully reinforces OP's case. We now have to use auxiliary apps with more predictable behaviour because designers made such a mess of things.
We've still yet to reach the "any textbox is just an embedded version of your EDITOR" nirvana.
Note the "very mild" jolt, not quite enough to rise to the level of switching to Notepad (or Emacs in my case).
Shift enter should always put in a new line. Good luck exiting a block though with it.
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.
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…
Unfortunately, some markdown renders differently when copied in vs when typed directly in teams.
Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.
I just tested this on Slack (macOS) and it's not the case. Pressing Enter in a code block submits the message, just as it does for any message.
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.
I would say it mirrors common behavior in the Web, which in turn was largely influenced by old desktop software: Enter in a `<textarea>` inserts a line break, while enter in an `<input>` submits the surrounding form (or does nothing). It is an established idiom after all, many apps just get it wrong.
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.
When you're in a multi code block it should simply never send on (shift+)enter then. Close the code block first.
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.
The worst part is if I paste markdown it's not formatted automatically.
Ctrl-shift-f to apply formatting to literal markdown that's been entered via pasting
There's a setting to toggle this behavior
This is a user preferences setting for what it's worth.
Nice solution for this might be:
Ctrl+Enter: Always submits
Shift+Enter: Always newline (if supported)
Enter: Reasonable default, depending on context
I thought this is how it works for most software. What are the exceptions to this rule?
> I don't know how we got here
I have a suspicion — it has to do with instant messaging clients. The idea being that you want to type short one-line messages and send them as quickly as possible in most cases, but in a rarer case when you do want a line break, that's Ctrl+Enter or Shift+Enter. Probably the first one where I personally encountered "enter is send" is ICQ, but I'm sure it's older than that, I would be surprised if no IRC clients did that.
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.
Yeah this is insane. Maybe most users of chat bots are just sending one line prompts but I find that hard to believe users of Claude code are doing that more often than sending multi-line prompts.
I think this one is easy to explain: it's a clash between chat idioms and forum idioms. Chats since IRC have had Enter=Send because messages were supposed to be single line, while web forums have had multiline text editors from the start so Ctrl+Enter=Send made the most sense. As the two merged, confusion and conflict was inevitable.
We can easily fix this by just letting everyone choose, but no one wants to make configurable UX.
> while web forums have had multiline text editors from the start so Ctrl+Enter=Send made the most sense
This is normal/standard behavior for multiline inputs such as the textarea, while input type=text/search/email will trigger a submit.
https://html.spec.whatwg.org/multipage/form-control-infrastr...
So basically a chat input based on web technology is saying:
"I'm a single line input, but will allow multiline editing if you ask nicely"
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.
I think this is just doing things differently, not fixing them - and IMO not for the better either.
I've been playing with making a chatbot with llama.cpp and FLTK[0] and FLTK's default behavior is actually to add a newline in the multiline editor when pressing Enter even if a 'Return button' is in the form (Return buttons are buttons activated when you press Enter or Return though Return is also handled kinda differently). And i have a big Submit 'Return button' there.
And TBH it annoyed me a LOT that i have to move the mouse and press the button to submit or that Enter adds newlines instead of submitting so that i explicitly added code so that pressing Enter is not handled by the editor (letting the Return button submit the input) and pressing Shift+Enter is what adds the newline (Ctrl+Enter also works, this comes from FLTK's behavior, but i've been used to Shift+Enter myself).
Which is basically how pretty much every chat interface (be it AI chatbot or something like Discord or whatever) that i've used in recent times works. And TBH it makes sense to me that the simplest/easiest shortcut (Enter) is what does the most common thing (send text) in a chat interface whereas the more involved shortcut (Shift+Enter or Ctrl+Enter) is used for the exceptional/less common case. In such an interface, the multiline editing is there as an exception (for when you want to paste some stuff and even then often Ctrl+V by itself can be enough), but most interactions are going to be single line submissions (often wordwrapped to look like multiple lines but still a single line).
[0] https://i.imgur.com/K3m9KAD.png
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.
Hot take — Shift enter to submit should be illegal everywhere. If there's any key chord to submit, it should be Ctrl Enter.
I think I'd be OK with some inconsistency in how Enter works as long as the key chords are consistent!
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.
Win32 standard multiline edit controls use Ctrl+Enter to insert a newline (instead of pushing the default button or "submit" action on a dialog), so that may be where the idiom came from.
For me, Enter to send and Ctrl+Enter for newline is the norm in an IM application, while longer and more asynchronous communication (like this textbox on HN for commenting, or a forum post, or an email client) implies that Enter inserts a newline and something more substantial (Alt+S is common, or Tab,Enter to move to and press the submit button) submits.
> and ctrl-enter forces a newline (not at my computer, but I think Slack does this)
Slack also has the option to invert this in settings. I always have it inverted, so that I can freely type multiline messages, and require the more intentional ctrl-enter to actually send.
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.
> - 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.
Web browsers have been like that by default for ages in text input (single line) vs textarea (multi line). Since way before smartphones even existed.
Regardless, many chat apps on the computer have what look like a multi line textarea but it will be anyone’s guess whether Enter will add a newline or submit in any particular one of them.
> Infuriatingly, some apps try to be smart — only one line, return submits
Tbf, this is almost certainly what the vast majority of people want, most of the time, from chat apps like Slack. It would be much more frustrating to have to click a button after each thought.
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.
Sometimes it's shift enter too! I am having a hard time keeping this straight between applications.
> you're probably more likely to want fancier formatting in a PR review comment than a chat message.
Exactly, and that's how you keep track
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.
Mobile keyboards also do have the advantage that they can at least change the label of the button; so writing Submit on the Enter key if it submits.
> so I press Tab
Now you have a bonus problem: how do you insert a Tab in a multi-line text box?
Enter-to-send is horrible.
ChatGPT does it.
Claude does it.
Nextdoor does it.
And none of those give you the courtesy of being able to turn it off.
Slack does it, but if you dig through the settings you may find the way to switch it.
How on earth did so many "designers" fixate on this idea that we must want to share our thought immediately instead of allowing a calmer interaction?
I can kinda understand why ChatGPT and other chat bots do it. It's a chat interface. Most people chat with single line prompts.
Next door and social media apps, to answer your question, I'm sure a PM somewhere was able to prove that engagement increased if we let people share their thoughts immediately, and the PM got a tidy bonus because of this.
I would be OK if they put a checkbox next to the text input that let me choose whether enter sends or line breaks. I would be OK even if that lived in session storage, to remove the friction of a new Db column. Just give us the option!
Sometimes it's ctrl-enter. Sometimes it's shift-enter. ARGH!
It's even worse on some websites. For example, Grok sends on enter. Even on mobile. Where you can't even press ctrl+enter, because mobile software keyboards don't have a control key. So you can't include line breaks at all when talking to Grok. You can merely accidentally send a message prematurely. (Maybe they have fixed it by now.)
>"bring back idiomatic design" doesn't help when we don't have enough idioms
One must always research and find the dominant or most applicable idioms for whatever they're doing. Are you building a command line tool? For which platform? What other similar tools are you basing its design on? You have to check yourself and see whether your software conforms to the idioms of the platforms, communities, etc that you're targeting.
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.
Precisely. 'member CUA?
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?
> _
A search box, I think
for this reason I use shift+enter. I'm blind and not sure if it starts a new paragraph or is just a paragraph break, but works well enough in my experience.
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.
It should be, but it isn’t. Hence the reason “why can’t you just do what we asked” can often be followed by “then we will find someone who will” in the end.
Pushback is valuable until it becomes obstinance.
If we all somehow had their same crystal ball to know for certain that “stupid shower ideas” won’t work because a specific developer thinks they are bad, there wouldn’t be much need for R&D ever again. I suspect this developer doesn’t have one either, or I’d certainly like to buy it.
Those people generally are not eager for feedback especially if it's even remotely perceived as negative or some kind of gatekeeping.
The only way to avoid getting furious about this is to deeply understand that you can't require people to be properly self-aware, especially because many many people that checks the expert boxes are very incompetent or inadequate, so they when the come up with their half bake ideas, they delegate the other to deliver contrarian proofs. It's exhausting.
How about: It's too easy for users to use the product wrong, leading to unnecessary tech support calls, and doing tech support costs us money.
An underrated senior engineer skill is saving stakeholders from their own worst impulses.
Agreed, but I think it's underrated because the trait could also get someone fired or laid off.
Yeah you don't walk into the job doing it. But once your position is secure and you've built some stuff to where you can make changes in 5 minutes that might take someone else a day, then you can start pushing back on craziness.
There's also an art to how you do it. It's important to build up trust that you won't tell the client something is impossible or really hard just because you don't want to do it. You try to explain to them how much complexity this is going to add, how that will make it harder to add new features in the future, and most importantly offer some alternatives that get them 90% of what they're trying to do. Most clients will appreciate that approach IME, especially if you've already thrilled them a few times.
This is one of the reasons I'm not so worried about Claude taking my job in the immediate future. But I am still extremely worried about the industry as a whole and by extension the future of the middle class.
Yeah I agree. I've worked with my boss in various capacities for the last ten years. When he says "can we do X" my answer is always like "we can do anything, the question is does the company want to allocate Y resources to get X done." Claude, being a yes-man, will always say "you're absolutely right!" to any idea you throw at it, not knowing (and, perhaps more crucially, not caring) if it's the right fit for your product/business.
I think part of the problem is that many engineers don't stick around long enough to build that rapport, which isn't a problem of AI in itself but is certainly exacerbated by it.
Too many people think being good at designing a UI primarily means knowing where to put something on a page.
Honestly, if we could even get that level of thought, it would be an improvement.
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“.
I'm the lead for an internal tool for a non-technical team. We iterate so quickly that the team we're building it for was like "can you guys stop changing things so quickly? We can't keep up with where anything is." which was a fair assessment.
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.
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
Software is now media, not tooling. Media tends to come with a lot of baked in perverse incentives.
Feels like somebody has read their Marshall McLuhan :) I recently started reading Understanding Media, and every chapter delivers at least one mind-melting moment; something he draws attention to and/or frames in some way.
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
That would happen in a free market, but software is intentionally not a free market thanks to copyright/patent laws. In software, lock-in effects dominate. People will continue using bad software because it's necessary to interoperate with bad software other people are using. There's a coordination problem where everybody would be better off if they collectively switched to better software, but any individual is worse off if they're the first to switch.
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
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).
I have an AutoHotkey that just takes whatever is in my clipboard and sends it through as individual virtual keystrokes, specifically for defeating paste-disabled form fields.
It gets way more use than I wish it did.
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.
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?
This is the kind of thinking that takes a normal credit card form and makes it so weird that auto fill doesn't work.
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
> 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.
>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.
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
I was writing VB desktop apps when that whole ribbon menu thing came in. Everyone hated it. Literally everyone.
> 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).
It doesn't matter that different platforms have different standards, as long as applications on any given platform are mostly consistent.
I don't care if your app looks different on Windows, because I'm on a Mac. I care that it behaves like a Mac application, and the muscle memory I have from all my other Mac apps also works on yours.
If you say that too loud, the “but my brands unique UI supersedes your functional requirements” people will emerge, screeching, from the woodwork!
I can’t prove it, but I just know they’re the ones who live their lives one NPS score at a time, and must think that we operate our software, being thankful for every custom animation that they force us to sit through on their otherwise broken and unimportant software.
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.
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.
> 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.
As a designer, the issue I see is that desktop design requires knowledge and experience of the native toolkits.
This makes desktop the hardest platform to design (well) for.
For example, on macOS you need to know about where the customisation points are in NSMenu, you need to know a little about the responder chain etc.
Most designers only have web or mobile experience, and the nuances of the desktop get lost, even at th design stage. You end up with a custom and shallow system that is weird in the context of the OS.
You also end up with stuff like no context menus, weird hover states (hand cursors anyone?), weird font and UI sizing (why are Spotify's UI elements literally twice the size of native controls? The saving grace of it being an Electron app is that I can zoom out 3 steps to make the UI size sane). I digress...
> 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.
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”
> 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.
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 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.
> 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.
Perhaps the situation has changed since I last tried.
It used to be, in AppKit, that a normal NSButton could have its size class changed (small, regular etc.) but you couldn't set the height without subclassing and doing the background drawing yourself!
Bootstrap was nice.
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.
> 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.
And even when they let you type it in, sometimes it turns out that the website was made by Americans and so expects the bonkers date format of MM/DD/YYYY.
A good example of appropriate use of a calendar interface on a flight booking website is Aviasales. They show flight prices for each day right there, so if your travel dates are flexible, you know when it's cheaper by just looking at it! This should be a standard feature.
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.
That can get messy and confusing if the user's locale is different from the language of the web page.
When I write in English, I of course also want to edit dates and numbers using English conventions. But instead, I am forced to use decimal comma and day/month order because those are the default locale for Swedish, which is my default locale. I have never encountered an OS that doesn't work that way. On the web you'll often don't know: it could be anything.
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?
Exactly. Under Windows, this isn't even consistent across applications. I'm in France, with the location set to France, using English display language and "English (Europe)" formatting. This means that the expected date is DD/MM/YYYY. It's what shows up in the taskbar, for example. But many applications seem to do this based on language, so I sometimes get MM/DD/YYYY.
I don't normally run Windows, so I can't check right now, but I think it's mostly "modern" applications that mess this up. Like the MS Store, Teams (obviously).
the only locale i know about is the windows one that's hidden in some menu that i had to set to japan to get some random application to run, and now all of my backslashes look like yen symbols :P ... maybe i won't get mm/dd/yyyy now!
I think modern browsers are actually quite good here. They show a template in the form TT.MM.JJJJ for me (so the German equivalent of MM/DD/YYYY, with the usual order and separator in German). I can just type the date, including the dots if I want (they're just ignored; there would be extra points for moving me to the next component when typing "2.", but the world's not perfect). If I'm confused about the format, or want to see a calendar view, I can click on the calendar icon (also accessible via tab) and select a date there.
For normal date inputs, I really don't think there is a good reason to use anything else. (Possible exceptions I can think of: Selecting date ranges and/or showing extra data about the dates (like daily prices).)
No, modern browsers are horrible at this as they are often ignoring your settings (at least Chrome and Edge on Windows do). They are basing the format entirely on the language instead of the date format configured in your Windows settings. Safari on iOS seems to not have this issue though as far as I can tell.
https://stackoverflow.com/questions/7372038/is-there-any-way...
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.
Well, the issue is when the applications look at the wrong configuration to set this up.
Think about traveling to a different country for a limited time. I want my location, time zone, etc to be set to where I am. I traveled across the US a few years ago, and I would rather not have to mentally follow in which time zone I was. Heck, I don't even know where the limits are. Bonus points for DST happening on a different date than in Europe, and extra bonus for there being no DST in Arizona, except for Navajo Nation? I remember signs saying it was illegal to carry alcohol, but I don't recall anything about time zones.
But as a European, I don't want my date to suddenly appear in US format; I'm only there for a few weeks.
> 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.
> 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.
It's normal in Asia.
I'm not in Asia though.
It's also normal to speak Chinese in China. That doesn't mean that I should be speaking Chinese as well.
> "Normal" people never use YYYY-MM-DD format.
My point was that this isn't true.
And Sweden. And probably lots of other countries too. It's a world standard, and there are very few places that use hyphens in dates that are not ISO dates.
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
Iso 8601![0]
[0] https://en.wikipedia.org/wiki/ISO_8601
Just spell the month.
https://parkscomputing.com/page/just-spell-the-month
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.
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.
This has a solved problem for a long time
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
Most of these I just say I am 200 years old or so.
Thank you so much for writing this. I'm also from the desktop era and I can't STAND all the reinvention going on, or the fact that I have to move the mouse all over the screen or randomly stab my phone with my finger to find out what I can interact with.
I'm working on a GUI app and a web app in concert right now. They work in the same niche, but at different levels (one is desktop-level management, the other is enterprise-level management). I stepped back and developed a unified design language (Tela Design Language, or TDL) which has saved my sanity and made the apps actually usable again.
https://parkscomputing.com/content/tdl-reference.html
https://github.com/paulmooreparks/tela/blob/main/TELA-DESIGN...
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.
On mobile it made sense on the original 320px wide iPhone screen. On the huge screens we have today, less so.
For group chats in Microsoft Teams with more than seven participants, if you click on "View and add participants" (an icon with two people and a plus sign) you see a list of seven participants. At first I didn't know that you could scroll in this list.
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.
> 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...
There's tons of research on this. Use words.
It varies, some applications - the ones that people spend their workday in - have specific iconography that is domain specific for that application.
A difference needs to be made between general public applications and domain specific employee applications. SAP is a great example of this. Of domain specific icons I mean, not of good UX design.
...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 not true. Just today for example, in android at least, I went to whatsapp, selected a chat with long tap, I want to archive the chat. I have a download like button. Apparently that is the archive button. I had no idea.
If it was the opening to the alternate dimension, I wouldn't still know. If it was something harmful like backup and delete, I wouldnt know. I just took the plunge and hoped it wasn't gonna be harmful. Luckily it was archive.
These kind of stupid things are there now in their calling screen and other places. Absolutely ridiculous and hard for me. Now imagine my parents who are 60+!!
Easier has more than one dimension (speed, error rate, recall, precision, cognitive load), but the baseline for generic statements is not one particular, very rare task. That's anecdote.
And in this case, the statement was about recognition, not intuition. Otherwise there are counter arguments: there are enough words in UIs which do not have an intuitive meaning either. "New" would be one. New what? File and folder are others, especially with decreasing awareness of the file system under young generations.
I'd say that you recognized the button fast enough, but the wrong function was attached to it. It's as if they would have had a menu item called "Download" which would archive.
> Now imagine my parents who are 60+!!
I can, because I am too.
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.
You're wrong. There's a body of literature on this. I encourage you to review it.
It's a little interesting that they would pick Office 2000 as an example, since Office 97 and onwards do not use standard OS widgets -- it reimplements and draws them itself*.
The menu bar in Office 2000 does not look like the standard OS menu bar, for instance. The colors, icons and spacing are non-standard. This is only slightly jarring, because it's pretty well done, but it's still inconsistent with every other app.
This was kind of the beginning of the end for Windows consistency -- when even Microsoft thought that their own toolkit and UX standards were insufficient for their flagship application. Things have only become worse since then.
* This becomes very obvious when you run Office 97 on NT 3.51, which generally looks like Windows 3.1, but since Office 97 renders itself and does not care about OS widgets, it looks like this: http://toastytech.com/guis/nt351word.png
This is funny because Teams on Windows uses its custom notifications instead of the system ones. But running it in a browser under Linux, I get my native notifications!
> 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.
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.
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.
I think the answer is they just don't know.
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.
And yet, Microsoft is still doing their own thing. It's a shame they didn't follow through with, and / or the industry didn't follow along with, Windows Phone because it was a pretty unique design.
Google / Material Design also does their own thing still.
Squircles[1].
[1] https://en.wikipedia.org/wiki/Squircle
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.
I like how it became uncool about 10 years ago for buttons to provide any feedback that they've been pressed. Thanks Tim Apple!
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.
And knowing how to get the version of an application (which used to be in Help -> About).
Also having the cursor show up in the proper place on a new form and having tab order work.
Oh yeah.
Keyboard focus and focus indication on browsers is fundamentally broken.
We often notice when focus is buggy. But there are many many hidden/unobvious edge cases.
Previously I created a fix for the worst focusing issues on browsers by creating a fully custom framework (before modern HTML help with popovers/dialogs/overlays/viewports/anchors). No other framework at the time managed Internet Explorer's quirks very well (we served businesses who mostly used that browser).
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....
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.
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)
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...
> It's pretty easy. Open the inspector, select an element and you will find all the styles that apply.
Of course it's not easy, 80% of that list will be some garbage like global variables I would only need when I actually see them in a style value, not all the time.
The names are often unintuitive, and search is primitive anyway, so that's of little help. And the values are just as bad, with --vars() and !important needless verbosity in this aborted attempt of a programming language
Then there is this potentiality more useful "Computed" styles tab, but even for the most primitive property: Width, it often fails and is not able to click-to-find where the style is coming from
> Also styles are semantics like:
That's another myth. You style could just be. ReactComponentModel.ReactComponentSubmodel.hkjgsrtio.VeryImportantToIncludeHash.List.BipBop.Sub
What does that inspire in you when you read it?
Someone is using Tailwind (and the likes) and/or CSS-in-JS. Which I dump squarely in the weird tools.
What do you dump the other 99% of the poor designs and papercuts on? But at any rate, shifting blame doesn't help you make a hard system easy by citing a broken tool
> 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
This and the structure of the other pages will give you an insight on how to target the relevant elements.> As an example, the structure of HN's reply page
Is made up of table tags, which the CSS people will tell you is wrong/impossible/has different semantics.
> Is made up of table tags, which the CSS people will tell you is wrong/impossible/has different semantics
A table is a grid. Lot of UI toolkits have a grid container, and even CSS added it specifically as a layout engine.
> A table is a grid. Lot of UI toolkits have a grid container
Sure. As long as the end result is the same grid, it shouldn't matter. But in a CSS world you switch your table for grid-layout divs (or vice versa) and suddenly one corner case thing that is in one grid cell somewhere in your app gets its styling flipped.
You should talk the people behind the vanillajs framework, this sounds like it might work well over there.
http://vanilla-js.com/
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.
What do you think about search override on some dysfunctional modern forums that can't display more than 3 replies, so if you used the built in browser search you wouldn't be able to find anything in a discussion?
But also, Vivaldi is awesome here is allowing you to block overrides for specific shortcuts so you Ctrl F is always yours
> dysfunctional modern forums that can't display more than 3 replies,
I assume that's overzealous virtualization/infinite scroll pagination? I don't have a solution, I think fundamentally we're building a workaround for a workaround and the root cause for the performance issues should be fixed. Somehow, HN is able to show a lot of comments per page and page loads are always O(100ms). I'm wondering what kind of sorcery they're using to achieve this.
But if you have to deal with this in your codebase, my instinct is still not to hijack the native Cmd+F, even if it only searches what's inside your viewport. You can expose some other command for full custom search (Cmd+K seems to be the standard, I think VSCode made that popular).
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
Usable has to come first. That's what all these designer types are missing. It's user interaction design, not visual design. The interaction is key.
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....
> The visuals feel a little ugly and dated: it’s blocky, the font isn’t great, and the colors are dull.
I don't get this at all. I find the screenshot clear and beautiful if anything.
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?
The Mac desktop era before its iOS-ification was, in fact, awesome. It was a triumph of consistency. The UI guidelines were excellent. Nearly every application worked in predictable ways. I appreciated it at the time and I miss it terribly.
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.
As a tangent, he has so many really important pieces of advice, naming one as "Jakob's Law" is deeply impractical.
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.
Isn't the Macintosh desktop (with Cmd as the modifier for standard shortcuts) older than Windows and Linux desktops? So historically, it's not Apple that deviated but the others?
(I did not do an extensive search into this, so there might be Ctrl-based standard shortcuts that predate Apple.)
Apple moved the Ctrl key around at least a couple times. On the Apple II it was next to the A key, the same as it was on the Xerox Star. The CMD key was a later addition.
At this point, I'd say let history be history. It'd be better to standardize on what most people are using.
Yes, the Cmd key has been around since 1984.
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.
> 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.
There are too many issues with those designs of the old, so instead of going regressing into them let’s instead progress towards the fantasy of universal user-centric configuration!
Who do I need 50 different “save” icons in different apps when I could set just one and have instant “idiomatic” recognition anywhere? I could even ditch the text because it’s one of the top 10 commonly used icons that require no text. Oh, and the web apps would also use it in their menus… Or not, I never need this icon in the first place since I always use a shortcut, so one config change, and now not a single app has the icon!
Can I have “Close” menu use X as an accelerator shortcut everywhere instead of C, and let it work on Windows and Mac and Linux?
Can I not waste the most ergonomic thumb modifier key Alt to open menus I rarely use? And if I waste it, can I also have it working on a Mac, where it would have the same physical position, ie, Cmd?
> Study and follow HTML/CSS idioms whenever possible. For example, a link should be underlined, colorful, pointer on mouseover, and written as an <a> tag.
Moreover, if you change the color, you should also change the color of visited links, otherwise they will be the same color. And ideally, you should use a shade of blue for links, and purple for visited links.
The examples chosen are particularly interesting to me.
In particular Microsoft Word 2000 was panned at the time for not following native conventions. Its inputs, buttons, and File/Edit menus actually do not match the underlying OS.
Do developers who came from Photoshop or Fireworks days actually like Figma? Maybe it's just down to how our designers are using it but I find pawing around a giant 2 dimensional document awkward as hell versus just opening a well named PSD in a folder.
I mean, looking at it in 2026 Word 2000 looks _amazing_. How far my standards have fallen.
And yeah, I've met a lot of people who love Figma. I hate it so much, personally, getting around and finding what I need in it is so much pain.
> 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.
This is the kind of thing why I still prefer Windows as a UI.
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.
Age doesn't matter, usability and consistency does, so that's a valid complaint towards all those hostile apps that haven't changed the defaults
This is why Apple gave Macs a command key in 1984. Control is for sending control cides; command is for issuing commands!
Plan 9 fixes this.
> 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.
Are mobile native apps "idiomatic" then? Speaking of uis made with native frameworks of a specific platform. They surely share some patterns, especially on navigation, top bar, button bar, etc but it's been the death of design and ux. You can't use any app with one hand alone, everything is flat. I share the sentiment that some basic elements should behave the same, like inputs, but I miss the day where we experimented with uis, especially with early internet and flash. Sure many of these looked bad and were horrible to use, but in some ways each one had some character. We basically stopped doing any ui innovation on both the web and native desktop/mobile platforms and that's sad to me
>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.
A few of my favorites:
- "Not-Boxes": Negatively formulated text (disable... / don't...)
- "Button-Checkboxes": Checkboxes with verbs that trigger actions
- "Radio-Checkboxes": Radios that are actually checkboxes (not mutually exclusive)
- "Toggle-Checkboxes": Checkboxes that are actually toggle buttons and can't decided wheter the text should show the current state or the state that will happen when you click.
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?
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.
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.
But I'm not convinced the old consistency was purely a design victory... it was also a result of heavy constraints
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).
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!
https://news.ycombinator.com/item?id=22475521
There are quite a number of them: <https://en.wikipedia.org/wiki/Human_interface_guidelines#Exa...>
I think it was a Xerox thing. But since the 90s, everybody has some since.
Oh, and if you want to read one to learn, the Microsoft ones are better than the Apple's.
In the Windows 2000 era, you didn't need a product tour or a tooltip onboarding flow because the UI was self-documenting. If a feature existed, it was in the menu bar. If a shortcut existed, it was underlined.
Today, we’ve replaced functional density with clean whitespace. We hide essential features under hamburger menus and invisible long-presses to make the UI look good in a Dribbble shot, then we wonder why we have to spend millions on UX research to see if users can find the Settings button.
We’ve moved from User Interfaces to User Puzzles. We’re essentially forcing every user to learn a new language for every single app they open. It’s a massive, collective drain on global productivity, all for the sake of brand identity.
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
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?
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.
This is a feature, not a bug. By making your software different you make it harder for people to switch.
You're confusing it with something else. You don't have to have the same things. But there are basic understanding for UI like how certain elements should work. People might tolerate cos its not on their hands. But the moment they can, they'll make sure to not use it.
This also means more support tickets and internal escalations. Just like how you should drive predictably on road to avoid maximum accidents, predictable UI's are important for maximum productivity. People will use it more. And when they move to another software and don't get the same, they will talk sh*t about it. They will tell people how a certain software is soooo good.
ClickUp for example is the most disastrous UI I've used in recent history. If you get angry while using software, you've done your job poorly. When someone discussed about ClickUp, I immediately shut it down. It's the same reason why people disliked Jira. AWS console Etc. They might tolerate for a while. But they will jump ship at the first opportunity. So can't figure out how it is a feature.
I am basing it on what I have heard normal users say. The easiest thing is what they are used to. People mostly use UIs that are not idiomatic. Websites vary wildly, lots of mobile apps do not stick to conventions, and even some desktops apps do not. For example, what else uses a ribbon menu like MS Office? Most people switch between desktop and mobile. Some people like an app to be consistent across platforms - which means breaking with platform conventions.
People do tolerate AWS Console though. Jira seems to be widely used.
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.
It's not only the users that are frustrated.
Developing a VB app in the 90's was simple; just drag'n'drop components around the place and boom, you're done. There were very little design choices to make, and most of those were about accessibility rather than style. It had to look like a Windows app, and that was it. A developer could (and we did) slap together screens in minutes, and while they would never win any prizes for best-looking application UI, they were instantly usable by users because they all shared a consistent UX.
Making a web app means following a Figma thing where a designer tried a new experiment with some new thing they read about last week, and it kinda looks OK as a static screen design, but has huge problems as a User Interface because users don't understand it (and that's not even considering accessibility). And as a developer it's a pain in the arse to implement; lots of work to work around the standard way of things working because the designer thinks it looks good.
My personal bugbear on this is scroll bars: just leave the fucking scroll bar alone. No, it's not "pretty", but it tells me how far down the page I am and it's useful. Removing it is actively making my life worse. You are spending effort making my life worse. Stop doing that.
Day-to-day usability doesn't bring much "wow" factor to a sales pitch.
That windows 2000/win 95 interface was peak windows design.
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)
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?
Seconded. Your browser is probably set to clear cookies on close.
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.
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.
They were not. Their own apps on iOS are wildly inconsistent.
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".
[1]: https://www.nngroup.com/articles/flat-design/
[2]: https://geekyants.com/blog/affordances-in-ui-design
... and please stop doing paralax...
Such a nice way to give more depth to your content. </s>
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 want to be able to sit down at a fresh install (or someone else's) and not spend time learning their preferences.
This is impossible: someone else is also capable of customizing
But also, what 0% of your use cases are fresh installs with config wiped out and not restored?
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.
> The visuals feel a little ugly and dated
It's... beautiful.
> Apple is a great example.
... checks publication date ...
... right, 2023. I think the article needs an update.
(2023)
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.
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.
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.
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?
"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.
> 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?
Do you have any idea what you are talking about?
Serious question: I have one response for fellow web dev, and another (that would be pedantically explanatory, and maybe even offense to a web dev) for a non-web dev.
Design is more than styling, it is also behaviour and state, which is what react helps you encapsulate in a component.
> Design is more than styling, it is also behaviour and state,
Maybe I need an example of this for buttons: what behaviour on buttons should be consistent? What about state - what state on buttons should be consistent?
The core value of front-end JavaScript frameworks is state management. You don't need to use a framework, but the need to manage complex application state doesn't go away.
Take this example: when a checkout button on an ecommerce website/application is triggered, the button should reflect that state and prevent re-triggering the same action so the button has to be disabled, then ideally a loading state has to be shown. When that action fails, an error may need to be displayed. Ideally you would use native DOM states first, ARIA states may be used if no native DOM states can be used, and if that's not enough then custom data states may be necessary.
Styling should be reacting to application state, preventing impossible states and bugs to create predictable UIs. Thus, styling is also a state management concern. UI=fn(state).
> 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.
> 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.
> Amazon to make all their buttons orange
> It'd be awful!
Why do I care about their choice of a screaming color for my buttons?
> same Windows button gray
We don't need to go the other extreme, can there be no middle ground of letting users pick between the boring gray and the bright orange? You know, a good system could even offer you a choice of palette that takes the website color into account...
>>> 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?
Imagine how cool would it be if we had a pure, logical language where we could set properties in a page based on the properties of the objects around it!
> 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.