I attended the first Java One conference back in 1995. Anyone who was in the industry at the time will remember the excited throngs (at the conference and in the industry) getting all lathered up over all things Java. (They gave out super cool mini Leatherman knives with the Java logo. The TSA now owns mine.) The height of the Java excitement was Corel’s announcement that they would port their entire Office suite to Java. What value customers would get out of the developers convenience that Corel was optimizing around I have no idea. And in fact, customers had no idea either. While I can’t find any official net record of this project’s cancellation, as far I can tell it never made it out of beta.

This kind of mob mentality running to the latest technology is not uncommon among software developers. And it’s not all bad. The WORA promise of Java was and is attractive to developers. The fact that people over-reacted (as they often do) to the excitement by starting efforts like Corel’s isn’t the fault of the technology, it’s the fault of corporations being dopey. Today’s mass migration of apps from the desktop to the web has some similarities. Unlike Java, the stated (and real) advantages are not just for developers, but they’re for consumers and they’re very very real. But there are tradeoffs, and even using client-based technologies like Flash and Silverlight to augment the native browser platform, these tradeoffs are still there and they’re significant.

Here at Jackson Fish we’re not big on technical religion. We’ll use whatever works best for the experience we’re trying to build. The true state-of-the-art app platform doesn’t exist yet. But its definition is not about a particular set of technologies, it’s about a set of characteristics and behaviors. Not all web apps suck. In fact, some are quite lovely especially with the right mix of browser-based technologies creating smooth and polished experiences. So the glass is definitely half full. But the web will still not be the right platform for a certain set of apps until the following issues are addressed. (Note: I know there are techniques for addressing these concerns to some degree, but for me, from an experience perspective, they fall short.)

• Responsiveness. It may not seem like a big deal when a product responds to your input just a touch slowly. And in truth, most websites today are certainly tolerable. But there’s a difference between tolerable and enjoyable. Well written client apps, where nothing gets in the way of the UI thread, are performance race cars compared to most web apps that cough and sputter after you click something. And never mind Ajax. My accounting webapp, which I really enjoy relative to its over-complicated desktop cousins, is busy using Ajax to death and is super super slow.
• Controls. I think most developers (never mind most users) don’t realize how many details are critical to get right when it comes to a set of controls. It’s mostly around subtle interactions, especially with the keyboard, that are the fine grain details that need to be gotten right. It took years for IE’s basic HTML controls to become tolerable and Firefox still has work to do in my opinion (text boxes specifically). When sites use Flash things get worse as they’re often rolling their own controls and most developers don’t have the time to nail every detail for every control. Scrollbars are a particular sore point with them never quite working right.
• Handling large datasets. There are a couple of axes when it comes to handling large amounts of data. In the first blush analysis it’s simply an issue of memory. The more data (thousands of rows in a list or a very large image) that you try to load into a web page, the slower the page gets. Scrollbars are a wonderful piece of UI. However, even Gmail, the crown-prince of Ajax doesn’t let you see all the mail in your inbox at once. Instead I have to page between 50 rows at a time. Outlook is happy to show me 1569 messages at once and it’s not even breathing hard. And yes, I understand the technical realities of the browser that force these paging metaphors on users. Until those realities are fixed, the user experience in these situations will always suck. The paging user interface model is an abomination. It’s a fax machine in a world of e-mail.
• Multi-select. On deeper analysis, there’s another more insidious problem that is raised with large sets of data… that’s the issue of multiple selection. Introducing any form of selection to users is a chasm you’d prefer to not cross as it can’t help but introduce complexity to your audience. However, sometimes it’s required. There are all sorts of mechanisms that have developed for selection and operating on selections (the most famous perhaps being the Finder/Explorer model of selecting with one click — relegating double-click to opening). I’m not saying that’s the best model, but I know that checkboxes are not even close to a credible way to do multi-select on more than a couple of items. Selecting multiple items (as in hundreds) is simply a non-starter. There are techniques that have been explored, but it’s just not something you can even really do in a web app today in a tolerable fashion.
• Online. Being “online” is of course one of the main advantages of web apps. They’re hosted elsewhere, always up-to-date and only cached locally, etc. But the online world is not quite perfect. I know the optimists among us will claim that these problems are temporary, but my network still goes out sometimes, there are still weird latencies in the network that affect my user experience, and the net isn’t available everywhere yet. Maybe I’m living in the past as soon these will all be problems of the past. But for now, I think they’re real, and I’m not sure they’re disappearing any time soon. At the very least, in my opinion, the issue of network latency is a real one for some time to come. Until web apps have a way to protect their user interface from minor slowdowns and dropouts in the network (and it’s not just slight delays… it’s data loss as well… should I lose all the data I just spent 20 minutes entering into a text box because I hit the “submit” button while the network decided to flake out?) then it’s not first class app platform I really want.
• App Navigation/Management. Finally, and this is a problem really for the OS vendors, web apps are still living in their own world when it comes to the inventory of applications on your system. I suppose given how many web apps I use today, maybe it’s my client apps that are living in a separate world. Either way, there is an app dichotomy today in each OS interface. Launching apps, switching between apps (window management), etc. is done two ways. One in the shell/finder, and the other in the browser of choice. It’s not like it’s been a huge problem for users that has limited app adoption (in fact none of these issues have because the benefits of web apps so outweigh the limitations) but it’s still an issue in my opinion. Having been partly responsible for the user interface of one of those OSes I’m criticizing, I failed to get this issue addressed, and I’ll admit that not many people seemed to think it was a big problem. But I do. Microsoft tried to address this issue in the IE4 time frame but not all of their initiatives were on target. I am looking forward to a world where “installing”, launching, and navigating between apps works consistently and thoughtfully across all the different “apps” on my system.

Some folks might check out this post and immediately move to defend the virtues of web apps. There’s no need. We started a company focused on writing great software and the first two apps we published (and many more likely to come) are web apps. We get it. And we could easily write the corollary to this post talking about the numerous advantages of web apps (e.g. near-zero client footprint, no version management, anywhere-availability, etc.). However, that post has been written many times.

Some people might argue that the limitations of the browser force people to create simpler apps, and that’s a good thing. I suppose that for undisciplined developers, forced constraints can result in inadvertently simpler user experiences. However, in this case, the compromises are too egregious when it comes to writing apps with power, span, and responsiveness. There are workarounds for some of the issues listed above, and attempts at putting band-aids on some of these problems. But until these issues are addressed at a foundational level, many of the apps we use every day will always be good but not great.