Browse > Home / Handy tools and technology, Mobile, Podcast, Traffic / Blog article: Web apps v native apps v mobile sites: a guide

Web apps v native apps v mobile sites: a guide

In two year’s time mobile phones will overtake computers as the most popular device for web browsing, John Barnes, managing director of digital and tech at Incisive Media, told delegates at the Mobile Media Strategies day.

Users expect a seamless experience whether they are accessing websites on a Android device, a BlackBerry, iPhone, tablet, laptop or desktop.

It is therefore essential that news sites understand the future of mobile and work out whether to spend money developing a range of native apps: for iPhone, iPad and Android, for example; a web-based app such as the much-discussed web app launched by the Financial Times less than a fortnight ago; spend time building an m.site or opt for a mobile-friendly site.

Bear in mind the following facts:

  • The smartphone market is 25 per cent of the mobile market in the UK;
  • The UK is Europe’s leading market for smartphones;
  • There are 18 million smartphones in the UK. By 2015 there will be 42.9 million;
  • In 2015 there will be more Android smartphones in Europe than the total number of smartphones in Europe today;
  • Apple has a 82.5 per cent market share of apps;
  • Android’s Market will take a increased market share and dominate the market;
  • BlackBerry will (probably) switch to Android within 18 months, according to Dominic Jacquesson who has written a report on mobile. Indeed the BlackBerry PlayBook, a small tablet, which went on sale this week, can display some Android apps.

And consider your traffic drivers: with social media playing an increasingly important role in directing readers to stories – and with one in every six minutes online spent on social media sites in the US – it is worth noting the use of Facebook is already 40 per cent mobile with 250 million users worldwide, according to Jacquesson. Indeed, Facebook appears to be building an HTML5 web-based app to reach even more people, according to this article posted on TechCrunch.

What is clear from all of the facts is that you need to do something.

“I honestly cannot believe there are still people in publishing who don’t at least have some way of looking at their content on a mobile device that doesn’t mean looking at the full site itself,” said Ilicco Elia, who until last week worked for Reuters, told Journalism.co.uk.

There is no one size fits all, according to Mark Kirby, lead developer for Ribot, an award-winning mobile specialist, so his first piece of advice is do your homework.

If your title is B2B then most of your readers will probably be using a BlackBerry device. If you produce an art magazine, your audience is most likely to be one with iPhones and iPads. Do your research and don’t expect just because your readers have, say, Nokia handsets, that they download apps.

If you already have a mobile site you will be able to work out which devices your readers have by using data from Google Analytics and Webtrends.

“Have a look at your site on all handsets used by your audience, test it out and get those less familiar with your site to see how the experience feels for them,” advises Kirby. “Don’t just spend one minute testing on each device, spend at least 10,” he said.

And that experience and journey is very important. “It’s not about what technology can do, it’s about how technology can make you feel,” Elia said at the conference organised by the Media Briefing.

One you have your data some of the results may surprise you. You may find people are reading lengthy articles on a mobile. Just because people are using a mobile for web browsing, do not assume they are on the move and in a hurry. “Some mobile web-browsing takes place at home, and in a study of users of a mobile app, most were using that at home,” Kirby explained.

Mobile sites

The most important thing to remember is “don’t break the web”, which is something of a mantra for Kirby. Social media is likely to be a big traffic driver for you and a link from Twitter, Facebook or email should send a viewer directly to a story and not to your home page.

Kirby also stresses the importance of ensuring all content is on every version of your site and recommends having a button on the home page and each article page to allow users to flip between sites. Some mobile users may want to see the full desktop view, readers with large screens may want to see the mobile version.

He favours a single column view for mobile and spending time thinking about the user’s journey through your site.

There are two ways of creating a mobile site, Kirby explained. You can either opt for a “responsive website”, which uses the same HTML as your main site and a system of different HTML templates to display different sets of data. “You’re simply using CSS Media Queries to reshape it on various different size screens, mobile being one of those,” he said.

The second option is to use device detection “to serve up a different template, a different HTML, to mobile devices”, he explained.

