Now that the Web has finally invaded just about every corner of life and the magic of "thin client" has been applied to every conceivable application we can finally as ourselves the question "is this the right thing to do" rather than "can we" or "how do we." the answer to the second is "yes" and with some Googling the answer to the third is within easy grasp. But these two beg the first question, of "should we." At my company we started out our first pass on the GUI as a pure think client DHTML nirvana. At the time the think client kool-aid was quite strong and everybody bought into the vision of it. We didn't have any real serious discussions on any non-html solutions. We have since started going down the swing path for various reasons. It wasn't a bad thing we started out thin, because if we started out thick we would have certainly have been asked the question about why we don't just do it in HTML. Now people can see the difference and for waht is wanted it is a real value.
But thick isn't always the answer. Sometimes thin is the way it should be done. But when and which? Here is a bullet list based on some of my experiences, dating all the way back to when NetDynamics was sold by a company called Spider Technologies.
- Scale - This is actually two questions, with different answers for each extreme based on the way you ask it.
- Number of Users - How many users are going to be using this application? If it is large (hundreds to thousands per instillation) then a thin client avoids messy install issues. If it is small then either way.
- Amount of Data - How much data is the user expected to handle. It's not about how much water is coming through the hose but how big the nozzle is. To much data coming through a thin client is like a fire hose. But on a thick client it can look like a meandering river. Lots of data at once means go thick
- Interactivity - Is the interface meant to be highly interactive? We're not talking just mouse overs and hovers. Resizable and removable column headers have a hight cost associated with then in a thin client. Similarly a frequent need to update data on the server can place a heavy load on the server application if done poorly, even if done smartly. A thick client can more easily update a small piece of data without dragging back across the wire a large amount of strictly visual effects, such as adding a new node to your typical tree control.
- Rich UI Controls - How much control do you need over the UI controls? Editable ComboBoxes/SelectBoxes are one example that are all but impossible to do well in HTML. A rich table control with sortable columns that can be dynamically resized and have columns removed showing thousands to possibly millions of rows can be done with HTML through various HTML and serving tricks, but the tend to work better when thick. Some controls can be emulated "good enough" in HTML with scripting, such as calendar selects and formatted fields, so that may work for thin. But plain old goofy controls will requires some meat on them bones.
- Frequency of User Use - How often is the typical user going to use it? If it's once a month they won't endure a 10 minute install, like your typical online banking app. But if it is continually used they may want a client image, like an Instant Messenger client. Some frequently used apps can be done well with a thin client, but that's because the UI is simple
Thin clients are good, but I think they are being over-done. When I hear of people writing a UI that 10 people at each large client will be using all day with rich table controls and massive amounts of data pushed through it being written as a DHTML web app it makes me want to take the blinders off and introduce them to old friends like Applets and new friends like WebStart. After all, thick is the big trend. |
