11th

Jul

Apps vs Web

Mobile apps v mobile web is a hot topic at the moment, so it offered strong and relevant subject matter for MoMoMcr’s first debate and attracted approximately 110 attendees from the region’s mobile and digital communities.

Introduced by MoMoMcr’s Garry Partington and chaired by blogger Volker Hirsch, the expert panel included Code ComputerLove’s Ste Brennan,Matmi’s Jeff Coghlan, Brendan Dawes from magneticNorth, Duncan Stockdill of Capsule CRM, Adam Fleming from Apadmi2ergo’s Richard Millington and Tim Haysom from the WAC.

With such a strong mix of both web and app specialists putting forward their case as to whether the future of mobile lies with native apps or the web, was a heated debate on the cards?

First up was Ste Brennan who started by making the point that the phrase ‘mobile web’ could be misleading as people could construe it as meaning purely ‘mobile website’ when, in fact, apps themselves are web aware.   Ste felt that clients often ask for an app without being sure that’s really what they need.  What they should do is start by looking at how they can make their website mobile aware to provide a good user experience – ensuring it renders well on mobile and tailoring the content through use of geo-location etc.

Ste’s feeling was that we shouldn’t get too hung up on the technology as it’s not quite so clear-cut as to whether you’re building a native app or a mobile website because there are so many ways of building an app – you can use a browser wrapped in a native app, Titanium X, Flash or the native code itself.  If the user can’t tell difference, it doesn’t matter which technology has been employed, it’s the end user experience that’s important.

Ste felt that, if put on the spot, he feels that native apps have the advantage as they currently provide a tighter experience and are more slick.  He also pointed out that the current model is unsustainable and we need one common platform that will support all apps.

Brendan Dawes also felt that it all boils down to end-user experience.  He commented that there’s no such thing as a mobile web app – there’s web pages made for mobile, but they’re not actually apps. The appealing aspect of true apps is that you can ‘collect’ them in a way that you can’t collect web pages.

Brendan concluded that whilst there is loads of great web development technology available, if you want to create a really beautiful experience with the subtle transitions that make all the difference, a native app does the job better.

Rich Millington had a similar view that the main difference between mobile apps and web is the way in which the user interacts with them.  When faced with a choice of apps or web, brand-loyal consumers are more likely to opt for an app as it provides a slicker experience and may offer functions that aren’t possible within mobile site architecture.

It’s all about what companies want to get from their mobile channel – have they got the budget, are they new to mobile, have they done anything before in the mobile channel?  Discovery of the brand is important so, for example, an app would be more suitable for Next, who has brand-loyal consumers, whereas a mobile site may do the job fine for a retailer like Boots who is selling more commodity-led items.

Another factor that needs to be considered is whether the content/layout is likely to change a lot?  If so it might make more sense to build a mobile site.  Also think about if there gaming elements or loyalty involved in the app.

We need to look at how we can make efficiencies greater across application operating systems and make them more cost-effective.  Apps should have a specific function outside of the mobile site to give them longevity.

Tim Haysom said that we should consider how to make apps that don’t just sit on mobile but have the ability to interact with other apps, eg in cars and on set-top boxes.

Going forward, both web apps and native apps will continue to exist but they will be used for different purposes.  If a developer wants to access to all the latest and greatest capabilities of a device, they’re not going to be writing a web application, they will be writing a native app.  However, everybody also wants access to loads of other services, and that’s where having a quick and simple updatable application that uses web technologies can be useful.

Services like Facebook and Twitter are changing week by week in terms of user experience whereas if you buy an iPad app it’s going to stay the same so you don’t get the interactive user experience that can be constantly and easily updated. Tim noted that the FT and Facebook are pushing html5 and pointed out that the new FT service will be provided through an html5 app, rather than native app, as the FT wants its service to be available on lots of different devices.

So an app can be anything that a user wants it to be.  For some it’s a native app, downloaded from an app store, but for another user it could just be a bookmark which looks exactly the same on some devices as an app – click the button, it  takes you to a web page that can look the same as an iphone or android app

Tim concluded that, at the moment, if you wanted to compare a web app with a native app, the latter would look better but, in the future this will change as all the hardware will be made available to support web technologies.

Jeff Coghlan from Matmi agreed that the solution chosen is dependent on the desired end-user experience.  The concerns are all to do with what technologies will work with different platforms. We shouldn’t overlook the use of middleware, such as Unity, which allows us to port stuff to iphone, Android, web, Playstation, Wii and X-box etc.

He said that mobile web currently has limitations but not everything needs an app. It all depends on what the customer actually requires.  Work out what you need to give to the client and base your decision that.

Adam Fleming from Apadmi also agreed that he doesn’t like the phrase ‘app versus web’ – we should be talking about ‘app versus some kind of runtime of some description’.  A native app is something to communicate with a device to an extent in the way that the device applications themselves communicate with a device.  The underlying operating system isn’t always what you’re writing the app for.  The nub of the question is: do you actually want and need to be talking directly to the device, at the level that the device is written in, or are you happy to accept a level of abstraction?  You pick your tool set based on what it is you’re trying to achieve, the budget you’ve got available and what you’re expecting to do with it after your initial deployment.

 

It depends on what you’re trying to do; why you’re trying to do it and how much longevity you want it to have.  If, for example, it’s a marketing campaign that will run for 6 months and go to a few thousand people, it’s not worth it. However if it’s something that is performance critical, and has to be 100% right and needs a very fine degree of control, you’re not going to be able to do that through any abstraction platform, regardless of what level that abstraction sits at.

Our final panelist, Duncan Stockdill from Capsule CRM, staked a claim for web, rather than native apps. He felt that, for a service like Google Plus, for example, which has the aim of exposing the service on as many mobile devices as possible, it makes sense to build on one environment (web device) and then roll it out across as many devices as possible.

 

He said that html5 and Javascript worked well in his experience and that Capsule CRM have created a mobile web app that feels exactly like a native app, although it’s easier to get the ‘native’ feel with an iPhone than it is on an Android.  The future looks really strong for Javascript in particular – extensions will make Javascript as a development platform really quite powerful and quite easy.

So all in all some interesting points on mobile apps and web were raised by all our experts who, in conclusion, seemed united in the view that it really does all boil down to the desired end-user experience.

Thanks to all of our panelists and to all those who attended, either to ask questions or simply to listen to the experts and network with like-minded colleagues.

Thanks to our sponsors for sponsoring the event and for their ongoing support of MoMoMcr.