IT:AD:Design:Blueprints:UX
- Accessibility: always deal with first
- For vision impaired:
- Avoid Red/Green (1 in 7 males, can't distinguish the two. 1/20 women can't) or Blue/Yellow combinations.
- Instead, Use Red/blue for success/failure.
- For those that can't see colour, use colour + icon (eg: checkbox on red background, tick on blue).
- For the blind:
- Unclutter the UI: lots on the page = lots of reading to get to the relevant section. If you have ever listened to a reader, you'll know how much torture that is.
- Improve usability not by cramming the page, but by improving navigation between View/s.
* Views/Pages:
- Think in terms of View/s – not Pages.
- The concept of Pages is an artefact left over from the inability of ASP.NET to render View/s.
- One View Per Page
- In the early century it was cool to cram the page with many Views (header, footer, weather widget, news, everything to distract from the primary task of the apge – the form view).
- Multiple Form Factor Design has taught us that this is not portable design. Only one View can fit a mobile screen, potentially two on tablet. More can fit on a desktop or HDI tv screen – but there is the notion of data-entry error mentioned below.
- One View per Page is the current concensus – using styling for backgrounds, and faster navigation to make it less boring to look at.
- ViewsType: Views should be either Input, or Output, not combinations of the two.
- An example would be input form fading to be replaced with the results grid.
* Data entry error:
- Clutter and Multiple Dimensions of Actions leads to confusion and data entry mistakes.
- Complexity of meaning increases in order of magnitude according to the numbers data dimensions of what one has to decipher: text, coloured text, link, button, list, dropdown, tree, grid, treegrid, 3d.
- In other words, prefer lists of summarised data to grid.
- This “fovea centralis” of the eye is the only part of the that sees things in focus. Only 2 degrees of vision at a time (we only see the rest of the page by moving the eye, and the brain recording residual images).
* Wide grids lead to an inability to see more than one or two columns at a time. Prefer using Template rows instead.
* Actions:
- Each View/ should have only one primary action (eg, a Form's Save should be the Primary action, the Clear and Cancel are be Secondary actions). Bring attention to the primary by keeping it as an Button, de-emphasis secondary Actions by turning them into simply Links.
- The eye can recognize a symbol faster than read text. A Button that has an Edit symbol is more productive than a button with the word “Edit”
- Nothing more annoying than being given a button to be clicked only to be rewarded with
Feedback: - No action should lead to an alteration of data without a means to cancel – this promotes discovery, therefore competence.
- Avoid errors: keep buttons grouped on left. Not left and right and top and button and all over the place (murder on large screens as your mouse has to travel miles, and slow down…and hit it…just right…or overshoot, and hit the button beside the one you intended to hit).
* Validation:
- Validation should be done in real-time. Not wait till the Submit button is clicked. Give the feedback when on the field in question – not a different control (the submit button).
- Alerts:
- Modals are obstructions to completions of tasks: they obstruct you from what you are trying to achieve by taking your focus to a completely separate window. Error messages can be shown as real-time validation and tips beside the control in question while you are on it.
- Help:
- Help docs are admissions of incompetence at designing intuitive application flow and layout. Don't plan for them. Plan to design in order to not need them.
- That said, if you need to add tips and help text, consider giving it tips in real time to the right of a control or in a designated area (in a desktop app, for example, the footer can be used for simple sentences).
- Forms should have Titles, then About text optionally displayed depending on a TipSeen value per user, then the fields. It's far less expensive and intuitive to show/hide a div in which some help text is displayed, than a completely separate Page/Field help system.