On The Limitations Of Notes On The Web

• Some context
• On The Limitations Of Notes/Domino On The Web

In the week after Lotus announces lots of innovation in the forthcoming version of Lotus Notes, with lots of great screenshots and undoubted enhancements, it may seem weird to post a short article I had written a few weeks ago on the past limitations of said product in my internal IBM blog. I do this because I've been taking a historian of science's approach to my writing on technology and its effects. I am always interested in how organizations work and how they make decisions. And a certain amount of dirty laundry airing is healthy if only to pat ourselves on the back to show that now we have learnt our lessons and that there is a lot of introspection and thought in the company. Also my focus is not on the Notes client which has always sold itself, but on rather the web interfaces that product has had since the advent of Domino, its first embrace of the web. As you may know I am an unabashed believer in the web as the ubiquitous client. This piece should give some context to these three slides from my recent REST presentation. They weren't quite a twisting of the dagger but more a challenge to the development organization. I believe there's Joy in Repetition and with a hip-hop sensibility remix myself constantly. So here's the original version before the sample.

On The Limitations Of Notes/Domino On The Web

Joe Turic and others are pondering Lotus Notes vrs Gmail and coming down in favour of the latter.

The complaints are about "Why is the email program that we use internally so limited?" and some of it has to do with storage quotas and the fact that we have very low ones (even as the platform handles 49 GB mailboxes just fine as Ed Brill keeps pointing out when comparing it to Microsoft Outlook). Most of the reason for this hence is not technical but rather I suspect a hint about the direction of email retention policy.

Later David Crumpton asks "Does Notes offer a Webmail interface?"

And of course it does, and it even has two, the regular webmail interface and iNotes, the prettier dhtml version which should give a snappier performance with lower latency for the user. A third way of getting your notes mail in a browser is through a portlet in WebSphere Portal.

The question is, why did these web interfaces not get widely adopted?

Let's start with the question of investment.

1. Investment and Adoption

Plainly put, not everyone at IBM has bought into the web, html and http.

I would count Lotus/IBM's efforts over the past 7 years as half-hearted although now we are supposedly hardcore about the web, Linux and open source in general. The thing to take away is that, at the point that judicious investment could have been made, and leadership in thought, if not in software products, was possible, we blinked.

IBM does middleware and services and moves slowly due to a sense of innate conservatism. I think this is fair, there are parts of IBM that are bleeding edge and one has to get buy-in before the rest of the elephant moves. As someone who was advocating the web almost from the beginning, it has been a long road to convince others to buy-in. The fact that we are now moving (and quickly) is great but I think it is cause for rueing missed opportunities.

2. Innefficient IT structure at IBM

Jim Gray's Distributed Computing Economics (pdf) makes a devastating case for the relative innefficiency of many in the industry that haven't embraced the web style.

"Megaservices like Yahoo!, Google, and Hotmail have relatively low operations staff costs. These megaservices have discovered ways to deliver content for less that the milli-dollar that advertising will fund. For example, in 2002 Google had an operations staff of 25 who managed its two petabyte (2^15 bytes) database and 10,000 servers spread across several sites.

Hotmail and Yahoo! cite similar numbers - small staffs manage ~300 TB of storage and more than ten thousand servers."

Up until 2000, I believe the operational staff at Yahoo was 8 and included the founder Jerry Yang.

Google has embraced redundancy and written software to work around human fallibility and hardware reliability. Google File System is not too shabby, if may say so. We have efforts in the same arena whether it is the Grid and autonomic computing work and say the move to VOIP but are we eating that dogfood?

Are we prepared to change our corporate structure and have profits come more from well-designed and usable software as opposed to consultantware? Are we prepared to eat our babies and make products that have much lower operational costs?

Tim Bray had this to say $46,213,000,000.00

I looked up the answer to the question: What is IBM's consulting revenue? In 2004, IBM's gross revenue was $96B, of which $46B was Global Services, i.e. consulting. I see that basically as testimony to how our profession, the IT profession, has failed our customers. Nothing against IBM; in fact, as solution-providers go, my experience is that IBM GS is pretty good. But if you see IBM as a microcosm of the industry, it shouldn't cost $46B in consulting to deploy $50B worth of technology. It's not going to be easy to get there, and it's going to take a long time, but we just have to focus on making things simpler.

