Saturday, February 6, 2016

RNZ Browser and OS stats for Feb 2016

A few times a year I release browser and OS stats for and The Wireless.

In this February 2016 release we can see that the the Chrome browser is still increasing its market share, and the shift from desktop to mobile continues.

It is no longer good enough to provide a mobile compatible site, or even a mobile friendly one - we need to be making sites where the mobile experience is excellent.


Browser 02/2016 07/2015 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009
Chrome 39.2 37.63 33.6 30.8 25.23 23.7 14.6 13.8 8.75 4.2
Safari 26.7 20.14 18 18.8 18.94 17.52 17.3 5.6 13.1 10
IE 9.83 14.73 17.2 18.9 24.02 26.3 37.5 41.2 50.6 56
Firefox 9.03 11.26 12.3 14.5 14.81 16.6 19.8 23.2 25.52 27.5
Safari (in-app) 8.78 7.8
Android 3.3 5.3 8.3 9.0 11.71 11 7.5
Opera 0.3 .38 0.4 0.4 0.46 0.69 0.7 0.9 1.02

At The Wireless things are very different: Chrome 48%, Safari (in app) 19.58%, Safari 16.27%, Firefox 7.5%, IE 4.3%, Android 1.7%

Operating Systems

OS 02/2016 07/2015 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009
Windows 36.2 42.67 44.8 48.9 52.9 58 67.3 72 81 84.8
iOS 31.3 23.37 21.42 18.4 16.6 14 7.88
Android 21.16 20.66 20.89 17 16.5 13.7 7.79 3.6 0.3 0.02
Mac 8.99 9.69 9.44 11.7 10.7 13.4 14.7 15.6 14.2 12.6
iPhone 2.5 1.4 0.56
iPad 2.4 0.63 0
Linux 1.04 1.38 1.6 1.9 1.8 1.27 1.53 1.4 1.45
Win Phone 0.7 0.82 0.63 0.57 0.44 0.39
iPod 0.5 0.35 0.22

And at The Wireless, iOS 31.4%, Windows 30.8%, Android 21.6%, Mac 13.6%, Linux .99%, Win Phone 0.55%


In June 2012 mobile was 16% of our traffic. In November 2013 it was 29%. In March 2014 it was 23.4% mobile and 10.8% for tablet, making 34.2%. In September 2014 it was 61.8%, 26.3% mobile and 11.8% for tablet. Feb 2015 it was 55.5% desktop, 32.8% mobile and 11% for tablet.

At the end of July 2015 it is 53% desktop, 34% mobile, and 12.4% tablet.

This month desktop has declined once again, now down to 45.6%. Mobile has increased to 42.49% mobile, and tablet is down slightly to 11.84%.

At The Wireless it is 46.7% mobile, 45% desktop, and 7.7% tablet.

Sunday, August 2, 2015

RNZ Browser & OS Stats for July 2015

This is the July 2015 release of browser and OS stats for and The Wireless.

The Chrome browser is still increasing its market share, and the shift from desktop to mobile continues.


Browser 07/2015 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009
Chrome 37.63 33.6 30.8 25.23 23.7 14.6 13.8 8.75 4.2
IE 14.73 17.2 18.9 24.02 26.3 37.5 41.2 50.6 56
Safari 20.14 18 18.8 18.94 17.52 17.3 5.6 13.1 10
Firefox 11.26 12.3 14.5 14.81 16.6 19.8 23.2 25.52 27.5
Safari (in-app) 7.8
Android 5.3 8.3 9.0 11.71 11 7.5
Opera .38 0.4 0.4 0.46 0.69 0.7 0.9 1.02

At The Wireless things are very different: Chrome 45%, Safari (in app) 22%, Safari 13.8%, Firefox 8.1%, IE 7.8%, Android 3.3%

Operating System

