Danno Ferrin blogged on the overuse of thin clients when sometimes thick are more appropriate. He describes a number of useful criteria to use when starting to think about which client style to use.
But he stops too soon. While he mentions at the end that WebStart is a new friend, he didn't attach this to thoughts on the scale of deployment. A lot of people use thin clients to avoid sneakernet install issues for think clients, but in reality JavaWebStart is solving this problem now for think clients.
But one of the larger problems in my mind, that Danno didn't mention, is UIs for which the data presented is driven by events other than the user. Stock trading consoles that want to display dynamically updating quote information. Power grid managment wants to display real-time loading, current,voltage, frequency samples. Sure you can solve these problems with auto-refresh, but that has its own cost in extra reads (solving for accuracy) or out of date data (solving for bandwidth). Not to mention that the actual data that is updated is way way smaller than the whole page refresh. Again, bandwidth.
Another case was a web calendar I was looking at lately. Setting up a group for cross referencing calendars to find availability, required flipping through piles of screens to find a person's calendar, go to another to add it to the group, go to the search again to find the next person. Came to something like 4 screens per person added. Each with HTTP page loading times. Took forever. Totally crazy. Compare to some fat clients doing similar things in one dialog.
Some thick clients are a joy to use, while their thin counterparts make me want to use another product.
But he stops too soon. While he mentions at the end that WebStart is a new friend, he didn't attach this to thoughts on the scale of deployment. A lot of people use thin clients to avoid sneakernet install issues for think clients, but in reality JavaWebStart is solving this problem now for think clients.
But one of the larger problems in my mind, that Danno didn't mention, is UIs for which the data presented is driven by events other than the user. Stock trading consoles that want to display dynamically updating quote information. Power grid managment wants to display real-time loading, current,voltage, frequency samples. Sure you can solve these problems with auto-refresh, but that has its own cost in extra reads (solving for accuracy) or out of date data (solving for bandwidth). Not to mention that the actual data that is updated is way way smaller than the whole page refresh. Again, bandwidth.
Another case was a web calendar I was looking at lately. Setting up a group for cross referencing calendars to find availability, required flipping through piles of screens to find a person's calendar, go to another to add it to the group, go to the search again to find the next person. Came to something like 4 screens per person added. Each with HTTP page loading times. Took forever. Totally crazy. Compare to some fat clients doing similar things in one dialog.
Some thick clients are a joy to use, while their thin counterparts make me want to use another product.
1. a reader left... Fat vs Thin is certainly a valid argument to have, but I think that most discussions rest of certain assumptions that dont have to hold true. The biggest of these is the assumption that every user action in a thin client requires a HTTP round-trip. Smart use of javascript and HTML makes it relatively easy to avoid these things - the web calendar you mention is a classic. The real argument there is, as Danno puts it, the amount of data coming down the pipe. In my spare time atm I'm working on a training diary aimed at rowers, available at http://training.coxless.com, which has a MS Money style interface to viewing a diary, and works (I think) very well.
Having said all that, there are plenty of times when a thick client works wonders - but the biggest argument from my point of view is the number of users. Having not too long ago finished a contract where a thick client was deployed to 60-70 users, and even at those numbers, deployment was an issue (mind you they refused to accept my advice regarding webstart).
Dmitri Colebatch
Sunday, 23 November 2003 2:12 pm
Having said all that, there are plenty of times when a thick client works wonders - but the biggest argument from my point of view is the number of users. Having not too long ago finished a contract where a thick client was deployed to 60-70 users, and even at those numbers, deployment was an issue (mind you they refused to accept my advice regarding webstart).
Dmitri Colebatch
2. glen martin left... Well, ok, there's javascript, but I think that is blending the two styles of interface. If there's behaviour running on the client, it can't precisely be called thin, can it?
Though I might be accused of splitting hairs here. Many seem to say thin when they really mean broswer-based. The problem is, if javascript (or whatever javascript alternative you care to name)isn't present or is disabled, what happens? True thin clients wouldn't have client-side behaviours.
But I think your closing thought perfectly underscores my thinking: Despite well known solution to the sneakernet problem, folks continue to choose thin vs thick for reasons of installation, rather than for more credible ones.
One reason of which is size of data in the pipe.
Given JavaWebStart, folks have the opportunity to make choices for more relevant reasons, which should in theory result in greater diversity of interfaces out there.
Monday, 24 November 2003 10:18 am
Though I might be accused of splitting hairs here. Many seem to say thin when they really mean broswer-based. The problem is, if javascript (or whatever javascript alternative you care to name)isn't present or is disabled, what happens? True thin clients wouldn't have client-side behaviours.
But I think your closing thought perfectly underscores my thinking: Despite well known solution to the sneakernet problem, folks continue to choose thin vs thick for reasons of installation, rather than for more credible ones.
One reason of which is size of data in the pipe.
Given JavaWebStart, folks have the opportunity to make choices for more relevant reasons, which should in theory result in greater diversity of interfaces out there.
No comments:
Post a Comment