Now that Godfather Bray is at Sun, perhaps there's a little pleasure in tweaking us. But the question still remains. Have we bought into Radical Simplification?

3. Technology Adoption Takes Time

It takes time for the effects of technology to be felt and for people to get comfortable with the web. We have now had 10 years of Moore's Law in the Datacenter and so we have examples and success stories to pick from. It was a more uncertain world 5-10 years ago and perhaps as a corporation we were hedging our bets. When IBM moves it's a sign that something is ready to take off.

4. Fragility of the browser platform

One answer is that usability was a problem in webmail interfaces that are used daily. In the browser world 5-7 years ago, you had to handle that beast called Netscape 4.7 which meant that it was a case of lowest common denominator in the user interface and frequent browser round trips (read poor user interaction experience due to latency). It was controversial when iNotes was developed and proclaimed that it only supported MS Internet Explorer 5.0 and above only. The product manager who managed to get this dispensation approved deserves to be elevated to the highest levels. Many other managers didn't even bother fighting that battle. I'll hazard that even though IBM could have written something like GMail 7 years ago (and I certainly had a framework from K-station that would have made it possible with some work) it would have been a tough sell internally.

I've written about what was possible back then On Rich Web applications, AlphaBlox and Oddpost and On Gmail and DHTML architecture again

5. Transparency and Visibility

Joel Spolksy says that "it is easier to write code than to read code". This is what the Not Invented Here attitude betrays. We didn't have anything like community source where others might discover and find out about components that have solved similar problems.

(sidenote: when one asks about spending time to document one's component, one is often told that it is not mature enough, that we'd have to spend time supporting new users, we can't afford to slow down to support the one current users etc. There's a tendancy to keep everything close to our chests. Even if others will be able to help and flesh out flaws in our designs, it is thought that exposure to inchoate thinking will be a fatal flaw. This is a mindset that has to be overcome and on this, I am not so sure that it will happen, certainly I appear to me a lone voice in my parts of the wood)

See also Why Specs matter and the Law of Leaky Abstractions

Back to the subject of web interfaces for Notes... No one really invested in making great browser voodoo happen even though we had lots of great frameworks internally. Indeed I still see people grapple with problems that I have fixed before and keep digging up my old code to point them to. Ideally I would have been able to start an incubator at some site and others would have discovered it. Instead everyone is re-writing the same code all over. We haven't codified best practices or if we have, we haven't publicised them sufficiently.

6. Braindead "corporate standards"

Braindead "corporate standards" are another aspect of the problem. Back in 1999 when iNotes was just about usable and we were developing the Notes portlet for Lotus K-station (and subsequently WebSphere Portal), we were told that

1. It was against "corporate best practices" for the http port to be enabled on Domino servers (because it increased the load on the server). Now it seemed weird for an HTTP server like Domino not to turn on its HTTP port, but let's leave that aside.
2. If we got past that ridiculous plank, we were told that if the http port was to be enabled, that "corporate security standards" meant that it had to be SSL enabled, hence https had to be used. The idea is that the same HTTP basic authentication which we use in webmail and everywhere else in the web (other than when we're purchasing something) is too insecure for IBM mail (I've looked at my mail and perhaps only 3% should be confidential). Was it really so bad to just use good old HTTP?

We certainly paid a heavy price for this risk aversion.

• We found that using SSL made thing 3-10 times slower. The server load of processing SSL was insuperable not to mention that that it degraded performance on the wire. Hence iNotes which was already pushing the dtml envelope at that point was nigh unusable. The same concern for server load raised in the first objection was in fact exacerbated.
• As far as the portlet in K-station and WebSphere Portal went, where we were aggregating Domino's xml on a portal server and then marshalling it to the user, this was even worse because there was an extra level of indirection (mail server to portal server to the user's browser)
• On servers where HTTP was disabled, one had to use CORBA (DIIOP and again the SSL variant of this), this wasn't tuned since the DIIOP api was essentially the same as the local notes api, meaning that we couldn't do coarse-grained calls, and instead had to call many apis in a row to get the data that one http request would have obtained.

