Do all web forms have a left aligned button by default? I just realized they do on HN but if you'd asked me 5 minutes ago I'd have told you it was on the right.

Determining which those are can be really hard depending on how your users use your app. And won't always be universal. The example of the "commonly used" closed window versus quit app... the destructiveness of the former is equivalent.

When one is a common action and the other causes more pain when performed accidentally, it's been more helpful to add an option to ask if that was the intended action than to retrain now-generations of users on keyboard commands. Cmd+Q/Cmd+W have been used this way since I was in diapers.

We don't have to go back to skeuomorphism of the old iphones, but whenever I use my phone I have no idea what's tappable and what's not. There's even this trend now of not making it obvious what's even a text box or what's not. It /looks/ nice, but it's infuriating to use. And then you have the weird gestures that are completely undiscoverable. Like pulling down from the top right to get the utility menu thing. I mean, yeah, I know it's there, but I never would have actually discovered that on my own. Also now there's this trend of just hiding everything to make an app look minimalistic and simple even though it's not. So I have no idea what it can even do when I look at it. And I /still/ have no idea how to properly line up apps side by side on my iPad. I mean I kind of do, but I constantly forget, and worse, once I do have them lined up, it's hard to get rid of them. It's all insanely undiscoverable.

I wish UX designers would realize it's not all about being pretty, you have to actually give people an idea of what things actually DO. All the clunky old interfaces with the bevelled buttons and huge scroll bars and stuff might have been ugly as sin, but at least they weren't a constant confusion.

The thing the author doesn't seem to realize / acknowledge is that UI/UX design is about balancing enormous numbers of competing constraints and concerns. It's a human problem, and like most problems of this genre there is no "best" answer, only different sets of weights for different, often competing, concerns. Simplicity and ease of use are good things, but they are almost always at odds with flexibility and power...also good things. Do you make things bigger with more space so they're easier to see, or do you make them smaller so you can fit more things on the page? Do you use color so you can communicate more and catch the eye more quickly, or do you avoid that so that your app is friendly to colorblind users? (Yes, I know there are color schemes that can achieve both to a decent degree.)

These kinds of tradeoffs are lurking almost everywhere you look in UI/UX design, but this kind of nuance seems to be lost on the author. He only seems to see his set of priorities for a UI. Yes, there are plenty of cases where one thing is pretty objectively worse than another, but usually it's more subtle than that. I'm way more impressed with someone who can talk intelligently about the tradeoffs than I am with someone who fixates on something that very well might have been traded off and rant about it.

I can't be the only one getting confused about this on a regular basis.

Firstly, I've observed a phenomenon when I talk to a programmer about a problem I want to solve. They might get excited, learn a bit of the problem domain and then go off and build something that kind of solves part of my problem. But then I'm stuck in a endless cycle of explaining the rest of the problem, to someone who isn't really interested, then waiting for a new iteration and then evaluating how it doesn't completely the solve the problem until the programmer gets bored and goes off to find something new and exciting to do with computers. Programming the computerwas always the end for them. They don't actually care about the problem. I care about the problem. So for me computers are a tool to solve my problem. I might as well write the program myself because it's less work to become a mediocre programmer than to intimately understand the problem.

My theory is that something like this happens in interface design. There are designers who love to create beautiful designs, and we love that, but beauty is the end of it for them. They don't actually care about the problem that the program (website, app, whatever) is supposed to solve. If they were stuck in a job filling out forms all day they would quickly learn the lesson to put the reset button out of the way. If they were intimately familiar with the problem, the better design would be obvious. And so it is that people with no "design skills" can point out the obvious mistakes of the designers.

It's also true that good design is hard. Starting with a blank sheet and creating something, let alone something good, is daunting. Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well.

Oh man, I actually remapped quit on Firefox because this bit me too many times and Firefox kept removing ways to confirm quit. I will die on the hill that "confirm quit" is the correct behavior.

(I have, in fact, died on this hill enough times I may be outing my HN burner with this comment.)

Not all UI elements should have the same visual weight

If you have 3 buttons, probably one of those buttons will be pressed 80% of the time, and the other buttons pressed less than 10% of the time. How do you style those buttons?

As a programmer, we like to think of the three buttons symmetrically. We want all the buttons to look the same and behave the same, because then they're easier to style and easier to reason about. Our instinct is to make a button class and then place all the buttons next to each other in a nice neat table.

