return to table of content

Golden Rules of Interface Design (2013)

graypegg
40 replies
5d20h

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
11 replies
5d20h

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

mjevans
7 replies
5d17h

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, but 'related' things seem weaker to me, and the context switch price is much higher. Plus there's a need to hunt and kill with a mouse instead of direct with the keyboard.

userbinator
2 replies
5d15h

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.

Espressosaurus
1 replies
5d12h

Especially after they made everything cloud-first, making saving my damn documents to my local drive a pain in the ass.

TaroEld
0 replies
5d11h

F12 brings up the old "Save As" filebrowser.

troupo
2 replies
5d5h

Ribbons for Word used to have actual research behind them. Since then it's just cargo culting.

Sadly, many images are broken, but the blog series "Why The New UI" survives on web archive: https://web.archive.org/web/20080316101025/http://blogs.msdn...

saratogacx
1 replies
5d

There's an old MIX08 video where some guys from MS actually talk through the design process and everything that went into it with a lot of depth as well as looking at alternative ideas and why they didn't work.

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

hypercube33
0 replies
3d12h

I think I've seen a video where they take the metrics they ask to collect (and everyone I've seen opts out) where the more buttons were clicked in office the bigger and further to the left they moved.

I find it weird based on my comment that windows and office is built around people who choose not to opt out either by ignoring the dialogs or by knowing what it's used for and hoping their metrics make some difference. Unfortunately I think it's mostly just people wanting to be a part of the product who really participate in user voice a lot of the time so we get weird design choices sticking like the mystery meat cut copy paste in windows 11

kuchenbecker
0 replies
5d15h

My first job was on a particularly verbose set if software that's hard to learn. But, everyone that uses it does so daily and quickly become experts in their workflows.

Number of clicks was the #1 metric because a "pretty" UI would generally add steps and slow everyone down.

Verbose UIs are hard to learn but once learned have much better end-to-end workflows with fewer steps. Simple UIs hide information behind interactive (i.e. slow) workflows and universally hated by customers.

staplers
2 replies
5d19h

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.

jonshariat
1 replies
5d19h

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.

Often times its required because as a product moves into mass market phase of its life cycle, it needs to be simple to use for lots of people, which mean it doenst work great for any specific goup.

Which is why I'm really in favor of allowing customizations to the user where appropriate. It allows experts to have control over their flow and new users can enjoy the UX optimized for them.

staplers
0 replies
4d20h

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

eviks
7 replies
5d8h

How can MS Office be this example when shortcut modification is awful there, as well as Ribbon customization??? People pride themselves on all the nonsense they've invested a huge deal of time into, that's not an indication of any quality or UI excellence Vim is another prime example of extremely user unfriendly UI design, breaking most of the principles from the linked article (but similarly, with folks who've invested a few metric tons of effort into fixing it will pride themselves)

jpc0
6 replies
4d8h

Vim is another prime example of extremely user unfriendly UI design

I know it's going to come off the wrong way but as an editor, I would take plain vim over VSCode/VS/IntelliJ etc any day. Give me neovim as an option and I would be even happier.

I don't spend "a few metric tons of effort into fixing it", there's nothing wrong with a modal editor with key chords as the primary interface. It's not something you can "open and just use with 0 experience" but neither is your car or any other useful complex tool.

The fact that Vim & Emacs design hasn't really changed in decades yet they still have a very vast userbase should indicate something.

eviks
5 replies
4d4h

Give me neovim as an option and I would be even happier.

That's fine, the issue here isn't someone's personal happiness, but good design (my 2nd sentence already covers this apparent contradiction)

there's nothing wrong with a modal editor with key chords as the primary interface.

There is this whole list of UI design principles that tells you what's wrong

It's not something you can "open and just use with 0 experience" but neither is your car or any other useful complex tool.

Yeah, that's not the issue, >0 experience doesn't require bad interface. Like, a car doesn't require pressing 6 buttons with no feedback to turn left, instead you have a wheel with immediate feedback (still requires experience to get the feel for the connect at different speeds)

The fact that Vim & Emacs design hasn't really changed in decades yet they still have a very vast userbase should indicate something.

It doesn't indicate what you imply it does. But to answer in kind: the fact that both have multiple (in total) close to complete rewrites of the whole interface (full set of key bindings, commands, tabs, plugin languages, etc.) should indicate something, and not something positive about those interfaces

jpc0
2 replies
3d21h

Not to discredit, really I am actually interested and may even agree with you.

Give me an example of a text editor that you concider to have good UI design.

eviks
1 replies
3d4h

That's not a very useful approach, there are big issues with all of the stock configs, though with enough customization you could pick various design patterns to make it good (but still you can't collect all of the best ones in one app unfortunately, and doing that is a lot of effort). Thinking from "first principles" like this list is more appropriate

But a few examples:

The "visual-first" approach of kakoune/helix is good UI, better than the "keep the whole sequence of ops in your head". Then emacs' which-key displaying a helpful menu of key chord continuation, but only if you're stuck (after a delay) is good UI design, better than Helix's constant popups.

That's "informative feedback" right there

Then any GUI's tab management approach where you can simply drag&drop tabs around is good. Though if you could "cut/copy&paste" that would be better as that would be consistent with how you manage files in a file manager

Command palette like with fuzzy search like Sublime Text's is good UI design, that helps in reducing your memory load as you can find an action without remembering a shortcut (but then if you invoke it frequently enough you could remember the shortcut from the tip and use that instead)