Now of course we worked around all of these obstacles and made the best of things, lots of people toiled to get performance fairly reasonable (the CORBA api is now (slightly) more coarse-grained, we developed Collaboration Services for Portal so that others could reuse our code and hard-learnt lessons - now the most downloaded aspect of WebSphere Portal etc), but our efforts were hobbled in many ways. We certainly could have had more things going our way.

Summing up, first impressions matter, just ask Malcolm Gladwell (Blink)...

I f the pilot deployments of the various webmail interfaces internally had been reasonable (instead of awful experiences for the executives and other audiences who tried them), we would have been able to get more buy-in, more investment and with a bit of luck might have made comparable interfaces to the snappy Gmail that not only us but also our users and customers would have loved.

It is true that many things had to go right for this vision to have transpired but let's admit that we shot ourselves in the proverbial foot and also acknowledge that it was a failure of imagination and ultimately a failure of technical leadership.

Looking at today's opportunities and the various directions in which Lotus/IBM can go in, I only hope that we don't Get on the wrong Bus this time.

File under: technology, software, web, Lotus, notes, IBM, history, strategy, organizations, adoption, decisions, iNotes, K-station, WebSphere, portal, history, toli

Calling Things By Their Names

So I heard that sanity has returned to these parts. ^[1]

Our marketing folks are now going to call Lotus QuickPlace, QuickPlace instead of whatever bland and insipid name that had been previously mandated. IBM Lotus Team-Workplace-something or-the-other?

Similarly Sametime will now be called Sametime instead of "IBM Lotus Instant Messaging and Web Conferencing". For a while the Lotus in that designation had been deprecated.

This probably portends that our marketing teams now better understand how to sell the Lotus portfolio. A few years ago, the perception from the trenches where I live was that there was a rush away from the land of Lotus simply because (in my estimation) it wasn't understood or didn't mesh well with the compensation structure of our sales teams. Presumably we've adjusted and now understand what these products are capable of instead of dismissing them out of hand.

Now when belts tighten in the IT industry (and right now, it is a deep retrenchment), people fall back on things that work, whether it is the glue, spackle or wrenches that I keep referencing. And much in the Lotus portfolio works even if it isn't pretty sometimes. And it works especially in the SMB space that is in the Long Tail of software. See our recent acquisitions of more Glue Layer People or even my recent hand-waving thoughts on Lotus Notes:

"For those unfamiliar with Notes/Domino, my handwaving elevator pitch is that it is a platform essentially based on the fundamental insight that a huge class of applications can be built based on just a few compositional building blocks: Forms, Views and a standard file format, the note in Notes terms. The brouhahas made about messaging, security, directory services, and all that paraphernalia that marketing people throw about when they pitch the platform to you are all syntactic sugar around the core competency of Forms and Views and the client and server processes that can manage them. A whole cottage industry of business partners are doing very fine thank you building custom and evolvable applications for businesses, small and large, everywhere. The fact that email can be construed as a forms application is just a side benefit and detracts from the real focus of the platform. This is much misunderstood by people whose only encounter with Notes is as a Mail client. It's really just a forms and view app for people and processes. Incidentally this same platform is most likely what is funding my current work and much of the IBM Software Group, even as resources are spent on other "sanctioned" and more "strategic" approaches. C'est la vie."

So that's the good news.

The not so good news:

Coincidentally the [redacted] domain was removed from the internal dns without notice sometime in the last 2 weeks. I was wondering for a few days why I coudn't couldn't post to [redacted product] or vnc into my development servers from home. I thought it was a temporary flaw and added temporary entries to my hosts file. Of course I eventually realized that nothing in the internal [redacted] hierarchy would ever resolve again that this was part of the reason why [redacted product] moved away from [redacted domain]to its current location at [redacted new location]

Some of us who had to jump through hoops to get static ip addresses like [redacted] were a little disgruntled for a good 15 minutes. Mr Feinberg even brought Godwin's law into the mix albeit with a smiley at the end of that invocation.

I guess it was approriate that the hard drive for that twilight zone machine died 2 days later. Cosmic justice or Sign of the times. These are strange days...

Now this was probably just a case of run-of-the-mill miscommunication, but let's remember that simple things like naming bring out the tribal instinct in people with sometimes shocking reactions... A lot of goodwill could well be lost.

