Monday, June 2, 2014

8 years of data

I have just published a Google doc of eight years of Operating System, Browser and Mobile data for www.radionz.co.nz.

I have also included a couple of graphs such as this one showing the decline of desktop use (click to see a larger version).

A graph showing the decline of desktop use (65% in 2006) compared with mobile (35%)
There are other interesting trends - the decline of IE, the decline of the Windows desktop OS, and the rise of Chrome (all as a percentage of the market) are also evident in the data.

Graph showing the decline of IE, and the rise of other browsers such as Chrome and Firefox


A graph showing the decline in Windows from nearly 100% to just of 50%. iOS, android and OS takng much of that.

I have released this data under a Creative Commons Attribution-ShareAlike 4.0 International License, so please share links to anything you do with it in the comments below.

Sunday, May 18, 2014

A visual aid to show you which media query is active

I've found it handy during the development of responsive CSS to know what stylesheet or media query is active.

The following is an example of how to dynamically add labels to a page.

@media screen and (max-width:600px) {
  .site-time p::after { 
    content:" (0-600px)";
  }
}

@media (min-width: 601px) and (max-width: 800px) {
  .site-time p::after { 
    content:" (601-800px)";
  }
}

I've picked an element that was in every variant of the site layout, and appended some text indicating the active sheet.

Sunday, March 23, 2014

Radio NZ Browser Stats - March 2014

Here is another lot of browser and OS stats for www.radionz.co.nz and The Wireless.

Size of Content Library

The audio library now contains 27,000 hours of material, all of it searchable from www.radionz.co.nz/audio. That is 179,000 items, most of which are downloadable and embeddable.

We also just partnered with DigitalNZ who now have a copy of most of our audio metadata, and update it each night with new content.

Browsers


Browser 03/2014 11/201306/201211/201111/201011/200911/2008
Chrome 25.23 23.7 14.6 13.8 8.75 4.2 1.47
IE 24.02 26.337.541.250.65663
Safari 18.94 17.5217.35.613.1105.66
Firefox 14.81 16.619.823.225.5227.527.73
Android 11.71 117.5
Opera 0.46 0.690.70.91.021.08

IE is still in decline, and IE6 is 0.32%, IE7 1.86%, IE8 25%, IE9 20.7%, IE10 13%. IE11 is new at 37%.

At The Wireless things are very different: Chrome 37%, Safari (in app) 20%, Firefox 13%, Safari 12.5%, IE 11.3%, Android 5.0%

Operating System

OS 03/2014 11/201306/201211/201111/201011/200911/2008
Windows 52.9 5867.3728184.889.3
iOS 16.6 147.88
Android 16.5 13.77.793.60.30.020
Mac 10.7 13.414.715.614.212.68.5
iPhone 2.51.40.560.19
iPad 2.40.6300
Linux 1.9 1.81.271.531.41.451.72
Win Phone 0.44 0.39
iPod 0.50.350.220.08

And at The Wireless, Windows 42%, iOS 26.5%, Mac 18.3%, Android 11%, Linux .78%, Win Phone 0.48%

Mobile

In June 2012 mobile was 16% of our traffic. In November 2013 it was 29%. It is now 23.4% mobile and 10.8% for tablet, making 34.2%.

The most popular devices are the same as last time - iPad (25%), iPhone (22%), and Samsung GT-I9300 Galaxy S III (5%)

Over at The Wireless 38.3% of the traffic is mobile, with popular devices being iPhone (51%), iPad (17%) Galaxy S III (5%).

Saturday, November 23, 2013

November 2013 Browser Stats for Radio NZ

Here it is once again - my roundup of browser and OS stats for www.radionz.co.nz. This time I'm including stats from The Wireless.

Size of Content Library

The audio library now contains 25,000 hours of material, all of it searchable from www.radionz.co.nz/audio. That is 167,000 items, most of which are downloadable and embeddable.

Browsers

Browser 11/2013 06/201211/201111/201011/200911/2008
IE 26.3 37.541.250.65663
Chrome 23.7 14.6 13.8 8.75 4.2 1.47
Safari 17.52 17.3 5.6 13.1 10 5.66
Firefox 16.6 19.823.225.5227.527.73
Android 11 7.5
Opera 0.690.70.91.021.08

IE is in decline, and IE6 is 0.6%, IE7 3%, IE8 31%, IE9 22.6%, IE10 42%.

At The Wireless things are very different: Chrome 35%, Safari 16%, Safari (in app) 16%, Firefox 15%, IE 9.4%, Android 5.5%

Operating System

