Skip to content

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