“There are pros and cons of each,” he said. “The second option is less flexible but the first has more pitfalls.”

Where media analyst Elia is a fan of m.sites, which use a different URL beginning with ‘m.’, Kirby feels they are unnecessary. “I can’t really think of any argument for an m.site,” he said.

For those on a low budget Elia suggests taking a look at Instapaper and Readability and using one of them to format pages and suggests Mippin, which can take RSS feeds from your site and turn them into a mobile site or app.

Web apps

Web apps are hosted on a URL and are either made for a specific device or are hybrid apps made to be viewed on any device. The new FT app is currently available for the iPad and iPhone but built with the Android in mind and indeed based on the FT’s Android app.

“The hybrid is built by using HTML technology and a solution such as Phone Gap to package it. It’s much like a native app and some people wouldn’t realise it wasn’t. And then the code can be reused across multiple platforms: the iPhone, Android, BlackBerry and so on,” Kirby explained.

A web app may sound like a perfect solution to a problem in that you pay for the development of one app, rather than two or three, and an in-house developer team may well have the skills to build it. The other big advantage for sites which charge a subscription is that a web-based app bypasses the App Store, so publishers avoid paying Apple a 30 per cent cut for selling their content.

As Elia said: “Most news sites use pretty simple text, pictures and video, so you don’t necessarily tax a device as much as a 3D game would, for example, so a HTML5 web-based app is perfectly acceptable and you will be able to get as much as the wow factor as you need.”

However, readers will need to know that your app exists as they will not find it by searching in the App Store and, unless you are a major player such as the FT so able to generate sufficient buzz to result in 100,000 hits in the first week, you could struggle to get people using it.

The user experience may not be as good as with a native app, although the FT is reporting initial feedback has been good with many users finding the web-based app experience better than the native. If you have an iPad it’s worth testing the FT’s native app against its web-based one.

Kirby said for him (using an iPad 1) the web-based app seemed sluggish. “I have experienced these problems myself when building hybrid apps. It does seem perhaps they’re not there yet but the platforms will improve,” he said.

Native apps

There are two points worth remembering. Firstly “an app should be the answer to a question and not the question itself,” according to Kirby. It needs to be a solution to a problem rather than simply built for the sake of having an app.

Barnes offers a suggestion of how to test your need for one. “Write the press release on the launch of an app before you build it. You’ll often realise it’s a crapp – or a crap app,” he said.

Secondly, there is no need to hurry. “You don’t have to be first when it comes to apps,” Elia said, suggesting it was better to spend more time researching and developing a better app.

And a good app will cost you. Expect to pay a minimum of £20,000 per app as decent developers charge around £1,000 a day and it is likely to be at least two month’s work, Kirby said, and suggested an app is more likely to be in the region of £100,000 to £200,000.

Kirby also pointed out that iPhone, Android and BlackBerry users all have different expectations and expect a certain design. Android readers expect an app that looks like an Android app, iPhone users expect a familiar style, feel and layout too. However, “you need a branded experience across platforms”, Elia said.

The iPad offers “big opportunities for publishers”, Staffan Eckholm, from Bonnier’s Moving Media+ said last week.

But Kirby warns against trying to do too much. For him it is all about user experience – or UI – and he feels GQ’s iPad app is “confusing and stressful”, due to being so complicated it gives instructions on how to use it.

He points those considering a magazine iPad app in the direction of PixMax and to Zinio, an even better option in his opinion, which includes added functionality like links and hyperlinks within the contents pages of its products.

For several publishers initially the number of people using native apps is encouraging. This month the Guardian has reported 400,000 global downloads of its iPhone app, with more than 67,000 paying subscribers; the Economist has reported two million downloads of the iPad and iPhone app with 650,000 regular readers, most of them paying; the Times has not released app stats but in March said it had 79,000 paying digital subscribers; and although the Telegraph has not revealed figures it has said it is “hugely encouraged” by the number of people willing to pay to read news.

So it is worth remembering that it is barely a year since the first iPad hit shops in the UK and that the landscape for news consumption is constantly evolving.

Similar posts:

© Mousetrap Media Ltd. Theme: modified version of Statement