Tag: html5

Back in summer last year (when there was a whole lot less rain), I looked at comparing the mobile web to mobile apps. There is quite a discussion raging on which it will be. The Church of Jobs raving on about their uncountable number of app downloads on the one hand, and the brave warriors of ubiquity on a technical level on the other.

Asking the right Questions

I would posit that there are three distinct issues to be discussed:

1.    What is the web?

2.    What is the mobile web and is it distinct to the web?

3.    What about the content and its context (irrespective of platform)?

Every attempt to an answer should really start from the point of the user (who, I am aware of that, more and more becomes a creator at the same time) because, without them, there is not much of a (commercial) point to it.

Now, distinct to what old lore may have, users do not tend to care for technology much. They care for what technology allows them to do (or not to do). I therefore think the first question to be asked is: can the web do things better than an app (or, indeed, vice versa)? When you then start looking at what is being done (and what users may want to do if and when technology allows them to in a convenient and accessible way), you will come to a couple of easy conclusions.

The web in itself is just one huge content repository,

… which is – currently – being accessed predominantly by browsers. Some questions on this:

• Has this always be that way? No. Pre-web, there were libraries with clever people in them that could help you find what you needed. With enough time, you would eventually get close(r) to the truth.
• Does this always have to be that way? No. Text input via keyboards is not an “intuitive” way of communicating (the old folks here may remember the finger that hovered like a hawk above the keys of an Olympia). May touch control be a game changer? Later more on this…

Prior to Google, people search through catalogues, and they thought that this was an awesome improvement over having to run to libraries and stuff in order to find things. Along come the Google fairies that deliver the same more easily and quickly, and everyone now feels that catalogues are a little quirky and very old-fashioned indeed.

This is to illustrate that the packaging and connection into discovery mechanisms are more important to the usability of the content than its actual delivery. Ease of access matters as, otherwise, there is, well, none.

The mobile web is the web, the web and nothing but the web.

It only so happens it is being accessed from a device with a smaller form factor (that is, until H&M starts shipping those iPad anoraks with monstrously big pockets next autumn). Increasingly, browsers available for mobile devices render web content originally formatted (not created!) for larger devices for the smaller screens. This does not, however, mean that they are the best way to deliver content to a small device.

One big thing speaking in favour of a unified web platform (including on mobile devices) to deploy content is, of course, volume and unit costs: all other things equal, the cost of deploying via a unified web platform is significantly lower than on others (no need to build custom solutions for every man and his dog and unit costs drop to virtually zero very quickly. This is arguably the key argument in favour of the web but I would suggest that it will only work if you can deliver at least as well as other routes of deploying that content offer to.

The usefulness of content is, per se, independent from the device.

In other words, device constraints have, per se, nothing to do with content being accessed, used, consumed, processed. By way of example, who would have thought that people would read a book on the go in the early 90s? Doesn’t seem to be a big thing anymore today, does it? And why not? Because we got used to solutions that make this convenient.

It is a question of packaging and approach that will determine how well (or poorly) access and usage of content on any device works. If you call it an app or a widget or whatever else does not matter. Most people just do not care. They look at how easy it is to retrieve the latest weather forecast. If an app does that more quickly and comfortably, they’ll use that. If a widget does the same thing, they’ll choose what they like more. And if you can deliver the same thing as easily, as comfortably, as quickly and as discoverable on the web, they might just do that.

Not everything is delivered best on the web

Now, the web is big, it is very big indeed but it is unlikely – despite of what Apple tells us – that there will be an app for every web page. Then again, does there need to be? No. Why not? Because not every web page will be accessed from mobile devices or, rather, will not need to be accessed from mobile devices in numbers large enough to be of commercial relevance.

Hah, I hear you say, he is taking a short cut here: the above implies that, if there is a need to access content from a web page, an app is the better solution. And, yes, you are right. But I will come to this later.

Sometimes, the web does not even work well through a browser. Google Earth is one of these: it is a desktop application because of functionality constraints over the web. It is connected, mind you.

Not everything is best delivered through an app

The equation works around the other way, too. There are things I will normally access through a browser, simply because it would be too onerous to have a single app for all web pages I access. Moreover, there are indeed web pages (this blog included) that use nifty code (don’t ask me; it’s run through WP plug-ins) to render content in a more useful way for smaller devices. Would you care much for a “Volker on Mobile app”? Probably not. Because I only update this blog a couple of times a week, and it probably does not generate enough value-add to merit the (presumably) superior functionality you could deliver with an app.

Some things don’t work on Mobile, or do they?

Did you ever use Google Earth via its iPhone app? If not, let me tell you that is a pretty poor experience compared to the wow-feeling all of us will have felt the first time we played around with it on their desktop app. Why? Because it just doesn’t translate properly. Imagine watching Independence Day on the iPod Touch: you’d get cute little spaceships but not really the awe-inspiring size Emmerich had in mind when shooting it.

Both of these lack of one thing mobile can never deliver, namely the big screen. They are, in their current packaging, unsuitable. This may not however apply to subsets of the content and/or information embedded in them. Google Earth may provide useful data that, if re-packaged, delivers a powerful and good user experience on a mobile device, too.

Functionality and Usability are King and Queen

Almost all considerations result from and in questions of functionality and usability. On devices with larger form factors and constant high-bandwidth connections, a lot of rich content can be appropriately delivered via a web browser. The same cannot (yet) be said of mobile devices. Even with 3G, performance of rich media can often be shoddy. Poor user experience = frustration = low or no usage.

With 4G on its way, this may change considerably. With down-speeds North of 10 Mbps to your mobile device, there is a lot of rich content that you can get to your device in no time (or, rather, real time). That would be functionality solved then.

In the short and medium term, I see, however, two other constraints, and these are a) usability from a device perspective and b) usability from a user perspective.

Currently, a device running constantly on a high-speed data connection sucks battery life. With an iPhone already running on something like 30 minutes when in full use (OK, I exaggerate, and, yes, I do know that Nokias do better – but then, they are not as usable [anymore]), this is a non-starter. People will not do it. Once this is solved (and this is a question of when, not of if), this goes away, and that will be a huge constraint removed.

The other obstacle is usability from a user perspective. What does an app actually do? It pre-packages content. And because it (or some of it) is already in there, you don’t have to download it again. It also allows you to build in specific input mechanisms that optimise use for the mobile device (and how this impacts uptake, the iPhone has shown!).

Touch as a game changer?

Touch control is very much on the fore. And it makes perfect sense: that stylus just seems to dangle on the end of one (OK, normally two) of your limbs, it’s always on, it’s always with you (quite literally at arm’s reach) and you learn how to control it from pretty early on in life. Heck, it’s even been used to get us onto this earth in the first place (or so some people believe).

Touch control then also does away with a few constraints in particular on mobile screens (where mouse control, touchpads, etc are not normally readily available nor as useful as they are on a desktop). So once HTML5 is widely deployed (which – I am told – makes the UI life within web pages a whole lot easier), the usability thing might just go the way of the mobile web.

Touch control (and other nifty things; check here for another Apple patent on finger-based input using the camera) then propels the usability forward (or back? the first maps were arguably drawn with fingers in the sand…), and this will be quite helpful – in particular also on the smaller device.

Until then, build apps that incorporate controls that make the user’s life easy (or at least easier). If you call them apps, widgets or whatever else you can come up with, doesn’t really matter…