Email or username:

Password:

Forgot your password?
Top-level
Zen

expanding on 1. Natural Mapping:
user interfaces typically “map” to the system they control, each button and dial corresponding to some element of the system. Natural mapping is when the interface forms an obvious spatial relationship to the system, such as 4 stovetop dials that are in the same arrangement as the stovetops. the anti-pattern is arranging controls in an arbitrary order with no spatial correspondence to the system.

118 comments
Zen replied to Zen

2. Visibility of System State:
Software typically has state (to state the obvious), such as “where” you are in the software’s menu system, what “mode” you are currently in. whether your work is safely stored on disk or has “unsaved changes”, what stage of a process you are up to and how many steps are left. Failure to effectively communicate system state to the user is inviting them to get lost and make mistakes. counterexamples: setting the time on a digital wrist watch, programming a VCR

Zen replied to Zen

3. Discoverability
this is about making the possible actions in a system visible- or if not immediately visible, the mechanism of their discovery should be visible and consistent. For instance, the menu items in a GUI system are discoverable. the available commands in a unix system are not. the opposite of this principle is “hidden interface”, examples of hidden interface are rife in iOS: tapping the top of the screen for “scroll to top”, shake to undo, swipe from edge for browser back- etc.

Zen replied to Zen

4. Constraints and Affordances.
A constraint is something that is not possible in a system. an affordance is something that is possible to do. which is which should be communicated clearly- the nature of this communication breaks down into three subcategories:
a. physical:
visually obvious from the shape of objects in a system- two lego bricks can only snap together in a limited number of ways.
b. logical: what’s possible or not makes sense logically: e.g. color coding,
c. cultural

Zen replied to Zen

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.
flat design throws the baby out with the bathwater. we still need real buttons.

Zen replied to Zen

5. Habits and Spatial Memory
this is mostly about not arbitrarily moving around.buttons in an interface. people are creatures of habit, and if you fundamentally change the method of performing a task for no good reason, it’s not a “UI revamp” it’s pointlessly frustrating your existing users.
for spatial memory, millions of years of evolution have left us with mental machinery for remembering exactly *where* something is physically. you can take advantage of this in UI with persistence of space.

Zen replied to Zen

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.

Zen replied to Zen

6. Locus of Attention
this is a recognition of the fact that human consciousness is single threaded. that while parallel processes permit us to do things like walk and chew gum at the same time, there is only one thread of processing that represents our conscious awareness. therefore, interfaces that expect our attention to be fully present in the status bar, the cursor, the flashing banner ad, the address bar, the lock icon, the autoplaying video and the notifications are misguided.

Zen replied to Zen

7. No Modes
A Gesture is an action (a keystroke, a mouse move) expected to result in some effect (a letter being added to a document, a cursor moving).
A mode changes the effects associated with some or all gestures. caps lock is a mode. “apps” are modes. Modes are bad if they result in modal error: the unawareness that a mode has been activated, resulting in unexpected effects, and possibly unawareness it *is* a mode, or how to get out of it. VIM is prime offender. so are modern TVs.

Zen replied to Zen

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.
suggested remedies include quasimodes like the shift key, that activate a mode only while a button is being held down. another approach is developing composable UI conventions like GUI menus, or search, that can scale without modes.

Zen replied to Zen

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?
no.

Zen replied to Zen

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.
apple ruined it with the iphone X swipey home gesture. not only is it hidden interface, but it’s modal now-which edge you swipe depends on the orientation sensor, and is —- sometimes but not always visually indicated by a line that is maybe correct.

Zen replied to Zen

8, Fast Feedback 17. Consider the 3 important limits of your user's patience:
0.1 second, 1 second, 10 seconds

nngroup.com/articles/response-

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.

Zen replied to Zen

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.

Zen replied to Zen

29. Never use a warning when you mean “UNDO”.
while there are many actions you can take on a computer that are non reversible, most of the ones with confirmation dialogs truly are reversible. these boxes should only be used when absolutely necessary, and seriously rethoghr even then. the unfortunate side effect of their overuse has been alert fatigue: people have become accustomed to their typical meaninglessness and dismiss them without reading, even important ones

