Saturday, April 9, 2016

New home for blog

I am now blogging over at richard.hulse.nz. See you there.

Saturday, February 6, 2016

RNZ Browser and OS stats for Feb 2016

A few times a year I release browser and OS stats for www.radionz.co.nz 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.

Browsers

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%

Mobile

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 www.radionz.co.nz and The Wireless.

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

Browsers

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%

Mobile

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.