|
Top-level
30. Avoid alert fatigue at ALL costs. when there’s something actually important, like a real fire, people would die, and it would be marketing directly responsible for those deaths. this is why letting app developers register notifications on your phone was a huge mistake. 83 comments
31. don’t rely on the user to have fast reaction times, or high levels of hand eye coordination. this is as much an accessibility guideline as it is a usability guideline. Primary offenders are things like double clicks, rapidly changing search results, drop down menus, popouts that rapidly appear and disappear, and in general bait and switch buttons. 32. don’t confuse a steep learning curve for bad UI. don’t confuse something that is just similar to what you’re used to for good UI. Don’t confuse the level of pain you went through to learn something with its intrinsic worthiness. The only “intuitive” interface is the nipple. 33. the subjective experience of a UI is often vastly different from the objective reality of the system, particularly with regards to perception of time and mental models about what the computer is actually *doing* and how it works. The Watched Kettle effect. For instance, shortcut keys *feel* faster but are measurably slower than just using menus. A file copy routine can be made as fast or slow as you like but the *perception* of its speed is down to how the progress bar is animated. 34. The user maintains a mental model of the system in their mind, a representation of the way the system works that helps them percieve situations, respond to situations predict outcomes and solve problems. It’s the software UI’s responsibility to either help the model become more accurate, or intentionally abstract and deflect the mental model from the truth. A user with a wrong mental model making an inaccurate prediction leads to user frustration. 35. the brain structures responsible for human memory and perception of time are wired directly to the amygdala: the seat of human emotion. a session at a computer will be represented by an episodic memory, regulated by the user’s emotional state at different points in time. frustrating experiences will be represented more prominently in memory than “average” experiences. the last experience in the episode is more prominent than experiences in the middle. our memory is structured narratively. an amusing consequence of #35 is what a study about colonoscopies can teach us about software interfaces. https://www.fool.com/investing/general/2013/06/30/the-colonoscopy-theory.aspx #37. https://lawsofux.com contains another numbered list of of principles that amazingly mostly does not overlap with this one. #38. Gestalt, or “the sum is greater than the parts” refers broadly to the repertoir of tricks the human mind has for completing patterns from incomplete evidence. I could go on and on about it, but i found this great article summing it up along with examples of how it applies to various UI situations #40. Convention over experimentation. There are many arbitrary decisions in UI design. for example: where to place the search bar? fundamentally, it doesn’t matter what you do, but if there’s an established convention please use that. Place the search bar on the upper right hand side of your global nav; not because there’s science to back that up but because if you put it there I’ll be able to guess where it is. that’s where most sites put it. Don’t make me search for search. 41. Dark Patterns so, serious question about where to go next: I have started to include, sparingly, general design and cognitive psychology principles, which I had been avoiding as while they apply, they’re not *directly* and obvioisly about UI in the specific. should I go ahead and start including more of that stuff? the lawsofux didn’t shy away.  42. for legible body text, optimal line length is 60-70 characters per line. no fewer than 35, no greater than 80. going longer than these ranges makes it difficult for the eye to track back to the beginning of each line. go shorter and reading becomes stuttered, like reading a telegram. or a toot. 43. The web, and UI frameworks will fight you on this, but if you establish a vertical rhythm in your typographic grid, you’ll increase the feeling of unity in the design and help the eye flow better across the design. Choose a verrical spacing that suits the size and style of your main text font. there’s no hard and fast rules, but it’s good to aim for the vertical spacing to be around 1.33-1.5 the point size of your body text. heading sizes can be neat integer multiples of 1/2 or 1/3 of main 44. Past the age of 40, vision tends to decline at a steady pace. mine certainly has. Us old people can’t really deal with font sizes much below 14pt- which tends to look large and goofy to younger folk. whatever size you choose or however you set up your grid, please gracefully permit users to override your choice, and ideally design and code your thing to not break when this is done. this isn’t just politeness, it’s the law in USA, the UK and Australia, along with the rest of WCAG 2.0 45. in olden times, type was carved by hand into metal for each type size. the different sizes were not just scaled versions of the same design: tiny adjustments were made for each size for color and workarounds for printing technology. With the invention of computer fonts, "hinting" was only done for screens at small sizes, wrong anti-aliasing later accidentally mimicked the effect. Few noticed laser printed documents looked slightly wrong or why. Now retina screens have the same issue. 46. Untitled%20toot%208_FINAL.docx 47. Optical Adjustment 48. Things that work different should look different. 49. Figure-Ground and sillouettes. The fastest and most well developed stage of visual recognition is of the sillouette of an object. In character design, getting the sillouette of a character to be disctinct is most important. in portraiture if you get the shape of the head right, you’re 90% there. it takes far longer to notice the interior features. time how long it takes you to spot what is wrong with adele. This is important in icon design too- don’t mask all your avatars in circles please 51. Humans make mistakes. It’s no use pretending they don’t. You’re just going to have to deal with it. So just make them easy as possible to fix. Include infinite undo, back button, home button, version control. Autocorrect, I am not so sure about. I for one don’t like the computer to insist it knows better than me and then provide no way to easily insist i am right. Let me make mistakes! just make it easy to fix them. 55. All manufactured things should be designed to be used by one hand. either hand. there are safety features of some industrial equipment that require both hands so that both hands are no where near the dangerous hand mangler part- use best judgement via @space_cadet 56. on Unskippable Cut Scenes. 57. Negativity Bias 58. more on episodic memory ever stand up to do something, walk into another toom and forget what you were doing? it turns out there’s a reason for this. since human memory is organised around episodes, experiments have found that walking through a door is a trigger for ending an episode- the result? short term memory is cleared and primed for new input. what triggers exist in software? how often have you picked up your phone to do something, saw a notification and lost your flow? 59. Please don't use confirmation dialogues, but if for some reason you absolutely must, don't sleepwalk through writing the the messages and the button labels. Don't just label them "okay" and "cancel" Without thinking about whether that wording harmonises with the message text. If possible, label the buttons as what they actually do, specifically.  @zensaiyuki This is exactly why I advise against using JavaScript's alert(), confirm(), or prompt() functions: They don't allow you to label your buttons anything other than "Okay" & "Cancel". I generally prefer native UIs, but in this case: PLEASE implement your own! Preferably something non-blocking like GTK's InfoBars.  @zensaiyuki i couldn't figure out what was wrong with Adele until i put her upside down… i hate it. @zensaiyuki It's worth noting: This is why FontConfig is part of GNOME's text stack! To allow font designers to distribute multiple font files for a single font family, so they can perform these optical adjustments for each relevant size & style. @zensaiyuki I think this idea of different fonts [in the old sense, where font implies a size as well as a typeface] not just being scaled versions of each other is something that OpenType tries to address with its parametric features. There doesn’t seem to have been much uptake of the feature though. @futzle past a certain threshold of nuance, people tend not to care. they might have the odd feeling that one peice of design seems nicer or “more expensive” than another peice but they won’t be able to put a finger on why. this level of care in web typography basically represents the tip of the diminishing returns curve: lots of effort for an implacable feeling  53. reiterating the point, is @enkiv2 “Hot UX take apparently: interactive elements should never change position except in direct response to a user-initiated input event, and should never appear or move while such an event is taking place; while they may change color or contents (for instance, a button inverting in response to a mousedown), their bounding box should never change shape during the course of any event.” Ah, this is a big concern of mine in exploring how best to replace JavaScript! I'm warry of all the surveillance it enables, but adding more permission prompts would just backfire! In order to be effective I need to master the art of subtlety! As in "ofcourse clicking this link send a network request", or "ofcourse the file I just selected will be uploaded when I submit this form".  @zensaiyuki Rob Ewashuck, Google SRE, has an excellent set of guidelines on alerting. I've discussed previously: https://old.reddit.com/r/dredmorbius/comments/2j9xri/alerting_response_google_site_reliability/  |
Gregory's Server
a multifaceted solution to alarm fatigue (pdf)
https://delftdesignlabs.org/wp-content/uploads/2017/07/124-nlugtenburg.pdf