Then keymaps that prioritize convenience of key locations for most commonly used keys is good UI design (don't think any text editor has it by default, most prioritize English-only semi-abiguous keycap abbreviations)

Etc. etc.

jpc0
0 replies
3d

See I can agree with all of this and ironically the exact changes I make to my neovim setup address quite a few of these.

I'm going to look into helix again, I never gave it a good go since I didn't really see any benefit ovwe what I already have but maybe I was premature on it.

I just wanted to make sure we aren't on two completely different trains of thought here where potentially your answer would have been "Visual Studio is the pinnacle"...

Everything is a trade-off and for me personally I really don't want to have to touch my mouse to do common things, I'll take a slightly more intuitive UI where I need to memorize things to make doing the things I do the most often easy.

Neovim (only slightly modified, telescope + lsp and completions effectively ) + tmux or a tab based terminal is where I am happy.

I happened to spend 3-4 months in Visual Studio and fleet when I switched back to Windows (C++/golang ane some python/js) and when I eventually could dedicate the time to setup neovim correctly on Windows it felt like a breath of fresh air compared to that.

graypegg
1 replies
4d1h

The conversation we’re having is about consistency only. That’s why I said “they aren’t examples of exceptional UI”.

They just respect the fact that people have become experts in using their tools.

eviks
0 replies
3d4h

Sorry about broadening the scope, but even in the narrow one Ribbon broke stability in a big way consistency when it was introduced, so that's not uniquely stable

Vim is stable in a close-to-tautological "if plugins respect stability, they're stable", otherwise vim ecosystem has a lot of packages wildly departing from the default (it's definitely uniquely customizable, though)

ShadowBanThis01
5 replies
5d18h

I agree with the importance of consistency, but disagree with "Office and (Neo)Vim aren’t exceptional examples of UI, but they are uniquely stable."

Office is not stable, at least over the long term. The hated "ribbon" marked a sad departure from the "stable" and efficient Word UI, and Microsoft's clueless regressions across the Windows platform have compounded the problem. For example, the deletion of the menu bar from applications. WTF.

troupo
2 replies
5d5h
ShadowBanThis01
1 replies
3d14h

Thanks. I'm going to watch that MS video and see if I'm still as pissy about the ribbon afterward.

Ribbon aside, there are still lots of regressions in Word. The handling of styles, for example, which used to be excellent. Now Microsoft has stuffed the style list with dozens of asinine canned styles (most of which consist of different-colored underlines) that you can't get rid of. So instead of being able to format your document efficiently by selecting styles, you must now wade through a giant list of shit, looking for your own styles every goddamned time you want to apply one.

hypercube33
0 replies
3d12h

Just wait until the default template gets hacked up by some fluke in word and it's permanently stuck to weird formatting. you can revert it back but it's weirdly hidden and took me a Google to do it instead of just finding and clicking a "default word style format" theme thing.

This crap really drives me to use markdown and pandoc to crap out word files when I'm done. I also really hate how word deals with document formatting and images.

kemotep
1 replies
5d15h

We are about a year or 2 from the Ribbon interface existing in Office longer than the pre-Ribbon interface.

I will agree that the Ribbon and what you can customize or use in it/looks has changed drastically since 2007.

But the Ribbon “paradigm” will soon have existed longer than the non-Ribbon “stable and efficient” interface so it is more “stable” in one way.

ShadowBanThis01
0 replies
5d13h

Stabilizing on shit is a sad thing to double down on. But Microsoft is doing that at every opportunity now. Witness their offensive, relentless hounding to log in, log in, LOG IN WITH YOUR "MICROSOFT ACCOUNT!!!!!!"... or you can't do anything, including install Windows.

DonHopkins
5 replies
5d17h

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 them is actually rehearsal for how a more experienced and experts use them.

Unlike invisible gestures, they can pop up and show users the available items. They also support reselection and browsing, which gestures don't. They also utilize 100% of possible "gesture space" as meaningful predictable actions, as opposed to gesture recognition which squanders most possible gestures as syntax errors.

Gesture Space:

https://donhopkins.medium.com/gesture-space-842e3cdc7102

Unlike pull-down menus that have keyboard shortcuts, pie menu "shortcuts" are exactly the same action a novice takes to use them in the first place, only quicker, so using them in the slow way trains you to use them in the fast way. While selecting from a linear menu with the mouse is a totally different action than selecting a menu shortcut with the keyboard.

Ben Shneiderman introduces Don Hopkins' work on pie menus in Spring 1989 on a Sun Workstation, running the NeWS window system:

https://www.youtube.com/watch?v=8Fne3j7cWzg

After an 1991 intro by Ben Shneiderman we see the older 1989 demo by Don Hopkins showing many examples of pie menus on a Sun Workstation, running the NEWS operating system.

This is work done at the Human-Computer Interaction Lab at the University of Maryland.

A pie menu is a menu technique where the items are placed along the circumference of a circle at equal radial distance from the center. Several examples are demonstrated on a Sun running NeWS window system, including the use of pie menus and gestures for window management, the simultaneous entry of 2 arguments (by using angle and distance from the center), scrollable pie menus, precision pie menus, etc. We can see that gestures were possible (with what Don call "mouse ahead" ) so you could make menu selections without even displaying the menu. Don uses an artifact he calls "mousee" so we can see what he is doing but that extra display was only used for the video, i.e. as a user you could make selections with gestures without the menu ever appearing, but the description of those more advanced features was never published.

Pretty advance for 1989... i.e. life before the Web, when mice were just starting to spread, and you could graduate from the CS department without ever even using one.

This video was published in the 1991 HCIL video but the demo itself - and recording of the video - dates back to 1989 at least, as pictures appear in the handout of the May 1989 HCIL annual Open House.

The original Pie Menu paper is Callahan, J., Hopkins, D., Weiser, M., Shneiderman, B., An empirical comparison of pie vs. linear menus; Proc. ACM CHI '88 (Washington, DC) 95-100.

Also Sparks of Innovation in Human-Computer Interaction, Shneiderman, B., Ed., Ablex (June 1993) 79-88. A later paper mentions some of the more advanced features in an history of the HyperTies system: Shneiderman, B., Plaisant, C., Botafogo, R., Hopkins, D., Weiland, W., Designing to facilitate browsing: a look back at the Hyperties work station browser Hypermedia, vol. 3, 2 (1991)101-117.

PS: For another fun historic video showing very early embedded graphical links (may be the 1st such link) + revealing all the links/menu items + gestures for page navigation

• HCIL Demo - HyperTIES Browsing

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

https://news.ycombinator.com/item?id=11319498

DonHopkins on March 19, 2016 | parent | context | favorite | on: Motion Design Is the Future of UI

User interfaces should always be able to lead, follow, or get out of the way. Animation should never delay interaction, and it should never interfere with gestures and mouse-ahead (or whatever the input device is).

The user should never have to wait for animation to finish before they're able to do something, and the interface should never be disabled during animation, or ever ignore the user's input under any circumstances.

User input should always pre-empt and interrupt feedback and animation.

The interface should always support quick gestures (mousing ahead, touching ahead, or whatever), without ever requiring the user to pause and wait, or focus their attention on the screen to watch the animation play out before they know it's safe to make the next move.

I developed a gestural pie menu tabbed window manager for the NeWS window system in 1990, which supported mousing ahead, suppressing the pie menu display and pop-up animation until you stopped moving, showing light weight feedback on the overlay plane, and executing commands instantly without any animation or even popping up the menu, when you make a smooth quick gesture without hesitating.

NeWS Tab Window Demo:

https://www.youtube.com/watch?v=tMcmQk-q0k4

https://donhopkins.com/home/movies/TabWindowDemo.mov

Transcript of the relevant part of the demo:

Now you can press the right button to pop up a pie menu on the tab or on the frame itself. And that has commonly used commands like front and back in mnemonic directions. Back is down, and front is up.

When you make a menu selection by mousing ahead, it doesn't display the menu.

As long as you're moving, it suppresses the menu display.

And it gives you feedback on the overlay plane of the slice that you're in, and the label of that slice, so you can actually see what you're going to get before you choose it without even seeing the menu itself.

And when you wait, it pops up the menu once you stop moving.

So if you waste some time by just waiting around, it will waste a bit more time by giving you some stupid animation.

And this is meant to be negative reinforcement, to encourage you to mouse ahead.

The sub-menu pops up. This is "move to" which is unconstrained move.

You can always get that from the tab by mousing left and right.

That's an easy gesture. Just quickly...

Or mouse there and wait. There it is. It pops up the one you're at first.

This is constrained horizontal move.

And this is constrained vertical move.

So constrained horizontal... We'll wait.

Constrained vertical...

So, I mean, once you're there, and you know what you want, why wait?

This is "beam me up": put it in the next layout position. To tidy the windows.

So, if you've clicked the menu up and haven't moved, it will just spin it, because it's confused, and doesn't know what you're going to do.

----

In other words: As it pops up and scales up the round menu, it also tilts it along the axis perpendicular to the direction of movement to reinforce the selected direction, or spins around the center if you haven't moved to show no direction is selected.

And you only ever see any animation if you actually stop moving -- once you make a selection, the command always executes or the submenu always activates immediately.

You can mouse ahead smoothly through multiple levels of sub-menus, without popping any of them up or seeing any animation, as long as you never hesitate.

By "lead, follow, or get out of the way", I mean that pie menus can lead novice users by giving them feedback and animation when they pause, follow intermediate users who move in the right direction then pause for the feedback to make sure they got it right, and get out of the way of expert users who know the right direction and can quickly articulate gestures without pausing or waiting for feedback.

----

Here's another demo showing pie menus, mouse ahead gestures, and display pre-emption in SimCity:

X11 SimCity Demo:

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

----

And here's a really old demo from June 1986 of the "uwm" window manager for the X10 window system, that I hacked to support pie menus with mouse-ahead and display pre-emption.

X10 Pie Menu Window Manager:

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

---

More info here:

The Design and Implementation of Pie Menus -- Dr. Dobb's Journal, Dec. 1991:

https://donhopkins.medium.com/the-design-and-implementation-...

joeblubaugh
3 replies
5d16h

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.

cyberax
1 replies
5d10h

Basically, you use cursor keys to select the direction. So you can just memorize the paths to the correct items.

Modern console games use the same idea for communication wheels, that are usable from game controllers.

hypercube33
0 replies
3d12h

Great for game controllers and keyboard use but I find them horrible for mouse use, personally. moving a bound mouse cursor around a donut is really awkward when you're using to x or y movement

DonHopkins
0 replies
5d15h

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

llanowarelves
0 replies
5d15h

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

xp84
2 replies
5d18h

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.

hutzlibu
0 replies
5d10h

"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. "

Ahhh ... that's likely a Stilbruch (break of style) my design professor would have exclaimed. Designers hate those and I came to understand why and try to avoid it wherever possible. It is something that can be irritating and bringing in confusion, if suddenly there is a element out of place.

But you can have "highly-recognizable simple fundamental widget types" without breaking the style. It is just harder and of course, a functional ugly design is in my opinion still way better than a good looking broken design. But the goal should be something consistent - in terms of functionality and style.

DonHopkins
0 replies
5d17h

I had an interesting discussion on Twitter with Michael Darius about this very topic recently. He is an "Apple pioneer, skeuomorph & protégé of Steve Jobs" who epitomizes the excesses of aesthetics and branding at the expense of everything else, so I had to call him on his brash claim and ask him some pointed questions, and brought up the User Interface Hall of Shame's review of the QuickTime 4.0 player, as an example of the excesses of skeuomorphism.

https://twitter.com/darius/status/1741188955985604867

Michael Darius @darius 9:06 PM · Dec 30, 2023 22.1K Views:

There is just no reason why an interface should be anything but beautiful.

Don Hopkins @xardox:

Tell that to an airplane pilot who takes the lives of their passengers in their hands every day. Are you really saying that airplane cockpits should be beautiful, at the expense of safe and usable and accessible?

Michael Darius:

Beauty for the sake of beauty is a mistake but beauty for the sake of user enjoyment reduces cognitive dissonance. Don't forget that pilots are people too with emotional needs.

Don Hopkins:

Beauty should take a back seat when it comes to safety, usability, and accessibility, not only in airline cockpits, but in most other interfaces, too. Your statement that "there is just no reason an interface should be anything but beautiful" is extreme and dangerous.

Michael Darius:

An interface is a habitat for a persons soul to dwell. Some habitats are better than others and there some awfully designed habitats out there.

Don Hopkins:

There are many reasons why, and many things more important than beauty. A spreadsheet is more beautiful if it hides the ugly truth about the formulas, relationships, numbers, dependencies, and complexities. Its purpose isn't to be easy on the eyes, it's to be correct.

Are your earpods supposed to be beautiful, at the expense of being comfortable and actually fitting in your ears and not itching and poking and flaking paint and decorations into the holes on your head? You don't need to see them, just hear them.

The shape of your ear canals isn't beautiful, but your earpods have to conform to it nonetheless.

Michael Darius:

I'd sooner fly a luxury airliner with dashboard complexity that has been thought through for me than assume that safety was the tradeoff for getting to fly with simpler controls.

[photos of extremely complex airliner cockpits -- not sure which he's claiming are beautiful or ugly though]

https://twitter.com/darius/status/1741193514032267758

Don Hopkins:

Beauty is in the eye of the beholder, but safety and usability and complexity is scientifically measurable, you can't claim that thinking through safety and usability and complexity always results in beauty. Most people would consider those examples cluttered, complex, and ugly.

ESPECIALLY anyone who subscribes to the school of minimalistic design like iPads exhibit, like hiding scrollbars because they are ugly, even though they tell you how much more there is to scroll, and what to do to scroll to it. Airplanes and spreadsheets need ugly affordances.

Michael Darius:

You can tell when something has been thought through on the inside, just as much as it has on the outside and most of the people who disagree with me in practice have simply never had the opportunity to work with engineers who care more about what is under the hood than what can be seen by the naked eye.

I see no difference between beauty and the reduction in the margin for human error.

[Photo of two children piloting an airplane.]

https://twitter.com/darius/status/1741195625767772529

Don Hopkins:

You just have an extreme personal opinion about beauty if you think removing scrollbars and buttons and even cluttered features from iPad interfaces, and making airplane cockpits look like playschool toys, always equals beauty. Your original statement is extreme therefore wrong.

It's wrong to assume that "There is just no reason why an interface should be anything but beautiful." I'd rather be lazy and safe than wrong and dead because some interface designer though he was smarter than the FAA.

And you're also wrong because you're presuming there is only one definition of beauty: yours. And that it can be measured. It can't. Address that, please.

Michael Darius:

When effort has been put into an interface to simplify a function, the function itself becomes more beautiful. We see this when writing code. If I can perform an operation by writing 3 lines of code instead of 10, the margin for error decreases.

[An image with an example of "Ugly vs Beautiful" code claiming that a one-liner is more beautiful than 6 lines of equivalent code.]

Don Hopkins:

Again, you're pretending that beauty is not subjective, and that you know the one universal definition of beauty, and I would have expected better from you, and even more from a first year art student. Would the Mona Lisa be more beautiful with less paint?

Would the Sistine Chapel be more beautiful with stick figures like an XKCD comic? Get off your high horse of thinking you can define beauty. Especially after championing the overly minimalistic iPad user interface bereft of scrollbars, buttons with text labels, and even features.

Michael Darius:

Here's a quote that sums up Shaker philosophy:

“Don’t make something unless it is both necessary and useful; but if it is both necessary and useful, don’t hesitate to make it beautiful.”

[A photo of a "beautiful" chair.]

Don Hopkins:

But for the n'th time, you've again ignored me when I pointed out you're moving the goalposts from your original outrageously extreme and incorrect statement that "There is just NO REASON why an interface should be ANYTHING BUT beautiful."

Michael Darius:

I'm not ignoring you, I can't keep up with how much you are writing.

Don Hopkins:

Well at least go back and read the words you wrote in your initial tweet and try defending THOSE, instead of trying to move the goalposts and express the one true definition of beauty. I ask you again: define and defend the words you first chose and wrote yourself.

Your original statement is indefensible, so go back and try defending it instead of trying to move the goalposts and pretend you have a monopoly on the definition of beauty.

Your original statement didn't say anything about necessity or usefulness, as I said before. In fact it PRECLUDED them by claiming interfaces should ONLY be beautiful: "There is just NO REASON why an interface should be ANYTHING BUT beautiful." Stop deflecting. Defend THAT.

What exactly do you mean by "NO REASON" and "ANYTHING BUT". Usability and safety are reasons, and something but.

Some random guy:

Sorry to interrupt you guys. How about you two actually go to FAA or some shit and consult with them if it's possible to make a cockpit more beautiful but retain its practicality. I feel like the argument wouldn't go anywhere without trying to do something for real.

Don Hopkins:

You suggest us just walking in the front door of FAA headquarters, waltzing through security, and insisting on a meeting with the heads of the FAA to redesign their interfaces? Should Darius and I drop all we're doing and volunteer our time to do that for free?

Michael Darius:

The images themself do a better job of communicating what I mean by "beauty standards for excellence".

I've never met a designer who didn't feel that their responsibility was to defend beauty standards for excellence and I'm not different.

The mechanics of a jail door might be functional and usable by a door guard but there is nothing beautiful about building more prisons.

Habitats for humanity cares more deeply about the ACTUAL lived experiences people are ACTUALLY having.

[... A side discussion about the definition of beauty, in which Darius channels Deepak Chopra, and I try to get him back on track to defend his own original words, and he stands by his statement but doesn't justify it: https://twitter.com/xardox/status/1741212753056944187 ]

Michael Darius:

If beauty were so subjective then walking through a meadow would feel no different than doing jail time.

Don Hopkins:

Now you're sounding like Deepak Chopra and his quantum faith healing mumbo jumbo hand waving woo woo. I would have expected much more from you. You made a clear unambiguous brash statement using the words NO REASON and ANYTHING BUT. Defend those words.

Michael Darius:

We can agree to disagree.

[...]

The subjectiveness here may not be around the definition of beauty and more around the ‘definition of an interface’. An interface can be defined as ‘the surface between Air and water’.

Don Hopkins:

More woo-woo, Deepak. Address points 1 and 2 which are directly about YOUR WORDS: "There is just NO REASON why an interface should be ANYTHING BUT beautiful." (How many times do I have to quote them back to you before you address them? I must be on #10 by now.)

[...]

Don Hopkins:

Of all those cockpits, which fit your definition of beauty and which don't, and aren't you aware that there are many hard won FAA regulations learned from the study of accidents, mass death, destruction, and human error, that vastly trump your personal opinion of beauty?

Or are you arguing that all iPad interfaces should look like 747 cockpits?

Or do you believe that beauty automatically implies safety, ergonomics, usability, visual unambiguity and perceptibility? Then how do you measure and prove that beauty is not subjective and not in the eye of the beholder and not just your personal opinion?

And what if your personal opinions about beauty happen to require more weight, more expensive, less durable, more bespoke and less modular materials? Do economics not come into the picture, or do you only design interfaces for extremely rich people?

Of course Donald Trump thinks that solid gold toilets in his luxury airliner are beautiful. Do you agree, because you think beauty isn't in the eye of the beholder and he's right, or because you want to make the customer happy no matter how bad their taste and idea of beauty is?

Michael Darius:

In a field where cognitive safety needs to be the priority and a world where user enjoyment reduces cognitive load, it is intellectually lazy to assume that beauty is the tradeoff for ergonomic safety.

Don Hopkins:

The UI Hall of Shame's review of the notorious QuickTime 4.0 player proves the perilous consequences of a UI designer's personal opinions about skeuomorphic beauty trumping usability and ease of use. Were you involved with that, or was it before your time?

http://hallofshame.gp.co.at/qtime.htm

That article should be required reading for aspiring UI designers. Hacker News discussion:

https://news.ycombinator.com/item?id=18212478

My comment in that discussion:

"Apple's long romance with skeuomorphism peaked with Bob Bishop's APPLE-VISION, and went downhill from there." I posted several other comments about VLC's terrible UI, too.

https://news.ycombinator.com/item?id=18219757

Bob Bishop's Apple Vision:

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

[At this point I took it to private DMs.]

Don Hopkins:

Are you familiar with that review and the problems that caused the widespread negative response to the QuickTime 4 Player user interface? Have you taken the time to read the whole article? Were you involved with that product, or was it before your time?

http://hallofshame.gp.co.at/qtime.htm

I have written about it on Hacker News, and compared it to the even worse WinAmp user interface. Other commenters compared them to WinAmp, but I don't believe WinAmp's infinite and easy skinnability is nearly as maliciously terrible or professionally irresponsible as the QuickTime 4 player (I expected SO MUCH MORE from a company like Apple that published Tog's original UI guidelines), or VLC (which is an open source project without any money or professional UI designers).

HN discussion:

https://news.ycombinator.com/item?id=18212478

One of my comments (among several), which includes a thread about VLC:

https://news.ycombinator.com/item?id=18219757

You can see that I actually give a shit enough about VLC to have spend quite a bit of time analyzing the problem and writing up bug reports, but the culture of the project is so insular and "NIH" that they don't give a shit about user interface design. So I have little hope that VLC will ever improve. But at least Apple finally improved their QuickTime 4 Player in response to acceoss-the-board criticism.

A counter example to the rule of thumb that open source user interfaces are terrible is Blender. Especially when you compare it to GIMP (which is like shooting fish in a barrel, but still is an instructive comparison of cultures).

Blender was infamous for its complex non-standard confusing user interface design, but they LISTENED TO THEIR USERS and vastly improved it!

But of course there is no way of getting around the fact that it's an extremely complex tool that's used differently by a wide range of people, so a lot of that complexity is necessary, and you can't just simplify it away and dumb it down without destroying its usefulness.

One thing Blender does have excellent support for is pie menus! And there are some great pie menu editors, which are important because every different Blender user has their own workflow and set of common commands. So Blender users need to customize and define their own pie menus. Just like HyperCard enabled normal users to construct their own task oriented user interfaces.

(Of course Steve Jobs hated pie menus, which is a story I can tell you about later, or maybe you can tell me the Apple side of that story: Why didn't Apple ever adopt pie menus for MacOS or iOS?)

Pie menus have the potential of being both beautiful, efficient, reliable (low error rates), and easy to use, but it takes a lot more design and programming to pull off than a traditional linear menu.

Simon Schneegans is a brilliant user interface designer as well as an accomplished programmer, and he has developed not only beautiful pie menus (for example the Coral and Trace menu he did for his Master's thesis years ago, and he more recent work on Gnome-Pie, Fly-Pie, and the cross platform Kandu pie menus for desktop app launching, window management, text selection, and many other tasks).

The Trace-Menu A short demonstration of a Pie-Menu I developed for my Bachelor thesis.

https://vimeo.com/51073078

The Coral-Menu A short demonstration of a Pie-Menu I developed for my Bachelor thesis.

https://vimeo.com/51072812

The thing about those examples (and his later work) is that the cool graphics don't spoil the underlying good Fitts' Law friendly design -- they actually increase usability and reinforce the gestural navigation user interface metaphor.

His most amazing accomplishment is the WYSIWYG drag-and-drop interactive pie menu editor he designed and implemented for Gnome-Pie, that he's reimplementing across platforms (Linux X11 Gnome, KDE, Wayland Gnome, etc, Windows, and Mac).

Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!

https://www.youtube.com/watch?v=sRT3O9-H5Xs

Fly-Pie is an attractive marking menu for GNOME Shell. Fly-Pie 7 supports GNOME Shell 40+ and brings a completely rewritten menu editor.

I hope this proves to you how important I believe beauty is. but how I also believe it doesn't need to sacrifice usability.

Here's the latest demo of his current project, Kandu: cross platform super customizable pie menus for Linux, Windows, and Mac. I just sent him my old Mac laptop so he can support the Mac desktop well. The way it works is by using Electron with a full screen transparent overlay window, so it can draw the pie menus with html/css/svg/canvas or any other standards based web technologies.

Kando becomes useful for the first time!

https://www.youtube.com/watch?v=7vVdJ9LORAM

With Kando, I am creating an open-source pie menu which runs on Windows, Linux and (eventually) macOS. In the future, you will be able to create your own men...

Michael Darius (excerpts):

[...] Tim Wasko was the designer for the initial QT player and still remains one of the best interaction designers I know." [...]

I don’t consider something unusable or barely usable to be beautiful so if the work hasn’t been put in on the usability side or if something isn’t working it doesn’t matter how beautiful the interface elements themselves are. But in that case what makes it not beautiful is not that the interface elements aren’t beautiful. What makes it not beautiful is that what is under the hood isn’t beautiful and what is under the hood is more often than not not thought through the way it should be.

My definition of ‘beauty’ is inseparable from my definition of functional design:

An interface should go beyond usable, it should delight, create enjoyment, provide a sense of safety and control over one’s environment, it should be beautifully engineered inside and out and when any one of those pieces go missing beauty itself goes missing.

munificent
1 replies
3d22h

I'm a programming language designer, so I think about this stuff all day every day.

I believe you're right that expertise has something to do with it, but I don't think your comment quite connects why consistency leads to expertise.

Consistency is about taking what users already know about a system and compounding that expertise across other parts of the system. When a system is consistent, once I spend the effort to learn X and Y, then I also know Z and W because they'll behave the same way. In an inconsistent system, I can't extract as much value from my existing learning investment.

hypercube33
0 replies
3d12h

I fully agree. it's also how the user takes what they know and making it work for them.

Windows 95 had years of user testing behind it. They'd sit people down who were used to DOS or Windows 3.11 and give them tasks and see where they struggled or where it worked and iterated on it and the talks by the ux teams really stuck with me. every color and design choice was important even the awful but good real background wallpaper colors

throwaway2037
0 replies
5d8h

It’s about letting someone become an expert in your software.

This is brilliantly said. Watching someone, who does not think that they are technical, zoom around Excel is always special to watch.

Microsoft office was always his example.

The Microsoft UI design rules are pretty amazing. The consistency over the years allows people to upgrade every 1-2 years and continue to use their software. (I do not write this a Microsoft fanboi.) The key for each upgrade: Incremental changes to improve the UX. One thing I never understood: When Win 95 introduced the concept of "right click everywhere for properties (and deeper settings/details)", why didn't the design team reject it? After all, it is invisible to user (to indicate right click is possible). It seemed like no one understood right click the first few times they used Win 95.

danielvaughn
0 replies
5d19h

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

PennRobotics
0 replies
5d8h

I have been screwing around with Microsoft C 3.0 in DOS. What a breath of fresh air it is to install Vim for editing and still have nearly all of its modern functionality (macros, syntax highlighting, folding, splits, regex, visual mode) with absolutely NO keystroke changes.

bithive123
29 replies
5d18h

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 frequently changing positions for no apparent reason.

While I'm complaining, my other pet peeve, which unfortunately is only getting worse is: unlabeled icons (often without even tooltips). If I have to google for documentation to know what a button is called, your UI design is bad!

godzillabrennus
16 replies
5d18h

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.

threethree
4 replies
5d16h

Very interesting. Yeah I think bad UI could be a way to gatekeep. 4chan for example has its mostly-unchanged now old-school interface, with its own quote/reply system, which some call an IQ barrier. That plus all the lingo. It typically gives out outsiders (journalists, govt agents, new users etc)

bheadmaster
3 replies
5d10h

4chan for example has its mostly-unchanged now old-school interface, with its own quote/reply system, which some call an IQ barrier

I doubt it would be an IQ barrier, considering the apparent intelligence of many of the posters there. I would rather call it a "normie filter" - the UI is so old-school ("ugly") that "normies", who usually dwell on fancy UI sites like Facebook, Reddit, etc., will consider it lame and avoid it.

I also think this site employs the same filter, whether intentionally or not.

98789992165
1 replies
5d1h

4chan - smart people acting dumb

HN - dumb people acting smart

AJ007
0 replies
4d23h

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 fashion because they are old, they go out of fashion because people outside of the circle begin to wear them.

There are arguments here about about gatekeeping or whether changing UI conventions are good or bad. There is some parts of truth to all of this.

I would make an important distinction. UI/UX design can be quantitatively good or bad. It is measurable if UI sucks or not. That measurement can be, perhaps mistakenly, only taken by new users: how fast did they learn the UI? I would argue it's the advanced users which are more important: how much can an experienced user get done?

To make matters more difficult, most of the UI design we are experiencing is commercial. It is, in fact, not there to improve our output, it's there to make their owners more money. The move toward cloud software has really fucked up the UI/UX of stuff that worked for a long time, like Photoshop. New stuff is continually introduced breaking known workflows.

On the business side I was always very pro-active about building our tools and systems on open source software or at least in a way we could always easily migrate our data to something else. Now I'm in the process of doing it on the personal side. I have minimal interest in using new tools that aren't interoperable, that I can't control the UI/UX workflow. Even something like Signal, that should be open source, really falls flat on this one. Imagining using something (like Snapchat) where the UI is going to switch so they can increase their engagement and increase ad revenue is just horrible. Internet users don't deserve this and don't need it.

Edit: hn's UI is fantastic, and a major reason I'm still here many years later (I don't use reddit)

staunton
0 replies
5d6h

I also think this site employs the same filter, whether intentionally or not.

Definitely intentional.

weinzierl
2 replies
5d4h

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

lcnPylGDnU4H9OF
0 replies
4d22h

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.

CyberDildonics
0 replies
4d21h

Those interfaces were made out neccesity before graphical interfaces existed.

pprotas
2 replies
5d10h

Interesting, after reading your comment I've decided bad UI is subjective. I'm gen z, and never found Snapchat's UI to be confusing, and none of my gen z friends have ever complained about it, either.

They flock to difficult to use interfaces that become an insider feature for young folks to keep their parents out.

This part might be true on a subconscious level (or it might be part of Snapchat's design philosophy), but do you think younger generations really choose apps for this reason on purpose?

beowulfey
1 replies
5d6h

Bad UI is just one that breaks the patterns we're used to. If you're young and learning fresh patterns it doesn't matter as much

asoneth
0 replies
5d3h

Every interface convention was novel at some point. Breaking them doesn't necessarily make a UI bad, just as following them doesn't make it good. It depends on your skill as well as your audience, their expectations, and how experienced they are with the current interface patterns.

But certainly the vast majority of products should not create new or novel interface patterns just as they shouldn't "roll their own" cryptography -- it is almost always unnecessary and unless it is your primary focus it is very likely that what you come up with will be significantly worse than the status quo.

iambateman
1 replies
3d22h

Allow me to introduce you to literally all of the enterprise software I’ve ever seen from previous generations.

Gen Z definitely didn’t invent confusing UI.

lencastre
0 replies
3d21h

I had a German boss who said that Germans who designed the DB interface often had meetings to discuss where users were most likely to click onscreen to perform whatever action, and then move that button to the opposite side and if possible under 3 layers of menus.

thworp
0 replies
5d8h

I think it's all just decreasing neural plasticity and having more routine you need to break.

munificent
0 replies
3d23h

Or more likely explanation for this phenomenon is that for Gen Z people:

1. Snapchat has relatively more people that they want to interact with.

2. The cost of learning a difficult UI is relatively low since they have more spare mental bandwidth since they aren't working full time, raising kids, etc.

So for a younger person, it's worth it to fight a bad UI to get to the social network, but for an older person the trade-off may not be worth it.

busymom0
0 replies
5d17h

I think this has been observed by others too:

Snapchat’s UI Receives Backlash From Users for being too complicated. However, Snapchat’s user experience is not bad. It’s actually an incredibly smart design. Their challenging user experience is what keeps them relevant to their primary target audience: teenagers and millennials.

It keeps the adults out..Snapchat is a safe place for teens. They intentionally made the user interface challenging to grasp in order to make it difficult for adults to use. Most adults would not bother putting up the effort to learn how to use the app, leading to its abandonment. All content is ephemeral with strict limitations on editing. Most content is sent privately, and no content can be publicly rated or compared. Adults would not bother putting up the effort to learn how to use the app, leading to its abandonment. This limits Snapchat’s user base to teenagers.

https://uxmag.com/articles/how-snapchat-and-netflix-break-ux...

esafak
5 replies
5d14h

Hardware companies aren't known for their UX chops.

throwaway2037
3 replies
5d8h

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.

fireflash38
1 replies
4d23h

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.

esafak
0 replies
4d22h

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

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

esafak
0 replies
5d1h

There sure were lots of bells and whistles that impressed my young self but as an adult I've become more of a Bang and Olufsen guy. I had a rich friend that had one and I thought they were pretty cool at the time too. Partly because nobody else nobody else had one.

rubidium
0 replies
5d5h

UX started with hardware, it was just called human factors. And most of what they came up with then gets forgotten today.

weinzierl
2 replies
5d4h

"unlabeled icons (often without even tooltips)"

The worst software I worked with in this regard was CATIA V5. It had not only hundreds of little icons in the UI, but they were also used in the documentation. The manual regularly said things like "Todo X first click [], then [] and finally go to [] to do []."

This is from the very first versions of V5, so many years ago, and hopefully has improved.

albert_e
1 replies
5d3h

... first versions of V5

So "V5" is not "version five" of something?

God.

weinzierl
0 replies
4d23h

5 is the version, but has been the current version for 26 years by now. I should have said the first releases of V5 or whatever they are called.

That's not to say there hasn't been a version 6 at some point, but the most recent version is still 5.

mortenjorck
0 replies
5d17h

Performance is part of design! The best designers will have conversations with developers about the performance implications of the UI they’re proposing, and will help negotiate trade-offs as engineering makes user-facing technical decisions.

heresie-dabord
0 replies
5d

Although not really part of a UI's "design", //talking to the customer// is often overlooked as well.

The single biggest cause of failure in UI design is isolation from the users and their requirements.

Everything else is coding.

9dev
0 replies
3d19h

the home screen layout and app icons frequently changing positions for no apparent reason.

Spotify does this, too. Every morning I listen to the same two news podcasts. And every bloody morning the suggestions in the app shuffle around for no apparent reason. To add insult to injury though, when the app starts, it still shows the layout from yesterday, hangs for a second while it loads, then reorders stuff - and every time I’ll tap on something that moves somewhere else in that exact moment. It’s extremely frustrating.

breadwinner
12 replies
5d18h

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

euroderf
2 replies
5d9h

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.

An exception to this: premium (for-pay) features.

There is a certain To-Do app that does this. Premium commands are visually indistinguishable from freemium commands, so they get clicked a lot and they interrupt the entire experience with nag dialogs.

A serious UI error IMO.

carlosjobim
1 replies
5d6h

It's not an error, it's deliberate.

euroderf
0 replies
5d

It's deliberate AND an error.

verinus
1 replies
5d9h

I disagree. Disabling an action that is not feasible in the current context IS helpful, but ONLY if you provide an explanation on WHY.

UIs that simply disable certain actions without telling me why always infuriate me :(

gpderetta
0 replies
5d6h

Even better[1]: GUIs that hide actions that are not feasible.

[1] and by better I mean worse.

moring
1 replies
5d8h

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.

Why not grey out these menu items, but still show the exact same message when you click them? That seems to be the best of both worlds to me.

breadwinner
0 replies
5d4h

Because users are accustomed to grayed out items not responding to mouse clicks, so they will never click it.

arcanemachiner
1 replies
5d15h

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

breadwinner
0 replies
5d14h

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.

nirimda
0 replies
5d8h

I used to use a lot of Gtk+ apps, where the menu item was disabled, but all this meant was that it was shown greyed out. In fact, as far as the toolkit was concerned it was still active and still sent a message to the app, and the app was supposed to respond to the message and inform the user about why the action was presently unavailable. I think that was a good choice at the time, because a menu was a stateful bit of UI (clicking the menu item closes the menu), so a fore-warning that the activity is unavailable might help me remember "oh, I forgot to ..." before I see the message, but I can still try anyway and find out what I didn't know.

Nowadays, I think menu options in user interfaces are much rarer, and complex stateful applications are usually HTML web programs where the disabled flag is a hint to the web browser to reject the interaction. Some of these web programs color submit buttons in a washed-out version of the normal color until the form is fully validated, but they will report the reason (to a greater or lesser utility) when clicked - such a widget is not formally disabled to the computer engineer, it's just presented to look like one. I find this subtle distinction frustrating, because it represents an ambiguity of thought that makes precise conversation difficult. Why should a widget ever reject interaction? A widgetset/toolkit is just a medium for dialog between a user and the developer, and they should always be allowed to communicate. A software developer should be able to say "hi widget set, please let the user know this button doesn't make sense at the moment" but they should not be allowed to say "hi widget set, if the user wants to tell me something - i don't want to know it, just throw it away. we're not on speaking terms" (They could, of course, completely ignore the user, but it's intuitively obvious that they shouldn't completely ignore the user. Most developers intuitively want to communicate the reason for the error if they know it's possible for a button to be clicked when they can't handle it, but they often get frustrated because the UI designer didn't clearly indicate to them how they should communicate errors - but perhaps they them what they shouldn't do and now they are stuck).

I liked the option 5 mockup in the link, although I'm not so sure it works for actions (like shooting) so much as state toggles (like activating the weapon). I do strongly disagree with the reasoning at the end of the page "it's okay to break the rules for a piece of software that people often use", because it's 100% a case of "rules for thee but not for me". Aside from the fact that I might have been using Outlook until I changed jobs to a new one (and there's a lot of people who only use Gmail unwillingly/primitively and attempt to use the phone and Teams and Slack and meatspace for their communication needs), it's exactly the most commonly used programs that set the norms for users and software developers. We know how to communicate because we imitate previous dialogues. If the most commonly used programs get to break the rules because some of the people who use them use them dozens of times a day whereas others only want to use the features once a week or two and only manage to use them once a month or so, then the members of both parties will come to the view that cryptic software is fine - one because they use it all the time and have no problem, and the other because they see that hard-to-understand software is highly regarded. And so the designer of a widget designing tool will say "no, it's fine for the widget to show only when it's available, because the people who use this widget-designing software will almost always be using it daily, and they'll only have to learn it once at the beginning of their career". Are they correct? Who knows. At this point it's just a position in the design space by the user interface designer.

La-Douceur
0 replies
4d20h

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

KineticLensman
0 replies
5d2h

Update: Read more about this in this article

I read the article (TL;DR it describes a bond car that lets Bond select a weapon only to then give him an error message saying 'ammunition not loaded', and then considers how this should be handled from a UI perspective).

Thinking about the overall UI guidelines topic, the bond article misses an obvious point - that cars already have familiar mechanisms for displaying the status of consumables such as fuel, oil and battery: gauges on the dashboard. Applying the consistency guideline, Q could have installed an ammo gauge, and the 'backfire' button would then be permanently available. After all, Bond might still wish to deploy the gun for effect, e.g. to intimidate someone, even if he knows that there isn't in fact any ammo.

infotainment
10 replies
5d20h

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.

naasking
3 replies
5d18h

Add a tooltip on disabled inputs.

o11c
1 replies
5d13h

Tooltips seem to have gone out of style in this touch-first world.

Good UIs still use tooltips, you just have to click or drag when in touch mode.

There's also the awkward problem of most native tooltips being plain-text-only, when text is not actually sufficient for every problem (such as international text). And emulated "tooltip" widgets are slow, buggy, etc.

saratogacx
0 replies
5d

From what I've noticed, the touch-friendly replacement for tooltips, for elements like form entry, is the info icon (the circle with the i in it). I actually find this to be even more useful than the tooltip (when space allows) because I know there is more context I can get at a glance.

DonHopkins
0 replies
5d18h

A thousand times this! All disabled menu items and inputs should always have a tooltip or other means of explaining why they are disabled and what to do to enable them, with no exceptions.

eviks
2 replies
5d8h

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.

No, it's better to prevent a mistake and offer immediate explanatory feedback why something is incorrect. For example, the answer to "why can't I type text here??" would be a message explaining that no text is allowed, only numbers.

whycome
1 replies
5d3h

Or, as is possible on mobile, make the input mode change to numbers-only

eviks
0 replies
5d2h

Yes, and make your now useless alpha keys into a perfectly usable numpad so you don't have to use the worse horizontal numbers row or shift your hand to the actual numpad!

uio 123

jkl 456

m,. 789

pvorb
0 replies
5d18h

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.

ivan_gammel
0 replies
5d19h

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
0 replies
5d19h

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.

joshuaheard
9 replies
5d19h

"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.

ShadowBanThis01
7 replies
5d18h

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.

nox101
4 replies
5d17h

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 >:(

rrr_oh_man
1 replies
5d15h

That is only to keep you busy and engaged

esafak
0 replies
5d14h

I just engaged the close button.

bluGill
0 replies
5d15h

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)

ShadowBanThis01
0 replies
5d12h

I actually bring this up when they ask me again. "Didn't I just enter that?"

akavi
1 replies
5d17h

Or its twin cousin: forcing me to login after updating my password.

Cockbrand
0 replies
5d14h

I assume that this is to help the user memorize their new password. I know we on HN all use password managers, but most people out there don’t.

pugworthy
0 replies
5d13h

Right. And if I type in "Corvallis", ask me "Oregon or Montana?" If I type in "97330" just skip the rest.

georgeecollins
8 replies
5d20h

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.

quickthrower2
0 replies
5d18h

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

projektfu
0 replies
5d19h

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.

p1necone
0 replies
5d19h

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.

leetrout
0 replies
5d20h

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.

ivan_gammel
0 replies
5d19h

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.

ebiester
0 replies
5d20h

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

JusticeJuice
0 replies
5d14h

+1, consistency above everything is a very common trap new designers fall into. Humans are messy.

Jtsummers
0 replies
5d19h

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.

bbor
6 replies
5d20h

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
1 replies
5d19h

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
0 replies
5d19h

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.

sib
0 replies
5d19h

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.

marapuru
0 replies
5d9h

This post also reminded me of Nielsens' Heuristics. I can still recall them by heart and never heard of Shneiderman.

I can't shake the feeling that Nielsen (& Norman) simply marketed and productized their principles way better.

jonstewart
0 replies
5d19h

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

DonHopkins
0 replies
5d18h

Donald Norman and Ben Shneiderman are old friends and colleagues.

https://www.nngroup.com/news/item/hci-pioneers-photos/

NN/g News; HCI Pioneers Photos; Announcements; September 8, 2015

Professor Ben Shneiderman (University of Maryland) is one of the founders of the discipline of human-computer interaction (HCI) and has produced breakthrough research and influential textbooks since the early 1980s. He is also an accomplished photographer from a family of world-class photographers. Dr. Shneiderman has now released a website that collects many of his photographs from the last 32 years of the field's other pioneers, including Jakob Nielsen and Don Norman. It's amazing how young they look in the early photos :-)

https://hcipioneers.wordpress.com/

Shneiderman's comment on launching this history site: "My goal is to make HCI more visible and tell our history more widely. I think HCI designs have had as much impact as Moore’s Law in bringing the web and mobile devices to the world."

Since this is a photohistory, it's much more approachable than most history sites. Well worth perusing for anybody with an interest in where we come from.

----

Ben Shneiderman coined and defined the term "Direct Manipulation":

http://www.csc.kth.se/utbildning/kth/kurser/DH3050/hcihist11...

https://news.ycombinator.com/item?id=11365359

DonHopkins on March 27, 2016 | next [–]

Wow, Ben Shneiderman looks so young in that photo. He's still hard at work making computers easier for people to use, and he just published a major update to his classic book, "Designing the User Interface: Strategies for Effective Human-Computer Interaction", which just went to the printers and will be available on April 26. [1]

I enjoyed working with him at the University of Maryland Human Computer Interaction Lab, and the experience deeply influenced everything I've done since.

Ben is the human who suggested the field be called "Human Computer Interaction" instead of "Computer Human Interaction", to put humans first.

He defined the term Direct Manipulation [2] as:

1) continuous representation of the objects and actions,

2) rapid, incremental, and reversible actions, and

3) physical actions and gestures to replace typed commands.

He also came up with the blue underlined hypertext link, as well as embedded graphical links [3] for the "HyperTIES" system [4].

Here's a paper I published when I was at HCIL, about a visual PostScript programming environment that featured "direct stack manipulation": "The Shape of PSIBER Space - October 1989". [5]

Ben's an avid photographer, and has published this photo history of SIGCHI conferences. [6]

[1] http://www.amazon.com/Designing-User-Interface-Human-Compute...

[2] https://en.wikipedia.org/wiki/Direct_manipulation_interface

[3] https://www.youtube.com/watch?v=fZi4gUjaGAM

[4] http://www.cs.umd.edu/hcil/hyperties/

[5] http://www.donhopkins.com/drupal/node/97

[6] http://www.sigchi.org/photohistory/lib_viewer.jsp?lib=chi

----

Ben Shneiderman founded the University of Maryland Human Computer Interaction Lab, but instead of calling it "Computer Human Interaction" like CHI, he put Humans first instead of Computers.

https://news.ycombinator.com/item?id=35736775

*

4 points by DonHopkins 8 months ago | root | parent | prev | next [–]

That's a point Ben Shneiderman insisted on making in 1983, when he named his "Human Computer Interaction Lab" at the University of Maryland HCIL instead of CHIL, where I worked with him from 1986-1990. Go Terps! ;)

Do you have any citations of European or other labs using that human-first convention before 1983?

University of Maryland Human–Computer Interaction Lab:

https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...

Ben Shneiderman:

https://en.wikipedia.org/wiki/Ben_Shneiderman

Ben also coined the term "Direct Manipulation", and came up with the design of making links blue for the early HyperTIES hypermedia system we developed at HCIL.

https://en.wikipedia.org/wiki/Direct_manipulation_interface

Revisiting why hyperlinks are blue (blog.mozilla.org):

https://blog.mozilla.org/en/internet-culture/why-are-hyperli...

https://news.ycombinator.com/item?id=29897811

https://news.ycombinator.com/item?id=29921532

Ben Shneiderman recalled that "Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project".

Hypertext on Hypertext CACM1988:

https://www.youtube.com/watch?v=29b4O2xxeqg

30 YEARS AT THE UNIVERSITY OF MARYLAND’S HUMAN-COMPUTER INTERACTION LAB (HCIL). (2013) By Ben Shneiderman, Kent Norman, Catherine Plaisant, Benjamin Bederson, Allison Druin, Jennifer Golbeck:

http://interactionsdev.acm.org/archive/view/september-octobe...

One attraction of the University of Maryland was its strong psychology department. My computing colleagues were intrigued by my early attempts to use empirical techniques to study programmers as they wrote, modified, or debugged programs. These crossover ideas caught the attention of Azriel Rosenfeld (1931–2004), a world leader in computer vision, who was forming an interdisciplinary Center for Automation Research (CfAR). He led the Computer Vision Lab and invited me to form a Human-Computer Interaction Lab when he launched CfAR in 1983. In a campus reorganization, HCIL became a unit in the Institute for Advanced Computer Studies and eventually became jointly managed with the iSchool.

Rosenfeld's invitation advanced my efforts by at least five years, giving credibility to the "marriage of computer science and psychology," which I described in my 1980 book, Software Psychology. Gaining credibility was important, as this was still a time when many computer scientists were unsure about the value of psychological studies of programmers and database systems' users, and even the growing field of interactive computer systems. The term human-computer interaction (HCI) was still novel, but I insisted on putting the human first, as opposed to the ACM's choice of computer-human interaction to make a more pronounceable name, "CHI."

Ken Perlin:

https://en.wikipedia.org/wiki/Ken_Perlin

Ken Perlin's Blog:

http://blog.kenperlin.com/?p=237

Human first (May 29th, 2008)

I spent the day today at the annual end-of-year symposium of the Human Computer Interaction Lab (HCIL) at the University of Maryland. All three of the Lab’s successive directors – Ben Shneiderman, Ben Bederson and Allison Druin – were there, and they are all good friends of mine. Ben Shneiderman founded the lab in 1983. He is one of the fathers of the field of HCI research, and is a font of wisdom on many subjects. Ben Bederson, with whom I’ve been friends since he was in grad school, took over the lab directorship in 2000. Allison, who is married to Ben Bederson, became the lab’s director in 2006. I actually know Allison the longest of the three. I have had lots of time to talk with all three of them in the last twenty four hours, which has been great fun.

The wonderful thing about the HCIL, as Allison pointed out today, is that it puts the “human” first. Much of computer science research seems to forget that there are such things as humans. Instead it seems to be a quest for a kind of abstract algorithmic purity, as though computer science were merely a branch of mathematics. The HCIL people have been way ahead of the curve in recognizing that the real power of computers comes when we find ways to interweave that power with the complementary power of the human mind. Computation is indeed enormously powerful, but computation that augments human thought is downright transformative. And to achieve that, you’ve got to understand human thought.

This is rather tricky for many academics, because it requires bridging the large gap in scientific subcultures between computer science on the one hand, and psychology on the other. It’s very hard to get academic recognition when any given reviewer of your manuscript is not going to understand half of what you are saying. To me the people at HCIL are visionary because they recognized, a full quarter of a century ago – long before it was fashionable – the need to reconcile these two parts of the problem.

And they are still at it. Only now the world is starting to catch up.

Ben Shneiderman says on June 3, 2008 at 8:12 pm:

Thanks Ken… for your kind words and thoughtful contribution to the 25th Anniversary events…. it’s great to see that our message was heard and received in a warm human way. Sincerely… Ben Shneiderman

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser: By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.

https://donhopkins.medium.com/designing-to-facilitate-browsi...

HyperTIES Discussions from Hacker News:

https://donhopkins.medium.com/hyperties-discussions-from-hac...

An Empirical Comparison of Pie vs. Linear Menus: Jack Callahan, Don Hopkins, Mark Weiser () and Ben Shneiderman. Computer Science Department University of Maryland College Park, Maryland 20742 () Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303. Presented at ACM CHI’88 Conference, Washington DC, 1988.

https://donhopkins.medium.com/an-empirical-comparison-of-pie...

GMoromisato
6 replies
5d12h

The one "rule" I wish it covered is about surfacing/exposing the conceptual model to the user.

If I don't understand the conceptual model of the product, I will always be confused, no matter how well-labeled the icons are. For example, imagine a product that has a "New Configuration" command. What is a "Configuration"? Is it like a template that lets me define other objects? Is it a way to rapidly switch between different sets of options? Is it a container, like a folder?

The UI must be designed so that the user can infer the conceptual model just from exploring the interface. This is not always easy.

Ygg2
5 replies
5d12h

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

nirimda
4 replies
5d9h

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.

moring
2 replies
5d8h

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 (IMHO) best results is: design the conceptual model, then build/change the implementation model to be equal to it.

One example for this strategy that is forever stuck in my head is macOS application folders. The conceptual model is that an application can be moved around like a file, and applications be organized in folders like files. But you also want to run an application by double-clicking it. Instead of what Windows (and then Linux) did with links, menus, installing applications and centrally registering them etc., the implementation was changed to be like the conceptual model. A whole class of errors from inconsistencies just vanished.

Ygg2
0 replies
5d1h

I'd argue the implementation detail is still hidden. You don't know if Applications use FUSE or are WASM containers or docker images or what not.

Interface is a translator between what user understands ("I press button, channel changes") and implementation detail ("rubber dome changing resistivity, ...causing IR signal to be sent", ...).

GMoromisato
0 replies
4d20h

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.

GMoromisato
0 replies
4d21h

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!

nyreed
3 replies
5d1h

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.

jetrink
2 replies
5d1h

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.

yshklarov
0 replies
4d11h

One problem with this: People often learn to touch multiple targets quickly in sequence, because one touch event predictably pops up the target for the next event.

murermader
0 replies
4d22h

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

kazinator
3 replies
5d18h

Where are the apps shipped by umn.edu?

DonHopkins
1 replies
5d16h

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

https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...

Or Ben Shneiderman's home page:

https://www.cs.umd.edu/users/ben/

One app that the UMD Human Computer Interaction Lab shipped in several versions was HyperTIES, which was used to implement “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference, which influenced Tim Berners-Lee to make hypertext links blue:

The Interactive Encyclopedia System:

https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_S...

HyperTIES Discussions from Hacker News:

https://donhopkins.medium.com/hyperties-discussions-from-hac...

Don Hopkins sent the following message at 10:07 AM, AUG 28, 2021

Why are hyperlinks blue?

Hello Elise. Here is some information about why hyperlinks are blue, from Ben Shneiderman’s answer to a question I asked him about the origin of the term “hyperlink”. I think your belief that HyperTIES was not the first instance of blue hyperlinks because it used cyan links is splitting hairs, and a “No Blue Scotsman” argument, especially since Tim Berners-Lee told Ben Sheniderman at the time that he was influenced by Ben’s design as he saw it in the HyperTIES-based “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference at the University of North Carolina. Ben describes the color as “light blue”, which he chose from the limited palette available on PCs at the time, based on controlled experiments he and his students performed comparing user comprehension and recollection.

https://news.ycombinator.com/item?id=28317104

HI Don (and Jack Gilmore),

Thanks for including me in this conversation.

I do not have a claim for the term “hyperlinks” and don’t know when it came into use. My claim is for the visual interface for showing highlighted selectable links embedded in paragraphs. This is what we called embedded menu items in that I think is an influential paper on the topic, which was peer-reviewed and published in the CACM in April 1986.

https://dl.acm.org/doi/10.1145/5684.5687

http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf

While Engelbart had shown a list that could be selected by pointing and clicking in 1968, I claim the idea of embedded highlighted selectable text in paragraphs. This was implemented by grad student Daniel Ostroff and described in:

Ewing J, Mehrabanzad S, Sheck S, Ostroff D and Shneiderman B (1986), "An experimental comparison of a mouse and arrow-jump keys for an interactive encyclopedia", International Journal of Man-Machine Studies, Jan., 1986, Vol 24, pp. 29-45.

[Abstract] [BibTeX] [DOI]

Ostroff D and Shneiderman B (1988), "Selection devices for users of an electronic encyclopedia: an empirical comparison of four possibilities", Information Processing and Management, Nov., 1988, Vol 24(6), pp. 665-680.

[Abstract] [BibTeX] [DOI]

I think the 1988 paper was the earlier study, but the publication took a while.

My students conducted more than a dozen experiments (unpublished) on different ways of highlighting and selection using current screens, e.g. green screens only permitted, bold, underscore, blinking, and I think italic(???). When we had a color screen we tried different color highlighted links. While red made the links easier to spot, user comprehension and recollection of the content declined. We chose the light blue, which Tim adopted.

His systems with embedded menus (or hot spots), where a significant user interface improvement over early systems such as Gopher. But Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project that we used Hyperties to build for the July 1988 CACM that held the articles from the July 1987 Hypertext conference at the University of North Carolina. The ACM sold 4000 copies of our Hypertext on Hypertext disks.

Our history is here:

https://www.cs.umd.edu/hcil/hyperties/

and the video is very helpful in showing the design we used, which is what I think Tim built on for his WWW prototypes.

https://www.youtube.com/watch?v=29b4O2xxeqg

So in summary, I don’t know who coined hypertext, but I do think our work visual and interaction design was influential.

Our Hyperties system was picked up by Cognetics Corporation (around 1987) who made a modestly successful commercial run with it, doing dozens of corporate projects, most notably the Hewlett-Packard user manual for their Laserjet 4 was distributed as a Hyperties disk.

Hyperties was the name we shifted to after we got a stop and desist order from a lawyer because our TIES (The Interactive Encyclopedia System) conflicted with an existing product. By then “hyper” was a growing term.

Let me know if this helps, and what other questions you have…. Ben

----

HCIL also shipped various treemapping applications:

https://en.wikipedia.org/wiki/Treemapping

Area-based visualizations have existed for decades. For example, mosaic plots (also known as Marimekko diagrams) use rectangular tilings to show joint distributions (i.e., most commonly they are essentially stacked column plots where the columns are of different widths). The main distinguishing feature of a treemap, however, is the recursive construction that allows it to be extended to hierarchical data with any number of levels. This idea was invented by professor Ben Shneiderman at the University of Maryland Human – Computer Interaction Lab in the early 1990s. [21][22] Shneiderman and his collaborators then deepened the idea by introducing a variety of interactive techniques for filtering and adjusting treemaps.

https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf

https://treemapart.wordpress.com/

bluGill
0 replies
5d15h

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

subroutine
0 replies
5d18h

Universities teach students about a lot of things they don't actually create themselves.

andsoitis
2 replies
5d3h

Nielsen's 10 usability heuristics for user interface design gives a good north star:

1. Visibility of system status

2. Match between system and the real world

3. User control and freedom

4. Consistency and standards

5. Error prevention

6. Recognition rather than recall

7. Flexibility and efficiency of use

8. Aesthetic and minimalist design

9. Recognize, diagnose, and recover from errors

10. Help and documentation

https://www.nngroup.com/articles/ten-usability-heuristics/

lcuff
1 replies
5d2h

The contrast between this Nielsen-Norman (NN) page and the OP page is marked. The NN page is much easier to absorb the information. More succinct, way better page layout.

Both articles have information/direction worth heeding, but there is irony in the fact that the OP page adopts same-text size and paragraphing conventions of yesteryear that the NN page does away with.

It's also frustrating that Hacker News doesn't pay attention to some of the information. In creating an edit to an existing post, the feedback after clicking on the 'update' button is not as clear as it should be. (It's a screen redraw, I guess).

btbuildem
0 replies
3d23h

Are we looking at the same thing?

The NN pages are cluttered with navigation to other areas, links for "more this and that", related courses, etc. Everything is in six different font sizes, there are variously-coloured illustrations that pull at strenuous off-topic metaphors... it's a mess.

In contrast, the OP page is clear, simple, sticks to the topic at hand. Easy to read typography, eight paragraphs for the eight rules.

stronglikedan
1 replies
5d3h

9. Stop popping in something else in place of what I'm just about to select, causing me to select the wrong thing! (I know this maybe violates or can be mitigated by some of the previous rules, but it is the one thing that drives me absolutely bonkers, and I consider it to be a particularly egregious mistake.)

tech2
0 replies
5d2h

Jira and the Unassigned/Automatic selection when trying to change a story assignment, I'm looking at YOU in particular!

pugworthy
1 replies
5d13h

I inherited an app from someone a few years ago at work, and for whatever reason, the developer loved a gray themed UI. Gray buttons. Gray text entry. You never knew what was disabled and just gray for fun. Needless to say that changed...

hannofcart
0 replies
4d16h

Am certainly not the dev you inherited the project from but I used to prefer an all gray palette too on projects that didn't afford me any design help.

This was because I'm colour blind (red green) and find it near impossible to keep track of what signal I may be sending using one of the other colours while I am likely oblivious to that colour even being used.

So I used to use an all gray palette as a placeholder till real designers who could properly see colours and understood significance of each could come in and "colour in" the UI.

ozim
1 replies
5d11h

One thing is that some times some things have to be made harder for end users good or for business rules protection.

It is sometimes hard to explain but as an example - delete confirmation - it gets in the way of user because user wants to delete stuff and be done with it. Preventing accidental deletes is more important than any specific user convenience.

Keep in mind this is most generic example I came up with on the spot. There are more complex scenarios that are complex for the same reasons. But I find people trying to remove such fences even if they don’t know why they’re there. Claiming simplicity and user convenience as golden rule.

Kranar
0 replies
5d10h

I really detest that principle. For the design of my software I make almost every action reversible and avoid at all costs confirmation dialogs or anything that makes it seem like the user could be at fault for something if they choose incorrectly.

I also work on financial trading software so I do need to think a great deal about user error and the best principle I have found is to never create a situation where a confirmation is needed.

Among new users it creates anxiety and indecisiveness, and among experienced users they just ignore it and it's noise to them. All confirmation dialogs do is make the developer/designer punt responsibility off to the user for what is generally a bad design decision.

guardian5x
1 replies
5d8h

I would like to add: "Live up to expectations" in a sense that there are so many Websites or UIs there, that most users have some sort of expectations, on where to find the menu, how to go back etc. How this and that buttons should behave. Even though, you might have a great idea, it might just confuse the user, if it is totally different than what the "standard" is.

whycome
0 replies
5d4h

Everyone wants to create new expectations and hope they become the new standard

bob1029
1 replies
5d17h

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 is some workflow implementation with a # of discrete steps. Our criteria for the scope of a step is guided by a dark and mystical process wherein we all argue about the business for a few hours and then sketch out some prototypes. One trick is to design these with lego-like reuse in mind. Oftentimes, the business will have the exact same view used across a wide range of activities.

rrr_oh_man
0 replies
5d15h

Care to share the product?

Stenzel
1 replies
5d19h

Title should say screen design, for general UI these are quite useless, especially if your UI is physical.

madeofpalk
0 replies
5d18h

I think these guidelines are pretty translatable for any kind of user interface, including physical.

Machines should have consistent physical controls that make it readily apparent whether it's a button to press or a knob to turn. They should prevent errors like an exposed blade cutting my hand off.

zubairq
0 replies
4d10h

I always think of the one golden rule of interface design to be:

Don’t make me think!

zestyping
0 replies
4d20h

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.

wouldbecouldbe
0 replies
5d18h

The Golden Rules of obvious Utopia.

I think most of us won't disagree with these rules.

Yet also most devs will have worked on interfaces that break these rules often. Not because we didn't understand or didn't want, just that the cost was too high at that point.

For instance reversibility is very difficult and only possible if the datastructure under the application is build up with this in mind. Or take preventing errors, often it's very difficult and costly to know exactly what errors are, and ever more complicated to provide perfect feedback to a user in their own language.

tsunamifury
0 replies
5d11h

The big one missing is “design symmetrically”. The way you go in is also wheee you go out. Where you turn something on is also where it’s turned off. Swipe up so swipe down and on and on.

This is so obvious yet so many completely fail to do it.

stevage
0 replies
5d20h

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.

oivviopolite
0 replies
5d12h

1. Set your page margin to 0px.

lxe
0 replies
4d

These rules were already breaking apart even in 2013. We lost consistency with the advent of CSS-based UI, where design had free reign. This devolved into every site and app doing its own thing for UX. Now we have interfaces with zero visual affordances and you have to basically discover by trial end error what each swipe/long-press/drag/click does.

Funny enough, with flash gaining traction in the early 2000s, there was a huge barrage of "mystery meat navigation" which was criticized heavily by the UX community, and it ended up falling out of favor for some time. Yet, we're back to "mystery meat navigation" yet again.

eviks
0 replies
5d9h

Looks like a good list, though missing are customization (technically you could tuck customization into "user control", but it's too important for that) and composability (which also helps with 8 memory load - you can remember 'primitive' actions that compose well easier, and that memory would be reinforced with repetition)

dmalik
0 replies
5d17h

A lot of these rules are taken care of by design systems these days. If you're off developing your own design system or creating custom components the laws of UX are far more useful.

https://lawsofux.com/

Here are a few that relate to laws:

Strive for consistency - Jakobs law

Reduce short-term memory load - Millers Law

dang
0 replies
5d18h

Related:

Eight golden rules of user interface design - https://news.ycombinator.com/item?id=36652355 - July 2023 (1 comment)

8 Golden Rules of Interface Design - https://news.ycombinator.com/item?id=233654 - July 2008 (7 comments)

causality0
0 replies
5d16h

0. Don't change things just for the sake of justifying your employment as a UI designer.

The software I use with the best UI is also the software I use with the oldest UI.

bluSCALE4
0 replies
5d17h

I think undo and history is vastly underrated. Lots of systems have activity logs but not many associate anything actionable to them.

beefield
0 replies
5d7h

I think it would be important to understand the distinction between two types of applications, I call them "utilities" and "tools" here.

Utilities are things that should be designed with the current typical paradigm of simplicity and discoverability to extreme. I should not need to read user manual for my toaster or microwave.

Tools then, should be pretty much the opposite. It should be fine and expected to invest some time to learn the efficient and safe usage of the tool. There is no reason to have a intuitive interface on your tool, as long as it is efficient after you did your training. Vim is way better editor than notepad, but I don't think anyone praises it for the intuitively easy to use.

And the peeve here is of course that way, way too often these are confused.

ShadowBanThis01
0 replies
5d18h

It's missing a critical one, which once seemed obvious: Distinguish between static information and controls.

Also, don't HIDE inapplicable controls; GREY THEM OUT. That way people learn

1. They exist 2. Where they reside 3. There's some condition to satisfy before they can be used

Related: Never, never rely on peek-a-boo UI that hides things unless the user accidentally rolls the cursor over them. I'm trying to get shit done, not explore an Advent calendar.

23B1
0 replies
5d18h

9. The actual golden rule: don't create UX that you yourself would find hostile.