Software and People

I've been readinlg a lot of articles about "rich web applications" recently. (for example, here ). I can't help worrying that knee-jerk adoption of such things could greatly reduce the usability of the web, though.

I think it's fair to say that a great majority of computer users know how to use a web browser. It's certainly the most used piece of software on my computers, and those at the college where I work. Following on from that, it seems reasonable to assume that the conventions of the web browser user interface are the most familiar conventions in software usability. It's easy to spot the impact of web idioms on other software if you look - Microsoft added a "back button" to their desktop file management tools "Windows Explorer" and "My Computer", for example.

There are many other aspects of the web user experience that are less obvious, though. The little "throbber" in the corner of the window that shows when slow activity is taking place, a big button to stop things that you no longer want to continue or that are just taking too long. User control of whether to open a new window or reuse an existing one. The ability to resize windows to personal taste. The ability to save a whole page or any part of it to local storage for viewing offline later, print any page ... I'm sure you can think of more.

These are the kind of things that I miss when I use a "desktop" application these days. At least nine times out of ten I just want to read a Word document, so why does Microsoft Word always open it for edit? And what changes has it made, that it needs to ask me whether to save changes when I exit. Why do so many "desktop" applications lock up (with no "stop" button) if a resource such as a removable disk is unavailable? Why can't I just stretch a window to see more at once?

So, back to my worries. All around the web you can now find demonstrations of so-called "rich" web applications written using plug-ins such as Flash or Java, browser scripting such as JavaScript or DHTML, or browser extensions like XUL. What a great many of these seem to have in common is that they start from the assumption that they can ignore or disable all the things I find most usable about the web. Flash applications with no "back" or "undo". Applets that lock up if a resource is unavailable. JavaScript software that pops up sub windows without my control. Long operations with no indication of movement or ability to stop them. No control of window size, fonts, colours, or images. Forms you can't print. No way to copy text or save to disk, text that can't be found by search engines ...

I know I'm just one quiet voice in a storm, but if you are thinking of developing any kind of "rich" web application, please, please, embrace all the aspects of the web experience we all love so much rather than rejecting them for your own preferences and assumptions. Don't make your application an irritating, restricted and unfamiliar alternative to the web browser experience, make it a comfortable extension to the web browser experience. If you don't allow your customers the control they are used to on the web, you will alienate your users and risk being out-evolved by a more compatible product.


And this is why I advocate desktop applications as opposed to web applications. Here is how it works my friend. You get some CEO, CTO or what have you that reads about the Web as the final frontier. So they decide they are going to build a desktop application as a web application. But they want it to look/work/feel like a desktop application!! Why? As far as I have been able to figure it, mostly for the "ease of deployment" via the web. Ok, this is nice, but come on people, we are not in the stone age any longer. As a developer of an open source application framework built around plugins (www.platonos.org), I feel strongly that desktop applications should remain desktop applications. Installations are almost painless these days. Installers such as Install4J build installs for mac, linux and windows just fine, and mostly take advantage of the platform being installed on (such as Windows and Registry usage, uninstall, and exe wrapper around java application, as well as services). As I see it, if you are trying to pull every last desktop application miracle out of a web application just so you can provide server based updates, there is something wrong with your design. Web applications are great for convenient things, such as online banking, shopping, hunting for a job, finding info, etc. But to turn an application that needs a lot of user interaction into a web app, frankly results in a LOT more work than is necessary. A few forms here and there are no big deal. But when you have page after page of wizards, and require round-trips to update info on a screen based on what a user chooses, you are doing something wrong. I dislike all these flash/applet/javascript sites. I don't mind a littel javascript that does the common fly over, but trying to make it into a full function user interactive application is in my opinion a BAD design decision. If anything, take advantage of building a client side app that communicates to the server. That way, your users are left feeling like their application is responsive and looks like an application, while the back-end server side work is done on a server instead of in the client app. A thick client is often one that has the UI, logic, and database code in it. A thin client is one that uses a browser like interface. I like to think of a middle client.. one that does some logic as necessary, calls upon the server to do the bulk of the logic/db work, and ultimately frees the client to focus on the UI and user interactivity!
I think you got it backwards...knee-jerk adaption of web interfaces has ruined the usability of many business applications. RIA's are meant to restore some of the usability that was lost when business applications were rewritten using web technology.
Ted, I don't know that I got it backwards. I think the move to rewrite business apps into full fledged web based apps was getting it backwards. The web was this next great frontier, so everybody and their mother was using it and thus every business thought they had to cater to it by making every conceivable application web bound. I still think there is room for both. Rich interactive applications, in my opinion, belong as desktop apps, and as a developer of both, I find it much easier to write and maintain Swing applications with all the rich UI glory, than trying to use various technologies via the web to offer similar capabilities. I'd much rather maintain more simple web based apps and easier Swing based apps, then trying to combine the two into swing (applet), web, javascript, flash and more into one app. Maybe I am not the norm, but having done all of these, I find it much more tedious doing the latter.
y'know, I had to reread your post. And I have to admit that I missed the point about making RIA's an 'extension' of the web instead of an 'alternative' to the web. For instance, making any form in an RIA printable as it's displayed - that would be pretty cool. Also - I just noticed that the Eclipse IDE essentially has a 'Back' button that navigates to previous editors.
As a developer, you have to make a tradeoff of usability vs getting the project done in time. If people want something done right, along with all the things that I agree are important, then you have to pay a hefty price. For many smaller companies that just want to get the job done, they set the shortest dead lines.
What are your opinions of iTunes and the music store? I think that that application has hit the "Rich Web Application" nail right on the head. It has the responsiveness of a desktop app, displays the operational semantics of back buttons, resizing, etc. which you desired plus content is pulled from the web. Granted, iTunes leans more towards a desktop application but, I think with the music store, it poses as a good example of a rich web application. Other thoughts?
I think its horses for courses.

Say you need a full blown (Financial) Portfolio Management System. Such a complex system can be administered best from an application.

However if the firm want to display Portfolio performance and various reports to clients, then a web based deployment is more appropriate. In this case, there is more to display and less of interaction.

For the latter, a RiA is much better, imho, than your standard Model2 arch which ultimately boils down to HTML for display.

Given that client side PC's have a fair amount of processing power these days, the server (in the above scenario) simply acts as a data repository.

The rendering (and functions such as sorting of columns) is performed on the client side.

The problem is when the development teams gets too evangelistic and try to deploy the entire desktop application as a RiA. Here we get back that point as to why Java applets failed , in the first place.

TrackBack to http://radio.javaranch.com/frank/addTrackBack.action?entry=1101660825000