OS 11/2013 06/201211/201111/201011/200911/2008
Windows 58 67.3728184.889.3
iOS 14 7.88
Android 13.7 7.793.60.30.020
Mac 13.4 14.7 15.6 14.2 12.6 8.5
iPhone 2.51.40.560.19
iPad 2.40.6300
Linux 1.8 1.271.531.41.451.72
Win Phone 0.39
iPod 0.50.350.220.08

And at The Wireless, Windows 40%, iOS 26%, Mac 20%, Android 10%, Linux 1.9%, Win Phone 0.55%

Mobile

When I last published stats in June 2012 mobile was 16% of our traffic. It is now 29%.

The most popular devices are iPad (27%), iPhone (21%), and Samsung GT-I9300 Galaxy S III (6%)

Over at The Wireless 36% of the traffic is mobile, with popular devices being iPhone (47%), iPad (21%) Galaxy S III (4%).

Social

20% of referrals to radionz.co.nz come from social sites (and 35% from Google news).

73% of referrals to thewireless.co.nz come from social sites.

Saturday, June 8, 2013

Why you should allow time (and pay) for refactoring of code

At Radio NZ we engage outside contractors to help us build the web applications we use. The most public of these apps is our website, and internally there is a large database system that is used company-wide.

One of the challenges of writing code is that over time the codebase tends to become rundown. This can be made worse if many people are working on that code. Differences in coding styles, changes in best-practices over time, current (and past) fashion; these all contribute to software rot.

That is not to say that the code was bad when it was first written, or that the original developer did not know what they were doing. Most likely, they did know what they were doing at the time, based on what they knew at that time. Perhaps there were other contraints (such as limited time). Someone did there best, at the time.

Refactoring is a critically important part of maintaining a software application.

Wikipedia describes refactoring:
Code refactoring is a "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.
It goes on to quote Joshua Kerievsky:
By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code. — Joshua Kerievsky, Refactoring to Patterns

Some will say, "if it ain't broke don't fix it".

Apply that to your car or your house and gardens and see where it gets you. Where it gets you is: broken down in the middle of nowhere, and your phone battery is flat because who needs to charge those things anyway. Or a house that has to be re-clad because you did not repaint it early enough, and the garden, well, I think we have all seen those.

Your code is a valuable asset. It contains business logic - knowledge about how things should work that have been built up over time, and codified in the software. You paid for the process that converted that knowledge to code.

The source code repository also contains (or should contain) business intelligence about why certain decisions were made, and the evolution of the code over time. This is vital information for future developers. If you do not have a code repository, please look for another field of work. Now.

Refactoring has a cost attached. It takes time. But at its core, refactoring is about reducing future costs.

You must accept the cost of refactoring, and make time for your developers to do this work.

The benefits are twofold:

1. Better quality code that costs less to maintain over time.

2. Your staff will be more productive.

On point two, everyone wants to have pride in their work. For programmers, refactoring code is a key part of the process of remaining connected to the code, and experiencing joy in their work. Many studies have shown that happy staff are more productive, on top of the gains of working with quality code.

At Radio NZ I encourage the developers who work for us to suggest refactorings, and I allocate the time for them to do the work because I see this as an investment in the future. The person who has to maintain this code might be me. Or it might be you

Forcing people to continue to work on code they know could be improved without letting them make those improvements is bad management.

Some of the code in your system will be hard to refactor. It is probable that this code was put together quickly, possibly without tests. Don't let this put you off. Read and understand the concept of technical debt.

Also, watch this excellent presentation where Katrina Owen refactors some code that has no tests. Watch it a second time if you don't quite get it. If you are technical, read Martin Folwer's book.

If you use Ruby and/or Rails read the book Practical Object-Oriented Design in Ruby. The approach outlined in book has fuelled many refactorings in our projects.

On point about tests. Having good tests is necessary to facilitate refactoring. Without tests you have no way to know for sure that the refactored code behaves the same as the original code.

Chances are, if you don't already have good tests, you will already being seeing application errors after changes to the code, and that these will be hard to find and fix. You'll also see new bugs appear as the direct result of fixing an existing bug. Yes, just like Novapay.

I suggest you do three things:

1. Right now, go and ask your key developers, is there some part of the application that is wasting their time and should be refactored. Get an estimate of how much time is required, and schedule it.

2. Start a discussion with your developers about the overal design of the app. Does it support where the business is now? Is it making future enhancements difficult, or reducing productivity and/or job satisfaction?

3. And more broadly, find out from from each of your developers three things that they feel make it hard for them to produce quality work. Don't put your own definition on quality, just ask the question. Make a commitment to fix these things.