Mobile Cross-platform Choices. Unraveled
And don’t get me wrong. I don’t like the idea of silver bullet work flow chart that makes the decision for you(though here‘s a good one, still I disagree with some points). This decision tree is intended to help you better understand the correlations between your requirements and corresponding technology. You can think of it as unraveling the cables behind that old audio/TV/any system. It’s still complicated, but it’s much clearer now.
So, how does it work? Basic idea is to define your requirements from the product vision, and then, by prioritizing them, go left or right in a tree. Then you repeat it until you’ve reached the leafs, i.e. the bottom of a tree. Pretty easy, isn’t it?
Now let’s delve into details.
Choosing between App and Web Site
I intentionally rooted my decision tree with a Vision, as this is a thing, without which you cannot start choosing the technology. You have to know what you’re aiming for before you start shooting. Then, you need to turn the vision into some more specific requirements. I’ll help determining the criteria, but there is still work to be done with setting the requirements and understanding them.
The first choice to be made is whether you want a Mobile App or Web App(Site). You probably heard of topics like “HTML5 vs Native.” I think it’s a bit confusing and too generic comparison, as with HTML5 you can build both web and mobile apps. My point is that you shouldn’t choose between Native and Web. Native is a way of implementing Mobile App. Web is a whole family of apps, with its attributes and specialties. Instead, you should choose between Web and App approaches as they deliver more or less equal alternatives, cover different usage scenarios and reflect different marketing channels. And these are basic criteria you want to base upon when choosing mobile strategy.
So, the criteria. I’ll start with the easy ones: if you know you’re gonna need access to device features(gyroscope, accelerometer, bluetooth, contacts, calendar, push notifications), you care about security or you need non-trivial computation tasks – in these cases you can forget about Web App. You simply don’t have required APIs for device features, you don’t have infrastructure for security and web has been proven not to be able to deal with heavy-computational tasks.
Please note, I didn’t include offline and camera access here on purpose. This is one of most common confusions people make in this field. Web has already grown to an extent where whole websites can go offline(and I’ll give you an example later on). And about camera – there is a big progress and workarounds there so before eliminating web as a platform for your app it’s better to make deeper investigation. I must say, in my humble opinion, HTML5 s moving(slowly though) towards accessing all these device features, so in future(far future) that will not be a show stopper.
Then, if you don’t have a need for any of listed above, you need to define and prioritise the following criteria.
Questions: What do you expect from user? How do you want to interact with him? Do you want him just to read information or to input something? How often do you want him to use your app?
Hints: Mobile apps are more adapted for interacting with users and entering information, although skilled web developer can nail it in the web. In contrast, when a user just googles for some information, he doesn’t want to download the app, he just needs the piece of advice as quickly as possible. Yes, by the way, one fact you should always keep in mind – mobile users are much less patient than desktop users. As Eric Reiss, usability expert, states, the three-clicks rule is not applicable to the mobile environment. Users will leave your system the moment they feel it doesn’t bring much use to them, i.e. possibly after the first click.
Q: What is it that you’re showing to your user? Is it a daily newspaper article, or a 3D model of his new house? Or maybe a medical record input form?
H: Content is tightly integrated with user experience, he actually defines it. I highlighted it as a separate criterion to help you better understand your UX strategy. Here’s a good popular tip from Prasant Varghese:
If your goal is just to display and show content, I suggest a responsive or mobilized website. If your goal is to show productivity tools, build an app
Q: How do you want to deploy your app? How do you want to deliver updates? How do you want users to reach your app? What is your maximal time-to-market?
H: Apple has started a very good culture with its AppStore. Apps there are easy to find, to choose between competitors thanks to rating & comments and have good compatibility model. Those are huge pros for mobile apps. The con would be bigger time-to-market because of Apple’s and Microsoft’s review process(if you’re aiming Android, BB or enterprise that’s not a problem). Also, there may be scenario where you want to employ your own distribution model, or you already have good SEO rating for your website and just want it to go mobile. Choice is yours.
campaign? Or are you going to monetize your application? Do you want to use built-in methods of payment?
H: Some build apps to sell them. Some to market their company. Some to improve their employees productivity. Anyway, if you want to deal with money, it’s better to go the App way, as there are built-in user-friendly ways to handle money transfer from inside the app, or when buying the app itself. Again, if you have your own well-made monetization model you can go your way
Q: Who is your target audience? What devices are they using? Phones? Tablets? Phablets? Which OS? How much devices are your going to support? Is functionality the same for all devices?
H: Both App and Web can give you great portability, just for different cost. Going Web usually means (if made correctly) that everyone can use it. When going the App way, you’ll have to pay more(Native) or less(Hybrid) for every new platform. Learn your audience and what devices they are using. If you have really diverse audience(e.g. you’re a food retailer) and your customers have all range of phones from old Nokias to brand new Nexus’ it makes sense to have a website which will cover them all. On the contrary, if you have more specific customers, like lawyers, who usually use iPhones, you can save some budget by cutting support of other screen sizes or platforms. One more advice – don’t rely on statistics of browsing your (desktop) site from different operating systems too much . It is typical that user who has visited your site and didn’t like it, won’t visit it anymore. Better learn who do you want to use your system
Q: How far can you go to reach the best quality? Where is “good enough” for you? What is the long-term planning?
H: For most people this is final word. Keep in mind cost of development, testing, maintenance, deployment etc. It’s not a secret that App way will be more costly. You should also consider in what tools and technologies you want to investigate, i.e. what types of applications you are going to build in future.
Also, consider choosing both ways – Web and Apps for several platforms. Here’s a quote from Jason King which describes budgeting very well (source)
Desktop, mobile web, and apps are all different marketing channels. You have to decide where to focus your development budget…If you have the budget, do it all.
A very popular scenario is to develop an app for most important audience and make a web site with limited functionality to cover all the rest. When budget is limited and functionality allows, the killer combination is HTML5 code base with tuning for accessing device features for Hybrid tools(PhoneGap, Titanium) and tuning for workarounds without these features for web site. But don’t ask me about maintaining this code base and the number of branches there.
Also, note that I didn’t give such popular criterion as availability of developers for right technology. I’m sorry, that’s just too obvious for me. If you don’t have people to use certain technology – then you can’t afford it. Or, if you really need some technology – you’ll find the people somewhere.
Just to use the right moment, here‘s another good source of topic that we were talking about.
So, we’ve made the most important part – we’ve set a line between an app and a site. Now we’re going to see the difference in technologies for developing each. I like the polish notation, so will go to the apps first.
Choosing technology for the App
Choosing between Hybrid technologies
It may be a surprise for someone, but people actually created a lot of ways just not to deal with Objective C:) No, just kidding. The idea of cross-platform development isn’t new – we’ve had it with Java for Linux, Windows and the rest of the company, we had it with HTML5 for different browsers, there’s similar problems in gaming world(PlayStation, XBox etc). It’s absolutely normal to want your code to work across all the platforms. But the world is not fair, and this comes with the price.
WebView-based, aka PhoneGap
Custom container-based, aka Titanium
Cross-compiled, aka Xamarin
Choosing between Web technologies
Screen Size Range
An all-platforms App for Time Tracking
Back around 2005, when all enterprises were still on BlackBerry, we were in a middle of a huge project, developing product for lawyers’ time-tracking. The system worked well without mobile part, but the time has come and mobilization took it’s part.
A Mobile Web App for Healthcare
A Hybrid App with Native injections for Logistics
But then we got to signing functionality. It was way too slow through WebView layer. But impossible is nothing! We implemented it in Java, the Native way, and injected into the hybrid part of application. And everyone was happy ever after :)
I love this example as it shows how combining different technologial approaches may benefit the final result. For more details you can follow this link.
An ELEKS’ Responsive Web Site
Recently our marketing department together with UX department had a great challenge to showcase our expertise in Web Design and Web Development by redesigning our own web site. The main priority of course was the quality of the result. We knew that we will update the content frequently, that we want to reach as wide audience as possible, that all we want is to present information, not to interact with users. So it was clear that we don’t need an app, and it was clear that we don’t want two separate websites. We wanted responsive. And, in my humble opinion, as a person who didn’t participate in this project, the result is awesome. Oh, yes, it’s not just my opinion, we won quite nice awards for this work. Here’s a nice interactive case study explaining how me made it.