I wonder what’s the most polished or “sanded” UI out there?

You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ.

Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes.

Compare this to big box stores like “Home Depot”, “Lowe’s”. I can spend 10-15 minutes just trying to find the right size of screw, board, or whatever using their bloated sites. On mobile it’s even worse.

This is so lost in Agile.

Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed.

The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it.

[In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.]

As a fellow old, I'm inclined to say labels should just wrap the control unless there's a very good reason for it not to. Would have completely prevented the issue, wouldn't need a global ID nor the "for". Just generally more semantic and cleaner.

The goto tactic for this specific `<label>` problem is:

    <label>
        Foo
        <input>
    </label>

Is so important have people with that spark to see and fix those little UX issues, a good analogy used on UX design is papercuts for the user, not critical but it degrades user satisfaction.

To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.

I've been "sanding" my personal website (https://dustinbrett.com) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.

This is my strategy in bug bashes, and it generates way more tickets than anyone who has a multidimensional Cartesian matrix of test case combinations.

It’s good to know those tests cases to start, but random testing quickly outpaces planned testing when trying to find small issues. Also planned testing is often happy path or expected errors. Sanding like this finds edge bugs much faster.

This is totally what I’ve been doing all day. I call it “digital puttering”.

It’s where much of the beauty and craft of something is developed. It requires a craftsperson to not just “call it done and move on”, but instead to be intrinsically motivated to spend time with the creation intimately, rolling it around in your hands/brain. Guiding a vine here and there, plucking a leaf or two… until it ‘feels’ right.

It’s an important insight that the state space for UI is very large and that is why intuition is especially useful — it’s rarely feasible to account for all possibilities analytically. This is true to some extent in all areas of software development, but I think for UI dev moreso than most.

I generally wrap my radios inside of the label for this reason. Is there a reason not to do that?

This attention to detail is what separates the mediocre frontend devs from the rest. How the heck do I improve our hiring process so we get more of you!!!

If you’re not putting the input inside the label then you’re doing it wrong.

Bootstrap changing this in v4 is no excuse to not do it.

That's pretty much what I do.

TestFlight records how many sessions I run, on the release-ready app. I use TestFlight from very early on.

It always shows thousands of sessions for me. The next-highest tester is often only tens or hundreds.

But that number is dwarfed by how many sessions I run in the simulator.

It tends to result in apps that folks like using.

The biggest danger is that I get so familiar with the UI, that I don't understand its [lack of] discoverability for those unfamiliar with it. I can easily design inscrutable UI.

My beliefs in the same vein:

  - If you think you've found all the bugs, look again.
  - If you think you've just fixed a bug, test again.
  - If you think your program is done, you're wrong.

I think the article has good sentiments about it. Actually using your application a lot helps polish it down a ton.

However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.

Decent analogy. I wonder how many techies have ever used a belt sander. Or have one. I think very, very few.

Built an app when the iPhone first came out. Spent 2 months building the core app and another 3 months working to reduce the number of taps and remove road-bumps in the UI/UX flow.

Totally paid off.

Working on another app now. Sweating the details on the 'watercourse way.' That first experience is critical.

I miss this attention to detail in popular websites' UI. Often even clicking on the label won't update the form.

This applies to mobile apps a lot. If you're not careful (especially when using the iOS/Android simulators too much) you can create tiny awkward hit boxes for buttons that are difficult to tap with fingers

I like this idea of sanding your UI...

Just recently have done quite naturally the same thing... Expand the clickable surface area of a region

Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com makes the layout shift a bit in Safari on macOS. The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space.

I once spent hours debugging this before I realized what was happening, my confusion coming from the fact that with the inspector open that wasn't the case (As there the scrollbar was always visible...).

A broken pattern I see constantly related to author’s example is large buttons where only the button label - and not the rest of the button - is clickable.

Sounds like op is manually fuzz testing.

I prefer a well tuned smoothing plane or a card scraper, personally.

oof ouch I just got stabbed by a giant checkmarks-in-radio-buttons splinter

Is this Jim Neilsen related to Jakob Neilsen (famous UI guy)?

  It’s kind of a QA tactic in a sense

I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.

The algorithm of clicking around trying to break things heavily optimizes for workflows the designer finds natural. The more you do it, the more you reinforce your existing patterns because, you know, brains.

This tends to produce experiences that are very smooth for a large group of people but fail really badly for anyone who is slightly different. Most Apple stuff feels like this to me, for example. It's like carving a polished stone path where any direction you step off the path is raw and jagged.

Just put the input inside the label. Problem solved, no need for for=

On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed.

On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song.

When you consider the scale of these apps, there must be so much combined annoyance.

You can also do <label><input> label</input>

this is the way