This work is licensed under a Creative Commons License.
Tangled in the Threads
Jon Udell, April 12, 2000Web UI on the cusp of change
Core standards matter enormously. So do core components.In my March 6th column I talked about Mozilla's XUL and MSIE's DHTML, noted that the era of the impoverished HTML user interface won't last forever, and wondered how we'll move forward.
One option I discovered is Sash, from the infinitely-inventive folks at IBM's AlphaWorks division. In a 1.9MB download, for Windows only, Sash delivers a toolkit that supports "Weblications" written in "SashScript" (enhanced JavaScript).
This isn't cross-browser DHTML, but rather, outside-the-browser DHTML. The runtime is based on the MS browser control.
I installed the Sash runtime, and a couple of weblications, and then went looking around in the Sash directory to see what the code was like. The whole thing has a very Windows-like flavor, right down to the use of GUIDs -- for example, the weblication called Buzzword Bingo is named {A8C6DC15-9852-11D3-BC6C-0004AC77F55A}. Linux and Palm versions of Sash are in the works, says the Sash FAQ, but at the moment, it's a creature of the Windows environment.
Several newsgroup participants noted other options.
Martijn Pieters:
XUL was never intended to go cross-browser. We use XUL as a GUI framework, also taking advantage of the networking framework Mozilla offers. It basically is a new development platform for web centric apps.
Maybe the XForms group of the HTML working group at W3C will lead us there [to an enriched cross-browser UI methodology]:
http://www.w3.org/MarkUp/Forms/But, it is also a W3C group, so don't expect a solution too soon.
Steven Marcus pointed to another AlphaWorks invention, DirectDOM:
<quote> DirectDom in its simplest form is about writing Weblets which are Java client programs that use the client user interface facilities of a 5th generation browser or other DOM viewer (such as SVG) to render and control its interface via standard W3C interfaces found in DOM Level 1, DOM Level 2, and HTML 4.0. </quote>
So, instead of restricted java applets running inside a square of a page, you have java programs that can manipulate the browser.
Essentially, instead of having a java applet control a rectangle on your web page, you have java "weblets" that control the entire web page via the DOM. This becomes even more interesting when you add SVG support as they have.
Steven noted that growing interest in the ASP (application service provider) model is one of the factors driving more emphasis on richer browser GUIs. I agree. A recent report on script-language popularity, which was compiled by scanning the Web for words like Perl, PHP, Python, and ASP, showed that in early 2000 ASP was up sharply. Of course, this wasn't ASP in the Active Server Pages sense, but in the Application Service Provider sense!
Although Steven agreed that we need cross-browser standards, he wondered whether ASPs will not simply mandate the use of specific browsers. Thus, the ASP version of MS Office might only work with IE, and AOL services might only work with Mozilla.
Is fragmentation inevitable?
Some folks are already resigned to the idea that cross-browser portability is a utopian dream.
Peter Hess:
The company I work for has been developing a web-based application for the hazardous waste processing and environmental management industry. The initial plan three years ago was to make it entirely browser-based, presenting the interface through a browser and doing all the processing on our server. We quickly discovered that the browser didn't give us any decent GUI tools and that trying to support both the Netscape and IE platforms as they diverged was a nightmare.
What we ended up doing was to code a client application that handled the UI and data presentation while implementing most of the business logic and the database on our servers. That was a hard decision to make because it fundamentally altered the direction of the project. We wanted to avoid having to do a client side app install and then have to provide tech support for that client installation as well as distribution and upgrade services. On the other hand, there was no possible way to do the UI in the browser that gave us:
- A rich GUI toolset
- Good UI performance
- No client side software installation
- Cross-browser functionality.
We decided to sacrifice item 3 and ended up with a full client/server application that relies on the browser only for initial login and app launch.
Ouch! That's a terrible sacrifice! Something's got to give. There's tremendous pent-up demand for "real" web applications that you can bookmark, rather than install. As Peter points out, vertical markets are desperate for this kind of solution. But, he sadly concludes, "cross-browser GUI utopia seems as remote as cross-platform app utopia with Java."
I agree that client-side Java hasn't caught on. I think that's because it doesn't hit the sweet spot. You need real programming skills to make an applet, whereas all sorts of people can and do create useful web services out of HTML.
But cross-browser native-GUI technology, in the form of the browser, has achieved a larger installed base than any software in history. It works. It's what everybody uses every day. And I think that's because it strikes the right balance between content-authoring and programming. What will it take to move portable cross-browser technology forward? I can hardly think of anything more vital to the future of software and the Net.
Talking with the Web Standards Project's Steve Champeon
Another response to my March 6th column came from Steve Champeon, who's with the Web Standards Project. With Steve's permission, here is some of the follow-on discussion that we've had:
Jon:
I see part of the problem being that W3C and IETF are best at defining base standards and protocols, whereas what's needed to make portable web apps take off is more in the application realm -- where historically, the definers of standards have been the likes of Apple and Microsoft.
Steve:
Perhaps. Yet, if you'll look at the role of something like the DOM, or XML, these are not application-level standards, they're more like architectural foundations for applications. And that's what MS and Netscape are botching, to one degree or another. They provide us with niceties like colored scroll bars, the document.all collection, etc. but MS hasn't managed to provide XML+CSS support or DOM 1 Core, without which cross-browser apps are impossible. Netscape's XUL is great, but it needs to come after basic support for core standards.
Our role in getting Netscape to abandon the old rendering engine in favor of Gecko is well-known. We recently commended MS for releasing the best current standards-supporting browser on the market (MacIE/5) and chided the hell out of them for continuing to release garbage on Windows (non-forwards-compatible CSS support, no DOM 1 Core, useless XML support - no CSS; and so forth). We have an impact.
Our mission hasn't changed in the two years we've been around: innovation is fine and dandy, but you don't buy fuzzy dice for a car with no drive train. Focus on the fundamentals so we can enter the next generation of the Web, instead of spending so much time and money on glitter and schmaltz.
Jon:
Of course the SGML community, focusing on fundamentals, achieved very little mindshare. HTML struck the right note, and was massively adopted. I keep asking myself: what is the next "right note"? Part of the answer has to be some way of retaining the simplicity and mass appeal of HTML, while supporting more of the richness of the conventional GUI.
XUL (for better and worse) is an example of the kind of app-level approach that could garner the kind of mass appeal that HTML did. It rises up out of standards and would be unthinkable without them, but it packages them into a methodology for creating a new breed of web applications. That methodology is not about making a FruityGum skin, in my view, it's about richer Web UI components and ways of combining them.
Steve:
True. But XUL is a Netscape-only technology, just as behaviors are an MS only technology. I want a core cross-browser/platform foundation, so we can all use myProprietaryXMLFunThing, provided I write it in DOM Core and XML and CSS and Javascript.
Jon:
I want that foundation to exist too. But massive adoption does matter, enormously, and what drives that is people who are able to see what kind of house will be built on the foundation.
You cannot underestimate the impact of a site like www.halfbrain.com where people can see a real spreadsheet delivered through the web.
The core standards are necessary, but not sufficient, for those "real" applications. I'm convinced browsers need a richer set of standard, hardwired widgets that go beyond HTML 3.2's widget set, and deliver what's been long standard in the GUI realm. Things like menus, tree controls and grid controls. Look at how much mileage Zope gets out of its tree tag. This should just be a native widget! Of course, these things would be DOM-wired and scriptable.
I think the Web Standards Project is doing a terrific service. I support their work, and I'm displaying one of their banners on my home page. In another context, Tim O'Reilly said that Amazon.com is "pissing in the well" by asserting its 1-click patent. That's a great metaphor, and it applies equally to those who would fragment the consensus that has so far enabled the browser to function as a universal client.
A modest proposal
So what to do? Here's a specific proposal: revise standard HTML to include the bread-and-butter widgetry that powers many GUI apps, which widgetry could then be implemented natively in any browser, however that browser chose to, wired standardly to the DOM, which is scriptable in the standard ways DOMs can be scripted. I'm not asking for wild stuff. Just 15-year-old things like menus, trees, grids.
Franck Arnaud::
Where do you stop in the functionality of a grid? It can range from something very limited to all of Office's functionality. It's not uncommon for people who develop a GUI using ActiveX controls to find that third-party controls don't suffice, so it's necessary to write your own.
Very true. As I see it, HTML should define base components and create a lowest common denominator that goes beyond today's rather pathetic LCD. The key point would be to get the new LCD as universally deployed as the current one, as soon as possible.
Of course, enhanced components would be needed. These could come in a variety of flavors: compiled plugins, Java components, scripted components. You want these kinds of things to compete with one another for the honor of defining new base-level functionality that could get rolled into the core standard. But they should all support the current core standard, so that an app written to the LCD can assume basic tree, grid, and menu functionality.
You can write a page that requires FancyGridControl v1.12 if you like. A user might or might not bother to install that control. But FancyGridControl and SillyGridControl and FruityGumGridControl should all deliver at least the behavior of the standard HTML BasicGridControl, when handed markup written in terms of BasicGridControl.
Could this work? Why or why not? I think this discussion is going to continue to heat up over the next few months. Drop by and let us know what you think.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads
This work is licensed under a
Creative Commons License.