Category Archives: Projects

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

Cape Town Front-end developers Code of Conduct

Naga IT Services
Filed under: Industry, Projects

From our next meetup onwards, all of our CTFEDs events will have a footer added, telling people that (TL;DR) they must be cool to each other. We’ve added it to our template that we use for our events.

Attendees must read and follow our Code of Conduct. Thanks! :)

We’ve had a Code Of Conduct for a while, and the organising team has tried to mindful of it before that. Finally getting around to publishing our site (via GitHub Pages) and the current buzz around the topic gave us the push we need to be more open and obvious about it.

The tech industry (and the world general) can be a pretty messed up place. We are committed to making our meetups and workshops friendly, safe, and inclusive spaces. Like Sparkbox’s recent, brave, post we realise that we have a lot of work to do, and we are trying hard to make our events better for everyone. We’ll be (re)reading awesome resources like Ashe Dryden’s Codes of Conduct 101 + FAQ, and blog posts like Lessons from a Code of Conduct and Talking & Listening about Conduct to find ways of doing so. We hope that you will hold us accountable, and help us get better. :)