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.
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.
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 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 "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 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.
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.
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.
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
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.
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"
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.
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.
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.
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.
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.
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.
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.
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 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.
"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.
> 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.
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 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 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
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.
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.
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.
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.)
Process gets dictated from above. Laborers like coders do not get the authority to do that stuff.
Agile is a failure because it imagines this pixie dreamland where every replaceable cog in the machine somehow has the ability to dramatically change how the machine operates. We don't. We don't get to design the machine we are a part of because that's not how capitalism works.
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.
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.
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.
> 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.
> [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.
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.
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.
Is not UI programming, it’s designing UIs on top of HTML and CSS. There’s way too many degrees of freedom, while basic things like forms should work well by default.
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).
There were some pretty good platforms in the past where the details were sweated for you by default. But with the web platform—while tolerable for docs—is at the wrong level of abstraction for apps. And so web UI is reinvented every year with new leaky ones.
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.
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 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.
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.
Readit News
I suspect this is why small teams with strong ownership can be so effective. If you feel ownership of a thing then you feel users' pain when they hit these little paper cuts, and it becomes a point of personal pride to fix these things and make the UX as smooth as possible.
You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ.
Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes.
Compare this to big box stores like “Home Depot”, “Lowe’s”. I can spend 10-15 minutes just trying to find the right size of screw, board, or whatever using their bloated sites. On mobile it’s even worse.
Guess they really live up to their promise
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
No one's sanding anything there.
https://littlebigdetails.com is exactly that
Windows 2000. Everything newer has been slowly downhill.
CSS is too powerful, OOB HTML is too basic/ugly.
There is no point in sanding something that someone else is using hammer and chisel on. FAANGS are the companies of continuously delivered websites, self-updating evergreen software, churners of framework-du-jour that are deprecated sooner than you can say "FAANG". Even if took the time to sand something, it would be replaced by something else the following day.
Yes, frontend moves quickly and there is a new framework every day. No, most products teams at FANGs are not rewriting frontends in a new framework every year.
I find the aesthetics of free to play games very stressful and unsatisfying (lots of notifications and popular to distract you), but they ARE effective at getting me to click into menus to make those nuisances go away
premium iOS apps. Procreate {,Dreams}, Photomator, Overcast, Crouton, Mela, Carrot Weather, Apollo.
Dead Comment
But I think asking for a UI toolkit/framework is more helpful. Otherwise, you optimize for straightforward use cases, like entering a search box.
Stripe is also quite excellent but not entirely bug free. I think they have a bit more surface area though.
I'd look to study lots of internal tools that don't get marketed or outside influences. That would be interesting to find out. Where's the crossover from just enough resources to make it exist and enough resources to leave it as "finished"
Deleted Comment
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.
Deleted Comment
Deleted Comment
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
I guess it is kinda beside the point though as it was just an example to illustrate the point.
Dead Comment
Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed.
The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it.
[In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.]
This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer.
That prioritization can be inserted into any development methodology if you want it.
Agile is irrelevant here.
It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output.
Management is likely out of touch with the demands of creating a high quality product. This leads to misalignment with the development team and probably the business needs. Most businesses need a higher quality product than they have. Some don't, though. In those circumstances it doesn't really matter - I recommend avoiding these places like the plague.
Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? It is how it is used, not what it was used for.
When working on my own apps it's really obvious that non focused time leads to lots of improvements. Instead of only the business wishes. In that regard it seems that the potential of a dev is a bit diminished when you don't have time to do things according to your own priorities.
Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
No we don't.
I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
Man, Discord does have a "posts" feature that works similar like a forum. If you draft a text there, the HOME/END keys are all messed up and you can't select text with shift, or move by word holding CTRL (I don't remember the specifics at the moment).
I have reported that a couple of times over the past 3 years, because that makes the drafting text *extremely* difficult and frustrating.
As a web dev myself, I wonder how this even broke in the first place. Meaning, I wonder what kind of incompetency is needed to break something, that works out of the box. Anyhow, this should be a fix that cannot possibly take longer than 30 minutes to fix and would immediately make the user experience 1000 times better for everyone. Yet, the bug is still there 3 years after reporting it.
I also reported a bug in Teams, where you cannot use the HOME/END keys in the phone number input, to Microsoft, through Premiere Support. The reply was: This works as designed.
I am not surprised that customers don't report these kind of bugs any longer, because neither the employees/developers, nor the company doesn't give a shit anyway.
From the business point of view, why would they spend time and money on fixing these things unless it's hurting sales or brand? Long term it likely does affect the brand but most people will have moved role/company in 5 years so don't care.
I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”.
That’s if you get a response at all.
L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something.
We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly).
Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all.
You can probably guess how user-friendly that software was, and how much the users liked it.
If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step.
For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done.
One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout.
The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation.
The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.
In some rare cases there's a direct feedback button in the product itself. Then usually you don't get the response, but at least your remarks are read by someone. Or at least that's the impression I get.
As a positive example - check out the new commit view page in GitHub which they are currently rolling out. There's a Feedback button which goes to a *public* discussion page with voting and comments. One can tell they are really into listening the feedback. And that's something. At least one of the miracles for free.
You obviously have a process that does not serve your customers' needs: work with your team to fix it.
If you have SCRUM ceremonies, a retrospective is where you can raise it, but really, any time works (retrospectives are to purposely look at the past few weeks, but things you notice along the way, look to solve along the way).
I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software.
At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, certainly for the past 17 or 18 years, mostly some flavour of agile that most closely aligned with Scrum. It's not been that great anywhere, and there are a handful of places it's been outright terrible.
Reality check: if agile never gets any better than "not that great" then maybe agile is the problem.
There's different kinds of software. The software I work on now, the advertisers are the real customers, not the users of the app. So the users have basically zero buying power unless they stop using the app and we need to attract them back, but a small bug like this isn't going to do that.
The other kind of app you sell to a company. They want a good app that meets their business needs, but the ones making purchasing decisions still aren't the Frontline staff that have to use it. And there's no way a bug like this is making it up their internal chain and then over to the vendor.
And even if all of that happens, I have trouble believing this would be prioritized in a sprint. The only way anything gets fixed is if by some miracle an eng with the power to fix it either notices himself or if the app is popular enough, someone tweets about it and he happens to read it. It'll never make it through the formal chain.
I know this because as an eng who would rather do some sanding then add more useless features... Well, then the PMs wouldn't have anything to do.
It’s saying that the people behind the agile alliance and so on aren’t actually working in software engineering. Many haven’t since 20 years before the birth of Python. They’re also famous for handling any form of criticism with “you didn’t understand our principles”. Which to be fair is often completely correct, but maybe it’s because those principles are horrendous?
What it has lead to is an industry full of pseudo-jobbers. As others point out… your software engineers, can, do the work if you let them. Even if you don’t, you have no guarantee that your added personal actually catches errors like the ones in this article. Because human testers usually aren’t part of the team in any meaningful way.
(I understand that this goes completely against the textbook idea of scrum, but there is always the textbook and "the way we do scrum at our company", and those two often have very little in common.)
Agile is a failure because it imagines this pixie dreamland where every replaceable cog in the machine somehow has the ability to dramatically change how the machine operates. We don't. We don't get to design the machine we are a part of because that's not how capitalism works.
My personal experience is that you have to blame the people and not the method.
I would define my current project as very agile in the sense that we only have details plan for what to do a week ahead at the time. Each week the team has an hour long meeting where we present what we have done, and discuss if it's good enough. If something like a hover region is found to be wrong it will get fixed for next week. If you find this issue while working on something else, you make task and PR and just fix these smalls things. I feel like this way of working is what what meant by the people who invented the idea of making software development agile.
It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.
it'll be a low priority ticket with a very large tshirt size because the product manager doesn't want it done and the newbie who estimated it doesn't know what's going on, so it'll take a very long time to figure out.
Companies don’t want Software Artisans.
Agree wholeheartedly. Back & forth emails, screenshots, Q&A (what version are you on?), etc. The number of times I make it to checkout on the last step and something breaks on a certain version of a browser
Writing CSS for every checkbox makes no sense in Agile.
Deleted Comment
To the author I will add that that radio button is not following the convension of a dot for the selected state instead of a check. Users may think at first sight that multiple/no selection is possible.
I’d say that desktop is an order of magnitude better, but a kde installation I have to work with also doesn’t register clicks on buttons sometimes. Because for the sake of ui-ness they used flat elements instead of buttons and forgot making them down-upable anywhere within to click. So when you move-quick-and-click it registers (I guess) drag instead due to the movement, and drag is a no-op.
Allowing clueless developers to use lower level and normalizing lower level graphics is a huge mistake these platforms make. The web is basically built with this in mind, that’s why it sucks.
20 years ago you couldn’t even imagine clicking around in a desktop app to see if radio works. People would literally laugh at you.
1. https://garden.bradwoods.io/notes/design/juice
Deleted Comment
Is UI construction inherently that complex, or have we just not found the right programming model yet? Is it unreasonable to wish that sometimes things would just look and work the way I intended on the first try?
You can see the same in other areas. E.g. if there’s no easy way to send a request or parametrize to a query, people will invent all sorts of half assed ways to do that, even if mindful about it, due to natural pressures.
Web platform is absolutely bleeding edge graphics, but actually dogshit ui. And no one has nerve to admit it and make a change because people believe in the first part and then legacy and complexity of browsers prohibit it. And when you do it as a lib, it’s not “standard”, so nobody cares.
Or have a highlighted button but the enter key doesn't activate it.
Or there are three different menus all behind a different symbol (ellipsis, hamburger, kebab).
There is a lot of variance in quality. Those of you who polish your UI: you are appreciated. Truly.
> Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work.
Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company.
[1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
But not for keeping the input outside of the label.
This is not a problem for radio buttons, but I suspect a few people have been bitten by this and do it "just to make sure". In the same way, adding a semi-colon at the end of a line of JavaScript is rarely useful but people put them everywhere because they don't know when it's needed exactly (granted that one is a bit tricker to remember).
Put the label around the input, then put a span for the text if you want some styling for the text. You can even make the label display:flex and handle the positioning of the text that way.