[HN Gopher] User Interface Design: Rules of Thumb
___________________________________________________________________
User Interface Design: Rules of Thumb
Author : elephant_burger
Score : 204 points
Date : 2022-12-23 14:23 UTC (8 hours ago)
(HTM) web link (mannhowie.com)
(TXT) w3m dump (mannhowie.com)
| throwaway4good wrote:
| Anyone remember Jakob Nielsen and his usability heuristics:
|
| https://www.nngroup.com/articles/ten-usability-heuristics/
|
| 10 Usability Heuristics for User Interface Design
|
| ?
| twojacobtwo wrote:
| I'm starting to get into frontend development after sticking to
| backend for years. Does anyone know of a more fleshed-out set of
| rules of thumb for beginners in UI/UX development?
| iamphilrae wrote:
| Don't Make Me Think by Steve Krug is an absolute must book for
| any UX beginner. Easily digestible and lasts through the ages
| as an example of good rules to follow.
| twojacobtwo wrote:
| From the quick searches I've done, it seems a lot of people
| agree with you. Do you have any opinion on whether the 2nd
| edition is preferable? Either way, thank you for the
| recommendation!
| solardev wrote:
| I think this ebook is very very good and well worth the
| money...
|
| https://www.refactoringui.com/
|
| Full of great tips and no fluff. Basically gives you a large
| but fantastic set of rules to live by, cohesive enough that you
| don't have to deviate from them unless you know what you're
| doing and have a solid need to. But otherwise it's a great
| foundation that you can implement in any design system.
| twojacobtwo wrote:
| That is quite pricey for an ebook, but if it's as good as you
| say, it seems worth adding to my library. Thank you for the
| recommendation!
| runarberg wrote:
| Not really, but browsing Smashing Magazine[1] or A List
| Apart's[2] more popular articles could give you a better sense,
| and some more in depth knowledge.
|
| 1: https://www.smashingmagazine.com/
|
| 2: https://alistapart.com/
| twojacobtwo wrote:
| Added to my bookmarks. Much appreciated!
| andrei_says_ wrote:
| An example of thoughtful approach to ui https://design-
| system.service.gov.uk/
|
| A collection of ui patterns https://every-layout.dev/
|
| A great resource for css reference https://css-tricks.com/
|
| https://typographyforlawyers.com/ Covers the basics with zero
| pretense
|
| Kevin Powell on YouTube has great css rutorials
| https://youtu.be/rg7Fvvl3taU
|
| Jen Simmons on YouTube and https://labs.jensimmons.com/
|
| https://youtu.be/0Gr1XSyxZy0
| twojacobtwo wrote:
| Wow! This is an excellent set of resources. Thank you!
| joegahona wrote:
| Any experience or opinions on https://baymard.com/ ?
| joegahona wrote:
| Small quibble: I agree with No. 1, but I'm annoyed with the
| example of the "Good" version, because it gives no option for an
| amount that doesn't exist. Imagine buying your next coffee and
| having the barista swivel that iPad around to you to pay, and
| your options for tipping were ONLY "$5, $10, or $15." In reality,
| there's always a backdoor to put a custom amount, so I
| acknowledge I'm being fussy.
| [deleted]
| JakeAl wrote:
| You're right, it's not user-centered design, it's creator-
| centered design, like those god-awful lightbox overlays for
| subscribing to newsletters that are the most horrible
| interference ever. And no, I don't care that they have huge
| conversion rates, they piss off the user, so they are bad
| design. This is the kind of garbage designed by marketing
| people, not tech design people who know anything about good UX.
| politelemon wrote:
| I can't help but notice, the first rule there has an overlap with
| dark patterns. It makes sense, you're trying to encourage a
| specific behaviour through an option, so it represents how far
| you're willing to go.
| a-r-t wrote:
| Fixed options can also reduce the outcome (donations in this
| case) if you don't A/B test them properly.
| mixedCase wrote:
| Here's another one: Have proper contrast for the close button in
| the newsletter ad.
| SicSemperUranus wrote:
| So far 3 out of 5 items in the list have been called into
| question. Seems like an entire domain of knowledge might be a bit
| too broad to be summarized into listicles, even with the caveat
| that they are "rules of thumb".
| BuckyBeaver wrote:
| 6. Don't hide things that are disabled. GREY THEM OUT. That's how
| users learn that
|
| a. The function exists
|
| b. Where it resides
|
| c. That it requires some condition to be satisfied before usage
| kersplody wrote:
| Furthermore, communicate why the function is disabled. Nothing
| is more frustrating than knowing a function existents but not
| knowing the conditions required to enable it.
| BuckyBeaver wrote:
| Yep, that's ideal. Sometimes, though, this can be hard to
| convey efficiently when there are multiple conditions.
| ToolTips can help.
| runarberg wrote:
| Even better, don't gray it out, allow people to prematurely
| click, and if they do, guide them to the precondition with a
| focus and a message about what must be done.
| brailsafe wrote:
| It depends on whether they can affect the condition that would
| enable it imo.
| foobarbecue wrote:
| His "flash mode" example, which he labels "good," is bad, in my
| opinion.
|
| He's drawn one of those circle-in-a-slot switches. I often have
| trouble figuring out what the on / off state of those is supposed
| to be. And then the discription "flash mode" makes it even more
| unclear how a switch state corresponds to app state (does on mean
| enabled? does on mean suppressed?).
|
| The good example for "email weekly summary" is actually good,
| because checkboxes have a clearly enabled / disabled state and if
| it's enabled the user knows the thing in the text next to it will
| happen. It's clear. "flash mode" should be re-written in the
| "email weekly summary" style. It would have a checkbox with a
| label "use Adobe Flash for rendering."
| intrepidhero wrote:
| Toggle slider switches are the blue/gold dress of UI design. In
| a given population roughly 50% will swear with absolute
| certainty the given state is "enabled" and the other 50% will
| be ready to start a holy war with the conviction it is
| "disabled".
|
| The population can be further subdivided into camps which
| disagree over what enabled and disabled even mean in this
| context.
|
| Literally any design choice is better.
| joegahona wrote:
| Genuinely curious, not challenging you: Do you have trouble
| figuring out the on/off state on iPhone toggles? They've always
| been obvious to me, but I have seen bad toggles out in the
| wild.
| burntwater wrote:
| On Androids I have this problem all the time. It's a
| combination of bad color and bad text - I don't know if iOS
| forces the color OS-wide, but the text is app dependent.
| waboremo wrote:
| His flash example is particularly bad because it's not a
| setting that should be binary in the first place. Auto/On/Off
| are all important settings for flash photography. Removing one
| of them would actively anger a lot of people. This section is
| actually a really great example of how tiny decisions made in
| UI can actively reduce usability even though on the superficial
| level it seems like a good idea.
|
| I also think flash mode is represented well on most camera
| apps. I wouldn't change a thing about them other than maybe
| adding a text label.
| terr-dav wrote:
| >He's drawn one of those circle-in-a-slot switches. I often
| have trouble figuring out what the on / off state of those is
| supposed to be.
|
| iOS has an option to display I/O labels on these toggles too,
| and as it turns out, not everyone knows that I/O refers to
| on/off. I found out about this when I had to explain to a
| friend that those symbols meant open and closed respectively on
| the vents in a car.
| burntwater wrote:
| I know what I/O refers to, and I have for the last, I dunno,
| 30 years. Do I know which letter refers to which state? Not a
| damn clue. I have never been able to remember it.
| robocat wrote:
| Yeah, terrible convention, especially because on and off
| both begin with O. And memory-aid stories don't help:
| "those symbols meant open and closed respectively on the
| vents" - hang on - is O like an open vent or does it mean
| off?
| layer8 wrote:
| It's not I/O (the "I" displays with serifs for me), it's |/
| (line and circle). As a mnemonic, you can think of it as 1
| and 0 (for on and off).
|
| The standby symbol [?] combines the two.
| Groxx wrote:
| The real solution is to stop describing _the thing being
| changed_ and start describing _the state_.
|
| "Flash mode" is the problem.
|
| "Flash is on/off" is the solution.
|
| ("is" is important here. "flash on" has many ways to be
| interpreted because it's missing a verb.)
|
| Your UI should be understandable from text alone if needed.
| Dalewyn wrote:
| One of the problems compounding unusable UI that I've noticed
| is the trend to use as little text as possible.
|
| I can understand why designers and even developers want to
| not use text: Handling multiple languages is annoying and
| getting people to read is impossible.
|
| But you know what? I don't understand what that fucking
| black-and-white hieroglyph you pulled out of your ass five
| days ago fucking means.
| 8n4vidtmkvmk wrote:
| you mean pulled out of font awesome's limited ass
| FractalHQ wrote:
| For booleans I tend to prefer using "Enable/Disable". In this
| example, "Disable Flash" with a checkbox that is clearly in
| an "Enabled" state can reduce ambiguity. Alternatively,
| displaying the state and using tooltips that describe the
| action can be great, but falls apart on mobile devices.
| user3939382 wrote:
| The absolute worst is the "iPhone is dead / charging / not
| charging" graphic on my phone. I have absolutely no idea which
| one indicates that the charger is successfully connected. Like
| PLEASE can you just put the label "Charging" on it.
|
| Is this an instruction or a status??
| https://i.imgur.com/2u8RlDG.jpg
| addandsubtract wrote:
| Not owning an iPhone, I would say this is an instruction.
| Once it's charging, the battery indicator should show a
| lightning symbol in the middle, or a "Charging" text as you
| said.
| bxparks wrote:
| I don't have an iPhone, so I would say that the lightning
| symbol and the plug icon means the cable is connected and
| charging.
| worldmerge wrote:
| Does anyone have recommendations for learning physical user
| interface design or hci? A lot of the articles I find on UI
| design are focused on websites or apps.
| larsrc wrote:
| Additional rules of thumb:
|
| * Avoid single choices. If there's only one possible choice,
| don't waste the user's time by requiring an action. At most show
| that that value is chosen.
|
| * Select the best defaults you possibly can. If some extra coding
| work allows pre-selecting the right default infor 50% of the
| users without making it harder for the rest of the users, it's a
| win.
|
| * Remember the user's input. Making the user select the same
| thing again and again is insulting.
|
| * Don't have an explicit setting when an implicit one will do.
| The width of a panel can be remembered from the last time the
| user resized it, there doesn't have to be a place to enter a
| value for it.
| yashap wrote:
| There's a couple that stand out as "nice ideas in theory, but
| rarely practical in reality" - undo over confirmation, and
| progress bar over spinner.
|
| Confirmation dialogs take about 2 minutes to implement. Undo,
| while there's the odd problem where it's easy, very often it's a
| massive amount of work to implement, like many months.
|
| Likewise, a spinner is a few mins of work, while an ACCURATE
| progress bar can be much, much more. It's often really hard to
| predict how long a given operation will take.
| btbuildem wrote:
| I think the key thing to keep in mind is that the end user
| really, really, and I cannot emphasize this enough, absolutely
| and totally does not care about how much effort something was
| for a developer.
|
| This guide is from a UX person, they are looking at things from
| a usability perspective. Developer effort is not a
| consideration here, and rightfully so.
| hbrn wrote:
| > Confirmation dialogs take about 2 minutes to implement. Undo,
| while there's the odd problem where it's easy, very often it's
| a massive amount of work to implement, like many months.
|
| UX is a feature.
|
| Might be irrelevant for yet another SaaS, but for consumer-
| facing products it will be the reason you succeed.
|
| Looks at this decade old presentation from Instagram:
| https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mob...
|
| This is the mindset that led to $1B valuation (which many
| believe to be undervalued).
| zdragnar wrote:
| One thing I hate about my phone is that certain apps have
| horizontal swipe to delete list items. It presents an undo
| option, but the undo option doesn't appear for very long, and
| can itself be dismissed quite easy by accident. Text message
| conversations are especially prone.
|
| The number of times I've deleted something with no recourse
| because my dog bumped my hand while holding the phone (or some
| similar unintentional action) went from frustrating to
| embarassing to enraging long ago.
| rahoulb wrote:
| A problem with confirmation dialogues is users become
| accustomed to confirming everything ("of course I want to do
| that") and then miss the important irreversible change and just
| hit the button.
| mykowebhn wrote:
| Okay, good.
|
| Now that you got the UI right, stop tweaking and changing it. I
| can't stand when the UI on so many apps and webpages change
| simply because the UI folks and programmers need something to do.
| notatoad wrote:
| UI doesn't change because UI folks have nothing to do, it
| changes because people love to complain, and sales loves to be
| able to tell customers "we made that change you asked for".
|
| If you like an app and don't want the UI to change, tell the
| company. as long as all the people who like it are silent and
| all the people who don't like it are complaining loudly, apps
| are going to keep changing.
| BuckyBeaver wrote:
| Eh, not sure about that. Microsoft has made a profound mess
| out of Windows and Office, in ways that are hard to imagine
| anyone asking for.
| InCityDreams wrote:
| 1000 purchases. 100 complaints. Change something because 900
| people didn't tell you they were ok with things?
| timfsu wrote:
| Sure, because you don't know if the 900 people are silent
| because they're happy or lazy. A 10% complaint rate feels
| quite high for a typical feature and would tell me that I
| probably got something wrong.
| [deleted]
| [deleted]
| papito wrote:
| "Hey, everyone - new guideline bible from AirB&B just dropped!"
| happytoexplain wrote:
| Spinner vs progress bar is not short vs long operation, it's non-
| progressive vs progressive operation (though you may opt for a
| spinner if a progressive operation is _consistently, predictably_
| very short).
|
| In the software world, designers need to be engineers (or work
| very closely with engineers, very early in the process). We
| recently had designers give us a nice looking progressive
| indicator for a non-progressive operation that _happened_ to take
| a somewhat predictable amount of time. Business loved the look
| and visual feedback. Then we got use cases where the operation
| could be instantaneous. They didn 't want to skip the progress
| animation because they liked how it made the app feel like it was
| doing something, and also if the user got the result instantly,
| it was "jarring". So now, even if the operation finishes
| instantly, we show the animation, wasting the user's time.
| lelandfe wrote:
| > though you may opt for a spinner if a progressive operation
| is consistently, predictably very short
|
| For greater guidance on this, the Nielsen Norman Group spake
| thusly:
|
| > _Use a progress indicator for any action that takes longer
| than about 1.0 second._
|
| > _[A looped loading animation] should be reserved for actions
| that take between 2-10 seconds. For anything that takes less
| than 1 second to load, it is distracting to use a looped
| animation, because users cannot keep up with what happened and
| might feel anxious about whatever flashed on the screen_
|
| > _Generally, percent-done progress indicators should be used
| for longer processes that take 10 or more seconds._
|
| https://www.nngroup.com/articles/progress-indicators/
| elboru wrote:
| Junk apps have taught me that a spinner that takes too much
| time could be an indication of failure though. The user will be
| inclined to refresh or close the app.
| mort96 wrote:
| Same, but only if it "looks like" the app expects it to take
| a short-ish amount of time. If your operation will take more
| than a few seconds, the app can include text saying "This
| usually takes a few minutes" (or whatever is appropriate),
| and I'll know that a long of a delay to expect before I think
| something's wrong.
| tshaddox wrote:
| > So now, even if the operation finishes instantly, we show the
| animation, wasting the user's time.
|
| I thought it was fairly well accepted that small deliberate UI
| delays (for things like loading spinners and animations) can in
| many cases result in a better user experience. Of course, that
| would depend on how long this animation is that you're talking
| about.
| happytoexplain wrote:
| You're absolutely right, in some cases. It depends on who you
| are and what kind of software you use. Delays or animations
| can improve communication between the UI and the user. Or,
| they can be pointless and frustrating, e.g. if the software's
| task feels utilitarian, and there's no confusing or hard-to-
| perceive transition that an animation would help to bridge,
| and the user _knows_ the animation is functionless.
| geysersam wrote:
| Wonder how often this is the case. Especially a couple of years
| ago, in early SPA time, show 1s spinner every page navigation.
| _shudder_
| a-r-t wrote:
| Do you work for TurboTax by any chance? :)
| happytoexplain wrote:
| No, but I'm aware they do the same thing for psychological
| reasons. Our road to hell was much less formal (Business: "I
| like the way it feels").
| geysersam wrote:
| Perhaps you can reduce the animation time by 5% every
| month. One day people will have gotten used to the faster
| behavior. Eventually you can remove it without anyone
| feeling that something is off.
| franky47 wrote:
| And brag to management that you made the app 100% faster.
| simonmales wrote:
| This is quite a well know pattern for flight ticket
| aggregators.
| [deleted]
| simonbarker87 wrote:
| I had this on a project recently, they wanted the spinner to
| appear for at least 5 seconds even if the operation took less
| than that. Most of the time it took under 2 seconds - made me
| so annoyed.
| CharlesW wrote:
| > _Spinner vs progress bar is not short vs long operation, it
| 's non-progressive vs progressive operation..._
|
| Spinners are typically used for "indeterminate" operations
| while progress bars are typically used for "determinate"
| operations1.
|
| "Progressive" is a less useful adjective here because
| indeterminate operations progress too, and it's just that their
| total duration can't be usefully estimated.
|
| And as you note these aren't hard-and-fast rules, and a spinner
| is generally a perfectly fine choice for short determinate
| operations.
|
| 1 Progress bar controls typically have an indeterminate flavor
| too, and these can be mixed. For example, you'll typically see
| an indeterminate form of a progress bar until a total duration
| can be estimated, at which point the progress bar will change
| to its determinate form.
| wintogreen74 wrote:
| Even determinate progress bars are challenging because they
| typically represent a portion of a known measure that doesn't
| necessarily match with the user's measure of reference.
| Example: "75%" complete might mean 75 of 100 files updated
| while the user is thinking "It's taken 15 minutes so 5
| minutes longer.
| CharlesW wrote:
| Absolutely! Is there anything more painful than a progress
| bar that "hangs" at 95% for 30% of the total time?
| happytoexplain wrote:
| >Progress bar controls typically have an indeterminate flavor
| too
|
| Good point - I was simplifying by referring to all
| progressive animations as "progress bars" and all non-
| progressive animations as "spinners".
|
| >indeterminate operations progress too
|
| I normally think of "non-progressive" and "indeterminate" as
| synonymous in this context. If the UI can't tell what
| fraction of the whole has been completed by _any_ metric
| (which could even include best guesses based on historical
| data), I refer to that as non-progressive or indeterminate,
| interchangeably.
| CharlesW wrote:
| Cool, I figured we were just using different words for the
| same thing. I learned a lot of this stuff in the "Inside
| Macintosh" days, so my UX argot tends to align with it.
| https://developer.apple.com/design/human-interface-
| guideline...
| psygn89 wrote:
| On the opposite side of jarring there are times where an app
| refresh action works so fast that users think that it's broken
| since they didn't visually see a change (even though it did
| refresh and there is nothing new to show).
| Arrath wrote:
| "Wait did the page actually refresh? I better hard refresh
| just be to safe..."
| ziml77 wrote:
| My solution to that is to simply have a last updated time on
| the page with precision down to seconds. Just update it to
| the current time every time there's a response from the
| server even if it's empty.
| [deleted]
| jonnybgood wrote:
| > They didn't want to skip the progress animation because they
| liked how it made the app feel like it was doing something, and
| also if the user got the result instantly, it was "jarring".
|
| Like hard bristle toothbrushes. Hard bristle toothbrushes are
| not good for your gums. So why do they make them? Because
| customers like hearing the sound of the toothbrush brushing.
| They like hearing it do something.
| caradine wrote:
| I inherited a React codebase that was littered with
| setTimeout() for no apparent reason.
| bmelton wrote:
| Bad race condition protection or trying to impose a sense of
| gravitas through loading times?
| robocat wrote:
| I think setTimeout() is a bad code smell because it very
| often introduces race conditions. Fortunately async has
| reduced the need for it.
| jamil7 wrote:
| Recently worked on an iOS app with the exact same thing,
| delays inserted on every write which was basically instant as
| it was writing to SQLite. Client refused to remove it too,
| you need to pick your battles as a freelancer to get anything
| done, so I left them there.
| [deleted]
| kevincox wrote:
| If you are lucky it is to give the illusion of the app
| working hard. If you are unlucky they are "fixing" race
| conditions.
| RicoElectrico wrote:
| The zeroth should be "don't fuck with the middle mouse button".
| Though it's not as bad as it used to be.
| SilasX wrote:
| What? It's much worse now, I routinely see rich web apps which
| refuse to open a detail view in a new tab, and reject the
| attempt by the middle mouse button to do so. Instead I get a
| huge noticeable lag to switch between the two. Ick.
| savingGrace wrote:
| While pair programming I will say something like "just click on
| it with your mmb" and I always hear "what's that do?" I have
| yet to work with a single developer that uses the mmb. I live
| and die by mine. This doesn't include the "I don't have a MMB"
| Mac club.
| RicoElectrico wrote:
| It is quite handy as a clipboard in Linux distros.
|
| That said, I learned the hard way the switches put for MMB
| are often subpar and fail quite fast. I replaced an Omron (?)
| switch in a Logitech mouse... twice. Thankfully the current
| Corsair M55 (pretty basic wired gamer mouse) goes strong.
| neon_electro wrote:
| My "middle mouse button" on my Mac is the Command key. It
| does the same thing as the middle mouse button when combined
| with a left click.
| jonas-w wrote:
| Yes, there is also a ctrl + left-click feature in Windows
| and Linux, but it isn't nearly as convenient as the middle
| mouse button.
| GGO wrote:
| if you want dark patterns in your UI, just do all the bad ones :)
| hermitcrab wrote:
| I find the slide left/right buttons shown as the first diagram in
| point 2 to be confusing. Is the text referring to the current
| state or what happens if I click it? Is there an official name
| for that button type? Give me a check box any day.
| gsich wrote:
| Don't use the slider checkbox from example 2. It's not obvious
| what the state is, especially without color/contrast.
| buttersbrian wrote:
| I don't think slide toggles are inherently bad, but yes color
| is your friend and doing them like Material does them is a
| solid foundation.
| cosmotic wrote:
| Slide toggles are widely considered to have bad usability
| because it's not clear what position they are in.
| foobarbecue wrote:
| Slide toggles are such an annyoing fad. I find them really
| unusable. If you're going to implement one, please label
| which side is on vs off. Or just use a damn checkbox -- it's
| the same thing, but actually clear when it's enabled or
| disabled.
| andrei_says_ wrote:
| Appple iOS design uses these instead of checkboxes and the
| web followed. Don't see how they are better - maybe when
| used without a submit button to imply that the change takes
| place immediately.
| skydhash wrote:
| I believe because it always mean On/Enabled/Active when
| it's green. So consistent meaning.
| kristopolous wrote:
| You can generalize this: if you have to implement the UI
| element because it's not there by default (like a slider), it's
| probably worthwhile to investigate why.
| andrei_says_ wrote:
| Also default browser elements have been tested and retested.
| Reimplementing prettier versions is not always better.
|
| some form elements like checkboxes, radios, sliders, cannot
| have their size or color be controlled via css - they need to
| be outright replaced.
| kristopolous wrote:
| People reimplementing basic things like scrolling always
| comes out so comically bad and broken.
|
| It reminds me of the classic dragon drop parody
| https://m.youtube.com/watch?v=DCu1G2rxj5c
| thealienthing wrote:
| Do the opposite of this blog post and you get Eclipse IDE
| btbuildem wrote:
| I'm curious about the hierarchy one. On one hand, it seems like a
| good rule, because one of the hallmarks of a dense, hard-to-use
| UI is the presence of deep option trees. On the other hand, there
| is ALWAYS complexity in something large enough, and it cannot be
| abstracted away, best we hope for is to organize it well -- and
| hierarchies are a natural way of doing that.
|
| A good middle ground that I've seen across programs, apps and OS-
| level menus is to add a search box that "skips" the hierarchy
| navigation when the user knows what they're looking for.
|
| Another interesting idea was "adaptive" menus where the most used
| options (per user) would be "nearest" / easiest to get to. That
| one is nice in theory, but in practice it causes things to move
| around, and makes it harder to develop familiarity with the
| nested menus.
|
| On the point of familiarity: a solution that appears clever and
| great, but hasn't taken off (probably because it still feels
| "unusual") is the circle menu. It makes good use of muscle
| memory, as all the options are arranged in concentric rings
| around a start point, with selection on one ring opening the next
| (more outer) ring with more options.
|
| As far as the author's suggestion -- I guess it aims to keep the
| top-level menus simple. Where does the complexity go? If it's
| boxed away in some other dialog, per "category" or "subject", it
| could work relatively well. A bit more effort from the designers
| to make it that way, but generally that means it's less effort
| for the user to interact with.
| deltarholamda wrote:
| >A good middle ground that I've seen across programs, apps and
| OS-level menus is to add a search box that "skips" the
| hierarchy navigation
|
| I use this in the iOS Settings all the time. It truly is a
| great and important UI element.
|
| Web sites could benefit from adopting this as well. With the
| rise of Google, it seemed like everybody just kind of gave up
| on search. "They'll just Google it anyway." But for a lot of
| Web sites, having a decent and working search tool is really
| important.
|
| I remember a lot of articles talking about how to handle search
| on your Web site, with lots of tools and libraries and whatnot,
| and it just kind of dried up. There's still work happening on
| Big Time search technologies (Lucene, et. al.), but other than
| built-in things for platforms like Wordpress, it's kind of
| stale and quiet.
| notatoad wrote:
| i don't think there's a good answer on the hierarchy problem.
| there's two types of users - the ones who like to see all the
| settings available to them, and the ones who get angry or
| confused if any settings are displayed that aren't relevant to
| them. these two groups of users will never agree on what
| settings should be visible and what should be hidden.
| 83457 wrote:
| I communicated with my son's doctor through a system that
| included a checkbox with label Not Urgent that defaulted to
| checked. As I submitted an urgent message, I clicked that
| checkbox and hit submit in quick succession.
|
| Later I went through sent messages and the urgency indicator was
| opposite of intended on all. I looked at the form more closely
| and realized that the label was actually indicating what clicking
| the checkbox would change the state to, so clicking indicated it
| was not urgent.
|
| I emailed the company about the confusing behavior and received
| no response.
| efortis wrote:
| [x] Set as Urgent
|
| Having a verb helps.
|
| Here'a blog post with more examples, and tips for checkboxes.
|
| https://blog.uidrafter.com/guidelines-for-checkboxes
| Nifty3929 wrote:
| One thing I haven't seen discussed before are the two different
| types of options, which should be handled differently.
|
| - Options which any particular user might want to change on a
| regular basis. These should be near the "front" of the UI within
| reach according to how often a user might be expected to change
| it.
|
| - Options which different users may select differently, but which
| a specific user is unlikely to change. These can be buried, as
| long as they are easily discoverable so that users are at least
| aware of the option.
|
| Also please make toggles unambiguously on or off. Those little
| sliders, especially solo, can be difficult to figure out the
| current state of. Maybe put the word "On/Off" right on the slider
| itself. Or put the state in the label: (-0) Flash is ON. (0-)
| Flash is OFF
| montebicyclelo wrote:
| I'd add that I've noticed older people struggling with hidden UI
| elements. (E.g. not knowing that button X will appear if they do
| Y (and then not remembering if told...)).
| tracker1 wrote:
| I think that beyond a relatively obvious menu, non-obvious UI
| elements are an anti-pattern. And I'm someone that largely came
| up in text-based UI interfaces (BBSes, terminal apps, etc).
| Things should be largely discoverable in practice for graphical
| user interfaces, even if there's a shortcut.
| ericmcer wrote:
| There must be a whole branch of design geared towards older
| generations. I have been trying to work in this area and have
| noticed older people are very persistent and will read
| instructions carefully, but are very hesitant to click and
| explore things. Meanwhile young people immediately click and
| interact with everything without any fear but will completely
| ignore any kind of written instruction.
|
| I was testing a web app out on my dad and he dragged the cursor
| to the bottom of the screen, which brought up the Mac Dock
| which immediately confused him and he asked my why I did that.
| I am not sure how to code around just general inability to use
| a computer, maybe avoid elements at the edges of the viewport
| haha.
| ragnese wrote:
| I've noticed this as well. Ironically, I believe it's because
| product design was generally _worse_ "back in the day."
| Normal items you'd buy from a store or catalog could be
| legitimately dangerous if you operated them incorrectly
| (electrically powered appliances like lamps and toasters that
| were not polarized/grounded, for example). So, rather than
| risk the very real likelihood of breaking your new gadget or
| injuring yourself, you were better off reading the
| instructions and only using the device as you were instructed
| to.
|
| These days, things are pretty much "stupid proof." No matter
| how many times I insist on it, people my parents' age simply
| refuse to believe that there is nothing they could reasonably
| type or click while using their computer that will
| irreparably harm it. (Yes, of course they _could_ somehow
| format their hard drive, etc, but there 's zero chance you'd
| be able to do that on accident.)
| BuckyBeaver wrote:
| "I believe it's because product design was generally worse
| 'back in the day.'"
|
| I don't agree with this generalization. Here's an example:
| A stereo receiver, even today's A/V receiver, has a certain
| number of physical inputs. Back in the day, you had buttons
| on the front to select the input you wanted, clearly
| labeled. One press gets you the source you want, every
| time.
|
| Many receivers today force you to press an Input button or
| turn a wheel to iterate through a list of inputs, a list of
| unknown size and unknown beginning and end. This is because
| the display idiotically doesn't show a complete LIST of the
| inputs at once, or even a moving dot to show you where you
| are in the list. So you could be one input below the one
| you're trying to select in the list, but if you happen to
| turn the dial the other way you'll go through 10 inputs to
| get back to it. Granted, this is much less commonly
| encountered now because nobody is going over to his
| receiver to put a disc in the player, but it was a problem
| for many years when people were still doing so.
|
| In some cases, older designs were also better for safety.
| When safety is on the line, the best design (or at least
| universally-understood standards) often percolate to the
| top and stay there.
|
| A sad example of this was Jeep's attempt to "innovate" with
| a disastrously defective gear shift, which killed Star Trek
| actor Anton Yelchin:
| https://www.theguardian.com/film/2016/jun/20/star-trek-
| actor...
|
| But I also acknowledge that there have been major safety
| improvements. The other day I rented a chain saw for the
| first time and was comforted to see the safety brake on it.
| BuckyBeaver wrote:
| That's why UI elements should almost never appear and
| disappear. There's a reason that GREYING OUT disabled controls
| has always been a fundamental concept of GUI design. It shows
| users that the function exists, where it exists, and that it's
| conditional.
|
| Peek-a-boo UI is incompetent. It's even dumber when you
| consider that, in most cases, the space for the disappearing
| controls has already been reserved; so nothing is gained by
| hiding them.
|
| And almost as bad as peek-a-boo UI is "flat" UI, where most
| controls aren't demarcated as such. So you're reduced to
| clicking on plain text labels and other inert-looking
| components to see if there are hidden goodies associated with
| them. Absurd.
|
| This is age-related only in that that it's about visual cues,
| which are the entire point of GUIs to begin with. Physical
| buttons on a device are inherently discoverable, as were the
| controls in GUIs for decades. Younger people are used to the
| incompetence of newer designs, and more tolerant of having to
| click every pixel on the screen to find things. It's
| unfortunate.
|
| The bright spot is that there has been some backlash against
| the "flat" laziness and a return to some visual cues.
| runarberg wrote:
| I'm generally not a fan of this design pattern. If an action is
| required before the button is applicable, consider disabling it
| instead of hiding it, or--even better--allow clicking it and
| simply guide the user to the required action (e.g. focus the
| required element and show and error message under it; maybe
| shake it a little if you're up to it).
| neon_electro wrote:
| ESPECIALLY "buttons" that are basically text links without the
| underline. If you're lucky, you might have a "pill" border or
| drop shadow, but that hasn't helped my dad in my experience
| observing him.
| Mesopropithecus wrote:
| Hasn't helped me either, and I'm in all likelyhood a bit
| younger than most people's dads :).
|
| This is an anti pattern which good directly against the
| concept of "affordance."
| hateful wrote:
| The latest example of this I've seen is that after the latest
| cable box update - full screen ads will show for shows when it
| turns on and my mom doesn't know how to close them and I have
| to come help. She only knows how to change the channels, not
| interact with GUIs. She's never used a mouse before or used
| "arrow" keys to move an interface. She only knows "this button
| does this".
|
| Another example is that our last TV had a "Source" Button. But
| it doesn't change the source, it brings up a list so you can
| choose a source. Nearly every week she would accidentally hit
| Channel Up or Down on the TV remote and then not know how to
| switch it back to the Cable Box. She'd hit Source and it
| wouldn't change the source and then call me.
|
| Sadly, she has dementia now and will never learn.
| paulryanrogers wrote:
| Could you open the remote and remove channel up/down buttons?
| Or put some electrical tape underneath to make them
| ineffective?
| rkagerer wrote:
| This article lost me in the first two examples.
|
| Defaults are fine, but as a user I'd like a choice to enter my
| own donation amount.
|
| I've always found the touted toggle box control to be ambiguous
| compared to the old-fashioned checkmark in a box.
| Damogran6 wrote:
| You ever get two button choices and due to the color selection,
| can't tell which is highlighted? Not a fan of that.
| dylan604 wrote:
| When programming DVD menus, this was a very common issue. I
| used to think to myself that at least in web design, this isn't
| an issue since the :hover type action is what caused the
| highlight. Then we got touch screens without :hover and it now
| haunts me again.
| JakeAl wrote:
| I recommend this book, but it's pre-smartphone. Still the best
| book for telling you what design elements should be used under
| which circumstances.
|
| https://archive.org/details/guidesignhandboo0000fowl
| chiefalchemist wrote:
| > "... cchoices or behaviour you want to encourage."
|
| Perhaps. But too often tbat mindset results in dark patterns.
| That is, the user is "encouraged" to make choices not in their
| best interest.
|
| This was in the first couple of lines. I checked out immediately.
| trilbyglens wrote:
| Apparently "rule of thumb" is now banned accordingly to Stanford
| as it's "harmful"
| orthecreedence wrote:
| Do you have any idea how hurtful the phrase is to people
| without thumbs? And if we only follow "rules of thumb" where
| does that leave canines, whales, and tardigrades? Not to
| mention mycelium. What UI best practices are they to follow?
|
| Let's try to be a bit more inclusive...
| type0 wrote:
| This rule is considered harmful and hurts Koalas that have two
| opposable thumbs
___________________________________________________________________
(page generated 2022-12-23 23:01 UTC)