Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golden Rules of Interface Design (2013)

cs.umd.edu

Post reply on HN
Print view View original

61–70 of 173 posts

Re: Golden Rules of Interface Design (2013)

#61

Post by userbinator »

mjevans wrote: post #51
Angostura wrote: post #8

Earlier quoted context omitted.

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

I still hate ribbons. MS Office UI peeked around versions 97-2003 or so. Everything in a menu, actions grouped / categorized so they were easier to discover. QUICKLY accessible by underlined keyboard combinations (alt+menu letter THEN item in menu letter) and with any actions that had a direct keyboard shortcut annotated. Everything easily discoverable. Ribbons, I've no idea how the categorize what's popular or not,…

You can still access the items in the ribbons with Alt key sequences (although I agree that they've become far less discoverable), but the full-screen(!) "file menu" abomination that they added in later versions is even more hostile and offensive.

Re: Golden Rules of Interface Design (2013)

#62

Post by rrr_oh_man »

nox101 wrote: post #48
ShadowBanThis01 wrote: post #37

Earlier quoted context omitted.

Annoying as shit. If I'm trying to log into something with an E-mail address (already a fail, but that's another topic) and password, and I click "forgot password," don't take me to a form where I have to re-enter the goddamned E-mail address I JUST ENTERED.

Or every customer service phone line where the automated system asks for your info (account# or phone#) and then the customer service rep asks again >:(

That is only to keep you busy and engaged

Re: Golden Rules of Interface Design (2013)

#63

Post by rrr_oh_man »

bob1029 wrote: post #46

> Sequences of actions should be organized into groups with a beginning, middle, and end. Informative feedback at the completion of a group of actions gives users the satisfaction of accomplishment, a sense of relief, a signal to drop contingency plans from their minds, and an indicator to prepare for the next group of actions. This is why we built our product around a workflow abstraction. Everything the user can do…

Care to share the product?

Re: Golden Rules of Interface Design (2013)

#64

Post by bluGill »

nox101 wrote: post #48
ShadowBanThis01 wrote: post #37

Earlier quoted context omitted.

Annoying as shit. If I'm trying to log into something with an E-mail address (already a fail, but that's another topic) and password, and I click "forgot password," don't take me to a form where I have to re-enter the goddamned E-mail address I JUST ENTERED.

Or every customer service phone line where the automated system asks for your info (account# or phone#) and then the customer service rep asks again >:(

In some cases this is a verification and reques, for more information. when doctors reask what the nurse just asked.

most of the time it isn't. the doctor already knows what you told the nurse. (where the doctor doesn't that is bad)

Re: Golden Rules of Interface Design (2013)

#65

Post by bluGill »

DonHopkins wrote: post #55
kazinator wrote: post #33

Where are the apps shipped by umn.edu?

What does the University of Minnesota Twin Cities have to do with this discussion? And why do you care which apps a university research lab shipped? ;) If you want to know about what contributions Ben Shneiderman and his University of Maryland Human Computer Interaction Lab have made, you can read my other post: https://news.ycombinator.com/item?id=38920423 Or wikipedia: https://en.wikipedia.org/wiki/Ben_Shneiderman…

To someone in Minnesota umd means university of Minnesota Duluth campus.

Re: Golden Rules of Interface Design (2013)

#66

Post by [deleted] »

godzillabrennus wrote: post #38
bithive123 wrote: post #31

Although not really part of a UI's "design", performance is often overlooked as well. A poorly performing UI violates every single one of these design rules. My sony android smart TV looks amazing but the UI is so slow as to be unusable. An unstable UI that is always changing also violates most of these principles. Smart TVs seem to be exceptionally bad in this area too, with the home screen layout and app icons freq…

Ever since Snapchat exploded in popularity I’ve decided bad UI is a gen z feature. They flock to difficult to use interfaces that become an insider feature for young folks to keep their parents out.

[deleted]

Re: Golden Rules of Interface Design (2013)

#67

Post by arcanemachiner »

breadwinner wrote: post #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 th…

Sure, but there should be some kind of consistent visual affordance that conveys that the action is disabled, before the user clicks on it.

Re: Golden Rules of Interface Design (2013)

#68

Post by llanowarelves »

DonHopkins wrote: post #45
graypegg wrote: 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…

I worked with Ben Shneiderman at the UMD Human Computer Interaction Lab developing pie menus, and one of the important principles of pie menus, especially in comparison to both traditional linear menus, and invisible gestures as used by the iPad and mobile apps, is that they smoothly TRAIN novice users to become experts by using "rehearsal". Pie menus can lead, follow, or get out of the way. The way a novice uses the…

Thanks. A lot of good stuff here that may go overlooked.

Re: Golden Rules of Interface Design (2013)

#69

Post by DonHopkins »

joeblubaugh wrote: post #56
DonHopkins wrote: post #45

Earlier quoted context omitted.

I worked with Ben Shneiderman at the UMD Human Computer Interaction Lab developing pie menus, and one of the important principles of pie menus, especially in comparison to both traditional linear menus, and invisible gestures as used by the iPad and mobile apps, is that they smoothly TRAIN novice users to become experts by using "rehearsal". Pie menus can lead, follow, or get out of the way. The way a novice uses the…

Do you know of any work about how to combine pie menus and keyboard usage? Mousing is very uncomfortable for me, but if a pie menu could be used with a keyboard-attached joystick, it might be a really quick way to work.

Pie menus work well with trackpads and trackpoints (keyboard clitoris), as well as analog and digital 4- or 8-directional joysticks, and even numeric keypads and arrow keys.

If you arrange your menus into 4- and 8-item pie menus, they are uniformly navigable and memorable for many types of input devices including keyboards. Four and eight items are ideal for muscle memory, and also cognitive memory too. So using pie menu layouts that map directly to keyboards and digital joysticks works really well.

The ActiveX pie menus I implemented for Internet Explorer a couple decades ago supported full keyboard navigation:

https://www.youtube.com/watch?v=nnC8x9x3Xag

Re: Golden Rules of Interface Design (2013)

#70

Post by breadwinner »

arcanemachiner wrote: post #67
breadwinner wrote: post #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 th…

Sure, but there should be some kind of consistent visual affordance that conveys that the action is disabled, before the user clicks on it.

If the user is likely to keep clicking the button only to be told that the feature is currently unavailable, then some kind of status indicator would be helpful. In my experience, this situation is very uncommon.
Post reply on HN