Rich clients look like the future (to me)

I’ve been thinking about rich clients apps (RCA) versus HTML client apps (HCA), and why I tend to like rich clients better. The RC app that most impressed me in the last few years was iTunes; for an HCA, it would probably be this German website to look for rooms for rent. The world has certainly shifted towards HCAs in a big way. It’s not that people aren’t writing RCAs, or that we don’t use them all the time, but you’ll find a lot more of your new work in HCAs these days than in RCAs. But I tend to prefer RCAs, so the question is, what’s going on here?

RCAs have one general killer aspect to them: they are context-specific. By that I mean that, despite following the general GUI guidelines of their respective platform, they tend to be focused on one particular problem, or one particular task set that one needs to address. iTunes deals with music: downloading it, organizing it, playing it. There are secondary features, like burning CDs, but the main thing is I can see my music as individual files, listed by name, band, album, and I can work with the files in a way that seems natural to me. In fact, I don’t even think of them as files–I don’t see file names, or file sizes–I see my music as I would expect songs to be shown to me–there are song titles, album name, band or singer, length of the song (in minutes). I work in a context that is music-specific.

An RCA can be context-specific for two reasons, I think. One is that the toolkit(s) for writing RCAs are much richer than those in HTML. HTML has a very limited set of GUI controls, formatting and layout commands, and programmability. RCAs have not just the default toolkit for the operating system, but any new control you can imagine. 20 years ago you might have adjusted the volume using a spinner; then you could use a slider; now you can use a “knob” that you “turn”. And you can do this because there is a low-level set of constructs that the operating system provides to not only control what you’re rendering, but also to interact with input (mouse, KB, tablets) and to communicate with your program. What this means is that your interface can be specific to a particular task not only in what it accomplishes (managing music) but in how you interact with it. For a music program, a slider control on volume is great. For a zoom feature in a text editor, a spinner might be better. This control over the interface enhances the user’s illusion that they are working in a specific context.

Secondly, an RCA can be context-specific because that’s how we understand RCAs in this phase of technology. We expect websites to have a navigation bar, menu, or side bar, some main content, some images, and that’s about it. While an RCA can stick to the rules and also have a menu bar, toolbar, and main panel, it doesn’t have to–and we are OK with that. We get used to switching interface metaphors when using different RCA apps. This probably limits the range of the apps we can work with successfully, but on the other hand, means that the interface in each case can be targeted to the problem that app is trying to address.

HTML, on the other hand, offers no great flexibility in interface controls, nor do we expect that websites will present drastically different UIs for different purposes. This is probably the great strength of HTML as well–it supports a very simple, limited feature set. Those limitations both allow you to learn it quickly as well as to build new sites quickly, or modify the existing ones with less work than would be the case for an RCA.

There is a lot I am skipping over, of course. HTML is delivered live (unless cached somewhere), so the UI can be updated with zero deployment cost. HTML can use CSS for layout and formatting, scripting for programmability, and supports some limited plugin extensions (like Flash, applets, etc.). It doesn’t have a compile cycle. Most RCAs on the other hand, are written in some programming language that has a compile cycle, use complicated toolkits for building the UI, have costly deployment, etc.

But at the end of the day, I’m getting pretty sick of the limitations of HTML. I’m sick of not having truly context-specific “web applications”. It’s true that it’s great to have universal access to my email, to my bank and to the news. That much I like. But I can’t imagine writing any serious document on a web page, even if I’m doing it in an editor applet of some kind. Too many things are missing; I can’t seem to leave the context that websites provide, automatically, in the background.

There is some hope for the future, in that a number of groups are working on making RCAs easier to deploy and easier to develop. Apple is coming out with a desktop-based HTML/JavaScript toolkit for small mini-applications. Microsoft is pushing XAML. Mozilla has XUL and JavaScript, and Sun is starting to focus on making Swing easier to use, and many Java FOSS developers are starting to play with XML as a way to store layouts.

My guess is that Apple is looking in the right direction with iTunes, in that the lines between client and web are blurred. When you browse the Music Store, you don’t have to leave iTunes to use a browser: it appears in the context of the iTunes app, and the layout looks almost exactly like the rest of the app, despite the fact that the Music Store is online. On the other hand, their concept of updating iTunes is old-fashioned: download an installer, run it, restart iTunes. Apps that can download patches and update themselves live, and that support plug-and-play plugin extensions seem like the future.

Lot’s more to say, but this is getting long.

(originally posted as this JRoller entry)

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.