Inclusive design: some principles and notes

Written on 29 April 2018, 09:01pm

Tagged with: , , ,

Time to mix IT security with web design, so a few notes from the first chapters of Inclusive Design Patterns, by Heydon Pickering.

Some basic principles:
– always use semantic structures (ex. use the lang attribute)
– prefer existing HTML elements instead of inventing new structures. In other words, embrace standard behavior. If you can use a native HTML element, then do so.
– use progressive enhancement: HTML, then add CSS, then add JS (also known as ‘content first design’)
“If it’s not curlable, it’s not on the web”
Henny Swan UX principles: give users choice, put the users in control, design with familiarity in mind, prioritize features that add value
– remove redundancy (ex. instead of having a logo and a ‘home’ label both pointing to the homepage, consider turning the logo into a navigation link)

Fonts:
– never use absolute font size (ex. 16px), use the relative measures
– use rem over em to avoid font size nesting problems
– font display problems (especially when using web fonts): FOIT – Flash of Invisible text, FOUT – Flash of Unstyled text. See SmashingConf London — Zach Leatherman on ‘Web Fonts are ▢▢▢ Rocket Science’
– start using font-display: swap, optional, fallback (Chris Coyier – If you really dislike FOUT, `font-display: optional` might be your jam)
– when using web fonts, you can specify to download only the characters that you need: https://fonts.googleapis.com/css?family=Roboto&text=ABCDEFGH

Accesibility:
– try to navigate your website using only the keyboard: skip links, tab index, highlight the focused element
– the ‘skip to content’ links are mostly for sighted, keyboard-only users
– make sure that all the elements are focusable, that the focused element is visible and highlighted
– try to navigate your website using a screen reader
– design for the extremes:
– design for the people with poor networks: the ones with good networks will also be happy
– design for the people with readability problems (ex. dyslexia or color vision deficiency): the other users will also benefit
– always provide alternative text
– don’t differentiate by color alone
– don’t make the touch targets too small (believe it or not, everybody has fat fingers)

Do not break conventions:
– allow pinch to zoom
– use blue and underlined links (color is not sufficient, use underline as well)

The human brain uses patterns called schemata to understand sense data. Schemata constitute prior experience against which current experience is evaluated.
In programming terms, schemata are a kind of cache for understanding. So long as a familiar thing is being experienced, little more effort is required to understand it.
By the same token, if something genuinely new is experienced, there’s nothing in the cache to be relied on and thesense data must be evaluated in full
smashingmagazine.com/inclusive-design-patterns/

Design
– prefer left align of text instead of justified (especially for narrow columns)
– be careful with the line height: the users will zoom in. Never use absolute font size!
– warn the users about the external links
– automatically add icons from CSS instead of the WYSIWYG editor (example: icons for the external links that will open in a new tab)
– make the link texts descriptive
– if you use video, think about closed captions. They are not only for the users with hearing problems (ex. watching it without volume)
– don’t be afraid of using relative #links in the navigation menu
– SVG is probably the best option to design the hamburger MENU button (instead of image, font, unicode character, etc)
– if you have an online store, use microdata to have rich snippets in the search results
– if you have to implement infinite scrolling, then consider having a ‘load more’ link for the keyboard users. Or think if it’s the right thing to do 🙂
turn the placeholders into labels when the users start typing

Content
– follow the ‘content-first’ guidelines
– keep it short, avoid passive sentences, eliminate redundancy, vary the length of sentences
– use readability tests (ex. Flesch)
– when creating your headings, think about the table of contents (do the headings still make sense when reading in the ToC?)
– don’t make your site content dependent on client-side JavaScript
– everybody loves table of contents, especially if the content is long

In the end, a strong conclusion: it’s all about the end result. What we have to design is processes, not screens.

People are not really into using products. Any time spent by a user operating an interface, twisting knobs, pulling levers or tapping buttons is time wasted. Rather, people are more interested in the end result and in obtaining that result in the quickest, least intrusive and most efficient manner possible.
We will design processes, not screens.
We will design systems, not individual pieces.
We will design less “using,” and more getting results.
– Goran Peuc – Nobody Wants To Use Your Product

Wireframing

Written on 30 December 2016, 10:38pm

Tagged with: , , ,

These are some notes that I took while skim-reading The Guide to Wireframing.

What are wireframes?
Wireframes connect the conceptual structure to the visual design of a website/app.
They communicate 3 main points:
– Content
– Structure / Information Hierarchy
– Behavior / Functionality

How to do wireframes?
– paper drawing (sketching)
– whiteboard drawing
– paper kits (cutouts)
– digital drawing (Wacom devices)
– word processing software (Word, Google Docs, etc)
– presentation software: PowerPoint, Keynote
– graphic design tools: Adobe Illustrator, Adobe Photoshop, Sketch
– dedicated wireframing and prototyping tools: Balsamiq, proto.io, Axure, UXPin, InVision

Advantages of the dedicated wireframing tools
– element libraries
– flowcharting and user flows
– interaction with the wireframe: some wireframing tools offer the possibility to interact with the wireframes in order to showcase the behaviour (click-thgrough experience)
– collaboration (comments, feedback)
– presentation (pdf/ppt or standalone presentation mode)

Final point to remember
Delivering wireframes is not a goal in itself. The goal of wireframing is to deliver the final product, not the wirefames. So don’t aim for the perfect wireframe: as long as your wireframe delivers the intended message, move on.

Should it look the same in every browser?

Written on 27 December 2016, 10:50pm

Tagged with: ,

I recently finished reading the excellent book Resilient Web Design, by Jeremy Keith.
At one point, in the 5th chapter, the author was discussing whether the websites should all look the same in every browser or not.
The answer – in the view of the Jeremy – is no:

New browsers and old browsers; monochrome displays and multi‐coloured displays; fast connections and slow connections; big screens, small screens, and no screens; everyone can access your content. That content should look different in such varied situations. If a website looks the same on a ten‐year old browser as it does in the newest devices, then it probably isn’t taking advantage of the great flexibility that the web offers.

Then I remembered about this manifesto of Barry Smith (not quite safe for work): (more…)