Take for example the time 5 years ago when it was not announced that Lotus Development Corporation had been deincorporated and a good 7,000 people suddenly received payslips from the IBM corporation saying that they had received only their thousand or so dollars year-to-date (and it was mid-year). Indeed it was only months later, after prompting by an atypically tough question in an Lotus all hands meeting and seeing the quite hurt and vociferous articulation of pent-up feeling that the question belied that this was acknowledged in a subsequent prickly corporate message. Perhaps we were being babies (after all we were still getting paid), why should we care about trivial things like the name on our paycheck? I didn't attend said meeting but I caught the fallout since I just became "reverse-mentor" to [redacted executive] and had to explain why such things would matter to us "[redacted] folks"...

The identity of a community is to be found in the most unlikely of things. The things that draw people together to form a cohesive whole are not the explicit things that one thinks, it's not a kind of warlike territoriality or dedication to some mission statement or other, it is rather in small insignificant items that the tribal instinct is articulated.

People will rally round the most surprising items (Elian Gonzalez, OJ Simpson, Teri Schiavo) and they quickly become litmus tests. Think of some of the most intractable political conflicts (say Serbia/Croatia/Bosnia or and here I hesitate, I wonder who else will have an Israel/Palestine category on Blogcentral) and wonder whether the political, religious or economic arguments were really the cause of the conflict or if there weren't instead some more mundane hurt feelings that then blossomed into what we have seen and subsequently rationalized by opportunist political or religious hacks.

Or take this example form my part of the woods: for the past 9 years, Northern Ghana has been in turmoil because of an argument at a market stall over a chicken or guinea fowl (the historians will have to figure this out at some point). Two ethnic groups, the Dagbons and the Kokonbas who have lived peacefully together for centuries are now in open dispute. Many, many lives have been lost, and a huge amount of money, goodwill, diplomacy, cajoling and outright bribing has had to to done to try to cool things down and to get that part of the country to begin to contribute again to the rest of the community. This in a place that can ill afford such distractions. Now in my analogy, the guinea fowl is the stand-in for the name or for a dns entry.

All this to say that when nurturing communities, it is best to keep such sensitivities in mind and call things by their names. If not all those Sensational Fruity Delights might come home to roost.

Editors note: I posted this piece on May 18 on my internal blog but now that the information is no longer a rumour but has received confirmation, I decided to remove the embargo since it speaks to the tribal instinct in communities, something that interests me as an anthropologist of social software

File under: language, naming, communities, tribes, patterns, best practices, software, history, strategy, Lotus, quickplace, sametime, notes, IBM, web, conflict, israel, palestine, Ghana, Dagbon, Kokonba, africa, chicken, Guinea fowl, anthropology, sociology, social software, technology, toli

On XForms, XPath, CSS, Brevity, Syntax And More

The always interesting Mark Birbeck of formsPlayer has a nice article up on his blog.

Ostensibly it's about "CSS, the XForms Dependency Engine, and 'Dynamic Infosets'", and he starts out by asking why there are 2 main languages (CSS and XPath) for selecting and addressing nodes within a DOM. It's a good question, and one that many have asked before. The piece is probably the definitive consideration of the question and he's a great guide, walking us through all the issues involved.

What is more interesting to me is the wider point that he goes on to make as he lurches into a very useful discussion of how we design languages and layer and model our systems. Almost in passing he addresses an issue I find most fascinating which boils down to importance of ease of authoring and syntax in technology.

The mental makeup of human beings means that brevity matters and "intuitiveness" becomes a concern. As an example, so long as the length of phone numbers was low, they were easily memorable, these days however, with 10+ digit dialing, we rely on Caller Id and programming numbers into our phones. Thus our cognitive faculties and our short-term powers of recall come into question. Being able to control the nicknames and identifiers we use in our buddy lists is a very significant factor in the spread of instant messaging and now applications like Skype. Identifiers matter significantly in this respect. The simplicity of a URI as a key, and memorable tenet, of the web architecture is a similar case in point.

From another angle on the issue, consider that not everyone can tilt their heads enough to handle the parentheses of a typical Lisp program. Most programmers can, on the whole, and some, like the Paul Grahams of the world, even wear it as a badge of honour. Of course a good computer science program should expose budding engineers to this way of thinking and many do. But these, like the Smalltalk gurus and others, are sadly outliers in the software landscape. I would hazard here that the largest impediment to the widespread adoption of the elegant programming model of Lisp is not that something like recursion is difficult to understand but rather the dissonance that the proliferation of parentheses can cause when Jane Programmer scans a listing in an editor. Vacant stares and cognitive overload ensues.