To a user, the three buttons are different, and it should be obvious which one is the button you're expected to press most of the time. From the user's perspective, "Submit form" isn't really the same type of UI element as "reset form". The submit button should be big, bold, colorful and obvious. My eyes should naturally settle on it. The reset form button (if it exists) should be small and non-obvious. Its an advanced feature. It should be out of the way and most people should never notice it.

My email compose window has this problem. It has 3 buttons - "Send", "Save Draft" and "Discard". When I'm writing an email, I'm not choosing between 3 equivalent options. I hit send about 80% of the time I type an email. Once I've written an email, if I visually hunt for the obvious button on the screen, my eyes should naturally settle on "Send". Styling should make that obvious. But no - there are 3 buttons I have to choose from. They're all next to each other, and they're all styled in an identical manner. The interface makes users actively hunt for the "Send" action. This is bad UX.

This video shows it at 6:33 https://m.youtube.com/watch?v=dKx1wnXClcI&t=6m33s

I was sharing my screen, then using the chat, muting, unmuting, and eventually went to unmute and was jacked out of the call, with not even a "Hey, are you sure you want to leave?"

> this particular problem is apparent even to a blockhead like me

> So it must be extremely obvious

"I'm not an expert, and even I can see that" sounds reasonable, but it's often used to disagree with experts. Whereas it's not unlikely that while it may look obvious to a layman, someone with more familiarity with a problem might know about non-obvious trade-offs that come with the "obvious" solution.

All of which doesn't necessarily relate to the article, the rest of which I'm going to read now - I just found it interesting, and wanted to share.

https://imgur.com/a/HO6oi2F

As organizational complexity increases, design debt and responsibility becomes diffused among larger and larger groups of people. Leading to the bizarre situation where no individual has power or responsibility over anything specifically.

