54 ms·

Sanding UI

1300 points by roosgit 2y ago

MBS680 2y ago
Anyone discussing theporndude.com? It's a simple porn directory site, but I think the interface design shows a very clear information !
jamamp 2y ago
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.
- lelandfe 2y ago
  label>input instead of label+input. This is called an implicit label - time was, there were concerns about screen readers that couldn't interpret them. I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit https://a11ysupport.io/tests/html_label_element_implicit ...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit https://a11ysupport.io/tests/html_label_element_explicit
  - swatche 2y ago
    The spec says either way (https://www.w3.org/TR/html401/interact/forms.html#h-17.9 https://www.w3.org/TR/html401/interact/forms.html#h-17.9), but I agree with putting the input inside the label for the acessibility and avoiding the blank space issue.
    - lelandfe 2y ago
      The HTML spec doesn't speak much on a11y guidelines. Here's what the W3's WAI says https://www.w3.org/WAI/tutorials/forms/labels/#associating-labels-implicitly https://www.w3.org/WAI/tutorials/forms/labels/#associating-l... > Whenever possible, use the label element to associate text with form elements explicitly > [..] > In some situations, form controls cannot be labeled explicitly... Generally, explicit labels are better supported by assistive technology ...but people have been saying that for like 15 years now, I don't know how big of a deal those failures are. That'd be a good blog post
      - dumbo-octopus 2y ago
        Parent link says NVDA, VoiceOver, and JAWS all support the implicit way. That’s the industry standard suite to support, they’re all free and available across all platforms. If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.
        extra88 2y ago
        Yes, all the screen readers handle implicit labels just fine. As the a11ysupport.io tests show, it's Voice Control software that fails, not just Dragon NaturallySpeaking but also the built-in Voice Control in macOS. I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.
        dumbo-octopus 2y ago
        Voice Control also works perfectly fine, I just tested it myself on their provided sample. Say "select your name" on this page: https://a11ysupport.io/tests/html/html_label_element_implicit.html https://a11ysupport.io/tests/html/html_label_element_implici...
        extra88 2y ago
        They must have fixed it in Safari 18. I'm running macOS 14.6.1 and at the beginning of the month it didn't work but I also just tried it and now it does.
        acka 2y ago
        JAWS isn't free[1]. Using the trial version for accessibility testing goes against its EULA[2]. [1] https://www.freedomscientific.com/products/software/jaws/ https://www.freedomscientific.com/products/software/jaws/ [2] https://webaim.org/blog/jaws-license-not-developer-friendly/ https://webaim.org/blog/jaws-license-not-developer-friendly/
  - chenmike 2y ago
    There’s no reason you can’t do both, and indeed some a11y linters recommend doing that
  - oxidant 2y ago
    Put the input inside the label and still use "for" on the label. No way to test right now but that's what I usually do.
- tshaddox 2y ago
  That’s what I generally do as well, but sometimes I don’t like how it leads to empty space that is part of the clickable area. This will happen if you have a label tag with the label text above the input (and the label text is much narrower than the input widget). This isn’t a huge problem, but it always bugs me.
- philo23 2y ago
  > However, wouldn't putting the input inside of the label (before the label text) be a better solution The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue. This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
  - bastawhiz 2y ago
    That's only true if you let your labels be as wide as the parent container. > on mobile it might lead to miss-clicks while trying to scroll past the <label>s You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
    - philo23 2y ago
      Well with the CSS in the post they would end up as wide as their parent. If you made it an inline flex box then yes, that wouldn’t be an issue. > You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern. Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.
dexwiz 2y ago
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.
- gwervc 2y ago
  From time to time, especially when too tired to work on a full feature, I do some random click here and there, and try stuff I usually don't in my game. I always discover some issues or little improvements than can be made. A lot would indeed not come up using planned testing.
fitsumbelay 2y ago
this is the way
- jv22222 2y ago
  Came here to say this, thank you.
dewey 2y ago
Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com 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...).
- promiseofbeans 2y ago
  There's a newish CSS feature to fix just this: scrollbar-gutter (https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...). Unfortunately, Safari doesn't support it. Can also lead to an ugly gap in your navbar depending on which container you're making scroll.
  - dewey 2y ago
    That sounds promising, for some reason the webkit issue says “resolved / fixed” but I don’t see any updates in the issue itself: https://bugs.webkit.org/show_bug.cgi?id=167335 https://bugs.webkit.org/show_bug.cgi?id=167335
    - extra88 2y ago
      Not everything committed to WebKit ships in Safari. But the status changed to resolved/fixed only a month ago and it's in the latest Safari Technology Preview so maybe scrollbar-gutter will ship this year. https://www.webkit.org/blog/15860/release-notes-for-safari-technology-preview-203/ https://www.webkit.org/blog/15860/release-notes-for-safari-t...
- madeofpalk 2y ago
  > The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space. Every browser with non-floating scrollbars will do this, right? Safari, in its default configuration on a touch-ish device (macbook without a scrollwheel mouse, iOS) don't show explicit scroll bar gutters IIRC, and so won't have this problem.
quirino 2y ago
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.
- dustingetz 2y ago
  org chart has been shipped (excel labor cost model actually)
- andrepd 2y ago
  UI/UX standards in general are dogshit in most modern software. It's actually baffling how nobody bothers to do even the most basic polishing of their application as the OP. Like they note, clicking around for 10 or 20 minutes would reveal many imperfections, not to mention actually having testers and experiments and any semblance of a scientific design methodology.
  - ibash 2y ago
    I believe it boils down to what we teach as “finished”. Is a feature finished when the code works? When the pull request is merged? Or when a feature works well? I also believe there’s a lack of care. The difference between a craftsman and anyone else is care.
    - voidfunc 2y ago
      The lack of care from the product managers filters down through engineering. Product managers only care if a feature is shipped, not it it is polished. More shit shipping means more personal gain.
      - chii 2y ago
        but then why not keep going down the line, and say that the customers also doesnt care?
