This post originated from an RSS feed registered with Java Buzz
by John Topley.
Original Post: Users Are Not Dogs
Feed Title: John Topley's Weblog
Feed URL: http://johntopley.com/posts.atom
Feed Description: John Topley's Weblog - some articles on Ruby on Rails development.
The problem of what to do about the browser Back button has reared its ugly head again. Actually it's never really gone away, it's just gone out of focus because other issues have come up and because it appears intractable.
Our latest thinking on the matter is that we'll display a friendly error message (whatever that is) to the user if they click Back until, like a dog learning by repetition, they come to know that a web application is not a web site; even though it looks the same and is accessed in the same way. I'm skeptical that this attempt to refine the user's mental model of how the application behaves will be successful and I hate the current technological limitations of web applications for forcing me to inflict this crippled solution on my users, who are not dogs and don't need to be taught new tricks.
I've just started reading the book Dealers of Lightning which is a detailed account of the astonishing level of creativity and invention that occurred at the legendary Xerox Palo Alto Research Centre (PARC) in the 1970s. For those who aren't familiar with the story, the brightest minds in the industry were brought together at PARC, the result of which was that (for example) their 1973 Alto personal computer had a mouse with which to access the familiar desktop GUI that we all use every day. Oh, and you could hook it up to other Altos too, using Ethernet technology that was also invented at PARC. Or perhaps use Bravo, its WYSIWYG word processor invented at PARC, which is the grandaddy of Microsoft Word. Remember, this was in 1973 when Britain was driving about in the Ford Cortina and listening to the Bay City Rollers!
Every family in Britain had a Cortina in 1973.
For various reasons Xerox were not able to capitalise on their twenty year head start in modern computing, although it's often forgotten that PARC paid for itself many times over from the revenues generated by its invention of the laser printer alone. Incidentally, I've never understood why computer monitors don't follow the A4 portrait form factor used by the units at PARC.
Where all this nostalgia is taking me is to the thought that with web applications, we've dragged to the trash can icon over thirty years of research, innovation and refinement of HCI technology, and have effectively gone back to the time of the IBM 3270 dumb terminal. The network may be the computer, but if I create a conventional desktop application then I have a rich variety of widely-used and understood user interface widgets to choose from. On the other hand, creating a web application constrains me to structuring the interface in a way that tries not to expose the limitations of the underlying technology, but in fact does end up exposing them. I have to coerce the users into working a certain way rather than giving them the freedom to choose how they'd like to work within the boundaries of the application. Apart from the intellectual challenge, the pleasure I get from programming is from the thought that in some small way my software is making the lives of my users just that little bit better, or certainly less tedious, but I'm denied that feeling when constrained by the HTTP straight jacket.
As someone who has had the pleasure of rolling out a slightly complex Visual Basic 6 application to a few supposedly identical PCs that turned out to be anything but identical, I can well understand the lure that the zero footprint web application model offers. From an IT support department perspective this is great; just send out a URL to the application and then you can happily spend the rest of your day installing Microsoft security patches or perhaps working out how to get Linux to do what that nice Windows 2003 Server start-up wizard did for you. I exaggerate the point for comic effect but apparently the reduction in the support burden in a reasonably sized organisation—which is not the same as a reasonable organisation—is huge. I've never been entirely convinced about this, mind. It should be possible to control DLL hell in a tightly controlled corporate environment on the proviso that you have people who know what they're doing. I think a lot of the problems stem from programmers developing internal applications—probably using VB—not entirely understanding what it is they're doing (accidental programming) or crucially, not knowing how to package up and deploy their applications properly.
Half-way houses between full-blown desktop applications and half-cocked web applications are starting to emerge. In response to my original article Nigel McFarlene helpfully pointed me to an excellent article he'd written about Mozilla's XUL and more recently Microsoft are pushing their own XAML for Windows Longhorn. Both seem like worthy ways to address the problems of current web applications (I know there's more to XAML than that). However, neither help me because unfortunately Mozilla isn't an option where I work and Windows Longhorn is years away from shipping and even further away from widespread adoption.
For corporate software that is never going to be accessed from a PDA or phone, thin client applications are a criminal waste of all that Moore's Law horsepower packed into that new black and silver Dell gigabox sat on your desk—a miracle of technological progress that was brought to you not without environmental impact, so why waste it? Ultimately what it comes down to is this: are you creating software for your IT department or for your users? And herein lies the problem: the difficulty I have with web applications is that they're designed to benefit the IT department and not the user. The user may as well be a dog.
Previous Topic
