Category Archives: Industry

Mobile stats and things

Naga IT Services
Filed under: Industry

Every quarter ScientiaMobile publishes a Mobile Overview Report, which always has some interesting stats. I look through it because I want to be aware of what kind of devices people over the world are using, and I want to keep the device lab up to date. Here are a few highlights that caught my eye.

Feature phone browsing is (still) about 12% of mobile use

The split between form factors in Africa is 12% feature phone, 62% smartphone, and 26% tablet. Feature phone browsing on other continents is in the single digits, and rapidly dwindling.

This is important to keep in mind because feature phones don’t have great support for fancy CSS and JS. In fact, they don’t have great support for older CSS and JS.

There is no fold

Scrolling is a natural, easy, action on smartphones. People are more likely to scroll if a page takes more than a few seconds to load. Luke W has more great stats and research on this.

This makes me wonder about the many sites that have a large image (or auto-playing video) in the header: how many people scroll right past it (at least on the first visit)?

Android is huge

iOS takes up 33% of the global market (with Android taking up most of the rest), but the picture closer to home is a bit different. Africa has only 8% iOS (Europe and North America are at 32% and 47%, respectively), 8% on Windows phone (more than the rest of the world, but dropping), a staggering 79% Android, and 5% for the rest.

In terms of Android versions across the world, various flavours of 4 take up most of the market, with older version taking up only single digits.

For me, this means updating the device lab with another Android phone that fits the specs of popular locals devices: cheap, fairly low power, but running a version of Android 4 (one of Vodafone’s Smart 4 devices or one of the MTN Steppa family).

Busy, busy, busy!

Naga IT Services
Filed under: Industry, Projects

The past few months have been a little bit busy. Lots of exciting things have been happening, and work has been interesting, but that hasn’t left a lot of time for reading or writing.

Cape Town Front-end developers

At the start of July the CTFEDs meetup group had a great talk from Deb Butler of the Startum Project: “I Know More Than You” – Said Every Client Ever. It was a frank and open talk about the trials and tribulations of being a freelancer in the web development business, and I really enjoyed it.

We also finally got around to starting our website: Yes, it is more than a little ironic that people who make websites have taken ages to make a website for themselves :). Behind the scenes the site is hosted on GitHub Pages, and is powered by Jekyll. You can view the source code for the site on our GitHub repository.

Our next event is a little different: we’re running a workshop as part of the Open Design festival. The festival’s theme is Design is for Tomorrow, so we’re inviting people to come and get help making their sites more Future Friendly. Join us!


At the end of July I was scheduled to give a talk about the hamburger icon, but due to a scheduling snafu at the venue it had to be postponed. It seems like it might be the end of this month instead: I am ready to rant!

At the start of August, I gave a short talk at Friends of Design about #fedlyfe. I talked about how I got into Front-end development, what the jobs I’ve had have been like (in terms of team, roles, culture, …).


Then, just last weekend, me and a handful of fine friends ran a Railsbridge at the University Cape Town, for the Women in Computer Science group. You can read more about the event on our site.


Maybe I need a holiday! :)

The CSS bits of Progressive Enhancement

Naga IT Services
Filed under: Industry, Process

At work the other day we were talking about Progressive Enhancement and feature phones, particularly in terms of CSS. The feature phones part of the chat led me to write up a short Dos and Don’ts of Feature phone design (written for designers more than developers). The PE part of the chat made me scribble up the following pictures.

Every web page looks like this. A base of HTML, with CSS layered on top, and JS layered on top of that. It’s a triangle because the balance should mostly be like that: lots of HTML, quite a lot of CSS, and as little JavaScript as possible.

Practically speaking, we chop things up a bit more than this, though.

First we load in a small file of simple CSS. Then we do some PE fancy magic testing stuff and load in Fancy CSS for fancy browsers.

Actually, though, even the fancy CSS file is splitty too. Inside the fancy CSS file we do more little tests and give fancier browsers fancier styles.

Technical details

The initial split between basic and fancy CSS files is done using a media query on a link element.

The basic CSS is loaded like this:

<link rel="stylesheet" href="/css/style.css">

All browsers get this stylesheet (and it contains simple CSS rules that all browsers will understand). The fancy CSS should be loaded like this:

<link rel="stylesheet" media="screen and (min-width: 20em)" href="/css/enhanced.css">

Since it’s qualified with a media query, it should be the case that only browsers that understand that media query (goodbye old Internet Explorer, and many older phones) load that stylesheet. However, Scott Jehl’s tests have shown that this isn’t the case: browsers are greedy and download all the stylesheets, even ones they will never use!

That’s not so great. Ideally we’d like to improve Front-end performance by using Filament Group’s loadCSS to asynchronously load our enhanced stylesheet (so that it doesn’t block page render), but that would mean everyone downloads every stylesheet. Instead we use Scott Jehl’s eCSSential. This lets us load the CSS file asynchronously (yay, performance!), and use matchMedia to test for (min-width: 20em) with JavaScript. Testing with matchMedia in JavaScript rather than than a media query on a link element works: browsers only download the stylesheets they need. (Of course, we also provide a no JavaScript fallback in a <noscript> tag, in case something goes wrong somewhere.)

You can see an example of this in action on my work in progress project, fufu (A future friendly front-end style guide that even caters for feature phones).

Gotcha: older Androids

The use of matchMedia has me a bit conflicted. Looking at matchMedia on, we see that this means that Android versions less than 3 and Opera Mini users won’t get the enhanced stylesheet. If we went the loadCSS route, some Android 2.* users would get the enhanced styles (which their browsers are capable on displaying), but we increase data costs for all users, because everyone loads all the stylesheets.

Opera Mini, JavaScript, and mustard

Naga IT Services
Filed under: Industry

The rather talented Alex Maughan was in our office the other day, and we got to chatting about Opera Mini and JavaScript (as FEDs in our situation are often want to do). Our chat got me thinking a bit.

Opera Mini is a strange little browser. There are Android, iOS, and Windows version, but the biggest market is the version that runs on low end feature phones. Opera claims that it “works on almost any phone” and in my experience that’s certainly true.

I call it strange because despite running on low end tech it’s quite advanced. The article Opera Mini and JavaScript by Tiffany Brown on the Opera dev blog does a great job of breaking down exactly what (and how) Opera Mini handles JavaScript. More strangeness comes in because of the way it handles things: everything requires a server round-trip. This complicates matters for things like off-canvas / side drawer menus.

Feature testing versus device detection

What Alex and I were discussing was how to solve a particular conundrum. A feature-detection test on the JavaScript required to show / hide an off-canvas menu would pass on Opera Mini, but because of the server round trip, the experience would be a bit wonky. So, do we resort to device detection, which goes against our general Progressive Enhancement principles? In her article, Ms Brown says

99% of the time, you should use feature detection to determine whether a browser supports a particular feature or API. Yet sometimes browser sniffing is the right choice.

and I’m thinking that for Opera Mini, that might indeed be the right approach. I want to take a mustard cutting approach: probably using localStorage (support for localStorage on as the yardstick for “a higher end browser,” and load in the JavaScript for those only: that would exclude Opera Mini.

However, Opera Mini exposes a window.operamini object. Although this is still basically the same as device detection, it feels less horrible.


I’m still not sure, to be honest, but I’m going to stick with my mustard cutting for now. I quite like the combo of localStorage and querySelector: that gives me a set of fairly modern, fairly capable, browsers as a first pass.