ivanjermakov 2y ago
I miss this attention to detail in popular websites' UI. Often even clicking on the label won't update the form.
tikkun 2y ago
Is this Jim Neilsen related to Jakob Neilsen (famous UI guy)?
kmoser 2y ago
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.
- arendtio 2y ago
  While I agree with the first two, the third is a problem. Yes, you can always extend your program, but should you? The more code and functionality you include, the harder it becomes to maintain. Finding the point where your software is so round or complete that you can call it done is somewhat of an art. You can undoubtedly add stuff beyond that point, but I won't improve the software in the long term.
  - robinsonb5 2y ago
    Quite the opposite - a design (in general, not just software) isn't done until you can't take anything else away from it. I've coined the term Bonsai Software here before, but I do like the sanding analogy. In the last week I've spent way more leisure time than could be considered sensible writing some user-interface code for the Amiga, in order to make defining the UI in future projects as simple and elegant as possible!
    - arendtio 2y ago
      While I agree with you on the design term, there is this fundamental conflict: unlike other design forms, software is an additive process. With wood or stone, you can work subtractively until there is nothing left to take away, but with software, you typically start with nothing and add stuff until you have enough. There is a high chance of overshooting the optimal design, and then you have to reverse direction.
  - kmoser 2y ago
    The third one isn't meant to imply that you should keep adding needlessly, or that you should necessarily add more functionality (yes, this is how feature creep starts). It's meant to indicate that software is never truly finished: there is always something to fix or improve upon (e.g. refactor). It's perfectly fine if you make the conscious choice to not make those fixes or improvements, usually for time/budget reasons, but the point is that you should be aware of those possibilities, and that those are the points to revisit if and when you have the resources to do so.
bbor 2y ago
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.
Retr0id 2y ago
oof ouch I just got stabbed by a giant checkmarks-in-radio-buttons splinter
someoneontenet 2y ago
Sounds like op is manually fuzz testing.
- gwern 2y ago
  Yes, but the important thing is the evaluation function of what happens after random actions - his intuitive expectations and things ripping his skin. A web fuzzer can click around randomly like he does, but it can't know things like "clicking here ought to have set the button" or "this is twice as slow as it should be, why". It can detect things like crashes or segfaults or JS code throwing exceptions, but not those other things.
jbverschoor 2y ago
Just put the input inside the label. Problem solved, no need for for=
ddtaylor 2y ago
The goto tactic for this specific `<label>` problem is: <label> Foo <input> </label>
- brailsafe 2y ago
  Back in the day I used to think this was taboo for some reason, but maybe it was only for XHTML to enforce one-to-one label -> input association. Flexbox seemed a bit redundant, since even with the non-nested syntax I'd think it would lay out inline and you can just add some padding in the same way.
  - 8n4vidtmkvmk 2y ago
    The alignment is not exactly the same when you just put them side by side. Flex can center the radio with the text a bit nicer. Otherwise it sits above the text baseline I believe.
- notduncansmith 2y ago
  This was my first thought. The entire text label should toggle the radio or checkbox, not just the box and the padding.
