I’m going to try and describe what a smart client means to me, please let me know what you think. 

The focus of this conversation is on LOB apps, but the discussion applies to other scenarios.

Without spending too much time on the obvious, I think a quick step back in time will help set the table for a definition of what a smart client is.

A PC on Every Desktop:

Before the advent of the browser, we were in client-server mode.  Microsoft’s vision of a PC on every desktop had pretty much materialized – and that revolutionized the workplace.  LOB apps were being cranked out quickly using a variety of RAD tools such as Visual Basic and PowerBuilder and a host of others.  But IT soon found they had thousands of PC’s running tens of thousands of line-of-business applications and of course DLL-hell was in full swing.  Installing one app often resulted in others breaking.  Business logic often ended up mixed in with the client presentation code (remoting business logic to a server based process wasn’t an easy task – unless you put it in the database.) So changing a business rule meant updating thousands of client installations – and that usually wasn’t easy. Admin rights were often required and of course DLL-hell ensured other apps on the machine would break.  All of these apps were stuck on the LAN, inside the firewall – they talked to databases on corporate servers using proprietary protocols.

I’m obviously generalizing a bit, but yikes, things were a mess.  That’s what we went running from,  those nasty thick client, desktop LOB applications when Netscape gave us the browser.

Browser based apps solved all of these problems.  They provided clear separation of presentation logic from business logic, were hosted on the server, were easy to install and manage, and accessible outside the firewall.

By the late 90’s, all new LOB applications it seemed were being built to run in the browser, and all ISV’s were scrambling to re-engineer their ‘legacy’ desktop applications to run in the browser.

But wait, they called it a ‘browser’ for a reason.  When I’m wandering through Best Buy, looking at 50” flat screen TVs, I always get a clerk asking if they can help, and I say: “No thanks, I’m just browsing”.  I’m not interested in transacting business with you, I’m just browsing.

HTML allowed great new presentation capabilities as compared to Win32, but I don’t think anyone would argue that HTML over HTTP was designed to support the rich interactivity needs of transaction processing oriented LOB client applications.

The benefits were too great though: TCO, reach beyond the LAN, 3-tier application architecture… and if that wasn’t enough there was that Dot Com fever – money was only being spent on browser based apps.  Users would just have to get used to clicking an “edit” button on a row of data in a grid to tell the server to redisplay the entire page with the requested row in “edit” mode - and then clicking again to save the change to the database, causing another complete page refresh.

Fast Forward to Today

First we saw the power of a PC on every desktop then we saw the power of the internet, now it is time to combine the 2 and deliver the next generation of user experiences.  Three technologies have emerged that have completely changed the desktop vs. web equation: web services, server based client deployment frameworks and the new Windows graphics and presentation subsystem – Windows Presentation Foundation (WPF).

With web services a desktop installed rich client application can easily centralize business logic on the server where it can be re-used by all – and with careful use of security protocols that desktop app is no longer confined to the corporate LAN because web services of course run over HTTP on port 80.

Client deployment frameworks such as Microsoft’s .NET 2.0 ClickOnce  platform combined with .NET’s side-by-side XCOPY deployed assemblies provide a server based deployment and update model with no more DLL-hell.  There are still thousands of installed clients, but they all know to update themselves when a new version is posted to the server – and there’s no chance that an update will break other apps on the machine.

And then there’s WPF.  The best of Html and Win32 and a whole bunch more, all rolled up into a new markup syntax and single .NET API for delivering UI, documents and media.

So let all of those negative connotations of installed, thick-client, desktop applications go. 

In its purest sense, a smart client:

  1. Leverages local resources to provide the best user experience possible for a given client platform.
  2. Communicates with distributed components via web services. 
  3. Downloads and runs from a centralized location, potentially installing to the local machine, without requiring administrator privileges and seamlessly updates itself when a new version becomes available.

There are a thousand shades of gray when it comes to identifying an application as a smart client or not.  We still have very powerful desktop applications such as Adobe Photoshop and Microsoft Excel.  These applications typically require an admin to install, they update the registry, they work with local data, they require a new license and a high-impact install to upgrade to a new version, etc.  Smart clients are a new class of application that sit between desktop applications and browser based web applications. 

I’m certainly not here to campaign for the replacement of all applications with smart clients.  Desktop applications and browser based web applications definitely have their place, we’ll talk more about that in future posts.

Another dimension to the discussion is the client platform.  Smart clients take advantage of the local client platform; they don’t sacrifice functionality by providing a lowest common denominator application that can run on multiple platforms.  Smart clients can be built for hand held devices such as those powered by Windows Mobile 5, for Windows PC’s, for Linux PC’s, for Macs, etc.  In this blog – in the coming weeks, I’m going to focus on Windows smart clients written to run on Windows XP or above, specifically the .NET WinFX platform.

So before we go on and talk more about why it makes sense to consider Windows smart clients.  Take a second to ask yourself why your LOB application is in the browser.  There are plenty of good reasons – again, I’m not suggesting all LOB apps should have smart client interfaces.  But think about your scenario, why are you in the browser?

Send me some mail, let me know.

In my next post I want to talk about 'reach' and round out my categorization of client applications into 4 buckets: desktop, smart client, standards reach, and rich reach.