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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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":
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]
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.
> 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.
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.
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.
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.
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.
> 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.
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!
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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]
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.
"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.
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.
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.
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.
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.
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.
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:
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
Do you know of any work about how to combine pie menus and keyboard usage? Mousing is very uncomfortable for me, but if a pie menu could be used with a keyboard-attached joystick, it might be a really quick way to work.
Pie menus work well with trackpads and trackpoints (keyboard clitoris), as well as analog and digital 4- or 8-directional joysticks, and even numeric keypads and arrow keys.
If you arrange your menus into 4- and 8-item pie menus, they are uniformly navigable and memorable for many types of input devices including keyboards. Four and eight items are ideal for muscle memory, and also cognitive memory too. So using pie menu layouts that map directly to keyboards and digital joysticks works really well.
The ActiveX pie menus I implemented for Internet Explorer a couple decades ago supported full keyboard navigation:
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
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)
> 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.
> 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
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)
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)
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.
> 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.
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.
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.
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
"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.
Annoying as shit. If I'm trying to log into something with an E-mail address (already a fail, but that's another topic) and password, and I click "forgot password," don't take me to a form where I have to re-enter the goddamned E-mail address I JUST ENTERED.
Or every customer service phone line where the automated system asks for your info (account# or phone#) and then the customer service rep asks again >:(
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.
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.
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.
> 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.
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.
> 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.
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.
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!
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.
> 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.
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)
> 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.
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)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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:
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:
>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.
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.
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 f...
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.
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.
> 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.
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.
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...
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.
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.
To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.
There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that).
But the one option that is rarely used but yields the (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.
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", ...).
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.
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!
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.
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.
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.
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)
172 comments
[ 3.4 ms ] story [ 214 ms ] threadThe one about giving users closure in a sequence of tasks is kind of novel. I like it.
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.
Now that we have more electric steer by wire... maybe.
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
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.
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.
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.
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.
https://en.m.wikipedia.org/wiki/Ben_Shneiderman
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] marapuru ↗ 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.
> 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.
That is just another form of error prevention: in the end erroneous data will not be submitted.
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.
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.
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.
uio 123
jkl 456
m,. 789
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.
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.
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.
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.
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.
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...
https://www.youtube.com/watch?v=AHiNeUTgGkk
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
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.
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/17411956257677725...
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.
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.
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.
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.
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.
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:/...
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
Modern console games use the same idea for communication wheels, that are usable from game controllers.
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.
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
They just respect the fact that people have become experts in using their tools.
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)
Give me an example of a text editor that you concider to have good UI design.
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.
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.
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.
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.
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
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.
most of the time it isn't. the doctor already knows what you told the nurse. (where the doctor doesn't that is bad)
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.
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...
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.
UIs that simply disable certain actions without telling me why always infuriate me :(
[1] and by better I mean worse.
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.
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.
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.
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!
> 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...
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.
Definitely intentional.
HN - dumb people acting smart
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)
> 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?
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.
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.
Gen Z definitely didn’t invent confusing UI.
And they do it for like 20 functions.
https://images3-hu-secure.gs-static.com/products/4096x4096/2...
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.
So "V5" is not "version five" of something?
God.
That's not to say there hasn't been a version 6 at some point, but the most recent version is still 5.
The single biggest cause of failure in UI design is isolation from the users and their requirements.
Everything else is coding.
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.
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 f...
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.
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)
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.
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.
https://lawsofux.com/
Here are a few that relate to laws:
Strive for consistency - Jakobs law
Reduce short-term memory load - Millers Law
The software I use with the best UI is also the software I use with the oldest UI.
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.
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.
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.
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", ...).
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.
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!
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.
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.
This is so obvious yet so many completely fail to do it.