|
Top-level
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. 105 comments
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. 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.  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 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 That GNOME case does show something interesting: It may be useful to have behind-the-scenes options to allow different platforms to share code, whilst not exposing it to end-users because it might/will break stuff. Also makes it easier for *some* apps to target a selection of those platforms. But in terms of UX this essentially comes out to the same thing as you're saying. @zensaiyuki In the case of browsers, the question seems to have always been not whether to have configuration but who should be configuring these settings. The standards now say that webdevs have ultimate say whilst browsers provide defaults. The problem though is that the defaults are no longer reasonable, and webdev's final say can't always be trusted for reasons you've described in other toots. Fairly trivial to fix when I'm not worrying about breaking JS... @alcinnz it is certainly possible and even easy to write webpages and even web apps that leave browser accessibility settings available and working. it’s an education problem though and if, i, for instance, wrote a guide on how to do it, everything in it would fly in the face currently fashionable practices, which seem to view accessibility as “old fashioned” @zensaiyuki I'm very much not a JS fan, though I have to admit that it has it's uses. I think it's a security risk that's too complex for independant browser engines to implement. But regardless of what I think of it in general, it's inappropriate to implement in my auditory & smart TV browser engines. It's I/O model doesn't line up with what I need, and it's a clearer message to tell webdevs to not rely on JS if you want to be accessible on these devices. @alcinnz i suppose the problem it solves is, if the html “document” actually represents the UI of some kind of application, it’s a bad experience to require a full page refresh for every meaningful interaction, especially form validation. forms are especially complicated for screen reader accessibility as well. @alcinnz in the less extreme case, it kind of sucks to need to listen to all the menu options over and over again on every page navigation. thankfully most screen readers are smart enough to let you skip it, so long as the page is marked up correctly and includes a “skip to content” link. @zensaiyuki Rhapsode is amongst those screenreaders: <nav> is silenced & it automatically skips to <main>. And UI buttons arbitrarily shuffling around is especially bad when navigating the page with a TV remote! I can't let it happen! Though I will be happy to allow partial page refreshes akin to Intercooler.js. @zensaiyuki Forms meanwhile are a very interesting design space for me! I might struggle to verbalize some/many forms in the wild, but with some minor HTML extensions there's opportunity to build Alexa-level conversational UIs! Though not as many as some may think due to HTML5. TVs meanwhile needs those forms rendered to their own menus. In either case I have to seperate forms out into their own mode & disallow styling to make them function well in these mediums. @alcinnz the base html form language is pretty good at expressing semantically what the form is/wants. it’s even a great API definition language, even if the apis amit describes are boring and old fashioned. ideally stuff like css/javascript is only used to enhance the experience- the forms *should* work with javascript and css fully disabled. but as we all know, they typically don’t. @alcinnz but, assuming they did, they fulful the promise of a self describing API. all a client needs to do is understand the html form and it can present any sort of UI it needs to, to fully interact with the api the form describes. it’s really under appreciated how great a design it is. @zensaiyuki Absolutely! Now can I make it a reality? The struggle ofcourse is the majority of forms which like to define their own widgets, there's no way I'll be able to handle that... |
Gregory's Server
28. making your software configurable/customisable allows you to accomodate more diverse users, but it also makes your software more complicated and harder to document and learn, since a configuration is a kind of mode.