Home The future of web-chrome

The future of web-chrome

This is part three in a series. Parts 1 and Part 2 covered explorations of Office UI chrome. This article looks at what's next.

As part of my work at Raizlabs I work with many companies that are creating new applications or updating existing applications. Over the past few years I've seen an interesting shift. Around 1998 most companies that had desktop applications began to flock to the web to create web-versions of their applications. Then in 2000 as the .com bubble popped many started building smart-client tools. This was usually in .Net, Java or even C++. Now I'm seeing a merging of these two worlds.

Rich client based applications are incorporating web UI (back/forward, links, breadcrumbs) and similarly web based applications are adding AJAX components to give users client side features: (right click, drag/drop, toolbars & menus.) The two worlds are merging and as far as the user is concerned it doesn't matter if it's web or windows.

From the development side I'm also seeing some interesting things as client side applications are embedding aspects of the browser within the application to perform either rendering or significant portions of the application. So to some extent the chrome of the browser is wrapped within an application. Although iTunes isn't a web-browser many users experience the music purchasing process as if it was just a web-browser. Similarly Outlook uses a web-browser component to render the body of the HTML message and sometimes UI elements.

As the worlds of browsers and web-applications merge we will see two trends.

  1. There will be more web-browsers that are designed and released as special purpose applications
  2. You will see more functionality from a web-application that was previously only possible from a traditional application.

For the generic browser (Firefox & IE) this means that the tools and metaphors found within these browsers needs to be extensible as a model so that new applications that use the browser as a foundation don't have to re-invent the wheel.

Both Firefox and IE release components to create applications (XULRunner and MSHTML) each of these packages the rendering components of the browser make it easy to re-use the rendering parts. Many companies are already doing this and there are already music players, contact managers, and large applications built using the web-browser interface from a client perspective.

From the web-side we will see the number of things that a web-site can do expand to encompass many of the things that are traditionally thought of as client tools. Adobe Flash has already been pushing this boundary and Java has been doing the same allowing web-developers to build more and more complete tools right within the browser.

The mix of client and server spaces means that it'll be harder to tell where the data actually lives. A good example of this is Google Desktop. This application ties in neatly with the existing Google website functionality allowing you to search for things both on the desktop and on the web. The line is blurred and it's not always clear when you're within the web-space.

The same approach could be used by many other web-properties. Some examples:
- Flickr - upload photos and view photos in a seamless experience from desktop to web
- Plaxo/LinkedIn - synchronize with Outlook but keep the experience online
- Yahoo Maps - offline and online driving directions
- Etc Etc.

The traditional chrome of the browser will continue to add features and functions around HTML but at it's core this framework will stay similar to what it has always been. The big Aha moment will happen when browser makers decide to focus on making it easy to create great applications and not just websites. Once this happens more people will realize that HTML, CSS and Javascript is an awful and imprecise way to develop software.

Up next. Why CSS Sucks...

This post is licensed under CC BY 4.0 by the author.