Saturday, November 22, 2003

Thick or thin

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.

[Comments from my previous blog]

1. a reader left...
Sunday, 23 November 2003 2:12 pm
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, 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
2. glen martin left...
Monday, 24 November 2003 10:18 am
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.

Tuesday, November 11, 2003

Derivation vs. residual knowledge

I am not a lawyer, and these comments do not constitute legal opinion, my own, my employer's, or any others'.
This post is not related directly and makes no comment on other timely happenings. I'm just following a train of thought.
I find myself wondering at the intersection of 'derived work' and 'residual knowledge'. SFAIK, on changing employment the future use of residual knowledge (eg. skills, not proprietary facts) is protected in at least some jurisdictions. LGPL source (to pick an example not precisely at random) is proprietary in the sense that there is an owner, and used under license.

But does 'derivation' require that the source be in front of you? Or that you are remembering the original source? Or thinking about it? Surely once you get to the point that your are remembering that laying out a solution using some pattern is useful, that is only residual knowledge, even if you conceptualised that pattern through looking at or hearing about some source.

Supposing residual knowledge rules could apply, and if only *some* jurisdictions protect residual knowledge, this could lead to a truly unpleasant situation in which *where* the code is typed becomes important. Blech!
The application of residual knowledge law in cases in which there isn't an employment contract is best left to those with more fortitude than myself.