[HN Gopher] Sanding UI
___________________________________________________________________
Sanding UI
Author : roosgit
Score : 1016 points
Date : 2024-09-21 19:36 UTC (1 days ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| jamamp wrote:
| 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.
| lelandfe wrote:
| label>input instead of label+input. This is called an _implicit
| label_ - time was, there were concerns about screen readers
| that couldn 't interpret them.
|
| I don't know how bad that is in practice:
| https://a11ysupport.io/tests/html_label_element_implicit
|
| ...but it does look worse than explicit:
| https://a11ysupport.io/tests/html_label_element_explicit
| swatche wrote:
| The spec says either way
| (https://www.w3.org/TR/html401/interact/forms.html#h-17.9),
| but I agree with putting the input inside the label for the
| acessibility and avoiding the blank space issue.
| lelandfe wrote:
| The HTML spec doesn't speak much on a11y guidelines. Here's
| what the W3's WAI says https://www.w3.org/WAI/tutorials/for
| ms/labels/#associating-l...
|
| > _Whenever possible, use the label element to associate
| text with form elements explicitly_
|
| > [..]
|
| > _In some situations, form controls cannot be labeled
| explicitly... Generally, explicit labels are better
| supported by assistive technology_
|
| ...but people have been saying that for like 15 years now,
| I don 't know how big of a deal those failures are. That'd
| be a good blog post
| dumbo-octopus wrote:
| 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.
| extra88 wrote:
| 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.
| dumbo-octopus wrote:
| Voice Control also works perfectly fine, I just tested it
| myself on their provided sample. Say "select your name"
| on this page: https://a11ysupport.io/tests/html/html_labe
| l_element_implici...
| extra88 wrote:
| 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.
| acka wrote:
| JAWS isn't free[1]. Using the trial version for
| accessibility testing goes against its EULA[2].
|
| [1]
| https://www.freedomscientific.com/products/software/jaws/
|
| [2] https://webaim.org/blog/jaws-license-not-developer-
| friendly/
| dumbo-octopus wrote:
| Ah, I got it mixed with Orca. NVDA is the thing to target
| in Windows.
| chenmike wrote:
| There's no reason you can't do both, and indeed some a11y
| linters recommend doing that
| oxidant wrote:
| Put the input inside the label and still use "for" on the
| label. No way to test right now but that's what I usually do.
| tshaddox wrote:
| 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.
| philo23 wrote:
| > 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
| bastawhiz wrote:
| That's only true if you let your labels be as wide as the
| parent container.
|
| > on mobile it might lead to miss-clicks while trying to
| scroll past the <label>s
|
| You can scroll on mobile by swiping over the text of a label
| itself without activating the input; this isn't generally a
| concern.
| philo23 wrote:
| 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.
| dexwiz wrote:
| 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.
| gwervc wrote:
| 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.
| fitsumbelay wrote:
| this is the way
| jv22222 wrote:
| Came here to say this, thank you.
| dewey wrote:
| 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...).
| promiseofbeans wrote:
| There's a newish CSS feature to fix just this: scrollbar-gutter
| (https://developer.mozilla.org/en-
| US/docs/Web/CSS/scrollbar-g...). Unfortunately, Safari doesn't
| support it.
|
| Can also lead to an ugly gap in your navbar depending on which
| container you're making scroll.
| dewey wrote:
| That sounds promising, for some reason the webkit issue says
| "resolved / fixed" but I don't see any updates in the issue
| itself: https://bugs.webkit.org/show_bug.cgi?id=167335
| extra88 wrote:
| Not everything committed to WebKit ships in Safari.
|
| But the status changed to resolved/fixed only a month ago
| and it's in the latest Safari Technology Preview so maybe
| scrollbar-gutter will ship this year.
|
| https://www.webkit.org/blog/15860/release-notes-for-
| safari-t...
| madeofpalk wrote:
| > 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.
| quirino wrote:
| 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.
| dustingetz wrote:
| org chart has been shipped (excel labor cost model actually)
| andrepd wrote:
| 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.
| ibash wrote:
| I believe it boils down to what we teach as "finished".
|
| Is a feature finished when the code works? When the pull
| request is merged? Or when a feature _works well_?
|
| I also believe there's a lack of care. The difference between
| a craftsman and anyone else is _care_.
| voidfunc wrote:
| 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.
| chii wrote:
| but then why not keep going down the line, and say that
| the customers also doesnt care?
| voidfunc wrote:
| 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.
| sonofhans wrote:
| 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.
| layer8 wrote:
| 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.
| thelastparadise wrote:
| Yep it's just pure jank. Even Apple (especially post-Jobs)
| can produce jank.
| aag wrote:
| 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.
| worstspotgain wrote:
| Well the Time Machine comparison doesn't really belong in
| a laundry list, it's basically Apple's greatest
| unmitigated disaster ever.
| DonHopkins wrote:
| https://news.ycombinator.com/item?id=28355058
|
| Time Machine's "Floating Time Tunnel" user interface for
| browsing backups and restoring files is such a useless
| pretentious piece of shit. I DO NOT CARE for it taking
| over the entire screen with its idiotic animation, that
| prevents me from browsing current Finder folders at the
| same time or DOING ANYTHING ELSE like looking at a list
| of files I want to retrieve on the same screen.
|
| https://www.youtube.com/watch?v=CSwy_thSXow
|
| It even sadistically blacks out every other connected
| display, and disables Alt-Tab, as if it was so fucking
| important that it had to lock you out of the rest of your
| system while you use it.
|
| You can't just quickly Alt-Tab to flip back to another
| app to check something before deciding which file to
| restore and then Alt-Tab back to where you were. No, that
| would be too easy, and you'd miss out on all that great
| full screen animation. It not only takes a long time to
| start up and play its opening animations, but when you
| cancel it, it SLOWLY animates and cross fades back to the
| starting place, so you LOSE the time and location context
| that you laboriously browsed to, and then you have to
| take even more time and effort to get back to where you
| just were.
|
| It was designed by a bunch of newly graduated Trump
| University graphics designers on cocaine, with absolutely
| NO knowledge or care in the world about usability or
| ergonomics or usefulness, who only wanted to have
| something flashy and shiny to buff up their portfolios
| and blog about, and now we're all STUCK with it, at our
| peril.
|
| Crucial system utilities should not be designed to look
| and operate like video games, and turn a powerful
| mutitasking Unix operating system interface into a single
| tasking Playstation game interface. ESPECIALLY not backup
| utilities. There is absolutely no reason it needs to take
| over the entire screen and lock out all other programs,
| and have such a ridiculously gimmicky and useless user
| interface.
|
| Whatever the fuck is wrong with Apple has been very very
| wrong since the inception of Time Machine and is STILL
| very wrong. How can you "Think Different" if you're not
| bothering to think at all?
|
| Time Machine isn't just Apple Maps Bad...
|
| https://www.youtube.com/watch?v=tVq1wgIN62E
|
| It's QuickTime 4.0 Player Bad.
|
| http://hallofshame.gp.co.at/qtime.htm
|
| The most damning praise comes from Wired Magazine,
| 06.08.2007. Fuck Core Animation and the "Delicious
| Generation":
|
| https://www.wired.com/2007/06/core-anim/
|
| >Core Animation will allow programmers to give their
| applications flashy, animated interfaces. Some developers
| think Core Animation is so important, it will usher in
| the biggest changes to computer interfaces since the
| original Mac shipped three decades ago.
|
| >"The revolution coming with Core Animation is akin to
| the one that came from the original Mac in 1984," says
| Wil Shipley, developer of the personal media-cataloging
| application Delicious Library. "We're going to see a
| whole new world of user-interface metaphors with Core
| Animation."
|
| >Shipley predicts that Core Animation will kick-start a
| new era of interface experimentation, and may lead to an
| entirely new visual language for designing desktop
| interfaces. The traditional desktop may become a
| multilayered three-dimensional environment where windows
| flip around or zoom in and out. Double-clicks and
| keystrokes could give way to mouse gestures and other
| forms of complex user input.
|
| >The Core Animation "revolution" is already starting to
| happen. Apple's iPhone at the end of the month will see
| people using their fingers to flip through media
| libraries, and pinching their fingers together to resize
| photos.
|
| >The "Delicious generation" is a breed of young
| developers who embrace interface experimentation and
| brash marketing. The term "Delicious generation" was
| meant as an insult, but they wear it as a badge of honor.
|
| >Image: Adam BettsShipley's initial release of Delicious
| Library, with its glossy, highly refined interface, gave
| birth to a new breed of developers dubbed the "Delicious
| generation." For these Mac developers, interface
| experimentation is one of the big appeals of programming.
|
| [...]
|
| >Apple has been ignoring its own HIG for some time in
| applications like QuickTime, and is abandoning them
| completely in upcoming Leopard applications like Time
| Machine.
|
| >Functionality-wise, Time Machine is a banal program -- a
| content-version-control system that makes periodic,
| automated backups of a computer's hard drive.
|
| >But Apple's take on the age-old task of incremental
| backups features a 3-D visual browser that allows users
| to move forward and backward through time using a virtual
| "time tunnel" reminiscent of a Doctor Who title sequence.
| It's completely unlike any interface currently used in
| Mac OS X.
|
| [...]
|
| >While it seems logical to speculate that interfaces like
| those of Time Machine and Spaces will lead to the end of
| the familiar "window" framework for desktop applications
| altogether, many Mac developers predict that the most
| basic elements of the current user interface forms won't
| disappear entirely.
| inferiorhuman wrote:
| 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.
| IanCal wrote:
| 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.
| rty32 wrote:
| 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.
| yen223 wrote:
| 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.
| dmd wrote:
| 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.
| emmelaich wrote:
| On the Tesla screen, parked view you can tap the frunk and
| trunk buttons to open them.
|
| If you miss them by even a slight amount, the view does this
| annoying animation which hides the frunk and trunk butttons for
| about a second. You have to wait for the animation to stop
| before trying again.
|
| So damn annoying.
| brontitall wrote:
| 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
| ivanjermakov wrote:
| I miss this attention to detail in popular websites' UI. Often
| even clicking on the label won't update the form.
| tikkun wrote:
| Is this Jim Neilsen related to Jakob Neilsen (famous UI guy)?
| kmoser wrote:
| My beliefs in the same vein: - 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.
| arendtio wrote:
| 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.
| robinsonb5 wrote:
| 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!
| arendtio wrote:
| 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.
| kmoser wrote:
| 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.
| bbor wrote:
| It's kind of a QA tactic in a sense
|
| 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.
| Retr0id wrote:
| oof ouch I just got stabbed by a giant checkmarks-in-radio-
| buttons splinter
| someoneontenet wrote:
| Sounds like op is manually fuzz testing.
| gwern wrote:
| 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.
| jbverschoor wrote:
| Just put the input inside the label. Problem solved, no need for
| for=
| ddtaylor wrote:
| The goto tactic for this specific `<label>` problem is:
| <label> Foo <input> </label>
| brailsafe wrote:
| 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.
| 8n4vidtmkvmk wrote:
| 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.
| notduncansmith wrote:
| This was my first thought. The entire text label should toggle
| the radio or checkbox, not just the box and the padding.
| dmix wrote:
| Bootstrap moved from <label><input></label> in 4.0 to <input> +
| <label> in 5.0 for radios/checkboxes [1]. I was curious about
| why but my guess is that it adds some simplicity for theming
| when repositioning/padding either the label or input.
|
| [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
| parasti wrote:
| 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.
| abdusco wrote:
| 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
| input:focus + label {} label:has(input:focus) {}
| Ciantic wrote:
| 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.
| robin_reala wrote:
| Even with nesting you still need for/id attributes to make it
| accessible to common voice command software:
| https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
| rafram wrote:
| That's the voice control software's problem.
| robin_reala wrote:
| 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.
| 7bit wrote:
| 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.
| robin_reala wrote:
| 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.)
| wruza wrote:
| 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.
| robin_reala wrote:
| _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.
| raincole wrote:
| And unless you're google or facebook, people will not
| change their voice control software for your website.
| melchizedek6809 wrote:
| 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.
| robin_reala wrote:
| 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.
| melchizedek6809 wrote:
| 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.
| mattlondon wrote:
| I think that would not have worked with the grid CSS approach.
|
| I guess it is kinda beside the point though as it was just an
| example to illustrate the point.
| dclowd9901 wrote:
| 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.
| sdflhasjd wrote:
| 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
| AlienRobot wrote:
| You can also do <label><input> label</input>
| pentagrama wrote:
| 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.
| ix101 wrote:
| 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.
| kchr wrote:
| 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.
| wruza wrote:
| It's called a cursor grab and in the web exists as
| el.setPointerCapture().
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/set...
| wruza wrote:
| 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.
| chrisweekly wrote:
| Agreed. What "Papercuts" is on the negative side, "Juice"^1
| (recently discussed here on HN) is to the positive.
|
| 1. https://garden.bradwoods.io/notes/design/juice
| dcre wrote:
| 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.
| thex10 wrote:
| 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!!!
| tkzed49 wrote:
| 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.
| DustinBrett wrote:
| 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.
| high_priest wrote:
| Warning: Prepare for a jumpscare with authors face. Fun page
| idreyn wrote:
| this is very smooth and scratches an itch I didn't know I had
| -- to use a windowed OS on my phone
| tkzed49 wrote:
| 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!
| bschmidt1 wrote:
| Looks incredible. Snappier than real Windows tbh
| jay-barronville wrote:
| This is so fun. I love it. Well done!
| steve_adams_86 wrote:
| This is so fun to explore. You've done some great work on this!
| It's inspiring. A lot of fun to think about how you've
| implemented everything.
| darepublic wrote:
| very nice. though you cannot have > 1 nesting of
| dustinbrett.com afaict
| ustad wrote:
| On my iphone I can! Tested to 3 levels deep.
| meowface wrote:
| 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.
| fhdsgbbcaA wrote:
| It may surprise you, but some people like to program
| computers for reason other than money.
|
| Makes no sense right? Weirdos, all of them!
| meowface wrote:
| 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.
| 8n4vidtmkvmk wrote:
| 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.
| exe34 wrote:
| do you think makers of abstract art should do something
| more useful? how about people in marketing? landlords?
| toast0 wrote:
| All of those things are useful.
|
| With no abstract artists, art museums will have bare
| walls (which is fine, if the wall is the one they gave to
| me... but nobody wants to look at a bare wall and pretend
| its art for a whole museum!)
|
| Marketting seems useless sometimes, but when Pepsi spent
| their marketting budget on community projects, they lost
| a ton of sales. My local ice rink has no marketting and
| nobody in the county knows it exists, even people who
| would like to do ice skating or ice hockey; a smidge of
| marketting would be super useful; other rinks in
| neighboring counties have doubled or more the number of
| kids playing hockey in the past few years since we got a
| local NHL team, but ours struggles to get a single full
| team at most age groups.
|
| Landlords are not well liked on HN, but seems to me
| having a place to live on a month to month basis was
| pretty handy before I had the ability to make a long term
| commitment to a single place. I know some people buy a
| place to live for college, but an off campus rental
| seemed a lot more sensible to me. And similar when moving
| for work if you're not sure you'll be there long term, or
| you want out of a hotel before you're sure of what
| neighborhoods you like.
| 8n4vidtmkvmk wrote:
| 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.
| exe34 wrote:
| https://en.wikipedia.org/wiki/Replicas_of_Michelangelo%27
| s_D...
| exe34 wrote:
| I think it's perfect. Art should be completely useless and
| yet spark joy - this one does both!
| sibeliuss wrote:
| Nice man!
| fhdsgbbcaA wrote:
| Ok, be honest: how many hours put into this were during 9-5,
| and on the boss' dime?
|
| I hope all of them. :-)
| dgellow wrote:
| I wish Windows was that snappy! Incredible work, kudos!
| MaxikCZ wrote:
| Meanwhile we get a loading splash screen when opening a
| calculator.
| InvaderFizz wrote:
| 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.
| llama_drama wrote:
| Looks really cool. One thing that I found missing is that I
| can't use mouse4/mouse5 in explorer. "Sanding" really could go
| on forever.
| dmd wrote:
| 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.
| wheresmycraisin wrote:
| I prefer a well tuned smoothing plane or a card scraper,
| personally.
| socialentp wrote:
| 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.
| christophilus wrote:
| I generally wrap my radios inside of the label for this reason.
| Is there a reason not to do that?
| marcosdumay wrote:
| AFAIK, the only reason to use the label's `for` is when you
| want to place it in a different place from the widget.
| emsimot wrote:
| It also helps with accessibility, screen readers etc
| marcosdumay wrote:
| Not compared to including the widget inside the label.
| jay-barronville wrote:
| > 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.
| parasti wrote:
| 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.
| ants_everywhere wrote:
| 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.
| raminf wrote:
| Built an app when the iPhone first came out. Spent 2 months
| building the core app and another 3 months working to reduce the
| number of taps and remove road-bumps in the UI/UX flow.
|
| Totally paid off.
|
| Working on another app now. Sweating the details on the
| 'watercourse way.' That first experience is critical.
| ChrisMarshallNY wrote:
| That's pretty much what I do.
|
| TestFlight records how many sessions I run, on the release-ready
| app. I use TestFlight from very early on.
|
| It always shows _thousands_ of sessions for me. The next-highest
| tester is often only tens or hundreds.
|
| But that number is dwarfed by how many sessions I run in the
| simulator.
|
| It tends to result in apps that folks like using.
|
| The biggest danger is that I get so familiar with the UI, that I
| don't understand its [lack of] discoverability for those
| unfamiliar with it. I can easily design inscrutable UI.
| 4b11b4 wrote:
| I like this idea of sanding your UI...
|
| Just recently have done quite naturally the same thing... Expand
| the clickable surface area of a region
| 4b11b4 wrote:
| That should be a metric... % clickable. Could look at app,
| page, component levels
| xyst wrote:
| I wonder what's the most polished or "sanded" UI out there?
|
| You would think FAANG would have a half decent UI and UX with the
| amount of money they have. But anybody that has used Amazon.com
| or AWS, GCP, or even Azure would beg to differ.
|
| Personally, off the top of my head. The most polished UI/UX has
| to be "mcmaster.com". I can find anything I need in what seems
| like a couple minutes.
|
| Compare this to big box stores like "Home Depot", "Lowe's". I can
| spend 10-15 minutes just trying to find the right size of screw,
| board, or whatever using their bloated sites. On mobile it's even
| worse.
| skykooler wrote:
| My biggest issue with mcmaster's website is that it doesn't
| provide any sort of navigation hierarchy - if you go into, say,
| the "rounded head screws" subcategory, there's no option to get
| back to the general "screws" category besides the browser's
| navigation buttons.
| etrautmann wrote:
| Yep, this is indeed annoying but infrequently pointed out.
| djhn wrote:
| I don't know - I could argue that the user's browser should
| be the preferred way to navigate, duplicating it's
| functionality is redundant and adds clutter to the interface.
| It's at least a defensible position.
| edflsafoiewq wrote:
| "Back" is the not the same thing, since you didn't
| necessarily come from the "Screws" category page.
| ccakes wrote:
| imo GitHub has to be up there. I think some of the recent
| changes to search and making the code view more IDE-like are
| steps backward from a "polish" perspective, but still useful
| features
| masklinn wrote:
| Couldn't disagree more. GitHub has jank from the api to the
| ui.
| robin_reala wrote:
| GitHub specifically has the issue mentioned in this blog
| post! It annoyed me so much I had to file it with them three
| years ago, and it's still not fixed:
| https://github.com/orgs/community/discussions/7506
| geysersam wrote:
| I like the IDE "defined here/used here" features but I wish
| the page would be faster. It can be quite painful to read
| code on GitHub. The code view is also broken and unusably
| slow in some mobile browsers (Firefox) when scrolling
| horizontally
| mattlondon wrote:
| This sort of problem (speed) is a much overlooked secondary
| functionality requirement IMO.
|
| You might get amazing UX mocks and wireframes and designs
| etc from the UX team, and the mockups from Figma or
| whatever may have user-tested really well, but if there is
| huge latency in the real implementation then that is a
| usability-killer IMO, regardless of how polished the UI is.
| chrisweekly wrote:
| Agreed! Performance is the most important feature.
| donatj wrote:
| I can name multiple Facebook features that have been broken for
| months. Temporary profile pictures most annoyingly of all. They
| stopped working close to a year ago. They simply never change
| back.
|
| No one's sanding anything there.
| waterproof wrote:
| The incentive structure doesn't encourage it. Nobody gets a
| promotion for going back and fixing issues; it's all about
| new initiatives and boosting metrics with new ideas.
| qingcharles wrote:
| If you look at the HTML output of FB, IIRC it is about 100
| levels deep <divs> that cause me physical pain.
| djhn wrote:
| The thing that gets me is how _slow_ all of it is. And I've
| programmed against facebook APIs, which are ludicrously
| performant! Hundreds of megabytes of data in single digit
| milliseconds total roundtrip.
| kristiandupont wrote:
| They do this in an attempt to combat ad blockers. It's an
| arms race that is sadly bound to create cruft like this.
| egeozcan wrote:
| exactly, one example is there are a lot of
| programatically absolute positioned divs to break ad-
| blockers or make them very inefficient, while the
| performance of the app suffers from many tricks like
| these as well.
| dpkirchner wrote:
| The "feeds" screen in the app has been throwing errors for at
| least a year ("Feed isn't available right now"). I only try
| to use the screen because a while back it was the only way to
| view content in the correct order.
| blovescoffee wrote:
| mcmaster is the most polished ui/ux you know? To each their own
| but this is a very hackernews comment - it's very much a site
| for engineers but I can't agree it's a polished UI or UX.
|
| To me: Sense of hierarchy is off, accessibility is meh, there's
| an enormity of information per page, there's poor use of color
| and spacing... it could be worse but I can imagine this site
| giving my designer friends a seizure.
| tikhonj wrote:
| I've listened through some of the developer commentary on Half
| Life 2 and Half Life Alyx and the amount of user testing
| coupled with attention to detail really impressed me. The same
| can't be said for Steam though :/
| duckmysick wrote:
| Linear (of linear.app) has a highly polished UI. In fact they
| had a dedicated period for fixing just usability issues:
|
| https://linear.app/changelog/2022-12-01-polishing-season-202...
|
| https://web.archive.org/web/20231003205004/https://linear.ap...
| 8n4vidtmkvmk wrote:
| I wish they'd make more apps. I use Linear but with a team of
| 1, it's not exactly the best fit for me.
| boundlessdreamz wrote:
| Linear has the best UI/UX of all the web apps I have used.
| After Gmail and Google Maps, I don't recall any other web app
| wowing me as much as Linear.
| arendtio wrote:
| 15 years ago, one would have said google.com
|
| But I think asking for a UI toolkit/framework is more helpful.
| Otherwise, you optimize for straightforward use cases, like
| entering a search box.
| TheAceOfHearts wrote:
| FastMail has one of the best-feeling web apps I've ever used.
| It's incredibly snappy and I never encountered any bugs while
| using it. They raised the bar for what I thought a web app
| could achieve.
| yawnxyz wrote:
| recently switched all our mail to FastMail and that took 1ish
| hour... I was ready to spend a couple of days to wrestle
| switching mail providers.
|
| Guess they really live up to their promise
| dsissitka wrote:
| I think the only thing I really dislike about Fastmail's UI
| is they've hidden the "Report phishing" and "Report spam"
| links and they're in two completely different places.
| martinsnow wrote:
| That's an unfortunate decision
| RockRobotRock wrote:
| To clarify:
|
| There's a menu bar for the entire email chain, and an
| "Actions" button for each mail message. Report Spam is only
| available in the former, and Report Phishing is only
| available in the latter.
|
| I agree, it's annoying! Maybe someone at Fastmail will see
| this.
| tombh wrote:
| Yes! It doesn't make sense. It took me ages to remember
| where to go for each.
| EmilStenstrom wrote:
| Agreed. And that you can't mark a folder as read.
| Everything else is stellar.
| vishnugupta wrote:
| +1 to Fastmail. More so after I discovered their shortcut
| keys.
| corytheboyd wrote:
| Agree! Only bummer is when I want to create calendar events
| and reference email details, or vice versa. On desktop it's
| easy enough to have two tabs, but on mobile, it's a pain. I
| get why it is the way it is, but we are talking about
| exceptional UX here, and I think there is room for
| improvement.
| userbinator wrote:
| _I wonder what's the most polished or "sanded" UI out there?_
|
| Windows 2000. Everything newer has been slowly downhill.
| exe34 wrote:
| amen. and at some point Gmail was perfect, but they kept
| fixing it, so now it's getting bloated, slow and occasionally
| just does random things.
| 7bit wrote:
| Windows 3.1 was better. Windows 2000 introduced a lot of
| point and click, which just distracts from what you actually
| want to do on a computer.
| ahoka wrote:
| I would say Project Chicago was maybe one of most consistent
| UI projects ever executed. Too bad they kept reinventing
| parts of it, so now we have a mishmash of different UX
| paradigms, some better, some worse, but certainly
| inconsistent. At least it's not macOS though.
| rollcat wrote:
| I really wish we had something resembling a "native" UI
| toolkit, but for the web. Just throw together a couple
| <button>s or <input type=checkbox>es with absolutely zero
| additional JS/CSS, but have it actually look & work
| moderately decent, the way SwiftUI does.
|
| CSS is too powerful, OOB HTML is too basic/ugly.
| ansgri wrote:
| Bootstrap started as something like this, but it both
| evolved too quickly IMO, and for some reason a generic look
| on the web is considered bad (by who? marketing? designers?
| even users as they think lack of distinctive style means
| lack of developer skills?)
| cezart wrote:
| I still just throw in default bootstrap in a .container
| div when I need a fast prototype that looks decent.
| kizer wrote:
| There is SO much bloat in all the "modern" UI "culture".
| Reinventing things over and over again. Creating entire
| frameworks for tiny, simple things. And the worst part of web
| UIs is that (though there have been efforts to address this)
| there is low regularity between the experiences especially
| compared to native UI apps where you are purposely restricted
| to a set of controls which look and behave the same across
| all apps that use them.
| bosky101 wrote:
| That time of the year when everyone can see there is
| craftsmanship in the tiny details.
|
| https://littlebigdetails.com is exactly that
| peheje wrote:
| Idk. I just visited the site (McMaster) for like 2 minutes and
| found a few annoying things. I filtered for cotton (o rings).
| Nothing happens after click for 4 secs. Then it chooses
| something else to filter on. Next the animation to get the
| filtering menu is bugging out. And dragging it down triggers a
| site refresh.
| 8n4vidtmkvmk wrote:
| Linear app is quite polished.
|
| Stripe is also quite excellent but not entirely bug free. I
| think they have a bit more surface area though.
| cocoflunchy wrote:
| Probably Netflix?
| dgellow wrote:
| As something I'm using on a daily basis, Linear has one of the
| best product UI I experienced. It is extremely polished and
| snappy
| SSLy wrote:
| > _I wonder what's the most polished or "sanded" UI out there?_
|
| premium iOS apps. Procreate {,Dreams}, Photomator, Overcast,
| Crouton, Mela, Carrot Weather, Apollo.
| fuzzy2 wrote:
| Mobile games, especially those with microtransactions. They're
| highly incentivized to offer a satisfying user interface. So as
| to get more money, of course.
| parpfish wrote:
| They don't optimize for satisfying interfaces, they optimize
| for driving engagement.
|
| I find the aesthetics of free to play games very stressful
| and unsatisfying (lots of notifications and popular to
| distract you), but they ARE effective at getting me to click
| into menus to make those nuisances go away
| 2024user wrote:
| HEY! mail was great when I used it
| jmb99 wrote:
| RockAuto is my favourite website. Incredibly simple and
| utilitarian, but also quite powerful. You can easily drill down
| or search for parts, depending on what is more intuitive to
| you. Price comparison is automatic, and grouped into useful
| price/quality categories. You can see year/make/model
| compatibility for a part number once you've found it, as well
| as a brief description, at least 1 picture (usually more), and
| determine whether it will be shipped from the same warehouse as
| other parts in your cart. It does all this with 0 friction,
| from one page, blazing fast on any platform. I end up ordering
| almost all my car parts there, not because they necessarily
| sell the best parts but because it's just so easy to.
| Cannabat wrote:
| I used RockAuto for the first time recently. The site is
| super dense with info and functionality, but never once did I
| feel lost or overwhelm. Neither did I feel like anything was
| missing. Everything I needed to see and do was exactly where
| it should be. It's so rare for the screen to disappear like
| that. It's so transparent that I _almost_ can't say it's a
| joy to use (it's a joy to use!).
| Already__Taken wrote:
| The best UI is no UI. Anyone who tries to design for increased
| engagement isn't who you're looking for.
|
| I'd look to study lots of internal tools that don't get
| marketed or outside influences. That would be interesting to
| find out. Where's the crossover from just enough resources to
| make it exist and enough resources to leave it as "finished"
| dclowd9901 wrote:
| As far as app UIs go, I just started using Duolingo and their
| app seems to be tremendously well polished.
| mrighele wrote:
| > You would think FAANG would have a half decent UI and UX with
| the amount of money they have.
|
| There is no point in sanding something that someone else is
| using hammer and chisel on. FAANGS are the companies of
| continuously delivered websites, self-updating evergreen
| software, churners of framework-du-jour that are deprecated
| sooner than you can say "FAANG". Even if took the time to sand
| something, it would be replaced by something else the following
| day.
| shepherdjerred wrote:
| I have no idea where you got this idea from. Can you give
| some examples showing that switching to a new framework is a
| common at FANGs?
|
| Yes, frontend moves quickly and there is a new framework
| every day. No, most products teams at FANGs are not rewriting
| frontends in a new framework every year.
| timzaman wrote:
| Decent analogy. I wonder how many techies have ever used a belt
| sander. Or have one. I think very, very few.
| hipadev23 wrote:
| Your assumption is quite wrong.
|
| https://www.zainrizvi.io/blog/why-software-engineers-like-wo...
| duckmysick wrote:
| What does this suppose to prove? The OP said "very few" not
| none. Of course there will be a few anecdotes of overlap.
|
| A better way would be to compare the size of Stack Exchange
| boards at https://stackexchange.com/sites . It's not perfect
| but it's as good as it can get. Stack Overflow has 26 million
| users. Woodworking has 17 thousand. A fraction.
|
| Further still, not every woodworker will use a belt sander.
| It's used for a specific purpose (large flat surfaces) and
| it's not a beginner's tool. So the fraction gets smaller. I'd
| say the assumption stands.
| hipadev23 wrote:
| You and him are incorrigible. Him for the naive assumption
| and stereotype that "techies" don't do any manual trades or
| crafts, you for looking at the count of activity on stack
| fucking overflow for woodworking.
| duckmysick wrote:
| That's not the assumption I got from the OP's comment.
| What I got was - and I agree - that the intersection
| between the members of the technical field (specifically
| those responsible for apps UI) and the members of the
| woodworking field who also use an advanced, single-
| purpose tool is tiny. The assumption will be the same if
| you replace the belt sander with a guitar amplifier, a
| lawn aerator, or a pressure canner and woodworking with
| their respective hobbies.
|
| If you have better data that shows an overlap between
| those in the technical field and those that do
| woodworking with highly specialized tools, I'm all ears;
| I'm willing to be convinced otherwise.
|
| In the meantime, here's another anecdote for you - I do
| woodworking (and gardening and constructions) and I don't
| own a belt sander.
| michaelbarton wrote:
| I have not used a belt sander! I prefer to start with a planer,
| then use an orbital sander! Generally work from 60 grit up to
| 220 depending on the surface. Popping the grain and covering
| the whole surface in pencil marks in between each!
|
| For anyone seriously interested in how to get a great finishing
| with sanding here's the guide I follow:
|
| https://www.blacktailstudio.com/blog/how-to-sand-wood-proper...
| duckmysick wrote:
| Thanks for posting it! Good point about adding the right
| lighting rig, haven't thought about.
|
| I use a planer a lot but I'm still struggling with making
| multiple passes down a wide piece of wood. I often end up
| with grooves. I've gotten better over time but I'm still not
| happy with the results.
| michaelbarton wrote:
| If it's a particularly wide piece of wood you could try a
| router planning jig. I think these are used with slabs
|
| Otherwise you could try and get access to a CNC or a large
| industrial belt sander
| aetherspawn wrote:
| This is so lost in Agile.
|
| Engineers should get the time to "sand" their products, but we
| just don't. If QA doesn't make a ticket for the space between,
| it'll never get fixed.
|
| The customer probably notices this kind of a thing but it's a
| miracle if the customer bothers to report it, and another miracle
| if it eventually turns into a ticket, and another miracle if
| someone prioritises it enough to spend time fixing it.
|
| [In fact most companies have such opaque issue boards that as a
| customer I get so frustrated when I find a small issue or bug and
| have to spend like 50 hours back and forth to prove it's a bug
| and actually get a ticket put in the tracker.]
| crazygringo wrote:
| What does agile have to do with anything? You think waterfall
| explicitly provided time to test out the UI and "sand" it?
|
| This is a process that generally requires a product manager to
| choose to prioritize, together with a capable UX engineer
| and/or designer.
|
| That prioritization can be inserted into any development
| methodology if you want it.
|
| Agile is irrelevant here.
| exe34 wrote:
| I agree that it's not agile, it's the environment that led to
| agile/scrum being adopted: not that it leads to better
| products, but that it gives management more control over
| every decision of how time is spent. essentially they can
| arbitrarily reduce the time/budget you have, and hire
| standard code monkeys, etc, to get something made.
|
| I think in a company like Steve Job's Apple, where it needs
| to look perfect (within his tastes), you'd have the time to
| polish the UI even with agile/scrum - one of the acceptance
| criteria will be "I spent 5 minutes kicking it and I didn't
| get any splinters". and then later on when Steve gets a
| splinter, he'd yell at you for a bit and then create a
| ticket.
| JimDabell wrote:
| > I agree that it's not agile, it's the environment that
| led to agile/scrum being adopted: not that it leads to
| better products, but that it gives management more control
| over every decision of how time is spent. essentially they
| can arbitrarily reduce the time/budget you have, and hire
| standard code monkeys, etc, to get something made.
|
| This is the exact opposite of agile. Direct from the Agile
| Manifesto:
|
| > Build projects around motivated individuals. Give them
| the environment and support they need, and trust them to
| get the job done.
|
| > Agile processes promote sustainable development. The
| sponsors, developers, and users should be able to maintain
| a constant pace indefinitely.
|
| > The best architectures, requirements, and designs emerge
| from self-organizing teams.
| exe34 wrote:
| may I refer you to Karl Marx? Communism is perfect, it's
| just been implemented wrong.
| pixelready wrote:
| I'm not sure if you meant this to be sarcastic but I
| think you're on to something. In both cases: a rebellion
| against a soul crushing authoritarian system by writing a
| manifesto describing a decentralized utopia... which then
| gets implemented in an authoritarian context and
| undermined along the way until all that remains is the
| name and some window dressing from the manifesto.
| Orwell's Animal Farm still resonates because of this.
| Viliam1234 wrote:
| Perhaps the problem is that there are few self-organizing
| teams in companies. Managers needs to justify their
| salaries.
| 8n4vidtmkvmk wrote:
| I don't think you even need PMs and UX to be involved here.
| Let the eng get a little bored and they'll find stuff to fix.
| The way it actually works though is we set some arbitrary
| impossible deadline, rush to meet it, creating a wake of tech
| debt, launch, and then straight on to the next thing.
| mlnj wrote:
| The best way to build products I've found is to 1. hire
| passionate engineers. 2. give engineers enough room to
| breath and collaborate on the product.
|
| Every project that uses Agile defeats 2. I'm not saying
| that Agile is the reason for this but after 15 years of
| seeing this repeatedly I'm very wary of places which place
| Agile as a component of their culture.
| robocat wrote:
| An interesting critique of how Agile is practiced:
|
| https://ludic.mataroa.blog/blog/tossed-salads-and-
| scrumbled-...
| meiraleal wrote:
| > Let the eng get a little bored and they'll find stuff to
| fix.
|
| That is the opposite of all engineers I worked with.
| Engineers easily learn that they should click in the
| specific part of the element and will forget it is an issue
| and use it like that for 5 years if nobody point that the
| issue is making the UX terrible for most users.
| lol768 wrote:
| I think that says more about the engineers you've been
| working with than anything else.
| meiraleal wrote:
| sure but in some of the cases we were scaling products to
| millions of users. And it would work great but don't
| expect engineers to create good UI/UX paying attention to
| the "small" details. That won't happen naturally.
| swiftcoder wrote:
| Maybe hire some UX-focussed engineers then?
|
| I can't help thinking that the "fungible engineer"
| concept has done a lot of harm to tech hiring and team
| structure - of course if you take a guy who most is
| excited about database optimisation and put him on UI
| work he won't be passionate about it.
| Hasu wrote:
| Where deviance is normalized, sure. If that dev didn't
| have to rely on 52 "weird tricks" and half-assed hacks
| just to keep their local environment running, they might
| care more about the quality of the product. But when
| everything around you has the grime of "just do enough to
| get it barely working", that's the game.
|
| The will to have nice things is a cultural value that
| some companies just don't have, and if they don't have it
| for themselves, they won't have it for their customers.
| magicalhippo wrote:
| Even better, let the devs just watch the users use the
| product.
|
| I often join support when they have a call with a customer
| demonstrating an issue. I also sometimes get to join
| support when they're on-site for training or similar.
|
| Every time I watch users use our product, I learn so much
| about what to do and what not to do.
| xorcist wrote:
| "Waterfall" is not a development process. But plenty of the
| processes that give space for planning, also give space for
| QA. So surely agile, in the broad sense of development
| processes, is relevant to the comparison.
| ahoka wrote:
| A development process is not either Agile or "waterfall"
| anyway.
| beryilma wrote:
| By all "software engineering" books' definition, Waterfall
| is a software/development process. Good or bad...
| jurgenkesker wrote:
| Agree, we have some time in sprints to do whatever we want,
| and then you finally can fix those minor annoyances that are
| probably the users annoyance too. But in general I think more
| time should be there reserved for it. It's now once in x
| sprints.
|
| When working on my own apps it's really obvious that non
| focused time leads to lots of improvements. Instead of only
| the business wishes. In that regard it seems that the
| potential of a dev is a bit diminished when you don't have
| time to do things according to your own priorities.
| raincole wrote:
| It's just a general romanticization of how programmers work:
| if we have more time we'll fix everything.
|
| No we don't.
| ungamedplayer wrote:
| You do not speak for me. I think but can't prove that you
| don't even speak for most programmers.
| meiraleal wrote:
| He is not speaking for me but all enterprise projects I
| worked was like that. When devs (me included) run out of
| high priority tasks we ask or are directed to more high
| priority tasks, not fix the minor label/input issue, or
| the border of the disabled button in resolutions smaller
| than 400px, or whatever the PM/Scrum master didn't
| prioritize. Tired of bad management, developers just do
| what master Jira tell us to do.
|
| I do my best to fix all open bugs in my own software,
| tho.
| bravetraveler wrote:
| I think the key to your post is that waterfall or agile is
| irrelevant if you're getting work done and setting priorities
|
| Window dressing in the virtual space! Spending too much
| time/effort worrying about this nears sabotage, IMO
| noisy_boy wrote:
| Agile is relevant here because it has been adopted almost
| universally as a shovel to push more things on the
| programmer's back without much care to the quality of the
| changes being done.
|
| Sure, it is not to be blamed as per Agile manifesto but how
| many companies are adhering to the manifesto? It is how it is
| used, not what it was used for.
| beryilma wrote:
| > Sure, it is not to be blamed as per Agile manifesto but
| how many companies are adhering to the manifesto?
|
| Increasingly, I am also blaming the Agile Manifesto for
| causing the mess we are all in.
|
| Given current business tendencies, the authors should have
| probably foreseen the future consequences of their wishy-
| washy manifesto declarations. I think "true Agile has never
| been implemented" should not absolve them from assuming
| some responsibility.
| richardlblair wrote:
| Agile isn't entirely irrelevant, it's also not the main
| issue.
|
| It's a cultural one. If someone tells me they work on an
| 'Agile Development' team my immediate perception is that they
| are a culture of cargo culting and bike shedding, without
| putting a ton of thought or care into their product, process,
| or users. These systems are designed to maximize output, not
| the quality of the output.
|
| Management is likely out of touch with the demands of
| creating a high quality product. This leads to misalignment
| with the development team and probably the business needs.
| Most businesses need a higher quality product than they have.
| Some don't, though. In those circumstances it doesn't really
| matter - I recommend avoiding these places like the plague.
| Viliam1234 wrote:
| Business is trying to maximize money. It seems like quality
| has much less of an impact on sales than many of us would
| wish. I am not sure why it is like that, but as long as it
| is... it is a financially rational decision to throw
| unpolished products on the market as fast as possible.
|
| It would be easy to blame the customers. But let's look in
| the mirror -- how do I make purchase decisions as a
| customer?
|
| Actually, not a good example, because I usually don't buy
| software. OK, I buy Windows, but... I don't feel like I
| have a choice between more polished and less polished
| versions of Windows. Other than that, I use free software.
| When I use software at work, someone else made the decision
| and I had zero input. And that kind of software usually
| sucks (now I am thinking of Confluence, Jira, and other
| user-hostile monstrosities).
|
| So I guess a part of the answer is that if you sell
| software to business, there is no need to make it nice,
| because the people who decide whether the company buys it
| are not the ones who will be stuck with using it.
| __MatrixMan__ wrote:
| I wish users more aggressive about their software. At
| least once a week I hear something along the lines of:
|
| > I'm not a technology person, so I can't make X do Y
|
| It would be so much better if the go to response was:
|
| > This technology sucks, so I can't make X do Y. And if
| it can't even manage to make Y easy, then I'm sure not
| going to trust it with Z, and I'm going to tell my
| friends that they shouldn't either.
|
| If the business types need to be reminded that the
| quality problem is hurting them, then we should
| coordinate among ourselves to ensure that it hurts _even
| more_ until they notice.
| devmor wrote:
| > It seems like quality has much less of an impact on
| sales than many of us would wish.
|
| This is the unpleasant truth of the matter. As people who
| hone our craft and want to take pride in our work, a
| competent developer's ethos is at odds with maximizing
| profit.
| rebeccaskinner wrote:
| I think you are on the right track, but realistically I
| think the answer is even more cynical: the last 20 years
| in software has been all about refining business models
| that remove choice and disempower customers. Quality
| doesn't matter. Privacy doesn't matter. Price matters a
| little, but only in the sense that you need to make your
| monthly SaaS fee low enough to avoid sticker shock- you
| don't need to provide real value though. Just keep
| milking those monthly fees and make the UI a little worse
| every year or so.
|
| Lack of interoperability and vendor lock-in, the move
| toward SaaS software that you run on behalf of your
| customers, making network effects fundamental to your
| value prop, bundling, and the enterprise sales tactics
| you pointed out are all ways that quality of software has
| been removed from the conversation entirely.
| radium3d wrote:
| It's the balance between staying in business, going out of
| business, reducing employee count, increasing employee
| count, etc. Also how much unpaid overtime is the dev
| willing to put into the project. That seems to be what
| causes most of us to not be allowed to put in the required
| time for properly sanding the UI.
| osigurdson wrote:
| I legitimately question if waterfall was ever practiced
| beyond a very small niche of projects.
| necovek wrote:
| The idea behind "agile" is to recognize when something isn't
| working and improve it.
|
| You obviously have a process that does not serve your
| customers' needs: work with your team to fix it.
|
| If you have SCRUM ceremonies, a retrospective is where you can
| raise it, but really, any time works (retrospectives are to
| purposely look at the past few weeks, but things you notice
| along the way, look to solve along the way).
| 8n4vidtmkvmk wrote:
| I don't buy this. Not serving the customer's needs? Is this
| the paying customer's #1 feature request/bug fix? It's
| probably some poor random sap that has to use the software
| and notices it.
|
| There's different kinds of software. The software I work on
| now, the advertisers are the real customers, not the users of
| the app. So the users have basically zero buying power unless
| they stop using the app and we need to attract them back, but
| a small bug like this isn't going to do that.
|
| The other kind of app you sell to a company. They want a good
| app that meets their business needs, but the ones making
| purchasing decisions still aren't the Frontline staff that
| have to use it. And there's no way a bug like this is making
| it up their internal chain and then over to the vendor.
|
| And even if all of that happens, I have trouble believing
| this would be prioritized in a sprint. The only way anything
| gets fixed is if by some miracle an eng with the power to fix
| it either notices himself or if the app is popular enough,
| someone tweets about it and he happens to read it. It'll
| never make it through the formal chain.
|
| I know this because as an eng who would rather do some
| sanding then add more useless features... Well, then the PMs
| wouldn't have anything to do.
| necovek wrote:
| But that's because you care about the output vs what might
| bring value to the company.
|
| If things never bubble up, does that not mean that this is
| really a non-issue?
|
| You may be surprised, but most useful software is crappy by
| too many metrics, except for the main one: it gets the job
| done.
|
| And to be honest, on the original story, as a software
| engineer, I would rather consider if this is a better
| behavior for "gap" that most people would expect? Perhaps
| an addendum to W3C CSS flexbox spec is a more useful
| avenue? Fix it once and for everyone.
| devjab wrote:
| The idea behind agile is to sell you training and later
| consulting once your organisation fails to adopt it in any
| meaningful way because it's principles are so vague your
| culture, will, get it wrong.
|
| It's saying that the people behind the agile alliance and so
| on aren't actually working in software engineering. Many
| haven't since 20 years before the birth of Python. They're
| also famous for handling any form of criticism with "you
| didn't understand our principles". Which to be fair is often
| completely correct, but maybe it's because those principles
| are horrendous?
|
| What it has lead to is an industry full of pseudo-jobbers. As
| others point out... your software engineers, can, do the work
| if you let them. Even if you don't, you have no guarantee
| that your added personal actually catches errors like the
| ones in this article. Because human testers usually aren't
| part of the team in any meaningful way.
| bartread wrote:
| Stop drinking the koolaid, will you?
|
| I didn't get into software development to spend my entire
| time focussed on fixing broken processes. I'd bet almost none
| of us did. I got into it because I like building software
| and, more than that, I like building high quality software.
|
| At the end of the day it comes down to this: I've worked a
| bunch of different places over 25 years. I've seen a lot of
| different processes but, certainly for the past 17 or 18
| years, mostly some flavour of agile that most closely aligned
| with Scrum. It's not been that great anywhere, and there are
| a handful of places it's been outright terrible.
|
| Reality check: if agile never gets any better than "not that
| great" then maybe agile is the problem.
| mlnj wrote:
| Every single time this gets brought up we see the Agile
| defenders come up with "It's not agile, it's literally
| anything else.".
|
| All I can say is if this is the common denominator...
| rrr_oh_man wrote:
| "It's not real communism..."
| sutra_on wrote:
| I worked in companies that are committed to Agile and
| companies that have a completely custom planning and
| development process. I don't understand your argument.
| What process in Agile dictates shipping subpar UI?
|
| Build, test, file bugs, resolve bug. You can do this
| within any framework. Or, better, develop a high quality
| UI component library instead of asking a junior engineer
| to write CSS for correct checkbox handling.
| itronitron wrote:
| Particularly with Scrum, people get hung up on the
| 'rules' of the 'process'.
|
| For example, following the rules of Scrum, if a developer
| finds a bug, decides to fix it, and wants to commit the
| fix such that it can be tested and closed out then that
| bug needs to first be assigned to the current sprint
| before the developer can touch it. It's extremely
| constraining and antagonistic towards shipping good
| software.
| madeofpalk wrote:
| Fixing "agile" is not the point. Find a process (and
| iterate on it) that helps you ship good software. I think
| there's a bunch of stuff in the agile toolbox that's
| helpful. Pick and mix that works for you.
|
| Maybe the business just doesn't value shipping good
| software all that much - plenty don't.
| necovek wrote:
| This is something those wishing to build higher quality
| software often forget: business mostly care about return
| on investment.
|
| As software engineers, it's our job to find exactly the
| right balance of quality and speed, and strategies to
| increase quality with no detriment to speed, for what is
| usually asked of software engineers.
|
| Just like bridge and building engineers do not design
| those structures to stand up to 1000x the forces that
| they expect those structures will experience, software
| engineers need to learn to build with just the right
| level of complexity to quickly provide quality solution
| to a business need.
|
| And that's where software engineers really struggle, and
| agile helps keep that in check, but in practice does not
| really improve quality. Software engineers should come up
| with ways to achieve quality with limited resources (just
| like engineers do everywhere else), and the best teams I
| worked in or with have!
| necovek wrote:
| There are certainly issues with "agile", but it never
| really says much other than keep-it-lean-and-iterate: it
| really is "let engineers build software the way they think
| they should".
|
| Yes, the usual tools (JIRA, yuck!) and methodologies
| (SCRUM, SAFe...) tend to be the problem as they are too
| prescriptive and too cumbersome and verbose. But they are
| simply a set of tools to have in one's belt once you hit
| some common themes, but yes, some take them to heart.
|
| I think true agility is only achievable with a switch to
| proper outcome-oriented goals which give a lot of liberty
| to engineering teams. Otherwise, the decision makers on
| what gets built and how are too far removed from those
| doing the building.
|
| But that means a mindset shift for engineers (and everybody
| else!), in that they need to stop thinking about projects,
| and start thinking about results they achieve.
|
| I do agree that the fact that most get this wrong (I
| remember a new TL writing down a 30 page document on teams'
| "agile processes") means that something has been lost in
| translation, and "Agile" really isn't.
|
| I think it's fair to say that agile method is something to
| strive for, but never fully realise.
|
| But, what would you propose we call the type of process we
| strive for, and is there a methodology/strategy you do
| like?
|
| What are the principles of building software and building
| high quality software that worked for you in a team?
| Viliam1234 wrote:
| Fun fact: most companies doing "scrum" actually don't have
| retrospectives.
|
| (I understand that this goes completely against the textbook
| idea of scrum, but there is always the textbook and "the way
| we do scrum at our company", and those two often have very
| little in common.)
| necovek wrote:
| As long as you fix things that don't work or make you less
| effective, it does not matter if it's a retrospective, or
| stop-the-line approach, or whatever your nameless approach
| is.
|
| Basically, retrospectives are a common tool, but the goal
| is to talk about optimizing how you do something, and to
| keep doing that.
| exe34 wrote:
| > QA doesn't make a ticket for the space between, it'll never
| get fixed.
|
| it'll be a low priority ticket with a very large tshirt size
| because the product manager doesn't want it done and the newbie
| who estimated it doesn't know what's going on, so it'll take a
| very long time to figure out.
| whazor wrote:
| You can recommend adding analytics to all your flows. Then
| recommend some of these sanding tasks in order to improve
| metrics such as drop-off rate. Managers are more inclined to
| say yes when there is data involved.
| bl4ckm0r3 wrote:
| priority matters though, if you want to go full Apple with
| UI/UX then you need to lock the UI/UX for years, like Apple
| does, and refine every little thing to bring a fully ecstatic
| UX to the user. Or accept that most users won't notice that or
| wouldn't mind it behaving like that and build new features that
| will bring useful behaviours to the app (and revenue to the
| company). If you have to spend 50 hours to explain why it's a
| bug, most likely only you care about it. In some cases it may
| matter to be THAT precise with UI/UX and it's cool, not saying
| i don't appreciate quality but you can't have everything. One
| thing I'd like to point out is that most of the time it isn't
| even a matter of priority, lots of dev energy gets wasted in
| useless refactors and picking "the right library/framework" and
| building the "next outdated design library", instead of being
| used to improve things ;)
| martinsnow wrote:
| Apple does many things right but things like Mail.app got
| thrown to the side for years. There's still many odd
| utilities here and there that have not seen any love like
| grapher.
| 7bit wrote:
| > The customer probably notices this kind of a thing but it's a
| miracle if the customer bothers to report it, and another
| miracle if it eventually turns into a ticket, and another
| miracle if someone prioritises it enough to spend time fixing
| it.
|
| Man, Discord does have a "posts" feature that works similar
| like a forum. If you draft a text there, the HOME/END keys are
| all messed up and you can't select text with shift, or move by
| word holding CTRL (I don't remember the specifics at the
| moment).
|
| I have reported that a couple of times over the past 3 years,
| because that makes the drafting text *extremely* difficult and
| frustrating.
|
| As a web dev myself, I wonder how this even broke in the first
| place. Meaning, I wonder what kind of incompetency is needed to
| break something, that works out of the box. Anyhow, this should
| be a fix that cannot possibly take longer than 30 minutes to
| fix and would immediately make the user experience 1000 times
| better for everyone. Yet, the bug is still there 3 years after
| reporting it.
|
| I also reported a bug in Teams, where you cannot use the
| HOME/END keys in the phone number input, to Microsoft, through
| Premiere Support. The reply was: This works as designed.
|
| I am not surprised that customers don't report these kind of
| bugs any longer, because neither the employees/developers, nor
| the company doesn't give a shit anyway.
| ahoka wrote:
| It's more of the artifact of ticket centric development, so I
| would blame Jira and the like before "programming self help"
| methodologies.
| 2024user wrote:
| This is so true. I'm the lead developer for a product and we
| have loads of small issues all over the place. It is not a
| great feeling to be responsible for something while also not
| having any power to fix it.
|
| From the business point of view, why would they spend time and
| money on fixing these things unless it's hurting sales or
| brand? Long term it likely does affect the brand but most
| people will have moved role/company in 5 years so don't care.
| dustingetz wrote:
| it is hurting sales and brand, the underlying problem is that
| to dramatically increase performance requires recomping both
| the tech team and the management and likely also the
| executives whose decisions shape and limit the org in the
| first place. In any org, the #1 priority for everyone
| involved is to keep their salary flowing, which means not
| replacing themselves with someone better.
| sutra_on wrote:
| This sounds like a lead/architect issue. If you can't roll
| out a custom UI component library, use one of several mature
| libraries that already handles these cases. Accumulating tens
| or hundreds of thousands of lines of UI tech debt is not an
| Agile issue.
| davedx wrote:
| Here is the correct answer to this, buried in the comments.
| itronitron wrote:
| Why do you not have any power to fix it?
| jagged-chisel wrote:
| I feel like this goes along with the recent Artisan Software
| discussion on HN.
|
| Companies don't want Software Artisans.
| itronitron wrote:
| Thanks, I think I just discovered my new job title :)
| abbadadda wrote:
| > [In fact most companies have such opaque issue boards that as
| a customer I get so frustrated when I find a small issue or bug
| and have to spend like 50 hours back and forth to prove it's a
| bug and actually get a ticket put in the tracker.]
|
| Agree wholeheartedly. Back & forth emails, screenshots, Q&A
| (what version are you on?), etc. The number of times I make it
| to checkout on the last step and something breaks on a certain
| version of a browser
| ibash wrote:
| > The customer probably notices this kind of a thing but it's a
| miracle if the customer bothers to report it, and another
| miracle if it eventually turns into a ticket, and another
| miracle if someone prioritises it enough to spend time fixing
| it.
|
| I report a lot of bugs. But it seems like a lot of customer
| support people view their jobs as "protect engineers from bug
| reports and deflect responsibility".
|
| That's if you get a response at all.
| swiftcoder wrote:
| In most companies customer support doesn't have any authority
| to retask engineers. Maybe if a customer reports a security
| issue, or a truly application-breaking bug. Otherwise all
| that customer feedback just gets rolled up into a slide deck
| once per quarter, and ignored
| __MatrixMan__ wrote:
| A neat quirk of having an open source saas product is that
| really it's customer support that's the product (after all,
| you can get the software for free). I think it makes for a
| higher percentage of tickets that are directly related to
| user experience--although there's still plenty of make-
| sales-happy type tickets too: gotta put a really shiny
| bezel around the open source thing.
| Viliam1234 wrote:
| In my experience, it can make a huge difference if the
| developers are allowed to talk directly to the users of their
| product. The users tell them which parts of the product hurt
| them most, and the developers find a way to fix that.
|
| If instead the communication is something like "the end users
| give information to their manager, their manager gives
| information to our analyst, our analyst gives information to
| our manager, our manager creates Jira tasks for us", there is
| often a lot of information lost at every step.
|
| For example, once my team made a web application that allowed
| users to edit some forms. When we asked how many rows there
| will on a form, we got an answer "five, on average". So we
| made forms that supported unlimited number of lines, tested
| them with about 10 rows, everything worked, we considered our
| job well done.
|
| One day, we met a guy who actually used the software. He
| complained about how it sucks, that validating or saving the
| form takes forever, that he sometimes loses data because of a
| timeout, etc. It turned out that although _most_ of the forms
| contained about five rows, _some_ of them actually contained
| thousands of rows. And yes, with over ten thousand rows in a
| form, on a bad day the web application lost the data because
| of a timeout.
|
| The developers were quite shocked. We complained about the
| analysis, but the analyst insisted that the _average_ number
| of rows per form _was_ about five, so the analysis was not
| wrong. (Technically correct; the best kind of correct.) Had
| we known this in advance, we certainly would have chosen a
| different web framework, but now it was too late to rewrite
| everything from scratch. So we just did what we could at this
| moment, some ugly hack like validating only 1000 rows at a
| time, so the end user had to push the validation button
| multiple times for very long forms or something like that,
| but at least he didn 't get a timeout. The hack took about a
| week to implement and test, and the end user was happy,
| because it was a huge improvement over the previous
| situation.
|
| The management still insisted that developers meeting with
| the end users were wasting time. There were Jira tasks
| waiting to do, no time for chat.
| Vegenoid wrote:
| I worked as a sysadmin in a large physical services company.
| We had in-house software that integrated with almost all
| levels of our operations, most employees were using this
| software throughout their day. The whole IT staff, including
| the team of ~10 devs who built and maintained this software,
| worked in-person on the same floor.
|
| L1 support was constantly escalating issues that the sysadmin
| team could not assist with, because they had to do with this
| software. Either bugs, or new corner cases, or something
| changed, or they didn't know how to do something.
|
| We would tell them again and again "we cannot help with
| operating this software" (it was outside our scope of
| responsibilities and knowledge - our job was to make sure the
| computers, servers, and network were all functioning
| properly).
|
| Despite the team of devs sitting 10 meters away, support
| would never, ever, talk to them. I think this was probably a
| dictate from management. It made no sense to me - these
| support staff were constantly using and helping people use
| this software, discovering the problems with it and the ways
| people wanted to use it, and all that feedback just died with
| them. The devs never interacted with the users of the
| software at all.
|
| You can probably guess how user-friendly that software was,
| and how much the users liked it.
| playingalong wrote:
| Yeah.
|
| In some rare cases there's a direct feedback button in the
| product itself. Then usually you don't get the response, but
| at least your remarks are read by someone. Or at least that's
| the impression I get.
|
| As a positive example - check out the new commit view page in
| GitHub which they are currently rolling out. There's a
| Feedback button which goes to a *public* discussion page with
| voting and comments. One can tell they are really into
| listening the feedback. And that's something. At least one of
| the miracles for free.
| madeofpalk wrote:
| I don't know what we're calling "agile", but it's explicitly
| supposed to capture this. You use the product, get feedback
| (from either yourself or users), and iterate on it.
|
| It sounds like you have organisational failures that prevent
| you from getting the feedback or iterating on it.
| corytheboyd wrote:
| When it's something this trivially small, why don't you just...
| do it? So long as you can demonstrate your ability to deliver
| on "real" work, why not just knock these tiny things out too if
| you can? Work it into an adjacent change if that comes up. "But
| my manager and PM and CEO all say this is ILLEGAL TO DO" always
| seems to be the answer... but if your company isn't completely
| rotten to the core with toxic waste, I don't think anyone is
| going to axe you for making small microscopic incremental
| product improvements...
| etherealG wrote:
| Because it's not small. Doing what the article describes
| takes a very significant amount of time. Especially compared
| to a much more directly estimated and measurable action like
| "add x feature". Doing what is described halfway will likely
| return poor results since noticing the subtle things like the
| example given only happens when trying many times with a
| tendency to try random things that you didn't before. Who
| purposefully clicks somewhere they never did before, QA
| people. Most engineers are not QA, and they don't even begin
| to think in a way that leads them to try things that they
| didn't before just to try to find a few pixels of unclickable
| UI. Your assumption that the kind of work described is small
| is a much bigger problem than any so called assumption that
| blaming the PM and CEO is at fault.
| janaagaard wrote:
| > This is so lost in Agile.
|
| My personal experience is that you have to blame the people and
| not the method.
|
| I would define my current project as very agile in the sense
| that we only have details plan for what to do a week ahead at
| the time. Each week the team has an hour long meeting where we
| present what we have done, and discuss if it's good enough. If
| something like a hover region is found to be wrong it will get
| fixed for next week. If you find this issue while working on
| something else, you make task and PR and just fix these smalls
| things. I feel like this way of working is what what meant by
| the people who invented the idea of making software development
| agile.
| sutra_on wrote:
| Not sure what this has to do with Agile. Companies that move
| fast and have complex UI almost always use React (or similar)
| and a UI component library that handles all these edge cases.
|
| Writing CSS for every checkbox makes no sense in Agile.
| wordofx wrote:
| If you're not putting the input inside the label then you're
| doing it wrong.
|
| Bootstrap changing this in v4 is no excuse to not do it.
| donatj wrote:
| As a fellow old, I'm inclined to say labels should just wrap the
| control unless there's a very good reason for it not to. Would
| have completely prevented the issue, wouldn't need a global ID
| nor the "for". Just generally more semantic and cleaner.
| two_handfuls wrote:
| Meanwhile, some other UI uses square boxes for radio buttons.
|
| Or have a highlighted button but the enter key doesn't activate
| it.
|
| Or there are three different menus all behind a different symbol
| (ellipsis, hamburger, kebab).
|
| There is a lot of variance in quality. Those of you who polish
| your UI: you are appreciated. Truly.
| selimco wrote:
| I think space is usually the key that performs a click on
| focused buttons, not enter.
| two_handfuls wrote:
| I was talking about the default button (typically blue,
| activated with enter), not the currently focused button
| (outlined, space).
| meindnoch wrote:
| It's up to the user agent. On one platform it's the spacebar,
| on another it's the return key. Of course, fake controls
| written in JS wouldn't be able to do this. Which is why it's
| the wrong thing to do.
| qingcharles wrote:
| Square or squircle seems to moving towards the standard for
| radio buttons now. Even Apple plays this game :(
| two_handfuls wrote:
| File each as a bug, fight the good fight.
| throwaway14356 wrote:
| i always wrap the labels around the radio buttons and checkboxes.
| the animation also shows nicely that the label should not be
| selectable text. if one wants to further polish it a hover
| highlight might look nice at times.
|
| Drawing a box around the radio buttons is perhaps not modern but
| it may make the form more usable.
|
| The title or description of the element should not be the same as
| the options.
|
| The 4 times might belong in two or more groups. This is something
| to dwell on, make a few mockups then most likely it shouldn't be
| used. If it doesn't jump out as amazingly useful restore
| normality.
|
| consider lining up the time so that the :'s sit in a line. Try
| put the PM in a collum too. Maybe there should be AM as well.
|
| Keep doing useless experiments until you strike gold. It should
| be really hard to beat default form elements (unless it is
| iphone)
|
| Your truly fantastic 1000 line text input should most likely be
| deleted.
|
| the example animation probably has insufficient line height. The
| user shouldn't have to aim that much.
| invaliduser wrote:
| Anecdata, but I found the very same issue (the bermuda triangle
| gap between radioboxes, but also checkboxes, and their labels) in
| a project a few months ago.
|
| It seemed a pretty big deal to me, specially because I always
| clicked on the gap, and got frustrated and angry at this. So I
| reported it to the UX team managing the design system, and to the
| developers implementing the design system, and nobody really
| cared. Some people even tried to convince me this behaviour was
| OK (because other design systems worked that way too, or because
| they were planning to refactor this on the far future so they
| didn't want to spend time on this).
|
| I think the industry is now filled with people that just don't
| care, specially on big companies where, if it's not in a ticket,
| and if the ticket is not prioritized as critical, nobody cares.
| All they care about are metrics (test coverage, line count of a
| function, whatever). Pretty sad actually.
| beryilma wrote:
| Most software engineering has become the modern equivalent of
| assembly line workers, which brings about the concept of
| alienation from our work products, per Marx. It is all about
| productivity metrics and nobody actually cares about non-
| measured forms of quality and artisanship.
| bhy wrote:
| Shouldn't these all be smoothed out by UI frameworks, design
| guidelines and best practices? It doesn't look like the industry
| should spend so much productivity on these sanding works?
| Jaxan wrote:
| I agree that these things should smooth it out. But so far the
| reality shows they do not.
| ryandrake wrote:
| Yea, I'm not a web developer, but coming from the desktop
| world, I am _shocked_ by how little web UI frameworks do for
| you and how buggy their implementation is. Adding padding here
| and margin there and flex boxes and all that shit just to get a
| radio button or a drop-down that we do in one line of code on
| the desktop side? It 's like the software development
| equivalent of using stone tools and chisels to build a car.
| defanor wrote:
| Not directly related to the article's message (though may count
| as collaborative "sanding"), but related to its UI: the page has
| texts centered (margin-left: auto, margin-right: auto, short
| lines), but paragraphs with embedded images lack that, and the
| images are aligned to the left. I thought it may be due to JS
| disabled (if it relies on JS for the layout somehow), but
| enabling it did not change that. Observed in Firefox 115; it is
| not the intended layout, is it?
| ehnto wrote:
| I have found the same to be true in game development once all the
| pieces start coming together. There is no substitute to just
| using the thing. Maybe you don't find bugs/splinters, maybe you
| realise that it just doesn't feel right once you've glued the
| components together.
| smokel wrote:
| This is a great example of where unit testing does not apply.
|
| I see many developers get caught up in rituals, and polishing
| (and monkey testing for that matter) seem to go against a
| reproducible approach, and are therefore frowned upon and even
| ignored. Still, it is a much more powerful technique to get
| something both working _and_ user friendly.
|
| Investing in developers to spot that something is 3 pixels off,
| or the basic idea that different users have different tastes, can
| be very productive.
| dataviz1000 wrote:
| It is also very easy to develop systematic automated ways to do
| this with tools like Playwright and Nut.js.
| handsclean wrote:
| Ok, how would you use Playwright and Nut.js to discover the
| OP's "splinter"? Note I'm specifically asking about
| discovery, not testing for it once you already know what to
| look for.
| thom wrote:
| I've actually been thinking lately about property based
| testing for UIs. In this particularly case, there should be
| an invariant for each entry in a radio button list that the
| selectable area covers the entire bounding box from button
| to the end of the label. There are many such invariants you
| could imagine - every paragraph of text should be
| selectable by a click and drag, menu drop downs shouldn't
| hide as long as the mouse is within its area etc. Build up
| a big enough suite of these tests and you could quite
| easily integrate them in Storybook or beyond. Probably not
| something you want to run on every save, but an
| asynchronous process running somewhere recreating this
| "sanding" activity would be a worth way of saving time and
| improving quality.
| thom wrote:
| Obviously this won't catch everything human QA can, but
| where an invariant can be expressed (navigating then
| going back should result in being in the right place, as
| mentioned in the article) it seems good to try and
| capture it.
| smokel wrote:
| If I understand you correctly, you mean to build up one
| test suite, and apply it to many diverse applications?
|
| I'm afraid that will be pretty hard to accomplish, given
| that such requirements are not easy to distill from the
| user interface itself, and impossible to obtain from the
| codebase (which, by definition, would contain bugs that
| you'd like to catch).
|
| Perhaps LLMs or a "user interface foundation model" might
| come in handy to find these implicit requirements, and
| run tests on the application.
| thom wrote:
| Not sure I'm proposing a single test suite, although some
| of these invariants are very likely applicable to
| multiple components or sites. I'm just saying that
| property based testing ought to be applicable to UIs, but
| it's not the sort of thing we've experiment with because
| executing the tests is slow. That's probably fixable in a
| practical way that's still more efficient than human QA
| for a large class of bugs (including both the back button
| and non-convex hitbox issues mentioned in the article).
| jeffreygoesto wrote:
| The computer always exactly does what you told it to do. You
| almost never know what exactly you told it.
| webprofusion wrote:
| This is (potential) an advantage of small teams and individual
| developers. In more formal teams developers are often handed a UI
| and that's what they have to build, no variation permitted.
|
| However, not every developer will craft a great UI just given
| time, I've seen some truly inspired monstrosities.
| paxcoder wrote:
| Might be a good idea to record clicks that have no associated
| action. If you could display all of such clicks visually, the
| problem might become obvious.
| gwern wrote:
| The problem with that is that users (1) often click at random
| or for stupid reasons (I was shocked when one user contacted me
| to complain about my site acting poorly when they clicked on
| random empty whitespace - they said they just did that
| compulsively as a habit, like fidgeting), and (2) users learn
| to _not_ click on these sorts of papercuts via operant
| conditioning. Like the OP 's example is something that his
| users would learn not to do, and so it would disappear from the
| statistics. It's not obvious to me that it would emerge out of
| the sea of misclicks and bots and random fidgeting clicks. Are
| you going to review a vast list of logged null clicks (and of
| course, lots of these papercuts will be for clicks that _do_
| have actions - the wrong action) regularly? Realistically, no.
| You probably aren 't even reviewing your site's 404s or making
| sure all links work.
| ImHereToVote wrote:
| Seems like a multimodal LLM unit test could do the sanding.
| mdavid626 wrote:
| Put the input >into< the label. Then gap doesn't matter, it'll
| work. Of course, don't allow such mistakes. It's quality work
| when such small details are noticed and cared about.
| remus wrote:
| I think being a big user of whatever you're building is
| incredibly useful for finding these kinds of issues. If you're a
| big user as well as a dev then you will often stumble on these
| little things before a user does, and you are also perfectly
| placed to fix these issues before users can stumble on them.
|
| I suspect this is why small teams with strong ownership can be so
| effective. If you feel ownership of a thing then you feel users'
| pain when they hit these little paper cuts, and it becomes a
| point of personal pride to fix these things and make the UX as
| smooth as possible.
| kizer wrote:
| Also why companies dogfood and have internal betas for products
| (when this is possible; i.e., you're not making something for
| enterprises or other kinds of customers). The sense of
| ownership you're talking about may not be as direct but stake
| in success of the product is there.
| gaborme wrote:
| I really like the sticky face menu on the bottom right. Never
| seen this before. Gave me some inspiration for one of my sites.
| youssefarizk wrote:
| I'm always torn whether this is a good use of time or not. If
| you're an early stage startup, it feels like shipping features
| (that work) quickly is your biggest differentiator, not how nice
| your UI is.
|
| I guess this is true if you're doing something in a not so
| saturated field, but understand that if you're in a saturated
| space, you probably do need the design to be natural os as to set
| yourself apart.
| hombre_fatal wrote:
| The good use of time is that OP learned that labels should wrap
| their inputs, so the next 10,000 times they write a control on
| a form, they'll just do it off the bat.
|
| That this post has 800 upvotes is just a reminder of the
| caliber of UI/UX experience the average HNer has, especially
| when you see them disparage UI development as something
| unworthy of their time / expertise.
| ludwigvan wrote:
| Did they? My understanding is they replaced gap with padding,
| didn't necessarily wrap the input with the label (which they
| should as you suggest)
| wruza wrote:
| Yep, they used flexbox to nicely do... absolutely nothing
| useful beyond blogspam.
|
| Next up "how I made my ui responsive but then heroically
| stopped labels wrapping away from radio marks".
|
| There's a reason, even if accidental, why writing custom
| controls was sort of a black magic in traditional ui. And
| that reason is, most people are clueless about how fragile
| ui actually will be in their hands.
| ryandrake wrote:
| I guess what I learned from the article is how crazy it
| is that developers are still putting UIs together with
| text labels and padding and flexbox-this and align-that.
| What kind of stone age shit is this? Back in the '90s we
| were putting UIs together with controls already polished
| and perfected by the OS vendor, presumably backed by man-
| years of UX research from those companies. The controls
| themselves had styling, behavior, event handling, and so
| on baked in. Fast forward to today's web development,
| where we've regressed to drawing text inside rectangles
| and trying to handle click events on those rectangles,
| and/or wrestling with half-baked "frameworks" that poorly
| do some subset of what OS-provided controls did 30 years
| ago?? UI development seems like cooking in a clay pot
| over a fire that you had to start with flint.
| wruza wrote:
| Absolutely agree, there's so much to lose with completed
| ui controls. It's akin to the situation when you
| disassemble a device for the first time, then reassemble
| it and it's always some parts left on the table.
|
| Styling and customization are useful and interesting
| topics in ui. But instead of thinking it through, most
| libs today just throw a ball of wires at the developer
| who is clueless and often couldn't care less even.
| TimTheTinker wrote:
| The root cause here is that unlike native OS controls,
| most native web controls are primitive as heck.
|
| So companies that don't want to look like Craigslist end
| up either using an off-the-shelf UI controls library (not
| a bad decision, in my opinion), or building their own.
|
| Along with the second option, a new set of disciplines is
| emerging: the design system designer and engineer. Since
| companies have grown so accustomed to building their own
| bespoke design language (instead of using the one the OS
| ships with), it's doubtful that a well-designed set of
| modern, native web controls (that ship with browsers)
| would be able to compete with the notion of "having a
| bespoke design system".
|
| Also, white-label libraries (like Radix UI) are
| increasingly appearing that handle all the implementation
| details and leave the appearance to be defined.
| TimTheTinker wrote:
| > That this post has 800 upvotes is just a reminder of the
| caliber of UI/UX experience the average HNer has
|
| Or maybe it's our collective frustration with processes and
| expectations that make it very difficult to be a craftsman--
| and that make web app UI bad in general.
|
| I remember my boss being frustrated with how long it was
| taking me to build a set of filtering dropdown components
| from scratch (one of the most difficult to get right). I
| stuck with it and put in some extra hours to really get all
| the small details right. Later that year, he asked me to
| tech-lead a newly forming team of UI engineers.
|
| A year later, everyone called it great work and no one
| remembered how long it took.
| enraged_camel wrote:
| Eliminating "friction" is a huge part of maximizing conversion
| and retention, both of which are important metrics for early
| stage startups. It's only once you achieve significant momentum
| that you can afford to let these types of UX annoyances slide.
| The risk is that once you do that, the normalization of
| deviance makes your product end up like Jira.
| throwaway743 wrote:
| It's not about how nice the UI is is, but rather how responsive
| it is and if it's providing your users with enough feedback.
|
| If it's not, it will lead to your users being confused and/or
| frustrated which will lead to them looking for an alternative
| tool.
|
| If you're product is the only one in town, then they're just
| left to deal with it until a competitor pops up with a better
| (whether real or perceived) UI.
| Ylpertnodi wrote:
| >(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.
| cal85 wrote:
| Please elaborate a bit on real vs. perceived UI!
| steve_taylor wrote:
| People tend to underestimate the competitive advantage of a
| nice UI.
| parpfish wrote:
| Absolutely.
|
| Having well sanded features doesn't necessarily remove bugs
| directly drive conversion, but it gives the entire product an
| established professional "feel.
|
| Even though your customers feel it, they won't explicitly
| articulate it
| Viliam1234 wrote:
| Is there actually a competition where the UI could decide the
| winner?
|
| I mean, it is probably very rare to have two products that
| have the same features, and the only difference is how nicely
| done they are. For example, MediaWiki is in my opinion 100x
| better than Confluence, but Confluence has some extra
| features that I don't care about but managers do (stuff like
| easily attaching PowerPoint presentations to web pages), so
| the managers decide that the company uses Confluence. And I
| keep silently screaming in frustration every time I lose a
| part of text during editing, or the links break when a typo
| in a page name is fixed (because there is no option to add a
| redirect), etc.
|
| The extra feature often wins, when the salesman describes the
| product to the manager who makes the buying decision. That's
| why we have the "checkbox features" that most end users don't
| care about, but it allows the product to seem better in
| comparison. Feature creep is how stuff gets sold.
|
| The situation of two featurewise identical products competing
| only on better UI would probably be highly unstable, even if
| it happened somehow. There are network effects, so if one
| product starts winning, most people will switch to that
| product because "that's what everyone else is using". The
| other product will be left without money to pay for
| development, and will go out of business. Afterwards, the
| winning product does not have to care about their UI anymore.
| pennomi wrote:
| I think more projects need some form of the One Hundred Papercuts
| project in Ubuntu, where the goal was to fix little bugs that
| were annoyances but not critical.
| razodactyl wrote:
| You know what.... this was an amazing post. There was a lesson,
| analogy, and a very to-the-point example.
| d_burfoot wrote:
| Someone should do a YouTube channel where they "sand" popular
| software products and point out these kinds of subtle UI bugs.
| gnomespaceship wrote:
| One person I saw do this is Mia:
| https://www.tiktok.com/@heymiadotco
|
| If you sort videos by popularity there's a lot I enjoyed where
| she does a "UX roast" of SaaS or streaming websites
| masklinn wrote:
| You could probably do an entire channel out of just YouTube.
| wruza wrote:
| The lesson here is don't split a control into two parts because
| developers will screw it up. Who prevented control designers from
| doing <radio>foobar</radio> <radio
| mark=end>foobar</radio>
|
| and allowing a mark pseudoelement to participate in alignment? Or
| at least forcing everyone to use the input-in-label variant?
| Nobody.
|
| But they split it, and now people without clear understanding how
| ui should work do it wrong by design and invent Monte Carlo
| methods to check if it works.
|
| And it seems some crappy screenreaders don't even recognize the
| proper form of it, adding salt to the cut.
| perfunctory wrote:
| Alan Kay was right classifying most software engineering as pop
| culture. It's 2024 and we are still fiddling with spaces around
| radio buttons, a problem that should have been solved decades
| ago.
| dclowd9901 wrote:
| I don't get this take. "Still fiddling with spaces around radio
| buttons." It's design. Design is unique to the creation. We
| still fiddle around with spacing around radio buttons because
| one spacing doesn't work for every design.
|
| Unless you're talking about the clicking dead zone, which I
| would argue is more a problem with not using the right cursor
| than the dead zone the gap introduces.
| Sardtok wrote:
| I was on a site the other day, a hotel or flight website. I think
| it was a review form. There were checkboxes, where the checkbox
| wasn't clickable, only the labels. I was sure the whole thing was
| frozen, but happened to find some other UI controls were
| responding. So I tried the labels.
|
| I've come across the reverse scenario quite a few times, where
| the label isn't clickable, but this variant was new to me.
| jbeninger wrote:
| I suspect those were custom UI elements and not native. They
| remembered to onclick the label (or it's a native <label>
| element) but forgot to onclick the checkbox itself
| djsamseng wrote:
| > So I click around, using the UI over and over, until I finally
| cannot give myself any more splinters.
|
| I'd take this with a grain of salt (pun intended). There's a lot
| of bugs that you cannot reproduce without certain permissions or
| a particular environment. Let alone the race conditions or user
| setup. In my experience, most bugs would not have been uncovered
| using this brute force approach. A few tests using your
| understanding of the code and critical thinking goes a lot
| further in my opinion.
| linux2647 wrote:
| "Sanding" shouldn't be the only approach to testing an app.
| Developers should test using a variety of techniques. Some bugs
| are discovered through unit or integration tests, others by
| brute force, others still from end users
| dclowd9901 wrote:
| Bike shedding kind of: I think the real failure here is not using
| a "cursor: pointer" directive. Easy to tell what's clickable when
| your cursor changes based on what's clickable.
| snegrus wrote:
| Sir, this is Ikea.
| VeejayRampay wrote:
| we need to stop pretending that CSS is awesome though, it's been
| in use for about twenty five years now, keeps reinventing itself
| and still fails at simple things (as exhibited in this example)
| anybodyhome wrote:
| Hard to believe this hasn't been abstracted and solved at the
| browser level in 2024.
| Muromec wrote:
| It's hard to believe because it's not true. You wrap the input
| with a label and it works.
___________________________________________________________________
(page generated 2024-09-22 23:00 UTC)