Accessing the web on the move is becoming something all of us are doing more and more of each and every day. With smartphones and tablets becoming more advanced on an almost daily basis, the question of "should I make my website mobile enabled?" has been replaced with "how do I make my website mobile enabled?" and with technology in it's current state, that question can be boiled down to the following:
"App or Website?"
By this I mean, do you write a native app which you can download from an app store and run on your mobile device or, do you improve your website so that it can be accessed by a mobile device easily?
In my humble opinion, and bare in mind I am primarily a web application developer, that the website option is the way to go. Most things can be achieved by a website and it reaches a far wider audience than an app ever would do.
Why do I say this? Well, I'm going to go through what I consider to be the important factors when weighing up the above question, hopefully after that all will become clear.
Audience Reach
This is the first major issue and one that should hold some serious weight. If you develop an app, your app will only work on a specific platform. So, if you build an app for the iOS then only apple devices will be able to use it. What if your user is using an Andriod, Blackberry, Samsung or some other smartphone? Well tough. You've limited the amount of people your product/service can reach straight away. The workaround for this is to build the app separately for each individual platform. That in it self brings problems. If you're a software house, it's unlikely that you're going to have developers who know how to program for iOs, Android, Windows Phone 7, etc. That means you're going to have to train them up, that takes time and money. If you're not a software house, or you don't want to build it yourself, you can always outsource the work, but that's not cheap. Put simply, unless you're a company with a large amount of resources or, you're somebody with an immense amount of time on your hands, that's not really an option.
Let's compare that to making your website platform independant. Yes, over the years, making a website work on many different browsers has been a complete headache but things are changing. Browsers are learning! Yes, the odd tweak is needed here and there but in the most part, if you program to W3C standards then you shouldn't have many problems now days, especially on the major mobile platforms, which in my eyes, doesn't include Microsoft Internet Explorer. So you've made your website, you've programmed to W3C standards, what next? Well nothing. That's it. All browsers on all phones can access your mobile website. That's considerably cheaper and easier in just about every way you can think of.
Look and Feel
When discussing this topic with fellow developers, people inevitably say that a website won't give the same look and feel as a native app. "You can't get rid of the address bar!" I hear them say. Well, that's not strictly true. You can, but both you, the developer and your user need to know what to do. In iOS (I own an iPhone and have access to an iPad so know this platform reasonably well) you can add meta tags that, when run from the home screen, will get rid of the address bar and will let you style the status bar too. For example, the tag:
<meta name="apple-mobile-web-app-capable" content="yes" />
will ensure that the web application loads in full screen, with no address bar, when loaded from the home screen. Unfortunately though, there is a bit of a flaw in this. As I said, this only occurs when loaded from the home screen. That means your user must first add the website to their home screen. As far as I'm aware, there's no way of providing the user with an easy way of doing this, they must be familar with the iOS user interface. I'm sure this is equally true with Android phones. This does pose a bit of a problem, maybe it's not a problem for your particular product/service but it is something to bear in mind.
A Website Can't Be Viewed Offline!
"A website can't be viewed offline, what if my user is on a plane or in tunnel?". I hear that argument a lot when talking about this and it just doesn't hold up. HTML5 has introduced Offline Web Applications which I've blogged about before. They allow a website to be viewed with no internet connection available. Yes, it assumes you've visited the site previously but you can easily argue the same with an app, after all you need to be online in the first place to download the app. And yes, I agree, offline web applications can be a pain to create, especially if your content is dynamic but they're by no means impossible. I imagine it'd be no more harder than creating an app from scratch. Again though, it depends on your needs. If you definiately require offline access then it can be achieved by both an app and by an offline web application. Chances are though, you don't.
Access To Phone Devices
Unfortunately, building a website isn't the holy grail. After all, if it was there wouldn't be a need for apps. This is one area where apps have the upper hand. They have access to your phones devices, for example, your phone has a microphone. Your app can use that. Your phone has a camera, your app can make use of that. Now in theory, if you're just deciding whether to make your website an app or to make it mobile compatible, then this may not be a problem. Your original website wouldn't have had access to these devices either but maybe by using these controls, you can make a certain process within your website easier. It's something to consider.
I should say on this note that phone developers are beginning to realise this and seem to be building API's that help bridge the gap for websites. In the iOS 4.1 update, Apple sneaked in an undocumented update to it's Safari browser... two new JavaScript events were created, ondevicemotion and ondeviceorientation (see http://mobile.dzone.com/articles/how-use-gyroscope-your-iphone for more details). These provide website developers access to the accelerometer data and the gyroscope data of an iPhone/iPad which they can then use for whatever they want.
The App Store
Just about all mobile devices now have some form of "App Store". A central place that a user can go to search and download your app. Whether the use of an app store is a good or bad thing completely depends on your situation. The app store does give users a central place to be able to search for your specific app. It may also open up another revenue stream for you; you can charge people to download your app! On the flip side of the coin, it's an extra expense, for example, you need to pay Apple to be able to put your app in the app store. On top of this, all apps are accredited by Apple so you need to make sure your app ticks all of their boxes. This may or may not be extra work for you and your development team. Plus, accrediation takes time. You've got to wait for someone at Apple to do their job before your app gets out in to the world. Maybe this extra time delay isn't a problem, maybe it is. Either way, It's certainly something that you don't have to worry about when building a web application.
The other thing to consider in this area is, how do you push out updates? If your application is sold to many different clients, it's quite possible that each client will buy and use a particular version of your product. What happens when you need to release an update? Maybe some clients have contracts so that they can download the latest updates, maybe some don't. There's no way to distinguish. In it's current form, the app store (at least the Apple version) doesn't support this kind of business model, either all users have the ability to download the latest update, or none of them do. This may very well lead to clients receving access to versions of your product that firstly they haven't paid for and secondly, and arguably more importantly, they may not want. As always, there are ways around this, you could for example release a "new" app for each client. You'd then have to come up with a way of managing that. If you then have that across all major mobile devices (I'm thinking Android, iOS, Blackberry, Windows), you've now got to have some form of version control for all of those, for all your clients. That's going to get very messy, very quickly. Maybe you could build your app so that it's backwards compatible and then only allow new content to be accessed by the clients that have that in their contract? There are ways around it but the chances are, it's not how you do things currently and will require a bit of a re-think in your release procedures.
So, what do you do?
In my very humble opinion, if your application is a web application, first and foremost, make sure it works on mobile devices before even thinking about building a native app. The amount of effort and resources that are required to make sure that your app has the same audience reach as a web application just isn't worth the bother. A native app, in my eyes, should be considered an extra bonus and nothing more.
As an example, let's look at the National Rail website as I think it's a particularily good example. Using their website, I can find out the times of trains across the whole of England. If I access http://www.nationalrail.co.uk on my desktop then I get the full blown website, I can look up times, book tickets, look up services updates, the lot. If I access the site on my iPhone or iPad (these are the only devices I have access to at the moment), then a specific mobile device website is loaded. The website I see there is a bit more stripped down but, I can perform all the same functions with minimal fuss.
Once National Rail had that in place, they went one step further and built an app. If you load the app on the iPhone, like the mobile specific website, it too allows you to look up train times. The difference here is that they've taken advantage of device specific features. For example, the iPhone has the ability to track your position via GPS. National Rail have then used that information within their app to give you a listing of the nearest stations to your current location, something not really possible with current web technology (That's not strictly true, you could use the new HTML5 Geolocation API but I have no idea how accurate that actually is... maybe a subject for a different blog post).
Ok, so what if your application isn't a web application at all, maybe it's a desktop application that you're thinking of porting to a mobile device. Well, there is no generic solution for this. It'll depend on your product and the service you provide. As a general rule of thumb, I think it's always better to port your application to the web before creating an app but then again I am a web developer so my opinion may be a little biased.
I hope the above has helped but this is a subject that has quite a few different schools of thought so I'm interested in hearing what you think so feel free to comment!
I hope the above has helped but this is a subject that has quite a few different schools of thought so I'm interested in hearing what you think so feel free to comment!
No comments:
Post a Comment