The browsers of tomorrow will likely include some type of editorial guidance, as this example of a child-oriented browser at TechCrunch today shows.
During The First Browser Wars, Netscape and Microsoft competed on adding similar new features in incompatible implementations, and in the rush did not think through the security implications. This pattern is recurring in The Second Browser Wars today, with the current “HTML5″ committee focusing on RIA specs, and it’s likely that many of the brandname browsers of tomorrow will be much larger codebases, with more functionality which will inevitably interact in unexpected ways.
But a different approach is to tailor the browser to the needs of the audience, rather than to the needs of the browser vendors. Here a group optimizes a user-experience for children using AIR. As TechCrunch describes:
“KIDO’Z is a pretty nifty Adobe AIR-powered desktop browser app that gives kids a safe and fun environment to play games, watch videos and/or visit pre-approved websites. When you first install the AIR app as a parent, you can configure the age and gender of your offspring as well as your location and preferred language… All content only shows up when a KIDO’Z team member approved the content beforehand, and to add more layers of security all scripts, file downloads, pop-ups and any other attempts that could lead to content which has not been approved, are thoroughly blocked. To use the app, kids won’t need to know how to read or write since obviously the whole UI is quite visual of nature, and very colorful to boot.”
The application is tailored to the needs of the audience. HTML should serve children well… children should not be forced to have adult sensibilities before using a browser. One editorial approach will not suffice for all, obviously, and there are many possible “trusted voices” which can help guide the web-browsing experience.
I think the hypertext specification should be clear and easy to implement. But that now conflicts with corporate desires to control each layer of the consumer experience, and to lock-in use of their own runtime engines. AIR provides a way to fight back, by using HTML or SWF to customize a particular user experience atop a standard Webkit implementation.
AIR includes a browser, but is not itself a browser… you can think of it as a web browser toolkit. Anyone can now make tools for surfing the web more efficiently, more appropriately. No need to all wear the same uniform… browsers can now be customized for the audiences they serve.