Any individual interface element might have taken input from as many as 100+ different people over many years, each with competing interests and goals (no, I'm not joking). Combine this with the precedents and decisions made on projects in the past (design debt), and you end up with stupid outcomes like this.

As a multiple FAANG alumni, I've seen this firsthand hundreds of times.

I think it's cute that people think IC designers or engineers have the power to make any real decisions inside large organizations.

What's more likely, is these stupid icons were part of some design system somebody created 7 years ago (have to stay consistent of course!). The circular floating buttons were a precedent somebody set 5 years ago on a completely different product (god forbid it feels "off-brand"). The colors were set 6 years ago on some project where this kind of application was never thought of.

And finally, the order & placement of the icons was changed 15 times by some PM, then the PM's boss, then the accessibility guys, then the brand team, the brand team's boss, then the director of marketing, etc. etc. The tie breaking vote going to whoever is perceived as having more soft power inside the org at the time.

Hence, the inevitable outcome of big company stupidity.

The big fat red phone button means "click this button to achieve the state that is depicted on the button (hung up)".

Okay, so good so far, by clicking a button, you get whatever is pictured on it. Makes sense.

One would thus think that similarly, a picture of a muted microphone on a button means "click to mute" and a picture of an unmuted microphone on a button means "click to talk" and this is backwards from what they actually mean.

https://dev.to/swyx/my-new-mac-setup-4ibi/

"When I came to Washington before World War II to head the electrical section of the Bureau of Ships, I found that one man was in charge of design, another of production, a third handled maintenance, while a fourth dealt with fiscal matters. The entire bureau operated that way. It didn’t make sense to me. Design problems showed up in production, production errors showed up in maintenance, and financial matters reached into all areas. I changed the system. I made one man responsible for his entire area of equipment—for design, production, maintenance, and contracting. If anything went wrong, I knew exactly at whom to point. I run my present organization on the same principle." -Admiral Rickover, creator of the US Nuclear Navy

the hang-up button in between the audio- and video- mute buttons results from the lack of responsibility described above. any single person would agree this is wrong, therefor no single person is in charge.

Pictures are nice. And I get that they are maybe easier for i18n. But if it isn't completely clear what the picture is supposed to mean (and everybody seems to like their own) then it understanding what the heck to do can take some time.

I value my time.

I'm still looking for the "back" button on my Apple TV. I seem to be easily able to touch something that takes me to some unknown place and basically have to start over.

In a word, I would tell the FAANGs: don't re-invent UI. You're simply not good enough at it. Simple, repeatable and ugly is much preferable to confusing and pretty.

The timer app has a similar UI, two buttons, one to repeat, and one to stop, spaced out. The problem: They are swapped!

When I first started developing software in the mid-late `90s I bought a book published by Apple called "Apple Human Interface Guidelines". I expected it to be a very technical book, but it felt more like an 5th grade level school book with lots of cartoonish illustrations and very simple language. At first I was very disappointed. I sped through it and felt I'd learned nothing.

After a few days I picked it up and went through it again. It only took about 10 minutes to read it. It explained how the GUI widgets were based on UIs that people were familiar with, like the old Radios in cars with push buttons that changed the radio station and check boxes used on printed forms and then it began to dawn on me just how brilliant that design was, and how well that book was written. So well most any 5th grader could understand it.

In my own software I've been tempted to use one of the many "Icon" galleries we have to choose from now but decided not too. I opted for simple links and buttons with short but descriptive words, like "Preferences" and "New Document" and "Reports".

There are icons for all of those, but my users don't need to learn what those stand for, and really don't want to. It's silly for me to expect them to learn the purpose of an icon in my app when every other app they use might implement them for a different purpose.

Sometimes "a picture is worth a thousand words" is not a good thing. Sometimes just a word or two is a lot better.

No specific advantage has actually been attributed to either choice of order. What matters is (1) keeping the order consistent throughout an application, and (2) following the provided style guide for the platform you're developing on.

(Also, the order may need to be changed if the primary action is destructive, such as a "Reset" button.)

I did an extensive write-up about this topic if you're curious on more details: https://dev.to/sergix/ux-illuminating-intention-198k

For example I would think this makes much more sense:

  Name                 [arp242                 ]
  Email                [arp242@example.com     ]
  I have a HN account  []

                       [Submit]

  Name                 [arp242                 ]
  Email                [arp242@example.com     ]
  I have a HN account  []

                                        [Submit]

This also works much better if you put the labels above the inputs:

  Name
  [arp242                 ]

  Email
  [arp242@example.com     ]

  [] I have a HN account

  [Submit]

                   [Submit]

And people read things from left-to-right; I find left-alignment almost always more natural; this is why most navigation sidebars are also on the left (which is often also inverted in websites using right-to-left scripts).

It's even worse if you also place a reset button; I would imagine more than a few people in a hurry will accidentally reset forms if it's placed on the left and has equal prominence to submit. Aas the article already mentioned, you probably shouldn't have a reset button at all, and most forms these days don't.

Anyway, I think "it goes forward in the procedure, in time" is overthinking these things too much in too abstract terms. Just put things where people's eyes and mouse cursor will naturally go for these kind of things will get you a long way.

All of that being said, consistency is also important, so if there's a system/platform where things are consistently on the right then sticking to that is usually more important.

Everyone and their mother has an opinion on what they think is good design. I am thankful that as a developer I am not having to fight over pixel pushing.

Try finding the menu item that brings back the app once you've quit.

But it's not all bad; you can't put heaps of buttons on a mobile interface because of the limited screen size and lack of precision with pressing them, so some amount of 'magic' and hiding is necessary imo.

It's rare to see it solved cleanly. I try to avoid interface elements that attempt to combine these two roles entirely.

I quite like the way the Twitter "Follow" button works: when you click it the text changes to "Following", which I think is just clear enough, but only because it's a button that every Twitter uses frequently enough that they are likely to remember how it works.

Windows: "Right-align commit buttons in a single row across the bottom of the dialog box, but above the footnote area. Do this even if there is a single commit button (such as OK)."

Mac: "Any buttons in the bottom right of a dialog should dismiss the dialog. An action button, which initiates the dialog’s primary action, should be farthest to the right." (Also noteworthy: "Separate destructive buttons from nondestructive buttons.")

    browser.quitShortcut.disabled true

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=52821 (only took 21 years, jeez)

I do believe there are programmers for every category though.

[1] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...

- Swipe from bottom to wake. - Swipe from bottom whilst inside an app, peaks all open apps, once let go it fully minimizes the app. During a peek you also see the number of unread notifications on the left. - Swipe from left to go back. - Swipe from bottom, then to the right to access the BlackBerry hub, which aggregates ALL emails/IMs/notifications in a single list (can be customized into groups). - Swipe from bottom left corner towards center hides on-screen-keyboard. - Top swipe displays app specific option/help/misc links. - 2-finger swipe from top revealed quick settings (wifi, flashlight, etc). No notifications here (they're in the hub)! - Not swiping, but it had a clean, single unified location for all app notification/permissions/etc which feels much easier than Android.

I feel if BlackBerry released the Q10 2-3 years earlier we would have had a totally different phone ecosystem today. I still miss it.

I think a lot of the methodological knowledge built by usability people has probably been ignored in favour of a metric-driven approach these days. That approach is very good at identifying bottlenecks in existing workflows or deciding between two ideas, but ultimately lacks the empathy you describe. You can only really build that by engaging directly with users, and watching them suffer at the hands of your creations.

Having it on the left, imo, people might look there first but continue to scan to see what the other control is. When you finish reading a sentence of text in a paragraph, you certainly have the last word of it stick out, how is this different?

I know, there are open source business models which work for some companies and that's true but generally in the sorts of technical problems for IT people. Compared to the IT industry as a whole those are edge cases. They seem more important to us embedded in the IT industry, but compared to the overall multi-trillion dollar global IT industry they're peanuts.

When forms were implemented, it was important to keep the behavior consistent with what people experienced in their OS.

Now that we have touch phones, the situation has changed, but the best practices have not.

In my experience designers are the worst people to hire for UX because they often sacrifice usability for aesthetics. Programmers fare a bit better (usable UI usually doesn't conflict with the code quality), still not perfect though. Casual users are probably best, with some education in usability of course.

For this specific problem (Google Meet UX/UI) sure anyone agree with: don't put a destructive action that requires no confirmation (leaving the meeting) next to a common action (mute/unmute yourself). If designers don't get that right, sorry but they are not competent designers. It's like a programmer that, in order to "balance enormous numbers of competing constraints and concerns" decides to not escape user-provided HTML in the frontend. Well, that programmer is not a competent one.

512 x 342 x 1 bit color created some pretty fantastic usability.

I've wanted a modern consistent, monochrome interface for a while as a general computing interface.

I've been looking at the e-ink devices for inspiration.

Forced contrast, forced visibility, it all has to be apparent. I've been hacking lua for this holy grail for about 6 years now, before that in perl, then in C since around 2001 or so.

I've got foot pedals, midi controllers I use for general computing, lots of little hacks. Multiple 4k monitors in portrait mode, lots of hacking with arduino sensor packs. Still not there yet.

Interfacing is the current limitation in computing. I've got 128 cores, hundreds of gb of ram, and no good way to use it other than the current paradigms. There's gotta be something better

These things have huge resolution now and the user can pick their language; would it really kill them to write words over the little icons? If in English, perhaps "ANSWER", "HANG UP", "MUTE" and so on, but the magic of words is that it doesn't have to be those exact words ("HANG UP" and "END CALL" are completely different sets of words yet in the context of a phone call, mean the same thing to almost everyone - magic).

Words. They carry so much information. So much. I know, people want to find some magic picture that carries full meaning to all cultures, but there simply ain't no such picture and there never will be; there's no shame in using words. Please. Use words. I'd even happily take them in a language I don't even speak, so long as it used an alphabet I could read (or even not - I can read some common software related words in Japanese simply through having sounded them out a few times). For me at least, words are easy; the ever-changing mist of icon-style-du-jour is not.

The solution is:

1) Publish Human Interface Guidelines that detail a rich set of standard gestures, how various tappable elements MUST be marked, and how they SHOULD be arranged.

2) Publish abridged HIG for end-users as a part of user manual for the device/platform. Aim for closed-world reasoning, i.e. the user must be able to build a mental model of, "if I can't see this functionality here, here or here, it does not exist", and not "it may be hidden somewhere else".

3) Tell app developers to stick to the HIG or GTFO.

I know, wishful thinking.

The decay started long, long ago. The other day, someone commented on HN with a link to a piece of old Microsoft WinAPI documentation, I think Windows 95 era or older, where there was a side note on window styling and "escape hatches" that unfortunately had to be built in, because marketers are marketers and desperately want to fuck up usability to put branding on things. Back then, platforms already gave away too much control over styling to software vendors (where originally this control resided with end-user).

> I will die on the hill that "confirm quit" is the correct behavior.

Google Chrome has a weird 'solution': on cmd-q press it popups a temporary overlay which reads "Hold cmd-q to quit"

Concurrency is excellent as an idea for systems design but horrible for user interfaces. Nothing seems to provide a stable interface and some concurrent process considers it it's privilege to suddenly modify a list of things I'm choosing from .. resulting in the items shifting just a few milliseconds before I click or tap my choice, which results in the wrong choice. This shift happens not only in vertical lists, but also tab-bar style buttons.

To be precise concurrency isn't to blame for it, but it's more like laziness. The interface elements should be locked in place if the system detects that I'm about to select something. Whatever else is waiting to show up can wait, because I obviously didn't need to know about them a few milliseconds earlier.

Yes, it's a bit inconsistent, but I can see why they make the buttons inconsistent within themselves rather than breaking user expectations.

This does not excuse the placement, though.