Gregory's Server19. Don't force the user to remember things if you can help it. Humans are really bad at remembering things. This includes passwords, sms codes, sums, function names, and so on. My own personal philosophy is to consider humans a part of your system, and design around our shortcomings instead of thinking of users as adversaries. Software should serve humans, humans shouldn't serve software.
|
142 comments
The first 8 items of this thread are extremely terse, to the point of being meaningless on their own. Please use them as search terms, or ask me to expand on them when my dog isn't barking at me to go to bed. 21. Gall’s Law: 22. show, don’t tell. lengthy tutorials and “protips” forced on the user at app start usually do nothing other than get in the way of the user’s task. if you want to teach the user about a feature, include easy to find examples. 23. don’t interrupt flow of thought. if a user is opening an application, they usually have some specific task to complete. nagging them at this point in time about software updates or handy tips is very user hostile. 24.many jokes are made about the “save” icon looking like a floppy disk. it’s very appropriate, since the command as a concept is built around the technological limits of floppy disks, limits that are comically irrelevant in the 21st century.drag your app out of the 1980s and implement autosave and version control already. 25. consistency consistently consistent. there’s few things more fun than designing your own custom ui widget toolkit, css framework, or interaction paradigm. however, please strongly consider *not* doing this. custom UI is like ugly baby photos. instead, stick as much to the HIG guidelines and conventions of the platform you are on, so users can use what they’ve already learned about where things usually are, and what the fuck the weird molecule icon does. 26. try to imagine ways to use your shiny new software to abuse, harass, stalk, or spy on people, especially vulnerable people. ask a diverse range of people to do the same. 27. UX is ergonomics of the mind (and also body). Where traditional ergonomics considers the physical abilities and limits of a human body, UX considers the limits of the human mind: attention, memory, response time, coordination, emotions, patience, stamina, knowledge, subconscious, and so on. If you ever find a UX practitioner sacrificing accessibility on the altar of so called “good experiences”, you are dealing with incompetence. expanding on 1. Natural Mapping: 2. Visibility of System State: 3. Discoverability 4. Constraints and Affordances. constraints and affordances is at the heart of the “flat design” vs. “skeumorphism” debate. the benefit of skeumorphic interfaces is that replicating the look of real world objects like buttons, provides a natural way to communicate interactions. where skeumorphism went wrong is communicating false affordances: a detail in the ios6 calendar app hinting that pages could be torn out- when no interaction supported it. 5. Habits and Spatial Memory an example of this persistence of space concept is the meticulous way some people curate their phone’s launch screens. even better would be if iOS allowed a different wallpaper for each page, and for icon grids to permit gaps anywhere instead of forcing them to sort left to right, top to bottom. the different look of each screen could then be very personal and memorable. Finding an app, then, a matter of finding the page with the right color and shape. 6. Locus of Attention 7. No Modes modes are typically employed as solutions to the situation of the number of functions in a system far exceeding the number of available external controls. this can happen either as a result of featuritis, or an apple-esque fetish for small numbers of buttons. another way of looking at this is examining how much context a user needs to understand what effect a gesture will have, and how effectively that context is being communicated. Can i write a step for step guide to doing a task on a computer, for a computer novice, that doesn’t include first determining where in the operating system you are, whether the correct application is open, figuring out which of many methods can get you into that apllication are applicable in that situation? this is what was nice about the “home” button on iphones: it doesn’t matter where you are in the system, there’s a physical hardware clicky button that will always bring you back to the start, and cannot be overriden by third party software. 8, Fast Feedback 17. Consider the 3 important limits of your user's patience: https://www.nngroup.com/articles/response-times-3-important-limits/ why is this important? because without fast and constant communication, the UI will feel broken. it’s why a chattering cli log *feels* faster than a crawling progress bar. the gui might, on stopwatch time, be faster than the CLI, but time *perception* works differently, it works with feedback and delays. a multifaceted solution to alarm fatigue (pdf) https://delftdesignlabs.org/wp-content/uploads/2017/07/124-nlugtenburg.pdf 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.  @zensaiyuki I find it interesting that these benefits & drawbacks can vary a lot between different configuration options. e.g. letting users set the (default?) font for websites can both help accessibility, and is trivial to implement because it's just a "magic number" used during rendering. @alcinnz also, that option doesn’t otherwise change the behavior of gestures. the example raskin uses is the configurable toolbars of some 1990s versions of MS Word. convenient if you’re a power user, but now you can’t document those shared installations (households, libraries, schools) of msword for novices because the toolbars could contain literally anything. @alcinnz after reading raskin’s book I became hardline against configuration: especially since it would be a topic of argument whenevee apple would change something in OSX (just add a configuration switch!). and so, upon approaching a stranger’s macbook you now have no idea which way the scroll gesture will scroll. however I’ve softened now that I’ve realised some configuratoon options are essential for accessibility. @alcinnz on the opposite end of the spectrum, the gnome project is now discovering that too much configurability can be a curse. there’s so many theme options in gnome now it’s impossible to write an app and test for every possible configuration. most of the devs are forced to make the unsatisfactory tradeoff of testing only with default configurations. (which it seems, taken as a whole across all software, default settings become a defacto platform. changing them puts you in weird bug land)  @zensaiyuki I do try to adhear to this for Odysseus (in bridging between an elementary OS & Web experiences), but for my other browser(s) I'm guilty of all three. But really that's in the name of giving webdevs something even cooler to play with: Building webpages that works great on absolutely any device and/or OS! @alcinnz i wouldn’t begrudge anyone their fun or their experiments trying to push the state of UI forward. brace for failure though. hopefully the “ugly baby photos” metaphors makes sense. years ago I took a photography class that forbade pet photos. Your pets always look beautiful to you, but that’s not enough to make it a good photo interesting for everyone else to look at. @zensaiyuki Well, success to me looks like webdevs building more accessible pages. For it to be feasable for others to build their own, simpler, browser engines to display those pages. And for The Web to better protect users' privacy! What I really care about are the deeper architectural issues, which I may still fail at. @alcinnz and well, more broadly, you’d have to be fairy resiliant and inattentive to not have been occasionally annoyed by some electron app or cross platform ui toolkit completely breaking the conventions of your os, perhaps even having non standard keyboard shortcuts. or the morass of the linux/unix world where you’d be hard pressed to find any standards whatsoever. the trouble with quitting vim, for instance, isn’t that it’s hard to learn, it’s that it’s not just control+c or control+d @zensaiyuki This has been one reason I've looked at moving away from Atom. I often perform `git commit` from the command line and use my editor for filling in the message. The 1s or 2s load time is enough to disrupt my thoughts. I switched to vim for a bit, and that is quite snappy. As I'm choosing to learn emacs, I've changed to use that for my messages @takeonrules i tried atom once and immediately dumped it when it threw up a sequence of “save or discard” dialogue boxes on attempting to exit. once you’ve tried a text editor that just simply saves your workspace and then exits, upon telling it to exit, it’s hard to go back to software that doesn’t just do what you ask it to. @zensaiyuki To expand on this point: Linus only wrote his code to run on his x86. Stallman did similar for his early GNU tools. Early computers could really only handle English text, now they can easily handle practically any language. But it takes a lot more code to do so. Now these projects are totally rewritten, and much larger. |
20. Some Sources:
Donald Norman
Jef Raskin
Jacob Nielsen
Bruce "Tog" Tognazzini
I recommend all the talks by Alan Kay and Bret Victor, here's two:
Doing with Images Makes Symbols
https://www.youtube.com/watch?v=p2LZLYcu_JY
The Future Of Programming
https://www.youtube.com/watch?v=8pTEmbeENF4