I think being a big user of whatever you're building is incredibly useful for finding these kinds of issues. If you're a big user as well as a dev then you will often stumble on these little things before a user does, and you are also perfectly placed to fix these issues before users can stumble on them.
I suspect this is why small teams with strong ownership can be so effective. If you feel ownership of a thing then you feel users' pain when they hit these little paper cuts, and it becomes a point of personal pride to fix these things and make the UX as smooth as possible.
I wonder what’s the most polished or “sanded” UI out there? You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ. Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes. Compare this to big box stores l…
RockAuto is my favourite website. Incredibly simple and utilitarian, but also quite powerful. You can easily drill down or search for parts, depending on what is more intuitive to you. Price comparison is automatic, and grouped into useful price/quality categories. You can see year/make/model compatibility for a part number once you’ve found it, as well as a brief description, at least 1 picture (usually more), and determine whether it will be shipped from the same warehouse as other parts in your cart. It does all this with 0 friction, from one page, blazing fast on any platform. I end up ordering almost all my car parts there, not because they necessarily sell the best parts but because it’s just so easy to.
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. […
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.
Agile isn't entirely irrelevant, it's also not the main issue.
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.
The goto tactic for this specific ` ` problem is: Foo
Even with nesting you still need for/id attributes to make it accessible to common voice command software: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
Not sure I agree with the conclusion of that article, according to it, only 2 screen readers don't support nested labels, I couldn't find statistics on how prevalent these are, but there are a lot of alternative screen readers one could use which might support nested labels since they're not mentioned there (I've mainly heard of JAWS, which isn't mentioned there), so it doesn't seem to be an inherent limitation of assistive technology, just a bug in some (popular?) screen readers.
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.
Even with nesting you still need for/id attributes to make it accessible to common voice command software: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
Not sure I agree with the conclusion of that article, according to it, only 2 screen readers don't support nested labels, I couldn't find statistics on how prevalent these are, but there are a lot of alternative screen readers one could use which might support nested labels since they're not mentioned there (I've mainly heard of JAWS, which isn't mentioned there), so it doesn't seem to be an inherent limitation of as…
VoiceControl and Naturally Speaking aren’t screen readers: they’re voice command software. They’re designed for people with mobility problems, not vision problems. There’s no inherent limitation here that couldn’t be solved by bug fixes, but they’re the two major pieces of assistive tech in that sector so can’t be dismissed without dismissing people who need that functionality.
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.
I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.
> Let the eng get a little bored and they'll find stuff to fix.
That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.
It's just a general romanticization of how programmers work: if we have more time we'll fix everything. No we don't.
You do not speak for me. I think but can't prove that you don't even speak for most programmers.
He is not speaking for me but all enterprise projects I worked was like that. When devs (me included) run out of high priority tasks we ask or are directed to more high priority tasks, not fix the minor label/input issue, or the border of the disabled button in resolutions smaller than 400px, or whatever the PM/Scrum master didn't prioritize. Tired of bad management, developers just do what master Jira tell us to do.
I do my best to fix all open bugs in my own software, tho.
> 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 desi…
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 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.
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.