Sanding UI

I think being a big user of whatever you're building is incredibly useful for finding these kinds of issues. If you're a big user as well as a dev then you will often stumble on these little things before a user does, and you are also perfectly placed to fix these issues before users can stumble on them.

I suspect this is why small teams with strong ownership can be so effective. If you feel ownership of a thing then you feel users' pain when they hit these little paper cuts, and it becomes a point of personal pride to fix these things and make the UX as smooth as possible.

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.

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

    <label>
        Foo
        <input>
    </label>

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.]

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.

This post demonstrates why I hate UI programming. The number of unpredictable, niggling little things that can go wrong exceeds my patience for dealing with them. I kind of enjoy thinking through the ways something might fail and writing tests to catch them, but aimlessly clicking around to see if anything breaks feels haphazard and annoying.

Is UI construction inherently that complex, or have we just not found the right programming model yet? Is it unreasonable to wish that sometimes things would just look and work the way I intended on the first try?

Meanwhile, some other UI uses square boxes for radio buttons.

Or have a highlighted button but the enter key doesn't activate it.

Or there are three different menus all behind a different symbol (ellipsis, hamburger, kebab).

There is a lot of variance in quality. Those of you who polish your UI: you are appreciated. Truly.

I don't understand why putting the <input> inside the <label> is so unpopular. It completely avoids these problems and you don't need to come up with a unique id to use with 'for'.

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.

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.

  It’s kind of a QA tactic in a sense

It's not kind of a QA tactic, this is literally the definition of QA. Specifically, this post is about ad-hoc functional testing. Kinda funny how this kind of testing used to dominate, but in the era of CI/CD, dedicated QA departments, and fancy webdriver suites, we've flipped too far the other way, and developers need to be reminded to QA their own stuff!

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.

This is (potential) an advantage of small teams and individual developers. In more formal teams developers are often handed a UI and that's what they have to build, no variation permitted.

However, not every developer will craft a great UI just given time, I've seen some truly inspired monstrosities.

Before I started in infosec I was a software tester for a year in the mid-90s. We called this kind of testing “monkey testing” and usually spent some time on it because it turned up lots of bugs, both code bugs and design/usability bugs. One time I delayed our product’s launch by a day because I found a crashing bug in the “about” dialog (missing handler for keyboard shortcut).

I also usually spent a few minutes in each UI page doing a test I called “spaz clicking” which, just like it sounds, consisted of just randomly clicking as fast as I could and moving the mouse around. Surprising how many bugs you’d find that way.

I'm always torn whether this is a good use of time or not. If you're an early stage startup, it feels like shipping features (that work) quickly is your biggest differentiator, not how nice your UI is.

I guess this is true if you're doing something in a not so saturated field, but understand that if you're in a saturated space, you probably do need the design to be natural os as to set yourself apart.

Put the input >into< the label. Then gap doesn’t matter, it’ll work. Of course, don’t allow such mistakes. It’s quality work when such small details are noticed and cared about.

This is a great example of where unit testing does not apply.

I see many developers get caught up in rituals, and polishing (and monkey testing for that matter) seem to go against a reproducible approach, and are therefore frowned upon and even ignored. Still, it is a much more powerful technique to get something both working and user friendly.

Investing in developers to spot that something is 3 pixels off, or the basic idea that different users have different tastes, can be very productive.

Alan Kay was right classifying most software engineering as pop culture. It's 2024 and we are still fiddling with spaces around radio buttons, a problem that should have been solved decades ago.

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.

Someone should do a YouTube channel where they "sand" popular software products and point out these kinds of subtle UI bugs.

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.

Shouldn’t these all be smoothed out by UI frameworks, design guidelines and best practices? It doesn’t look like the industry should spend so much productivity on these sanding works?

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

I think more projects need some form of the One Hundred Papercuts project in Ubuntu, where the goal was to fix little bugs that were annoyances but not critical.

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.

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.

On the inputs.. for radio/checkbox, I prefer to wrap inside the label element.

    <label>
      <input ... />
      <span>Some text...</span>
    </label>

When you do it this way, the label doesn't need to be mapped to the id for the input, it's implicit. Also, it allows easier adjustments to the characteristics of the checkbox/radio input via CSS.

You do want an inner <span> if you want to stylize the input control as an inline-block depending on your needs. For general use, with the native controls, the inner span isn't necessary, I still prefer it by convention.

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!!!

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

The lesson here is don’t split a control into two parts because developers will screw it up. Who prevented control designers from doing

  <radio>foobar</radio>
  <radio mark=end>foobar</radio>

and allowing a mark pseudoelement to participate in alignment? Or at least forcing everyone to use the input-in-label variant? Nobody.

