Golden Rules of Interface Design (2013)
cs.umd.edu
cs.umd.edu
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.
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...
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/1741195625767772529
Don Hopkins:
You just have an extreme personal opinion about beauty if you think removing scrollbars and buttons and even cluttered features from iPad interfaces, and making airplane cockpits look like playschool toys, always equals beauty. Your original statement is extreme therefore wrong.
It's wrong to assume that "There is just no reason why an interface should be anything but beautiful." I'd rather be lazy and safe than wrong and dead because some interface designer though he was smarter than the FAA.
And you're also wrong because you're presuming there is only one definition of beauty: yours. And that it can be measured. It can't. Address that, please.
Michael Darius:
When effort has been put into an interface to simplify a function, the function itself becomes more beautiful. We see this when writing code. If I can perform an operation by writing 3 lines of code instead of 10, the margin for error decreases.
[An image with an example of "Ugly vs Beautiful" code claiming that a one-liner is more beautiful than 6 lines of equivalent code.]
Don Hopkins:
Again, you're pretending that beauty is not subjective, and that you know the one universal definition of beauty, and I would have expected better from you, and even more from a first year art student. Would the Mona Lisa be more beautiful with less paint?
Would the Sistine Chapel be more beautiful with stick figures like an XKCD comic? Get off your high horse of thinking you can define beauty. Especially after championing the overly minimalistic iPad user interface bereft of scrollbars, buttons with text labels, and even features.
Michael Darius:
Here's a quote that sums up Shaker philosophy:
“Don’t make something unless it is both necessary and useful; but if it is both necessary and useful, don’t hesitate to make it beautiful.”
[A photo of a "beautiful" chair.]
Don Hopkins:
But for the n'th time, you've again ignored me when I pointed out you're moving the goalposts from your original outrageously extreme and incorrect statement that "There is just NO REASON why an interface should be ANYTHING BUT beautiful."
Michael Darius:
I'm not ignoring you, I can't keep up with how much you are writing.
Don Hopkins:
Well at least go back and read the words you wrote in your initial tweet and try defending THOSE, instead of trying to move the goalposts and express the one true definition of beauty. I ask you again: define and defend the words you first chose and wrote yourself.
Your original statement is indefensible, so go back and try defending it instead of trying to move the goalposts and pretend you have a monopoly on the definition of beauty.
Your original statement didn't say anything about necessity or usefulness, as I said before. In fact it PRECLUDED them by claiming interfaces should ONLY be beautiful: "There is just NO REASON why an interface should be ANYTHING BUT beautiful." Stop deflecting. Defend THAT.
What exactly do you mean by "NO REASON" and "ANYTHING BUT". Usability and safety are reasons, and something but.
Some random guy:
Sorry to interrupt you guys. How about you two actually go to FAA or some shit and consult with them if it's possible to make a cockpit more beautiful but retain its practicality. I feel like the argument wouldn't go anywhere without trying to do something for real.
Don Hopkins:
You suggest us just walking in the front door of FAA headquarters, waltzing through security, and insisting on a meeting with the heads of the FAA to redesign their interfaces? Should Darius and I drop all we're doing and volunteer our time to do that for free?
Michael Darius:
The images themself do a better job of communicating what I mean by "beauty standards for excellence".
I've never met a designer who didn't feel that their responsibility was to defend beauty standards for excellence and I'm not different.
The mechanics of a jail door might be functional and usable by a door guard but there is nothing beautiful about building more prisons.
Habitats for humanity cares more deeply about the ACTUAL lived experiences people are ACTUALLY having.
[... A side discussion about the definition of beauty, in which Darius channels Deepak Chopra, and I try to get him back on track to defend his own original words, and he stands by his statement but doesn't justify it: https://twitter.com/xardox/status/1741212753056944187 ]
Michael Darius:
If beauty were so subjective then walking through a meadow would feel no different than doing jail time.
Don Hopkins:
Now you're sounding like Deepak Chopra and his quantum faith healing mumbo jumbo hand waving woo woo. I would have expected much more from you. You made a clear unambiguous brash statement using the words NO REASON and ANYTHING BUT. Defend those words.
Michael Darius:
We can agree to disagree.
[...]
The subjectiveness here may not be around the definition of beauty and more around the ‘definition of an interface’. An interface can be defined as ‘the surface between Air and water’.
Don Hopkins:
More woo-woo, Deepak. Address points 1 and 2 which are directly about YOUR WORDS: "There is just NO REASON why an interface should be ANYTHING BUT beautiful." (How many times do I have to quote them back to you before you address them? I must be on #10 by now.)
[...]
Don Hopkins:
Of all those cockpits, which fit your definition of beauty and which don't, and aren't you aware that there are many hard won FAA regulations learned from the study of accidents, mass death, destruction, and human error, that vastly trump your personal opinion of beauty?
Or are you arguing that all iPad interfaces should look like 747 cockpits?
Or do you believe that beauty automatically implies safety, ergonomics, usability, visual unambiguity and perceptibility? Then how do you measure and prove that beauty is not subjective and not in the eye of the beholder and not just your personal opinion?
And what if your personal opinions about beauty happen to require more weight, more expensive, less durable, more bespoke and less modular materials? Do economics not come into the picture, or do you only design interfaces for extremely rich people?
Of course Donald Trump thinks that solid gold toilets in his luxury airliner are beautiful. Do you agree, because you think beauty isn't in the eye of the beholder and he's right, or because you want to make the customer happy no matter how bad their taste and idea of beauty is?
Michael Darius:
In a field where cognitive safety needs to be the priority and a world where user enjoyment reduces cognitive load, it is intellectually lazy to assume that beauty is the tradeoff for ergonomic safety.
Don Hopkins:
The UI Hall of Shame's review of the notorious QuickTime 4.0 player proves the perilous consequences of a UI designer's personal opinions about skeuomorphic beauty trumping usability and ease of use. Were you involved with that, or was it before your time?
http://hallofshame.gp.co.at/qtime.htm
That article should be required reading for aspiring UI designers. Hacker News discussion:
https://news.ycombinator.com/item?id=18212478
My comment in that discussion:
"Apple's long romance with skeuomorphism peaked with Bob Bishop's APPLE-VISION, and went downhill from there." I posted several other comments about VLC's terrible UI, too.
https://news.ycombinator.com/item?id=18219757
Bob Bishop's Apple Vision:
https://www.youtube.com/watch?v=CU_qKQL5PVk
[At this point I took it to private DMs.]
Don Hopkins:
Are you familiar with that review and the problems that caused the widespread negative response to the QuickTime 4 Player user interface? Have you taken the time to read the whole article? Were you involved with that product, or was it before your time?
http://hallofshame.gp.co.at/qtime.htm
I have written about it on Hacker News, and compared it to the even worse WinAmp user interface. Other commenters compared them to WinAmp, but I don't believe WinAmp's infinite and easy skinnability is nearly as maliciously terrible or professionally irresponsible as the QuickTime 4 player (I expected SO MUCH MORE from a company like Apple that published Tog's original UI guidelines), or VLC (which is an open source project without any money or professional UI designers).
HN discussion:
https://news.ycombinator.com/item?id=18212478
One of my comments (among several), which includes a thread about VLC:
https://news.ycombinator.com/item?id=18219757
You can see that I actually give a shit enough about VLC to have spend quite a bit of time analyzing the problem and writing up bug reports, but the culture of the project is so insular and "NIH" that they don't give a shit about user interface design. So I have little hope that VLC will ever improve. But at least Apple finally improved their QuickTime 4 Player in response to acceoss-the-board criticism.
A counter example to the rule of thumb that open source user interfaces are terrible is Blender. Especially when you compare it to GIMP (which is like shooting fish in a barrel, but still is an instructive comparison of cultures).
Blender was infamous for its complex non-standard confusing user interface design, but they LISTENED TO THEIR USERS and vastly improved it!
But of course there is no way of getting around the fact that it's an extremely complex tool that's used differently by a wide range of people, so a lot of that complexity is necessary, and you can't just simplify it away and dumb it down without destroying its usefulness.
One thing Blender does have excellent support for is pie menus! And there are some great pie menu editors, which are important because every different Blender user has their own workflow and set of common commands. So Blender users need to customize and define their own pie menus. Just like HyperCard enabled normal users to construct their own task oriented user interfaces.
(Of course Steve Jobs hated pie menus, which is a story I can tell you about later, or maybe you can tell me the Apple side of that story: Why didn't Apple ever adopt pie menus for MacOS or iOS?)
Pie menus have the potential of being both beautiful, efficient, reliable (low error rates), and easy to use, but it takes a lot more design and programming to pull off than a traditional linear menu.
Simon Schneegans is a brilliant user interface designer as well as an accomplished programmer, and he has developed not only beautiful pie menus (for example the Coral and Trace menu he did for his Master's thesis years ago, and he more recent work on Gnome-Pie, Fly-Pie, and the cross platform Kandu pie menus for desktop app launching, window management, text selection, and many other tasks).
The Trace-Menu A short demonstration of a Pie-Menu I developed for my Bachelor thesis.
The Coral-Menu A short demonstration of a Pie-Menu I developed for my Bachelor thesis.
The thing about those examples (and his later work) is that the cool graphics don't spoil the underlying good Fitts' Law friendly design -- they actually increase usability and reinforce the gestural navigation user interface metaphor.
His most amazing accomplishment is the WYSIWYG drag-and-drop interactive pie menu editor he designed and implemented for Gnome-Pie, that he's reimplementing across platforms (Linux X11 Gnome, KDE, Wayland Gnome, etc, Windows, and Mac).
Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!
https://www.youtube.com/watch?v=sRT3O9-H5Xs
>Fly-Pie is an attractive marking menu for GNOME Shell. Fly-Pie 7 supports GNOME Shell 40+ and brings a completely rewritten menu editor.
I hope this proves to you how important I believe beauty is. but how I also believe it doesn't need to sacrifice usability.
Here's the latest demo of his current project, Kandu: cross platform super customizable pie menus for Linux, Windows, and Mac. I just sent him my old Mac laptop so he can support the Mac desktop well. The way it works is by using Electron with a full screen transparent overlay window, so it can draw the pie menus with html/css/svg/canvas or any other standards based web technologies.
Kando becomes useful for the first time!
https://www.youtube.com/watch?v=7vVdJ9LORAM
>With Kando, I am creating an open-source pie menu which runs on Windows, Linux and (eventually) macOS. In the future, you will be able to create your own men...
Michael Darius (excerpts):
[...] Tim Wasko was the designer for the initial QT player and still remains one of the best interaction designers I know." [...]
I don’t consider something unusable or barely usable to be beautiful so if the work hasn’t been put in on the usability side or if something isn’t working it doesn’t matter how beautiful the interface elements themselves are. But in that case what makes it not beautiful is not that the interface elements aren’t beautiful. What makes it not beautiful is that what is under the hood isn’t beautiful and what is under the hood is more often than not not thought through the way it should be.
My definition of ‘beauty’ is inseparable from my definition of functional design:
An interface should go beyond usable, it should delight, create enjoyment, provide a sense of safety and control over one’s environment, it should be beautifully engineered inside and out and when any one of those pieces go missing beauty itself goes missing.
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://www.youtube.com/watch?v=fZi4gUjaGAM
https://news.ycombinator.com/item?id=11319498
DonHopkins on March 19, 2016 | parent | context | favorite | on: Motion Design Is the Future of UI
User interfaces should always be able to lead, follow, or get out of the way. Animation should never delay interaction, and it should never interfere with gestures and mouse-ahead (or whatever the input device is).
The user should never have to wait for animation to finish before they're able to do something, and the interface should never be disabled during animation, or ever ignore the user's input under any circumstances.
User input should always pre-empt and interrupt feedback and animation.
The interface should always support quick gestures (mousing ahead, touching ahead, or whatever), without ever requiring the user to pause and wait, or focus their attention on the screen to watch the animation play out before they know it's safe to make the next move.
I developed a gestural pie menu tabbed window manager for the NeWS window system in 1990, which supported mousing ahead, suppressing the pie menu display and pop-up animation until you stopped moving, showing light weight feedback on the overlay plane, and executing commands instantly without any animation or even popping up the menu, when you make a smooth quick gesture without hesitating.
NeWS Tab Window Demo:
https://www.youtube.com/watch?v=tMcmQk-q0k4
https://donhopkins.com/home/movies/TabWindowDemo.mov
Transcript of the relevant part of the demo:
Now you can press the right button to pop up a pie menu on the tab or on the frame itself. And that has commonly used commands like front and back in mnemonic directions. Back is down, and front is up.
When you make a menu selection by mousing ahead, it doesn't display the menu.
As long as you're moving, it suppresses the menu display.
And it gives you feedback on the overlay plane of the slice that you're in, and the label of that slice, so you can actually see what you're going to get before you choose it without even seeing the menu itself.
And when you wait, it pops up the menu once you stop moving.
So if you waste some time by just waiting around, it will waste a bit more time by giving you some stupid animation.
And this is meant to be negative reinforcement, to encourage you to mouse ahead.
The sub-menu pops up. This is "move to" which is unconstrained move.
You can always get that from the tab by mousing left and right.
That's an easy gesture. Just quickly...
Or mouse there and wait. There it is. It pops up the one you're at first.
This is constrained horizontal move.
And this is constrained vertical move.
So constrained horizontal... We'll wait.
Constrained vertical...
So, I mean, once you're there, and you know what you want, why wait?
This is "beam me up": put it in the next layout position. To tidy the windows.
So, if you've clicked the menu up and haven't moved, it will just spin it, because it's confused, and doesn't know what you're going to do.
----
In other words: As it pops up and scales up the round menu, it also tilts it along the axis perpendicular to the direction of movement to reinforce the selected direction, or spins around the center if you haven't moved to show no direction is selected.
And you only ever see any animation if you actually stop moving -- once you make a selection, the command always executes or the submenu always activates immediately.
You can mouse ahead smoothly through multiple levels of sub-menus, without popping any of them up or seeing any animation, as long as you never hesitate.
By "lead, follow, or get out of the way", I mean that pie menus can lead novice users by giving them feedback and animation when they pause, follow intermediate users who move in the right direction then pause for the feedback to make sure they got it right, and get out of the way of expert users who know the right direction and can quickly articulate gestures without pausing or waiting for feedback.
----
Here's another demo showing pie menus, mouse ahead gestures, and display pre-emption in SimCity:
X11 SimCity Demo:
https://www.youtube.com/watch?v=Jvi98wVUmQA
----
And here's a really old demo from June 1986 of the "uwm" window manager for the X10 window system, that I hacked to support pie menus with mouse-ahead and display pre-emption.
X10 Pie Menu Window Manager:
https://www.youtube.com/watch?v=IJhvB6kwmog
---
More info here:
The Design and Implementation of Pie Menus -- Dr. Dobb's Journal, Dec. 1991:
https://donhopkins.medium.com/the-design-and-implementation-...
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:
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
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!
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)
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.
1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Recognize, diagnose, and recover from errors
10. Help and documentation
Both articles have information/direction worth heeding, but there is irony in the fact that the OP page adopts same-text size and paragraphing conventions of yesteryear that the NN page does away with.
It's also frustrating that Hacker News doesn't pay attention to some of the information. In creating an edit to an existing post, the feedback after clicking on the 'update' button is not as clear as it should be. (It's a screen redraw, I guess).
The NN pages are cluttered with navigation to other areas, links for "more this and that", related courses, etc. Everything is in six different font sizes, there are variously-coloured illustrations that pull at strenuous off-topic metaphors... it's a mess.
In contrast, the OP page is clear, simple, sticks to the topic at hand. Easy to read typography, eight paragraphs for the eight rules.
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.
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.
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.
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.
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.
Utilities are things that should be designed with the current typical paradigm of simplicity and discoverability to extreme. I should not need to read user manual for my toaster or microwave.
Tools then, should be pretty much the opposite. It should be fine and expected to invest some time to learn the efficient and safe usage of the tool. There is no reason to have a intuitive interface on your tool, as long as it is efficient after you did your training. Vim is way better editor than notepad, but I don't think anyone praises it for the intuitively easy to use.
And the peeve here is of course that way, way too often these are confused.
The one about giving users closure in a sequence of tasks is kind of novel. I like it.
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)
Things that are the same should look the same, and things that are different should look different.
In my experience, a large portion of the user experience problems in real products are consequences of violating this principle. Construed broadly, this principle implies many design guidelines, e.g.:
- If the user changes something, make the change immediately visible
- If internal state affects what the user can do, make it visible
- Don't use nonstandard interface widgets or icons
If you can get this right, you're a lot of the way there.
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.
Funny enough, with flash gaining traction in the early 2000s, there was a huge barrage of "mystery meat navigation" which was criticized heavily by the UX community, and it ended up falling out of favor for some time. Yet, we're back to "mystery meat navigation" yet again.
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://www.nngroup.com/news/item/hci-pioneers-photos/
NN/g News; HCI Pioneers Photos; Announcements; September 8, 2015
Professor Ben Shneiderman (University of Maryland) is one of the founders of the discipline of human-computer interaction (HCI) and has produced breakthrough research and influential textbooks since the early 1980s. He is also an accomplished photographer from a family of world-class photographers. Dr. Shneiderman has now released a website that collects many of his photographs from the last 32 years of the field's other pioneers, including Jakob Nielsen and Don Norman. It's amazing how young they look in the early photos :-)
https://hcipioneers.wordpress.com/
Shneiderman's comment on launching this history site: "My goal is to make HCI more visible and tell our history more widely. I think HCI designs have had as much impact as Moore’s Law in bringing the web and mobile devices to the world."
Since this is a photohistory, it's much more approachable than most history sites. Well worth perusing for anybody with an interest in where we come from.
----
Ben Shneiderman coined and defined the term "Direct Manipulation":
http://www.csc.kth.se/utbildning/kth/kurser/DH3050/hcihist11...
https://news.ycombinator.com/item?id=11365359
DonHopkins on March 27, 2016 | next [–]
Wow, Ben Shneiderman looks so young in that photo. He's still hard at work making computers easier for people to use, and he just published a major update to his classic book, "Designing the User Interface: Strategies for Effective Human-Computer Interaction", which just went to the printers and will be available on April 26. [1]
I enjoyed working with him at the University of Maryland Human Computer Interaction Lab, and the experience deeply influenced everything I've done since.
Ben is the human who suggested the field be called "Human Computer Interaction" instead of "Computer Human Interaction", to put humans first.
He defined the term Direct Manipulation [2] as:
1) continuous representation of the objects and actions,
2) rapid, incremental, and reversible actions, and
3) physical actions and gestures to replace typed commands.
He also came up with the blue underlined hypertext link, as well as embedded graphical links [3] for the "HyperTIES" system [4].
Here's a paper I published when I was at HCIL, about a visual PostScript programming environment that featured "direct stack manipulation": "The Shape of PSIBER Space - October 1989". [5]
Ben's an avid photographer, and has published this photo history of SIGCHI conferences. [6]
[1] http://www.amazon.com/Designing-User-Interface-Human-Compute...
[2] https://en.wikipedia.org/wiki/Direct_manipulation_interface
[3] https://www.youtube.com/watch?v=fZi4gUjaGAM
[4] http://www.cs.umd.edu/hcil/hyperties/
[5] http://www.donhopkins.com/drupal/node/97
[6] http://www.sigchi.org/photohistory/lib_viewer.jsp?lib=chi
----
Ben Shneiderman founded the University of Maryland Human Computer Interaction Lab, but instead of calling it "Computer Human Interaction" like CHI, he put Humans first instead of Computers.
https://news.ycombinator.com/item?id=35736775
*
4 points by DonHopkins 8 months ago | root | parent | prev | next [–]
That's a point Ben Shneiderman insisted on making in 1983, when he named his "Human Computer Interaction Lab" at the University of Maryland HCIL instead of CHIL, where I worked with him from 1986-1990. Go Terps! ;)
Do you have any citations of European or other labs using that human-first convention before 1983?
University of Maryland Human–Computer Interaction Lab:
https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...
Ben Shneiderman:
https://en.wikipedia.org/wiki/Ben_Shneiderman
Ben also coined the term "Direct Manipulation", and came up with the design of making links blue for the early HyperTIES hypermedia system we developed at HCIL.
https://en.wikipedia.org/wiki/Direct_manipulation_interface
Revisiting why hyperlinks are blue (blog.mozilla.org):
https://blog.mozilla.org/en/internet-culture/why-are-hyperli...
https://news.ycombinator.com/item?id=29897811
https://news.ycombinator.com/item?id=29921532
>Ben Shneiderman recalled that "Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project".
Hypertext on Hypertext CACM1988:
https://www.youtube.com/watch?v=29b4O2xxeqg
30 YEARS AT THE UNIVERSITY OF MARYLAND’S HUMAN-COMPUTER INTERACTION LAB (HCIL). (2013) By Ben Shneiderman, Kent Norman, Catherine Plaisant, Benjamin Bederson, Allison Druin, Jennifer Golbeck:
http://interactionsdev.acm.org/archive/view/september-octobe...
>One attraction of the University of Maryland was its strong psychology department. My computing colleagues were intrigued by my early attempts to use empirical techniques to study programmers as they wrote, modified, or debugged programs. These crossover ideas caught the attention of Azriel Rosenfeld (1931–2004), a world leader in computer vision, who was forming an interdisciplinary Center for Automation Research (CfAR). He led the Computer Vision Lab and invited me to form a Human-Computer Interaction Lab when he launched CfAR in 1983. In a campus reorganization, HCIL became a unit in the Institute for Advanced Computer Studies and eventually became jointly managed with the iSchool.
>Rosenfeld's invitation advanced my efforts by at least five years, giving credibility to the "marriage of computer science and psychology," which I described in my 1980 book, Software Psychology. Gaining credibility was important, as this was still a time when many computer scientists were unsure about the value of psychological studies of programmers and database systems' users, and even the growing field of interactive computer systems. The term human-computer interaction (HCI) was still novel, but I insisted on putting the human first, as opposed to the ACM's choice of computer-human interaction to make a more pronounceable name, "CHI."
Ken Perlin:
https://en.wikipedia.org/wiki/Ken_Perlin
Ken Perlin's Blog:
http://blog.kenperlin.com/?p=237
>Human first (May 29th, 2008)
>I spent the day today at the annual end-of-year symposium of the Human Computer Interaction Lab (HCIL) at the University of Maryland. All three of the Lab’s successive directors – Ben Shneiderman, Ben Bederson and Allison Druin – were there, and they are all good friends of mine. Ben Shneiderman founded the lab in 1983. He is one of the fathers of the field of HCI research, and is a font of wisdom on many subjects. Ben Bederson, with whom I’ve been friends since he was in grad school, took over the lab directorship in 2000. Allison, who is married to Ben Bederson, became the lab’s director in 2006. I actually know Allison the longest of the three. I have had lots of time to talk with all three of them in the last twenty four hours, which has been great fun.
>The wonderful thing about the HCIL, as Allison pointed out today, is that it puts the “human” first. Much of computer science research seems to forget that there are such things as humans. Instead it seems to be a quest for a kind of abstract algorithmic purity, as though computer science were merely a branch of mathematics. The HCIL people have been way ahead of the curve in recognizing that the real power of computers comes when we find ways to interweave that power with the complementary power of the human mind. Computation is indeed enormously powerful, but computation that augments human thought is downright transformative. And to achieve that, you’ve got to understand human thought.
>This is rather tricky for many academics, because it requires bridging the large gap in scientific subcultures between computer science on the one hand, and psychology on the other. It’s very hard to get academic recognition when any given reviewer of your manuscript is not going to understand half of what you are saying. To me the people at HCIL are visionary because they recognized, a full quarter of a century ago – long before it was fashionable – the need to reconcile these two parts of the problem.
>And they are still at it. Only now the world is starting to catch up.
>Ben Shneiderman says on June 3, 2008 at 8:12 pm:
>Thanks Ken… for your kind words and thoughtful contribution to the 25th Anniversary events…. it’s great to see that our message was heard and received in a warm human way. Sincerely… Ben Shneiderman
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser: By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.
https://donhopkins.medium.com/designing-to-facilitate-browsi...
HyperTIES Discussions from Hacker News:
https://donhopkins.medium.com/hyperties-discussions-from-hac...
An Empirical Comparison of Pie vs. Linear Menus: Jack Callahan, Don Hopkins, Mark Weiser () and Ben Shneiderman. Computer Science Department University of Maryland College Park, Maryland 20742 () Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303. Presented at ACM CHI’88 Conference, Washington DC, 1988.
https://donhopkins.medium.com/an-empirical-comparison-of-pie...
I can't shake the feeling that Nielsen (& Norman) simply marketed and productized their principles way better.
This is so obvious yet so many completely fail to do it.
> 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
Don’t make me think!
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.
If you want to know about what contributions Ben Shneiderman and his University of Maryland Human Computer Interaction Lab have made, you can read my other post:
https://news.ycombinator.com/item?id=38920423
Or wikipedia:
https://en.wikipedia.org/wiki/Ben_Shneiderman
https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...
Or Ben Shneiderman's home page:
https://www.cs.umd.edu/users/ben/
One app that the UMD Human Computer Interaction Lab shipped in several versions was HyperTIES, which was used to implement “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference, which influenced Tim Berners-Lee to make hypertext links blue:
The Interactive Encyclopedia System:
https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_S...
HyperTIES Discussions from Hacker News:
https://donhopkins.medium.com/hyperties-discussions-from-hac...
>Don Hopkins sent the following message at 10:07 AM, AUG 28, 2021
>Why are hyperlinks blue?
>Hello Elise. Here is some information about why hyperlinks are blue, from Ben Shneiderman’s answer to a question I asked him about the origin of the term “hyperlink”. I think your belief that HyperTIES was not the first instance of blue hyperlinks because it used cyan links is splitting hairs, and a “No Blue Scotsman” argument, especially since Tim Berners-Lee told Ben Sheniderman at the time that he was influenced by Ben’s design as he saw it in the HyperTIES-based “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference at the University of North Carolina. Ben describes the color as “light blue”, which he chose from the limited palette available on PCs at the time, based on controlled experiments he and his students performed comparing user comprehension and recollection.
https://news.ycombinator.com/item?id=28317104
HI Don (and Jack Gilmore),
Thanks for including me in this conversation.
I do not have a claim for the term “hyperlinks” and don’t know when it came into use. My claim is for the visual interface for showing highlighted selectable links embedded in paragraphs. This is what we called embedded menu items in that I think is an influential paper on the topic, which was peer-reviewed and published in the CACM in April 1986.
https://dl.acm.org/doi/10.1145/5684.5687
http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf
While Engelbart had shown a list that could be selected by pointing and clicking in 1968, I claim the idea of embedded highlighted selectable text in paragraphs. This was implemented by grad student Daniel Ostroff and described in:
Ewing J, Mehrabanzad S, Sheck S, Ostroff D and Shneiderman B (1986), "An experimental comparison of a mouse and arrow-jump keys for an interactive encyclopedia", International Journal of Man-Machine Studies, Jan., 1986, Vol 24, pp. 29-45.
[Abstract] [BibTeX] [DOI]
Ostroff D and Shneiderman B (1988), "Selection devices for users of an electronic encyclopedia: an empirical comparison of four possibilities", Information Processing and Management, Nov., 1988, Vol 24(6), pp. 665-680.
[Abstract] [BibTeX] [DOI]
I think the 1988 paper was the earlier study, but the publication took a while.
My students conducted more than a dozen experiments (unpublished) on different ways of highlighting and selection using current screens, e.g. green screens only permitted, bold, underscore, blinking, and I think italic(???). When we had a color screen we tried different color highlighted links. While red made the links easier to spot, user comprehension and recollection of the content declined. We chose the light blue, which Tim adopted.
His systems with embedded menus (or hot spots), where a significant user interface improvement over early systems such as Gopher. But Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project that we used Hyperties to build for the July 1988 CACM that held the articles from the July 1987 Hypertext conference at the University of North Carolina. The ACM sold 4000 copies of our Hypertext on Hypertext disks.
Our history is here:
https://www.cs.umd.edu/hcil/hyperties/
and the video is very helpful in showing the design we used, which is what I think Tim built on for his WWW prototypes.
https://www.youtube.com/watch?v=29b4O2xxeqg
So in summary, I don’t know who coined hypertext, but I do think our work visual and interaction design was influential.
Our Hyperties system was picked up by Cognetics Corporation (around 1987) who made a modestly successful commercial run with it, doing dozens of corporate projects, most notably the Hewlett-Packard user manual for their Laserjet 4 was distributed as a Hyperties disk.
Hyperties was the name we shifted to after we got a stop and desist order from a lawyer because our TIES (The Interactive Encyclopedia System) conflicted with an existing product. By then “hyper” was a growing term.
Let me know if this helps, and what other questions you have…. Ben
----
HCIL also shipped various treemapping applications:
https://en.wikipedia.org/wiki/Treemapping
>Area-based visualizations have existed for decades. For example, mosaic plots (also known as Marimekko diagrams) use rectangular tilings to show joint distributions (i.e., most commonly they are essentially stacked column plots where the columns are of different widths). The main distinguishing feature of a treemap, however, is the recursive construction that allows it to be extended to hierarchical data with any number of levels. This idea was invented by professor Ben Shneiderman at the University of Maryland Human – Computer Interaction Lab in the early 1990s. [21][22] Shneiderman and his collaborators then deepened the idea by introducing a variety of interactive techniques for filtering and adjusting treemaps.