[HN Gopher] UX design patterns for loading
___________________________________________________________________
UX design patterns for loading
Author : akbarnama
Score : 44 points
Date : 2023-08-26 17:02 UTC (1 days ago)
(HTM) web link (pencilandpaper.io)
(TXT) w3m dump (pencilandpaper.io)
| agumonkey wrote:
| Thanks, nice reference/summary that is easy to forget when you're
| deep down in your component tree :)
| chrisjj wrote:
| > For high-stakes operations that are done occasionally, you
| might consider making tasks seem longer, as if more important,
| than they actually are.
|
| No. Just no.
| abdullahkhalids wrote:
| The unsend-within-a-minute feature in various email
| services/client is an example of this that is super useful.
| happytoexplain wrote:
| That's a grace period - the parent is referring to faux
| loading times, e.g. a spinner that blocks the UI despite
| nothing happening.
| nkrisc wrote:
| Like all things, know your audience.
|
| I know of a case where a delay was introduced because users
| didn't believe the task was done because it happened so
| quickly, and contacted support thinking there was a problem
| (there wasn't).
|
| All related support contacts stopped after the artificial delay
| was introduced.
|
| As you may have guessed, these were not technically savvy
| users. But it's what they needed.
| happytoexplain wrote:
| There are UX solutions that are not deceptive/time-wasting
| (e.g. a brief checkmark, but the actual solution will depend
| on many variables of the exact scenario).
| elwell wrote:
| How about dropping CPU clock speed until the computation
| _actually_ takes avg 5-10 seconds?
| blowski wrote:
| During testing of a pension calculator I built, the users
| expressed more trust in the page when it took about 5-10
| seconds to show results than when it showed them instantly.
| They equated instant results with a less complex model.
| happytoexplain wrote:
| I've always considered this a good example of the rare case
| where metrics are true and meaningful (how the users feel),
| but should still be ignored in favor of _principles_ (well,
| not _ignore_ - one should look into other avenues to improve
| the user 's perception of the tool). A more black-and-white
| example would be dark patterns that demonstrably increase
| user retention.
| Permik wrote:
| Ah yes, I love my "wipe my hard drive and send my wife a text
| message that divorce papers are on the kitchen counter"-button
| next to my enter button on my keyboard!
|
| Edit: Humans make mistakes, give them a little time for
| introspection before something non-reversible happens. Also,
| for people like you, there's usually an option for "don't show
| this again".
| serial_dev wrote:
| The feature you are looking for is the "undo" option. Gmail
| has it, many other apps have it, so you have time to cancel
| your divorce email.
|
| Pretending to be busy for five seconds with no way to undo it
| or cancel the request while waiting won't save you your
| marriage.
| Espressosaurus wrote:
| There's a difference between "are you sure?" and the
| time.sleep(10) with a loading bar to make it seem like you're
| doing work that was done in the first 10 milliseconds.
| Eduard wrote:
| > Progress bar
|
| > Hot tip: Use an ease-in animation to make the progress seem
| like it's accelerating.
|
| So annoying when websites try to deceive me with a quantified
| progress bar inversely inching towards completion even though I
| cut off Internet five minutes ago.
| amelius wrote:
| So what's a good programming design pattern to build good
| progress bars?
|
| Progress bars for I/O are typically easy. Progress bars for
| computations with deep call graphs are typically more
| difficult.
| tanbog5 wrote:
| I would say, don't use progress unless they are communicating
| useful and/or meaningful information?
| gochi wrote:
| All progress bars lie
| https://austinhenley.com/blog/fixprogressbars.html
|
| It's a challenging problem, because either attempts at a
| solution (being direct, or being indirect) causes a worse user
| experience due to expectations of linear progress. For example
| proposed solution 1 in the article would have you create some
| sort of animation or additional progress bar to let people know
| if something is actually stalled/dropped vs something just
| taking more time, you would still be lying to them, but it's
| for the benefit of user experience.
| jwells89 wrote:
| On the section regarding loading items in a list, the article
| notes to be careful with infinite loading or a "load more" button
| for performance reasons, which is totally correct but would it
| not be standard practice to have some kind of
| recycler/virtualizer mechanism in place if the UI is likely to be
| handling such large quantities of items?
| mteam88 wrote:
| This was my thought as well. Virtualization can reduce
| performance impact, but I like their point for pagination, that
| it gives users a specific place to link or reference.
| happytoexplain wrote:
| They make a common mistake in the "Frequency" section in regards
| to passive operations: The examples are a "frequent" operation
| (syncing your changes up) and a "rare" operation (remote changes
| being synced down while you are working). Frequency of course is
| not the salient property here. The difference in UX is practical:
| The latter requires your explicit attention, while the former
| does not.
| arthurofbabylon wrote:
| Minimal has a nice trick for loading new collaborations... When
| joining a note a writer is met with a simple presentation of the
| note title, the collaborator's name, and a small bit of text
| describing how collaboration works. By the time the writer has
| processed that minuscule yet valuable information, the note has
| loaded and is ready for them.
|
| Effect: - no wait time, snappy interaction - better context
| around a new experience
|
| Cost: - nothing
|
| It reminds me that a solid portion of good design is not applying
| a rule or system, but creatively working between the cracks of
| known/obvious problem-solution pairs.
___________________________________________________________________
(page generated 2023-08-27 23:00 UTC)