OS 07/2015 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009
Windows 42.67 44.8 48.9 52.9 58 67.3 72 81 84.8
iOS 23.37 21.42 18.4 16.6 14 7.88
Android 20.66 20.89 17 16.5 13.7 7.79 3.6 0.3 0.02
Mac 9.69 9.44 11.7 10.7 13.4 14.7 15.6 14.2 12.6
iPhone 2.5 1.4 0.56
iPad 2.4 0.63 0
Linux 1.04 1.38 1.6 1.9 1.8 1.27 1.53 1.4 1.45
Win Phone 0.82 0.63 0.57 0.44 0.39
iPod 0.5 0.35 0.22

And at The Wireless, iOS 31.6%, Windows 31%, Android 21.7%, Mac 13.5%, Linux .93%, Win Phone 0.6%


In June 2012 mobile was 16% of our traffic. In November 2013 it was 29%. In March 2014 it was 23.4% mobile and 10.8% for tablet, making 34.2%. In September 2014 it was 61.8%, 26.3% mobile and 11.8% for tablet. Feb 2015 it was 55.5% desktop, 32.8% mobile and 11% for tablet.

As at the end of July 2015 it is 53% desktop, 34% mobile, and 12.4% tablet.

At The Wireless it is 47% mobile, 45% desktop, and 7.4% tablet.

I should note that the sudden skew to mobile at The Wireless is because several of their stories have done well internationally, and much of that traffic was mobile.

Wednesday, June 17, 2015

What CMS Should I Choose?

Over the last 20+ years I have built, chosen and deployed many web content management systems (CMS). I've also integrated them with existing business systems and processes.

The task of choosing a CMS for your own use is filled with hard questions. Do I build from scratch or buy off-the-shelf? Can I use Open Source and customise? Should I licence the software or buy it outright?

These are not the right questions.

Better questions revolve around how well the CMS can support and enhance the business, and whether it can continue to do this as the needs of the business or the customer change.

In an earlier post, I outlined 4 things a CMS must do. To recap, it must: 
  1. Be able to deliver your product to the customer.
  2. Support your back-office processes.
  3. Integrate with your back-office systems.
  4. Allow you to keep innovating.
All of them 'obvious' yet I know of projects that have failed to even deliver satisfactorily on point 1.

The greatest tragedy of many CMS selection projects is that unreasonable constraints are in play before any business needs are even written down. Constraints such as:

1. The technology to be used.

This may include the operating system or database type, or even the CMS itself.

"We are a 'X' shop."

"We only have 'Y' Licenses."

I am not saying anything about 'X' and 'Y', just that the thinking is a constraint you could do without.

There is also, "We have too much invested in our existing suite of products to change".

2. The vendor to be engaged.

"We already have a relationship with 'X' to handle this for us."

Again, nothing wrong with 'X'.

3. The project owner

"All projects in the company with a major IT component will be run by IT."

There are a lot of fishhooks in here. Projects need to be run well. There have to be agreed outcomes, and risks have to be managed. The issue I have is that this is a business project. The technology being selected is to support a specific business process and a defined output.

An example of a purely IT project would be a network switch upgrade. There may be business outcomes such as improved throughput, but the core of the work is technical.

In a business project the majority of the outcomes are on the business side - faster publishing of content, easier workflows, and improved ease of use for the public being just three examples.  

Certainly, let anyone with a good track-record in project management run it. Just remember they are working for the business owner of the project. The technology is the servant. Everything it delivers must serve the business. If there are integration issues, put someone from IT on the project team.

4. We have to support it.

"All company IT is supported in house for security reasons. We have to know what the users are doing."

Working for the GCSB or SIS? OK, you can pass on this one. The rest of you don't get to pull the security trump card to stop new systems being selected. A good project will assess security implications of new systems. As above, include someone from IT who specialises in your in-house security on the project team.


Constraints like these are bad because they ensure that any project process will only deliver what it is allowed to deliver. That is not good enough in this modern age.

So back to the question, what CMS should I choose?

You could look at just the features, and Smashing Magazine covered those basics back in 2009. Not much has changed, but that isn't really the right answer either.

