Author Archives: Steve Barnett

Google Developer Summit

Naga IT Services
Filed under: Conferences, Industry

Yesterday I headed out the Google Developers Summit (the Cloud/Web track) to learn about Offline Page Caching, and other fun things.

The morning was a few introductory talks, where we were reminded of the importance of considering network performance, battery life of devices, and of finding ways of measuring the quality of our apps and sites.

I particularly enjoyed Andy Volk’s talk. He talked about prepaid markets: places that we often talk about as the Majority world, usually using featurephones. I thought approaching it from that angle was interesting (focusing on the money side rather than technology), and one that maybe helps hammer home the data-as-cost angle of (front-end) performance. He also mentioned reconnecting to a site or service as part of a discussion of offline access, which was good reminder of that particular use case (resuming a download or action upon reconnection).

Sketchnotes from google dev summit

The afternoon workshops were great, and I enjoyed finally having some time to play around a bit with Service Worker. My current thinking about providing offline support for devices is:

  1. Use serviceworker if it’s supported (checked via a if('serviceWorker' in navigator) { ... });
  2. Else use appcache if it’s supported (checked via a if('applicationCache' in windows) { ... }, and using appcache-nanny as a helper);
  3. Regular old “online” access.

I was also thinking about what to cache when. One suggested method was on-the-run: when a user visits a page, add it to the cache. Caching more pages earlier would result in better performance, but it comes at a data cost. Caching on the run is great for saving data.

jQuery vs JavaScript

Naga IT Services
Filed under: Projects, Workshops

At the recent CTFEDs workshop, I gave a lightning talk about jQuery vs JavaScript. You can view the slides on speakerdeck, or read a bit more detail here. I’ve also gathered some links on the topic under the tag ctfeds20150822 on my pinboard bookmarks.

I’m not picking on jQuery. I’m just choosing to talk about it because it’s so popular. These things can apply to libraries is general.

The TL;DR is: Think about it. Carefully. What’s the cost (of using jQuery, or the library of your choice)? The one thing I’d like people to do is not to use jQuery by default, but make it a conscious decision.

A good question to ask yourself is: Who does this help? Me or my users?

Good things about jQuery

  • It makes complex things simple(r). For example: ajax. That means it can be faster to write than regular JavaScript.
  • It’s well maintained and well tested. It has a big team working on it.
  • It helps you avoid bugs, even in modern browsers. Although that’s less of an issue these days.
  • It’s on a lot of Content Delivery Networks, so the file will be faster to download, or the user may already have it cached in their browser. The various versions of jQuery make this slightly less likely, though.

Bad things about jQuery

  • Parse and execution time can be slow. This one is important. Since the file is large, the time it takes a browser to read and execute the jQuery code can be slow, especially on low-powered devices. Older jQuery versions and plugins make this worse.
  • It adds a dependency to your set up. Now you (and future you, and other people working on the project) have to know about it and use it.
  • It can be overkill if you’re not using all of it, or if it’s something you could write quickly. These days jQuery lets you do modular builds (just pick the bits you need), which is great.
  • It can be painful to upgrade. You might need to rewrite sections of your code.
  • Like any library, it’s solving a particular set of problems, and these might not be the same as yours.

What are the alternatives?

Some really useful links:

And Now for Something Completely Different

Another important thing to think about is Cutting the Mustard: thinking about whether or not you send JavaScript to all your users. The team at BBC news decided to serve all users the basic (fast!) HTML and CSS, but only to send the JavaScript-enhanced, bells and whistles, version to browsers that they could say where “modern enough.” Here’s the test they use:

if('querySelector' in document &&
'localStorage' in window &&
'addEventListener' in window) {
	// load fancy js stuff

Think about using less JavaScript, and any that you do use: optimise the hell out of it.

CTFEDs workshop for Open Design Cape Town

Naga IT Services
Filed under: Projects, Workshops

This weekend just gone, two of the organisers of the CTFEDs meetup group (myself and Justin Slack of New Media Labs) ran a Future Friendly-themed workshop as part of the Open Design festival.

We wrote up the principles that we’d be following and a fairly extensive checklist of TODOs for workshop attendees to have a look through. We had a couple of sticky note activities to do during the day (yes, I use sticky notes for everything!) and Justin and I gave a lightning talk each (I talked about jQuery vs JavaScript (which I will do a short write up of soon) and Justin talked about Iconfonts vs SVG)..

One of my favourite things about the workshop was that we had a wide range of experience levels: from people writing their first lines of HTML and CSS to people tweaking performance metrics on their clients’ sites. It was awesome!

What went well

We gathered some feedback from the students about the workshop: the things that cropped up the most were that people enjoyed the lightning talks (yay!) and they were looking forward to the next one.

This was the first workshop event we’ve run: we usually just have presentations. I really enjoyed it, and I hope that we can run another one.

What didn’t go so well

The checklist could have been presented a bit better. We printed out the whole checklist on one piece of paper, and I think it was a bit overwhelming. The idea was to pick a few that piqued your interest and just look at those, but that wasn’t clear.

What we could change

If we run this workshop, or one similar to it, again, I think we’ll print each section of the checklist out separately: have just a handful of items on each page. It might also be interesting to have a limited number of cards: you take a page, do one thing, then put the page back for someone else to pick up.

I really dig stickers. We use them at RailsBridge as tiny Achievement Unlocked celebratory things, and I think I’ll bring them along next time. If you finish one of the cards (a print out of one small piece of the giant checklist) you get a sticker.

User-Centered Design process

Naga IT Services
Filed under: Industry, Process, Productivity, Projects

I love User-Centered design. And I love obsessing about process, in a frameworks kind of sense. At work, we’ve been talking a lot (and blogging a bit about process, and iterating on ours. Here’s what we’ve got at the moment.

Our big picture looks a bit like this:


Diving into a bit more details, our Persona creation process looks like this:


A process for creating Personas


  • Should contain:
    • Picture
    • Name
    • Quote
    • Job title
    • Few short bullet points
  • Four personas at most
  • Use KJ method exercise to generate?


  • Existing team knowledge
  • User statistics
  • User interviews
  • Product positioning statement


  • Analysis of research
  • Expand bullets into paragraphs
  • Add “hats” or dimensions
  • Add categories
  • Team feedback


  • Print, put up on wall
  • Publish on the web
  • Blog about them
  • Share with team on Slack

Our User Flow / Customer Journey Map process looks a bit like this:


A process for creating User Flows


  • High level overview of phases
  • Quick discussions
  • Revise


  • Existing team knowledge
  • User statistics
  • User interviews
  • Product positioning statement
  • Use Personas
  • Expand sketch in Trello
    • Phases as Lists
    • Personas as Members, with photos
    • :) and :( as delighters and pain points
    • Labels as “hats”


  • Use Trello’s filters to view one aspect as a time
  • Discuss in depth
    • Details of each phase
    • Personas matched to cards
  • Revise


  • Print, put up on wall
  • Publish on the web
  • Blog about it
  • Share with team on Slack