Marc Andreessen will be remembered for many things; amongst others: Mosaic, Netscape, the AOL merger, a little dotcom hubris some might say, but simply youthful exuberance I would say, evidence in the flesh of what a monopoly like Microsoft can do when provoked, and a pointer, along with Jim Clark, to the role of gravity in deflating bubbles ala Great Crash). Historians will point to all that and more.

For me though, his choice of the syntax for the image is his most lasting contribution to technology and to mankind in general. Others argued otherwise at the time and would have foisted semantic doodles on us. The "View Source" impulse that has led directly to the success of the web, that great conversational engine, would have been stymied by much head-scratching by the eveyrday people who created many a homepage circa 1995-1999. Those much mocked homepages were wonderful assertions of identity, and the lowered barriers to entry enabled many people to land their flag on this here internet where they, their friends, parents and children now live, shop and commune. If he ever receives an honourary knighthood from King Charles, his coat of arms should read

<a href="http://netscape.com">Mozilla Hyperlink Andresson</a>

It is the succint expression of the ethos of simplicity in human history.

In this vein, I was perplexed that in XPath 1.0, it is better, or rather less ambiguous, to write true() rather than true. In other words, it is recommended or even required that we treat booleans as functions and not as literals. Indeed everything is a function and as we know functions need parentheses to indicate their arguments. This always trips me up and maybe this is no longer the case in XPath 2.0. Who knows? I certainly haven't cared to look. What is true is that the cognitive impedance this caused me on my first date with the language will forever taint it in my eyes even though I have daily dealings with it.

If you had to say huh? when you did your first view source of a web page, would you have gone with that newfangled web thing or would you have written it off as one of those overly complicated buzzwords that you would look at later "when you had more time"? First impressions and snap judgments (ala Blink) count surprisingly much in these things.

One of the things that I keep thinking we need, and that I hope someone with an itch will build, is a nice XPath expression editor, a component that parses XPath and walks you through the processes of adding conditions and formulating expressions. Maybe a wizard or something, with selectors for picking the various kinds of things that are typical when building forms applications e.g. this field should be less than the value from this other field. A component that would let you add a library of custom XPath functions that could implement additional rules. Each of these libraries would be able to specify their editors but most could just be simple drop-down lists. It's not a big thing to do and you can sketch out a nice design for such a component and knock it out over a weekend. Make it open source it and be done with it.

Still, my focusing on the critical necessity of such a component is simply a recognition that hand-authoring XPath can quickly turn into a nightmare of missed parentheses, predicates and selectors. It is true that authoring in XPath doesn't require as much head scratching as say XSLT, in which context I first encountered the language, and which mere mortals like me will never understand even as I used to write in Lisp. But it is something that raises the bar quite high for the average author. In contrast there is something strangely satisfying about editing a style sheet (or maybe it's just that I've grown accustomed to that over the years). Something like this I expect is what lies behind the impulse for Web Forms 2.0, and the WHATWG, a pragmatism borne of weighing programmers' familiarity with scripting languages and a tenacious devotion to backward compatibility.

More generally though, the issue is that getting general users to author structured content is a big problem, indeed it is a nigh insoluble issue. And all the software that we produce cares very much about structure. The wonder of the spread of HTML and XML is that, ever since Berners-Lee, Bray and others unleashed their projects on us, human beings have adapted to angle brackets, < >, and now don't see them as much ado about anything. The same thing goes with CSS, the tradeoff that was made for syntax is now bearing fruits.

