Last week the BBC updated its mobile homepage at m.bbc.co.uk, claiming that after three years the old one was “beginning to look a bit dated, particularly on mobile”. Reaction from users was overwhelmingly negative. Here are just a few of the more than 700 comments posted within the first 24 hours of the change.
“…the front page articles link to the desktop site. So this new front end is worthless…”
“…Images way too big…”
“AWFUL I am all for progress but this is not progress if it isn't broken don't fix it!”
“Please don't roll out a new site if it removes functionality. Customisation is a big thing and now I have to poke around to find the stories I'm interested in.”
“I think the previous comments have covered it. Awful. Horrendous.”
The BBC is one of my main sources of news and entertainment and I access the BBC on my mobile four to five times a day. I’m also a technologist focussing on how the web works and the complexity associated with delivering a good user experience. Here are five things any web professional can learn from the BBCs experiences with its new mobile home page.
Testing changes before releasing them to everyone is now easier than ever. Judging by the comments received, the BBC has a passionate group of users and a subset would have been very happy to have provided feedback on a beta version. They would also feel part of the change.
Launching “whole hog” in the way the BBC has done can only be due to some technical limitations or political pressure from management. As the site uses Node.js and Express, which is certainly flexible enough to support beta testing, I can only assume political pressures. Very BBC.
Keep popular features
The previous version of the mobile homepage enabled frequent users to customise the content received. I’m more interested in business and technology stories than sport so I remove sport from my homepage. The new homepage doesn’t support this feature and many comments express frustration at its removal.
Had the BBC analysed users enabling customisation and their visit frequency, I expect they would have seen that among frequent users customisation was heavily used. The irritation expressed at its removal was likely to be predictable.
On 8 February the previous homepage had a total page weight of less than 600kb. Most of this was made up of images and background technology like jQuery (which in my opinion is unneeded and could be sacrificed to save 100kb and speed up performance, but that’s one for another article). The new homepage weighs in at just under 1mb, or 70 per cent heavier!
Much of this is to do with images, which just aren’t needed, a view shared by many commenters. And many of the images downloaded (those for iPlayer and the footer promotion) are never displayed unless you explore all the navigation or have a large enough screen!
Michael Skelton, senior product manager, did say: “The editorial team have the ability to use less image-heavy layout options to present stories, and over the coming days, will be experimenting with these…” However editorial teams are unlikely to consider website performance when they choose images to associate with stories. The technology needs to prevent content editors from doing stupid things so setting a limit on the weight and layout of pictures which prioritises performance seems sensible.
The old homepage and the new homepage contain an equal number of links to web content at 18 each. However on the new homepage, only 1 of these 18 links is visible without scrolling on an iPhone 5C. These 18 stories are spread over six screens. Previously only 3.5 screens were needed. The increase is partly due to increased use of images, but also inefficient layout.
The screenshot shows two lines are allowed for each headline, even when the headline doesn’t require the extra line. To be fair this was also a drawback with the old design, but an upgrade should improve on such things rather than perpetuate the problem. Also, larger images are used with headlines appearing over the image.
The new page adds links to 12 TV and radio programmes from iPlayer (the BBC’s on demand service) using a horizontal scroll to view them all. This may just be me, but I don’t watch iPlayer on my mobile phone. I do listen to podcasts and radio (when I have a consistent data connection). When I do I like factual, news and drama content. I’m not interested in soap operas or reality TV.
Highlighting new content is important but could be done in a more space-efficient way using personalisation to limit the options. Personalisation can have a big impact on user interface design and performance.
Two layouts too few
A big screen with 100 square inches of screen space can display a lot more content than a smartphone with 6 square inches. The BBC understands this, which is why it has a mobile website and a standard big screen desktop layout. But smartphones now range from 4 square inches to 10 square inches. That’s a big difference and one layout doesn’t often work for them all.
Another misconception is that tablets and desktops/laptops should receive the same layout. Again there are plenty of differences to how they’re used and their performance. Increasing the number of layout options to include small screen mobile (11”) would reduce many of the problems identified. The user could easily change their preferred layout through customisation.
Maybe the BBCs device detection provider can’t provide this level of granularity which is why it has not been considered.
The team at the BBC face a difficult challenge. Do they roll back the changes and acknowledge they’ve learned some things, reconsider and try again? Or do they make changes quickly to address the feedback? I don’t envy them, but the dilemma was entirely preventable had they considered some of the points highlighted above.
With the web, using the right technology, making changes little and often, with plenty of A/B testing and analysis, is almost always better than one big change.
James Rosewell is founder and chief executive of 51Degrees