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!
 |
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.
2003–2024 John Topley
Comments
There are 6 comments on this post. Comments are closed.
You make some very good points. It often seems a bit goofy to create a web app, when others will do much better. But I believe that sometimes a web apps *is* the best choice for the job. It comes down to using the right tools for the right job.
Excellent article! I've encountered a few Content Management Systems (CMS) recently - all of them are browser-based, all contain Java applets for their editing - and they're all horrible! In each case, the interface feels hobbled and limiting (in comparison to what's possible in a desktop application), and the speed has been appalling. Even a fast browser response is always going to be slower than using a native desktop application. When you use these systems, you immediately sense the additional time it takes to perform even simple tasks. The worst aspect of these systems is how they take a primarily non-wysiwyg approach to content editing - end-users really dislike this. What's more, the Content Management Systems I've seen all run only under Internet Explorer and must use a specific version of the Java VM (the wrong version can cause errors when running the CMS) - these problems seem to completely negate the idea of cross-platform, hassle-free installation. I suppose it's not fair to blame Java for this, but what surprises me is how rapidly programmers have bought in to the idea of cross-platform deployment as a means to avoid vendor "lock-in". This sort of thinking was quite rare a few years ago. But then Sun came along and gave us some ridiculous claims about how Java would make the underlying Operating System irrelevant. I wish we could have some more balance in the debate and someone would argue about the benefits of fast, natively-compiled, client-side applications that take full advantage of the OS and the underlying hardware. It's perfectly possible to install a single executable file that doesn't spew dlls all over the place. So installation certainly need not be messy for client-side apps. Sorry, had to whinge :-) Oh, by the way, the Content Management Systems I've encountered all try to address the back button "problem" by simply launching the main CMS screen in a new browser window devoid of any browser buttons. I think that's what they call a kludge!
JC, As I said, web apps are appropriate if you need to support multiple client platforms, although even then I'd argue that you should provide a rich client GUI for your office-based users who are gonig to be stuck using the thing all day. Another thing I forgot to mention is that the edit/compile/debug cycle is so much longer with web applications. With Delphi it used to take a few seconds but using Oracle 9i JDeveloper at work it takes a few minutes per cycle. One of the advantages of computers is that they're very fast but in this instance I find myself waiting for the machine.
I highly recommend looking into Flash as the GUI for a web application. With Flash you have a few options. -Flash Remoting. This is Macromedia's proprietary communication between the server and the Flash player. I believe you either need Coldfusion on the server or their Flash Communications server. -Web Services. The latest Flash player can work with SOAP and Web Services. When it was first launched people were reporting memory leaks in the Flash player, but i'm sure it's a bug-release away from being very usuable. This will work with any server that can do web services. -Flex (http://www.macromedia.com/software/flex/). Macromedia's $12,000 answer to XUL and XAML. The user will only see a Flash movie, but the developer will be working with XML. The cheapest way to go would be the Flash w/Web Services. The only Macromedia product you'd have to buy is the Flash authoring environment (desktop app).
I don't know much about Flash but I know that it can integrate with a J2EE middle-tier. I agree, it seems like a neat solution, although I'm not convinced about the market penetration of the Flash player nowadays. I always seem to be prompted to download a new version. Obviously, that's not a problem in an intranet environment. Unfortunately I don't have any Flash skills. Does it come with a standard set of window widgets? And can you disable the context menu that has items for controlling the movie?
I don't have any Flash skills either, but we've got a guy here at who does. We've made a couple of demo apps that went back and forth with a DB on the server. To answer your question. The latest version of Flash has prebuilt window widgets (more so than in previous versions). Macromedia also has a version of the authoring environment that is supposed to be geared more towards traditional developers. I believe its "Flash MX Professional 2004". Check out their site, they've got tons of great content about their products. (I feel like a macromedia sales person.) As for the market penetration. They claim like 99% or something. But of course you need the latest player to do the cool stuff, but if its an app your building I wouldn't sweet it. It's just another requirement of the app. If it's a commercial/ecommerce/business site, i'd think about it a little more.