Live data from Hacker News

Golden Rules of Interface Design (2013)

cs.umd.edu

141–150 of 173 posts

Re: Golden Rules of Interface Design (2013)

#141

Earlier quoted context omitted.

If you strictly mean pure software for "UX", then I agree. However, for electronics from the 80s and 90s, Japanese audio/visual hardware (especially Sony) was amazing for UX design. Albeit, the screen was limited to a small LED screen, but the combination of buttons and menus was impressively designed.

The trend of everything having only one physical button sucks . Press and hold for X seconds to do one thing. Tap then hold to do Y. Double tap for a third. And they do it for like 20 functions.

They should combine buttons with a touchscreen. 80s remotes sometimes had too many buttons:

https://images3-hu-secure.gs-static.com/products/4096x4096/2...

Re: Golden Rules of Interface Design (2013)

#142
post #130

One golden rule that I learned is that interface elements should not move unexpectedly after the interface has been drawn. Google is particularly bad for buttons which move between you lifting your thumb and pressing the screen, but they're not alone.

I wish this would be addressed at the OS level. If a target popped into existence less than ~0.25 seconds before it was touched, a touch event shouldn't be generated. Humans reaction times aren't fast enough to hit a button that quickly anyway.

Great idea. Should also take into account misclicks directly after layouts shifts in some websites.

Re: Golden Rules of Interface Design (2013)

#143

Earlier quoted context omitted.

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.

One could say the same thing about the command line and software like vim being made to keep the youngsters out.

Not that I agree with GP but this comment doesn't make any sense. I don't think any serious software product was made specifically to be difficult to use for young people and I'm certain such an endeavor would fail or otherwise be difficult to use for anyone. Young people are the ones who will try to^W^W get DOOM to run on their smart toothbrush.

Re: Golden Rules of Interface Design (2013)

#144

Earlier quoted context omitted.

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.

One could say the same thing about the command line and software like vim being made to keep the youngsters out.

Those interfaces were made out neccesity before graphical interfaces existed.

Re: Golden Rules of Interface Design (2013)

#145
post #94
post #83

Earlier quoted context omitted.

Point of good interface is to hide implementation detail while guiding you towards your goal.

To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.

Exactly!

Usually, the designed conceptual model imposes constraints on the implementation. Sometimes, the implementation affects the conceptual model (a leaky abstraction). But they are logically orthogonal.

And you can't "abstract away" the conceptual model as if it were an implementation detail. The conceptual model IS the abstraction!

Re: Golden Rules of Interface Design (2013)

#146
post #105
post #94

Earlier quoted context omitted.

To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.

There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that). But the one option that is rarely used but yields the (IMH…

Excellent point and example!

Joel Spolsky described these as "leaky abstractions". If the implementation does not quite match the conceptual models, then the implementation "leaks out" to the user. The user is confused because the UI does not match the conceptual model in their head.

Re: Golden Rules of Interface Design (2013)

#147

Earlier quoted context omitted.

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.

UX designer here. I've learned that these changes are a delicate balance between allowing existing user to remain experts while improving the retention of new users. This can be accomplished by making small changes over time that break up all the new info a user has to learn and avoiding the big UI reveal which people universally hate because all that new learning is required at once and they need to get stuff done.…

As a fellow UX designer, i've learned the same.

Re: Golden Rules of Interface Design (2013)

#148
This one simple information-theoretic principle is an effective guide for user interface design:

    Things that are the same should look the same, and things that are different should look different.
Your UI conveys information to the user, and the user has finite cognitive capacity for receiving and interpreting that information. So keep the the signal-to-noise ratio high!

In my experience, a large portion of the user experience problems in real products are consequences of violating this principle. Construed broadly, this principle implies many design guidelines, e.g.:

- If the user changes something, make the change immediately visible

- If internal state affects what the user can do, make it visible

- Don't use nonstandard interface widgets or icons

If you can get this right, you're a lot of the way there.

Re: Golden Rules of Interface Design (2013)

#149

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

How about graying out the button, but adding a tooltip on hover that tells the user why they can't click

Re: Golden Rules of Interface Design (2013)

#150
post #140

Earlier quoted context omitted.

4chan - smart people acting dumb HN - dumb people acting smart

I haven't looked at 4chan in ages, but my conclusion was trolling by smart people evolved in to ideas enthusiastically spread by dumb people. You can see evidence of this in the anti-vax community where the line between devious trolling and just really idiotic behavior is. A better analogy for Snapchat and UI design is fashion. Fashion is basically an invisible circle of inclusion. Clothing styles don't go out of fas…

[dead]
Post reply on HN