DotYork 2016 – Performance for Everyone – Talk Notes

These are my notes from the Performance for Everyone talk given at the DotYork conference this year.

Instant loading, offline first web apps – Jake Archibald

Service Workers – I haven’t watched it but it looks like the same slides Jake used in his talk at DotYork.

At the most simple level Service Workers mean we can create custom no connection pages. Own the error!

Lie-Fi – when your phone tells you it has a connection even though it doesn’t.  Service Workers can be the first point of call for the request for the page, network can be a fall back if the files required are not in the Service Worker.

What would you do if the only toilet was out of Wi-Fi range? Treat the network as a progressive enhancement. This is relevant for normal websites, not just web apps.

Source –

For logged in users the first wave to the user is generic, then next wave is more specific data. Session data could be stored in indexdb. Think about when to clear cache – when logged out?

Browser cache can’t do anything with interdependencies, for example JS file making changes to the DOM requires specific CSS file version. It could get a different version to what it was expecting. Service Workers do not have this problem.

Source –

User research in Agile teams – Lucy Buykx

A/B testing is OK, but user research will tell us more about the issues, and why.

3 key points for user research

  1. Agree the research questions first – informs everything else
    • What needs setting up
    • Business case
    • Adds value
  2. Script and practice
    • If you don’t have a script it introduces bias. May use different words / terms for each session, and that influences behaviour differently. You can also end up wondering off topic and get findings that you don’t need, or may only affect 1 person. Practice the script to stop it sounding stilted. Focus on the research questions.
  3. Run each session independently – don’t’ change the prototype or the questions between users.

When selecting users for the tests make sure that they fit the profile of our real users. Don’t tell them what they are testing – users have been known to do research before they turn up.

Type 1 and type 2 errors

Type 1 – false positive. Getting off topic, users telling us stuff we don’t need. Findings that only affect 1 person in the study.

Type 2 – false negative. This can be from using words or phrases that introduce bias, and guide the user to help them complete the task

Performance for Everyone – Jeremy Keith

Decide on the core functionality and make it available to everyone.

Identify all functionality and then take things away until just the core is left.

Once the core functionality is enabled for the maximum number of people possible, ideally just by using structured HTML, then enhancements can be made.

Layout and typography are an enhancement. CSS is just a suggestion to the browser and should not be relied on to make the product or service work. Making it look and word the same in every browser wastes everyone’s time.

Local storage, service workers, indexdb are enhancements.

This is also good for resilience and performance.

Performance for the process too – Sarah Semark

Email is not project management, any time you find yourself using ‘reply all’ is bad!

Use a project lifecycle management tool that is accessible for the clients.

GitHub can be used as project management, can sit on top for dashboards / project performace.

  • Make a repo
  • File issues
  • Use labels to organise e.g. bug, conversation, enhancements
  • Document everything. Readme for developers, flatdoc and markdown for clients

Style guides provide a designer – development transition.

1 thought on “DotYork 2016 – Performance for Everyone – Talk Notes

  1. Pingback:DotYork 2016 – Making Progress – Talk Notes - Helen Lindley

Leave a Reply