Remember the amazing world of Fax Marketing? Mobile phones that only dialed numbers? The first website you worked with? How did we manage before all this tech came along? Obviously not very well, because soon afterwards the App arrived. Google and Apple opened their app stores in 2008 and today we spend most of our time with our smartphones communicating via apps both native and web based.
A recent article (https://blog.intercom.com/browsers-not-apps-are-the-future-of-mobile/) about the rise of mobile friendly websites (or web app) taking over from native web applications reminded us of a similar article in Dec 2015 (http://www.computerworld.com/article/3016736/mobile-wireless/the-mobile-web-vs-mobile-app-death-match.html) on mobile web versus mobile apps.
Before everyone was clambering to have an app built for their service, there was The Microsite. Today this is nothing out of the ordinary, but in the middle 90s it was an exciting move away from the bulky core website to a compact, popup site promoting a new program or service AND it was always scalable – because you never knew when a user would adjust the size of their popup window. Yes, you could force the size of the window, but how much more daring it would be to allow the content to scale. And the responsive, mobile application was born. We just didn’t know it yet.
The rise of the mobile and responsive web has been a game changer for apps. Websites used to come in pairs – one intended for desktops and one intended for mobile phones. Now, there is one website, that responds to the device being used, and delivering the content assumed to be required. If we think about a school or research lab today, when a visitor calls up the website on a mobile device they usually require less content, delivered quickly. Perhaps they are on the train or walking towards campus. On a desktop at home or in the office the user normally has more time and internet speed, and would like to read in depth about the school. The user story is different, and so the content should be different. Already we have begun to see the need for a „service“ to be provided in each scenario – and we can see the beginnings of what once would once have been a mobile app offering specific information like the telephone number, google map location, and the events being offered – perhaps even the menu in the food quad.
This same user, once on location and attending a workshop, could very well then launch a native application to make calculations, determine results of research being fed in by other users in other universities or in labs from principal companies. They could use a native app to have visitors in other countries deliver a talk during the workshop, or could view a film of DNA sequencing. Different needs, different user stories, different tools. Which one is best for you? That depends. Like anything else apps are tools, to serve a purpose, for a demographic – so you build what you need.
The differences, pros and cons, of a web app (basically a small website – easy to update, you can’t sell it, and you need internet connection, usually cheaper to produce) and a native app (basically a service installed on your smartphone – little more difficult to update on the fly, but you can sell it which is good as they are usually more expensive to program, and once installed might also work without internet connection) can be found here: http://sixrevisions.com/mobile/native-app-vs-mobile-web-app-comparison