The key to getting the right CMS is to have an understanding of the business objectives for the site, the content publishing processes (existing or new) to be supported, and to run an excellent selection process. In that, you'll want to avoid artificial constraints such as those mentioned above.

Real constraints such as budget, time-frame and project scope are fine.

You will also want to adopt some agile thinking - the project must be able to adapt as new information comes to hand, or as the business or the market changes - and you must have the flexibility to change some of the project parameters.

It is true that you have the most flexibility with systems based on Free and Open Source Software, but that might not be a requirement. You may need to outsource development and support of your whole system. These are long-term decisions, and you'll need a lot of information to get it right.

If you go with a proprietary system will it be agile enough if market conditions suddenly change? Only you can say?

Are you going to be disrupting an already existing market. Yes? Most disruptors are using Open Source. End of story on that one, really.

One trap is to try to copy someone else's 'magic formula'. It is almost never successful. If you try to copy a competitor by using the same system you lose, because they already have a head-start and you can only act based on the public information you have. This will be out of date.

Another is go with fashion. All the cool sites are using Rails, so let's use that. Bad again. The've chosen Rails for specific reasons based on their product, development process, funding and market. You might come to this decision independently - in which case, great - but if not, think again.

A third is to get someone else to decide. No one knows your business and your market like you do. Any consultant or vendor is never going to reach your level of understanding. You are the best judge of what factors are important to you.

If you are unsure, by all means engage an independent consultant who is familiar with running selection projects. They should be able to help you balance all the required factors based on your own business requirements.

The bottom line is that it is not really a question with a simple answer.

Should we underline links on headlines?

It has become fashionable in recent times to remove underlines from links on home pages and lists of repeating summary content.

You see this pattern on the home pages of almost every news site on the planet. One assumes this has been done in the name of aesthetics, but my guess is that in many cases little thought was put into the user experience.

Google did it, to much fanfare. "The link underline is dead!",  some proclaimed.

The important question is, should we do the same? The answer is, it is complicated, but well researched.

In his excellent book Don't Make Me Think Steve Krug wrote about designing websites so that users do not have to stop and think what to do. If a site visitor has to 'think' it interrupts their flow and creates a bad experience. In extreme cases they abandon the site or the task they were doing.

There are two levels of 'thinking' in this context.

The first is unconscious. Users may find it slow to move around a site, tasks take longer than they should, they have to re-read pages to work out what to do. There is a general feeling of frustration, but they do not know why. They may not even be aware of the feeling.

The second is conscious. This occurs when the user experience is so bad that they recognise their own frustration, and the reason for it. They think, "this website sucks".

I'd wager that most people have encountered this feeling when using online booking forms.

That feeling even has a name - ego depletion. When the cost of thinking goes up, energy consumption increases, and you start to become 'aware' of a problem.

I strongly recommend you read this article on managing ego depletion. Read it now before continuing here.

It has been known for years that faster websites are perceived as being more credible. It is also known that a slow website reduces revenue.  Colour, typeface and whitespace also impact the user's perception of the content and the time it takes to consume content.  There are a whole package of factors that must be understood and managed when designing a website.

So, returning to the subject of links, the Baymard Institute has researched link underling and found the following:
"If you see an underlined word or sentence in a text online, you immediately conclude that it’s a link."
Nielson Normal Group also have advice on links:
To maximize the perceived affordance of clickability, color and underline the link text. Users shouldn't have to guess or scrub the page to find out where they can click.
Google did it because they have a fixed layout, the site only does only one thing, they have clear colour differentiation between links and other text (and only link the headline), and they were able to extensively test the impact of the change before doing it. Not everyone agreed, though. 

But links are so ugly, I hear you cry, especially on large type or when they are lots of them grouped together.

I agree, and there are solutions to both these problems.

The first is to adopt customised link underlines. Medium has done it, and many others have followed suit. Others are experimenting with different styles. Wired uses quite bold inline links in body copy. The link underline is back!

Custom underlines allow you to control the position, size and colour of the link. You can retain link underlines but make them more subtle. Radio NZ does it too. If you want to know more about this technique I'd recommend two articles. This one shows a basic implementation, while this goes into much more detail and provides a method to make it automatic.

