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.
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.
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.
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.
I used RockAuto for the first time recently. The site is super dense with info and functionality, but never once did I feel lost or overwhelm. Neither did I feel like anything was missing. Everything I needed to see and do was exactly where it should be. It's so rare for the screen to disappear like that. It's so transparent that I _almost_ can't say it's a joy to use (it's a joy to use!).
FastMail has one of the best-feeling web apps I've ever used. It's incredibly snappy and I never encountered any bugs while using it. They raised the bar for what I thought a web app could achieve.
I think the only thing I really dislike about Fastmail's UI is they've hidden the "Report phishing" and "Report spam" links and they're in two completely different places.
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.
I love fastmail but the webapp does this one thing that drives me crazy: The first (and only the first) email I read triggers a reload of the entire page for some reason. It's pretty quick but very jarring...wish I knew what was going on; anyone else see this?
I'd never used Fastmail and as a sometimes-UI guy, thought I'd check out their 30 day trial to see what all the praise was about. I saw your comment before going, so kept that in mind.
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.
I see this.
My assumption is its some kind of html/js cache, local storage across browser sessions maybe. And when you click an email it realizes it needs to update.
Agree! Only bummer is when I want to create calendar events and reference email details, or vice versa. On desktop it’s easy enough to have two tabs, but on mobile, it’s a pain. I get why it is the way it is, but we are talking about exceptional UX here, and I think there is room for improvement.
How exactly do you imagine displaying those things at the same time on a mobile screen? While I agree it would be exceptional, I also think we shouldn’t expect the impossible.
I don’t know but there is my use case, I would expect a product and design team to figure it out as best they see fit. Or throw it out.
Maybe auto-suggestions as you type into certain fields? You’re typing into the location field of a new event and received a hotel booking receipt email in the last 2 hours, perhaps the address of that hotel could be a smart auto-suggestion? Things like that.
I can name multiple Facebook features that have been broken for months. Temporary profile pictures most annoyingly of all. They stopped working close to a year ago. They simply never change back.
The incentive structure doesn’t encourage it. Nobody gets a promotion for going back and fixing issues; it’s all about new initiatives and boosting metrics with new ideas.
The thing that gets me is how slow all of it is. And I’ve programmed against facebook APIs, which are ludicrously performant! Hundreds of megabytes of data in single digit milliseconds total roundtrip.
exactly, one example is there are a lot of programatically absolute positioned divs to break ad-blockers or make them very inefficient, while the performance of the app suffers from many tricks like these as well.
The "feeds" screen in the app has been throwing errors for at least a year ("Feed isn't available right now"). I only try to use the screen because a while back it was the only way to view content in the correct order.
Hate how it loses its place on the page and reloads when you zoom into a picture on mobile. I mean you have to go far out of your way to f’up that bad.
I really wish we had something resembling a "native" UI toolkit, but for the web. Just throw together a couple <button>s or <input type=checkbox>es with absolutely zero additional JS/CSS, but have it actually look & work moderately decent, the way SwiftUI does.
I like minimal, semantic frameworks like Pico CSS for this. You just give it HTML and it looks really nice. Tools like Bootstrap are great when you need more control but they also encourage more fiddling.
Bootstrap started as something like this, but it both evolved too quickly IMO, and for some reason a generic look on the web is considered bad (by who? marketing? designers? even users as they think lack of distinctive style means lack of developer skills?)
Exactly, and meanwhile relied on jQuery until the most recent major release (3 years ago).
Once you're starting with one framework (no matter how "lightweight"), you can't gradually introduce a different one that better fits your problem domain, you usually have to rip it out & redo at least some parts.
> [...] for some reason a generic look on the web is considered bad [...]
Yeah it is bad. I won't go into specifics but it's horribly bad, and the sheer amount of CSS frameworks out there is evidence enough.
But the main problem isn't even that it looks (&works) ugly, it is also lacking/incomplete as a basic UI toolkit. How long did we wait to have a standardised date picker? Color picker? Where's the progress bar? Context menu? Tab bar? Icons with labels, representing files/objects? Half the other stuff we've had figured out in the 1980s and considered absolutely necessary by 90s?
Fire up Borland Delphi Builder from the 90s and marvel at how easy it was to stitch together a simple UI that looks decent next to every other app that ran on your computer. JS is ~30 years old, and we've been building web apps even before that, there was plenty of time to match it - but we've spent it on churning through frameworks instead.
I myself started programming with Delphi from 90s, but your arguments sound like only a perfect toolkit would be useful. I'd be perfectly happy to have 80% of Delphi 7 VCL in web-native format with a clear defined way to add custom components that fit in. Like color picker, which more often than not needs customization. And not like it was themable back then. WinXP-level theming should be enough.
We do have a native toolkit for the web. You put a <button> down, the browser will render a button.
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.
I would say Project Chicago was maybe one of most consistent UI projects ever executed. Too bad they kept reinventing parts of it, so now we have a mishmash of different UX paradigms, some better, some worse, but certainly inconsistent. At least it’s not macOS though.
Yes Windows 2000 distracts me from what I want to actually do with a computer, point and click.
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 SO much bloat in all the “modern” UI “culture”. Reinventing things over and over again. Creating entire frameworks for tiny, simple things. And the worst part of web UIs is that (though there have been efforts to address this) there is low regularity between the experiences especially compared to native UI apps where you are purposely restricted to a set of controls which look and behave the same across all apps that use them.
I've listened through some of the developer commentary on Half Life 2 and Half Life Alyx and the amount of user testing coupled with attention to detail really impressed me. The same can't be said for Steam though :/
> You would think FAANG would have a half decent UI and UX with the amount of money they have.
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.
I have no idea where you got this idea from. Can you give some examples showing that switching to a new framework is a common at FANGs?
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.
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.
IMO the biggest issue used to be that it wouldn't tell you the shipping cost until after you ordered. A few years ago they fixed that, but it still only gives you a total cost and doesn't tell you how your ordered is split into different shipments.
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.
Azure Standard has an incredibly polished experience for shopping. It's not _perfect_ (if you know where to put your hands you can find a place that isn't perfectly sanded) but the sheer level of smoothness across the transaction flow is unmatched by anything else I have ever had the pleasure of using in the "online shopping" category.
Mobile games, especially those with microtransactions. They're highly incentivized to offer a satisfying user interface. So as to get more money, of course.
They don’t optimize for satisfying interfaces, they optimize for driving engagement.
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
imo GitHub has to be up there. I think some of the recent changes to search and making the code view more IDE-like are steps backward from a “polish” perspective, but still useful features
GitHub specifically has the issue mentioned in this blog post! It annoyed me so much I had to file it with them three years ago, and it’s still not fixed: https://github.com/orgs/community/discussions/7506
I like the IDE "defined here/used here" features but I wish the page would be faster. It can be quite painful to read code on GitHub. The code view is also broken and unusably slow in some mobile browsers (Firefox) when scrolling horizontally
This sort of problem (speed) is a much overlooked secondary functionality requirement IMO.
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.
Just browsed McMaster. What a clean interface! Very easy to drill in and see what you are looking for. Compare that with the promotion of paid ads on the many major e-commerce platforms.
Idk. I just visited the site (McMaster) for like 2 minutes and found a few annoying things. I filtered for cotton (o rings). Nothing happens after click for 4 secs. Then it chooses something else to filter on.
Next the animation to get the filtering menu is bugging out. And dragging it down triggers a site refresh.
The best UI is no UI. Anyone who tries to design for increased engagement isn't who you're looking for.
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"
mcmaster is the most polished ui/ux you know? To each their own but this is a very hackernews comment - it's very much a site for engineers but I can't agree it's a polished UI or UX.
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.
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?
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.
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).
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.
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.
I think it's for material design inspired focus animations. :has selector wasn't a thing, so you have to use + sibling selector to target the label of a focused input
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.
Incidentally Bootstrap 5.3 seems to have the same problem as the article describes. There is a gap which doesn't do anything if clicked, right between the radio button and the label.
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.
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.
Fair enough, so to test things out I've enabled Voice Control and tried whether it makes a difference how the elements were arranged:
At least with Chrome, it does not make a difference! It correctly determined the label and I could just tell it to click on that particular checkbox.
Since Dragon Naturally Speaking doesn't seem to have a trial, as well as having a broken shop page you can't order from, I can't give it a test, but that articles advice seems rather questionable to me.
At the end of the day it’s your users’ problem. Ideally their assistive tech would work, but if it doesn’t and you’ve got an easy fix then you should implement that fix.
I disagree. Of course you could fix that. But that would mean that you can fix a thousand and one issues that's caused by other softwares erroneous content handling. Which leads to nothing but bloat and introduces just more code that could come with more bugs.
If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.
Your software isn’t working, because the user cannot use it. Your UI is always a combination of whatever hardware and software come together to give an experience. Everyone chooses to marginalise certain segments of users’ technologies – I don’t support IE any more of course – but I typically won’t drop support for technologies that are vital assistive technologies for that segment of users.
(If you need a personal story to bring it home, the only way my dad, a programmer in the 70s-90s, could continue to use computers when he suffered from MND / ALS, was to use voice control software.)
You’re basically enabling for these shitty variants of voice control software to exist. Html, css and js allow dor more granularity in how ui works, but using them this way is just absurd.
shrug They exist regardless, and the users have no real other options. I’ve found in my career that devs tend to fall into the “caring about the effect” and “caring about the artefact” buckets, and I guess you’re in the second category? There’s no one right place to be – without people in the second we‘d have less effective solutions overall – but I hope your team is also balanced by people in the first.
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.
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.
Just a note that in a framework like react, this will introduce an error that propagates when people attempt to use something like “google translate” on your site. You’d need to wrap the “Foo” in an element to mitigate.
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'.
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.
That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)...
But not for keeping the input outside of the label.
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.
Having done a lot of accessibility consulting in the past (granted it was a long time ago now), we were instructed to use the aria-label attribute to provide the same text as the label.
Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object.
<%: Html.AccessibleCheckbox("MyCheckbox", label: "My Checkbox") %>
This would output something like:
<label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label>
This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.
Ah interesting, I figured that a properly set and identified label element would suffice - I haven’t noticed our sniffer complaining yet we also strictly use the for attribute and don’t wrap controls that I’m aware of. Thanks for the insight!
If you use a Rails helper to create a checkbox it puts a hidden field next to it with the "off" value to ensure something always gets POSTed back. I assume other frameworks do the same. If you put a <label> element around those two input fields, it's no longer valid HTML.
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).
This is how I've been doing it for at least 15 years (maybe 20, by now?). It's also much cleaner syntax for the typical use case of checkboxes/radio buttons.
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.
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.]
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.
The best way to build products I've found is to
1. hire passionate engineers.
2. give engineers enough room to breath and collaborate on the product.
Every project that uses Agile defeats 2.
I'm not saying that Agile is the reason for this but after 15 years of seeing this repeatedly I'm very wary of places which place Agile as a component of their culture.
Even better, let the devs just watch the users use the product.
I often join support when they have a call with a customer demonstrating an issue. I also sometimes get to join support when they're on-site for training or similar.
Every time I watch users use our product, I learn so much about what to do and what not to do.
> 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.
Where deviance is normalized, sure. If that dev didn't have to rely on 52 "weird tricks" and half-assed hacks just to keep their local environment running, they might care more about the quality of the product. But when everything around you has the grime of "just do enough to get it barely working", that's the game.
The will to have nice things is a cultural value that some companies just don't have, and if they don't have it for themselves, they won't have it for their customers.
sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.
I can't help thinking that the "fungible engineer" concept has done a lot of harm to tech hiring and team structure - of course if you take a guy who most is excited about database optimisation and put him on UI work he won't be passionate about it.
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.
Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible.
It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer?
Actually, not a good example, because I usually don't buy software. OK, I buy Windows, but... I don't feel like I have a choice between more polished and less polished versions of Windows. Other than that, I use free software. When I use software at work, someone else made the decision and I had zero input. And that kind of software usually sucks (now I am thinking of Confluence, Jira, and other user-hostile monstrosities).
So I guess a part of the answer is that if you sell software to business, there is no need to make it nice, because the people who decide whether the company buys it are not the ones who will be stuck with using it.
I wish users more aggressive about their software. At least once a week I hear something along the lines of:
> I'm not a technology person, so I can't make X do Y
It would be so much better if the go to response was:
> This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either.
If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.
I think you are on the right track, but realistically I think the answer is even more cynical: the last 20 years in software has been all about refining business models that remove choice and disempower customers. Quality doesn’t matter. Privacy doesn’t matter. Price matters a little, but only in the sense that you need to make your monthly SaaS fee low enough to avoid sticker shock- you don’t need to provide real value though. Just keep milking those monthly fees and make the UI a little worse every year or so.
Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.
> It seems like quality has much less of an impact on sales than many of us would wish.
This is the unpleasant truth of the matter. As people who hone our craft and want to take pride in our work, a competent developer’s ethos is at odds with maximizing profit.
It's the balance between staying in business, going out of business, reducing employee count, increasing employee count, etc. Also how much unpaid overtime is the dev willing to put into the project. That seems to be what causes most of us to not be allowed to put in the required time for properly sanding the UI.
Agile is relevant here because it has been adopted almost universally as a shovel to push more things on the programmer's back without much care to the quality of the changes being done.
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.
> Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto?
Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in.
Given current business tendencies,
the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.
Agree, we have some time in sprints to do whatever we want, and then you finally can fix those minor annoyances that are probably the users annoyance too.
But in general I think more time should be there reserved for it. It's now once in x sprints.
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.
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.
"Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.
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.
> 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.
I’m not sure if you meant this to be sarcastic but I think you’re on to something. In both cases: a rebellion against a soul crushing authoritarian system by writing a manifesto describing a decentralized utopia… which then gets implemented in an authoritarian context and undermined along the way until all that remains is the name and some window dressing from the manifesto. Orwell’s Animal Farm still resonates because of this.
If somebody says “be agile; do A, B, and C for better software engineering”, and you do not A, not B, and not C then complain about how terrible agile is, the problem is not with agile. You did something different to agile and got different results, so why are you blaming agile for your own failure?
It is, in fact, possible to implement agile wrong – by doing the exact opposite of agile. This is not a rhetorical trick you are catching people out on.
> 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.
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”.
I worked as a sysadmin in a large physical services company. We had in-house software that integrated with almost all levels of our operations, most employees were using this software throughout their day. The whole IT staff, including the team of ~10 devs who built and maintained this software, worked in-person on the same floor.
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.
In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that.
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 my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product.
Yes. But also HELL NO.
Back when we were a small company and I did a bit of everything, from infrastructure management to support, on top of actually doing dev work, taking to them was the bit I dreaded most at times!
I do occasionally interact with our customers' technology/security teams as part of my remit is dealing with ingesting this party data and pushing information (or making it available to be pulled) the other way. That can be irritating enough, you would not believe the amount of people working in that area that don't properly understand SFTP and, for instance, get thoroughly confused by key based auth.
In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored
A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.
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.
This is so true. I'm the lead developer for a product and we have loads of small issues all over the place. It is not a great feeling to be responsible for something while also not having any power to fix it.
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.
This sounds like a lead/architect issue. If you can't roll out a custom UI component library, use one of several mature libraries that already handles these cases. Accumulating tens or hundreds of thousands of lines of UI tech debt is not an Agile issue.
it is hurting sales and brand, the underlying problem is that to dramatically increase performance requires recomping both the tech team and the management and likely also the executives whose decisions shape and limit the org in the first place. In any org, the #1 priority for everyone involved is to keep their salary flowing, which means not replacing themselves with someone better.
The idea behind "agile" is to recognize when something isn't working and improve it.
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.
Fixing “agile” is not the point. Find a process (and iterate on it) that helps you ship good software. I think there’s a bunch of stuff in the agile toolbox that’s helpful. Pick and mix that works for you.
Maybe the business just doesn’t value shipping good software all that much - plenty don’t.
This is something those wishing to build higher quality software often forget: business mostly care about return on investment.
As software engineers, it's our job to find exactly the right balance of quality and speed, and strategies to increase quality with no detriment to speed, for what is usually asked of software engineers.
Just like bridge and building engineers do not design those structures to stand up to 1000x the forces that they expect those structures will experience, software engineers need to learn to build with just the right level of complexity to quickly provide quality solution to a business need.
And that's where software engineers really struggle, and agile helps keep that in check, but in practice does not really improve quality. Software engineers should come up with ways to achieve quality with limited resources (just like engineers do everywhere else), and the best teams I worked in or with have!
There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should".
Yes, the usual tools (JIRA, yuck!) and methodologies (SCRUM, SAFe...) tend to be the problem as they are too prescriptive and too cumbersome and verbose. But they are simply a set of tools to have in one's belt once you hit some common themes, but yes, some take them to heart.
I think true agility is only achievable with a switch to proper outcome-oriented goals which give a lot of liberty to engineering teams. Otherwise, the decision makers on what gets built and how are too far removed from those doing the building.
But that means a mindset shift for engineers (and everybody else!), in that they need to stop thinking about projects, and start thinking about results they achieve.
I do agree that the fact that most get this wrong (I remember a new TL writing down a 30 page document on teams' "agile processes") means that something has been lost in translation, and "Agile" really isn't.
I think it's fair to say that agile method is something to strive for, but never fully realise.
But, what would you propose we call the type of process we strive for, and is there a methodology/strategy you do like?
What are the principles of building software and building high quality software that worked for you in a team?
> There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should".
Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for.
"Let engineers build software the way they think they should," is an alien concept to all the businesses I've experienced. Now, as it happens, I don't necessarily think engineers should have the last word either, because I've seen too many people disappear down too many rabbit holes and not deliver anything valuable, but clearly agile is broken.
I am sorry that was your experience, and not because of "agile" — businesses which leave expertise to experts usually excel IME. The one gotcha is that you want to have good questions asked along the way (by PMs, business people...), and not necessarily have the "last word", when smart engineers will realize sooner when they are on the wrong path. This combination of talent is rarely achieved without specifically recruiting for it.
To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.
I worked in companies that are committed to Agile and companies that have a completely custom planning and development process. I don't understand your argument. What process in Agile dictates shipping subpar UI?
Build, test, file bugs, resolve bug. You can do this within any framework. Or, better, develop a high quality UI component library instead of asking a junior engineer to write CSS for correct checkbox handling.
Particularly with Scrum, people get hung up on the 'rules' of the 'process'.
For example, following the rules of Scrum, if a developer finds a bug, decides to fix it, and wants to commit the fix such that it can be tested and closed out then that bug needs to first be assigned to the current sprint before the developer can touch it. It's extremely constraining and antagonistic towards shipping good software.
In my experience, unnecessary processes can creep in into any org, regardless of the planning framework used. Agile or no Agile, over-planning cripples teams.
I don't buy this. Not serving the customer's needs? Is this the paying customer's #1 feature request/bug fix? It's probably some poor random sap that has to use the software and notices it.
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.
But that's because you care about the output vs what might bring value to the company.
If things never bubble up, does that not mean that this is really a non-issue?
You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done.
And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
> If things never bubble up, does that not mean that this is really a non-issue?
It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up.
And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress)
> And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.
You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues?
> Why would you make the gap clickable?
I already said why: if everyone expects that behaviour (OP obviously did).
Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language).
Regarding technical challenges, didn't OP switch to padding? How is that different?
The idea behind agile is to sell you training and later consulting once your organisation fails to adopt it in any meaningful way because it’s principles are so vague your culture, will, get it wrong.
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.
Fun fact: most companies doing "scrum" actually don't have retrospectives.
(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.)
As long as you fix things that don't work or make you less effective, it does not matter if it's a retrospective, or stop-the-line approach, or whatever your nameless approach is.
Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.
When it’s something this trivially small, why don’t you just… do it? So long as you can demonstrate your ability to deliver on “real” work, why not just knock these tiny things out too if you can? Work it into an adjacent change if that comes up. “But my manager and PM and CEO all say this is ILLEGAL TO DO” always seems to be the answer… but if your company isn’t completely rotten to the core with toxic waste, I don’t think anyone is going to axe you for making small microscopic incremental product improvements…
Because it’s not small. Doing what the article describes takes a very significant amount of time. Especially compared to a much more directly estimated and measurable action like “add x feature”. Doing what is described halfway will likely return poor results since noticing the subtle things like the example given only happens when trying many times with a tendency to try random things that you didn’t before. Who purposefully clicks somewhere they never did before, QA people. Most engineers are not QA, and they don’t even begin to think in a way that leads them to try things that they didn’t before just to try to find a few pixels of unclickable UI. Your assumption that the kind of work described is small is a much bigger problem than any so called assumption that blaming the PM and CEO is at fault.
priority matters though, if you want to go full Apple with UI/UX then you need to lock the UI/UX for years, like Apple does, and refine every little thing to bring a fully ecstatic UX to the user. Or accept that most users won't notice that or wouldn't mind it behaving like that and build new features that will bring useful behaviours to the app (and revenue to the company).
If you have to spend 50 hours to explain why it's a bug, most likely only you care about it.
In some cases it may matter to be THAT precise with UI/UX and it's cool, not saying i don't appreciate quality but you can't have everything.
One thing I'd like to point out is that most of the time it isn't even a matter of priority, lots of dev energy gets wasted in useless refactors and picking "the right library/framework" and building the "next outdated design library", instead of being used to improve things ;)
Apple does many things right but things like Mail.app got thrown to the side for years. There's still many odd utilities here and there that have not seen any love like grapher.
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.
I don’t know what we’re calling “agile”, but it’s explicitly supposed to capture this. You use the product, get feedback (from either yourself or users), and iterate on it.
It sounds like you have organisational failures that prevent you from getting the feedback or iterating on 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.]
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
Not sure what this has to do with Agile. Companies that move fast and have complex UI almost always use React (or similar) and a UI component library that handles all these edge cases.
Writing CSS for every checkbox makes no sense in Agile.
You can recommend adding analytics to all your flows. Then recommend some of these sanding tasks in order to improve metrics such as drop-off rate. Managers are more inclined to say yes when there is data involved.
> 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.
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.
> QA doesn’t make a ticket for the space between, it’ll never get fixed.
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.
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.
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.
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.
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.
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.
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.
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.
Before I started in infosec I was a software tester for a year in the mid-90s. We called this kind of testing “monkey testing” and usually spent some time on it because it turned up lots of bugs, both code bugs and design/usability bugs. One time I delayed our product’s launch by a day because I found a crashing bug in the “about” dialog (missing handler for keyboard shortcut).
I also usually spent a few minutes in each UI page doing a test I called “spaz clicking” which, just like it sounds, consisted of just randomly clicking as fast as I could and moving the mouse around. Surprising how many bugs you’d find that way.
I've been "sanding" my personal website (https://dustinbrett.com) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
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!
This is really fun. A usability note, at least on Safari on iOS, you have to put the protocol for a web page to load. If you just put www.cnn.com without the https, it never loads.
This is cool and very polished, but my advice (which may not resonate with you) is that you should channel this attitude into some user-facing app instead of letting it basically go to waste on a personal website most people won't see or won't use for more than a second or two.
I definitely didn't necessarily mean an app that had a way to make money. I mean exposing the work to more people who would get fun or utility out of the painstaking effort put into it. The world could use this sort of taste in a game, an activity, a tool, etc.
Yes, but you can make free apps for a wider audience. Or even just useful apps for yourself.
Can do what pleases you though. I sometimes work on intentionally useless apps just to try things out, but the idea is always to carry those ideas over to some app that has some purpose.
With no abstract artists, art museums will have bare walls (which is fine, if the wall is the one they gave to me... but nobody wants to look at a bare wall and pretend its art for a whole museum!)
Marketting seems useless sometimes, but when Pepsi spent their marketting budget on community projects, they lost a ton of sales. My local ice rink has no marketting and nobody in the county knows it exists, even people who would like to do ice skating or ice hockey; a smidge of marketting would be super useful; other rinks in neighboring counties have doubled or more the number of kids playing hockey in the past few years since we got a local NHL team, but ours struggles to get a single full team at most age groups.
Landlords are not well liked on HN, but seems to me having a place to live on a month to month basis was pretty handy before I had the ability to make a long term commitment to a single place. I know some people buy a place to live for college, but an off campus rental seemed a lot more sensible to me. And similar when moving for work if you're not sure you'll be there long term, or you want out of a hotel before you're sure of what neighborhoods you like.
I personally don't care much for abstract art, but if your goal is to produce an art piece, then sure, that's a purpose. I don't know if OP was going for "art" or just having fun with the tech. I wouldn't count it as art because it's very much a copy of an existing piece of software, not an original piece.
> Others were made for study at art academies in the late nineteenth century and later, while the statue has also been replicated for various commercial reasons or as artistic statements in their own right. Smaller replicas are often considered kitsch.[2]
There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying to make, because I wouldn't generally describe carbon copies as art. It's a copy of art, but not really artistic in itself.
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.
It's not kind of a QA tactic, this is literally the definition of QA. Specifically, this post is about ad-hoc functional testing. Kinda funny how this kind of testing used to dominate, but in the era of CI/CD, dedicated QA departments, and fancy webdriver suites, we've flipped too far the other way, and developers need to be reminded to QA their own stuff!
I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.
This is (potential) an advantage of small teams and individual developers. In more formal teams developers are often handed a UI and that's what they have to build, no variation permitted.
However, not every developer will craft a great UI just given time, I've seen some truly inspired monstrosities.
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.
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.
> That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has
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.
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.
I guess what I learned from the article is how crazy it is that developers are still putting UIs together with text labels and padding and flexbox-this and align-that. What kind of stone age shit is this? Back in the '90s we were putting UIs together with controls already polished and perfected by the OS vendor, presumably backed by man-years of UX research from those companies. The controls themselves had styling, behavior, event handling, and so on baked in. Fast forward to today's web development, where we've regressed to drawing text inside rectangles and trying to handle click events on those rectangles, and/or wrestling with half-baked "frameworks" that poorly do some subset of what OS-provided controls did 30 years ago?? UI development seems like cooking in a clay pot over a fire that you had to start with flint.
The root cause here is that unlike native OS controls, most native web controls are primitive as heck.
So companies that don't want to look like Craigslist end up either using an off-the-shelf UI controls library (not a bad decision, in my opinion), or building their own.
Along with the second option, a new set of disciplines is emerging: the design system designer and engineer. Since companies have grown so accustomed to building their own bespoke design language (instead of using the one the OS ships with), it's doubtful that a well-designed set of modern, native web controls (that ship with browsers) would be able to compete with the notion of "having a bespoke design system".
Also, white-label libraries (like Radix UI) are increasingly appearing that handle all the implementation details and leave the appearance to be defined.
Absolutely agree, there’s so much to lose with completed ui controls. It’s akin to the situation when you disassemble a device for the first time, then reassemble it and it’s always some parts left on the table.
Styling and customization are useful and interesting topics in ui. But instead of thinking it through, most libs today just throw a ball of wires at the developer who is clueless and often couldn’t care less even.
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
Is there actually a competition where the UI could decide the winner?
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.
It's not about how nice the UI is is, but rather how responsive it is and if it's providing your users with enough feedback.
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.
Eliminating “friction” is a huge part of maximizing conversion and retention, both of which are important metrics for early stage startups. It’s only once you achieve significant momentum that you can afford to let these types of UX annoyances slide. The risk is that once you do that, the normalization of deviance makes your product end up like Jira.
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.
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.
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.
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.
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.
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.
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.
If I understand you correctly, you mean to build up one test suite, and apply it to many diverse applications?
I'm afraid that will be pretty hard to accomplish, given that such requirements are not easy to distill from the user interface itself, and impossible to obtain from the codebase (which, by definition, would contain bugs that you'd like to catch).
Perhaps LLMs or a "user interface foundation model" might come in handy to find these implicit requirements, and run tests on the application.
Not sure I’m proposing a single test suite, although some of these invariants are very likely applicable to multiple components or sites. I’m just saying that property based testing ought to be applicable to UIs, but it’s not the sort of thing we’ve experiment with because executing the tests is slow. That’s probably fixable in a practical way that’s still more efficient than human QA for a large class of bugs (including both the back button and non-convex hitbox issues mentioned in the article).
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.
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.
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.
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.
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.
It’s an important insight that the state space for UI is very large and that is why intuition is especially useful — it’s rarely feasible to account for all possibilities analytically. This is true to some extent in all areas of software development, but I think for UI dev moreso than most.
I 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.
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.
> 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
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.
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.
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.
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.
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.
> 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.
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.
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.
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
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...
I love using 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
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?
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.
- 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.
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.
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.
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!
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.
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.
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!!!
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.
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.
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.
> 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.
“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
Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com makes the layout shift a bit in Safari on macOS. The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space.
I once spent hours debugging this before I realized what was happening, my confusion coming from the fact that with the inspector open that wasn't the case (As there the scrollbar was always visible...).
> 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.
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.
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?
This applies to mobile apps a lot. If you're not careful (especially when using the iOS/Android simulators too much) you can create tiny awkward hit boxes for buttons that are difficult to tap with fingers
i always wrap the labels around the radio buttons and checkboxes. the animation also shows nicely that the label should not be selectable text. if one wants to further polish it a hover highlight might look nice at times.
Drawing a box around the radio buttons is perhaps not modern but it may make the form more usable.
The title or description of the element should not be the same as the options.
The 4 times might belong in two or more groups. This is something to dwell on, make a few mockups then most likely it shouldn't be used. If it doesn't jump out as amazingly useful restore normality.
consider lining up the time so that the :'s sit in a line. Try put the PM in a collum too. Maybe there should be AM as well.
Keep doing useless experiments until you strike gold. It should be really hard to beat default form elements (unless it is iphone)
Your truly fantastic 1000 line text input should most likely be deleted.
the example animation probably has insufficient line height. The user shouldn't have to aim that much.
I have found the same to be true in game development once all the pieces start coming together. There is no substitute to just using the thing. Maybe you don't find bugs/splinters, maybe you realise that it just doesn't feel right once you've glued the components together.
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.
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.
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.
I have not used a belt sander! I prefer to start with a planer, then use an orbital sander! Generally work from 60 grit up to 220 depending on the surface. Popping the grain and covering the whole surface in pencil marks in between each!
For anyone seriously interested in how to get a great finishing with sanding here’s the guide I follow:
Thanks for posting it! Good point about adding the right lighting rig, haven't thought about.
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.
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 . 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.
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.
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.
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.
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.
On the Tesla screen, parked view you can tap the frunk and trunk buttons to open them.
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.
OMG yes! That appeared in the somewhat recent UI revamp and I’m so tired of mashing at that button. Not only is it unavailable for what feels like more than a second, but now it’s in a different place
Reading this on Safari on my iPad, the favicon for this tab is the Youtube logo. I genuinely have no idea how this bug came about, but it's been like that for months now.
Safari is really, really bad when it comes to everything around favicons. The biggest annoyance being it doesn’t accept updates, so things like mail status favicons don’t work.
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.
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.
The problem is real the customer isn't the business that buys the software, it's the end user that is frustrated and tired of the shitty UI but is powerless to effect any kind of change because their management chain and execs don't give a fuck either.
I believe that the iPad behavior you describe is intentional. I’m not sure I’m right here, and there are tradeoffs. I get frustrated with it too. But I think Apple is going for clarity, lack of ambiguity.
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.
This is only tangentially related, but the Safari address bar already does not always indicate the current state, specifically when pages take time loading and when going back and forth in history. There is some kind of broken synchronization between page display and address bar, in conjunction with page loading timeouts.
That being said, I would be fine with an "address bar has been edited but not commited yet" state. It's how most other (desktop?) browsers work and it's not an issue.
I've never understood the claim that Apple's UIs are better than others'. That wasn't true while Jobs was around, and it isn't true now. Apple Photos, for example, loses keystrokes every time I create a new album. That's been true for years. And Time Machine randomly drops files from backups. Linux isn't perfect, but my daily experience using it has been far superior for years.
Time Machine's "Floating Time Tunnel" user interface for browsing backups and restoring files is such a useless pretentious piece of shit. I DO NOT CARE for it taking over the entire screen with its idiotic animation, that prevents me from browsing current Finder folders at the same time or DOING ANYTHING ELSE like looking at a list of files I want to retrieve on the same screen.
It even sadistically blacks out every other connected display, and disables Alt-Tab, as if it was so fucking important that it had to lock you out of the rest of your system while you use it.
You can't just quickly Alt-Tab to flip back to another app to check something before deciding which file to restore and then Alt-Tab back to where you were. No, that would be too easy, and you'd miss out on all that great full screen animation. It not only takes a long time to start up and play its opening animations, but when you cancel it, it SLOWLY animates and cross fades back to the starting place, so you LOSE the time and location context that you laboriously browsed to, and then you have to take even more time and effort to get back to where you just were.
It was designed by a bunch of newly graduated Trump University graphics designers on cocaine, with absolutely NO knowledge or care in the world about usability or ergonomics or usefulness, who only wanted to have something flashy and shiny to buff up their portfolios and blog about, and now we're all STUCK with it, at our peril.
Crucial system utilities should not be designed to look and operate like video games, and turn a powerful mutitasking Unix operating system interface into a single tasking Playstation game interface. ESPECIALLY not backup utilities. There is absolutely no reason it needs to take over the entire screen and lock out all other programs, and have such a ridiculously gimmicky and useless user interface.
Whatever the fuck is wrong with Apple has been very very wrong since the inception of Time Machine and is STILL very wrong. How can you "Think Different" if you're not bothering to think at all?
>Core Animation will allow programmers to give their applications flashy, animated interfaces. Some developers think Core Animation is so important, it will usher in the biggest changes to computer interfaces since the original Mac shipped three decades ago.
>"The revolution coming with Core Animation is akin to the one that came from the original Mac in 1984," says Wil Shipley, developer of the personal media-cataloging application Delicious Library. "We're going to see a whole new world of user-interface metaphors with Core Animation."
>Shipley predicts that Core Animation will kick-start a new era of interface experimentation, and may lead to an entirely new visual language for designing desktop interfaces. The traditional desktop may become a multilayered three-dimensional environment where windows flip around or zoom in and out. Double-clicks and keystrokes could give way to mouse gestures and other forms of complex user input.
>The Core Animation "revolution" is already starting to happen. Apple's iPhone at the end of the month will see people using their fingers to flip through media libraries, and pinching their fingers together to resize photos.
>The "Delicious generation" is a breed of young developers who embrace interface experimentation and brash marketing. The term "Delicious generation" was meant as an insult, but they wear it as a badge of honor.
>Image: Adam BettsShipley's initial release of Delicious Library, with its glossy, highly refined interface, gave birth to a new breed of developers dubbed the "Delicious generation." For these Mac developers, interface experimentation is one of the big appeals of programming.
[...]
>Apple has been ignoring its own HIG for some time in applications like QuickTime, and is abandoning them completely in upcoming Leopard applications like Time Machine.
>Functionality-wise, Time Machine is a banal program -- a content-version-control system that makes periodic, automated backups of a computer's hard drive.
>But Apple's take on the age-old task of incremental backups features a 3-D visual browser that allows users to move forward and backward through time using a virtual "time tunnel" reminiscent of a Doctor Who title sequence. It's completely unlike any interface currently used in Mac OS X.
[...]
>While it seems logical to speculate that interfaces like those of Time Machine and Spaces will lead to the end of the familiar "window" framework for desktop applications altogether, many Mac developers predict that the most basic elements of the current user interface forms won't disappear entirely.
Hard disagree over here. Apple's not always been good but my experience has usually been better than the competition (at least OSX 10.4+). They've been on a downward trajectory, certainly I've whined a lot about how bad MacOS 14 is, but their main competition (Microsoft) has also been working to lower the bar. Linux on the desktop's largely been a non-starter for me due to Apple's ARM stuff and disinterest in spending the effort to find compatible hardware.
I've not used Apple for photo stuff past monkeying around with Aperture. However I recently tried digikam, darktable, and rawtherapee. Darktable in particular was atrocious, and if that's how Gtk apps are on Linux I'd consider that another strike against desktop Linux. All three crashed or hanged repeatedly. You could rather easily dismiss some things like keyboard shortcuts not being aligned (rawtherapee) or partially aligned (darktable) with MacOS norms. Even the lack of app signing (darktable, digikam) and mix of cocoa and gtk widgets could be attributed to big bad Apple.
But once you dig into them it's a rogues gallery. Darktable has two different modules for setting the white balance (ugh). Countless issues have been opened (and then closed) over this on github. The docs explain when each one comes into play. With the default settings if you believe the docs and change the module that's supposed to be active, you'll get an error. Widgets respond to mouse events even if you think the cursor isn't over the widget. Rawtherapee, for some reason, renders the metadata widget as blurry mess to the point of the text being illegible.
To me it feels like open source projects sneer at ease of use (especially after looking at how bug reports are dealt with) vs commercial software companies willingness to fund a UX team.
That doesn't sound too complicated? There's two things here being conflated, the view and the data.
You can show the current state when not in focus and show the edit state when in focus.
Or view it from the angle of the input. Show the current state or edited, but the input device could be smart enough to auto-fill a field if you click off and click back onto it within a short time period.
I don't know if it's a Windows/Mac thing, click/touch thing, or Apple vs others thing. I do notice that on Chrome/Firefox/Edge on Windows, when you click away from address bar after modifying the URL, it does not revert the value. Actually same on Android.
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.
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.
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)
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.
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.
We’re and enterprise making things for enterprises. You better believe the SSO part is well tested xD
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.
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.
I used RockAuto for the first time recently. The site is super dense with info and functionality, but never once did I feel lost or overwhelm. Neither did I feel like anything was missing. Everything I needed to see and do was exactly where it should be. It's so rare for the screen to disappear like that. It's so transparent that I _almost_ can't say it's a joy to use (it's a joy to use!).
FastMail has one of the best-feeling web apps I've ever used. It's incredibly snappy and I never encountered any bugs while using it. They raised the bar for what I thought a web app could achieve.
I think the only thing I really dislike about Fastmail's UI is they've hidden the "Report phishing" and "Report spam" links and they're in two completely different places.
To clarify:
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.
Always thought this was strange too and bad UX too
Agreed. And that you can't mark a folder as read. Everything else is stellar.
Yes! It doesn't make sense. It took me ages to remember where to go for each.
That's an unfortunate decision
recently switched all our mail to FastMail and that took 1ish hour... I was ready to spend a couple of days to wrestle switching mail providers.
Guess they really live up to their promise
I love fastmail but the webapp does this one thing that drives me crazy: The first (and only the first) email I read triggers a reload of the entire page for some reason. It's pretty quick but very jarring...wish I knew what was going on; anyone else see this?
I'd never used Fastmail and as a sometimes-UI guy, thought I'd check out their 30 day trial to see what all the praise was about. I saw your comment before going, so kept that in mind.
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.
I see this. My assumption is its some kind of html/js cache, local storage across browser sessions maybe. And when you click an email it realizes it needs to update.
Agree! Only bummer is when I want to create calendar events and reference email details, or vice versa. On desktop it’s easy enough to have two tabs, but on mobile, it’s a pain. I get why it is the way it is, but we are talking about exceptional UX here, and I think there is room for improvement.
How exactly do you imagine displaying those things at the same time on a mobile screen? While I agree it would be exceptional, I also think we shouldn’t expect the impossible.
I don’t know but there is my use case, I would expect a product and design team to figure it out as best they see fit. Or throw it out.
Maybe auto-suggestions as you type into certain fields? You’re typing into the location field of a new event and received a hotel booking receipt email in the last 2 hours, perhaps the address of that hotel could be a smart auto-suggestion? Things like that.
+1 to Fastmail. More so after I discovered their shortcut keys.
Linear (of linear.app) has a highly polished UI. In fact they had a dedicated period for fixing just usability issues:
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
I wish they'd make more apps. I use Linear but with a team of 1, it's not exactly the best fit for me.
Linear has the best UI/UX of all the web apps I have used. After Gmail and Google Maps, I don't recall any other web app wowing me as much as Linear.
I can name multiple Facebook features that have been broken for months. Temporary profile pictures most annoyingly of all. They stopped working close to a year ago. They simply never change back.
No one's sanding anything there.
The incentive structure doesn’t encourage it. Nobody gets a promotion for going back and fixing issues; it’s all about new initiatives and boosting metrics with new ideas.
If you look at the HTML output of FB, IIRC it is about 100 levels deep <divs> that cause me physical pain.
The thing that gets me is how slow all of it is. And I’ve programmed against facebook APIs, which are ludicrously performant! Hundreds of megabytes of data in single digit milliseconds total roundtrip.
They do this in an attempt to combat ad blockers. It's an arms race that is sadly bound to create cruft like this.
exactly, one example is there are a lot of programatically absolute positioned divs to break ad-blockers or make them very inefficient, while the performance of the app suffers from many tricks like these as well.
It actually is slow, you can see the loading bar load... In 2024 with the hardware we have, it is BAD.
In 2024, Facebook feels like a defunct shopping mall that’s slowly falling apart, but still houses one or two businesses you depend on.
The "feeds" screen in the app has been throwing errors for at least a year ("Feed isn't available right now"). I only try to use the screen because a while back it was the only way to view content in the correct order.
Hate how it loses its place on the page and reloads when you zoom into a picture on mobile. I mean you have to go far out of your way to f’up that bad.
That time of the year when everyone can see there is craftsmanship in the tiny details.
https://littlebigdetails.com is exactly that
I wonder what’s the most polished or “sanded” UI out there?
Windows 2000. Everything newer has been slowly downhill.
I really wish we had something resembling a "native" UI toolkit, but for the web. Just throw together a couple <button>s or <input type=checkbox>es with absolutely zero additional JS/CSS, but have it actually look & work moderately decent, the way SwiftUI does.
CSS is too powerful, OOB HTML is too basic/ugly.
I like minimal, semantic frameworks like Pico CSS for this. You just give it HTML and it looks really nice. Tools like Bootstrap are great when you need more control but they also encourage more fiddling.
Bootstrap started as something like this, but it both evolved too quickly IMO, and for some reason a generic look on the web is considered bad (by who? marketing? designers? even users as they think lack of distinctive style means lack of developer skills?)
> Bootstrap started as something like this [...]
Exactly, and meanwhile relied on jQuery until the most recent major release (3 years ago).
Once you're starting with one framework (no matter how "lightweight"), you can't gradually introduce a different one that better fits your problem domain, you usually have to rip it out & redo at least some parts.
> [...] for some reason a generic look on the web is considered bad [...]
Yeah it is bad. I won't go into specifics but it's horribly bad, and the sheer amount of CSS frameworks out there is evidence enough.
But the main problem isn't even that it looks (&works) ugly, it is also lacking/incomplete as a basic UI toolkit. How long did we wait to have a standardised date picker? Color picker? Where's the progress bar? Context menu? Tab bar? Icons with labels, representing files/objects? Half the other stuff we've had figured out in the 1980s and considered absolutely necessary by 90s?
Fire up Borland Delphi Builder from the 90s and marvel at how easy it was to stitch together a simple UI that looks decent next to every other app that ran on your computer. JS is ~30 years old, and we've been building web apps even before that, there was plenty of time to match it - but we've spent it on churning through frameworks instead.
I myself started programming with Delphi from 90s, but your arguments sound like only a perfect toolkit would be useful. I'd be perfectly happy to have 80% of Delphi 7 VCL in web-native format with a clear defined way to add custom components that fit in. Like color picker, which more often than not needs customization. And not like it was themable back then. WinXP-level theming should be enough.
I still just throw in default bootstrap in a .container div when I need a fast prototype that looks decent.
We do have a native toolkit for the web. You put a <button> down, the browser will render a button.
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.
I would say Project Chicago was maybe one of most consistent UI projects ever executed. Too bad they kept reinventing parts of it, so now we have a mishmash of different UX paradigms, some better, some worse, but certainly inconsistent. At least it’s not macOS though.
Windows 3.1 was better. Windows 2000 introduced a lot of point and click, which just distracts from what you actually want to do on a computer.
Yes Windows 2000 distracts me from what I want to actually do with a computer, point and click.
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
amen. and at some point Gmail was perfect, but they kept fixing it, so now it's getting bloated, slow and occasionally just does random things.
There is SO much bloat in all the “modern” UI “culture”. Reinventing things over and over again. Creating entire frameworks for tiny, simple things. And the worst part of web UIs is that (though there have been efforts to address this) there is low regularity between the experiences especially compared to native UI apps where you are purposely restricted to a set of controls which look and behave the same across all apps that use them.
I've listened through some of the developer commentary on Half Life 2 and Half Life Alyx and the amount of user testing coupled with attention to detail really impressed me. The same can't be said for Steam though :/
> You would think FAANG would have a half decent UI and UX with the amount of money they have.
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.
I have no idea where you got this idea from. Can you give some examples showing that switching to a new framework is a common at FANGs?
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.
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.
IMO the biggest issue used to be that it wouldn't tell you the shipping cost until after you ordered. A few years ago they fixed that, but it still only gives you a total cost and doesn't tell you how your ordered is split into different shipments.
Yep, this is indeed annoying but infrequently pointed out.
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.
"Back" is the not the same thing, since you didn't necessarily come from the "Screws" category page.
Azure Standard has an incredibly polished experience for shopping. It's not _perfect_ (if you know where to put your hands you can find a place that isn't perfectly sanded) but the sheer level of smoothness across the transaction flow is unmatched by anything else I have ever had the pleasure of using in the "online shopping" category.
Mobile games, especially those with microtransactions. They're highly incentivized to offer a satisfying user interface. So as to get more money, of course.
They don’t optimize for satisfying interfaces, they optimize for driving engagement.
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
> I wonder what’s the most polished or “sanded” UI out there?
premium iOS apps. Procreate {,Dreams}, Photomator, Overcast, Crouton, Mela, Carrot Weather, Apollo.
imo GitHub has to be up there. I think some of the recent changes to search and making the code view more IDE-like are steps backward from a “polish” perspective, but still useful features
GitHub specifically has the issue mentioned in this blog post! It annoyed me so much I had to file it with them three years ago, and it’s still not fixed: https://github.com/orgs/community/discussions/7506
I have to love that someone enthusiastically announced there was going to be a fix.
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.
Couldn’t disagree more. GitHub has jank from the api to the ui.
I like the IDE "defined here/used here" features but I wish the page would be faster. It can be quite painful to read code on GitHub. The code view is also broken and unusably slow in some mobile browsers (Firefox) when scrolling horizontally
This sort of problem (speed) is a much overlooked secondary functionality requirement IMO.
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.
Agreed! Performance is the most important feature.
[dead]
Just browsed McMaster. What a clean interface! Very easy to drill in and see what you are looking for. Compare that with the promotion of paid ads on the many major e-commerce platforms.
Idk. I just visited the site (McMaster) for like 2 minutes and found a few annoying things. I filtered for cotton (o rings). Nothing happens after click for 4 secs. Then it chooses something else to filter on. Next the animation to get the filtering menu is bugging out. And dragging it down triggers a site refresh.
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.
Linear app is quite polished.
Stripe is also quite excellent but not entirely bug free. I think they have a bit more surface area though.
The best UI is no UI. Anyone who tries to design for increased engagement isn't who you're looking for.
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"
As far as app UIs go, I just started using Duolingo and their app seems to be tremendously well polished.
As something I’m using on a daily basis, Linear has one of the best product UI I experienced. It is extremely polished and snappy
I like zfs.rent, very small but still it's a functioning business site.
HEY! mail was great when I used it
Probably Netflix?
mcmaster is the most polished ui/ux you know? To each their own but this is a very hackernews comment - it's very much a site for engineers but I can't agree it's a polished UI or UX.
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.
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?
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.
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).
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.
The goto tactic for this specific `<label>` problem is:
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/
I think it's for material design inspired focus animations. :has selector wasn't a thing, so you have to use + sibling selector to target the label of a focused input
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.
Incidentally Bootstrap 5.3 seems to have the same problem as the article describes. There is a gap which doesn't do anything if clicked, right between the radio button and the label.
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.
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.
Fair enough, so to test things out I've enabled Voice Control and tried whether it makes a difference how the elements were arranged:
At least with Chrome, it does not make a difference! It correctly determined the label and I could just tell it to click on that particular checkbox.
Since Dragon Naturally Speaking doesn't seem to have a trial, as well as having a broken shop page you can't order from, I can't give it a test, but that articles advice seems rather questionable to me.
That feels somehow like building your website for IE6 because some people still use them.
The article is right. A nested input with a for attribute is always better than an input without one.
Maybe not for the screenreaders of today, but maybe for the screenreaders of tomorrow.
That’s the voice control software’s problem.
At the end of the day it’s your users’ problem. Ideally their assistive tech would work, but if it doesn’t and you’ve got an easy fix then you should implement that fix.
I disagree. Of course you could fix that. But that would mean that you can fix a thousand and one issues that's caused by other softwares erroneous content handling. Which leads to nothing but bloat and introduces just more code that could come with more bugs.
If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.
Your software isn’t working, because the user cannot use it. Your UI is always a combination of whatever hardware and software come together to give an experience. Everyone chooses to marginalise certain segments of users’ technologies – I don’t support IE any more of course – but I typically won’t drop support for technologies that are vital assistive technologies for that segment of users.
(If you need a personal story to bring it home, the only way my dad, a programmer in the 70s-90s, could continue to use computers when he suffered from MND / ALS, was to use voice control software.)
You’re basically enabling for these shitty variants of voice control software to exist. Html, css and js allow dor more granularity in how ui works, but using them this way is just absurd.
shrug They exist regardless, and the users have no real other options. I’ve found in my career that devs tend to fall into the “caring about the effect” and “caring about the artefact” buckets, and I guess you’re in the second category? There’s no one right place to be – without people in the second we‘d have less effective solutions overall – but I hope your team is also balanced by people in the first.
And unless you're google or facebook, people will not change their voice control software for your website.
This was my first thought. The entire text label should toggle the radio or checkbox, not just the box and the padding.
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.
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.
Just a note that in a framework like react, this will introduce an error that propagates when people attempt to use something like “google translate” on your site. You’d need to wrap the “Foo” in an element to mitigate.
I think that would not have worked with the grid CSS approach.
I guess it is kinda beside the point though as it was just an example to illustrate the point.
[dead]
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'.
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-separa...
That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)...
But not for keeping the input outside of the label.
Is that not what the ARIA standards are for?
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.
Having done a lot of accessibility consulting in the past (granted it was a long time ago now), we were instructed to use the aria-label attribute to provide the same text as the label.
Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object.
This would output something like: This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.Ah interesting, I figured that a properly set and identified label element would suffice - I haven’t noticed our sniffer complaining yet we also strictly use the for attribute and don’t wrap controls that I’m aware of. Thanks for the insight!
If you use a Rails helper to create a checkbox it puts a hidden field next to it with the "off" value to ensure something always gets POSTed back. I assume other frameworks do the same. If you put a <label> element around those two input fields, it's no longer valid HTML.
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).
This is how I've been doing it for at least 15 years (maybe 20, by now?). It's also much cleaner syntax for the typical use case of checkboxes/radio buttons.
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.
Because of the dogma of semantic web
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.]
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.
The best way to build products I've found is to 1. hire passionate engineers. 2. give engineers enough room to breath and collaborate on the product.
Every project that uses Agile defeats 2. I'm not saying that Agile is the reason for this but after 15 years of seeing this repeatedly I'm very wary of places which place Agile as a component of their culture.
An interesting critique of how Agile is practiced:
https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...
Even better, let the devs just watch the users use the product.
I often join support when they have a call with a customer demonstrating an issue. I also sometimes get to join support when they're on-site for training or similar.
Every time I watch users use our product, I learn so much about what to do and what not to do.
> 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.
Where deviance is normalized, sure. If that dev didn't have to rely on 52 "weird tricks" and half-assed hacks just to keep their local environment running, they might care more about the quality of the product. But when everything around you has the grime of "just do enough to get it barely working", that's the game.
The will to have nice things is a cultural value that some companies just don't have, and if they don't have it for themselves, they won't have it for their customers.
I think that says more about the engineers you've been working with than anything else.
sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.
Maybe hire some UX-focussed engineers then?
I can't help thinking that the "fungible engineer" concept has done a lot of harm to tech hiring and team structure - of course if you take a guy who most is excited about database optimisation and put him on UI work he won't be passionate about it.
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.
Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible.
It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer?
Actually, not a good example, because I usually don't buy software. OK, I buy Windows, but... I don't feel like I have a choice between more polished and less polished versions of Windows. Other than that, I use free software. When I use software at work, someone else made the decision and I had zero input. And that kind of software usually sucks (now I am thinking of Confluence, Jira, and other user-hostile monstrosities).
So I guess a part of the answer is that if you sell software to business, there is no need to make it nice, because the people who decide whether the company buys it are not the ones who will be stuck with using it.
I wish users more aggressive about their software. At least once a week I hear something along the lines of:
> I'm not a technology person, so I can't make X do Y
It would be so much better if the go to response was:
> This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either.
If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.
I think you are on the right track, but realistically I think the answer is even more cynical: the last 20 years in software has been all about refining business models that remove choice and disempower customers. Quality doesn’t matter. Privacy doesn’t matter. Price matters a little, but only in the sense that you need to make your monthly SaaS fee low enough to avoid sticker shock- you don’t need to provide real value though. Just keep milking those monthly fees and make the UI a little worse every year or so.
Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.
> It seems like quality has much less of an impact on sales than many of us would wish.
This is the unpleasant truth of the matter. As people who hone our craft and want to take pride in our work, a competent developer’s ethos is at odds with maximizing profit.
It's the balance between staying in business, going out of business, reducing employee count, increasing employee count, etc. Also how much unpaid overtime is the dev willing to put into the project. That seems to be what causes most of us to not be allowed to put in the required time for properly sanding the UI.
Agile is relevant here because it has been adopted almost universally as a shovel to push more things on the programmer's back without much care to the quality of the changes being done.
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.
> Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto?
Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in.
Given current business tendencies, the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.
Agree, we have some time in sprints to do whatever we want, and then you finally can fix those minor annoyances that are probably the users annoyance too. But in general I think more time should be there reserved for it. It's now once in x sprints.
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.
I think the key to your post is that waterfall or agile is irrelevant if you're getting work done and setting priorities
Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
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.
I legitimately question if waterfall was ever practiced beyond a very small niche of projects.
"Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.
By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...
A development process is not either Agile or “waterfall” anyway.
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.
> 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.
Perhaps the problem is that there are few self-organizing teams in companies. Managers needs to justify their salaries.
may I refer you to Karl Marx? Communism is perfect, it's just been implemented wrong.
I’m not sure if you meant this to be sarcastic but I think you’re on to something. In both cases: a rebellion against a soul crushing authoritarian system by writing a manifesto describing a decentralized utopia… which then gets implemented in an authoritarian context and undermined along the way until all that remains is the name and some window dressing from the manifesto. Orwell’s Animal Farm still resonates because of this.
If somebody says “be agile; do A, B, and C for better software engineering”, and you do not A, not B, and not C then complain about how terrible agile is, the problem is not with agile. You did something different to agile and got different results, so why are you blaming agile for your own failure?
It is, in fact, possible to implement agile wrong – by doing the exact opposite of agile. This is not a rhetorical trick you are catching people out on.
> 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.
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.
I worked as a sysadmin in a large physical services company. We had in-house software that integrated with almost all levels of our operations, most employees were using this software throughout their day. The whole IT staff, including the team of ~10 devs who built and maintained this software, worked in-person on the same floor.
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.
In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that.
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 my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product.
Yes. But also HELL NO.
Back when we were a small company and I did a bit of everything, from infrastructure management to support, on top of actually doing dev work, taking to them was the bit I dreaded most at times!
I do occasionally interact with our customers' technology/security teams as part of my remit is dealing with ingesting this party data and pushing information (or making it available to be pulled) the other way. That can be irritating enough, you would not believe the amount of people working in that area that don't properly understand SFTP and, for instance, get thoroughly confused by key based auth.
In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored
A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.
Yeah.
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.
This is so true. I'm the lead developer for a product and we have loads of small issues all over the place. It is not a great feeling to be responsible for something while also not having any power to fix it.
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.
This sounds like a lead/architect issue. If you can't roll out a custom UI component library, use one of several mature libraries that already handles these cases. Accumulating tens or hundreds of thousands of lines of UI tech debt is not an Agile issue.
Here is the correct answer to this, buried in the comments.
it is hurting sales and brand, the underlying problem is that to dramatically increase performance requires recomping both the tech team and the management and likely also the executives whose decisions shape and limit the org in the first place. In any org, the #1 priority for everyone involved is to keep their salary flowing, which means not replacing themselves with someone better.
Why do you not have any power to fix it?
The idea behind "agile" is to recognize when something isn't working and improve it.
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).
Stop drinking the koolaid, will you?
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.
Fixing “agile” is not the point. Find a process (and iterate on it) that helps you ship good software. I think there’s a bunch of stuff in the agile toolbox that’s helpful. Pick and mix that works for you.
Maybe the business just doesn’t value shipping good software all that much - plenty don’t.
This is something those wishing to build higher quality software often forget: business mostly care about return on investment.
As software engineers, it's our job to find exactly the right balance of quality and speed, and strategies to increase quality with no detriment to speed, for what is usually asked of software engineers.
Just like bridge and building engineers do not design those structures to stand up to 1000x the forces that they expect those structures will experience, software engineers need to learn to build with just the right level of complexity to quickly provide quality solution to a business need.
And that's where software engineers really struggle, and agile helps keep that in check, but in practice does not really improve quality. Software engineers should come up with ways to achieve quality with limited resources (just like engineers do everywhere else), and the best teams I worked in or with have!
There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should".
Yes, the usual tools (JIRA, yuck!) and methodologies (SCRUM, SAFe...) tend to be the problem as they are too prescriptive and too cumbersome and verbose. But they are simply a set of tools to have in one's belt once you hit some common themes, but yes, some take them to heart.
I think true agility is only achievable with a switch to proper outcome-oriented goals which give a lot of liberty to engineering teams. Otherwise, the decision makers on what gets built and how are too far removed from those doing the building.
But that means a mindset shift for engineers (and everybody else!), in that they need to stop thinking about projects, and start thinking about results they achieve.
I do agree that the fact that most get this wrong (I remember a new TL writing down a 30 page document on teams' "agile processes") means that something has been lost in translation, and "Agile" really isn't.
I think it's fair to say that agile method is something to strive for, but never fully realise.
But, what would you propose we call the type of process we strive for, and is there a methodology/strategy you do like?
What are the principles of building software and building high quality software that worked for you in a team?
> There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should".
Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for.
"Let engineers build software the way they think they should," is an alien concept to all the businesses I've experienced. Now, as it happens, I don't necessarily think engineers should have the last word either, because I've seen too many people disappear down too many rabbit holes and not deliver anything valuable, but clearly agile is broken.
I am sorry that was your experience, and not because of "agile" — businesses which leave expertise to experts usually excel IME. The one gotcha is that you want to have good questions asked along the way (by PMs, business people...), and not necessarily have the "last word", when smart engineers will realize sooner when they are on the wrong path. This combination of talent is rarely achieved without specifically recruiting for it.
To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.
Every single time this gets brought up we see the Agile defenders come up with "It's not agile, it's literally anything else.".
All I can say is if this is the common denominator...
I worked in companies that are committed to Agile and companies that have a completely custom planning and development process. I don't understand your argument. What process in Agile dictates shipping subpar UI?
Build, test, file bugs, resolve bug. You can do this within any framework. Or, better, develop a high quality UI component library instead of asking a junior engineer to write CSS for correct checkbox handling.
Particularly with Scrum, people get hung up on the 'rules' of the 'process'.
For example, following the rules of Scrum, if a developer finds a bug, decides to fix it, and wants to commit the fix such that it can be tested and closed out then that bug needs to first be assigned to the current sprint before the developer can touch it. It's extremely constraining and antagonistic towards shipping good software.
In my experience, unnecessary processes can creep in into any org, regardless of the planning framework used. Agile or no Agile, over-planning cripples teams.
"It's not real communism..."
I don't buy this. Not serving the customer's needs? Is this the paying customer's #1 feature request/bug fix? It's probably some poor random sap that has to use the software and notices it.
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.
But that's because you care about the output vs what might bring value to the company.
If things never bubble up, does that not mean that this is really a non-issue?
You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done.
And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
> If things never bubble up, does that not mean that this is really a non-issue?
It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up.
And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress)
> And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.
You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues?
> Why would you make the gap clickable?
I already said why: if everyone expects that behaviour (OP obviously did).
Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language).
Regarding technical challenges, didn't OP switch to padding? How is that different?
The idea behind agile is to sell you training and later consulting once your organisation fails to adopt it in any meaningful way because it’s principles are so vague your culture, will, get it wrong.
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.
Fun fact: most companies doing "scrum" actually don't have retrospectives.
(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.)
As long as you fix things that don't work or make you less effective, it does not matter if it's a retrospective, or stop-the-line approach, or whatever your nameless approach is.
Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.
When it’s something this trivially small, why don’t you just… do it? So long as you can demonstrate your ability to deliver on “real” work, why not just knock these tiny things out too if you can? Work it into an adjacent change if that comes up. “But my manager and PM and CEO all say this is ILLEGAL TO DO” always seems to be the answer… but if your company isn’t completely rotten to the core with toxic waste, I don’t think anyone is going to axe you for making small microscopic incremental product improvements…
Because it’s not small. Doing what the article describes takes a very significant amount of time. Especially compared to a much more directly estimated and measurable action like “add x feature”. Doing what is described halfway will likely return poor results since noticing the subtle things like the example given only happens when trying many times with a tendency to try random things that you didn’t before. Who purposefully clicks somewhere they never did before, QA people. Most engineers are not QA, and they don’t even begin to think in a way that leads them to try things that they didn’t before just to try to find a few pixels of unclickable UI. Your assumption that the kind of work described is small is a much bigger problem than any so called assumption that blaming the PM and CEO is at fault.
priority matters though, if you want to go full Apple with UI/UX then you need to lock the UI/UX for years, like Apple does, and refine every little thing to bring a fully ecstatic UX to the user. Or accept that most users won't notice that or wouldn't mind it behaving like that and build new features that will bring useful behaviours to the app (and revenue to the company). If you have to spend 50 hours to explain why it's a bug, most likely only you care about it. In some cases it may matter to be THAT precise with UI/UX and it's cool, not saying i don't appreciate quality but you can't have everything. One thing I'd like to point out is that most of the time it isn't even a matter of priority, lots of dev energy gets wasted in useless refactors and picking "the right library/framework" and building the "next outdated design library", instead of being used to improve things ;)
Apple does many things right but things like Mail.app got thrown to the side for years. There's still many odd utilities here and there that have not seen any love like grapher.
> This is so lost in Agile.
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.
I don’t know what we’re calling “agile”, but it’s explicitly supposed to capture this. You use the product, get feedback (from either yourself or users), and iterate on it.
It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.
It’s more of the artifact of ticket centric development, so I would blame Jira and the like before “programming self help” methodologies.
I feel like this goes along with the recent Artisan Software discussion on HN.
Companies don’t want Software Artisans.
Thanks, I think I just discovered my new job title :)
> [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.]
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
Not sure what this has to do with Agile. Companies that move fast and have complex UI almost always use React (or similar) and a UI component library that handles all these edge cases.
Writing CSS for every checkbox makes no sense in Agile.
You can recommend adding analytics to all your flows. Then recommend some of these sanding tasks in order to improve metrics such as drop-off rate. Managers are more inclined to say yes when there is data involved.
> 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.
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.
> QA doesn’t make a ticket for the space between, it’ll never get fixed.
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.
You guys have QA?
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.
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.
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.
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.
It’s called a cursor grab and in the web exists as el.setPointerCapture().
https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
Agreed. What "Papercuts" is on the negative side, "Juice"^1 (recently discussed here on HN) is to the positive.
1. https://garden.bradwoods.io/notes/design/juice
Meanwhile, some other UI uses square boxes for radio buttons.
Or have a highlighted button but the enter key doesn't activate it.
Or there are three different menus all behind a different symbol (ellipsis, hamburger, kebab).
There is a lot of variance in quality. Those of you who polish your UI: you are appreciated. Truly.
I think space is usually the key that performs a click on focused buttons, not enter.
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.
I was talking about the default button (typically blue, activated with enter), not the currently focused button (outlined, space).
Square or squircle seems to moving towards the standard for radio buttons now. Even Apple plays this game :(
File each as a bug, fight the good fight.
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.
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.
Before I started in infosec I was a software tester for a year in the mid-90s. We called this kind of testing “monkey testing” and usually spent some time on it because it turned up lots of bugs, both code bugs and design/usability bugs. One time I delayed our product’s launch by a day because I found a crashing bug in the “about” dialog (missing handler for keyboard shortcut).
I also usually spent a few minutes in each UI page doing a test I called “spaz clicking” which, just like it sounds, consisted of just randomly clicking as fast as I could and moving the mouse around. Surprising how many bugs you’d find that way.
I've been "sanding" my personal website (https://dustinbrett.com) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
Ok, be honest: how many hours put into this were during 9-5, and on the boss’ dime?
I hope all of them. :-)
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!
Looks incredible. Snappier than real Windows tbh
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.
this is very smooth and scratches an itch I didn't know I had -- to use a windowed OS on my phone
Looks really cool. One thing that I found missing is that I can't use mouse4/mouse5 in explorer. "Sanding" really could go on forever.
This is really fun. A usability note, at least on Safari on iOS, you have to put the protocol for a web page to load. If you just put www.cnn.com without the https, it never loads.
I wish Windows was that snappy! Incredible work, kudos!
Meanwhile we get a loading splash screen when opening a calculator.
Warning: Prepare for a jumpscare with authors face. Fun page
This is so fun. I love it. Well done!
very nice. though you cannot have > 1 nesting of dustinbrett.com afaict
On my iphone I can! Tested to 3 levels deep.
Nice man!
This is cool and very polished, but my advice (which may not resonate with you) is that you should channel this attitude into some user-facing app instead of letting it basically go to waste on a personal website most people won't see or won't use for more than a second or two.
It may surprise you, but some people like to program computers for reason other than money.
Makes no sense right? Weirdos, all of them!
I definitely didn't necessarily mean an app that had a way to make money. I mean exposing the work to more people who would get fun or utility out of the painstaking effort put into it. The world could use this sort of taste in a game, an activity, a tool, etc.
Yes, but you can make free apps for a wider audience. Or even just useful apps for yourself.
Can do what pleases you though. I sometimes work on intentionally useless apps just to try things out, but the idea is always to carry those ideas over to some app that has some purpose.
do you think makers of abstract art should do something more useful? how about people in marketing? landlords?
All of those things are useful.
With no abstract artists, art museums will have bare walls (which is fine, if the wall is the one they gave to me... but nobody wants to look at a bare wall and pretend its art for a whole museum!)
Marketting seems useless sometimes, but when Pepsi spent their marketting budget on community projects, they lost a ton of sales. My local ice rink has no marketting and nobody in the county knows it exists, even people who would like to do ice skating or ice hockey; a smidge of marketting would be super useful; other rinks in neighboring counties have doubled or more the number of kids playing hockey in the past few years since we got a local NHL team, but ours struggles to get a single full team at most age groups.
Landlords are not well liked on HN, but seems to me having a place to live on a month to month basis was pretty handy before I had the ability to make a long term commitment to a single place. I know some people buy a place to live for college, but an off campus rental seemed a lot more sensible to me. And similar when moving for work if you're not sure you'll be there long term, or you want out of a hotel before you're sure of what neighborhoods you like.
I personally don't care much for abstract art, but if your goal is to produce an art piece, then sure, that's a purpose. I don't know if OP was going for "art" or just having fun with the tech. I wouldn't count it as art because it's very much a copy of an existing piece of software, not an original piece.
https://en.wikipedia.org/wiki/Replicas_of_Michelangelo%27s_D...
> Others were made for study at art academies in the late nineteenth century and later, while the statue has also been replicated for various commercial reasons or as artistic statements in their own right. Smaller replicas are often considered kitsch.[2]
There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying to make, because I wouldn't generally describe carbon copies as art. It's a copy of art, but not really artistic in itself.
I think it's perfect. Art should be completely useless and yet spark joy - this one does both!
On the inputs.. for radio/checkbox, I prefer to wrap inside the label element.
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.
I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.
This is (potential) an advantage of small teams and individual developers. In more formal teams developers are often handed a UI and that's what they have to build, no variation permitted.
However, not every developer will craft a great UI just given time, I've seen some truly inspired monstrosities.
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.
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.
> That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has
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.
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)
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.
I guess what I learned from the article is how crazy it is that developers are still putting UIs together with text labels and padding and flexbox-this and align-that. What kind of stone age shit is this? Back in the '90s we were putting UIs together with controls already polished and perfected by the OS vendor, presumably backed by man-years of UX research from those companies. The controls themselves had styling, behavior, event handling, and so on baked in. Fast forward to today's web development, where we've regressed to drawing text inside rectangles and trying to handle click events on those rectangles, and/or wrestling with half-baked "frameworks" that poorly do some subset of what OS-provided controls did 30 years ago?? UI development seems like cooking in a clay pot over a fire that you had to start with flint.
The root cause here is that unlike native OS controls, most native web controls are primitive as heck.
So companies that don't want to look like Craigslist end up either using an off-the-shelf UI controls library (not a bad decision, in my opinion), or building their own.
Along with the second option, a new set of disciplines is emerging: the design system designer and engineer. Since companies have grown so accustomed to building their own bespoke design language (instead of using the one the OS ships with), it's doubtful that a well-designed set of modern, native web controls (that ship with browsers) would be able to compete with the notion of "having a bespoke design system".
Also, white-label libraries (like Radix UI) are increasingly appearing that handle all the implementation details and leave the appearance to be defined.
Absolutely agree, there’s so much to lose with completed ui controls. It’s akin to the situation when you disassemble a device for the first time, then reassemble it and it’s always some parts left on the table.
Styling and customization are useful and interesting topics in ui. But instead of thinking it through, most libs today just throw a ball of wires at the developer who is clueless and often couldn’t care less even.
People tend to underestimate the competitive advantage of a nice UI.
Absolutely.
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
Is there actually a competition where the UI could decide the winner?
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.
It's not about how nice the UI is is, but rather how responsive it is and if it's providing your users with enough feedback.
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.
Please elaborate a bit on real vs. perceived UI!
>(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.
Eliminating “friction” is a huge part of maximizing conversion and retention, both of which are important metrics for early stage startups. It’s only once you achieve significant momentum that you can afford to let these types of UX annoyances slide. The risk is that once you do that, the normalization of deviance makes your product end up like Jira.
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.
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.
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.
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.
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.
It is also very easy to develop systematic automated ways to do this with tools like Playwright and Nut.js.
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.
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.
If I understand you correctly, you mean to build up one test suite, and apply it to many diverse applications?
I'm afraid that will be pretty hard to accomplish, given that such requirements are not easy to distill from the user interface itself, and impossible to obtain from the codebase (which, by definition, would contain bugs that you'd like to catch).
Perhaps LLMs or a "user interface foundation model" might come in handy to find these implicit requirements, and run tests on the application.
Not sure I’m proposing a single test suite, although some of these invariants are very likely applicable to multiple components or sites. I’m just saying that property based testing ought to be applicable to UIs, but it’s not the sort of thing we’ve experiment with because executing the tests is slow. That’s probably fixable in a practical way that’s still more efficient than human QA for a large class of bugs (including both the back button and non-convex hitbox issues mentioned in the article).
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.
Someone should do a YouTube channel where they "sand" popular software products and point out these kinds of subtle UI bugs.
One person I saw do this is Mia: 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
You could probably do an entire channel out of just YouTube.
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.
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.
The lesson here is don’t split a control into two parts because developers will screw it up. Who prevented control designers from doing
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.
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.
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.
You know what.... this was an amazing post. There was a lesson, analogy, and a very to-the-point example.
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.
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.
> 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
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.
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.
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
...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit
The spec says either way (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.
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-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
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.
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.
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_implici...
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.
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/
[2] https://webaim.org/blog/jaws-license-not-developer-friendly/
Ah, I got it mixed with Orca. NVDA is the thing to target in Windows.
There’s no reason you can’t do both, and indeed some a11y linters recommend doing that
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.
I generally wrap my radios inside of the label for this reason. Is there a reason not to do that?
> 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.
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.
you can, with the power of :has!
label:has(input:checked) { background-color: orange; }
AFAIK, the only reason to use the label's `for` is when you want to place it in a different place from the widget.
It also helps with accessibility, screen readers etc
Not compared to including the widget inside the label.
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.
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
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...
I love using 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
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?
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.
I agree that these things should smooth it out. But so far the reality shows they do not.
I miss this attention to detail in popular websites' UI. Often even clicking on the label won't update the form.
My beliefs in the same vein:
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.
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.
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!
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.
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.
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!!!
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.
You can also do <label><input> label</input>
Anecdata, but I found the very same issue (the bermuda triangle gap between radioboxes, but also checkboxes, and their labels) in a project a few months ago.
It seemed a pretty big deal to me, specially because I always clicked on the gap, and got frustrated and angry at this. So I reported it to the UX team managing the design system, and to the developers implementing the design system, and nobody really cared. Some people even tried to convince me this behaviour was OK (because other design systems worked that way too, or because they were planning to refactor this on the far future so they didn't want to spend time on this).
I think the industry is now filled with people that just don't care, specially on big companies where, if it's not in a ticket, and if the ticket is not prioritized as critical, nobody cares. All they care about are metrics (test coverage, line count of a function, whatever). Pretty sad actually.
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.
> 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.
“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
Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com makes the layout shift a bit in Safari on macOS. The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space.
I once spent hours debugging this before I realized what was happening, my confusion coming from the fact that with the inspector open that wasn't the case (As there the scrollbar was always visible...).
> 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.
There's a newish CSS feature to fix just this: 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.
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
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-t...
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?
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
Just checked SkyMass's radio + labels and they are fine.
Meanwhile in Apple Photos, if you meticulously select 17 images and then accidentally click between photos, your selection disappears…
i always wrap the labels around the radio buttons and checkboxes. the animation also shows nicely that the label should not be selectable text. if one wants to further polish it a hover highlight might look nice at times.
Drawing a box around the radio buttons is perhaps not modern but it may make the form more usable.
The title or description of the element should not be the same as the options.
The 4 times might belong in two or more groups. This is something to dwell on, make a few mockups then most likely it shouldn't be used. If it doesn't jump out as amazingly useful restore normality.
consider lining up the time so that the :'s sit in a line. Try put the PM in a collum too. Maybe there should be AM as well.
Keep doing useless experiments until you strike gold. It should be really hard to beat default form elements (unless it is iphone)
Your truly fantastic 1000 line text input should most likely be deleted.
the example animation probably has insufficient line height. The user shouldn't have to aim that much.
I have found the same to be true in game development once all the pieces start coming together. There is no substitute to just using the thing. Maybe you don't find bugs/splinters, maybe you realise that it just doesn't feel right once you've glued the components together.
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.
Built an app when the iPhone first came out. Spent 2 months building the core app and another 3 months working to reduce the number of taps and remove road-bumps in the UI/UX flow.
Totally paid off.
Working on another app now. Sweating the details on the 'watercourse way.' That first experience is critical.
Sounds like op is manually fuzz testing.
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.
oof ouch I just got stabbed by a giant checkmarks-in-radio-buttons splinter
I prefer a well tuned smoothing plane or a card scraper, personally.
I really like the sticky face menu on the bottom right. Never seen this before. Gave me some inspiration for one of my sites.
Just put the input inside the label. Problem solved, no need for for=
Hard to believe this hasn't been abstracted and solved at the browser level in 2024.
It's hard to believe because it's not true. You wrap the input with a label and it works.
op figured out iteration and incremental improvement
Is this Jim Neilsen related to Jakob Neilsen (famous UI guy)?
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
That should be a metric... % clickable. Could look at app, page, component levels
The computer always exactly does what you told it to do. You almost never know what exactly you told it.
If you’re not putting the input inside the label then you’re doing it wrong.
Bootstrap changing this in v4 is no excuse to not do it.
Decent analogy. I wonder how many techies have ever used a belt sander. Or have one. I think very, very few.
I have not used a belt sander! I prefer to start with a planer, then use an orbital sander! Generally work from 60 grit up to 220 depending on the surface. Popping the grain and covering the whole surface in pencil marks in between each!
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...
Thanks for posting it! Good point about adding the right lighting rig, haven't thought about.
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.
If it’s a particularly wide piece of wood you could try a router planning jig. I think these are used with slabs
Otherwise you could try and get access to a CNC or a large industrial belt sander
Woodworking is a popular hobby where it's possible.
But the tech market is centered in cities where owing a garage with tools in your 20s isn't possible.
Your assumption is quite wrong.
https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
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 . 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.
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.
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.
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.
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.
On the Tesla screen, parked view you can tap the frunk and trunk buttons to open them.
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.
OMG yes! That appeared in the somewhat recent UI revamp and I’m so tired of mashing at that button. Not only is it unavailable for what feels like more than a second, but now it’s in a different place
Reading this on Safari on my iPad, the favicon for this tab is the Youtube logo. I genuinely have no idea how this bug came about, but it's been like that for months now.
Safari is really, really bad when it comes to everything around favicons. The biggest annoyance being it doesn’t accept updates, so things like mail status favicons don’t work.
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.
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.
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.
but then why not keep going down the line, and say that the customers also doesnt care?
The problem is real the customer isn't the business that buys the software, it's the end user that is frustrated and tired of the shitty UI but is powerless to effect any kind of change because their management chain and execs don't give a fuck either.
I believe that the iPad behavior you describe is intentional. I’m not sure I’m right here, and there are tradeoffs. I get frustrated with it too. But I think Apple is going for clarity, lack of ambiguity.
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.
This is only tangentially related, but the Safari address bar already does not always indicate the current state, specifically when pages take time loading and when going back and forth in history. There is some kind of broken synchronization between page display and address bar, in conjunction with page loading timeouts.
That being said, I would be fine with an "address bar has been edited but not commited yet" state. It's how most other (desktop?) browsers work and it's not an issue.
Yep it's just pure jank. Even Apple (especially post-Jobs) can produce jank.
I've never understood the claim that Apple's UIs are better than others'. That wasn't true while Jobs was around, and it isn't true now. Apple Photos, for example, loses keystrokes every time I create a new album. That's been true for years. And Time Machine randomly drops files from backups. Linux isn't perfect, but my daily experience using it has been far superior for years.
Well the Time Machine comparison doesn't really belong in a laundry list, it's basically Apple's greatest unmitigated disaster ever.
https://news.ycombinator.com/item?id=28355058
Time Machine's "Floating Time Tunnel" user interface for browsing backups and restoring files is such a useless pretentious piece of shit. I DO NOT CARE for it taking over the entire screen with its idiotic animation, that prevents me from browsing current Finder folders at the same time or DOING ANYTHING ELSE like looking at a list of files I want to retrieve on the same screen.
https://www.youtube.com/watch?v=CSwy_thSXow
It even sadistically blacks out every other connected display, and disables Alt-Tab, as if it was so fucking important that it had to lock you out of the rest of your system while you use it.
You can't just quickly Alt-Tab to flip back to another app to check something before deciding which file to restore and then Alt-Tab back to where you were. No, that would be too easy, and you'd miss out on all that great full screen animation. It not only takes a long time to start up and play its opening animations, but when you cancel it, it SLOWLY animates and cross fades back to the starting place, so you LOSE the time and location context that you laboriously browsed to, and then you have to take even more time and effort to get back to where you just were.
It was designed by a bunch of newly graduated Trump University graphics designers on cocaine, with absolutely NO knowledge or care in the world about usability or ergonomics or usefulness, who only wanted to have something flashy and shiny to buff up their portfolios and blog about, and now we're all STUCK with it, at our peril.
Crucial system utilities should not be designed to look and operate like video games, and turn a powerful mutitasking Unix operating system interface into a single tasking Playstation game interface. ESPECIALLY not backup utilities. There is absolutely no reason it needs to take over the entire screen and lock out all other programs, and have such a ridiculously gimmicky and useless user interface.
Whatever the fuck is wrong with Apple has been very very wrong since the inception of Time Machine and is STILL very wrong. How can you "Think Different" if you're not bothering to think at all?
Time Machine isn't just Apple Maps Bad...
https://www.youtube.com/watch?v=tVq1wgIN62E
It's QuickTime 4.0 Player Bad.
http://hallofshame.gp.co.at/qtime.htm
The most damning praise comes from Wired Magazine, 06.08.2007. Fuck Core Animation and the "Delicious Generation":
https://www.wired.com/2007/06/core-anim/
>Core Animation will allow programmers to give their applications flashy, animated interfaces. Some developers think Core Animation is so important, it will usher in the biggest changes to computer interfaces since the original Mac shipped three decades ago.
>"The revolution coming with Core Animation is akin to the one that came from the original Mac in 1984," says Wil Shipley, developer of the personal media-cataloging application Delicious Library. "We're going to see a whole new world of user-interface metaphors with Core Animation."
>Shipley predicts that Core Animation will kick-start a new era of interface experimentation, and may lead to an entirely new visual language for designing desktop interfaces. The traditional desktop may become a multilayered three-dimensional environment where windows flip around or zoom in and out. Double-clicks and keystrokes could give way to mouse gestures and other forms of complex user input.
>The Core Animation "revolution" is already starting to happen. Apple's iPhone at the end of the month will see people using their fingers to flip through media libraries, and pinching their fingers together to resize photos.
>The "Delicious generation" is a breed of young developers who embrace interface experimentation and brash marketing. The term "Delicious generation" was meant as an insult, but they wear it as a badge of honor.
>Image: Adam BettsShipley's initial release of Delicious Library, with its glossy, highly refined interface, gave birth to a new breed of developers dubbed the "Delicious generation." For these Mac developers, interface experimentation is one of the big appeals of programming.
[...]
>Apple has been ignoring its own HIG for some time in applications like QuickTime, and is abandoning them completely in upcoming Leopard applications like Time Machine.
>Functionality-wise, Time Machine is a banal program -- a content-version-control system that makes periodic, automated backups of a computer's hard drive.
>But Apple's take on the age-old task of incremental backups features a 3-D visual browser that allows users to move forward and backward through time using a virtual "time tunnel" reminiscent of a Doctor Who title sequence. It's completely unlike any interface currently used in Mac OS X.
[...]
>While it seems logical to speculate that interfaces like those of Time Machine and Spaces will lead to the end of the familiar "window" framework for desktop applications altogether, many Mac developers predict that the most basic elements of the current user interface forms won't disappear entirely.
Hard disagree over here. Apple's not always been good but my experience has usually been better than the competition (at least OSX 10.4+). They've been on a downward trajectory, certainly I've whined a lot about how bad MacOS 14 is, but their main competition (Microsoft) has also been working to lower the bar. Linux on the desktop's largely been a non-starter for me due to Apple's ARM stuff and disinterest in spending the effort to find compatible hardware.
I've not used Apple for photo stuff past monkeying around with Aperture. However I recently tried digikam, darktable, and rawtherapee. Darktable in particular was atrocious, and if that's how Gtk apps are on Linux I'd consider that another strike against desktop Linux. All three crashed or hanged repeatedly. You could rather easily dismiss some things like keyboard shortcuts not being aligned (rawtherapee) or partially aligned (darktable) with MacOS norms. Even the lack of app signing (darktable, digikam) and mix of cocoa and gtk widgets could be attributed to big bad Apple.
But once you dig into them it's a rogues gallery. Darktable has two different modules for setting the white balance (ugh). Countless issues have been opened (and then closed) over this on github. The docs explain when each one comes into play. With the default settings if you believe the docs and change the module that's supposed to be active, you'll get an error. Widgets respond to mouse events even if you think the cursor isn't over the widget. Rawtherapee, for some reason, renders the metadata widget as blurry mess to the point of the text being illegible.
To me it feels like open source projects sneer at ease of use (especially after looking at how bug reports are dealt with) vs commercial software companies willingness to fund a UX team.
That doesn't sound too complicated? There's two things here being conflated, the view and the data.
You can show the current state when not in focus and show the edit state when in focus.
Or view it from the angle of the input. Show the current state or edited, but the input device could be smart enough to auto-fill a field if you click off and click back onto it within a short time period.
I don't know if it's a Windows/Mac thing, click/touch thing, or Apple vs others thing. I do notice that on Chrome/Firefox/Edge on Windows, when you click away from address bar after modifying the URL, it does not revert the value. Actually same on Android.
org chart has been shipped (excel labor cost model actually)
Sir, this is Ikea.
this is the way
Came here to say this, thank you.
Seems like a multimodal LLM unit test could do the sanding.
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.
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.
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)