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

Why so serious? Running a team hack day

  • 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

Gavin Davies

Using build tools

  • Gavin is an automation engineer/coder at Radify
  • software is advancing at a scary pace
  • it’s important to understand things conceptually first
  • it’s about workflow not particular tools
  • improve your workflow
  • reduce tedious, manual tasks
  • get feedback sooner
  • use Grunt or Gulp (it doesn’t matter which) to automate your asset pipeline
  • use linters to highlight bad code
  • optimise images and minify code
  • use gulp-rsync to deploy automatically
  • use source maps to debug your Sass
  • Yeoman can help get up and running quickly
  • Blog post about using front-end build tools

Fred Heath

The uncertainty principle

  • 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

Gavin Evans and Jaime Purvis

Designing accessible websites

  • 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

Andy Clarke

Designing imaginative grid systems

Helen Clark

Open and inclusive design

  • 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

Ashley Nolan

Developing for the unknown

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

Further reading