When we see terms like Web-Client or Thin-Client it means an application that runs in a browser like IE, Firefox or Chrome. The alternative is a Fat-Client usually meaning an application that runs within Windows (XP, Vista, Windows 7) on your desktop or notebook.
Neither the Web-Client nor the Fat-Client are new concepts having been around for many years but both have changed and improved over time as they have employed new technologies. Most Fat-Client applications today for instance are based on the 2008 or 2010 Microsoft .NET platform and require the .NET Framework to be installed on the workstation or notebook. Most Web-Client applications today utilize advanced multi-tier tools like those from Ajax plus more advanced toolsets from development systems like Visual Studio 2010 and provide a far better user interface and experience than their ancestors did.
In a nutshell, in the old days say fifteen years ago, Web-Clients were clunky, two-tier and had terrible user interfaces, nowhere near as good as their Fat-Client counterparts. Today, using the advanced development tools available, it is possible to build a Web-Client that looks and works little different from a Fat-Client. Much better development tools have made it much easier for programmers to build nicer looking, more functional and easier to use Web-Client user interfaces for applications.
It still isn’t all roses because not all browsers are equal and different browsers (e.g., IE versus Safari) and different versions of browsers (e.g., IE 6, 7, 8 and 9) force the programmer to have to write extra code to handle the differences. The advent of HTML5 will soon introduce another layer of differences and difficulty as vendors deploy different or non-standard versions of the HTML5 standard. However, this has been the case for as long as I can remember (there have always been differences in the HTML deployed by different vendors) and us programmers are used to it by now.
It used to be that because of the limited development tools available to code Web-Client interfaces that the typical Web-Client had far less functionality than its Fat-Client equivalent. Whereas it is still easier to implement complex functionality in a .NET Fat-Client than a Web-Client, it is possible to provide equivalent functionality in a Web-Client; it just needs smarter programmers, more work and a few extra tools.
So if your application vendor offers you the choice of a Fat or Web user interface, which should you choose and why?
You first need to ask a couple of very important questions:
· Does the Web-Client have equivalent functionality to the Fat-Client? and
· Is the Web-Client operating system and browser independent?
Let’s address the second question first because it is the most important. You can for example, write a Web-Client user interface that it not operating system independent and that in fact is ‘locked’ into a particular operating system like Windows and a particular browser like IE8. Most Silverlight Web-Client applications for instance require that the .NET Framework be installed on the local workstation or notebook. As the .NET Framework only works on Microsoft Windows systems it means you can’t run your Web-Client on other systems such as Linux, Mac OS, iOS or Android.
It also means that your IT department has to install and maintain software on each and every workstation or notebook that needs to run the application. This is the big problem because the cost of installing and maintaining software on each and every desktop and notebook is enormous.
Ideally, the Web-Client will be operating system independent and will support most of the latest versions of the most popular browsers. Expecting the Web-Client to support old versions of browsers is an unreasonable expectation.
If the Web-Client is operating system independent and has the same functionality as the Fat-Client then your decision is a foregone conclusion; go with the Web-Client and save on the installation and ongoing maintenance costs that would apply to the Fat-Client but not to the Web-Client.
If the Web-Client has a subset of the functionality of the Fat-Client you then need to compare the functionality offered to the needs of different classes of your users. It may not suit your systems administrator but will it suit inquiry users who just need to be able to browse, search, view and print? Will it also suit the middle-class of users who need to be able to add, modify and delete records but not perform administrative tasks like designing reports and building workflow templates?
It is important to have as many of your users as possible using the Web-Client because not only will this approach reduce your IT costs it will provide extra benefits for users who travel and operate from remote and poorly serviced locations not to mention those who work from home. After all, all that is needed is a computer (or tablet or smart-phone) and a secure Internet connection.
Obviously, as a Web-Client runs from a Web Server your IT people need to ensure that it is secure and for example, operates as a secure and encrypted HTTPS website rather than as an insecure HTTP website. All traffic from public sites needs to be encrypted both ways as a minimum security requirement.
The other major benefit of the Web-Client is that it protects you from differences in operating systems, e.g., Windows XP versus Windows 7 or even Windows 8. A Web-Client runs in the browser, not in Windows so it is much less affected by fundamental changes in an operating system than a Fat-Client application which has to be re-compiled and re-certified against every change. Importantly, you are not locked in to a particular operating system or version of an operating system.
I expect most application vendors to be moving their customers to a Web-Client end user platform; we certainly will be and are investing large amounts of dollars in our RecFind 6 Web-Client interface. There are enormous cost and convenience benefits to our customers in moving from our Fat-Client to our Web-Client user interface and we will be doing everything in our power to encourage this move.