Should our clients be thin or rich?

If you want it to be 100% available, go with the zero footprint model.

if you want to become locked into using something you have zero control over [ flash is an axample ]
then go for the rich client.

The zero footprint model doesn't mean a dead looking tool, check the links I have in my TR links, CSS Play website, by Stu Nichols has some interesting effects, all done with CSS only, no clientside scripting. [ some of the examples will only work with Mozilla's browsers, as IE doesn't meet w3c standards very well. ]

Didn't the tech world move to thicker clients because the users wanted more control over their applications. Is there a risk that the thin client will only be able to go so far in meeting the users' requirements.

I'm not familiar with Flash, but isn't the fact that they do take some control away the point. I will soon be looking at the latest Microsoft stuff which they tell me will be able to do the same rich client stuff and since I'm tied into Microsoft at the back end anyway - am I really losing out?

I'm guessing you're not a Microsoft fan...

"You can never be too rich or too thin." :)

some things you won't get with a thin client app, like sounds on mouse clicks.

if going browser based, you would have to throw ie into quirks mode by sending < xml? > tag at the top of the page and put ie only code in.

the true benefit of the browser based thin client model is that the app is portable, across all os, and all browsers, with standards compliant code as well as the ie code in it. this makes such an app a pruduct that can be sold, generating another revenue stream for the company, with zero people left out of usage because of os requirements.

The risks with the browser based thin client are more due to the nature of the connection, if it's not using ssl it's more accessible to packet sniffing on the web. Though the rich client has some of that risk, mostly it's defeated by the proprietary ui code. [ the person running the sniffer would have to be using the same tech, and catch every packet to get the data instead of being able to read any packet to see if there is any likelyhood of the data being send.

Only thing is, high speed internet access (or for some any at all) still isn't ubiquitous, and it won't be for a long time yet.

I'll believe in the thin client when I see a full function application (think Access, Excel, Photoshop, Autocad,...) with a web-style interface. That is with every feature that exists in the apps today. Things like customizable/draggable/dockable toolbars and menus. A proper multiple document interface with tiled/cascaded windows, etc....

When we see everyone with access speed high enough to provide this level of functionality and a web protocol that can deliver the functionality, we might be able to move to thin clients.

Regards

In my opinion, I think it's very clear-cut. You will need to do both, probably. If your application will require a complex user interface, then you'll need to go thick client/smart client. Writing web apps that do simple things like dropdowns from databases is a real pain because you have to write not just in your language of choice, but also use JavaScript or AJAX or whatever. Web apps that do significant work are cumbersome to write and will never have the slick interface of a thick client.

With that said, web apps have their place, too. If you have a situation where you have a simple input screen and needs to be accessed by people "on the go" or accessed from regular people on the Internet, then you should probably go with a thin client web app.

I am absolutely certain about that, and it should be common advice that you get from others. What I'm not so certain about is where the industry is going. If Microsoft has its way, smart clients are the future. And since I see no alternatives at this point, I'd be inclined to agree.

As someone who has to support a bunch of apps for a corporation, my view is: if the app is mission-critical, it should be a rich client. If it is an add-on or "nice-to-have", then I prefer the smallest footprint possible. My acconting software must be a rich client, but giving users remote access to their e-mail (not a critical function in my company) is best filled by a webmail product of some sort. Of course, developers and software vendors will have a different list of what is misssion-critical than network admins (and users will have yet another list), but the install, maintenance, and support needs of a particular app weigh very heavily in my mind when I am picking apps.

For typical applications, I contend there are two issues that precluding the viability of thin client, the low level of user interface support in HTML and brwosers, and the reliance on a "connectioness" model. For data intensive applications, I would add network response time.

The HTML display primitives are too basic for most needs and typically require download of custom code to do standard operations at the client. Some examples of this are the default behavior of a drop down list, lack of standard data validations such as character only, numeric only, date entry, simple range validation of numeric and date entries, spelling and grammar checking, and lack of a standard data validation phase (perhaps performing custom validation code) performed by the browser. To overcome these things, we either pay a penalty to download code to do these things on the client, or have operations deferred to the server.

A second issue is the "connectionless" model. The part that is connectionless is the part at the client, while back at the server we do handstands to recreate a connected service. This implementation is reverse of what is needed for applications. The client should operate as connected, while the server acts in a connectionless manner. The client machine has the resources to maintain the connection, instead we keep bulking up the server to maintain as many parallel connections as possible, and pay penalties as they are cached and retrieved from disk and constantly resent back to the client. In an application, a user will constantly revisit the same pages throughout the work day. Each time the user currently returns to a page, the client machine must retrieve both the common page code and the custom data displayed on the page. In many cases, the select lists and validation code on the page dwarfs the actual data. Constantly having to stop and wait for a page to display is one of the biggest user complaints with web-based applications.

As noted above, for many applications, the amount of unique data on a page is often quite small. There are some applications, though that are data intensive. A software development system is an example of this. I doubt there is a developer out there who would want to work on a thin client compiler.

I think there needs to be a major new infrastructure put into place where thin client can become truly useful. I think to be successful, thin client needs a full suite of generic capability built into the client (for those with long memories, think of extending the capabilities of a 3270 terminal). I do not think we will ever have enough bandwidth, low enough response time, or enough server storage to have all processing pushed back to the server.

.. when I see a full function application (think Access, Excel, Photoshop, Autocad,..

I guess you didn't see Autocad 2001?
Autodesk went with the server based web app model, you installed a ui that connected to their server to run it.

they went back to the install on local machine, since no-one wanted the heavy data transfer and monthly access fees the web based version incurred.

Although we have a business requirement to be OS independent for the client, we are MS dependent on the back end.

The client needs to be flexible and user friendly, but is not heavy on graphics. I'm a bit wary of Java due to its interpreted nature - although that goes for C# to some extent as well.

I guess the more specific question is given a Microsoft back end with a web service API, what will the industry be expecting the technology of the client to be in 2 years time?

I believe Rich client will need a local database at each remote site. For example 150 local networks connected to one head office would require 151 databases all of the same size i.e. large. If the local server dies then that remote site can not function and the function can not be performed anywhere else unless a local install and database are installed at the new site.

Is this the case?