[HN Gopher] Golden Rules of Interface Design (2013)
___________________________________________________________________
Golden Rules of Interface Design (2013)
Author : luu
Score : 274 points
Date : 2024-01-08 19:15 UTC (1 days ago)
(HTM) web link (www.cs.umd.edu)
(TXT) w3m dump (www.cs.umd.edu)
| stevage wrote:
| These seem common sense, but it's good to see them written down.
|
| The one about giving users closure in a sequence of tasks is kind
| of novel. I like it.
| georgeecollins wrote:
| 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.
| leetrout wrote:
| Not sure that is the best comparison because it removes the
| mechanical need for leverage, even with power steering.
|
| Now that we have more electric steer by wire... maybe.
| ebiester wrote:
| Think of it more like this.
|
| On page A, you have a button. It looks like a button. When you
| click it, a dialog opens that confirms you want to perform an
| action.
|
| On page B, you click on the button, and it's a dropdown. You
| now have lost a sense of the mental model of the application
| world.
|
| It's possible that you may want one of three actions based on
| your mental model, but the visual should lead you to know "this
| is different."
|
| If you have something that looks like a
| Jtsummers wrote:
| > 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.
| ivan_gammel wrote:
| > 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.
| projektfu wrote:
| When I was a kid there were toy RC cars that had two controls,
| kind of like 1-axis joysticks. The left one pushed upward would
| cause the car to go forward, possibly with more or less power.
| The right one pushed to the right allowed turning to the right
| (but not the left, like Zoolander).
|
| A consistent upgrade to this interface would be to allow
| reversing using the left control in a downward direction and
| turning left using the right control pushed to the left. An
| inconsistent application would be to have reverse on the right
| control pushed to the left and left turning on the left control
| pushed downward.
|
| Inconsistencies across classes are not uncommon and probably
| understandable given various expectations. For example, the
| same handlebar steering control behaves very differently on a
| two-wheeled motorcycle compared to a tricycle.
| p1necone wrote:
| 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.
| quickthrower2 wrote:
| In this case the consistency is between what you learned to
| drive in, and the car you use now.
| JusticeJuice wrote:
| +1, consistency above everything is a very common trap new
| designers fall into. Humans are messy.
| bbor wrote:
| Can an expert explain some context here?? This seems like a less-
| well-phrased version of Norman's principles, which were the ones
| I was taught in HCI class.
|
| The author is clearly some sort of textbook author so they know
| what they're talking about, but these principles seem like they
| were written without considering past work. Like "short term
| memory load" seems like a phrase that would be replaced by
| "cognitive load" by most authors, even if it's technically a
| little bit less specific. Some of the principles are pretty much
| identical (consistency), while others seem oddly phrased (like
| "prevent errors" instead of "constraints").
|
| Obviously these principles are great, just seems like there has
| to be a story about the academic drama here.
| ivan_gammel wrote:
| I was not familiar with this author, but they mentioned that
| these principles were defined around 1985 -- before Nielsen's
| heuristics. A lot of things were different 40 years ago, so
| language may indeed seem a bit archaic.
| bbor wrote:
| 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.
| jonstewart wrote:
| Ben Schneiderman is an ACM Fellow and CS professor emeritus of
| the University of Maryland-College Park. These 8 principles are
| from his 1986 book. He's done a lot of work in infovis and HCI
| and is the inventor of the treemap visualization.
|
| https://en.m.wikipedia.org/wiki/Ben_Shneiderman
| sib wrote:
| 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.
| DonHopkins wrote:
| Donald Norman and Ben Shneiderman are old friends and
| colleagues.
|
| https://www.nngroup.com/news/item/hci-pioneers-photos/
|
| NN/g News; HCI Pioneers Photos; Announcements; September 8,
| 2015
|
| Professor Ben Shneiderman (University of Maryland) is one of
| the founders of the discipline of human-computer interaction
| (HCI) and has produced breakthrough research and influential
| textbooks since the early 1980s. He is also an accomplished
| photographer from a family of world-class photographers. Dr.
| Shneiderman has now released a website that collects many of
| his photographs from the last 32 years of the field's other
| pioneers, including Jakob Nielsen and Don Norman. It's amazing
| how young they look in the early photos :-)
|
| https://hcipioneers.wordpress.com/
|
| Shneiderman's comment on launching this history site: "My goal
| is to make HCI more visible and tell our history more widely. I
| think HCI designs have had as much impact as Moore's Law in
| bringing the web and mobile devices to the world."
|
| Since this is a photohistory, it's much more approachable than
| most history sites. Well worth perusing for anybody with an
| interest in where we come from.
|
| ----
|
| Ben Shneiderman coined and defined the term "Direct
| Manipulation":
|
| http://www.csc.kth.se/utbildning/kth/kurser/DH3050/hcihist11...
|
| https://news.ycombinator.com/item?id=11365359
|
| DonHopkins on March 27, 2016 | next [-]
|
| Wow, Ben Shneiderman looks so young in that photo. He's still
| hard at work making computers easier for people to use, and he
| just published a major update to his classic book, "Designing
| the User Interface: Strategies for Effective Human-Computer
| Interaction", which just went to the printers and will be
| available on April 26. [1]
|
| I enjoyed working with him at the University of Maryland Human
| Computer Interaction Lab, and the experience deeply influenced
| everything I've done since.
|
| Ben is the human who suggested the field be called "Human
| Computer Interaction" instead of "Computer Human Interaction",
| to put humans first.
|
| He defined the term Direct Manipulation [2] as:
|
| 1) continuous representation of the objects and actions,
|
| 2) rapid, incremental, and reversible actions, and
|
| 3) physical actions and gestures to replace typed commands.
|
| He also came up with the blue underlined hypertext link, as
| well as embedded graphical links [3] for the "HyperTIES" system
| [4].
|
| Here's a paper I published when I was at HCIL, about a visual
| PostScript programming environment that featured "direct stack
| manipulation": "The Shape of PSIBER Space - October 1989". [5]
|
| Ben's an avid photographer, and has published this photo
| history of SIGCHI conferences. [6]
|
| [1] http://www.amazon.com/Designing-User-Interface-Human-
| Compute...
|
| [2] https://en.wikipedia.org/wiki/Direct_manipulation_interface
|
| [3] https://www.youtube.com/watch?v=fZi4gUjaGAM
|
| [4] http://www.cs.umd.edu/hcil/hyperties/
|
| [5] http://www.donhopkins.com/drupal/node/97
|
| [6] http://www.sigchi.org/photohistory/lib_viewer.jsp?lib=chi
|
| ----
|
| Ben Shneiderman founded the University of Maryland Human
| Computer Interaction Lab, but instead of calling it "Computer
| Human Interaction" like CHI, he put Humans first instead of
| Computers.
|
| https://news.ycombinator.com/item?id=35736775
|
| *
|
| 4 points by DonHopkins 8 months ago | root | parent | prev |
| next [-]
|
| That's a point Ben Shneiderman insisted on making in 1983, when
| he named his "Human Computer Interaction Lab" at the University
| of Maryland HCIL instead of CHIL, where I worked with him from
| 1986-1990. Go Terps! ;)
|
| Do you have any citations of European or other labs using that
| human-first convention before 1983?
|
| University of Maryland Human-Computer Interaction Lab:
|
| https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...
|
| Ben Shneiderman:
|
| https://en.wikipedia.org/wiki/Ben_Shneiderman
|
| Ben also coined the term "Direct Manipulation", and came up
| with the design of making links blue for the early HyperTIES
| hypermedia system we developed at HCIL.
|
| https://en.wikipedia.org/wiki/Direct_manipulation_interface
|
| Revisiting why hyperlinks are blue (blog.mozilla.org):
|
| https://blog.mozilla.org/en/internet-culture/why-are-hyperli...
|
| https://news.ycombinator.com/item?id=29897811
|
| https://news.ycombinator.com/item?id=29921532
|
| >Ben Shneiderman recalled that "Tim told me at the time that he
| was influenced by our design as he saw it in the Hypertext on
| Hypertext project".
|
| Hypertext on Hypertext CACM1988:
|
| https://www.youtube.com/watch?v=29b4O2xxeqg
|
| 30 YEARS AT THE UNIVERSITY OF MARYLAND'S HUMAN-COMPUTER
| INTERACTION LAB (HCIL). (2013) By Ben Shneiderman, Kent Norman,
| Catherine Plaisant, Benjamin Bederson, Allison Druin, Jennifer
| Golbeck:
|
| http://interactionsdev.acm.org/archive/view/september-octobe...
|
| >One attraction of the University of Maryland was its strong
| psychology department. My computing colleagues were intrigued
| by my early attempts to use empirical techniques to study
| programmers as they wrote, modified, or debugged programs.
| These crossover ideas caught the attention of Azriel Rosenfeld
| (1931-2004), a world leader in computer vision, who was forming
| an interdisciplinary Center for Automation Research (CfAR). He
| led the Computer Vision Lab and invited me to form a Human-
| Computer Interaction Lab when he launched CfAR in 1983. In a
| campus reorganization, HCIL became a unit in the Institute for
| Advanced Computer Studies and eventually became jointly managed
| with the iSchool.
|
| >Rosenfeld's invitation advanced my efforts by at least five
| years, giving credibility to the "marriage of computer science
| and psychology," which I described in my 1980 book, Software
| Psychology. Gaining credibility was important, as this was
| still a time when many computer scientists were unsure about
| the value of psychological studies of programmers and database
| systems' users, and even the growing field of interactive
| computer systems. The term human-computer interaction (HCI) was
| still novel, but I insisted on putting the human first, as
| opposed to the ACM's choice of computer-human interaction to
| make a more pronounceable name, "CHI."
|
| Ken Perlin:
|
| https://en.wikipedia.org/wiki/Ken_Perlin
|
| Ken Perlin's Blog:
|
| http://blog.kenperlin.com/?p=237
|
| >Human first (May 29th, 2008)
|
| >I spent the day today at the annual end-of-year symposium of
| the Human Computer Interaction Lab (HCIL) at the University of
| Maryland. All three of the Lab's successive directors - Ben
| Shneiderman, Ben Bederson and Allison Druin - were there, and
| they are all good friends of mine. Ben Shneiderman founded the
| lab in 1983. He is one of the fathers of the field of HCI
| research, and is a font of wisdom on many subjects. Ben
| Bederson, with whom I've been friends since he was in grad
| school, took over the lab directorship in 2000. Allison, who is
| married to Ben Bederson, became the lab's director in 2006. I
| actually know Allison the longest of the three. I have had lots
| of time to talk with all three of them in the last twenty four
| hours, which has been great fun.
|
| >The wonderful thing about the HCIL, as Allison pointed out
| today, is that it puts the "human" first. Much of computer
| science research seems to forget that there are such things as
| humans. Instead it seems to be a quest for a kind of abstract
| algorithmic purity, as though computer science were merely a
| branch of mathematics. The HCIL people have been way ahead of
| the curve in recognizing that the real power of computers comes
| when we find ways to interweave that power with the
| complementary power of the human mind. Computation is indeed
| enormously powerful, but computation that augments human
| thought is downright transformative. And to achieve that,
| you've got to understand human thought.
|
| >This is rather tricky for many academics, because it requires
| bridging the large gap in scientific subcultures between
| computer science on the one hand, and psychology on the other.
| It's very hard to get academic recognition when any given
| reviewer of your manuscript is not going to understand half of
| what you are saying. To me the people at HCIL are visionary
| because they recognized, a full quarter of a century ago - long
| before it was fashionable - the need to reconcile these two
| parts of the problem.
|
| >And they are still at it. Only now the world is starting to
| catch up.
|
| >Ben Shneiderman says on June 3, 2008 at 8:12 pm:
|
| >Thanks Ken... for your kind words and thoughtful contribution
| to the 25th Anniversary events.... it's great to see that our
| message was heard and received in a warm human way.
| Sincerely... Ben Shneiderman
|
| Designing to Facilitate Browsing: A Look Back at the Hyperties
| Workstation Browser: By Ben Shneiderman, Catherine Plaisant,
| Rodrigo Botafogo, Don Hopkins, William Weiland. Published in
| Hypermedia, vol. 3, 2 (1991)101-117.
|
| https://donhopkins.medium.com/designing-to-facilitate-browsi...
|
| HyperTIES Discussions from Hacker News:
|
| https://donhopkins.medium.com/hyperties-discussions-from-hac...
|
| An Empirical Comparison of Pie vs. Linear Menus: Jack Callahan,
| Don Hopkins, Mark Weiser ( _) and Ben Shneiderman. Computer
| Science Department University of Maryland College Park,
| Maryland 20742 (_ ) Computer Science Laboratory, Xerox PARC,
| Palo Alto, Calif. 94303. Presented at ACM CHI'88 Conference,
| Washington DC, 1988.
|
| https://donhopkins.medium.com/an-empirical-comparison-of-pie...
| marapuru wrote:
| 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.
| infotainment wrote:
| 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.
| ivan_gammel wrote:
| > It's often better to allow mistakes but also offer immediate
| explanatory feedback if something is incorrect.
|
| That is just another form of error prevention: in the end
| erroneous data will not be submitted.
| Jtsummers wrote:
| > 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.
| naasking wrote:
| Add a tooltip on disabled inputs.
| DonHopkins wrote:
| 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.
| o11c wrote:
| Tooltips seem to have gone out of style in this touch-first
| world.
|
| Good UIs still use tooltips, you just have to click or drag
| when in touch mode.
|
| There's also the awkward problem of most native tooltips
| being plain-text-only, when text is not actually sufficient
| for every problem (such as international text). And emulated
| "tooltip" widgets are slow, buggy, etc.
| saratogacx wrote:
| 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.
| pvorb wrote:
| 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.
| eviks wrote:
| > will just confuse users. "Why can't I type text here??" It's
| often better to allow mistakes but also offer immediate
| explanatory feedback if something is incorrect.
|
| No, it's better to prevent a mistake and offer immediate
| explanatory feedback why something is incorrect. For example,
| the answer to "why can't I type text here??" would be a message
| explaining that no text is allowed, only numbers.
| whycome wrote:
| Or, as is possible on mobile, make the input mode change to
| numbers-only
| eviks wrote:
| Yes, and make your now useless alpha keys into a perfectly
| usable numpad so you don't have to use the worse horizontal
| numbers row or shift your hand to the actual numpad!
|
| uio 123
|
| jkl 456
|
| m,. 789
| graypegg wrote:
| A designer I worked with years ago had a great explanation for
| why consistency is important.
|
| It's not about a limited colour palette or a careful selection of
| fonts no one will ever notice. Chasing the specifics makes
| horrible software. Some people equate less diversity in their UI
| to more consistency.
|
| It's about letting someone become an expert in your software.
|
| Microsoft office was always his example. People pride themselves
| on "knowing" Microsoft office. They jump between all of the apps
| because they have a feel for the inertia of "office". I have the
| exact same feeling in Vim. I just know how things are expected to
| be, and new (well made) plugins tend to respect those patterns.
|
| Office and (Neo)Vim aren't exceptional examples of UI, but they
| are uniquely stable.
| Angostura wrote:
| 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
| staplers wrote:
| Expectation should precede consistency in order of
| importance.
|
| Meaning, if a new user is learning your software, how would
| they expect the next [flow] to go?
|
| Consistency often shapes expectations but when things go how
| you expect them to, you don't need to learn new mental
| models.
| jonshariat wrote:
| UX designer here. I've learned that these changes are a
| delicate balance between allowing existing user to remain
| experts while improving the retention of new users.
|
| This can be accomplished by making small changes over time
| that break up all the new info a user has to learn and
| avoiding the big UI reveal which people universally hate
| because all that new learning is required at once and they
| need to get stuff done.
|
| Often times its required because as a product moves into
| mass market phase of its life cycle, it needs to be simple
| to use for lots of people, which mean it doenst work great
| for any specific goup.
|
| Which is why I'm really in favor of allowing customizations
| to the user where appropriate. It allows experts to have
| control over their flow and new users can enjoy the UX
| optimized for them.
| staplers wrote:
| As a fellow UX designer, i've learned the same.
| mjevans wrote:
| I still hate ribbons.
|
| MS Office UI peeked around versions 97-2003 or so. Everything
| in a menu, actions grouped / categorized so they were easier
| to discover. QUICKLY accessible by underlined keyboard
| combinations (alt+menu letter THEN item in menu letter) and
| with any actions that had a direct keyboard shortcut
| annotated. Everything easily discoverable.
|
| Ribbons, I've no idea how the categorize what's popular or
| not, but 'related' things seem weaker to me, and the context
| switch price is much higher. Plus there's a need to hunt and
| kill with a mouse instead of direct with the keyboard.
| kuchenbecker wrote:
| 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.
| userbinator wrote:
| You can still access the items in the ribbons with Alt key
| sequences (although I agree that they've become far less
| discoverable), but the full-screen(!) "file menu"
| abomination that they added in later versions is even more
| hostile and offensive.
| Espressosaurus wrote:
| Especially after they made everything cloud-first, making
| saving my damn documents to my local drive a pain in the
| ass.
| TaroEld wrote:
| F12 brings up the old "Save As" filebrowser.
| troupo wrote:
| Ribbons for Word _used_ to have actual research behind
| them. Since then it 's just cargo culting.
|
| Sadly, many images are broken, but the blog series "Why The
| New UI" survives on web archive: https://web.archive.org/we
| b/20080316101025/http://blogs.msdn...
| saratogacx wrote:
| There's an old MIX08 video where some guys from MS
| actually talk through the design process and everything
| that went into it with a lot of depth as well as looking
| at alternative ideas and why they didn't work.
|
| https://www.youtube.com/watch?v=AHiNeUTgGkk
| danielvaughn wrote:
| both vim and neovim _are_ examples of UI, just not (G)UI :)
| xp84 wrote:
| 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.
| DonHopkins wrote:
| I had an interesting discussion on Twitter with Michael
| Darius about this very topic recently. He is an "Apple
| pioneer, skeuomorph & protege of Steve Jobs" who epitomizes
| the excesses of aesthetics and branding at the expense of
| everything else, so I had to call him on his brash claim and
| ask him some pointed questions, and brought up the User
| Interface Hall of Shame's review of the QuickTime 4.0 player,
| as an example of the excesses of skeuomorphism.
|
| https://twitter.com/darius/status/1741188955985604867
|
| Michael Darius @darius 9:06 PM * Dec 30, 2023 22.1K Views:
|
| There is just no reason why an interface should be anything
| but beautiful.
|
| Don Hopkins @xardox:
|
| Tell that to an airplane pilot who takes the lives of their
| passengers in their hands every day. Are you really saying
| that airplane cockpits should be beautiful, at the expense of
| safe and usable and accessible?
|
| Michael Darius:
|
| Beauty for the sake of beauty is a mistake but beauty for the
| sake of user enjoyment reduces cognitive dissonance. Don't
| forget that pilots are people too with emotional needs.
|
| Don Hopkins:
|
| Beauty should take a back seat when it comes to safety,
| usability, and accessibility, not only in airline cockpits,
| but in most other interfaces, too. Your statement that "there
| is just no reason an interface should be anything but
| beautiful" is extreme and dangerous.
|
| Michael Darius:
|
| An interface is a habitat for a persons soul to dwell. Some
| habitats are better than others and there some awfully
| designed habitats out there.
|
| Don Hopkins:
|
| There are many reasons why, and many things more important
| than beauty. A spreadsheet is more beautiful if it hides the
| ugly truth about the formulas, relationships, numbers,
| dependencies, and complexities. Its purpose isn't to be easy
| on the eyes, it's to be correct.
|
| Are your earpods supposed to be beautiful, at the expense of
| being comfortable and actually fitting in your ears and not
| itching and poking and flaking paint and decorations into the
| holes on your head? You don't need to see them, just hear
| them.
|
| The shape of your ear canals isn't beautiful, but your
| earpods have to conform to it nonetheless.
|
| Michael Darius:
|
| I'd sooner fly a luxury airliner with dashboard complexity
| that has been thought through for me than assume that safety
| was the tradeoff for getting to fly with simpler controls.
|
| [photos of extremely complex airliner cockpits -- not sure
| which he's claiming are beautiful or ugly though]
|
| https://twitter.com/darius/status/1741193514032267758
|
| Don Hopkins:
|
| Beauty is in the eye of the beholder, but safety and
| usability and complexity is scientifically measurable, you
| can't claim that thinking through safety and usability and
| complexity always results in beauty. Most people would
| consider those examples cluttered, complex, and ugly.
|
| ESPECIALLY anyone who subscribes to the school of
| minimalistic design like iPads exhibit, like hiding
| scrollbars because they are ugly, even though they tell you
| how much more there is to scroll, and what to do to scroll to
| it. Airplanes and spreadsheets need ugly affordances.
|
| Michael Darius:
|
| You can tell when something has been thought through on the
| inside, just as much as it has on the outside and most of the
| people who disagree with me in practice have simply never had
| the opportunity to work with engineers who care more about
| what is under the hood than what can be seen by the naked
| eye.
|
| I see no difference between beauty and the reduction in the
| margin for human error.
|
| [Photo of two children piloting an airplane.]
|
| https://twitter.com/darius/status/1741195625767772529
|
| Don Hopkins:
|
| You just have an extreme personal opinion about beauty if you
| think removing scrollbars and buttons and even cluttered
| features from iPad interfaces, and making airplane cockpits
| look like playschool toys, always equals beauty. Your
| original statement is extreme therefore wrong.
|
| It's wrong to assume that "There is just no reason why an
| interface should be anything but beautiful." I'd rather be
| lazy and safe than wrong and dead because some interface
| designer though he was smarter than the FAA.
|
| And you're also wrong because you're presuming there is only
| one definition of beauty: yours. And that it can be measured.
| It can't. Address that, please.
|
| Michael Darius:
|
| When effort has been put into an interface to simplify a
| function, the function itself becomes more beautiful. We see
| this when writing code. If I can perform an operation by
| writing 3 lines of code instead of 10, the margin for error
| decreases.
|
| [An image with an example of "Ugly vs Beautiful" code
| claiming that a one-liner is more beautiful than 6 lines of
| equivalent code.]
|
| Don Hopkins:
|
| Again, you're pretending that beauty is not subjective, and
| that you know the one universal definition of beauty, and I
| would have expected better from you, and even more from a
| first year art student. Would the Mona Lisa be more beautiful
| with less paint?
|
| Would the Sistine Chapel be more beautiful with stick figures
| like an XKCD comic? Get off your high horse of thinking you
| can define beauty. Especially after championing the overly
| minimalistic iPad user interface bereft of scrollbars,
| buttons with text labels, and even features.
|
| Michael Darius:
|
| Here's a quote that sums up Shaker philosophy:
|
| "Don't make something unless it is both necessary and useful;
| but if it is both necessary and useful, don't hesitate to
| make it beautiful."
|
| [A photo of a "beautiful" chair.]
|
| Don Hopkins:
|
| But for the n'th time, you've again ignored me when I pointed
| out you're moving the goalposts from your original
| outrageously extreme and incorrect statement that "There is
| just NO REASON why an interface should be ANYTHING BUT
| beautiful."
|
| Michael Darius:
|
| I'm not ignoring you, I can't keep up with how much you are
| writing.
|
| Don Hopkins:
|
| Well at least go back and read the words you wrote in your
| initial tweet and try defending THOSE, instead of trying to
| move the goalposts and express the one true definition of
| beauty. I ask you again: define and defend the words you
| first chose and wrote yourself.
|
| Your original statement is indefensible, so go back and try
| defending it instead of trying to move the goalposts and
| pretend you have a monopoly on the definition of beauty.
|
| Your original statement didn't say anything about necessity
| or usefulness, as I said before. In fact it PRECLUDED them by
| claiming interfaces should ONLY be beautiful: "There is just
| NO REASON why an interface should be ANYTHING BUT beautiful."
| Stop deflecting. Defend THAT.
|
| What exactly do you mean by "NO REASON" and "ANYTHING BUT".
| Usability and safety are reasons, and something but.
|
| Some random guy:
|
| Sorry to interrupt you guys. How about you two actually go to
| FAA or some shit and consult with them if it's possible to
| make a cockpit more beautiful but retain its practicality. I
| feel like the argument wouldn't go anywhere without trying to
| do something for real.
|
| Don Hopkins:
|
| You suggest us just walking in the front door of FAA
| headquarters, waltzing through security, and insisting on a
| meeting with the heads of the FAA to redesign their
| interfaces? Should Darius and I drop all we're doing and
| volunteer our time to do that for free?
|
| Michael Darius:
|
| The images themself do a better job of communicating what I
| mean by "beauty standards for excellence".
|
| I've never met a designer who didn't feel that their
| responsibility was to defend beauty standards for excellence
| and I'm not different.
|
| The mechanics of a jail door might be functional and usable
| by a door guard but there is nothing beautiful about building
| more prisons.
|
| Habitats for humanity cares more deeply about the ACTUAL
| lived experiences people are ACTUALLY having.
|
| [... A side discussion about the definition of beauty, in
| which Darius channels Deepak Chopra, and I try to get him
| back on track to defend his own original words, and he stands
| by his statement but doesn't justify it:
| https://twitter.com/xardox/status/1741212753056944187 ]
|
| Michael Darius:
|
| If beauty were so subjective then walking through a meadow
| would feel no different than doing jail time.
|
| Don Hopkins:
|
| Now you're sounding like Deepak Chopra and his quantum faith
| healing mumbo jumbo hand waving woo woo. I would have
| expected much more from you. You made a clear unambiguous
| brash statement using the words NO REASON and ANYTHING BUT.
| Defend those words.
|
| Michael Darius:
|
| We can agree to disagree.
|
| [...]
|
| The subjectiveness here may not be around the definition of
| beauty and more around the 'definition of an interface'. An
| interface can be defined as 'the surface between Air and
| water'.
|
| Don Hopkins:
|
| More woo-woo, Deepak. Address points 1 and 2 which are
| directly about YOUR WORDS: "There is just NO REASON why an
| interface should be ANYTHING BUT beautiful." (How many times
| do I have to quote them back to you before you address them?
| I must be on #10 by now.)
|
| [...]
|
| Don Hopkins:
|
| Of all those cockpits, which fit your definition of beauty
| and which don't, and aren't you aware that there are many
| hard won FAA regulations learned from the study of accidents,
| mass death, destruction, and human error, that vastly trump
| your personal opinion of beauty?
|
| Or are you arguing that all iPad interfaces should look like
| 747 cockpits?
|
| Or do you believe that beauty automatically implies safety,
| ergonomics, usability, visual unambiguity and perceptibility?
| Then how do you measure and prove that beauty is not
| subjective and not in the eye of the beholder and not just
| your personal opinion?
|
| And what if your personal opinions about beauty happen to
| require more weight, more expensive, less durable, more
| bespoke and less modular materials? Do economics not come
| into the picture, or do you only design interfaces for
| extremely rich people?
|
| Of course Donald Trump thinks that solid gold toilets in his
| luxury airliner are beautiful. Do you agree, because you
| think beauty isn't in the eye of the beholder and he's right,
| or because you want to make the customer happy no matter how
| bad their taste and idea of beauty is?
|
| Michael Darius:
|
| In a field where cognitive safety needs to be the priority
| and a world where user enjoyment reduces cognitive load, it
| is intellectually lazy to assume that beauty is the tradeoff
| for ergonomic safety.
|
| Don Hopkins:
|
| The UI Hall of Shame's review of the notorious QuickTime 4.0
| player proves the perilous consequences of a UI designer's
| personal opinions about skeuomorphic beauty trumping
| usability and ease of use. Were you involved with that, or
| was it before your time?
|
| http://hallofshame.gp.co.at/qtime.htm
|
| That article should be required reading for aspiring UI
| designers. Hacker News discussion:
|
| https://news.ycombinator.com/item?id=18212478
|
| My comment in that discussion:
|
| "Apple's long romance with skeuomorphism peaked with Bob
| Bishop's APPLE-VISION, and went downhill from there." I
| posted several other comments about VLC's terrible UI, too.
|
| https://news.ycombinator.com/item?id=18219757
|
| Bob Bishop's Apple Vision:
|
| https://www.youtube.com/watch?v=CU_qKQL5PVk
|
| [At this point I took it to private DMs.]
|
| Don Hopkins:
|
| Are you familiar with that review and the problems that
| caused the widespread negative response to the QuickTime 4
| Player user interface? Have you taken the time to read the
| whole article? Were you involved with that product, or was it
| before your time?
|
| http://hallofshame.gp.co.at/qtime.htm
|
| I have written about it on Hacker News, and compared it to
| the even worse WinAmp user interface. Other commenters
| compared them to WinAmp, but I don't believe WinAmp's
| infinite and easy skinnability is nearly as maliciously
| terrible or professionally irresponsible as the QuickTime 4
| player (I expected SO MUCH MORE from a company like Apple
| that published Tog's original UI guidelines), or VLC (which
| is an open source project without any money or professional
| UI designers).
|
| HN discussion:
|
| https://news.ycombinator.com/item?id=18212478
|
| One of my comments (among several), which includes a thread
| about VLC:
|
| https://news.ycombinator.com/item?id=18219757
|
| You can see that I actually give a shit enough about VLC to
| have spend quite a bit of time analyzing the problem and
| writing up bug reports, but the culture of the project is so
| insular and "NIH" that they don't give a shit about user
| interface design. So I have little hope that VLC will ever
| improve. But at least Apple finally improved their QuickTime
| 4 Player in response to acceoss-the-board criticism.
|
| A counter example to the rule of thumb that open source user
| interfaces are terrible is Blender. Especially when you
| compare it to GIMP (which is like shooting fish in a barrel,
| but still is an instructive comparison of cultures).
|
| Blender was infamous for its complex non-standard confusing
| user interface design, but they LISTENED TO THEIR USERS and
| vastly improved it!
|
| But of course there is no way of getting around the fact that
| it's an extremely complex tool that's used differently by a
| wide range of people, so a lot of that complexity is
| necessary, and you can't just simplify it away and dumb it
| down without destroying its usefulness.
|
| One thing Blender does have excellent support for is pie
| menus! And there are some great pie menu editors, which are
| important because every different Blender user has their own
| workflow and set of common commands. So Blender users need to
| customize and define their own pie menus. Just like HyperCard
| enabled normal users to construct their own task oriented
| user interfaces.
|
| (Of course Steve Jobs hated pie menus, which is a story I can
| tell you about later, or maybe you can tell me the Apple side
| of that story: Why didn't Apple ever adopt pie menus for
| MacOS or iOS?)
|
| Pie menus have the potential of being both beautiful,
| efficient, reliable (low error rates), and easy to use, but
| it takes a lot more design and programming to pull off than a
| traditional linear menu.
|
| Simon Schneegans is a brilliant user interface designer as
| well as an accomplished programmer, and he has developed not
| only beautiful pie menus (for example the Coral and Trace
| menu he did for his Master's thesis years ago, and he more
| recent work on Gnome-Pie, Fly-Pie, and the cross platform
| Kandu pie menus for desktop app launching, window management,
| text selection, and many other tasks).
|
| The Trace-Menu A short demonstration of a Pie-Menu I
| developed for my Bachelor thesis.
|
| https://vimeo.com/51073078
|
| The Coral-Menu A short demonstration of a Pie-Menu I
| developed for my Bachelor thesis.
|
| https://vimeo.com/51072812
|
| The thing about those examples (and his later work) is that
| the cool graphics don't spoil the underlying good Fitts' Law
| friendly design -- they actually increase usability and
| reinforce the gestural navigation user interface metaphor.
|
| His most amazing accomplishment is the WYSIWYG drag-and-drop
| interactive pie menu editor he designed and implemented for
| Gnome-Pie, that he's reimplementing across platforms (Linux
| X11 Gnome, KDE, Wayland Gnome, etc, Windows, and Mac).
|
| Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!
|
| https://www.youtube.com/watch?v=sRT3O9-H5Xs
|
| >Fly-Pie is an attractive marking menu for GNOME Shell. Fly-
| Pie 7 supports GNOME Shell 40+ and brings a completely
| rewritten menu editor.
|
| I hope this proves to you how important I believe beauty is.
| but how I also believe it doesn't need to sacrifice
| usability.
|
| Here's the latest demo of his current project, Kandu: cross
| platform super customizable pie menus for Linux, Windows, and
| Mac. I just sent him my old Mac laptop so he can support the
| Mac desktop well. The way it works is by using Electron with
| a full screen transparent overlay window, so it can draw the
| pie menus with html/css/svg/canvas or any other standards
| based web technologies.
|
| Kando becomes useful for the first time!
|
| https://www.youtube.com/watch?v=7vVdJ9LORAM
|
| >With Kando, I am creating an open-source pie menu which runs
| on Windows, Linux and (eventually) macOS. In the future, you
| will be able to create your own men...
|
| Michael Darius (excerpts):
|
| [...] Tim Wasko was the designer for the initial QT player
| and still remains one of the best interaction designers I
| know." [...]
|
| I don't consider something unusable or barely usable to be
| beautiful so if the work hasn't been put in on the usability
| side or if something isn't working it doesn't matter how
| beautiful the interface elements themselves are. But in that
| case what makes it not beautiful is not that the interface
| elements aren't beautiful. What makes it not beautiful is
| that what is under the hood isn't beautiful and what is under
| the hood is more often than not not thought through the way
| it should be.
|
| My definition of 'beauty' is inseparable from my definition
| of functional design:
|
| An interface should go beyond usable, it should delight,
| create enjoyment, provide a sense of safety and control over
| one's environment, it should be beautifully engineered inside
| and out and when any one of those pieces go missing beauty
| itself goes missing.
| hutzlibu wrote:
| "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.
| ShadowBanThis01 wrote:
| 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.
| kemotep wrote:
| We are about a year or 2 from the Ribbon interface existing
| in Office longer than the pre-Ribbon interface.
|
| I will agree that the Ribbon and what you can customize or
| use in it/looks has changed drastically since 2007.
|
| But the Ribbon "paradigm" will soon have existed longer than
| the non-Ribbon "stable and efficient" interface so it is more
| "stable" in one way.
| ShadowBanThis01 wrote:
| 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.
| troupo wrote:
| https://news.ycombinator.com/item?id=38925695
| DonHopkins wrote:
| I worked with Ben Shneiderman at the UMD Human Computer
| Interaction Lab developing pie menus, and one of the important
| principles of pie menus, especially in comparison to both
| traditional linear menus, and invisible gestures as used by the
| iPad and mobile apps, is that they smoothly TRAIN novice users
| to become experts by using "rehearsal".
|
| Pie menus can lead, follow, or get out of the way. The way a
| novice uses them is actually rehearsal for how a more
| experienced and experts use them.
|
| Unlike invisible gestures, they can pop up and show users the
| available items. They also support reselection and browsing,
| which gestures don't. They also utilize 100% of possible
| "gesture space" as meaningful predictable actions, as opposed
| to gesture recognition which squanders most possible gestures
| as syntax errors.
|
| Gesture Space:
|
| https://donhopkins.medium.com/gesture-space-842e3cdc7102
|
| Unlike pull-down menus that have keyboard shortcuts, pie menu
| "shortcuts" are exactly the same action a novice takes to use
| them in the first place, only quicker, so using them in the
| slow way trains you to use them in the fast way. While
| selecting from a linear menu with the mouse is a totally
| different action than selecting a menu shortcut with the
| keyboard.
|
| Ben Shneiderman introduces Don Hopkins' work on pie menus in
| Spring 1989 on a Sun Workstation, running the NeWS window
| system:
|
| https://www.youtube.com/watch?v=8Fne3j7cWzg
|
| After an 1991 intro by Ben Shneiderman we see the older 1989
| demo by Don Hopkins showing many examples of pie menus on a Sun
| Workstation, running the NEWS operating system.
|
| This is work done at the Human-Computer Interaction Lab at the
| University of Maryland.
|
| A pie menu is a menu technique where the items are placed along
| the circumference of a circle at equal radial distance from the
| center. Several examples are demonstrated on a Sun running NeWS
| window system, including the use of pie menus and gestures for
| window management, the simultaneous entry of 2 arguments (by
| using angle and distance from the center), scrollable pie
| menus, precision pie menus, etc. We can see that gestures were
| possible (with what Don call "mouse ahead" ) so you could make
| menu selections without even displaying the menu. Don uses an
| artifact he calls "mousee" so we can see what he is doing but
| that extra display was only used for the video, i.e. as a user
| you could make selections with gestures without the menu ever
| appearing, but the description of those more advanced features
| was never published.
|
| Pretty advance for 1989... i.e. life before the Web, when mice
| were just starting to spread, and you could graduate from the
| CS department without ever even using one.
|
| This video was published in the 1991 HCIL video but the demo
| itself - and recording of the video - dates back to 1989 at
| least, as pictures appear in the handout of the May 1989 HCIL
| annual Open House.
|
| The original Pie Menu paper is Callahan, J., Hopkins, D.,
| Weiser, M., Shneiderman, B., An empirical comparison of pie vs.
| linear menus; Proc. ACM CHI '88 (Washington, DC) 95-100.
|
| Also Sparks of Innovation in Human-Computer Interaction,
| Shneiderman, B., Ed., Ablex (June 1993) 79-88. A later paper
| mentions some of the more advanced features in an history of
| the HyperTies system: Shneiderman, B., Plaisant, C., Botafogo,
| R., Hopkins, D., Weiland, W., Designing to facilitate browsing:
| a look back at the Hyperties work station browser Hypermedia,
| vol. 3, 2 (1991)101-117.
|
| PS: For another fun historic video showing very early embedded
| graphical links (may be the 1st such link) + revealing all the
| links/menu items + gestures for page navigation
|
| * HCIL Demo - HyperTIES Browsing
|
| https://www.youtube.com/watch?v=fZi4gUjaGAM
|
| https://news.ycombinator.com/item?id=11319498
|
| DonHopkins on March 19, 2016 | parent | context | favorite |
| on: Motion Design Is the Future of UI
|
| User interfaces should always be able to lead, follow, or get
| out of the way. Animation should never delay interaction, and
| it should never interfere with gestures and mouse-ahead (or
| whatever the input device is).
|
| The user should never have to wait for animation to finish
| before they're able to do something, and the interface should
| never be disabled during animation, or ever ignore the user's
| input under any circumstances.
|
| User input should always pre-empt and interrupt feedback and
| animation.
|
| The interface should always support quick gestures (mousing
| ahead, touching ahead, or whatever), without ever requiring the
| user to pause and wait, or focus their attention on the screen
| to watch the animation play out before they know it's safe to
| make the next move.
|
| I developed a gestural pie menu tabbed window manager for the
| NeWS window system in 1990, which supported mousing ahead,
| suppressing the pie menu display and pop-up animation until you
| stopped moving, showing light weight feedback on the overlay
| plane, and executing commands instantly without any animation
| or even popping up the menu, when you make a smooth quick
| gesture without hesitating.
|
| NeWS Tab Window Demo:
|
| https://www.youtube.com/watch?v=tMcmQk-q0k4
|
| https://donhopkins.com/home/movies/TabWindowDemo.mov
|
| Transcript of the relevant part of the demo:
|
| Now you can press the right button to pop up a pie menu on the
| tab or on the frame itself. And that has commonly used commands
| like front and back in mnemonic directions. Back is down, and
| front is up.
|
| When you make a menu selection by mousing ahead, it doesn't
| display the menu.
|
| As long as you're moving, it suppresses the menu display.
|
| And it gives you feedback on the overlay plane of the slice
| that you're in, and the label of that slice, so you can
| actually see what you're going to get before you choose it
| without even seeing the menu itself.
|
| And when you wait, it pops up the menu once you stop moving.
|
| So if you waste some time by just waiting around, it will waste
| a bit more time by giving you some stupid animation.
|
| And this is meant to be negative reinforcement, to encourage
| you to mouse ahead.
|
| The sub-menu pops up. This is "move to" which is unconstrained
| move.
|
| You can always get that from the tab by mousing left and right.
|
| That's an easy gesture. Just quickly...
|
| Or mouse there and wait. There it is. It pops up the one you're
| at first.
|
| This is constrained horizontal move.
|
| And this is constrained vertical move.
|
| So constrained horizontal... We'll wait.
|
| Constrained vertical...
|
| So, I mean, once you're there, and you know what you want, why
| wait?
|
| This is "beam me up": put it in the next layout position. To
| tidy the windows.
|
| So, if you've clicked the menu up and haven't moved, it will
| just spin it, because it's confused, and doesn't know what
| you're going to do.
|
| ----
|
| In other words: As it pops up and scales up the round menu, it
| also tilts it along the axis perpendicular to the direction of
| movement to reinforce the selected direction, or spins around
| the center if you haven't moved to show no direction is
| selected.
|
| And you only ever see any animation if you actually stop moving
| -- once you make a selection, the command always executes or
| the submenu always activates immediately.
|
| You can mouse ahead smoothly through multiple levels of sub-
| menus, without popping any of them up or seeing any animation,
| as long as you never hesitate.
|
| By "lead, follow, or get out of the way", I mean that pie menus
| can lead novice users by giving them feedback and animation
| when they pause, follow intermediate users who move in the
| right direction then pause for the feedback to make sure they
| got it right, and get out of the way of expert users who know
| the right direction and can quickly articulate gestures without
| pausing or waiting for feedback.
|
| ----
|
| Here's another demo showing pie menus, mouse ahead gestures,
| and display pre-emption in SimCity:
|
| X11 SimCity Demo:
|
| https://www.youtube.com/watch?v=Jvi98wVUmQA
|
| ----
|
| And here's a really old demo from June 1986 of the "uwm" window
| manager for the X10 window system, that I hacked to support pie
| menus with mouse-ahead and display pre-emption.
|
| X10 Pie Menu Window Manager:
|
| https://www.youtube.com/watch?v=IJhvB6kwmog
|
| ---
|
| More info here:
|
| The Design and Implementation of Pie Menus -- Dr. Dobb's
| Journal, Dec. 1991:
|
| https://donhopkins.medium.com/the-design-and-implementation-...
| joeblubaugh wrote:
| 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.
| DonHopkins wrote:
| Pie menus work well with trackpads and trackpoints
| (keyboard clitoris), as well as analog and digital 4- or
| 8-directional joysticks, and even numeric keypads and arrow
| keys.
|
| If you arrange your menus into 4- and 8-item pie menus,
| they are uniformly navigable and memorable for many types
| of input devices including keyboards. Four and eight items
| are ideal for muscle memory, and also cognitive memory too.
| So using pie menu layouts that map directly to keyboards
| and digital joysticks works really well.
|
| The ActiveX pie menus I implemented for Internet Explorer a
| couple decades ago supported full keyboard navigation:
|
| https://www.youtube.com/watch?v=nnC8x9x3Xag
| cyberax wrote:
| Basically, you use cursor keys to select the direction. So
| you can just memorize the paths to the correct items.
|
| Modern console games use the same idea for communication
| wheels, that are usable from game controllers.
| llanowarelves wrote:
| Thanks. A lot of good stuff here that may go overlooked.
| eviks wrote:
| 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)
| throwaway2037 wrote:
| > 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.
| PennRobotics wrote:
| 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.
| joshuaheard wrote:
| "For example, users should not have to retype an entire name-
| address form if they enter an invalid zip code but rather should
| be guided to repair only the faulty part."
|
| This is my biggest pet peeve, and I still see it. It should also
| be true for multi-page forms if you are going back and forth
| between form pages.
|
| "Erroneous actions should leave the interface state unchanged, or
| the interface should give instructions about restoring the
| state."
|
| Designers seeking to save space on small screens like phones and
| watches are increasingly relying on icons. However, many icons
| are unfamiliar or hard to decipher. Sometimes, the only way to
| figure it out is to click on it. Every such icon should have a
| way to go back to the original state if a mistake is made.
| ShadowBanThis01 wrote:
| Annoying as shit. If I'm trying to log into something with an
| E-mail address (already a fail, but that's another topic) and
| password, and I click "forgot password," don't take me to a
| form where I have to re-enter the goddamned E-mail address I
| JUST ENTERED.
| nox101 wrote:
| Or every customer service phone line where the automated
| system asks for your info (account# or phone#) and then the
| customer service rep asks again >:(
| rrr_oh_man wrote:
| That is only to keep you busy and engaged
| esafak wrote:
| I just engaged the close button.
| bluGill wrote:
| In some cases this is a verification and reques, for more
| information. when doctors reask what the nurse just asked.
|
| most of the time it isn't. the doctor already knows what
| you told the nurse. (where the doctor doesn't that is bad)
| ShadowBanThis01 wrote:
| I actually bring this up when they ask me again. "Didn't I
| just enter that?"
| akavi wrote:
| Or its twin cousin: forcing me to login after updating my
| password.
| Cockbrand wrote:
| I assume that this is to help the user memorize their new
| password. I know we on HN all use password managers, but
| most people out there don't.
| pugworthy wrote:
| Right. And if I type in "Corvallis", ask me "Oregon or
| Montana?" If I type in "97330" just skip the rest.
| Stenzel wrote:
| Title should say screen design, for general UI these are quite
| useless, especially if your UI is physical.
| madeofpalk wrote:
| 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.
| breadwinner wrote:
| > _gray out menu items that are not appropriate_
|
| Don't do this unless it is obvious why it is grayed out. Commands
| should be left enabled, then an error message should be displayed
| when the command is clicked and the command is unavailable, and
| in this case explain why it is presently unavailable. It is
| frustrating to the user to figure out why a command is disabled.
| The only time to not leave commands enabled is if the user is
| likely to end up wasting a lot of time only to be told at the end
| that the command is unavailable.
|
| Update: Read more about this in this article:
| https://medium.com/@vedranio/james-bond-and-the-design-of-di...
| arcanemachiner wrote:
| Sure, but there should be some kind of consistent visual
| affordance that conveys that the action is disabled, _before_
| the user clicks on it.
| breadwinner wrote:
| 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.
| euroderf wrote:
| > Commands should be left enabled, then an error message should
| be displayed when the command is clicked and the command is
| unavailable, and in this case explain why it is presently
| unavailable.
|
| An exception to this: premium (for-pay) features.
|
| There is a certain To-Do app that does this. Premium commands
| are visually indistinguishable from freemium commands, so they
| get clicked a lot and they interrupt the entire experience with
| nag dialogs.
|
| A serious UI error IMO.
| carlosjobim wrote:
| It's not an error, it's deliberate.
| euroderf wrote:
| It's deliberate AND an error.
| verinus wrote:
| I disagree. Disabling an action that is not feasible in the
| current context IS helpful, but ONLY if you provide an
| explanation on WHY.
|
| UIs that simply disable certain actions without telling me why
| always infuriate me :(
| gpderetta wrote:
| Even better[1]: GUIs that hide actions that are not feasible.
|
| [1] and by better I mean worse.
| nirimda wrote:
| 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.
| moring wrote:
| > Don't do this unless it is obvious why it is grayed out.
| Commands should be left enabled, then an error message should
| be displayed when the command is clicked and the command is
| unavailable, and in this case explain why it is presently
| unavailable.
|
| Why not grey out these menu items, but still show the exact
| same message when you click them? That seems to be the best of
| both worlds to me.
| breadwinner wrote:
| Because users are accustomed to grayed out items not
| responding to mouse clicks, so they will never click it.
| KineticLensman wrote:
| > Update: Read more about this in this article
|
| I read the article (TL;DR it describes a bond car that lets
| Bond select a weapon only to then give him an error message
| saying 'ammunition not loaded', and then considers how this
| should be handled from a UI perspective).
|
| Thinking about the overall UI guidelines topic, the bond
| article misses an obvious point - that cars already have
| familiar mechanisms for displaying the status of consumables
| such as fuel, oil and battery: gauges on the dashboard.
| Applying the consistency guideline, Q could have installed an
| ammo gauge, and the 'backfire' button would then be permanently
| available. After all, Bond might still wish to deploy the gun
| for effect, e.g. to intimidate someone, even if he knows that
| there isn't in fact any ammo.
| La-Douceur wrote:
| How about graying out the button, but adding a tooltip on hover
| that tells the user why they can't click
| bithive123 wrote:
| Although not really part of a UI's "design", performance is often
| overlooked as well. A poorly performing UI violates every single
| one of these design rules. My sony android smart TV looks amazing
| but the UI is so slow as to be unusable.
|
| An unstable UI that is always changing also violates most of
| these principles. Smart TVs seem to be exceptionally bad in this
| area too, with the home screen layout and app icons frequently
| changing positions for no apparent reason.
|
| While I'm complaining, my other pet peeve, which unfortunately is
| only getting worse is: unlabeled icons (often without even
| tooltips). If I have to google for documentation to know what a
| button is called, your UI design is bad!
| godzillabrennus wrote:
| 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.
| busymom0 wrote:
| I think this has been observed by others too:
|
| > Snapchat's UI Receives Backlash From Users for being too
| complicated. However, Snapchat's user experience is not bad.
| It's actually an incredibly smart design. Their challenging
| user experience is what keeps them relevant to their primary
| target audience: teenagers and millennials.
|
| > It keeps the adults out..Snapchat is a safe place for
| teens. They intentionally made the user interface challenging
| to grasp in order to make it difficult for adults to use.
| Most adults would not bother putting up the effort to learn
| how to use the app, leading to its abandonment. All content
| is ephemeral with strict limitations on editing. Most content
| is sent privately, and no content can be publicly rated or
| compared. Adults would not bother putting up the effort to
| learn how to use the app, leading to its abandonment. This
| limits Snapchat's user base to teenagers.
|
| https://uxmag.com/articles/how-snapchat-and-netflix-break-
| ux...
| threethree wrote:
| Very interesting. Yeah I think bad UI could be a way to
| gatekeep. 4chan for example has its mostly-unchanged now old-
| school interface, with its own quote/reply system, which some
| call an IQ barrier. That plus all the lingo. It typically
| gives out outsiders (journalists, govt agents, new users etc)
| bheadmaster wrote:
| > 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.
| staunton wrote:
| > I also think this site employs the same filter, whether
| intentionally or not.
|
| Definitely intentional.
| 98789992165 wrote:
| 4chan - smart people acting dumb
|
| HN - dumb people acting smart
| AJ007 wrote:
| 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)
| pprotas wrote:
| Interesting, after reading your comment I've decided bad UI
| is subjective. I'm gen z, and never found Snapchat's UI to be
| confusing, and none of my gen z friends have ever complained
| about it, either.
|
| > They flock to difficult to use interfaces that become an
| insider feature for young folks to keep their parents out.
|
| This part might be true on a subconscious level (or it might
| be part of Snapchat's design philosophy), but do you think
| younger generations really choose apps for this reason on
| purpose?
| beowulfey wrote:
| Bad UI is just one that breaks the patterns we're used to.
| If you're young and learning fresh patterns it doesn't
| matter as much
| asoneth wrote:
| 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.
| thworp wrote:
| I think it's all just decreasing neural plasticity and having
| more routine you need to break.
| weinzierl wrote:
| One could say the same thing about the command line and
| software like vim being made to keep the youngsters out.
| lcnPylGDnU4H9OF wrote:
| Not that I agree with GP but this comment doesn't make any
| sense. I don't think any serious software product was made
| specifically to be difficult to use for young people and
| I'm _certain_ such an endeavor would fail or otherwise be
| difficult to use for anyone. Young people are the ones who
| will try to^W^W get DOOM to run on their smart toothbrush.
| CyberDildonics wrote:
| Those interfaces were made out neccesity before graphical
| interfaces existed.
| mortenjorck wrote:
| 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.
| esafak wrote:
| Hardware companies aren't known for their UX chops.
| throwaway2037 wrote:
| 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.
| esafak wrote:
| 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.
| fireflash38 wrote:
| The trend of everything having only one physical button
| _sucks_. Press and hold for X seconds to do one thing. Tap
| then hold to do Y. Double tap for a third.
|
| And they do it for like 20 functions.
| esafak wrote:
| They should combine buttons with a touchscreen. 80s
| remotes sometimes had too many buttons:
|
| https://images3-hu-secure.gs-
| static.com/products/4096x4096/2...
| rubidium wrote:
| UX started with hardware, it was just called human factors.
| And most of what they came up with then gets forgotten today.
| weinzierl wrote:
| _" unlabeled icons (often without even tooltips)"_
|
| The worst software I worked with in this regard was CATIA V5.
| It had not only hundreds of little icons in the UI, but they
| were also used in the documentation. The manual regularly said
| things like _" Todo X first click [], then [] and finally go to
| [] to do []."_
|
| This is from the very first versions of V5, so many years ago,
| and hopefully has improved.
| albert_e wrote:
| > ... first versions of V5
|
| So "V5" is not "version five" of something?
|
| God.
| weinzierl wrote:
| 5 is the version, but has been the current version for 26
| years by now. I should have said the first releases of V5
| or whatever they are called.
|
| That's not to say there hasn't been a version 6 at some
| point, but the most recent version is still 5.
| heresie-dabord wrote:
| > Although not really part of a UI's "design", //talking to the
| customer// is often overlooked as well.
|
| The single biggest cause of failure in UI design is isolation
| from the users and their requirements.
|
| Everything else is coding.
| kazinator wrote:
| Where are the apps shipped by umn.edu?
| subroutine wrote:
| Universities teach students about a lot of things they don't
| actually create themselves.
| DonHopkins wrote:
| What does the University of Minnesota Twin Cities have to do
| with this discussion? And why do you care which apps a
| university research lab shipped? ;)
|
| If you want to know about what contributions Ben Shneiderman
| and his University of Maryland Human Computer Interaction Lab
| have made, you can read my other post:
|
| https://news.ycombinator.com/item?id=38920423
|
| Or wikipedia:
|
| https://en.wikipedia.org/wiki/Ben_Shneiderman
|
| https://en.wikipedia.org/wiki/University_of_Maryland_Human%E...
|
| Or Ben Shneiderman's home page:
|
| https://www.cs.umd.edu/users/ben/
|
| One app that the UMD Human Computer Interaction Lab shipped in
| several versions was HyperTIES, which was used to implement
| "Hypertext on Hypertext" that ACM distributed with the articles
| from the July 1987 Hypertext conference, which influenced Tim
| Berners-Lee to make hypertext links blue:
|
| The Interactive Encyclopedia System:
|
| https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_S...
|
| HyperTIES Discussions from Hacker News:
|
| https://donhopkins.medium.com/hyperties-discussions-from-hac...
|
| >Don Hopkins sent the following message at 10:07 AM, AUG 28,
| 2021
|
| >Why are hyperlinks blue?
|
| >Hello Elise. Here is some information about why hyperlinks are
| blue, from Ben Shneiderman's answer to a question I asked him
| about the origin of the term "hyperlink". I think your belief
| that HyperTIES was not the first instance of blue hyperlinks
| because it used cyan links is splitting hairs, and a "No Blue
| Scotsman" argument, especially since Tim Berners-Lee told Ben
| Sheniderman at the time that he was influenced by Ben's design
| as he saw it in the HyperTIES-based "Hypertext on Hypertext"
| that ACM distributed with the articles from the July 1987
| Hypertext conference at the University of North Carolina. Ben
| describes the color as "light blue", which he chose from the
| limited palette available on PCs at the time, based on
| controlled experiments he and his students performed comparing
| user comprehension and recollection.
|
| https://news.ycombinator.com/item?id=28317104
|
| HI Don (and Jack Gilmore),
|
| Thanks for including me in this conversation.
|
| I do not have a claim for the term "hyperlinks" and don't know
| when it came into use. My claim is for the visual interface for
| showing highlighted selectable links embedded in paragraphs.
| This is what we called embedded menu items in that I think is
| an influential paper on the topic, which was peer-reviewed and
| published in the CACM in April 1986.
|
| https://dl.acm.org/doi/10.1145/5684.5687
|
| http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf
|
| While Engelbart had shown a list that could be selected by
| pointing and clicking in 1968, I claim the idea of embedded
| highlighted selectable text in paragraphs. This was implemented
| by grad student Daniel Ostroff and described in:
|
| Ewing J, Mehrabanzad S, Sheck S, Ostroff D and Shneiderman B
| (1986), "An experimental comparison of a mouse and arrow-jump
| keys for an interactive encyclopedia", International Journal of
| Man-Machine Studies, Jan., 1986, Vol 24, pp. 29-45.
|
| [Abstract] [BibTeX] [DOI]
|
| Ostroff D and Shneiderman B (1988), "Selection devices for
| users of an electronic encyclopedia: an empirical comparison of
| four possibilities", Information Processing and Management,
| Nov., 1988, Vol 24(6), pp. 665-680.
|
| [Abstract] [BibTeX] [DOI]
|
| I think the 1988 paper was the earlier study, but the
| publication took a while.
|
| My students conducted more than a dozen experiments
| (unpublished) on different ways of highlighting and selection
| using current screens, e.g. green screens only permitted, bold,
| underscore, blinking, and I think italic(???). When we had a
| color screen we tried different color highlighted links. While
| red made the links easier to spot, user comprehension and
| recollection of the content declined. We chose the light blue,
| which Tim adopted.
|
| His systems with embedded menus (or hot spots), where a
| significant user interface improvement over early systems such
| as Gopher. But Tim told me at the time that he was influenced
| by our design as he saw it in the Hypertext on Hypertext
| project that we used Hyperties to build for the July 1988 CACM
| that held the articles from the July 1987 Hypertext conference
| at the University of North Carolina. The ACM sold 4000 copies
| of our Hypertext on Hypertext disks.
|
| Our history is here:
|
| https://www.cs.umd.edu/hcil/hyperties/
|
| and the video is very helpful in showing the design we used,
| which is what I think Tim built on for his WWW prototypes.
|
| https://www.youtube.com/watch?v=29b4O2xxeqg
|
| So in summary, I don't know who coined hypertext, but I do
| think our work visual and interaction design was influential.
|
| Our Hyperties system was picked up by Cognetics Corporation
| (around 1987) who made a modestly successful commercial run
| with it, doing dozens of corporate projects, most notably the
| Hewlett-Packard user manual for their Laserjet 4 was
| distributed as a Hyperties disk.
|
| Hyperties was the name we shifted to after we got a stop and
| desist order from a lawyer because our TIES (The Interactive
| Encyclopedia System) conflicted with an existing product. By
| then "hyper" was a growing term.
|
| Let me know if this helps, and what other questions you
| have.... Ben
|
| ----
|
| HCIL also shipped various treemapping applications:
|
| https://en.wikipedia.org/wiki/Treemapping
|
| >Area-based visualizations have existed for decades. For
| example, mosaic plots (also known as Marimekko diagrams) use
| rectangular tilings to show joint distributions (i.e., most
| commonly they are essentially stacked column plots where the
| columns are of different widths). The main distinguishing
| feature of a treemap, however, is the recursive construction
| that allows it to be extended to hierarchical data with any
| number of levels. This idea was invented by professor Ben
| Shneiderman at the University of Maryland Human - Computer
| Interaction Lab in the early 1990s. [21][22] Shneiderman and
| his collaborators then deepened the idea by introducing a
| variety of interactive techniques for filtering and adjusting
| treemaps.
|
| https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf
|
| https://treemapart.wordpress.com/
| bluGill wrote:
| To someone in Minnesota umd means university of Minnesota
| Duluth campus.
| ShadowBanThis01 wrote:
| It's missing a critical one, which once seemed obvious:
| Distinguish between static information and controls.
|
| Also, don't HIDE inapplicable controls; GREY THEM OUT. That way
| people learn
|
| 1. They exist 2. Where they reside 3. There's some condition to
| satisfy before they can be used
|
| Related: Never, never rely on peek-a-boo UI that hides things
| unless the user accidentally rolls the cursor over them. I'm
| trying to get shit done, not explore an Advent calendar.
| 23B1 wrote:
| 9. The actual golden rule: don't create UX that you yourself
| would find hostile.
| dang wrote:
| Related:
|
| _Eight golden rules of user interface design_ -
| https://news.ycombinator.com/item?id=36652355 - July 2023 (1
| comment)
|
| _8 Golden Rules of Interface Design_ -
| https://news.ycombinator.com/item?id=233654 - July 2008 (7
| comments)
| wouldbecouldbe wrote:
| The Golden Rules of obvious Utopia.
|
| I think most of us won't disagree with these rules.
|
| Yet also most devs will have worked on interfaces that break
| these rules often. Not because we didn't understand or didn't
| want, just that the cost was too high at that point.
|
| For instance reversibility is very difficult and only possible if
| the datastructure under the application is build up with this in
| mind. Or take preventing errors, often it's very difficult and
| costly to know exactly what errors are, and ever more complicated
| to provide perfect feedback to a user in their own language.
| bob1029 wrote:
| > Sequences of actions should be organized into groups with a
| beginning, middle, and end. Informative feedback at the
| completion of a group of actions gives users the satisfaction of
| accomplishment, a sense of relief, a signal to drop contingency
| plans from their minds, and an indicator to prepare for the next
| group of actions.
|
| This is why we built our product around a workflow abstraction.
| Everything the user can do is some workflow implementation with a
| # of discrete steps. Our criteria for the scope of a step is
| guided by a dark and mystical process wherein we all argue about
| the business for a few hours and then sketch out some prototypes.
| One trick is to design these with lego-like reuse in mind.
| Oftentimes, the business will have the exact same view used
| across a wide range of activities.
| rrr_oh_man wrote:
| Care to share the product?
| dmalik wrote:
| A lot of these rules are taken care of by design systems these
| days. If you're off developing your own design system or creating
| custom components the laws of UX are far more useful.
|
| https://lawsofux.com/
|
| Here are a few that relate to laws:
|
| Strive for consistency - Jakobs law
|
| Reduce short-term memory load - Millers Law
| bluSCALE4 wrote:
| I think undo and history is vastly underrated. Lots of systems
| have activity logs but not many associate anything actionable to
| them.
| causality0 wrote:
| 0. Don't change things just for the sake of justifying your
| employment as a UI designer.
|
| The software I use with the best UI is also the software I use
| with the oldest UI.
| pugworthy wrote:
| 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...
| GMoromisato wrote:
| The one "rule" I wish it covered is about surfacing/exposing the
| conceptual model to the user.
|
| If I don't understand the conceptual model of the product, I will
| always be confused, no matter how well-labeled the icons are. For
| example, imagine a product that has a "New Configuration"
| command. What is a "Configuration"? Is it like a template that
| lets me define other objects? Is it a way to rapidly switch
| between different sets of options? Is it a container, like a
| folder?
|
| The UI must be designed so that the user can infer the conceptual
| model just from exploring the interface. This is not always easy.
| Ygg2 wrote:
| Point of good interface is to hide implementation detail while
| guiding you towards your goal.
| nirimda wrote:
| To be clear - the conceptual space the software is built
| around isn't an implementation detail. It's the way you reach
| your goal; it necessarily imposes a burden on the user. A
| good conceptual space presses less heavily against the user,
| but you can't obscure the notion that there are containers in
| a file system but not a relational database.
| moring wrote:
| There is always the discussion whether the UI should "hide
| the implementation details" (make the internal model, which
| differs from the conceptual model, invisible -- resulting
| in hard-to-understand behavior) or "make the implementation
| details visible" (change the conceptual model to be equal
| to the implementation model, and force the user to adapt to
| that).
|
| But the one option that is rarely used but yields the
| (IMHO) best results is: design the conceptual model, then
| build/change the implementation model to be equal to it.
|
| One example for this strategy that is forever stuck in my
| head is macOS application folders. The conceptual model is
| that an application can be moved around like a file, and
| applications be organized in folders like files. But you
| also want to run an application by double-clicking it.
| Instead of what Windows (and then Linux) did with links,
| menus, installing applications and centrally registering
| them etc., the implementation was changed to be like the
| conceptual model. A whole class of errors from
| inconsistencies just vanished.
| Ygg2 wrote:
| I'd argue the implementation detail is still hidden. You
| don't know if Applications use FUSE or are WASM
| containers or docker images or what not.
|
| Interface is a translator between what user understands
| ("I press button, channel changes") and implementation
| detail ("rubber dome changing resistivity, ...causing IR
| signal to be sent", ...).
| GMoromisato wrote:
| Excellent point and example!
|
| Joel Spolsky described these as "leaky abstractions". If
| the implementation does not quite match the conceptual
| models, then the implementation "leaks out" to the user.
| The user is confused because the UI does not match the
| conceptual model in their head.
| GMoromisato wrote:
| Exactly!
|
| Usually, the designed conceptual model imposes constraints
| on the implementation. Sometimes, the implementation
| affects the conceptual model (a leaky abstraction). But
| they are logically orthogonal.
|
| And you can't "abstract away" the conceptual model as if it
| were an implementation detail. The conceptual model IS the
| abstraction!
| oivviopolite wrote:
| 1. Set your page margin to 0px.
| ozim wrote:
| One thing is that some times some things have to be made harder
| for end users good or for business rules protection.
|
| It is sometimes hard to explain but as an example - delete
| confirmation - it gets in the way of user because user wants to
| delete stuff and be done with it. Preventing accidental deletes
| is more important than any specific user convenience.
|
| Keep in mind this is most generic example I came up with on the
| spot. There are more complex scenarios that are complex for the
| same reasons. But I find people trying to remove such fences even
| if they don't know why they're there. Claiming simplicity and
| user convenience as golden rule.
| Kranar wrote:
| 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.
| tsunamifury wrote:
| 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.
| eviks wrote:
| 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)
| guardian5x wrote:
| I would like to add: "Live up to expectations" in a sense that
| there are so many Websites or UIs there, that most users have
| some sort of expectations, on where to find the menu, how to go
| back etc. How this and that buttons should behave. Even though,
| you might have a great idea, it might just confuse the user, if
| it is totally different than what the "standard" is.
| whycome wrote:
| Everyone wants to create new expectations and hope they become
| the new standard
| beefield wrote:
| I think it would be important to understand the distinction
| between two types of applications, I call them "utilities" and
| "tools" here.
|
| Utilities are things that should be designed with the current
| typical paradigm of simplicity and discoverability to extreme. I
| should not need to read user manual for my toaster or microwave.
|
| Tools then, should be pretty much the opposite. It should be fine
| and expected to invest some time to learn the efficient and safe
| usage of the tool. There is no reason to have a intuitive
| interface on your tool, as long as it is efficient after you did
| your training. Vim is way better editor than notepad, but I don't
| think anyone praises it for the intuitively easy to use.
|
| And the peeve here is of course that way, _way_ too often these
| are confused.
| stronglikedan wrote:
| 9. Stop popping in something else in place of what I'm just about
| to select, causing me to select the wrong thing! (I know this
| maybe violates or can be mitigated by some of the previous rules,
| but it is the one thing that drives me absolutely bonkers, and I
| consider it to be a particularly egregious mistake.)
| tech2 wrote:
| Jira and the Unassigned/Automatic selection when trying to
| change a story assignment, I'm looking at YOU in particular!
| andsoitis wrote:
| Nielsen's 10 usability heuristics for user interface design gives
| a good north star:
|
| 1. Visibility of system status
|
| 2. Match between system and the real world
|
| 3. User control and freedom
|
| 4. Consistency and standards
|
| 5. Error prevention
|
| 6. Recognition rather than recall
|
| 7. Flexibility and efficiency of use
|
| 8. Aesthetic and minimalist design
|
| 9. Recognize, diagnose, and recover from errors
|
| 10. Help and documentation
|
| https://www.nngroup.com/articles/ten-usability-heuristics/
| lcuff wrote:
| The contrast between this Nielsen-Norman (NN) page and the OP
| page is marked. The NN page is much easier to absorb the
| information. More succinct, way better page layout.
|
| Both articles have information/direction worth heeding, but
| there is irony in the fact that the OP page adopts same-text
| size and paragraphing conventions of yesteryear that the NN
| page does away with.
|
| It's also frustrating that Hacker News doesn't pay attention to
| some of the information. In creating an edit to an existing
| post, the feedback after clicking on the 'update' button is not
| as clear as it should be. (It's a screen redraw, I guess).
| nyreed wrote:
| One golden rule that I learned is that interface elements should
| not move unexpectedly after the interface has been drawn. Google
| is particularly bad for buttons which move between you lifting
| your thumb and pressing the screen, but they're not alone.
| jetrink wrote:
| I wish this would be addressed at the OS level. If a target
| popped into existence less than ~0.25 seconds before it was
| touched, a touch event shouldn't be generated. Humans reaction
| times aren't fast enough to hit a button that quickly anyway.
| murermader wrote:
| Great idea. Should also take into account misclicks directly
| after layouts shifts in some websites.
| zestyping wrote:
| This one simple information-theoretic principle is an effective
| guide for user interface design: Things that
| are the same should look the same, and things that are different
| should look different.
|
| Your UI conveys information to the user, and the user has finite
| cognitive capacity for receiving and interpreting that
| information. So keep the the signal-to-noise ratio high!
|
| In my experience, a large portion of the user experience problems
| in real products are consequences of violating this principle.
| Construed broadly, this principle implies many design guidelines,
| e.g.:
|
| - If the user changes something, make the change immediately
| visible
|
| - If internal state affects what the user can do, make it visible
|
| - Don't use nonstandard interface widgets or icons
|
| If you can get this right, you're a lot of the way there.
___________________________________________________________________
(page generated 2024-01-09 23:01 UTC)