In the past, I've had to deal with writing a number of applications that have had things like 60,000 lines of Javascript. The messy reality is that of dealing with things like focus, issues of scope in browsers, the power and contradictory complications of late-binding scripting languages, the earlier lack of powerful debuggers and Dom inspectors, the legacy of box-model quirks as well as the powerful notion of stitching together user interfaces by leveraging the incremental rendering and multi-threaded downloading that is the basis for the hypermedia browser. All this can be done, you can have even page editors and rich spreadsheet and presentation engines in Javascript. I've written about the heroism of those who write and maintain such things. Google (Suggest, Gmail, Maps and more), Yahoo/Oddpost, IBM, and many others have competitive edges because they have developers with the skillset and more importantly the insane programming discipline required to crank out the composable browser voodoo that causes much serendipity for end users. What however about the Long Tail of Application Authoring on the web? That's what VB and other environments have catered to on desktop clients. The endpoint in all of this is when a team lead or department head can compose an application for their local concerns without much (or preferably without any) handholding from the IT departments, if indeed they have one. People just want to be able to handle their little processes and get on with things. This is what web publishing and especially blogs and wikis have done by lowering the bar for authoring with the attendant benefits in communication and global conversation.

Thus, one of the main questions that will determine the adoption (or lack thereof) of XForms or Web Forms and their ilk is the perplexing matter of whether human beings in the next decade will become as inured to writing true() in an expression as they have become with the angle brackets of html and xml. Put a different way, it could well be something completely orthoganal to the merits of the underlying technology that will determine the outcome: it will be the appearance of the kind of code you see when you do View Source on the first cool forms application you encounter. I'm suggesting then that the language acquisition cost and what I'm terming the cognitive impedance in the average human being of parentheses for functions, and forward slashes for selectors will determine the adoption rates of XForms technology.