But they split it, and now people without clear understanding how ui should work do it wrong by design and invent Monte Carlo methods to check if it works.

And it seems some crappy screenreaders don’t even recognize the proper form of it, adding salt to the cut.

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.

You know what.... this was an amazing post. There was a lesson, analogy, and a very to-the-point example.

Bike shedding kind of: I think the real failure here is not using a “cursor: pointer” directive. Easy to tell what’s clickable when your cursor changes based on what’s clickable.

I was on a site the other day, a hotel or flight website. I think it was a review form. There were checkboxes, where the checkbox wasn't clickable, only the labels. I was sure the whole thing was frozen, but happened to find some other UI controls were responding. So I tried the labels.

I've come across the reverse scenario quite a few times, where the label isn't clickable, but this variant was new to me.

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.

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

Anecdata, but I found the very same issue (the bermuda triangle gap between radioboxes, but also checkboxes, and their labels) in a project a few months ago.

It seemed a pretty big deal to me, specially because I always clicked on the gap, and got frustrated and angry at this. So I reported it to the UX team managing the design system, and to the developers implementing the design system, and nobody really cared. Some people even tried to convince me this behaviour was OK (because other design systems worked that way too, or because they were planning to refactor this on the far future so they didn't want to spend time on this).

I think the industry is now filled with people that just don't care, specially on big companies where, if it's not in a ticket, and if the ticket is not prioritized as critical, nobody cares. All they care about are metrics (test coverage, line count of a function, whatever). Pretty sad actually.

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...).

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

It has also become quite easy when sanding a UI to provide code to an LLM and describe something like a click deadzone and it can usually fix it immediately without you needing to investigate it. The missing piece is really just the glue between the browser, coding environment and LLM. I know a bunch of YC startups are working on this but nothing has really worked well for me. Please recommend anything you are using that does in fact provide this type of glue...

> So I click around, using the UI over and over, until I finally cannot give myself any more splinters.

I’d take this with a grain of salt (pun intended). There’s a lot of bugs that you cannot reproduce without certain permissions or a particular environment. Let alone the race conditions or user setup. In my experience, most bugs would not have been uncovered using this brute force approach. A few tests using your understanding of the code and critical thinking goes a lot further in my opinion.

Not directly related to the article's message (though may count as collaborative "sanding"), but related to its UI: the page has texts centered (margin-left: auto, margin-right: auto, short lines), but paragraphs with embedded images lack that, and the images are aligned to the left. I thought it may be due to JS disabled (if it relies on JS for the layout somehow), but enabling it did not change that. Observed in Firefox 115; it is not the intended layout, is it?

i always wrap the labels around the radio buttons and checkboxes. the animation also shows nicely that the label should not be selectable text. if one wants to further polish it a hover highlight might look nice at times.

Drawing a box around the radio buttons is perhaps not modern but it may make the form more usable.

The title or description of the element should not be the same as the options.

The 4 times might belong in two or more groups. This is something to dwell on, make a few mockups then most likely it shouldn't be used. If it doesn't jump out as amazingly useful restore normality.

consider lining up the time so that the :'s sit in a line. Try put the PM in a collum too. Maybe there should be AM as well.

Keep doing useless experiments until you strike gold. It should be really hard to beat default form elements (unless it is iphone)

Your truly fantastic 1000 line text input should most likely be deleted.

the example animation probably has insufficient line height. The user shouldn't have to aim that much.

I have found the same to be true in game development once all the pieces start coming together. There is no substitute to just using the thing. Maybe you don't find bugs/splinters, maybe you realise that it just doesn't feel right once you've glued the components together.

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.

Sounds like op is manually fuzz testing.

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.

Anyone discussing theporndude.com? It's a simple porn directory site, but I think the interface design shows a very clear information !

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

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

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

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

Meanwhile in Apple Photos, if you meticulously select 17 images and then accidentally click between photos, your selection disappears…

I really like the sticky face menu on the bottom right. Never seen this before. Gave me some inspiration for one of my sites.

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

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.

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

The computer always exactly does what you told it to do. You almost never know what exactly you told it.

Hard to believe this hasn't been abstracted and solved at the browser level in 2024.

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 checked SkyMass's radio + labels and they are fine.

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.

op figured out iteration and incremental improvement

Sir, this is Ikea.

Seems like a multimodal LLM unit test could do the sanding.

this is the way

Might be a good idea to record clicks that have no associated action. If you could display all of such clicks visually, the problem might become obvious.

we need to stop pretending that CSS is awesome though, it's been in use for about twenty five years now, keeps reinventing itself and still fails at simple things (as exhibited in this example)