- dmix 2y ago
  Bootstrap moved from <label><input></label> in 4.0 to <input> + <label> in 5.0 for radios/checkboxes [1]. I was curious about why but my guess is that it adds some simplicity for theming when repositioning/padding either the label or input. [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/ https://getbootstrap.com/docs/5.3/forms/checks-radios/
  - parasti 2y ago
    They more than likely made that decision to be able to style the label based on input state using the + sibling selector. I use that trick for literally every visible input now.
  - abdusco 2y ago
sdflhasjd 2y ago
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
AlienRobot 2y ago
You can also do <label><input> label</input>
pentagrama 2y ago
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.
- deleted 2y ago
  [deleted]
- ix101 2y ago
  One I've experienced on GitHub and Jira is dragging to select text on a dialog, if you release outside the dialog the mouse up event dismisses the pop up which is probably a side effect of being able to click outside the dialog to dismiss it.
  - kchr 2y ago
    This could probably be fixed by tracking whether the mousedown event was started inside or outside the dialog, and only close the dialog if the mousedown started outside it.
    - wruza 2y ago
      It’s called a cursor grab and in the web exists as el.setPointerCapture(). https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
  - wruza 2y ago
    That’s classic “web ui”, the consequence of lowering the absraction level without providing and forcing developers to use useful mechanisms. So everyone just goes mindlessly with events which are badly targeted by design. I’d say that desktop is an order of magnitude better, but a kde installation I have to work with also doesn’t register clicks on buttons sometimes. Because for the sake of ui-ness they used flat elements instead of buttons and forgot making them down-upable anywhere within to click. So when you move-quick-and-click it registers (I guess) drag instead due to the movement, and drag is a no-op. Allowing clueless developers to use lower level and normalizing lower level graphics is a huge mistake these platforms make. The web is basically built with this in mind, that’s why it sucks. 20 years ago you couldn’t even imagine clicking around in a desktop app to see if radio works. People would literally laugh at you.
dcre 2y ago
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.
thex10 2y ago
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!!!
- tkzed49 2y ago
  Do you already have candidates actually write frontend code? Either async or during an interview, or both? I'm a big fan of being on either end of an interview where I'm actually working on a functioning project.
DustinBrett 2y ago
I've been "sanding" my personal website (https://dustinbrett.com https://dustinbrett.com) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
- high_priest 2y ago
  Warning: Prepare for a jumpscare with authors face. Fun page
- idreyn 2y ago
  this is very smooth and scratches an itch I didn't know I had -- to use a windowed OS on my phone
- tkzed49 2y ago
  I really appreciate this. Most of the time when I see a "desktop OS on webpage" it feels half-assed and honestly overplayed. This on the other hand is super tight and polished!
- bschmidt1 2y ago
  Looks incredible. Snappier than real Windows tbh
- jay-barronville 2y ago
  This is so fun. I love it. Well done!
- steve_adams_86 2y ago
  This is so fun to explore. You've done some great work on this! It's inspiring. A lot of fun to think about how you've implemented everything.
- darepublic 2y ago
  very nice. though you cannot have > 1 nesting of dustinbrett.com afaict
  - ustad 2y ago
dmd 2y ago
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.
deleted 2y ago
[deleted]
wheresmycraisin 2y ago
I prefer a well tuned smoothing plane or a card scraper, personally.
socialentp 2y 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.
christophilus 2y ago
I generally wrap my radios inside of the label for this reason. Is there a reason not to do that?
- marcosdumay 2y ago
  AFAIK, the only reason to use the label's `for` is when you want to place it in a different place from the widget.
  - emsimot 2y ago
    It also helps with accessibility, screen readers etc
    - marcosdumay 2y ago
      Not compared to including the widget inside the label.
- jay-barronville 2y ago
  > I generally wrap my radios inside of the label for this reason. Is there a reason not to do that? Actually, I think this is the best way to deal with all inputs that have labels—a small number of issues and edge cases (such as the one described in the article) just disappear. It’s also valid hierarchy-wise.
- parasti 2y ago
  You can't style the label based on input state if you do that. If you instead order them like input + label, then you can style the label with selectors like input:checked + label.
  - agos 2y ago
    you can, with the power of :has! label:has(input:checked) { background-color: orange; }
ants_everywhere 2y ago
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.
raminf 2y ago
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.
ChrisMarshallNY 2y ago
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.
4b11b4 2y ago
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
- 4b11b4 2y ago
  That should be a metric... % clickable. Could look at app, page, component levels
xyst 2y ago
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.
- arendtio 2y ago
  15 years ago, one would have said google.com But I think asking for a UI toolkit/framework is more helpful. Otherwise, you optimize for straightforward use cases, like entering a search box.
- skykooler 2y ago
  My biggest issue with mcmaster's website is that it doesn't provide any sort of navigation hierarchy - if you go into, say, the "rounded head screws" subcategory, there's no option to get back to the general "screws" category besides the browser's navigation buttons.
  - etrautmann 2y ago
    Yep, this is indeed annoying but infrequently pointed out.
  - djhn 2y ago
    I don’t know - I could argue that the user’s browser should be the preferred way to navigate, duplicating it’s functionality is redundant and adds clutter to the interface. It’s at least a defensible position.
    - edflsafoiewq 2y ago
      "Back" is the not the same thing, since you didn't necessarily come from the "Screws" category page.
timzaman 2y ago
Decent analogy. I wonder how many techies have ever used a belt sander. Or have one. I think very, very few.
- hipadev23 2y ago
  Your assumption is quite wrong. https://www.zainrizvi.io/blog/why-software-engineers-like-woodworking/ https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
  - duckmysick 2y ago
    What does this suppose to prove? The OP said "very few" not none. Of course there will be a few anecdotes of overlap. A better way would be to compare the size of Stack Exchange boards at https://stackexchange.com/sites https://stackexchange.com/sites . It's not perfect but it's as good as it can get. Stack Overflow has 26 million users. Woodworking has 17 thousand. A fraction. Further still, not every woodworker will use a belt sander. It's used for a specific purpose (large flat surfaces) and it's not a beginner's tool. So the fraction gets smaller. I'd say the assumption stands.
    - hipadev23 2y ago
      You and him are incorrigible. Him for the naive assumption and stereotype that “techies” don’t do any manual trades or crafts, you for looking at the count of activity on stack fucking overflow for woodworking.
      - duckmysick 2y ago
        That's not the assumption I got from the OP's comment. What I got was - and I agree - that the intersection between the members of the technical field (specifically those responsible for apps UI) and the members of the woodworking field who also use an advanced, single-purpose tool is tiny. The assumption will be the same if you replace the belt sander with a guitar amplifier, a lawn aerator, or a pressure canner and woodworking with their respective hobbies. If you have better data that shows an overlap between those in the technical field and those that do woodworking with highly specialized tools, I'm all ears; I'm willing to be convinced otherwise. In the meantime, here's another anecdote for you - I do woodworking (and gardening and constructions) and I don't own a belt sander.
aetherspawn 2y ago
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.]
- crazygringo 2y ago
  What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.
  - exe34 2y ago
    I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
    - JimDabell 2y ago
      > I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. This is the exact opposite of agile. Direct from the Agile Manifesto: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. > The best architectures, requirements, and designs emerge from self-organizing teams.
wordofx 2y ago
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.
donatj 2y ago
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.
two_handfuls 2y ago
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.
- selimco 2y ago
  I think space is usually the key that performs a click on focused buttons, not enter.
  - two_handfuls 2y ago
    I was talking about the default button (typically blue, activated with enter), not the currently focused button (outlined, space).
  - meindnoch 2y ago
    It's up to the user agent. On one platform it's the spacebar, on another it's the return key. Of course, fake controls written in JS wouldn't be able to do this. Which is why it's the wrong thing to do.
