There has been some speculation about Chrome being the central piece of Google’s web OS. There has also been some entertaining, if not entirely constructive, disagreement. It got me to thinking about how the web as a platform does work and how it should work before it can be a viable desktop replacement.
The web as a platform has some tremendous advantages. Software is always up to date, it’s connected to your friends and family, it’s consistent across machines, and there’s a low barrier to entry. Users don’t need to install anything, designers don’t need to learn how to program, and programmers can work in fun, high level languages. Awesome.
There are a lot of problems, however. The first is the obvious one. The web was never intended to be anything besides a publishing platform, and so web applications have to push browsers to their limits to achieve the kind of functionality users are accustomed to. Even with the amazing techniques and hacks that have been developed, the experience still does not compare. Web applications cannot easily access local storage. They cannot do heavy calculations. They cannot offer the vast array of interactive components that we expect in feature laden desktop apps.
This has caused a number of good things to come about. There is an emphasis on simple applications that do one thing very well. These applications (such as those made by 37signals, gmail, and meebo), all use a bit of JavaScript to improve the experience, but keep their core functionality to a minimum. This keeps the interface responsive, and makes it easy for users to learn. There has also been a number of great JavaScript frameworks developed, many of which try to take out the painful browser discrepancies while keeping the inherent flexibilty of the web platform. JavaScript interpreters have gained a lot in the past year, and stand to improve a lot more with innovations like V8 and the sophisticated interpreters being developed by the WebKit and Mozilla teams.
This is all great, and bodes well for the browser having the capabilities to deliver ever more sophisticated applications over the web. However, there are some basic limitations that make it exceptionally difficult to move all applications to the web. They are mostly centered around consistency and accessibility.
Consistency is vitally important to usability on a real platform. On my Mac, every program I go into has menus in the same spot. All the buttons look the same. All the windows look the same. All the fonts are the same. All the shortcuts are the same. On my Windows box, all these things are different than my mac, but they are generally similar and they are consistent across Windows applications. This makes these applications usable as a platform.
Web applications do not offer this. Every menu is custom designed and can be placed anywhere. Buttons do not look the same. There is a mismatch on what should be a link and what should be a button. Keyboard shortcuts exist on some sites, but they are so drastically different from the ones that I’m used to and other sites that they are essentially worthless. The customized, expressive power of the web is at once its greatest strength and its greatest weakness.
Until there is a standard, web applications will be less usable than their desktop couterparts. When every application is an entirely new experience, the user cannot begin at some basic building blocks for learning a program. Without this initial state, there is a limit to how complex a program can be. It is very difficult for a web program to be more complex than what you can learn from scratch in 5 minutes, because if it is, nobody will use it. This puts a ceiling on the capabilities of web applications that will not be solved by the fastest JavaScript interpreter.
Accessibility is another issue. By accessibility, I don’t mean optimizing a site for the disabled, though that’s an important limitation too. I mean having a set of applications that everybody can and does use. When a person buys a Windows PC, they can boot it up and use Microsoft Mail with whatever email address they have. They kind of know how to use it since it is the same as every other email client they have ever used. There’s a program for pictures, there is a browser, there is a calendar, there is a chat client, there is a music player. There is probably at least a basic word processor. All of these things are great because the user can just use whatever came with their machine.
What happens when you take away the machine defaults and give them a browser instead? First off, many users will not know where to go unless some defaults are offered. Assuming there should be defaults, how do we choose them? There is no web site that I know of that lets you work with any email address. The computer will need to figure out which site should be your email program as part of its setup process. Which word processor should be used? Which search service? Which music site? Which calendar? If the user used Flickr before switching and the browser’s default photo application is PhotoBucket, will they understand that they can use Flickr? That they can change the “Photos” shortcut to point to Flickr?
The answer to the accessibility problem is easier than the answer to the consistency problem. The defaults will be chosen by whoever ships the browser, and for the sake of example we will assume that’s Google. That makes Google the same as Microsoft, and that’s terrifying in many ways. However glum that might be, it’s not an interesting problem. We either have a dominant player or we don’t.
Solving the consistency issue is interesting. Some standards have started to arise, but they vary so much they’re hardly recognizable. Generally, the user name associated with the current user is in the top right of the screen, along with account settings. The top bar is usually branded and contains some broad navigation elements. Program functions are listed on the left or right side. However, any convention that has been established is loose and is only specific to a very small number of very common elements. Convention, if it’s working at all, is going at such a slow pace I would call it irrelevant.
If we cannot wait for convention to solve the consistency problem, then what can we do? The answer I see is to draw up a standard. The standard would be very specific; it should specify where menus should be placed, what keyboard shortcuts should be used to do what, how dialog boxes should behave, how forms should be presented, what should be a button, etc, etc. It would be possible to create tags to enforce the specification, but I think it would be useful now if it was just the established way of writing web applications. By updating JavaScript libriaries and templating systems to support the specification, it would be as easy for the developer to support as if there were new tags made available. A developer would not need to be intimately familiar with the specification if the libraries they used to work with their web UI was.
Agreeing on a specification is another issue, and perhaps a pipe dream. There should probably be user interface experts involved in creating it, and even with that, nobody will agree. Perhaps the best solution is just for somebody (I hope not me) to draw something up and discuss it until it stabilizes a bit. In the end, a set of specific guidelines for how to design user interfaces in web pages will never be useful until the big producers of web applications and the major JS and templating libraries support it.
Will that ever happen? We’ll see. However, until there’s some consistency, there can never be a web OS.