Mobile app or mobile web?Posted on February 21st, 2010 11 comments
Technology, users and business models
This is the second post in a series of three
Mobile access to information on the internet is the latest step in the development of information systems technology, as described in the previous post in this series. The two main features that distinguish mobile devices from other devices are:
- Access to the web literally any time, anywhere
- Location awareness using GPS or the mobile network
Let’s focus on web access first. There are two main ways in which information providers can provide access to their data: by a mobile web browser or by apps.
The easiest way to provide mobile access is: do nothing. Users of mobile internet devices can simply visit all existing websites with their mobile browser. However, in doing so they will experience a number of problems: performance is slow, pages are too large, navigation is difficult, certain parts of websites don’t work. These problems are caused by the very physical characteristics of mobile technology that make mobile internet access possible: the small size of devices and displays, the wireless network, the limited features of dedicated mobile operating systems and browsers.
Fortunately, technological development is an interactive, reciprocal, cyclic process. Technology continuously needs to find solutions to problems that were caused by new uses of existing technology.
Many organisations have solved this problem by creating separate “dumbed down” mobile versions of their websites, containing mainly text only pages and textual links to their most important services and information. In the case of libraries for instance “locations and addresses“, “opening hours“, etc. See this list of examples (with thanks to Aaron Tay). Another example is LibraryThing Mobile, which also has a catalog search option. In these cases you have to manually point your browser to the dedicated mobile URL, unless the webserver is configured to automatically recognise mobile browsers and redirect them to the mobile site.
Of course this not the optimal solution for two reasons:
- On the front end: as an information provider you are complete ignoring all graphical, dynamic, interactive and web 2.0 functionality on the end user side. This means actually going back to the early days of the world wide web of static text pages.
- On the back end: duplicating system and content administration. In most cases it will come down to manually creating and editing HTML pages, because most website content management systems may not offer manual or automatic editing of pages for mobile access. Some systems offer automatic recognition of mobile browsers and display content in the appropriate format, like the WordPress plugin “WordPress Mobile Edition” that automatically shows a list of posts if mobile browsers are detected. This is what happens on this blog.
Because of this situation we are witnessing a re-enactment of the client-server alternative to static HTML that I described previously: mobile apps! “Apps” is short for “applications“, apparently everything needs to be short in the mobile online web 2.0 age. Apps are installed on mobile devices, they run locally making use of the hardware, operating system and user friendly interface of the device, and they only connect to the internet for retrieving data from a database system in the cloud (on a remote server).
A disadvantage of this solution obviously is that you have to multiply development and maintenance in order to support all mobile platforms that your customers are using, or just support the most used platform (iPhone) and ignore the rest of your end users. Alternatively you can support one mobile platform with an app, and the rest with a mobile web site. Organisations have the choice of developing apps themselves from scratch, or using one of the commercial parties that offer library apps, such as Boopsie, Blackboard or the recently announced LibraryThing Anywhere, that is meant to offer both mobile web and apps for iPhone, Blackberry and Android.
- TU Delft mobile app for iPhone (powered by Blackboard). University wide, including library. Haven’t been able to test this because I have an Android phone. An Android version will be developed. For other devices they offer a mobile website.
- Duke University mobile app for iPhone. University wide, including library. For other devices they offer a mobile website.
- Santa Clara County Library mobile apps for iPhone and Android (powered by Boopsie).
- WorldCat Mobile (powered by Boopsie).
An alternative solution to the client-server and “dumbed down” models would be to use the new HTML5 and CSS3 options to create websites that can easily be handled by all PC and mobile webbrowsers alike. HTML 5 has geolocation options, and browsers are made location aware this way too. The iWebKit Framework is a free and easy package to create web apps compatible for all mobile platforms. See this demo on PC, iPhone, Android, etc.
Some say that HTML5/CSS3 will make apps disappear, but I suspect performance may still be a problem, due to slow connections. But it’s not only a technology issue. It’s also a matter of business models, as Owen Stephens and Till Kinstler pointed out.
Apps can be distributed for free by organisations that want to draw traffic to their own data, ignoring the open web. This method fits their clasic business model, as Till remarked, mentioning the newspaper business as an example.
But there is also another side to this: apps can be created by anybody, making use of APIs to online systems and databases, and be shared with others for free or for a small fee, as is the case with the iPhone Apps Store, the Android Market, the Nokia Ovi Store, or the newly announced Wholesale Applications Community (WAC). This model will never be possible with web based apps (like HTML5), because nobody has access to a system’s web server other than the system administrators. It is also much too complicated for developers and consumers of apps to host web apps on a server that mobile device users can connect too.
And there is more: independent developers are more likely to look beyond the boundaries of the classic model of giving access to your own data only. Third party apps have the opportunity to connect data from a number of data sources in the cloud in order to satisfy mobile user needs better. To take the newspaper business example, I mentioned this in my post “Mobile reading“: general news apps vs dedicated newspaper apps. The rise of the open linked data movement will only boost the development and use of the mobile client server model.
In my view there will be a hybrid situation: HTML5/CSS3 based web apps and local mobile apps will coexist, depending on developer, audience, and objectives.
What services library mobile apps should offer, including location awareness and linking data, is the topic of another post.Library2.0 apps, business models, catalog, client-server, library systems, mobile, technology, web apps
Good work, nice summary of current trends. Will be useful in our meeting 🙂
There is one argument between apps (installed on the device) and webapps that you didn’t mention though: for the user, an app when installed comes with a simple way of running it: an icon on the springboard or its equivalent in android, palm, etc.
Even though it’s pretty easy to add an icon to a webapp, about as easy as it is to bookmark/favourite a site in a browser… it just lacks the convenience. And frankly, how many people are still creating local bookmarks? These new devices, closed as they are, are all about convenience.
So a lot of apps in the iphone store are just wrappers that load an html5/css3 page in webkit and present it as an app. This way, the main developing costs are split between the iphone, android, palm and bb (soon) platforms, and only the shell is different between them.
Relevant discussion on Ask Mefi: http://ask.metafilter.com/137679/The-Elusive-Quick-and-Dirty-iPhone-App
BTW – I have a number of apps installed on my iphone that really are bookmarklets… Pie Guy for instance: http://mrgan.com/pieguy/ – which also runs offline, since it uses the html5 local storage!
It’s like seeing known history passing by! A great overview.
Do you know about this one already?
Perhaps the future of fully integrated information networks? A forerunner of possible future mobile hardware and software capabilities.
Will you be discussing bandwidth issues as well, perhaps together with signal formats and security?
Hey Lukas, thanks for your reply. I liked the overview also because it sums up known information technology and my understanding of it. I’m not terribly much of a techno man myself either and your overviews make it so much easier to find a starting point! 🙂
By the way, a friend of mine really is such a signals technomancer and works with the NATO doing network technology. I think I could get him to do a short seminar on those possible future network technology related to information sharing. Would there be some interest in that you think? For librarians it might offer some long term perspective on what to expect/plan/aim for?!
I agree. A port of a mobile website into a device specific app would be the best way to go. Low app maintenance, device convenience, and lower overall costs. It should be the way to go for predominitely online apps.
6 Trackbacks / Pingbacks
Social comments and analytics for this post…
This post was mentioned on Twitter by infopeep: Koster, Lukas: Mobile app or mobile web? http://bit.ly/cdZ1bl…
[…] Mobile app or mobile web? February 23, 2010 mobilewebservices Leave a comment Go to comments Read a very good article on CommonPlace.net […]
[…] Mainframe to mobile interessante serie op CommonPlace.Net Deel 2: Mobile app or mobile web? […]
[…] Koster schreef drie uitgebreide blogposts over mobiele applicaties voor bibliotheken: deel 1, deel 2, deel […]
[…] Commonplace.net, Mobile app or mobile web […]
[…] 2. Mobile app or mobile web? (Common Place, 21/02/2010) […]
Leave a reply