Live data from Hacker News

Golden Rules of Interface Design (2013)

cs.umd.edu

21–30 of 173 posts

Re: Golden Rules of Interface Design (2013)

#21

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 steer…

When I was a kid there were toy RC cars that had two controls, kind of like 1-axis joysticks. The left one pushed upward would cause the car to go forward, possibly with more or less power. The right one pushed to the right allowed turning to the right (but not the left, like Zoolander).

A consistent upgrade to this interface would be to allow reversing using the left control in a downward direction and turning left using the right control pushed to the left. An inconsistent application would be to have reverse on the right control pushed to the left and left turning on the left control pushed downward.

Inconsistencies across classes are not uncommon and probably understandable given various expectations. For example, the same handlebar steering control behaves very differently on a two-wheeled motorcycle compared to a tricycle.

Re: Golden Rules of Interface Design (2013)

#22

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 steer…

I feel like that's a bad example because touchscreen controls in cars are just bad in general. Adding a new one makes the car worse because the touchscreen control is bad, not because of anything to do with consistency - all the other touchscreen controls made the car worse too.

Re: Golden Rules of Interface Design (2013)

#24
post #4

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…

No drama, just history! Ben Shneiderman's been doing "UX" research since before it was a defined term (previously called "Human-Computer Interaction" or even "Man-Machine Interfaces"). He was my thesis advisor in the early 1990's and first published these guidelines in the 1980's.

Re: Golden Rules of Interface Design (2013)

#25
post #7

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…

both vim and neovim are examples of UI, just not (G)UI :)

Re: Golden Rules of Interface Design (2013)

#26

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?…

Add a tooltip on disabled inputs.

Re: Golden Rules of Interface Design (2013)

#27
> gray out menu items that are not appropriate

Don't do this unless it is obvious why it is grayed out. Commands should be left enabled, then an error message should be displayed when the command is clicked and the command is unavailable, and in this case explain why it is presently unavailable. It is frustrating to the user to figure out why a command is disabled. The only time to not leave commands enabled is if the user is likely to end up wasting a lot of time only to be told at the end that the command is unavailable.

Update: Read more about this in this article: https://medium.com/@vedranio/james-bond-and-the-design-of-di...

Re: Golden Rules of Interface Design (2013)

#28

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?…

I can't tell which browsers or UI libraries do this, but do you know those date pickers that try to maintain a valid date with every keypress? It's such a horrible user experience if you try to type a date by hand.

Re: Golden Rules of Interface Design (2013)

#29

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 steer…

In this case the consistency is between what you learned to drive in, and the car you use now.

Re: Golden Rules of Interface Design (2013)

#30
post #7

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…

As a non-"Designer" something I never shut up about is how powerful it is to bootstrap that expertness by leveraging the UI elements and concepts your users already know from elsewhere, for instance, literal native UI widgets, and more broadly, highly-recognizable simple fundamental widget types. When you have the opportunity to present 4 options, you could use your brand's themed version of [Insert UI Library]'s searchable combobox with checkable items, or you could show 4 normal labeled radio buttons or checkboxes. The latter beats the former in every way:

1. User knows whether they can pick one vs many based on the circles vs squares.

2. User can see all four options, even if the widget ends up unfortunately placed in the viewport (I've had to scroll inside these and only be able to see like 2 options at once, so many times).

3. No issues with mobile keyboard wanting to open to let you "search", further obstructing the tiny viewport.

4. Accessibility will always be 100%.

Yet this option "fails" in the category of "looks cute with our Design System" so usually designers choose the first choice, and worse, "standardize" on doing that, so that using normal widgets is a "bug."

Ultimately too many "UX designers" are hacks, who worship and pursue aesthetics and branding at the expense of everything else. A UI widget isn't the time or place to assert your brand or creativity, any more than you should design your own font that forces all letters to be shapes from your logo. Your customers don't care about your brand more than being able to complete their tasks.

Post reply on HN