Thick or Poor?

A big debate is brewing in the mobile software space over the best type of client – thin or rich?
Like many high tech terms, the words used are vetted by spinmeisters who don’t like the term “thick” or the opposite of “rich” (thus my title).
I suppose it’s no surprise that Microsoft’s .NET Compact Framework features a lot of support for rich clients.
On the other hand, the Alchemy project Adam Bosworth started at BEA (before he left for Google last week) is based on a thin client architecture.
Who’s right typically depends on what you’re using the application for, of course. In some cases, a thin client will be a better natural fit than a thick client and vice versa.
However, for mobile applications, and especially for the new type of user we’re building them for, rich clients make a lot more sense than thin clients.

Advertisements

5 responses to “Thick or Poor?

  1. Eric:
    I would classify Alchemy in the Thick client category since last time I checked I found it was not pure DHTML (everything that is not DHTML is thick to me, even if it runs in a browser).
    Nowadays, central management of deployment of thick client has been solved by many companies and there is problably more issue in deploying a browser plugin or java applet than there is deploying a thick client.
    Jean-Jacques

  2. Jean-Jacques,
    My understanding of Alchemy, from listening to Adam Bosworth present it, is that it includes a three pieces: a cache, a messaging engine, and a browser extended with XHTML capability.
    Is what you are saying about the acceptance of the BEA extensions? Or the footprint of the technology (browsers are already on mobile devices)?
    Eric

  3. The point I make in my SOAPbox blog is that proper use of SOA should allow us to structure a solution so that the fatness/thinness is itself isolated from the rest of the solution and can be varied tactically.

  4. Half Brain Half Biscuit

    Proper use of SOA should allow us to structure a solution so that the fatness/thinness is itself isolated from the rest of the solution and can be varied tactically.

  5. Richard –
    Thanks for the comment. I agree that on the server side we should be thinking about SOA, and about creating an SOA at the right level of abstraction as to handle thick or thin clients.
    However, I am more concerned about what’s right for the device. Is the device user better served by a thin client or a thick client? I would say the latter.
    A thin client (i.e. a Web browser) just doesn’t provide the level of interactivity users expect from their mobile devices. And it doesn’t suit the mobile lifestyle, in which someone might have only sporadic interaction with the device since they are not sitting at a desk while using it.
    People buy mobile devices such as PDAs and smart phones for a reason – to use them for the function they were designed for. OK, so a laptop is very similar to a desktop, and you can probably get away with using the same GUI for both of those. But a really mobile device often has a very different interactivity factor – different kind of keyboard, no keyboard at all because it uses a stylus, and has a very different kind of screen. It might not support horizontal scrolling, or complex visuals.
    Furthermore, devices come packaged with a certain number of applications. Those applications are often painstakingly designed and engineered to take full advantage of the device’s capabilities. If you deploy another application – say an enterprise application – on the same device the user is going to expect the same behaviour as exhibited by the native applications.
    Thin clients just won’t do the job.