web.archive.org/web/2020033119

29. Never use a warning when you mean “UNDO”.
while there are many actions you can take on a computer that are non reversible, most of the ones with confirmation dialogs truly are reversible. these boxes should only be used when absolutely necessary, and seriously rethoghr even then. the unfortunate side effect of their overuse has been alert fatigue: people have become accustomed to their typical meaninglessness and dismiss them without reading, even important ones

Zen replied to Zen

30. Avoid alert fatigue at ALL costs.
imagine the marketing department got their hands on the fire alarms. they would almost certainly use them every day to gather the entire building to one spot, and megaphone about the latest 30% off sale at Myer.

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.

30. Avoid alert fatigue at ALL costs.
imagine the marketing department got their hands on the fire alarms. they would almost certainly use them every day to gather the entire building to one spot, and megaphone about the latest 30% off sale at Myer.

when there’s something actually important, like a real fire, people would die, and it would be marketing directly responsible for those deaths.

Zen replied to Zen

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.

Zen replied to Zen

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.
(not actually true, there’s a whole job for teaching babies how to breastfeed, but that’s the catchphrase for this one, sorry.)

Zen replied to Zen

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.

Zen replied to Zen

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.

Zen replied to Zen

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.

Zen replied to Zen

an amusing consequence of #35 is what a study about colonoscopies can teach us about software interfaces.

fool.com/investing/general/201

Zen replied to Zen

#36. the law of conservation of complexity. Every system has an irreducable minimal amount of complexity. The only question is, where will you put the complexity? on the user, the application developer or the platform developer?

Zen replied to Zen

#37. lawsofux.com contains another numbered list of of principles that amazingly mostly does not overlap with this one.

Zen replied to Zen

#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

uxdesign.cc/ux-psychology-go-h

Zen replied to Zen

#39. this might seem obvious, but it’s violated enough times to make it worth saying: if you’re making a UI for a touch screen, make the buttons big enough for adult human fingers. Apple reccomends at least 40x40pts

Zen replied to Zen

#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.

Zen replied to Zen

41. Dark Patterns
Dark patterns refer to the repertoir of UI designs and techniques intended to trick or coerce a user into doing things or agreeing to things either with or without their knowledge. a windows prompt that registered closing the window as agreement to upgrade, prompts that give only the choices “ok” and “later”, or sign up sheets that hide the “skip uploading my contacts” link with a small dim font (twitter). If you do any of these, I think you’re probably a rapist too.

Zen replied to Zen

I don’t say that last part to be hyperbolic. lack of respect for other people’s consent runs deep and affects everything you do. Implementing a dark pattern is a fucking sign.

Adrian Cochrane replied to Zen

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

Adrian Cochrane replied to Zen

@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.

Zen replied to Adrian

@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.

Zen replied to Zen

@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.

Zen replied to Zen

@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)

Zen replied to Zen

@alcinnz so I guess the lesson here is: if you’re gonna add a configuration option, make sure you have a good testing plan for it.

Adrian Cochrane replied to Zen

@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.

Adrian Cochrane replied to Adrian

@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...

Zen replied to Adrian

@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”

Zen replied to Zen

@alcinnz i am a huge fan of js, as you know. but it’s like salt. it shouldn’t be the main ingredient.

Adrian Cochrane replied to Zen

@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.

Zen replied to Adrian

@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.

Zen replied to Zen

@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.

Zen replied to Zen

@alcinnz but by and large it’s bad if your ui buttons arbitrarily shuffle around and disappear and reappear and move up and down the screen as you navigate

Adrian Cochrane replied to Zen

@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.

Adrian Cochrane replied to Adrian

@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.

Zen replied to Adrian

@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.

Zen replied to Zen

@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.

Adrian Cochrane replied to Zen

@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...

Zen replied to Adrian

@alcinnz there’s spambots that do. which of course is another factor working against you. many websites, in the effort to stop spambots, make it difficult to realise this vision on purpose.

Henry Edward Hardy replied to Zen

@zensaiyuki

Or, you could use a journaling file system.

Go Up