The second is to use a faux link overlay. This allows you to have one visible link on the headline, and an overlay that makes the headline, image and summary area clickable. This technique is used quite widely by the BBC where they have applied a few tweaks to make it more accessible.

It avoids the very common pattern where headline, image, summary text and sometime even a 'more' link have the same link, forcing removal of all underlines.

One side note. Adding an underline on hover does not count anymore. There is no hover on touchscreen devices, and for many sites these now make up 50% or more of visitors.

There is one downside to having clearly defined navigation pathways: time on page takes a dip because people can quickly identify actionable links on a page. And they click on them. If you combine that with a clear uncluttered layout the effect may be even more marked; people can quickly see if this content is what they want, and if it is not they click on the something else. Some might even say that this is what a good user experience is!

I'd suggest that on mobile devices clear layout and clearly defined pathways are even more important. Size (and time) is at a premium on these devices.

So there it is. You can have links that don't look ugly and so ensure that everyone has a good experience of your site. And that's the business we are in.

Sunday, May 24, 2015

Stop Wasting My Time - Please Fix Your Podcast!

There has been an explosion of podcasts in the last few years. Whatever you are interested in there is a podcast for it. 

Medieval Castles? Yep. Haute Couture music? Yep. Recruiting? Yes.

I am a huge consumer of podcasts. I listen to everything from tech podcasts through to arts and much in between. It broadens the mind, apparently.

My background is in radio production and music engineering. I have worked on (probably) thousands of radio programmes, features, and live broadcasts.

I will talk here only about the subject matter podcast - it is about a particular thing - rather than the personal interview ('life and times'), documentary, or news interview ('just answer the question please'). Those are much more difficult and most of them require a lot of research and planning to execute well.

Subject matter podcasts also require research and planning but are limited in scope and your guest can be a great resource to help you identify the key points that need to be covered.

Please don't take any of this advice personally. :-)

General Guidance

Podcasts should have a beginning and middle and an end. The most important part of the interview is the setup at the beginning and there are two main ways to do this.

The first is the formal introduction. You hear these on radio all the time: "My guest this morning is Joe Bloggs. He is a specialist in micro macro blah blah blah, and he has just published a new book exploring the micro macro world of blah blah blah."

Include any information that is relevant to this interview and that adds enough context for the listener. 

The second is the self-introduction. In this case you ask the guest to introduce themselves. This is slightly trickier and is more appropriate when they are an expert. It is OK to get them to practice this and to coach them to get it nice and succinct. He is how I'd intro myself for a podcast about building the Radio NZ website: "I'm the webmaster at RNZ - I have been doing that for 10 years since I lead the project that rebuilt the site to include news and audio. My background is in sound engineering, and I have managed some large technology projects for RNZ.  I'd always done programming and web stuff on the side, which was the reason I got chosen to lead the original web rebuild project back in 2005."

Try to keep the introduction to less than 30 seconds. 

The middle part of the podcast is the interview proper; you ask the questions and the guest gives the answers. It is the important bit, the reason someone would listen. Think of yourself as a guide and facilitator. You are there to help guide the course of the interview so that the listener can follow the subject, learn something,  and to get the best out of the interviewee.

This is where I hear the most problems. Don't assume your listener knows the field you are discussing. This is a particular problem for the specialist podcast. There is a balance to be drawn between talking down to your regular audience, and making things understandable for new listeners.

Experienced interviewers will sometimes talk about the shape of the interview. It will have high points, low points, but an overall arc that keeps the listener engaged. The best way to learn this craft is to listen to the best. I'd recommend listening to the way Kim Hill works, or Simon Morton for specialised content. 

The end of the podcast is simple. Thank the guest, refer listeners to notes about the show on your website (you do have a website, right?) and perhaps preview next week's show. 

Listen back to the podcast to compile (or add to) the show notes, and to edit. Don't take notes in the interview, except to capture something the guest said that you want to come back to.

