The Web Design Book Blog

Web Applications and Mobile Apps

I don’t know whether Web Design students are asked to write essays, but if they are I shouldn’t be surprised to see titles cropping up this year along the lines of “Does the spectacular rise of mobile phone ‘apps’ indicate the coming end of the Web?”

Cameron Moll wrote a short piece on this subject recently. My interest in the matter is similar to his. If there is to be a second edition of Web Design: A Complete Introduction, I had been expecting to add a chapter on the Mobile Web, since it seemed that the Web would acquire even greater importance following the growth in the use of mobile devices. Right now, this doesn’t seem to be what’s happening.

Considering the options for a possible mobile application may clarify what’s going on.

For a while I’ve been idly thinking about creating a flashcard type of application, based on the data that drives the interactive glossary on this site and the other support sites for our books. We are not fans of rote learning, but we are aware that many of the readers of our books are not native English speakers, and that those readers may appreciate this sort of assistance with learning the specialized vocabulary.

The application could be simple, just displaying a glossary term, giving the student a chance to define it, then disclosing the stored definition to see whether they had got it right. Their progress would be recorded, so they could see which terms they needed to revise. Possibly, a tagging and classification scheme could be added, so attention could be confined to certain areas. It would probably also be a good idea to have an annotation facility, so for example, a student could provide alternative definitions in their own language or translations for each term.

Consider two options for implementing a system like this.

Such an application could easily be implemented on a server, using Rails or some equivalent framework. The data is already available in a relational database. We know how to implement users’ accounts so letting each student maintain their own records and notes would be simple. A bit of CSS and JavaScript could provide a nice interface. If this were done, the site could be accessed from anywhere, without being tied to a single computer, and with a bit of care it could be made usable on any device, whether a conventional computer running OS X, Windows or Linux, an iPhone OS device, or some other mobile device using Android or Windows Phone.

In contrast, making an iPhone (or iPod Touch) application would entail writing an Objective-C program, calling Cocoa Touch APIs for manipulating the interface and data. I have to confess that, despite more years’ programming experience than I care to count, I find the prospect of doing that thoroughly intimidating. I know that experienced iPhone developers tell us that Objective-C is wonderful and that anybody who prefers something a little higher-level, a bit more up-to-date and less like a clumsy graft of Smalltalk onto C – Ruby, for instance – has no right to call himself a real programmer, but I have to disagree. But even if I’m wrong, and Apple’s development tools are so great that creating an iPhone app is really a pleasant exercise in programming, at the end of it, I’d have an application that would only run on an iPhone or iPod Touch. It’s generally agreed that a non-trivial amount of redesign would be needed even for the iPad. For Android, I’d have to start again, this time using Java.

So why are developers frantically writing Objective-C for a single platform when they could be using more agreeable languages and frameworks to create web apps that would be accessible on anything?

The answer most often given is that apps provide a better user experience. (This is the prime concern of Cameron Moll’s piece I referred to earlier.) With a lot of ingenuity, you can provide users with a rich interface on a website by way of CSS and JavaScript, as SproutCore demonstrates, for instance. However, you can’t provide them with the native user experience they are used to. On a desktop platform, for example, you can’t take over the menu bar – it’s already taken by the browser. So this means that you can’t easily implement the fundamental interface mechanism of selecting something then choosing an operation to perform on it from a menu on the menu bar. On mobile devices, whose limited screen space has led to the development of new interface conventions, the situation is worse. You may be able to implement something that resembles the conventional interface using clever scripting (SproutCore Touch claims to do this, although the demo was displaying everything back to front in an entertaining fashion last time I looked) but then you will have sacrificed your platform-independence because what seems natural on an iPhone won’t seem natural on a MacBook.

There has been so much emphasis on the user experience of mobile devices, especially Apple’s, that this single factor may be seen as compelling. There are some other advantages to coding native apps instead of using the Web, though.

First, there is the lack of responsibility for the user’s data. With a Web app of the sort outlined earlier, the database on your server is the sole repository for everybody’s records and notes. The sad story of Magnolia should never be forgotten in this context. A single mistake leading to the loss of some users’ data will sink an application forever. At the very least then, you will have to include a secure backup strategy when you launch a Web application. Indeed, security in general will become a major concern: you don’t want the site to be hacked either. If you write an app, each user’s data will stay on their own device and its security will be their responsibility.

Second, rather obviously, they will be able to use the application when they are not connected to the Internet. There are new Web standards being developed that allow Web applications to be used in offline mode, but these are not universally implemented, so in offering a Web application you are demanding that your users be online. This may not always be possible or, depending on the tariff policies in their country, it may entail costs that they do not find acceptable.

Third, and perhaps most enticingly for the developer, when you write native apps you don’t need to worry about browser incompatibilities. You are writing for one platform with precisely known and documented capabilities. Either it works or it doesn’t. For Web applications, the more you strive for a rich interface by using CSS3 features and scripting APIs that go beyond the DOM standards, the more you will run into the limitation of common browsers. (At least now it is acceptable not to support Internet Explorer 6, but IE7 can still cause plenty of headaches.) Unless you are prepared to invest a lot of effort in coping with incompatibilities you will stick to the established standards, which means that your interface will be fairly basic. This shouldn’t matter as long as it works, but users have higher expectations, precisely because of native apps.

And it should go without saying that the native app will run faster.

If these reasons don’t add up to a case for apps, perhaps consideration of money will be more convincing. If you write an iPhone app, you can submit it to the App Store and if it is approved it will go on sale there, at the price you specify. Apple will only take 30%. If your app is good and you can get people to notice it, they will pay. You probably won’t get rich, but you may feel that you are getting repaid for your development work.

But what of a Web application? This too requires work, which you have a reasonable right to expect to get paid for. It also has associated hosting costs – if you give a Web application away for nothing, you aren’t just foregoing profit, you will lose money. The glib answer to the question of how to recoup it is by advertising. I would never consider this option, as I abhor advertising, but even if this were not so, you can only make money off adverts if you are able to get paid for every page view, and this is only possible if you have a popular site. If you expect to make money from Google adwords’ pay-per-click model, you will probably be disappointed.

The only other option is to charge a subscription for access to your Web application. This is a perfectly reasonable thing to do, but whereas people are willing to pay to download an app, they seem to be much more reluctant to pay even the cost of a cup of coffee for a year’s access to a website. The tradition of free access to the Web is too well established at present, as newspapers are learning. Perhaps also, the missing feeling of possession that comes from having all your data elsewhere contributes here. If you download an app, you feel you have got something and it’s yours. If you subscribe to a site, you feel you are paying for something transitory and won’t have anything to show for it at the end.

None of this answers the hypothetical exam question posed at the beginning, but it should help show you why there’s a question to be answered. If you are ever confronted with the question, you might also ask yourself why the question isn’t usually asked in the context of desktop computing, only mobile devices.

— Nigel Chapman · 29 April 2010

Previous  Next   Recent