Blog

Notes from Front-end London January

OK Computer - Peter Gasston

slides available on github

  • 3 ways to interact with a computer
    • Touch
    • Keyboard
    • Voice
  • Writing is good for recording knowledge, but voice is how we communicate
  • 10% of baidu search is voice
  • Synthesis - computers are going to talk back to us
    • Web speech API will allow 'SpeechSynthesisUtterance' in chrome and safari
    • Synthesis As A Service is available from several sources
    • SSML allows XML-like markup for Speech Synthesis
  • Speech Recognition
    • existed before Speech Synthesis
    • Challenges
      • Multiple users
      • Multiple languages
      • Accents
    • SpeechRecognition API
    • Fun fact: https will only ask for permissions once (http asks every time)
    • Firefox proposing SpeechRTC to use the local speech recognition of the client machine in browser
    • We need to focus on the intent of what's said, not just the words
    • http://wit.ai
  • Google have a trust, planning for if deep learning of computers ever goes wrong
  • Main use cases:
    • No screen
    • Hands are busy
    • Mostly closed systems, sadly

Visual Regression Testing - Charlie Owen

slides available on slideshare

  • Nobody likes regression
  • Unexpected bad consequences
  • Basic work-flow:
    • Screenshot initial state
    • Change things
    • Screenshot current state
    • Compare them (image diff)
    • Highlighted difference
  • PhantomCSS
  • Wraith
    • Offering available from BBC
  • The work-flow is simple for small sites
  • The more complex the site, the more chances of failure
    • Content
    • Interactivity
    • Dynamic features
  • Atomic design
    • Don't test the pages, test the components
    • Dummy content or consistent test data
  • Version and update the baseline images to be used by all
  • Only really effective on large projects
  • Many of these systems only work in one browser, it's possible that you can introduce browsers specific regressions
  • Make this part of your CI process

Hackers guide to testing with real users - Tom Alterman

slides available on speakerdeck

  • Why don't we user test
    • Too long
    • Too expensive
    • Too difficult
    • Not my job
  • But we want to build good, useful things
  • Hard lesson learned: don't use oracle web platform
    • After much effort social buttons were integrated
    • When tasked with sharing the link, everyone ignored the buttons and copied the URL
    • The URL was so dirty that it wasn't even tweetable
    • Clean URLs was in the backlog, but social buttons was prioritised over them
    • Simple user testing would have avoided this
  • The process
    • Recruit
      • Use the real target audience, not mates or stakeholders
      • Everyone wants a £20 Amazon voucher
      • Testing remotely is easier for everyone, (possibly not as quality though)
      • Quick survey to test if a user is relevant
      • Ethnio
      • Call people, check they're not weirdos or scammers
    • Plan
      • Steve Krug - Rocket Surgery Made Easy
      • Prepare a test script - setups for a user to complete their goal
      • Screen sharing is very important - try GoToMeeting
      • Observe, don't interrupt, no leading questions
      • Some good questions are:
        • "What are you thinking?"
        • "What would you do next?"
        • "At what point would you quit?"
        • "What do you think just happened?"
    • Analise
      • Write down the most important things you noticed
      • Identify the patterns
      • Focus on behavior
      • Share the findings
      • Identify some "quick wins" / urgent issues / future considerations
  • 5 users will help identify 80% of the usability issues. Minimum 3
  • Share video highlights
  • Helps create empathy with your users
  • Test frequently, at least every month, just test whatever you have ready
  • Pretend you didn't build what you ask people to test, you'll get more honest feedback