There are three ways to handle data services with the owner of a mobile phone – via SMS, with a wap site (a ‘thin’ client) or with actual code running on the device (a ‘thick’ client). Each has its place.
SMS is an excellent way to transfer small amounts of data, and it can be monetised if that’s part of the plan. Users can submit simple multiple-choice selections or whole messages using their standard phone functionality in a familiar way – all they need to do this is a short number. I don’t need to tell you what this is good for as the marketing and media communities have pushed the medium to its limits, but it is worth pointing out what it is bad for:
SMS apps are a very well ploughed furrow so I’ll concentrate the rest of this post on the other two options – the thick and the thin client.
A typical thin client could be a news or weather wap site, or a wap-based email system; an advanced system might be a wap version of an eCommerce site. All interaction requires an active network connection and takes place through a browser using the limited form fields available in Wap/XHTML-MP (a subset of normal web forms).
A thick client, on the other hand, is a downloadable application which must be installed onto the handset and stored locally, but can then be run at any point – a network connection is only needed if it needs to interact with a server, and the interactivity options are limited to the imagination of the programmer and the physical constraints of the device.
We should also mention briefly at this point the halfway house, Mobile AJAX. This aims to offer the advantages of thin client browser-based content (no installations, instant access to new features, etc) but with the greater interactivity of a thick client. It is a worthy goal hampered by a long list of constraints, principally very limited handset support and an architecture that is suited to cheap high-bandwidth low-latency high-uptime connections, everything a cellular connection is not. There are plenty of in-depth critiques of the platform as it stands today if you want to read further.
So if, in today’s mobile environment, both pure thick and pure thin clients have their strengths then what might those strengths be?
Thin clients are good for:
Thick clients are good for:
We can use these criteria to draw up a number of ideal candidates for each type of application – thin clients are great for news sites, cinema listings and other casual browsing whilst thick clients are better for things like online banking, repeated ticket purchases, eBooks and the like.
There is a very large grey area between these groups of ideal candidates, where exact circumstances could favour one approach or the other. E-mail, for example, is an ideal thick client app until networks become fast, cheap and reliable enough for a web-based approach –not having to install anything could outweigh the data overhead of resending the entire UI in every page, if offline access is not important, etc.
A dedicated analysis would be helpful for most projects, and the outcome of this analysis will depend on factors like:
I think most of the thin client cases are pretty obviously good as thin clients, but we can look at a little example which might help demonstrate some of the advantages of thick clients – here using my Barclays bank statement, simply because I happen to have a Barclays bank account (there is nothing special about Barclays in this context).
When I access my Barclays statement through the ‘normal’ web in Firefox, the HTML page is 98Kb (plus an extra 20Kb or so of graphics and CSS). This is the same page, incidentally, which the user of an iPhone or the WebKit browser on a Nokia Series 60 handset would enjoy downloading. The total page size is 118K * 1024 * 8 = 966,656 bits which at an absolute peak rate of 384Kb/s would take 2.5 seconds to download on the iPhone’s EDGE connection – real world performance would probably be under half that for the download, once we remove the fixed overheads of initiating a connection to the network etc. Nokia users lucky enough to be on a 3G network could get it quicker.
I had started this article hoping to use Barclays new mobile service – “specially redesigned to be viewed on mobile phones” - as my thin client example. Sadly right now Barclays.mobi appears to redirect users to the standard web site, so I’ve had to manually recode the HTML page as efficient XHTML-MP to estimate the size of the same statement if generated as a proper mobile-optimised thin client – it comes out at between 20-30Kb depending on exactly how streamlined you want to make the browsing experience, because the Wap2 XHTML tags are transmitted plaintext and add a lot of padding around content (Wap1 WML is converted to smaller binary which would help).
Barclays also recommend you use Opera Mini, a Java-based browser which recodes and compresses pages on a server into a proprietary Opera format before passing them to the client. This approach crunches the same page down to 7Kb, though on the UI front you see that even with the best mobile refactoring of the page you still have to scroll through 3 screens of nav links etc to actually reach the top line of the statement. It is worth noting that Opera themselves do not recommend using Mini for passing any kind of secure financial information around, something we touched on in a previous post.
If we now look at Masabi’s thick client banking app concept, we see two things – firstly, that same statement can be encoded in around 0.5Kb, and secondly the initial statement lines are completely visible with the display optimised for the user to instantly reorder statements whilst making best use of the available pixels. The initial download for the client would be 50-100Kb, depending on the level of branding the client used and the type of handset – about the same as the HTML for one normal web statement in fact. Here is a quick screenshot comparison:
Why do a few kilobytes matter? Well besides the speed of response – which can be enough to kill an app for some users – there is also a rather large cost factor associated with mobile. Despite all of the recent talk about flat rate data, flat rate really means quite a large fee for quite a small cap under the operator’s “fair usage” policies (surely a target for an enquiry into misleading nomenclature). Orange’s recent attempt offers a 30Mb cap for £8 per month – if we ignore the image/CSS overhead 30Mb is 300 full-web bank statement views, though in reality you’d need to go through a multi-step login and view a few other pages every session, so you’d maybe get at most half that. No-one is going to need to see their statements that often, but the general point here is that un-optimized data usage adds up very quickly if the user accesses a few services, and that can easily lead to bill shock. Orange are competitive but they don’t have the most generous data bundle in the UK right now – but then most customers don’t have a data bundle at all; Orange customers without a bundle pay £1.18 per Mb when in UK (£7.64/Mb roaming abroad), whilst O2 PAYG customers pay £3/Mb (in the smallprint). It will be a long time before proper data bundles are offered by the operators, and longer still before the average consumer sees any point in buying them if they are put off mobile data by early billing shocks.
A payload of half a kilobyte, in comparison, barely registers and can be downloaded very quickly; the Masabi client also has the benefit of real end-to-end security on all handsets regardless of certificates.
A thick client can be implemented badly, and could easily throw away all the potential usability and bandwidth gains we have discussed here. Web content can be manually fine tuned to be much more usable than the Opera Mini example above, and some types of data displayed on the web will translate better into mobile browsers than others. However when implemented with care and attention, for the right types of application a thick client makes a huge difference to the end user experience and cost and that has a huge impact on the uptake of the product.