I've been working on Forms, and XForms in particular, for the past couple of years. I happen to think that XForms has gotten the abstraction and decompostion right and that it is a great means for lowering the skillset required to model and author the kind of form-based applications that are the glue of the many custom processes of the Long Tail of Software. Indeed my only nitpick is that the specification doesn't include upfront the equivalent of the JavaScript confirm function as a concession to usablity so that you can easily put up a message for the user so that they can decide whether they "are really sure that they want to submit their form" or not. It can be done, I've been told, but it isn't emblazoned in the specification. By being too general (they'd argue that something like this needs to consider mutiple modalities and the like), they are missing out on something interaction designers would immediately point at as a shortcoming. Again, first impressions count.

I see a bright future in which that much maligned Forms "programming model" that is at the core of the Lotus Notes platform could be brought to the web platform leveraging the native primitives of the Web style (hypermedia, uris, linking etc). XForms is singularly well suited to do this. For those unfamiliar with Notes/Domino, my handwaving elevator pitch is that it is a platform essentially founded on the fundamental insight that a huge class of applications can be built based on just a few compositional building blocks: Forms, Views a standard file format, the note in Notes terms. The brouhahas made about messaging, security, directory services, and all that paraphernalia that marketing people throw about when they pitch the platform to you are all syntactic sugar around the core competency of Forms and Views and the client and server processes that can manage them. A whole cottage industry of business partners are doing very fine thank you building custom and evolvable applications for businesses, small and large, everywhere. The fact that email can be construed as a forms application is just a side benefit and detracts from the real focus of the platform. This is much misunderstood by people whose only encounter with Notes is as a Mail client. It's really just a forms and view app for people and processes. Incidentally this same platform is most likely what is funding my current work and much of the IBM Software Group, even as resources are spent on other "sanctioned" and more "strategic" approaches. C'est la vie.

One thing I've noticed is that many people seem to want to ignore the lessons learned from the Notes world over the past 15 years and and behave as if the forms space is terra incognita - a brave new world indeed. On the contrary, the Forms problem and the wider Process problem is nothing new. These are things that have been with us almost from the time that societies became organized and larger communities formed as Barry Briggs has pointed out. Whenever I plumb those depths however, I am reminded of the notion that Joel Spolksy so eloquently coined that in software it it easier to write code than to read code. In software terms, 15 years is an eternity hence we are fated to reinvent and rewrite anew old software. Just look as WS-* as opposed to Corba. Sometimes I almost despair at this notion, since it bespeaks a total lack of curiousity and historical memory even with those who are sitting in the same building who have learned comprehensive lessons about the many problems of forms: evolvable schemas, metadata, annotations and the like.

Of course I'll continue to build the tools, the processors, the renderers and the infrastructure plumbing to make the forms dream an easier reality. I'd still argue that adoption will ultimately come down to whether the View Source impulse can be leveraged and whether the average Joe will get turned off by things like true() instead of true. If I were inclined to be a research type, I'd imagine a case study or paper titled something like

"The Importance Of Syntax In Technology Adoption - Historical Insights From The Trenches 1940-2005"

A more prescient Historian of Science would note that the issue of notation in mathematics is similarly a longstanding area of concern. A linguist would add insights about how different societies adapted different writing systems and the impact on the writing system on cognition and development. Anthropologists, sociologists or psychologists would have much to say in this vein.

Technologies like XSLT and XForms which are the prime users of XPath are in still in their infancy (as are some of the other takes on this problem space from Adobe and Microsoft). Despite having many implementations at its launch, XForms is still ambling towards its inflection point and I'd hazard that the majority of XForms templates and transactions are machine-generated. Fair enough perhaps. Wearing my prediction hat however, it will be very interesting to see what happens 6 months after the default installation of Firefox includes its XForms extension. We're going to see the same thing in microcosm now that Mozilla have announced that Firefox 1.1 will include SVG which has a more limited utility for mass audiences. With very little tongue in cheek, I'd wonder what contact with a massively vaster audience of form authors will do to XForms implementors. I'd lay bets on the first XForms engine that implements a "quirks mode" for their XPath evaluation engines to dealt with common patterns of mistakes in hand-authored forms. It will be a case of omitted parentheses rather than browser tag soup that will cause much fretting in mailing lists the world over. I wonder whether Peter-Paul Koch will then have to add an XForms or XPath section on his invaluable site that documents browser quirks. The litmus test will be the teenager doing a summer job in a lawyer's office who is asked to write a little forms application to help some workflow. If parentheses make their eyes glaze over, I doubt I'll be proved wrong (although I hope to be), about whether XForms would be used for that custom application. If the typical simplified wiki syntax (whatever Jotspot or SocialText are using) is more intuitive, that will be what gets used.

The other point Birbeck raises, and here the argument is much stronger, is about the tradeoffs that designers consider when it comes to seperating the processing, addressing, eventing and styling models. He speaks to an architectural truism whatever the domain in question. This is where his clarity of thought comes to light. A clarity that stems from being one of the exalted "Invited Experts" on the XForms and HTML W3C working groups, and having an innovative product that daily explores this landscape

If, for example, you started off in the mad, slapdash world that was early browser development, you might opt instead for a very pragmatic viewpoint on these issues. That's the kind of weighing that has characterized the Mozilla folks. Håkon Lie, Hixie of Opera, fall into this category even if they appear to take it to almost militant extremes at times. Still I see where they are coming from. Your take on these things is coloured by contact with the millions of end-user authors and the daily reality of tag soup.

I've only spoken with the Opera folks a couple of times and always forgot to ask them the burning question I have. How difficult is it, by the way, to add an XPath engine to a browser? I've always assumed that the real reason (as opposed to the stated reason, "we have everything we need in scripting and css") for Opera's almost visceral objection to XForms has been a concern over footprint since the same codebase is used on desktop and pervasive clients. But with the necessity of XML engines in browsers(with the now indispensable XMLHttpRequest) and Moore's law at work on your more limited clients, at what stage do protestatations about XPath (and hence XForms which is a dependency engine over and above XPath) become simply bywords for inertia? As a very conservative software engineer personally, I am similarly not inclined to jump on bandwagons just because they are in vogue. Still I'm interested in the architectural thinking that lies behind their position.

If, on the other hand, like Birbeck, you've drunk the XForms Kool-Aid, you'd be a generalist and will be inclined to see almost everything through rose-tinted glasses in terms of seperation of model from UI and from eventing and actions. You might recite MVC chapter-and-verse as you lull yourself to sleep at night, self-satisfied at your specification. The irony is that the visual effect of mere parentheses on an average teenager could cut short your sweet dreams of empire building.

Of course it's not always so cut and dry, sometimes you're just in the middle, trying to figure out which of the 45 latest buzzwords you're expected to spout fluently tomorrow to get a raise that beats inflation - or even a promotion. Or maybe you're just trying to code for food and get some real work done by helping a doctor's assistant keep track of HMO paperwork more efficiently or something of that sort. Oh well. Food for thought in any case.

Cross-posted at the Inside Lotus weblog.

File under: technology, web, xforms, forms, xpath, css, language, design, architecture, comprehension, Lotus, IBM, notes, standards, adoption, html, xml, xform, toli,