Port80 2016

My notes from the brilliant Port80 web design conference, including talks from Gavin Davies, Digital Accessibility Centre, Helen Clark and Ash Nolan.

Louise Howells

Louise is a Professional Services Manager at Zengenti
happy working environments are good for staff
good offices need breakout zones
Zengenti call their annual hackathon “Lockdown”
step away from the day job and do something different
teams created digital and physical products like:
- a games room in the basement
- a BBQ area
- a website that listed design conferences
helps to foster a community
staff started up book clubs and pool clubs afterwards
it encouraged staff to do job swaps and learn about different areas of the business

how do we deal with uncertainty?
why do projects fail?
it’s hard (impossible) to estimate project time and cost
cushioning is when you give a client the worst case estimate and double it, this is bad
telling a client you don’t know how long things will take is not much better
Enter SCRUM
2 week sprints, then show client
product backlog > sprint planning > sprint backlog > sprint
behaviour driven development (BDD) is “outside in” development
stakeholders define features
features are like user stories
tools: cucumber
write scenarios for features
scenarios are like examples e.g. show special offers
these should be in plain English
then write a step definition
sprint planning > define steps (flesh out plan) > do the work > show and tell > retrospective

accessibility is about not creating barriers right from the design stage
developers need to use the right mark-up
follow web standards and WCAG 2.0
user testing with actual users with disabilities
tips for better mark-up
- provide alternative text for visual content
- consider users who don’t use a mouse
- use structure and logical hierarchy
- don’t suppress zoom
- display:none hides it from everyone, so be careful
- always style up hover, active, focus
- Use tools to check understanding level of your content
- html <track> element to add text or captions to videos (webVTT)
- bad error handling is bad
- don’t rely on placeholder text only in forms inputs
www.html5accessibility.com
Use ARIA roles for sectioning
How to use iOS Voiceover
- two finger tap stops speech
- swipe left and right to go to next item
- twist hand to choose different elements
- swipe down with 2 fingers to read on
<details> and <summary> in Firefox with NVDA skips over it completely
avoid cluttered designs
mobile versions of sites are generally better
the less content the better
label properly, be descriptive but concise
dynamic sites are hard to navigate, if something changes make sure focus changes too

beware stealth stakeholders, these are senior staff who pop up at the end of projects and try to change things
work in the open
document everything done on the project (on Tumblr for example)
speak to customers (end users) to discover user stories
get honest, impartial feedback (users might lie if staff are running the research sessions)
speak to staff (at their place of work) especially front line staff
create a list of priories based on this research
create paper prototypes
feedback can be applied beyond the website, so share your research
risks of working openly?
- research should uncover problems not solutions
- working in the open can make some people uncomfortable (it shows the behind the scenes, messy, ugly bits)
good research means you can justify design decisions
Code for America
- build iteratively
- people’s needs first
- design with data
- open by default
- ensure everyone can participate
Growth Driven Design
- launching the website shouldn’t be the end
- launch a basic site first
- build the must-haves, and leave the nice-to-haves until later
- then do continuous improvement
beware: clients might block access to users if they feel left out of research
immerse the client in the design team, then both can communicate with the audience

Ash is front end dev at Just Eat
no docs or commenting leads to legacy code straight away
put the right things in place from the start: structure and workflow
workflow
- grunt and gulp can act as self documentation to show new devs what workflows exists
- grunt or gulp, it doesn’t matter
- create common workflows: e.g. Sass, linting, minifying
documentation
- good commenting
- style guides
- “programs should be written for people to read and incidentally for machines to understand”
- describe what components do and where they’re used
style guide and component library
- look for patterns
- reuse them across website
- organise CSS
- start small and extend
- components only worry about themselves
- Read SMACSS by Snook
Naming schemes: BEM or SUIT
- be consistent
- show relationship between class names
- BEM: Block, elements, modifier
- BEM naming scheme
- Statix, a reusable snippets tool
- Static site generators Assemble or Jekyll
Separate your concerns
- decouple CSS classes from JS
- hook JS into data attributes or IDs
look into PostCSS
whatever we create should be built to last