Thick vs Thin Clients In Mobile Today

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:

1. Security. Operator data centres can be hacked, and you should assume that the contents of any message could be intercepted. Phone theft is an even greater risk, with the inbox/outbox potentially a treasure trove for thieves if some of the more foolhardy plans for SMS services ever get to see the light of day.
2. Complex data entry. An SMS is great for a one letter answer to a quiz. It’s good for asking a free form question from a service like AQA. Entering carefully structured data is simply too much for most users though, so any service which requires the user to remember arcane data markup just isn’t going to cut it, especially if there is a large amount of data to enter.
3. Trust. That’s taken a hammering recently and it may take a while for confidence to come back.

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:

• Displaying regularly changing information eg. news.
• Casual one-off browsing, where the user is unlikely to ever need to come back and benefit from having any sort of state remembered, and not being able to access any content is not a serious problem (due to lack of signal, etc).
• Very changeable data with simple display requirements that change unpredictably over time, with minimal data entry requirements.
• Situations where reliable network connections are guaranteed – either fast connections, or very small nuggets of content that can be found very quickly.

Thick clients are good for:

• Repeated user experiences - local secure caching can reduce data entry, always a significant pain point on mobile.
• Intelligent data delivery can reduce costly data overheads whilst providing faster responses for the user for known types of data set.
• High interactivity and improved user experiences with many potential data visualisation models and on-client validation (minimising round trip requirements to the server, which cost money and time).
• Improved branding around content, which only ever has to be downloaded once rather than at the start of ever session – handsets rarely dedicate persistent storage to browser caches so ever visit to a branded site reloads many Kbs of images, CSS etc.
• Real security, guaranteed – there are known issues with Wap security which can even affect Wap2 browsers running through legacy APNs.
• Offline access – content can be stored locally to browse even when there is no signal (eg. Tube maps), data entry can be performed when required and then submitted to a server asynchronously etc.
• Data roaming can be incredibly expensive so for content like travel guides designed to be read abroad, or interactive services for which Java can choose to use SMS instead of GPRS, there are big cost savings to be had.
• Precise optimal rendering of certain types of content, for example barcodes (used for ticketing etc) which would be useless if the handset decided to rescale them badly as can happen when displaying MMS messages or images in browsers.

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:

• Cost sensitivity, for example with data volumes and the overhead of resending branding and UI with every page.
• The importance of a good UI and the complexity of the content.
• Whether the project must be deployed now or can wait some number of years for the technology to catch up (3G penetration hit about 10% in most of the developed world at the end of 2006, so this can be a slow wait!).

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.