ui design
Tue, Nov 15, 2005Over and over again I run into client-server projects that attempt to do complicated user interface systems with web pages (or even rich gui applications) primarily driven by the back end engine. This inevitably leads to a high traffic volume, which in turn leads to high resource usage on the back end. The solution, as always, is to push as much work onto the client as is reasonably possible. Surprisingly enough this concept is older than myself, and yet not often followed (think most terminal systems). Although it is currently trendy in the web development community (AJAX ring a bell?). The classic problem with all of this client control is just that, the client has to be trusted to do-the-right-thing. While you can restrict the client's access domain, you still have to give the client access to something. What a troublesome world we live in.
Now this is always limited by technology. Try drawing a realtime waveform in pure javascript based on a raw stream of bytes. Then try the same exercise in C#, there will be a good bit of difference in regard to the difficulty of the task. Then introduce the possibility of multiple graphs painted in parallel and the choice should become obvious. Then again, the javascript client has the edge in portability, but can't match the capabilities of the C# client. There I think lies the problem ahead of web based companies like google and yahoo. At some point to compete with the wiz-bang graphics of MS and Apple they will need to provide some sort of competing wiz-bang super graphics. Right now I'm thinking that SVG may provide just such a platform, but that depends on browser support. From what I've seen currently (and no offence to the mozilla group) there isn't a viable built-in rendering engine. Hopefully one will come along.
I do like ajax, and edevil has a nice list of some javascript libraries which will certainly come in handy at some point. As a side note, I finally watched Spanglish which was an enchanting movie.