Principles of UI, A Thread:
1. natural mapping
2. visibility of system state
3. discoverability
4. constraints and affordances
5. habits and spatial memory
6. locus of attention
7. no modes
8. fast feedback





more at:!.h

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



20. Some Sources:
Donald Norman
Jef Raskin
Jacob Nielsen
Bruce "Tog" Tognazzini


Doing with Images Makes Symbols
The Future Of Programming


21. Gall’s Law:







expanding on 1. Natural Mapping:

2. Visibility of System State:

3. Discoverability

4. Constraints and Affordances.
a. physical:
c. cultural


5. Habits and Spatial Memory


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

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

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

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.

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.

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

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

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

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

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

@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

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

@alcinnz which is of course better for sighted users but it causes issues for screen readers- there’s aria attributes you must use on the part of the screen that is refreshed to ensure the screen reader is notified part of the screen has changed. it- kind of sort of works?

@zensaiyuki Ideally for an auditory browser you invoke a link, and that would be enough context to understand the update to the page! Without being told where that update happened.

@alcinnz in theory yes. in practice, since the screen reader is typically a seperate peice of software from the browser, interacting with the browser via an OS level accessibility api, if the page doesn’t “refresh” the screen reader doesn’t know you activated a link.

@zensaiyuki I actually went the path of implementing my own browser engine! Within the constraints of what a screenreader can easily handle, it's not actually that hard.

Pretty much as soon as I finished implementing CSS I was spitting out SSML files eSpeak could use to give an interesting performance!

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

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

Sign in to participate in the conversation
