Sanding UI
blog.jim-nielsen.com
blog.jim-nielsen.com
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.
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.
There's a menu bar for the entire email chain, and an "Actions" button for each mail message. Report Spam is only available in the former, and Report Phishing is only available in the latter.
I agree, it's annoying! Maybe someone at Fastmail will see this.
Guess they really live up to their promise
With a brand new user account, I was not at all able to reproduce your issue. I closed the browser and cleared cache and all that, but I did not see an entire page refresh at any point.
Perhaps there's some weird caching issue with your browser, or maybe you've got a browser extension misbehaving? Maybe I'm just lucky? Idk, but hopefully this helps.
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
No one's sanding anything there.
https://littlebigdetails.com is exactly that
Windows 2000. Everything newer has been slowly downhill.
CSS is too powerful, OOB HTML is too basic/ugly.
But then some people don't like the button: it's not animated enough for them, the corners aren't rounded enough, the button is too skeumorphic, or not skeumorphic enough, there is too much / not enough white space, etc etc. Everyone has a different idea of what the new button should look like, and we're immediately back to fragmentation.
There are financial incentives to seeming trendy and new, and that requires constant change. The standard <button> may be sturdy and steady and not require three hundred npm packages, but it will never, by definition, look trendy or new.
It absolutely prevents me from hitting the windows key and hitting the up button twice or three times mattering on if logout is there if my memory serves right after shutdown to get to run and then hit enter or just simply use the arrow keys on the desktop to get to my computer and hit enter which are all things I could do on Windows 3.1 by hitting the alt button to open up the menu or tab to switch between icons in the highlighted thing which are actually all things that I could do on Windows 2000 Windows XP Windows server 2003 Windows Vista Windows 7 Windows 8 Windows 8.1 Windows 10 Windows 11 Windows 98 Windows 95
There is no point in sanding something that someone else is using hammer and chisel on. FAANGS are the companies of continuously delivered websites, self-updating evergreen software, churners of framework-du-jour that are deprecated sooner than you can say "FAANG". Even if took the time to sand something, it would be replaced by something else the following day.
Yes, frontend moves quickly and there is a new framework every day. No, most products teams at FANGs are not rewriting frontends in a new framework every year.
I find the aesthetics of free to play games very stressful and unsatisfying (lots of notifications and popular to distract you), but they ARE effective at getting me to click into menus to make those nuisances go away
premium iOS apps. Procreate {,Dreams}, Photomator, Overcast, Crouton, Mela, Carrot Weather, Apollo.
Like, nobody, including the original issue author is actually enthusiastic about the fix. It’s just one less papercut.
I’m sure if these things were actually seen by devs they’d add a two line change to a random PR and it would be done in a few minutes.
You might get amazing UX mocks and wireframes and designs etc from the UX team, and the mockups from Figma or whatever may have user-tested really well, but if there is huge latency in the real implementation then that is a usability-killer IMO, regardless of how polished the UI is.
But I think asking for a UI toolkit/framework is more helpful. Otherwise, you optimize for straightforward use cases, like entering a search box.
Stripe is also quite excellent but not entirely bug free. I think they have a bit more surface area though.
I'd look to study lots of internal tools that don't get marketed or outside influences. That would be interesting to find out. Where's the crossover from just enough resources to make it exist and enough resources to leave it as "finished"
To me: Sense of hierarchy is off, accessibility is meh, there's an enormity of information per page, there's poor use of color and spacing... it could be worse but I can imagine this site giving my designer friends a seizure.
<label>
Foo
<input>
</label> input:focus + label {}
label:has(input:focus) {}Maybe not for the screenreaders of today, but maybe for the screenreaders of tomorrow.
I guess it is kinda beside the point though as it was just an example to illustrate the point.
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.]
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.
It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output.
Management is likely out of touch with the demands of creating a high quality product. This leads to misalignment with the development team and probably the business needs. Most businesses need a higher quality product than they have. Some don't, though. In those circumstances it doesn't really matter - I recommend avoiding these places like the plague.
Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? It is how it is used, not what it was used for.
When working on my own apps it's really obvious that non focused time leads to lots of improvements. Instead of only the business wishes. In that regard it seems that the potential of a dev is a bit diminished when you don't have time to do things according to your own priorities.
Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
No we don't.
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.
Man, Discord does have a "posts" feature that works similar like a forum. If you draft a text there, the HOME/END keys are all messed up and you can't select text with shift, or move by word holding CTRL (I don't remember the specifics at the moment).
I have reported that a couple of times over the past 3 years, because that makes the drafting text *extremely* difficult and frustrating.
As a web dev myself, I wonder how this even broke in the first place. Meaning, I wonder what kind of incompetency is needed to break something, that works out of the box. Anyhow, this should be a fix that cannot possibly take longer than 30 minutes to fix and would immediately make the user experience 1000 times better for everyone. Yet, the bug is still there 3 years after reporting it.
I also reported a bug in Teams, where you cannot use the HOME/END keys in the phone number input, to Microsoft, through Premiere Support. The reply was: This works as designed.
I am not surprised that customers don't report these kind of bugs any longer, because neither the employees/developers, nor the company doesn't give a shit anyway.
From the business point of view, why would they spend time and money on fixing these things unless it's hurting sales or brand? Long term it likely does affect the brand but most people will have moved role/company in 5 years so don't care.
I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”.
That’s if you get a response at all.
L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something.
We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly).
Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all.
You can probably guess how user-friendly that software was, and how much the users liked it.
If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step.
For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done.
One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout.
The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation.
The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.
In some rare cases there's a direct feedback button in the product itself. Then usually you don't get the response, but at least your remarks are read by someone. Or at least that's the impression I get.
As a positive example - check out the new commit view page in GitHub which they are currently rolling out. There's a Feedback button which goes to a *public* discussion page with voting and comments. One can tell they are really into listening the feedback. And that's something. At least one of the miracles for free.
You obviously have a process that does not serve your customers' needs: work with your team to fix it.
If you have SCRUM ceremonies, a retrospective is where you can raise it, but really, any time works (retrospectives are to purposely look at the past few weeks, but things you notice along the way, look to solve along the way).
I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software.
At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, certainly for the past 17 or 18 years, mostly some flavour of agile that most closely aligned with Scrum. It's not been that great anywhere, and there are a handful of places it's been outright terrible.
Reality check: if agile never gets any better than "not that great" then maybe agile is the problem.
There's different kinds of software. The software I work on now, the advertisers are the real customers, not the users of the app. So the users have basically zero buying power unless they stop using the app and we need to attract them back, but a small bug like this isn't going to do that.
The other kind of app you sell to a company. They want a good app that meets their business needs, but the ones making purchasing decisions still aren't the Frontline staff that have to use it. And there's no way a bug like this is making it up their internal chain and then over to the vendor.
And even if all of that happens, I have trouble believing this would be prioritized in a sprint. The only way anything gets fixed is if by some miracle an eng with the power to fix it either notices himself or if the app is popular enough, someone tweets about it and he happens to read it. It'll never make it through the formal chain.
I know this because as an eng who would rather do some sanding then add more useless features... Well, then the PMs wouldn't have anything to do.
It’s saying that the people behind the agile alliance and so on aren’t actually working in software engineering. Many haven’t since 20 years before the birth of Python. They’re also famous for handling any form of criticism with “you didn’t understand our principles”. Which to be fair is often completely correct, but maybe it’s because those principles are horrendous?
What it has lead to is an industry full of pseudo-jobbers. As others point out… your software engineers, can, do the work if you let them. Even if you don’t, you have no guarantee that your added personal actually catches errors like the ones in this article. Because human testers usually aren’t part of the team in any meaningful way.
(I understand that this goes completely against the textbook idea of scrum, but there is always the textbook and "the way we do scrum at our company", and those two often have very little in common.)
Agile is a failure because it imagines this pixie dreamland where every replaceable cog in the machine somehow has the ability to dramatically change how the machine operates. We don't. We don't get to design the machine we are a part of because that's not how capitalism works.
My personal experience is that you have to blame the people and not the method.
I would define my current project as very agile in the sense that we only have details plan for what to do a week ahead at the time. Each week the team has an hour long meeting where we present what we have done, and discuss if it's good enough. If something like a hover region is found to be wrong it will get fixed for next week. If you find this issue while working on something else, you make task and PR and just fix these smalls things. I feel like this way of working is what what meant by the people who invented the idea of making software development agile.
It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.
it'll be a low priority ticket with a very large tshirt size because the product manager doesn't want it done and the newbie who estimated it doesn't know what's going on, so it'll take a very long time to figure out.
Companies don’t want Software Artisans.
Agree wholeheartedly. Back & forth emails, screenshots, Q&A (what version are you on?), etc. The number of times I make it to checkout on the last step and something breaks on a certain version of a browser
Writing CSS for every checkbox makes no sense in Agile.
To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.
I’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.
https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
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?
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.
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.
> 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-separa...
But not for keeping the input outside of the label.
I've brought up it here just because parent comment stated what perhaps majority of developers believe:
> [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'.
As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.
> 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.
This is not a problem for radio buttons, but I suspect a few people have been bitten by this and do it "just to make sure". In the same way, adding a semi-colon at the end of a line of JavaScript is rarely useful but people put them everywhere because they don't know when it's needed exactly (granted that one is a bit tricker to remember).
Put the label around the input, then put a span for the text if you want some styling for the text. You can even make the label display:flex and handle the positioning of the text that way.
It’s good to know those tests cases to start, but random testing quickly outpaces planned testing when trying to find small issues. Also planned testing is often happy path or expected errors. Sanding like this finds edge bugs much faster.
I hope all of them. :-)
Makes no sense right? Weirdos, all of them!
It’s kind of a QA tactic in a sense
I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.
However, not every developer will craft a great UI just given time, I've seen some truly inspired monstrosities.
I also usually spent a few minutes in each UI page doing a test I called “spaz clicking” which, just like it sounds, consisted of just randomly clicking as fast as I could and moving the mouse around. Surprising how many bugs you’d find that way.
I 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.
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.
Or maybe it's our collective frustration with processes and expectations that make it very difficult to be a craftsman--and that make web app UI bad in general.
I remember my boss being frustrated with how long it was taking me to build a set of filtering dropdown components from scratch (one of the most difficult to get right). I stuck with it and put in some extra hours to really get all the small details right. Later that year, he asked me to tech-lead a newly forming team of UI engineers.
A year later, everyone called it great work and no one remembered how long it took.
Having well sanded features doesn’t necessarily remove bugs directly drive conversion, but it gives the entire product an established professional “feel.
Even though your customers feel it, they won’t explicitly articulate it
I mean, it is probably very rare to have two products that have the same features, and the only difference is how nicely done they are. For example, MediaWiki is in my opinion 100x better than Confluence, but Confluence has some extra features that I don't care about but managers do (stuff like easily attaching PowerPoint presentations to web pages), so the managers decide that the company uses Confluence. And I keep silently screaming in frustration every time I lose a part of text during editing, or the links break when a typo in a page name is fixed (because there is no option to add a redirect), etc.
The extra feature often wins, when the salesman describes the product to the manager who makes the buying decision. That's why we have the "checkbox features" that most end users don't care about, but it allows the product to seem better in comparison. Feature creep is how stuff gets sold.
The situation of two featurewise identical products competing only on better UI would probably be highly unstable, even if it happened somehow. There are network effects, so if one product starts winning, most people will switch to that product because "that's what everyone else is using". The other product will be left without money to pay for development, and will go out of business. Afterwards, the winning product does not have to care about their UI anymore.
If it's not, it will lead to your users being confused and/or frustrated which will lead to them looking for an alternative tool.
If you're product is the only one in town, then they're just left to deal with it until a competitor pops up with a better (whether real or perceived) UI.
Wouldn't they be the same? If i perceive some ui as awful, it's real(ly awful). A program I've used since the 80s has progressively been 'flattened' and is now a complete pain to use - to such an extent I often prefer to fire up ye olde atari emulator. To me - the pain is real, and perceived.
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.
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.
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.
Spaces, yes.
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.
If you sort videos by popularity there's a lot I enjoyed where she does a "UX roast" of SaaS or streaming websites
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.
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.
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
> 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.
I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit
...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit
<label>
<input ... />
<span>Some text...</span>
</label>
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.
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.
<radio>foobar</radio>
<radio mark=end>foobar</radio>
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.
- 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.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.
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.
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!
I've come across the reverse scenario quite a few times, where the label isn't clickable, but this variant was new to me.
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.
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...).
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.
Can also lead to an ugly gap in your navbar depending on which container you're making scroll.
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.
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.
Totally paid off.
Working on another app now. Sweating the details on the 'watercourse way.' That first experience is critical.
Just recently have done quite naturally the same thing... Expand the clickable surface area of a region
Bootstrap changing this in v4 is no excuse to not do it.
For anyone seriously interested in how to get a great finishing with sanding here’s the guide I follow:
https://www.blacktailstudio.com/blog/how-to-sand-wood-proper...
I use a planer a lot but I'm still struggling with making multiple passes down a wide piece of wood. I often end up with grooves. I've gotten better over time but I'm still not happy with the results.
https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
A better way would be to compare the size of Stack Exchange boards at 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.
But the tech market is centered in cities where owing a garage with tools in your 20s isn't possible.
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.
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.
If you miss them by even a slight amount, the view does this annoying animation which hides the frunk and trunk butttons for about a second. You have to wait for the animation to stop before trying again.
So damn annoying.
If your text remained in place but the control were not focused, what would that control then indicate? In Safari now it _always_ indicates (a) the current page, or (b) your current typing. To do otherwise would be to create a third state: “Used to be typing.” Then it would no longer unambiguously indicate the current state.