[HN Gopher] The Eight Golden Rules of Interface Design
___________________________________________________________________
The Eight Golden Rules of Interface Design
Author : luu
Score : 29 points
Date : 2024-01-08 19:15 UTC (3 hours ago)
(HTM) web link (www.cs.umd.edu)
(TXT) w3m dump (www.cs.umd.edu)
| stevage wrote:
| These seem common sense, but it's good to see them written down.
|
| The one about giving users closure in a sequence of tasks is kind
| of novel. I like it.
| georgeecollins wrote:
| Not sure that Strive for Consistency should be a golden rule of
| all interface design. Software maybe. But the reality is the
| world is inconsistent and humans mental model of tasks are
| inconsistent. Sometimes its better to design an interface that
| conforms to the world or the mental model.
|
| As a random example: You could have an interface on a car that is
| almost entirely touch screens. You might see replacing the
| steering wheel with a touch screen interface. That would be
| consistent but not a good mapping to people's mental model.
| leetrout wrote:
| Not sure that is the best comparison because it removes the
| mechanical need for leverage, even with power steering.
|
| Now that we have more electric steer by wire... maybe.
| ebiester wrote:
| Think of it more like this.
|
| On page A, you have a button. It looks like a button. When you
| click it, a dialog opens that confirms you want to perform an
| action.
|
| On page B, you click on the button, and it's a dropdown. You
| now have lost a sense of the mental model of the application
| world.
|
| It's possible that you may want one of three actions based on
| your mental model, but the visual should lead you to know "this
| is different."
|
| If you have something that looks like a
| Jtsummers wrote:
| > that are applicable in most interactive systems. These
| principles, derived from experience and refined over three
| decades, require validation and tuning for specific design
| domains. No list such as this can be complete, but even the
| original list from 1985, has been well received as a useful
| guide to students and designers.
|
| The author already caveated that they aren't absolutes. That
| is, they aren't declaring you should follow these rules off a
| figurative cliff. That would be stupid. The presumption is that
| people would still exercise judgement.
| ivan_gammel wrote:
| > You could have an interface on a car that is almost entirely
| touch screens. You might see replacing the steering wheel with
| a touch screen interface. That would be consistent but not a
| good mapping to people's mental model.
|
| Consistency means that users can expect the same behavior from
| elements with the same specific purpose. When you put steering
| wheel and infotainment system in the same classification
| bucket, it is not consistency, it is excessive abstraction.
| bbor wrote:
| Can an expert explain some context here?? This seems like a less-
| well-phrased version of Norman's principles, which were the ones
| I was taught in HCI class.
|
| The author is clearly some sort of textbook author so they know
| what they're talking about, but these principles seem like they
| were written without considering past work. Like "short term
| memory load" seems like a phrase that would be replaced by
| "cognitive load" by most authors, even if it's technically a
| little bit less specific. Some of the principles are pretty much
| identical (consistency), while others seem oddly phrased (like
| "prevent errors" instead of "constraints").
|
| Obviously these principles are great, just seems like there has
| to be a story about the academic drama here.
| ivan_gammel wrote:
| I was not familiar with this author, but they mentioned that
| these principles were defined around 1985 -- before Nielsen's
| heuristics. A lot of things were different 40 years ago, so
| language may indeed seem a bit archaic.
| bbor wrote:
| Ah okay saw the textbook publish date and stupidly assumed
| that was the overall date. Thanks, makes sense! In that case
| this is a fascinating look into the past and a testament to
| how solid these principle are, since they've endured and
| popped up in similar lists.
| jonstewart wrote:
| Ben Schneiderman is an ACM Fellow and CS professor emeritus of
| the University of Maryland-College Park. These 8 principles are
| from his 1986 book. He's done a lot of work in infovis and HCI
| and is the inventor of the treemap visualization.
|
| https://en.m.wikipedia.org/wiki/Ben_Shneiderman
| infotainment wrote:
| Some good stuff here, but generally I'd disagree with:
|
| _> Prevent errors: As much as possible, design the interface so
| that users cannot make serious errors; for example, gray out menu
| items that are not appropriate and do not allow alphabetic
| characters in numeric entry fields (Section 3.3.5_
|
| This sounds nice in theory, but in practice too many guardrails
| like this will just confuse users. "Why can't I type text here??"
| It's often better to allow mistakes but also offer immediate
| explanatory feedback if something is incorrect.
| ivan_gammel wrote:
| > It's often better to allow mistakes but also offer immediate
| explanatory feedback if something is incorrect.
|
| That is just another form of error prevention: in the end
| erroneous data will not be submitted.
| Jtsummers wrote:
| > It's often better to allow mistakes but also offer immediate
| explanatory feedback if something is incorrect.
|
| Which is what the rule actually describes.
|
| > If users make an error, the interface should offer simple,
| constructive, and specific instructions for recovery. For
| example, users should not have to retype an entire name-address
| form if they enter an invalid zip code but rather should be
| guided to repair only the faulty part. Erroneous actions should
| leave the interface state unchanged, or the interface should
| give instructions about restoring the state.
|
| I'm very confused by some of the attempts at "gotchas" in this
| discussion that are just restating what the list (and context
| paragraphs) already say as if it didn't say it.
| graypegg wrote:
| A designer I worked with years ago had a great explanation for
| why consistency is important.
|
| It's not about a limited colour palette or a careful selection of
| fonts no one will ever notice. Chasing the specifics makes
| horrible software. Some people equate less diversity in their UI
| to more consistency.
|
| It's about letting someone become an expert in your software.
|
| Microsoft office was always his example. People pride themselves
| on "knowing" Microsoft office. They jump between all of the apps
| because they have a feel for the inertia of "office". I have the
| exact same feeling in Vim. I just know how things are expected to
| be, and new (well made) plugins tend to respect those patterns.
|
| Office and (Neo)Vim aren't exceptional examples of UI, but they
| are uniquely stable.
| Angostura wrote:
| It's possibly one of the reasons why so many people were bent
| out of shape when MS introduced the adaptive ribbon shenanigans
| that tried to 'help' by only showing the most likely options.
| Really knocked my ability to find stuff
| staplers wrote:
| Expectation should precede consistency in order of
| importance.
|
| Meaning, if a new user is learning your software, how would
| they expect the next [flow] to go?
|
| Consistency often shapes expectations but when things go how
| you expect them to, you don't need to learn new mental
| models.
| joshuaheard wrote:
| "For example, users should not have to retype an entire name-
| address form if they enter an invalid zip code but rather should
| be guided to repair only the faulty part."
|
| This is my biggest pet peeve, and I still see it. It should also
| be true for multi-page forms if you are going back and forth
| between form pages.
|
| "Erroneous actions should leave the interface state unchanged, or
| the interface should give instructions about restoring the
| state."
|
| Designers seeking to save space on small screens like phones and
| watches are increasingly relying on icons. However, many icons
| are unfamiliar or hard to decipher. Sometimes, the only way to
| figure it out is to click on it. Every such icon should have a
| way to go back to the original state if a mistake is made.
___________________________________________________________________
(page generated 2024-01-08 23:00 UTC)