Code: prototype vs production

Naga IT Services
Filed under: Process

I’m a big fan of making prototypes as part of a User-Centered Design process. I even prefer to skip doing wireframes entirely and instead use sketches, (heavily annotated) prototypes (that have been tested with users), and Style Tiles to start work on a Front-end Style Guide. For this work, a designer and a developer need to work closely together, so it can sometimes be hard to do.

I prefer more interactive prototypes that let you do stuff rather than the clickable-hot-spot prototypes that most tools offer. Since I’m a Front-end Developer, I like to make those prototypes myself in HTML, CSS, and JavaScript, rather than using a tool to do so. To make sure that I can make the prototypes quickly, I’ll often use a framework like Bootstrap or Foundation.

Throw away prototype code

This code is written just for testing the prototype, and won’t be used in production, so I let myself be a bit sloppy (e.g. don’t write tests). For the prototype how it works is more important the code quality. Another reason the prototype code doesn’t make it to the live site is because frameworks like Bootstrap and Foundation tend to be quite heavy in terms of size. There are tools like unCSS that can remove unused CSS, but I’ve have mixed results with them. It feels a little like fixing the symptom rather than the problem: I’d rather write less CSS in the first place, and have a simpler code base with lots of reusable modules.

Zurb’s Foundation

Foundation 6, Prototype to Production on the Zurb blog is a very interesting read. They set out a clear set of principles that guide the decisions they make about Foundation for both prototype and production use. The most exciting part for me is the focus on Front-end performance, starting with a lighter Theme and file size:

We’re approaching this problem two fold with Foundation 6 by styling the already minimal framework less from the start and giving users easier tools to strip files themselves.

I’m still not sure I’d use a framework like this for production code, and I certainly wouldn’t want to use my sloppy prototype code in production, but it is awesome to see Zurb trimming down their framework and giving more power to developers to pick out just the bits they want.

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.