- qingcharles 2y ago
  Square or squircle seems to moving towards the standard for radio buttons now. Even Apple plays this game :(
  - two_handfuls 2y ago
    File each as a bug, fight the good fight.
throwaway14356 2y ago
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.
invaliduser 2y ago
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.
- bsoles 2y ago
  Most software engineering has become the modern equivalent of assembly line workers, which brings about the concept of alienation from our work products, per Marx. It is all about productivity metrics and nobody actually cares about non-measured forms of quality and artisanship.
bhy 2y ago
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?
- Jaxan 2y ago
  I agree that these things should smooth it out. But so far the reality shows they do not.
- ryandrake 2y ago
  Yea, I'm not a web developer, but coming from the desktop world, I am shocked by how little web UI frameworks do for you and how buggy their implementation is. Adding padding here and margin there and flex boxes and all that shit just to get a radio button or a drop-down that we do in one line of code on the desktop side? It's like the software development equivalent of using stone tools and chisels to build a car.
defanor 2y ago
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?
ehnto 2y ago
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.
smokel 2y ago
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.
- dataviz1000 2y ago
  It is also very easy to develop systematic automated ways to do this with tools like Playwright and Nut.js.
  - handsclean 2y ago
    Ok, how would you use Playwright and Nut.js to discover the OP’s “splinter”? Note I’m specifically asking about discovery, not testing for it once you already know what to look for.
    - thom 2y ago
      I've actually been thinking lately about property based testing for UIs. In this particularly case, there should be an invariant for each entry in a radio button list that the selectable area covers the entire bounding box from button to the end of the label. There are many such invariants you could imagine - every paragraph of text should be selectable by a click and drag, menu drop downs shouldn't hide as long as the mouse is within its area etc. Build up a big enough suite of these tests and you could quite easily integrate them in Storybook or beyond. Probably not something you want to run on every save, but an asynchronous process running somewhere recreating this "sanding" activity would be a worth way of saving time and improving quality.
      - thom 2y ago
        Obviously this won't catch everything human QA can, but where an invariant can be expressed (navigating then going back should result in being in the right place, as mentioned in the article) it seems good to try and capture it.
jeffreygoesto 2y ago
The computer always exactly does what you told it to do. You almost never know what exactly you told it.
webprofusion 2y ago
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.
paxcoder 2y ago
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.
- gwern 2y ago
  The problem with that is that users (1) often click at random or for stupid reasons (I was shocked when one user contacted me to complain about my site acting poorly when they clicked on random empty whitespace - they said they just did that compulsively as a habit, like fidgeting), and (2) users learn to not click on these sorts of papercuts via operant conditioning. Like the OP's example is something that his users would learn not to do, and so it would disappear from the statistics. It's not obvious to me that it would emerge out of the sea of misclicks and bots and random fidgeting clicks. Are you going to review a vast list of logged null clicks (and of course, lots of these papercuts will be for clicks that do have actions - the wrong action) regularly? Realistically, no. You probably aren't even reviewing your site's 404s or making sure all links work.
ImHereToVote 2y ago
Seems like a multimodal LLM unit test could do the sanding.
mdavid626 2y ago
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.
remus 2y ago
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.
- kizer 2y ago
  Also why companies dogfood and have internal betas for products (when this is possible; i.e., you’re not making something for enterprises or other kinds of customers). The sense of ownership you’re talking about may not be as direct but stake in success of the product is there.
  - Aeolun 2y ago
    We’re and enterprise making things for enterprises. You better believe the SSO part is well tested xD
gaborme 2y ago
I really like the sticky face menu on the bottom right. Never seen this before. Gave me some inspiration for one of my sites.
youssefarizk 2y ago
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.
- lofaszvanitt 2y ago
  Of course it is good time. UI designers are paid the lowest wages... that's why most of the sites have terrible or just plain braindead interfaces. That's why the browsers of today are soulless, non intuitive, hence not productive at all. All this dancing around money made the whole web a shallow info gathering place. Oh my god, just look at Facebook's comment system. It's a fucking mess and it's based on their fancy React steposhi soft. Mind boggling that even their own engineers can't create a usable UI. Well, they are too big to care.
- hombre_fatal 2y ago
  The good use of time is that OP learned that labels should wrap their inputs, so the next 10,000 times they write a control on a form, they'll just do it off the bat. That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has, especially when you see them disparage UI development as something unworthy of their time / expertise.
  - ludwigvan 2y ago
    Did they? My understanding is they replaced gap with padding, didn’t necessarily wrap the input with the label (which they should as you suggest)
    - wruza 2y ago
      Yep, they used flexbox to nicely do… absolutely nothing useful beyond blogspam. Next up “how I made my ui responsive but then heroically stopped labels wrapping away from radio marks”. There’s a reason, even if accidental, why writing custom controls was sort of a black magic in traditional ui. And that reason is, most people are clueless about how fragile ui actually will be in their hands.
pennomi 2y ago
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.
razodactyl 2y ago
You know what.... this was an amazing post. There was a lesson, analogy, and a very to-the-point example.
d_burfoot 2y ago
Someone should do a YouTube channel where they "sand" popular software products and point out these kinds of subtle UI bugs.
- gnomespaceship 2y ago
  One person I saw do this is Mia: https://www.tiktok.com/@heymiadotco https://www.tiktok.com/@heymiadotco If you sort videos by popularity there's a lot I enjoyed where she does a "UX roast" of SaaS or streaming websites
- masklinn 2y ago
  You could probably do an entire channel out of just YouTube.
wruza 2y ago
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.
perfunctory 2y ago
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.
- lofaszvanitt 2y ago
  Well, Pagani Utopia vs a Corvette ZR1. Spaces, yes.
- dclowd9901 2y ago
  I don’t get this take. “Still fiddling with spaces around radio buttons.” It’s design. Design is unique to the creation. We still fiddle around with spacing around radio buttons because one spacing doesn’t work for every design. Unless you’re talking about the clicking dead zone, which I would argue is more a problem with not using the right cursor than the dead zone the gap introduces.
Sardtok 2y ago
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.
- jbeninger 2y ago
  I suspect those were custom UI elements and not native. They remembered to onclick the label (or it's a native <label> element) but forgot to onclick the checkbox itself
djsamseng 2y ago
> 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.
- linux2647 2y ago
  “Sanding” shouldn’t be the only approach to testing an app. Developers should test using a variety of techniques. Some bugs are discovered through unit or integration tests, others by brute force, others still from end users
dclowd9901 2y ago
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.
- deleted 2y ago
  [deleted]
snegrus 2y ago
Sir, this is Ikea.
VeejayRampay 2y ago
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)
anybodyhome 2y ago
Hard to believe this hasn't been abstracted and solved at the browser level in 2024.
- Muromec 2y ago
  It's hard to believe because it's not true. You wrap the input with a label and it works.
deleted 2y ago
[deleted]
jwr 2y ago
Meanwhile in Apple Photos, if you meticulously select 17 images and then accidentally click between photos, your selection disappears…
efitz 2y ago
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.
babyshake 2y ago
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...
- martin_corredor 2y ago
  I love using https://aider.chat/ https://aider.chat/ When you say glue between the browser though not sure if you're looking for something to automatically watch your browser's behavior. For now you can just pass screenshots to aider through the clipboard
wmil 2y ago
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'.
- myfonj 2y ago
  I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]: > Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work. Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company. [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separate/#:~:text=Both%20Dragon%20Naturally%20Speaking%20for%20Windows%2C%20and%20Voice%20Control%20for%20macOS%20and%20iOS%2C%20don%E2%80%99t%20recognize%20implicit%20association,work%2e https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
  - jermaustin1 2y ago
    Is that not what the ARIA standards are for?
    - phatskat 2y ago
      I don’t think so, correct me if I’m wrong: an ARIA attribute that might fit here would be aria-labelledby (sic), but per MDN > Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript. The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute. Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.
psadri 2y ago
Just checked SkyMass's radio + labels and they are fine.
whalesalad 2y ago
op figured out iteration and incremental improvement
tracker1 2y ago
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.
aaronkaplan 2y ago
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?
- hcarvalhoalves 2y ago
  Is not UI programming, it’s designing UIs on top of HTML and CSS. There’s way too many degrees of freedom, while basic things like forms should work well by default.
- ivan_gammel 2y ago
  It is not that complex. The nice ways to describe UI in code do exist. It is a business problem of a zero-sum game, where cross-platform UI is prohibitively expensive when it’s not done on the ugliest UI stack (HTML/CSS/JS).
- wruza 2y ago
  In this case (web) it’s a result of too low granularity without anything that could help a developer interested in proper ui. Simply too much work to just catch up. You can see the same in other areas. E.g. if there’s no easy way to send a request or parametrize to a query, people will invent all sorts of half assed ways to do that, even if mindful about it, due to natural pressures. Web platform is absolutely bleeding edge graphics, but actually dogshit ui. And no one has nerve to admit it and make a change because people believe in the first part and then legacy and complexity of browsers prohibit it. And when you do it as a lib, it’s not “standard”, so nobody cares.
- dmalik 2y ago
  This is what design systems are for. You only sand UI when you're initially creating the component. Sometimes you combine components in different ways or need to make a one off. It honestly doesn't take all that long if you know what you're doing. A good design engineer is a specialist for this type of role.

1300 points by roosgit 2y ago

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

jamamp 2y ago

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.

lelandfe 2y ago
label>input instead of label+input. This is called an implicit label - time was, there were concerns about screen readers that couldn't interpret them. I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit https://a11ysupport.io/tests/html_label_element_implicit ...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit https://a11ysupport.io/tests/html_label_element_explicit
- swatche 2y ago
  The spec says either way (https://www.w3.org/TR/html401/interact/forms.html#h-17.9 https://www.w3.org/TR/html401/interact/forms.html#h-17.9), but I agree with putting the input inside the label for the acessibility and avoiding the blank space issue.
  - lelandfe 2y ago
    The HTML spec doesn't speak much on a11y guidelines. Here's what the W3's WAI says https://www.w3.org/WAI/tutorials/forms/labels/#associating-labels-implicitly https://www.w3.org/WAI/tutorials/forms/labels/#associating-l... > Whenever possible, use the label element to associate text with form elements explicitly > [..] > In some situations, form controls cannot be labeled explicitly... Generally, explicit labels are better supported by assistive technology ...but people have been saying that for like 15 years now, I don't know how big of a deal those failures are. That'd be a good blog post
    - dumbo-octopus 2y ago
      Parent link says NVDA, VoiceOver, and JAWS all support the implicit way. That’s the industry standard suite to support, they’re all free and available across all platforms. If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.
      - extra88 2y ago
        Yes, all the screen readers handle implicit labels just fine. As the a11ysupport.io tests show, it's Voice Control software that fails, not just Dragon NaturallySpeaking but also the built-in Voice Control in macOS. I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.
        dumbo-octopus 2y ago
        Voice Control also works perfectly fine, I just tested it myself on their provided sample. Say "select your name" on this page: https://a11ysupport.io/tests/html/html_label_element_implicit.html https://a11ysupport.io/tests/html/html_label_element_implici...
        extra88 2y ago
        They must have fixed it in Safari 18. I'm running macOS 14.6.1 and at the beginning of the month it didn't work but I also just tried it and now it does.
      - acka 2y ago
        JAWS isn't free[1]. Using the trial version for accessibility testing goes against its EULA[2]. [1] https://www.freedomscientific.com/products/software/jaws/ https://www.freedomscientific.com/products/software/jaws/ [2] https://webaim.org/blog/jaws-license-not-developer-friendly/ https://webaim.org/blog/jaws-license-not-developer-friendly/
- chenmike 2y ago
  There’s no reason you can’t do both, and indeed some a11y linters recommend doing that
- oxidant 2y ago
  Put the input inside the label and still use "for" on the label. No way to test right now but that's what I usually do.
tshaddox 2y ago
That’s what I generally do as well, but sometimes I don’t like how it leads to empty space that is part of the clickable area. This will happen if you have a label tag with the label text above the input (and the label text is much narrower than the input widget). This isn’t a huge problem, but it always bugs me.
philo23 2y ago
> However, wouldn't putting the input inside of the label (before the label text) be a better solution The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue. This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
- bastawhiz 2y ago
  That's only true if you let your labels be as wide as the parent container. > on mobile it might lead to miss-clicks while trying to scroll past the <label>s You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
  - philo23 2y ago
    Well with the CSS in the post they would end up as wide as their parent. If you made it an inline flex box then yes, that wouldn’t be an issue. > You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern. Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.

dexwiz 2y ago

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.

gwervc 2y ago
From time to time, especially when too tired to work on a full feature, I do some random click here and there, and try stuff I usually don't in my game. I always discover some issues or little improvements than can be made. A lot would indeed not come up using planned testing.

fitsumbelay 2y ago

this is the way

jv22222 2y ago
Came here to say this, thank you.

dewey 2y ago

Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com 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...).

promiseofbeans 2y ago
There's a newish CSS feature to fix just this: scrollbar-gutter (https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...). Unfortunately, Safari doesn't support it. Can also lead to an ugly gap in your navbar depending on which container you're making scroll.
- dewey 2y ago
  That sounds promising, for some reason the webkit issue says “resolved / fixed” but I don’t see any updates in the issue itself: https://bugs.webkit.org/show_bug.cgi?id=167335 https://bugs.webkit.org/show_bug.cgi?id=167335
  - extra88 2y ago
    Not everything committed to WebKit ships in Safari. But the status changed to resolved/fixed only a month ago and it's in the latest Safari Technology Preview so maybe scrollbar-gutter will ship this year. https://www.webkit.org/blog/15860/release-notes-for-safari-technology-preview-203/ https://www.webkit.org/blog/15860/release-notes-for-safari-t...
madeofpalk 2y ago
> The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space. Every browser with non-floating scrollbars will do this, right? Safari, in its default configuration on a touch-ish device (macbook without a scrollwheel mouse, iOS) don't show explicit scroll bar gutters IIRC, and so won't have this problem.

quirino 2y ago

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.

dustingetz 2y ago
org chart has been shipped (excel labor cost model actually)
andrepd 2y ago
UI/UX standards in general are dogshit in most modern software. It's actually baffling how nobody bothers to do even the most basic polishing of their application as the OP. Like they note, clicking around for 10 or 20 minutes would reveal many imperfections, not to mention actually having testers and experiments and any semblance of a scientific design methodology.
- ibash 2y ago
  I believe it boils down to what we teach as “finished”. Is a feature finished when the code works? When the pull request is merged? Or when a feature works well? I also believe there’s a lack of care. The difference between a craftsman and anyone else is care.
  - voidfunc 2y ago
    The lack of care from the product managers filters down through engineering. Product managers only care if a feature is shipped, not it it is polished. More shit shipping means more personal gain.
    - chii 2y ago
      but then why not keep going down the line, and say that the customers also doesnt care?

ivanjermakov 2y ago

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

tikkun 2y ago

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

kmoser 2y ago

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.

arendtio 2y ago
While I agree with the first two, the third is a problem. Yes, you can always extend your program, but should you? The more code and functionality you include, the harder it becomes to maintain. Finding the point where your software is so round or complete that you can call it done is somewhat of an art. You can undoubtedly add stuff beyond that point, but I won't improve the software in the long term.
- robinsonb5 2y ago
  Quite the opposite - a design (in general, not just software) isn't done until you can't take anything else away from it. I've coined the term Bonsai Software here before, but I do like the sanding analogy. In the last week I've spent way more leisure time than could be considered sensible writing some user-interface code for the Amiga, in order to make defining the UI in future projects as simple and elegant as possible!
  - arendtio 2y ago
    While I agree with you on the design term, there is this fundamental conflict: unlike other design forms, software is an additive process. With wood or stone, you can work subtractively until there is nothing left to take away, but with software, you typically start with nothing and add stuff until you have enough. There is a high chance of overshooting the optimal design, and then you have to reverse direction.
- kmoser 2y ago
  The third one isn't meant to imply that you should keep adding needlessly, or that you should necessarily add more functionality (yes, this is how feature creep starts). It's meant to indicate that software is never truly finished: there is always something to fix or improve upon (e.g. refactor). It's perfectly fine if you make the conscious choice to not make those fixes or improvements, usually for time/budget reasons, but the point is that you should be aware of those possibilities, and that those are the points to revisit if and when you have the resources to do so.

bbor 2y ago

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.

Retr0id 2y ago

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

someoneontenet 2y ago

Sounds like op is manually fuzz testing.

gwern 2y ago
Yes, but the important thing is the evaluation function of what happens after random actions - his intuitive expectations and things ripping his skin. A web fuzzer can click around randomly like he does, but it can't know things like "clicking here ought to have set the button" or "this is twice as slow as it should be, why". It can detect things like crashes or segfaults or JS code throwing exceptions, but not those other things.

jbverschoor 2y ago

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

ddtaylor 2y ago

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

brailsafe 2y ago
Back in the day I used to think this was taboo for some reason, but maybe it was only for XHTML to enforce one-to-one label -> input association. Flexbox seemed a bit redundant, since even with the non-nested syntax I'd think it would lay out inline and you can just add some padding in the same way.
- 8n4vidtmkvmk 2y ago
  The alignment is not exactly the same when you just put them side by side. Flex can center the radio with the text a bit nicer. Otherwise it sits above the text baseline I believe.
notduncansmith 2y ago
This was my first thought. The entire text label should toggle the radio or checkbox, not just the box and the padding.
dmix 2y ago
Bootstrap moved from <label><input></label> in 4.0 to <input> + <label> in 5.0 for radios/checkboxes [1]. I was curious about why but my guess is that it adds some simplicity for theming when repositioning/padding either the label or input. [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/ https://getbootstrap.com/docs/5.3/forms/checks-radios/
- parasti 2y ago
  They more than likely made that decision to be able to style the label based on input state using the + sibling selector. I use that trick for literally every visible input now.
- abdusco 2y ago

sdflhasjd 2y ago

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

AlienRobot 2y ago

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

pentagrama 2y ago

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.

deleted 2y ago
[deleted]
ix101 2y ago
One I've experienced on GitHub and Jira is dragging to select text on a dialog, if you release outside the dialog the mouse up event dismisses the pop up which is probably a side effect of being able to click outside the dialog to dismiss it.
- kchr 2y ago
  This could probably be fixed by tracking whether the mousedown event was started inside or outside the dialog, and only close the dialog if the mousedown started outside it.
  - wruza 2y ago
    It’s called a cursor grab and in the web exists as el.setPointerCapture(). https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
- wruza 2y ago
  That’s classic “web ui”, the consequence of lowering the absraction level without providing and forcing developers to use useful mechanisms. So everyone just goes mindlessly with events which are badly targeted by design. I’d say that desktop is an order of magnitude better, but a kde installation I have to work with also doesn’t register clicks on buttons sometimes. Because for the sake of ui-ness they used flat elements instead of buttons and forgot making them down-upable anywhere within to click. So when you move-quick-and-click it registers (I guess) drag instead due to the movement, and drag is a no-op. Allowing clueless developers to use lower level and normalizing lower level graphics is a huge mistake these platforms make. The web is basically built with this in mind, that’s why it sucks. 20 years ago you couldn’t even imagine clicking around in a desktop app to see if radio works. People would literally laugh at you.

dcre 2y ago

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.

thex10 2y ago

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

tkzed49 2y ago
Do you already have candidates actually write frontend code? Either async or during an interview, or both? I'm a big fan of being on either end of an interview where I'm actually working on a functioning project.

DustinBrett 2y ago

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

high_priest 2y ago
Warning: Prepare for a jumpscare with authors face. Fun page
idreyn 2y ago
this is very smooth and scratches an itch I didn't know I had -- to use a windowed OS on my phone
tkzed49 2y ago
I really appreciate this. Most of the time when I see a "desktop OS on webpage" it feels half-assed and honestly overplayed. This on the other hand is super tight and polished!
bschmidt1 2y ago
Looks incredible. Snappier than real Windows tbh
jay-barronville 2y ago
This is so fun. I love it. Well done!
steve_adams_86 2y ago
This is so fun to explore. You've done some great work on this! It's inspiring. A lot of fun to think about how you've implemented everything.
darepublic 2y ago
very nice. though you cannot have > 1 nesting of dustinbrett.com afaict
- ustad 2y ago

dmd 2y ago

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.

deleted 2y ago

[deleted]

wheresmycraisin 2y ago

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

socialentp 2y 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.

christophilus 2y ago

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

marcosdumay 2y ago
AFAIK, the only reason to use the label's `for` is when you want to place it in a different place from the widget.
- emsimot 2y ago
  It also helps with accessibility, screen readers etc
  - marcosdumay 2y ago
    Not compared to including the widget inside the label.
jay-barronville 2y ago
> I generally wrap my radios inside of the label for this reason. Is there a reason not to do that? Actually, I think this is the best way to deal with all inputs that have labels—a small number of issues and edge cases (such as the one described in the article) just disappear. It’s also valid hierarchy-wise.
parasti 2y ago
You can't style the label based on input state if you do that. If you instead order them like input + label, then you can style the label with selectors like input:checked + label.
- agos 2y ago
  you can, with the power of :has! label:has(input:checked) { background-color: orange; }

ants_everywhere 2y ago

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.

raminf 2y ago

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.

ChrisMarshallNY 2y ago

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.

4b11b4 2y ago

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

4b11b4 2y ago
That should be a metric... % clickable. Could look at app, page, component levels

xyst 2y ago

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.

arendtio 2y ago
15 years ago, one would have said google.com But I think asking for a UI toolkit/framework is more helpful. Otherwise, you optimize for straightforward use cases, like entering a search box.
skykooler 2y ago
My biggest issue with mcmaster's website is that it doesn't provide any sort of navigation hierarchy - if you go into, say, the "rounded head screws" subcategory, there's no option to get back to the general "screws" category besides the browser's navigation buttons.
- etrautmann 2y ago
  Yep, this is indeed annoying but infrequently pointed out.
- djhn 2y ago
  I don’t know - I could argue that the user’s browser should be the preferred way to navigate, duplicating it’s functionality is redundant and adds clutter to the interface. It’s at least a defensible position.
  - edflsafoiewq 2y ago
    "Back" is the not the same thing, since you didn't necessarily come from the "Screws" category page.

timzaman 2y ago

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

hipadev23 2y ago
Your assumption is quite wrong. https://www.zainrizvi.io/blog/why-software-engineers-like-woodworking/ https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
- duckmysick 2y ago
  What does this suppose to prove? The OP said "very few" not none. Of course there will be a few anecdotes of overlap. A better way would be to compare the size of Stack Exchange boards at https://stackexchange.com/sites https://stackexchange.com/sites . It's not perfect but it's as good as it can get. Stack Overflow has 26 million users. Woodworking has 17 thousand. A fraction. Further still, not every woodworker will use a belt sander. It's used for a specific purpose (large flat surfaces) and it's not a beginner's tool. So the fraction gets smaller. I'd say the assumption stands.
  - hipadev23 2y ago
    You and him are incorrigible. Him for the naive assumption and stereotype that “techies” don’t do any manual trades or crafts, you for looking at the count of activity on stack fucking overflow for woodworking.
    - duckmysick 2y ago
      That's not the assumption I got from the OP's comment. What I got was - and I agree - that the intersection between the members of the technical field (specifically those responsible for apps UI) and the members of the woodworking field who also use an advanced, single-purpose tool is tiny. The assumption will be the same if you replace the belt sander with a guitar amplifier, a lawn aerator, or a pressure canner and woodworking with their respective hobbies. If you have better data that shows an overlap between those in the technical field and those that do woodworking with highly specialized tools, I'm all ears; I'm willing to be convinced otherwise. In the meantime, here's another anecdote for you - I do woodworking (and gardening and constructions) and I don't own a belt sander.

aetherspawn 2y ago

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

crazygringo 2y ago
What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.
- exe34 2y ago
  I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
  - JimDabell 2y ago
    > I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. This is the exact opposite of agile. Direct from the Agile Manifesto: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. > The best architectures, requirements, and designs emerge from self-organizing teams.

wordofx 2y ago

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.

donatj 2y ago

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.

two_handfuls 2y ago

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.

selimco 2y ago
I think space is usually the key that performs a click on focused buttons, not enter.
- two_handfuls 2y ago
  I was talking about the default button (typically blue, activated with enter), not the currently focused button (outlined, space).
- meindnoch 2y ago
  It's up to the user agent. On one platform it's the spacebar, on another it's the return key. Of course, fake controls written in JS wouldn't be able to do this. Which is why it's the wrong thing to do.
qingcharles 2y ago
Square or squircle seems to moving towards the standard for radio buttons now. Even Apple plays this game :(
- two_handfuls 2y ago
  File each as a bug, fight the good fight.

throwaway14356 2y ago

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.

invaliduser 2y ago

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.

bsoles 2y ago
Most software engineering has become the modern equivalent of assembly line workers, which brings about the concept of alienation from our work products, per Marx. It is all about productivity metrics and nobody actually cares about non-measured forms of quality and artisanship.

bhy 2y ago

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?

Jaxan 2y ago
I agree that these things should smooth it out. But so far the reality shows they do not.
ryandrake 2y ago
Yea, I'm not a web developer, but coming from the desktop world, I am shocked by how little web UI frameworks do for you and how buggy their implementation is. Adding padding here and margin there and flex boxes and all that shit just to get a radio button or a drop-down that we do in one line of code on the desktop side? It's like the software development equivalent of using stone tools and chisels to build a car.

defanor 2y ago

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?

ehnto 2y ago

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.

smokel 2y ago

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.

dataviz1000 2y ago
It is also very easy to develop systematic automated ways to do this with tools like Playwright and Nut.js.
- handsclean 2y ago
  Ok, how would you use Playwright and Nut.js to discover the OP’s “splinter”? Note I’m specifically asking about discovery, not testing for it once you already know what to look for.
  - thom 2y ago
    I've actually been thinking lately about property based testing for UIs. In this particularly case, there should be an invariant for each entry in a radio button list that the selectable area covers the entire bounding box from button to the end of the label. There are many such invariants you could imagine - every paragraph of text should be selectable by a click and drag, menu drop downs shouldn't hide as long as the mouse is within its area etc. Build up a big enough suite of these tests and you could quite easily integrate them in Storybook or beyond. Probably not something you want to run on every save, but an asynchronous process running somewhere recreating this "sanding" activity would be a worth way of saving time and improving quality.
    - thom 2y ago
      Obviously this won't catch everything human QA can, but where an invariant can be expressed (navigating then going back should result in being in the right place, as mentioned in the article) it seems good to try and capture it.

jeffreygoesto 2y ago

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

webprofusion 2y ago

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.

paxcoder 2y ago

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.

gwern 2y ago
The problem with that is that users (1) often click at random or for stupid reasons (I was shocked when one user contacted me to complain about my site acting poorly when they clicked on random empty whitespace - they said they just did that compulsively as a habit, like fidgeting), and (2) users learn to not click on these sorts of papercuts via operant conditioning. Like the OP's example is something that his users would learn not to do, and so it would disappear from the statistics. It's not obvious to me that it would emerge out of the sea of misclicks and bots and random fidgeting clicks. Are you going to review a vast list of logged null clicks (and of course, lots of these papercuts will be for clicks that do have actions - the wrong action) regularly? Realistically, no. You probably aren't even reviewing your site's 404s or making sure all links work.

ImHereToVote 2y ago

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

mdavid626 2y ago

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.

remus 2y ago

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.

kizer 2y ago
Also why companies dogfood and have internal betas for products (when this is possible; i.e., you’re not making something for enterprises or other kinds of customers). The sense of ownership you’re talking about may not be as direct but stake in success of the product is there.
- Aeolun 2y ago
  We’re and enterprise making things for enterprises. You better believe the SSO part is well tested xD

gaborme 2y ago

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

youssefarizk 2y ago

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.

lofaszvanitt 2y ago
Of course it is good time. UI designers are paid the lowest wages... that's why most of the sites have terrible or just plain braindead interfaces. That's why the browsers of today are soulless, non intuitive, hence not productive at all. All this dancing around money made the whole web a shallow info gathering place. Oh my god, just look at Facebook's comment system. It's a fucking mess and it's based on their fancy React steposhi soft. Mind boggling that even their own engineers can't create a usable UI. Well, they are too big to care.
hombre_fatal 2y ago
The good use of time is that OP learned that labels should wrap their inputs, so the next 10,000 times they write a control on a form, they'll just do it off the bat. That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has, especially when you see them disparage UI development as something unworthy of their time / expertise.
- ludwigvan 2y ago
  Did they? My understanding is they replaced gap with padding, didn’t necessarily wrap the input with the label (which they should as you suggest)
  - wruza 2y ago
    Yep, they used flexbox to nicely do… absolutely nothing useful beyond blogspam. Next up “how I made my ui responsive but then heroically stopped labels wrapping away from radio marks”. There’s a reason, even if accidental, why writing custom controls was sort of a black magic in traditional ui. And that reason is, most people are clueless about how fragile ui actually will be in their hands.

pennomi 2y ago

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.

razodactyl 2y ago

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

d_burfoot 2y ago

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

gnomespaceship 2y ago
One person I saw do this is Mia: https://www.tiktok.com/@heymiadotco https://www.tiktok.com/@heymiadotco If you sort videos by popularity there's a lot I enjoyed where she does a "UX roast" of SaaS or streaming websites
masklinn 2y ago
You could probably do an entire channel out of just YouTube.

wruza 2y ago

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.

perfunctory 2y ago

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.

lofaszvanitt 2y ago
Well, Pagani Utopia vs a Corvette ZR1. Spaces, yes.
dclowd9901 2y ago
I don’t get this take. “Still fiddling with spaces around radio buttons.” It’s design. Design is unique to the creation. We still fiddle around with spacing around radio buttons because one spacing doesn’t work for every design. Unless you’re talking about the clicking dead zone, which I would argue is more a problem with not using the right cursor than the dead zone the gap introduces.

Sardtok 2y ago

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.

jbeninger 2y ago
I suspect those were custom UI elements and not native. They remembered to onclick the label (or it's a native <label> element) but forgot to onclick the checkbox itself

djsamseng 2y ago

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

linux2647 2y ago
“Sanding” shouldn’t be the only approach to testing an app. Developers should test using a variety of techniques. Some bugs are discovered through unit or integration tests, others by brute force, others still from end users

dclowd9901 2y ago

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.

deleted 2y ago
[deleted]

snegrus 2y ago

Sir, this is Ikea.

VeejayRampay 2y ago

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)

anybodyhome 2y ago

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

Muromec 2y ago
It's hard to believe because it's not true. You wrap the input with a label and it works.

deleted 2y ago

[deleted]

jwr 2y ago

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

efitz 2y ago

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.

babyshake 2y ago

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

martin_corredor 2y ago
I love using https://aider.chat/ https://aider.chat/ When you say glue between the browser though not sure if you're looking for something to automatically watch your browser's behavior. For now you can just pass screenshots to aider through the clipboard

wmil 2y ago

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

myfonj 2y ago
I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]: > Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work. Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company. [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separate/#:~:text=Both%20Dragon%20Naturally%20Speaking%20for%20Windows%2C%20and%20Voice%20Control%20for%20macOS%20and%20iOS%2C%20don%E2%80%99t%20recognize%20implicit%20association,work%2e https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
- jermaustin1 2y ago
  Is that not what the ARIA standards are for?
  - phatskat 2y ago
    I don’t think so, correct me if I’m wrong: an ARIA attribute that might fit here would be aria-labelledby (sic), but per MDN > Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript. The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute. Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.

psadri 2y ago

Just checked SkyMass's radio + labels and they are fine.

whalesalad 2y ago

op figured out iteration and incremental improvement

tracker1 2y ago

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.

aaronkaplan 2y ago

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?

hcarvalhoalves 2y ago
Is not UI programming, it’s designing UIs on top of HTML and CSS. There’s way too many degrees of freedom, while basic things like forms should work well by default.
ivan_gammel 2y ago
It is not that complex. The nice ways to describe UI in code do exist. It is a business problem of a zero-sum game, where cross-platform UI is prohibitively expensive when it’s not done on the ugliest UI stack (HTML/CSS/JS).
wruza 2y ago
In this case (web) it’s a result of too low granularity without anything that could help a developer interested in proper ui. Simply too much work to just catch up. You can see the same in other areas. E.g. if there’s no easy way to send a request or parametrize to a query, people will invent all sorts of half assed ways to do that, even if mindful about it, due to natural pressures. Web platform is absolutely bleeding edge graphics, but actually dogshit ui. And no one has nerve to admit it and make a change because people believe in the first part and then legacy and complexity of browsers prohibit it. And when you do it as a lib, it’s not “standard”, so nobody cares.
dmalik 2y ago
This is what design systems are for. You only sand UI when you're initially creating the component. Sometimes you combine components in different ways or need to make a one off. It honestly doesn't take all that long if you know what you're doing. A good design engineer is a specialist for this type of role.