For the life of me I could not make out what directions Peter Coffee was recommending that browsers go in his story on Browser Vendors Monkeying Around. So let me propose two directions for the browser. One I call the Portal browser and the other I call the Browser-as-component.
Portal Browser
The Portal browser is really designed with the end user in mind. It is easily customizable and can present many faces to the end users. The Portal browser is remarkably close to being delivered now. Operas browser has the key capabilities already. Users can open up multiple and tilable windows in Opera. Some of those windows can have local browser applications. Now all that is needed to create the portal browser are three changes:
1)allow the user to start up any desktop application in a tilable browser window. Some IE add-on browsers can do this already. Note the requirement for tilable and easily resizable windows;
2)allow users to save the settings of all the tiled windows both for size, position and content; then allow the user to recall that browser workspace setting at start-up or anytime during a session. In effect your browser becomes a portal on the desktop for some grouping of tasks;
3)add to the DOM and scripting for browsers the appropriate API standards update to make these manual actions programmable in JavaScript (or any other DOM cognizant scripting language). This would allow central web adminsitrators the ability to setup some organizational portal settings easily in addition to the ones that users setup for themselves.
The idea behind the Portal browser is to make it easy for users to configure their desktops in repeatable ways that can be easily closed and then re-opened. Portals and digital dashboards are already one of the fastest growing UI segments – the Portal browser would make it available to end users.
The Components-as-Browser
The Browser-as-component already exists in a number of applications. IE has an ActiveX windowing componnent that is available in Visual Studio. Borland has been delivering a browser component in Delphi for at least 4 or 5 versions. Macromedias Contribute is but one example of software that contains an active, user configurable and activated Browser window that is one vital part of its total application solution. Mozillas XUL application framework delivers on this vision of the Browser-as-component and some major ERP and other application vendors are starting to adopt it. To an extent, Laszlos LZX and Macromedias MXML deliver on this vision as Browser-as-component but they must be embedded in a browser to get “the connection” to the Web.
Microsofts next OS, Longhorn with Avalon and Indigo, takes the Browser-as-component to the next logical step – make it a part of the operating system but in no ordinary way. IE is already a one OS browser; so why not build it right into the operating system in unique but also dependent ways. Make the Browser-as-component dependent on key Windows server applications like Content Management or SharePoint Portal servers for key operations. Perhaps Windows Server 2006 and Exchange 2006 can provide some essential security/identity and collaboration services. Tie the new Browser-as-component into the new Office 2006 in tightly coupled ways. This way, though the Microsoft browser may go cross platform for data and services, it will never aid and abet “outsourcing” of Microsoft desktop or browser based applications to rival desktop platforms or other devices (mobile, handheld, etc).
Now it remains to be seen whether Windows Longhorn will allow other browsers to run as first class citizens in the Longhorn environ. Microsoft is famous not for ignoring standards but adopting just enough so that they can distort them for their own purposes. It remains to be seen how much large users, the market, will bear.
As one might presume, this party prefers the Portal-browser over the Browser-as-component model. The Browser-as-component model allows for too much mischief by vendors – and not just Microsoft. We have already discussed how badly the database vendors mucked up the SQL standard – through no fault of their own, of course. But also we like the Portal Browser because it continues to invest in the end user as the primary arbitrer of what the browser should do. Part of the reason the browser has a big lead in the User interface battle with desktop applications is because the browser is easier to understand, easier to use, and easier to remember how to use than most applications – and the desktop OS for that matter.
(c)JBSurveyer