Here are some of the problems I hear in podcasts and my solutions.

Problem: The sponsors' messages at the start of the show are too long. The worst I've heard is 5 minutes.

Solution: Spread them out through the show if you can. Perhaps have just one sponsor in the intro and charge a premium for that placement. 

Problem: The guest is over-introduced/not guided.

A two minute introduction is way too long. Also, the first question to not ask your guest is, "what have you been up to". I don't care. I want to hear the guest's thoughts on the topic you've carefully outline in the title and description of the podcast. The worst example I've heard of this was a one hour podcast that spent the first 30 minutes discussing their respective housing, commuting and job situations. Sorry, but I don't care if you are both internet stars. I don't care about this stuff. Life is too short.

Problem: Too many anecdotes from the host.

Solution: Don't tell any. We want to hear from your guest. If you must tell an anecdote it should be there to move the interview along or provide a transition between sections of the interview

Problem: Too many hosts 

Solution: By all mean have multiple hosts, but one person must take the lead in the interview. I did hear one podcast with two hosts where they broke the interview into blocks and each host asked a series of questions based on their own areas of expertise. This provided a nice contrast and was an effective way to deal with a some complex technical questions.

There is some mental overhead whenever a new voice is heard in a podcast, so try to minimise this unless it is a panel discussion.

Problem: The sponsors messages within the show are too long. The worst I've heard is 6 minutes.

Solution: Limit the length of in-show sponsors messages to 15 seconds for a mention or 30 seconds for an endorsement. Tell me only one thing about why I should care about this sponsor's product. Better to have 6 short mentions in a one hour podcast than one of 3 minutes duration. 

Problem: Fawning over the guest.

Sometimes the host cannot get past their delight about being in the same room as the person they've admired for many years. They end up not talking about anything substantive.

I once heard an interview with Tom Peters where the interviewer spent considerable time telling him how wonderful he was, what an honour it was, and how influential he'd been. Everyone knows that. Get the guest to tell me something I didn't know. For example, what are they working on at the moment? Do they think they made a real difference in their field? Do they have any regrets? Are they still making a difference?

Solution: If you really, really cannot stop yourself remove it from what you post online.

I am going to give you an example of how an interview with a 'big name' person should be done. In this podcast Sarah Green from HBR interviews Eric Schmidt and Jonathan Rosenberg from Google about managing talent.

She gets straight into the interview after a brief introduction and only at the end does she introduce a personal note (about a Star Trek reference in their book), and then wraps up the interview. Go listen now.

Problem: The podcast rambles. Two hours is too long. 90 minutes is pushing it unless the guest is riveting or the discussion is on-fire. You may have thought it was at the time, but listen back and be honest with yourself. You don't have to fill any particular time-frame. This is not a live radio spot.

Solution: Prepare. Plan, Do some research into your guest to get some ideas for interview questions. Once the interview of over, edit ruthlessly. There is an expression in the industry about killing your babies. You have to cut weak content, and sometimes content you are really attached to. 

Ask yourself these questions: Is this moving the interview or story forward? Have we already covered this?

Problem: Too many jokes.

Solution: Unless this is a podcast about telling jokes, avoid. Jokes can really destroy the flow of an interview. They have to be good. Really good, and relevant. Jokes that are part of the context of the interview, told by the interviewee are the best. Jokes with a tenuous and oblique connection should be avoided.

Problem: Useless or quirky podcast titles.

This creates a massive problem for people looking for good content. Should I listen, or not? Is it worth pressing play? Who can say? This is compounded by a poor or non-existent introduction.

This fine if you are Big Bang Theory; you already know what you are getting when you watch.

Solution: Use good title and summary text so the potential listener knows what the topic being covered is and the name and brief qualifications of the guest. If must have a title with alliteration (for example) still give the listener the information they need.


I have only just touched the surface here - there is a great deal more that could be said about how to conduct an interview, how to plan, and problems to avoid. Hopefully this overview of some of the key issues will help you improve your own podcast.