I think the article has good sentiments about it. Actually using your application a lot helps polish it down a ton.
However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.
label>input instead of label+input. This is called an implicit label - time was, there were concerns about screen readers that couldn't interpret them.
Parent link says NVDA, VoiceOver, and JAWS all support the implicit way. That’s the industry standard suite to support, they’re all free and available across all platforms.
If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.
Yes, all the screen readers handle implicit labels just fine. As the a11ysupport.io tests show, it's Voice Control software that fails, not just Dragon NaturallySpeaking but also the built-in Voice Control in macOS.
I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.
They must have fixed it in Safari 18. I'm running macOS 14.6.1 and at the beginning of the month it didn't work but I also just tried it and now it does.
That’s what I generally do as well, but sometimes I don’t like how it leads to empty space that is part of the clickable area. This will happen if you have a label tag with the label text above the input (and the label text is much narrower than the input widget). This isn’t a huge problem, but it always bugs me.
> However, wouldn't putting the input inside of the label (before the label text) be a better solution
The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue.
This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
Well with the CSS in the post they would end up as wide as their parent. If you made it an inline flex box then yes, that wouldn’t be an issue.
> You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.
This is my strategy in bug bashes, and it generates way more tickets than anyone who has a multidimensional Cartesian matrix of test case combinations.
It’s good to know those tests cases to start, but random testing quickly outpaces planned testing when trying to find small issues. Also planned testing is often happy path or expected errors. Sanding like this finds edge bugs much faster.
From time to time, especially when too tired to work on a full feature, I do some random click here and there, and try stuff I usually don't in my game. I always discover some issues or little improvements than can be made. A lot would indeed not come up using planned testing.
Something for the sanding list: Navigating between https://blog.jim-nielsen.com/about/ and https://blog.jim-nielsen.com makes the layout shift a bit in Safari on macOS. The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space.
I once spent hours debugging this before I realized what was happening, my confusion coming from the fact that with the inspector open that wasn't the case (As there the scrollbar was always visible...).
Not everything committed to WebKit ships in Safari.
But the status changed to resolved/fixed only a month ago and it's in the latest Safari Technology Preview so maybe scrollbar-gutter will ship this year.
> The reason is that Safari only shows the scrollbar when it's needed but without "reserving" the space.
Every browser with non-floating scrollbars will do this, right?
Safari, in its default configuration on a touch-ish device (macbook without a scrollwheel mouse, iOS) don't show explicit scroll bar gutters IIRC, and so won't have this problem.
On Safari (iPad), type something in the search bar. If you accidentally click outside of your keyboard it will deselect the bar and delete everything you typed.
On Spotify the three little dots to do some action to a song have too small of a hitbox. Press even the slightest bit under the button and it will start playing the song. You'd never click there to play the song.
When you consider the scale of these apps, there must be so much combined annoyance.
UI/UX standards in general are dogshit in most modern software. It's actually baffling how nobody bothers to do even the most basic polishing of their application as the OP. Like they note, clicking around for 10 or 20 minutes would reveal many imperfections, not to mention actually having testers and experiments and any semblance of a scientific design methodology.
The lack of care from the product managers filters down through engineering. Product managers only care if a feature is shipped, not it it is polished. More shit shipping means more personal gain.
The problem is real the customer isn't the business that buys the software, it's the end user that is frustrated and tired of the shitty UI but is powerless to effect any kind of change because their management chain and execs don't give a fuck either.
I believe that the iPad behavior you describe is intentional. I’m not sure I’m right here, and there are tradeoffs. I get frustrated with it too. But I think Apple is going for clarity, lack of ambiguity.
If your text remained in place but the control were not focused, what would that control then indicate? In Safari now it _always_ indicates (a) the current page, or (b) your current typing. To do otherwise would be to create a third state: “Used to be typing.” Then it would no longer unambiguously indicate the current state.
This is only tangentially related, but the Safari address bar already does not always indicate the current state, specifically when pages take time loading and when going back and forth in history. There is some kind of broken synchronization between page display and address bar, in conjunction with page loading timeouts.
That being said, I would be fine with an "address bar has been edited but not commited yet" state. It's how most other (desktop?) browsers work and it's not an issue.
I've never understood the claim that Apple's UIs are better than others'. That wasn't true while Jobs was around, and it isn't true now. Apple Photos, for example, loses keystrokes every time I create a new album. That's been true for years. And Time Machine randomly drops files from backups. Linux isn't perfect, but my daily experience using it has been far superior for years.
Time Machine's "Floating Time Tunnel" user interface for browsing backups and restoring files is such a useless pretentious piece of shit. I DO NOT CARE for it taking over the entire screen with its idiotic animation, that prevents me from browsing current Finder folders at the same time or DOING ANYTHING ELSE like looking at a list of files I want to retrieve on the same screen.
It even sadistically blacks out every other connected display, and disables Alt-Tab, as if it was so fucking important that it had to lock you out of the rest of your system while you use it.
You can't just quickly Alt-Tab to flip back to another app to check something before deciding which file to restore and then Alt-Tab back to where you were. No, that would be too easy, and you'd miss out on all that great full screen animation. It not only takes a long time to start up and play its opening animations, but when you cancel it, it SLOWLY animates and cross fades back to the starting place, so you LOSE the time and location context that you laboriously browsed to, and then you have to take even more time and effort to get back to where you just were.
It was designed by a bunch of newly graduated Trump University graphics designers on cocaine, with absolutely NO knowledge or care in the world about usability or ergonomics or usefulness, who only wanted to have something flashy and shiny to buff up their portfolios and blog about, and now we're all STUCK with it, at our peril.
Crucial system utilities should not be designed to look and operate like video games, and turn a powerful mutitasking Unix operating system interface into a single tasking Playstation game interface. ESPECIALLY not backup utilities. There is absolutely no reason it needs to take over the entire screen and lock out all other programs, and have such a ridiculously gimmicky and useless user interface.
Whatever the fuck is wrong with Apple has been very very wrong since the inception of Time Machine and is STILL very wrong. How can you "Think Different" if you're not bothering to think at all?
>Core Animation will allow programmers to give their applications flashy, animated interfaces. Some developers think Core Animation is so important, it will usher in the biggest changes to computer interfaces since the original Mac shipped three decades ago.
>"The revolution coming with Core Animation is akin to the one that came from the original Mac in 1984," says Wil Shipley, developer of the personal media-cataloging application Delicious Library. "We're going to see a whole new world of user-interface metaphors with Core Animation."
>Shipley predicts that Core Animation will kick-start a new era of interface experimentation, and may lead to an entirely new visual language for designing desktop interfaces. The traditional desktop may become a multilayered three-dimensional environment where windows flip around or zoom in and out. Double-clicks and keystrokes could give way to mouse gestures and other forms of complex user input.
Hard disagree over here. Apple's not always been good but my experience has usually been better than the competition (at least OSX 10.4+). They've been on a downward trajectory, certainly I've whined a lot about how bad MacOS 14 is, but their main competition (Microsoft) has also been working to lower the bar. Linux on the desktop's largely been a non-starter for me due to Apple's ARM stuff and disinterest in spending the effort to find compatible hardware.
I've not used Apple for photo stuff past monkeying around with Aperture. However I recently tried digikam, darktable, and rawtherapee. Darktable in particular was atrocious, and if that's how Gtk apps are on Linux I'd consider that another strike against desktop Linux. All three crashed or hanged repeatedly. You could rather easily dismiss some things like keyboard shortcuts not being aligned (rawtherapee) or partially aligned (darktable) with MacOS norms. Even the lack of app signing (darktable, digikam) and mix of cocoa and gtk widgets could be attributed to big bad Apple.
But once you dig into them it's a rogues gallery. Darktable has two different modules for setting the white balance (ugh). Countless issues have been opened (and then closed) over this on github. The docs explain when each one comes into play. With the default settings if you believe the docs and change the module that's supposed to be active, you'll get an error. Widgets respond to mouse events even if you think the cursor isn't over the widget. Rawtherapee, for some reason, renders the metadata widget as blurry mess to the point of the text being illegible.
To me it feels like open source projects sneer at ease of use (especially after looking at how bug reports are dealt with) vs commercial software companies willingness to fund a UX team.
That doesn't sound too complicated? There's two things here being conflated, the view and the data.
You can show the current state when not in focus and show the edit state when in focus.
Or view it from the angle of the input. Show the current state or edited, but the input device could be smart enough to auto-fill a field if you click off and click back onto it within a short time period.
I don't know if it's a Windows/Mac thing, click/touch thing, or Apple vs others thing. I do notice that on Chrome/Firefox/Edge on Windows, when you click away from address bar after modifying the URL, it does not revert the value. Actually same on Android.
Reading this on Safari on my iPad, the favicon for this tab is the Youtube logo. I genuinely have no idea how this bug came about, but it's been like that for months now.
Safari is really, really bad when it comes to everything around favicons. The biggest annoyance being it doesn’t accept updates, so things like mail status favicons don’t work.
On the Tesla screen, parked view you can tap the frunk and trunk buttons to open them.
If you miss them by even a slight amount, the view does this annoying animation which hides the frunk and trunk butttons for about a second. You have to wait for the animation to stop before trying again.
OMG yes! That appeared in the somewhat recent UI revamp and I’m so tired of mashing at that button. Not only is it unavailable for what feels like more than a second, but now it’s in a different place
- If you think you've found all the bugs, look again.
- If you think you've just fixed a bug, test again.
- If you think your program is done, you're wrong.
While I agree with the first two, the third is a problem. Yes, you can always extend your program, but should you? The more code and functionality you include, the harder it becomes to maintain.
Finding the point where your software is so round or complete that you can call it done is somewhat of an art. You can undoubtedly add stuff beyond that point, but I won't improve the software in the long term.
Quite the opposite - a design (in general, not just software) isn't done until you can't take anything else away from it.
I've coined the term Bonsai Software here before, but I do like the sanding analogy. In the last week I've spent way more leisure time than could be considered sensible writing some user-interface code for the Amiga, in order to make defining the UI in future projects as simple and elegant as possible!
While I agree with you on the design term, there is this fundamental conflict: unlike other design forms, software is an additive process. With wood or stone, you can work subtractively until there is nothing left to take away, but with software, you typically start with nothing and add stuff until you have enough.
There is a high chance of overshooting the optimal design, and then you have to reverse direction.
The third one isn't meant to imply that you should keep adding needlessly, or that you should necessarily add more functionality (yes, this is how feature creep starts). It's meant to indicate that software is never truly finished: there is always something to fix or improve upon (e.g. refactor).
It's perfectly fine if you make the conscious choice to not make those fixes or improvements, usually for time/budget reasons, but the point is that you should be aware of those possibilities, and that those are the points to revisit if and when you have the resources to do so.
It's not kind of a QA tactic, this is literally the definition of QA. Specifically, this post is about ad-hoc functional testing. Kinda funny how this kind of testing used to dominate, but in the era of CI/CD, dedicated QA departments, and fancy webdriver suites, we've flipped too far the other way, and developers need to be reminded to QA their own stuff!
I think we've all learned the hard way that nothing works until it's been fixed, no exceptions... no code comes off the dome flawless.
Yes, but the important thing is the evaluation function of what happens after random actions - his intuitive expectations and things ripping his skin. A web fuzzer can click around randomly like he does, but it can't know things like "clicking here ought to have set the button" or "this is twice as slow as it should be, why". It can detect things like crashes or segfaults or JS code throwing exceptions, but not those other things.
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.
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.
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.
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
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.
At the end of the day it’s your users’ problem. Ideally their assistive tech would work, but if it doesn’t and you’ve got an easy fix then you should implement that fix.
I disagree. Of course you could fix that. But that would mean that you can fix a thousand and one issues that's caused by other softwares erroneous content handling. Which leads to nothing but bloat and introduces just more code that could come with more bugs.
If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.
Your software isn’t working, because the user cannot use it. Your UI is always a combination of whatever hardware and software come together to give an experience. Everyone chooses to marginalise certain segments of users’ technologies – I don’t support IE any more of course – but I typically won’t drop support for technologies that are vital assistive technologies for that segment of users.
(If you need a personal story to bring it home, the only way my dad, a programmer in the 70s-90s, could continue to use computers when he suffered from MND / ALS, was to use voice control software.)
You’re basically enabling for these shitty variants of voice control software to exist. Html, css and js allow dor more granularity in how ui works, but using them this way is just absurd.
shrug They exist regardless, and the users have no real other options. I’ve found in my career that devs tend to fall into the “caring about the effect” and “caring about the artefact” buckets, and I guess you’re in the second category? There’s no one right place to be – without people in the second we‘d have less effective solutions overall – but I hope your team is also balanced by people in the first.
Not sure I agree with the conclusion of that article, according to it, only 2 screen readers don't support nested labels, I couldn't find statistics on how prevalent these are, but there are a lot of alternative screen readers one could use which might support nested labels since they're not mentioned there (I've mainly heard of JAWS, which isn't mentioned there), so it doesn't seem to be an inherent limitation of assistive technology, just a bug in some (popular?) screen readers.
VoiceControl and Naturally Speaking aren’t screen readers: they’re voice command software. They’re designed for people with mobility problems, not vision problems. There’s no inherent limitation here that couldn’t be solved by bug fixes, but they’re the two major pieces of assistive tech in that sector so can’t be dismissed without dismissing people who need that functionality.
Fair enough, so to test things out I've enabled Voice Control and tried whether it makes a difference how the elements were arranged:
At least with Chrome, it does not make a difference! It correctly determined the label and I could just tell it to click on that particular checkbox.
Since Dragon Naturally Speaking doesn't seem to have a trial, as well as having a broken shop page you can't order from, I can't give it a test, but that articles advice seems rather questionable to me.
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.
This applies to mobile apps a lot. If you're not careful (especially when using the iOS/Android simulators too much) you can create tiny awkward hit boxes for buttons that are difficult to tap with fingers
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.
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.
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.
It’s an important insight that the state space for UI is very large and that is why intuition is especially useful — it’s rarely feasible to account for all possibilities analytically. This is true to some extent in all areas of software development, but I think for UI dev moreso than most.
This attention to detail is what separates the mediocre frontend devs from the rest. How the heck do I improve our hiring process so we get more of you!!!
Do you already have candidates actually write frontend code? Either async or during an interview, or both? I'm a big fan of being on either end of an interview where I'm actually working on a functioning project.
I've been "sanding" my personal website (https://dustinbrett.com) for nearly 4 years now, and it feels like it could go on forever. Luckily I enjoy working on it.
I really appreciate this. Most of the time when I see a "desktop OS on webpage" it feels half-assed and honestly overplayed. This on the other hand is super tight and polished!
This is cool and very polished, but my advice (which may not resonate with you) is that you should channel this attitude into some user-facing app instead of letting it basically go to waste on a personal website most people won't see or won't use for more than a second or two.
I definitely didn't necessarily mean an app that had a way to make money. I mean exposing the work to more people who would get fun or utility out of the painstaking effort put into it. The world could use this sort of taste in a game, an activity, a tool, etc.
Yes, but you can make free apps for a wider audience. Or even just useful apps for yourself.
Can do what pleases you though. I sometimes work on intentionally useless apps just to try things out, but the idea is always to carry those ideas over to some app that has some purpose.
With no abstract artists, art museums will have bare walls (which is fine, if the wall is the one they gave to me... but nobody wants to look at a bare wall and pretend its art for a whole museum!)
Marketting seems useless sometimes, but when Pepsi spent their marketting budget on community projects, they lost a ton of sales. My local ice rink has no marketting and nobody in the county knows it exists, even people who would like to do ice skating or ice hockey; a smidge of marketting would be super useful; other rinks in neighboring counties have doubled or more the number of kids playing hockey in the past few years since we got a local NHL team, but ours struggles to get a single full team at most age groups.
Landlords are not well liked on HN, but seems to me having a place to live on a month to month basis was pretty handy before I had the ability to make a long term commitment to a single place. I know some people buy a place to live for college, but an off campus rental seemed a lot more sensible to me. And similar when moving for work if you're not sure you'll be there long term, or you want out of a hotel before you're sure of what neighborhoods you like.
I personally don't care much for abstract art, but if your goal is to produce an art piece, then sure, that's a purpose. I don't know if OP was going for "art" or just having fun with the tech. I wouldn't count it as art because it's very much a copy of an existing piece of software, not an original piece.
> Others were made for study at art academies in the late nineteenth century and later, while the statue has also been replicated for various commercial reasons or as artistic statements in their own right. Smaller replicas are often considered kitsch.[2]
There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying to make, because I wouldn't generally describe carbon copies as art. It's a copy of art, but not really artistic in itself.
I don't have a downvote button. And I'm not gatekeeping. I don't care what people do. Art is subjective, and carbon-copying is not within my definition or appreciation of art. If you think that's art, great, you do you.
This is really fun. A usability note, at least on Safari on iOS, you have to put the protocol for a web page to load. If you just put www.cnn.com without the https, it never loads.
A broken pattern I see constantly related to author’s example is large buttons where only the button label - and not the rest of the button - is clickable.
This is totally what I’ve been doing all day. I call it “digital puttering”.
It’s where much of the beauty and craft of something is developed. It requires a craftsperson to not just “call it done and move on”, but instead to be intrinsically motivated to spend time with the creation intimately, rolling it around in your hands/brain. Guiding a vine here and there, plucking a leaf or two… until it ‘feels’ right.
> I generally wrap my radios inside of the label for this reason. Is there a reason not to do that?
Actually, I think this is the best way to deal with all inputs that have labels—a small number of issues and edge cases (such as the one described in the article) just disappear. It’s also valid hierarchy-wise.
You can't style the label based on input state if you do that. If you instead order them like input + label, then you can style the label with selectors like input:checked + label.
The algorithm of clicking around trying to break things heavily optimizes for workflows the designer finds natural. The more you do it, the more you reinforce your existing patterns because, you know, brains.
This tends to produce experiences that are very smooth for a large group of people but fail really badly for anyone who is slightly different. Most Apple stuff feels like this to me, for example. It's like carving a polished stone path where any direction you step off the path is raw and jagged.
413 comments
[ 2.0 ms ] story [ 359 ms ] threadHowever, 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.
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
> 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/
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.
> 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.
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 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...).
Can also lead to an ugly gap in your navbar depending on which container you're making scroll.
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...
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.
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.
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.
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 Ani...
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.
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.
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.
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.
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!
There is a high chance of overshooting the optimal design, and then you have to reverse direction.
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 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.
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
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.)
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 guess it is kinda beside the point though as it was just an example to illustrate the point.
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.
https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
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
Makes no sense right? Weirdos, all of them!
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.
There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying to make, because I wouldn't generally describe carbon copies as art. It's a copy of art, but not really artistic in itself.
I hope all of them. :-)
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.
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; }
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.