#clarity2016

They looked to GOV.UK for inspiration

“Be consistent, not uniform” (GOV.UK design principles)

18F pitched the style guide idea and got 4 months to make an MVP

First they talked to people who work for USDS

Flexible design

A consistent look and feel with common design elements will feel familiar, trustworthy, and secure

What components are important?

Brought in various departments and did an inventory of websites

They tested typography pairings on actual government websites

Settled on a font, but noted that it’s not required, so agencies can retain their brand identity if they want

3 ways to use the standards

Our design and our code

Our design and different code

Different design and our code

Flexible code

Just HTML, CSS, and JS

Sass preprocessor + Bourbon and Neat

Component-based design

Modified BEM syntax

For a healthy open source community…

Respond to GitHub issues within 24 hours

Respond to pull requests within 48 hours

You don’t have to have the answers, just acknowledge them

Be kind

Example

Name: naming

Context: a way to identify

Problem: we need to identify things so everyone knows what we’re talking about

Solution: work with stakeholders to establish a name

Related patterns: documentation

Why do we need a pattern language for front-end development?

The web is a complex system with moving parts

A pattern language for front-end web systems (four types)

I. Global patterns

Community guidelines

Temporary autonomous zones (meetups/conferences)

Independent disciplines

Web guidelines (W3C)

Open borders

Accessibility

II. Process patterns

Purpose

Planning/management

Code reviews

Cross functional teams

Single origin of truth

Documentation

Naming

Design systems

III. Workspace patterns

Editors

CLI

Syntax highlighting

Shortcuts

git/GitHub

Version and dependency management

Configuration/settings

IV. Project patterns

Build tools

Bundling dependencies

Directory structure

Linters

Composable

HTML templating

CSS methodologies

JS

Content strategy

Shareable data

Identifiers

At Casper, they created something called Ando that uses many of these patterns

Open borders = working with people across different disciplines

Problem: provide a way for everyone to work on the same codebase and contribute their skills

Solution: use a system that has minimal dependencies

Static, no DB, no migrations, back to basics

Related: cross functional teams, build tools

Documentation = a way to record decisions

Problem: code is not self-documenting. Decisions need to be captured. Captured decisions need to be easily referenced by people who did not write the doc

Solution: use community-vetted code documentation solutions. Pick a place to store documentation

SassDoc

JSDoc

HTML templating = a way to create sound structures, a way to componentize

Problem: HTML is verbose and at scale it becomes difficult to maintain

Solution: use a templating language

Nunjucks, Jade, Swig, Handlebars

Related: naming, documentation, directory structure

Directory structure = organizing/grouping project files

Problem: need a way to organize files that is easy to comprehend

Solution: traditional vs. component

Traditional

Files spread all around the app

Cruft often remains in the codebase

Component

Group files by component

Everything in one place

Works for organizing components and views

Use traditional director structure within component directories

Common accessible code techniques

Use semantic HTML

Use h1 for headings, not a span that is styled to look like a heading

This is for screen readers!

Use the button tag for buttons!

Input fields: use visible, explicit labels

Current trend is to put the label inside the input field as a placeholder

This is bad because of low contrast, and once you start typing it goes away

Also need to associate label with form field using for

Give ALL images alt text

If the image is redundant (example: home icon next to home label), use empty alt text or aria-hidden=“true” for SVGs

decorative images: use discretion, often empty alt tags

ARIA = accessible rich internet applications = communicate element’s role, state, and properties to assistive technology

Use it only when you need it

Modals, menus, accordions, tabs, alerts, trees

WCAG 2.0, @heydonworks’s practical ARIA examples, web-a11y.slack.com

Accessibility in design

Make keyboard interactions as rich as mouse interactions

A lot of people don’t use the mouse

Example: Facebook reactions animations still work when navigating with keyboard

Don’t forget about focus styles (the blue halo)

Don’t get rid of it! People navigating with keyboard rely on these

You can style the focus to look better than the blue halo (branding comes into play here)

Tooltips should appear on hover AND focus

Color

Rule #1: reasonable contrast for text

4.5:1 for regular text

3:1 for large text

Lea Verou’s contrast ratio tool

wave.webaim.org

colorsafe.co

Use vibrant colors! Use light colors! Just make sure the text has high contrast

Use those fun colors for borders, icons, etc.

Rule #2: use more than just color for meaning

Test: put website in grayscale mode and see if you can still use it

Example: input field border turns red when wrong = not enough

Add an icon and a message

Sharing your accessible code/documentation

Include accessibility notes in your documentation

See Dropbox’s Scooter framework, Salesforce Lightning, Bootstrap

Component-level documentation

Discourages accidental removal of accessible aspects

Encourages constant attention to accessibility

Spreads best practices

General documentation

Might get overlooked (so shouldn’t exist by itself)

Encourages holistic thinking about inclusive design

Designers want:

Thematic

Theory

Educational

Guidance

Developers need:

Granular (how to implement)

Components

Instructional

Maintainablity

How they compliment each other:

Documentation = what’s there and why

Defaults = building blocks and rules for spinning up new things

Unity and overlying choreography with language (?)

Guide and empower future contributors to make decisions

Deliverables: two types

Unicorns = designers who can code

Developers are given prototypes with code

Some designers argue that designing with code is inherently limiting

Throw-over-the-wall

When developers are only given gifs/movies, this is frustrating

Developers need numbers! Easing, timing, and properties

Easing = rate of change

Acceleration = ease-in —> system-initiated animations

Deceleration = ease-out —> human interactions

Bounce = increase animacy and add an element of fun

Fade and color changes look best with more linear subtle curves

Timing/duration

modularscale.com

Limitations

70-700ms

200-300ms is a sweet spot

Shorter duration for fades and color changes

Longer duration for large movements

Use ms instead of s to prevent decimal hell

Properties

What to animate

Opacity and transform are the most performant properties to animate on the web

But don’t be afraid to push the envelope! “The art challenges the technology, and the technology inspires the art” (John Lasseter)

Easing + timing + properties = deliverables = animation vocabulary

Patterns

Notification and dismissal: when something pops/fades in and then slides out

Storyboards (verbal)

Use orange to indicate behavior/animation, use blue to indicate user action

Blank story boards

boords.com

Animatics (visual)

Sometimes you need a video/stop motion/rough sketch that moves

But it is NOT a deliverable on its own

Keynote, Adobe After Effects, Principle app, Stop Motion app

Prototypes (visual)

Need interaction to be able to test an animation on users

Native-oriented: Principle, Pixate

Web-oriented: Invision + gifs, UX Pin

Code required: Foundation, Framer

Combine all three for great deliverables!

Generating buy-in (how to get people to care about animation documentation)

Group writing

Get index cards and ask people to draw the in-between stage between stage A and B (i.e., the animation)

Cultivate and champion: you need someone to be a champion!

Have a co-conspirator