Sanding UI(blog.jim-nielsen.com) |
Sanding UI(blog.jim-nielsen.com) |
Just recently have done quite naturally the same thing... Expand the clickable surface area of a region
Bootstrap changing this in v4 is no excuse to not do it.
For anyone seriously interested in how to get a great finishing with sanding here’s the guide I follow:
https://www.blacktailstudio.com/blog/how-to-sand-wood-proper...
I use a planer a lot but I'm still struggling with making multiple passes down a wide piece of wood. I often end up with grooves. I've gotten better over time but I'm still not happy with the results.
https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
A better way would be to compare the size of Stack Exchange boards at https://stackexchange.com/sites . It's not perfect but it's as good as it can get. Stack Overflow has 26 million users. Woodworking has 17 thousand. A fraction.
Further still, not every woodworker will use a belt sander. It's used for a specific purpose (large flat surfaces) and it's not a beginner's tool. So the fraction gets smaller. I'd say the assumption stands.
But the tech market is centered in cities where owing a garage with tools in your 20s isn't possible.
This tends to produce experiences that are very smooth for a large group of people but fail really badly for anyone who is slightly different. Most Apple stuff feels like this to me, for example. It's like carving a polished stone path where any direction you step off the path is raw and jagged.
On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song.
When you consider the scale of these apps, there must be so much combined annoyance.
If you miss them by even a slight amount, the view does this annoying animation which hides the frunk and trunk butttons for about a second. You have to wait for the animation to stop before trying again.
So damn annoying.
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.
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.
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.
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.
Otherwise you could try and get access to a CNC or a large industrial belt sander
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.
<label>
<input ... />
<span>Some text...</span>
</label>
You do want an inner <span> if you want to stylize the input control as an inline-block depending on your needs. For general use, with the native controls, the inner span isn't necessary, I still prefer it by convention.
Actually, I think this is the best way to deal with all inputs that have labels—a small number of issues and edge cases (such as the one described in the article) just disappear. It’s also valid hierarchy-wise.
label:has(input:checked) { background-color: orange; }
<radio>foobar</radio>
<radio mark=end>foobar</radio>
But they split it, and now people without clear understanding how ui should work do it wrong by design and invent Monte Carlo methods to check if it works.
And it seems some crappy screenreaders don’t even recognize the proper form of it, adding salt to the cut.
- If you think you've found all the bugs, look again.
- If you think you've just fixed a bug, test again.
- If you think your program is done, you're wrong.Finding the point where your software is so round or complete that you can call it done is somewhat of an art. You can undoubtedly add stuff beyond that point, but I won't improve the software in the long term.
It's perfectly fine if you make the conscious choice to not make those fixes or improvements, usually for time/budget reasons, but the point is that you should be aware of those possibilities, and that those are the points to revisit if and when you have the resources to do so.
I've coined the term Bonsai Software here before, but I do like the sanding analogy. In the last week I've spent way more leisure time than could be considered sensible writing some user-interface code for the Amiga, in order to make defining the UI in future projects as simple and elegant as possible!
I've come across the reverse scenario quite a few times, where the label isn't clickable, but this variant was new to me.
It seemed a pretty big deal to me, specially because I always clicked on the gap, and got frustrated and angry at this. So I reported it to the UX team managing the design system, and to the developers implementing the design system, and nobody really cared. Some people even tried to convince me this behaviour was OK (because other design systems worked that way too, or because they were planning to refactor this on the far future so they didn't want to spend time on this).
I think the industry is now filled with people that just don't care, specially on big companies where, if it's not in a ticket, and if the ticket is not prioritized as critical, nobody cares. All they care about are metrics (test coverage, line count of a function, whatever). Pretty sad actually.
I once spent hours debugging this before I realized what was happening, my confusion coming from the fact that with the inspector open that wasn't the case (As there the scrollbar was always visible...).
Every browser with non-floating scrollbars will do this, right?
Safari, in its default configuration on a touch-ish device (macbook without a scrollwheel mouse, iOS) don't show explicit scroll bar gutters IIRC, and so won't have this problem.
Can also lead to an ugly gap in your navbar depending on which container you're making scroll.
I’d take this with a grain of salt (pun intended). There’s a lot of bugs that you cannot reproduce without certain permissions or a particular environment. Let alone the race conditions or user setup. In my experience, most bugs would not have been uncovered using this brute force approach. A few tests using your understanding of the code and critical thinking goes a lot further in my opinion.
Drawing a box around the radio buttons is perhaps not modern but it may make the form more usable.
The title or description of the element should not be the same as the options.
The 4 times might belong in two or more groups. This is something to dwell on, make a few mockups then most likely it shouldn't be used. If it doesn't jump out as amazingly useful restore normality.
consider lining up the time so that the :'s sit in a line. Try put the PM in a collum too. Maybe there should be AM as well.
Keep doing useless experiments until you strike gold. It should be really hard to beat default form elements (unless it is iphone)
Your truly fantastic 1000 line text input should most likely be deleted.
the example animation probably has insufficient line height. The user shouldn't have to aim that much.
Totally paid off.
Working on another app now. Sweating the details on the 'watercourse way.' That first experience is critical.
There is a high chance of overshooting the optimal design, and then you have to reverse direction.
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...
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.
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.
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.
But I think asking for a UI toolkit/framework is more helpful. Otherwise, you optimize for straightforward use cases, like entering a search box.
Stripe is also quite excellent but not entirely bug free. I think they have a bit more surface area though.
I'd look to study lots of internal tools that don't get marketed or outside influences. That would be interesting to find out. Where's the crossover from just enough resources to make it exist and enough resources to leave it as "finished"
To me: Sense of hierarchy is off, accessibility is meh, there's an enormity of information per page, there's poor use of color and spacing... it could be worse but I can imagine this site giving my designer friends a seizure.
<label>
Foo
<input>
</label>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.]
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.
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.
It’s good to know those tests cases to start, but random testing quickly outpaces planned testing when trying to find small issues. Also planned testing is often happy path or expected errors. Sanding like this finds edge bugs much faster.
I hope all of them. :-)
It’s kind of a QA tactic in a sense
I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.
However, not every developer will craft a great UI just given time, I've seen some truly inspired monstrosities.
I also usually spent a few minutes in each UI page doing a test I called “spaz clicking” which, just like it sounds, consisted of just randomly clicking as fast as I could and moving the mouse around. Surprising how many bugs you’d find that way.
I guess this is true if you're doing something in a not so saturated field, but understand that if you're in a saturated space, you probably do need the design to be natural os as to set yourself apart.
I see many developers get caught up in rituals, and polishing (and monkey testing for that matter) seem to go against a reproducible approach, and are therefore frowned upon and even ignored. Still, it is a much more powerful technique to get something both working and user friendly.
Investing in developers to spot that something is 3 pixels off, or the basic idea that different users have different tastes, can be very productive.
Unless you’re talking about the clicking dead zone, which I would argue is more a problem with not using the right cursor than the dead zone the gap introduces.
Spaces, yes.
It’s where much of the beauty and craft of something is developed. It requires a craftsperson to not just “call it done and move on”, but instead to be intrinsically motivated to spend time with the creation intimately, rolling it around in your hands/brain. Guiding a vine here and there, plucking a leaf or two… until it ‘feels’ right.
If you sort videos by popularity there's a lot I enjoyed where she does a "UX roast" of SaaS or streaming websites
TestFlight records how many sessions I run, on the release-ready app. I use TestFlight from very early on.
It always shows thousands of sessions for me. The next-highest tester is often only tens or hundreds.
But that number is dwarfed by how many sessions I run in the simulator.
It tends to result in apps that folks like using.
The biggest danger is that I get so familiar with the UI, that I don't understand its [lack of] discoverability for those unfamiliar with it. I can easily design inscrutable UI.
However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.
input:focus + label {}
label:has(input:focus) {}I guess it is kinda beside the point though as it was just an example to illustrate the point.
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.
Makes no sense right? Weirdos, all of them!
That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has, especially when you see them disparage UI development as something unworthy of their time / expertise.
Or maybe it's our collective frustration with processes and expectations that make it very difficult to be a craftsman--and that make web app UI bad in general.
I remember my boss being frustrated with how long it was taking me to build a set of filtering dropdown components from scratch (one of the most difficult to get right). I stuck with it and put in some extra hours to really get all the small details right. Later that year, he asked me to tech-lead a newly forming team of UI engineers.
A year later, everyone called it great work and no one remembered how long it took.
Having well sanded features doesn’t necessarily remove bugs directly drive conversion, but it gives the entire product an established professional “feel.
Even though your customers feel it, they won’t explicitly articulate it
I mean, it is probably very rare to have two products that have the same features, and the only difference is how nicely done they are. For example, MediaWiki is in my opinion 100x better than Confluence, but Confluence has some extra features that I don't care about but managers do (stuff like easily attaching PowerPoint presentations to web pages), so the managers decide that the company uses Confluence. And I keep silently screaming in frustration every time I lose a part of text during editing, or the links break when a typo in a page name is fixed (because there is no option to add a redirect), etc.
The extra feature often wins, when the salesman describes the product to the manager who makes the buying decision. That's why we have the "checkbox features" that most end users don't care about, but it allows the product to seem better in comparison. Feature creep is how stuff gets sold.
The situation of two featurewise identical products competing only on better UI would probably be highly unstable, even if it happened somehow. There are network effects, so if one product starts winning, most people will switch to that product because "that's what everyone else is using". The other product will be left without money to pay for development, and will go out of business. Afterwards, the winning product does not have to care about their UI anymore.
If it's not, it will lead to your users being confused and/or frustrated which will lead to them looking for an alternative tool.
If you're product is the only one in town, then they're just left to deal with it until a competitor pops up with a better (whether real or perceived) UI.
Wouldn't they be the same? If i perceive some ui as awful, it's real(ly awful). A program I've used since the 80s has progressively been 'flattened' and is now a complete pain to use - to such an extent I often prefer to fire up ye olde atari emulator. To me - the pain is real, and perceived.
Oh my god, just look at Facebook's comment system. It's a fucking mess and it's based on their fancy React steposhi soft.
Mind boggling that even their own engineers can't create a usable UI. Well, they are too big to care.
The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue.
This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
> on mobile it might lead to miss-clicks while trying to scroll past the <label>s
You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit
...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit
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.
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've brought up it here just because parent comment stated what perhaps majority of developers believe:
> [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'.
As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.
https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
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.
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
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.
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.
> 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.
Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.
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.
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.
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.
Maybe not for the screenreaders of today, but maybe for the screenreaders of tomorrow.
I do my best to fix all open bugs in my own software, tho.
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'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.
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.
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.
> 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.
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") %>
<label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label>
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.
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'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.
If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.
(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.)
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.
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.
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.
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.
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.
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.
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.
> 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?
> 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
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.
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.
[1] https://www.freedomscientific.com/products/software/jaws/
[2] https://webaim.org/blog/jaws-license-not-developer-friendly/
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.
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.
https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...
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.
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.
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 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.
Maybe the business just doesn’t value shipping good software all that much - plenty don’t.
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!
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?
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.
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.
All I can say is if this is the common denominator...
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.
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.
How is padding different? It's kind of in the definition of padding. Background colors and click regions are expected to fill the padding but not margins. It's the standard CSS box model.
I was responding to you raising technical questions about how could gap work in some edge cases by saying: "same as padding".
If "gap" is always used like padding, why wouldn't it behave the same?
FTR, I am not sure it's used like that commonly (I've stopped doing CSS UIs before the flexbox came to be): I am not putting that out as a conditional by accident.
Ah.. yeah, that's a big loaded "if". I would say it's not. It's usually used as a gap, like the name implies. Gap and padding play nicely together too, so, if you want both, use both.
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.