The Unloved HTML Button and Other Folktales

A long, long time ago in a far, far-away land, there lived an HTML Button.

It lived happily with its parents, Mr HTML and Mrs Form, and its siblings: the older brother Text Entry Box and younger sisters, Drop-down List and Radio Button. As a family, they didn't look like much, but they got on with things. Indeed some would say that they had been second thoughts since grand-parents, Netscape, Microsoft, Apache and Berners-Lee, preferred to fawn and monopolistically squabble over cousins, Blink and Marquee Tag, the mobile duo, Java Applet and ActiveX, and the gruesome but quietly efficient twins, CSS and JavaScript. Let's not forget the ugly outlier, the Behaviour, and that perennial favourite of old Sir Tim, Semantic Purity. Still those pragmatic matchmakers, Fielding and Andreesson got together, sacrificed a few goats on the altar of sloppy expediency and dotcom hubris respectively and got the marriage together. The good Reverend HTTP was the officiating priest. Thus they called for a great many festivities and plenty palm wine and Schnapps was consumed by the merry populace. Yahoo! and Google, they ululated as they devoured the fatted Browser calf.

The Lord looked unto them and saw that it was good. He was pleased with his creation, thus he thundered: "Let my children prosper. Go forth and multiply forthwith". The VC Angel of the Lord blessed them with a strong essence and wide child-bearing hips. Verily I say unto thee, many offspring were spawned throughout the land. This allowed Uncle Amazon and Auntie eBay to garner many an oxen, selling little e-commerce gnomes on the child labour, and great work-ethic, of these precocious, and outsourced, children. The UPS town criers beat FedEx talking drums loudly and strew countless packages in villages from Kokomlemle in the south to Bolgatanga in the north, all the way to the far corners of this Flat Earth we live on. Big Blue-suited Armonkians day-dreamt of middleware and on-demand eBusiness, Oracles everywhere hummed expensive ballads of Databases, and itch-scratching Scandinavian Viking ants from the village of Linux (they were of the GNU genus) began to colonize many a continent.

Seeing all the fun they were having, Godfather Bray and Grand Wizard Paoli spawned another cousin to add to this fertile mix: the virtuous XML. Of course you have to understand that back in the old days, before all this boom-boom stuff, Real Men could hug each other without fear of overzealous prosecution.

XML was a boy genius. As an industrious type, he was singularly prolific and many offspring were issued from his legendary nightly encounters including the incomprehensible RDF and the Siamese twins XSL and XSLT (but we all have skeletons in our closets), and those sloppy but similarly prodigious critters, RSS and Atom, who founded a land called Blogosphere and struck fear into all and sundry so unruly was their behaviour. The Ananse's web that was woven was wondrous and resplendent in its glory. Hosannas were sung and there was much myrrh and frankincense which caused much mirth and frankly increased the joy felt by all who alliteratively assembled at the proceedings.

Periodically however, people got jealous and countless trials and tribulations were launched in the direction of this happy family. Where others would turn to ashes and sackcloths, throughout they kept the faith, and never complained about the insane contortions that those two wicked aunts, Gertrude UI Designer, and the quadruple-barreled Felicia Unsatisfied-Application-Framework-Developer, made them go through. Still, with the help of those Glue Layer People, Shadrach, Meshach and Abegnego who came armed with duct tape and spanners, they persevered in the righteous way. They were kindly sorts, steadfast, humble and true to the Lord. As I start my tale, the future looked ever so bright for them.

Lest you think I have too much time on my hands or that I don't have a day job, I should preface my folktale by saying that it was actually 10 months ago in Cambridge that I started writing a few fragments for what I codenamed the Toli Technology Series. And so, dear reader, the topic of this long-mulled note is that fair and foulweather friend of ours: the unloved html button and its form family.

Now 9 or more months from conception to birth is typical for me and for most mammals even if it is a long time in the technology world, and it leaves much opportunity for others to make much the same point and vividly so. Thus I can make no claims to originality or insight. I happen however to believe in Gabriel Garcia Marquez's maxim that

"Any idea that couldn't stand a few decades of neglect is not worth anything".

My first novel is certainly pushing in that direction but that is water under the proverbial bridge.

Before I get into our tangled tale of prodigal buttons, let me begin by recounting what prompted this current jaundiced delivery...

• A case of mis-directed advocacy
• The Unloved HTML Button
• MBTA Buttons
• Flickr Buttons
• Missing Blogger Buttons
• Why Specs Matter and the Law of Leaky Abstractions
• A Hyphenated Parable
• Acela Blues
• Forms in Browsers
• Pushing Buttons

A case of mis-directed advocacy

Over the weekend, in one of my episodic eruptions, I found myself trying to knock heads together to make sure that the right lessons had been learned in the reaction to last week's release of the beta of Google's Web Accelerator (GWA).

To give some context, the GWA is simply a client-side proxy server application that can speed things up for the user by making use of Google's wonderful infrastructure. Of course Google have other reasons (read metrics) for introducing this product but there is some real innovation here (additional compression of documents, the insightful idea that only updates to documents are transferred, the so-called differential exchange, and, most of all, leverage of the scalability of Google's unparalleled and massively parallel server farm). The browsing experience for millions of people could be markedly improved especially for those on dialup if this product is widely adopted. This is plainly an opportunity for the immediacy of communication, conversation and plain social intercourse to further flourish. I won't even dwell on the likelihood of this product further lubricating promiscuous commerce throughout the land.

Thus it would seem a caching intermediary like Google's should be fair game. Caches are used everywhere in the internet and there were a lot of tradeoffs that were made in the architecture to accommodate them. HTTP bends over backwards to make possible the magic of such intermediaries. Indeed almost all the differences between the HTTP 1.0 and HTTP 1.1 specifications relate to this issue of giving visibility to intermediaries. Tim Berners-Lee's prototype was turned into the "product" we know by repeated contact with the real world.

The trouble however is that many people, almost since the beginning of our tale, have been abusing HTTP and misusing its semantics especially as regards HTML forms and their offspring. People regularly use hyperlinks, the kind that you would type in in a browser location bar, to cause side effects. This goes against the injunction in the good book that goes under the name of idempotency.

Google's web accelerator in barely a few hours exposed how widespread this abuse has been. Like an assiduous cache who had read those ancient tablets, GWA simply assumed that there would be no side effects to performing an HTTP GET on a hyperlink on a web page, it did so and tried to prefetch things intelligently. Of course since these hyperlinks were doing unsafe things, sometimes things got deleted. Now this train wreck was predicted in the wise counsel of the Reverend HTTP in his opening address and the toast that matchmaker Fielding gave at the wedding where the whole world was invited to witness. Apparently however, many of the guests were drinking too much; their calabashes runneth over with Schnapps. The Yahoo! and Google choruses were rather symptoms of their inebriated bubbly state.

That being said, I was actually surprised that some of the brightest and most inventive developers around were metaphorically caught with their pants down, dead drunk, and, even worse, that they were then protesting their good intentions and rectitude. I was therefore fulminant when I weighed in:

There is an architecture to the World Wide Web.

Truly.

Really.

I kid you not, there is an architecture to this messy thing that we live on. This architecture was worked out in blood, sweat and tears (and a lot of fun during the dot com boom) over the past 15 years in countless mailing lists, with countless dear lessons learned.

Now when you start a post in that vein, what is to follow might get a little heated. As ever, I should have been calmer and like Joe Gregorio framed that episode as a parenting lesson:

I'm sorry, I can't kiss it and make it better.

I firmly believe there are just some things that a child will only learn through experience (read pain). Many times children can just be stubborn, or choose not to believe you, and ignore your warnings. I understand this. I did this myself. No matter how many times my parents told me that the iron was hot, it wasn't until I actually touched it and burned my finger did I believe them. That feeds into my parenting strategy, if they misbehave and end up in pain, I believe that's the right time to reinforce the message, make sure the lesson is tightly coupled with the pain, that way they're less likely to forget.

Instead my discourse devolved into a case of I told you so, a kind of Old Testament view of things instead of the softer New Age stylings that are in vogue these days. Sure there was a little concern for the users that had been hurt by lost data, but there was almost no empathy for the developers who had to lose their weekends furiously reworking their applications to do the right thing especially because it appeared that they would rather persist in trying to do the wrong thing.

The sentiment behind that mini tempest-in-a-teapot however was a recognition of the fact that those who have been quietly evangelizing the web style were talking about the wrong thing and to the wrong people.

Advocacy is great on xml-dev and the various forums where the REST/SOAP debate is played out but it is missing entirely the audience that counts. We might as well ignore those RPC and "complicated framework people" even if their claims are sometimes so unbelievable. Thus I believed that my own REST intervention and the countless other inquisitions were a touch mis-directed. According to de.lici.ous, 30 people appreciated my piece; my efforts would have been best directed at the 3 million or more people out there who are simply trying to build web sites and web applications and proliferate those gnomes.

As a community, we should have been like the Web Standards Project who stuck to their guns and instead compiled a litany of examples of best current practices that everyone could have seen, understood and copied. There is no reason that developers should only now be sensitized that HTTP GET SHOULD be safe and not have side-effects.

Your first encounter with a web application or web site should have this lesson hardwired in it. The recipes that you did view source on to learn about the web (like the thousands of sites that have lifted the stylesheets from the CSS Zen garden) should have been had such practices encoded in them so that it would be second nature.

Zef Hemel (his tagline: "your daily tech snack"), who in my folksonomy is tagged with very little tongue-in-cheek as "The next Linus Torvalds" later admitted to this blindspot

But to be honest, I wasn’t so aware of the badness of using GETs for this purpose until yesterday.

All this to say that the things one thinks are obvious are often not.

The View Source imperative was crucial in how most people learned about HTML and the Web and to its widespread adoption.

As I wrote those words, I looked over to my bookshelf and saw my dogeared copy of the 1995 edition of Laura Lemay's Teach Yourself Web Publishing With HTML In A Week which should be a collector's item for all historians of science. I smote myself upside the head as I remembered how irascible young me had gotten onto this web of ours. I recalled that I first fully read the HTTP 1.1 spec in the year 2000 out of a sense of curiosity and when I saw that great dissertations were being written about the design philosophy behind it. I had heard rumours that there was much that was good in the web and like everyone had seen the daily evidence everywhere. Instinctively I had realized that some of the decisions that had been made at its formation were simply inspired and had subconsciously followed those design patterns and best practices that had been implicitly articulated. On the other hand, I had lived and written web software for 5 years with only the occasional peek at the HTTP spec to learn about things like content negotiation.

And that's the nub of the issue, who other than curmudgeons, has the time to read the HTTP spec where the importance of idempotency is prominently inscribed?

The vast majority of the world won't read long treatises. People will however copy and paste your code. Thus, in addition to good well-designed specs, we also need good samples and documentation.

Joe Gregorio's Show Me The Code tactic is the right way to go about education as is Mark Birbeck's quiet and repeated advocacy (first RSS Readers in XForms, then Google Suggest using XForms and now Google Maps using XForms). I bow down to these folks and others who are actually taking on this heavy task.

The prescient Ryan Tomayko of course was in the mix anticipating these sorts of things just weeks earlier: On HTTP Abuse

There's been a lot of good discussion around Udell's End HTTP abuse article. We need to get this figured out because it's almost embarrassing to be an advocate of standard approaches to building web applications when something as fundamental as the correct use of HTTP GET is butchered so often. Unfortunately, misuse of HTTP GET is just the tip of the iceberg. There's a whole slew of HTTP abuse going on out there (often in the form of neglect) that can be laid at the footstep of two parties: frameworks and evangelists. The frameworks suck and the evangelists aren't trying hard enough.
The small community that is coalescing around REST/HTTP should prioritize the following objectives above anything else at this point:

1. Raise awareness of what HTTP is capable of.
2. Fix the tools.

He then points the way to a more effective advocacy strategy namely

Can we take a page from their book? In my opinion, we're just as entitled to the phrase "Designing with Web Standards" as they are. We have a three legged stool too: HTTP, URIs, and XML. Except our stool is more like a three legged dog - you can get around but it is not quite optimal.

There is a lot more in that vein and it appears that there is a lot of soul searching among my fellow travelers. I would only add that there is also the problem that those lowly HTML Forms and Buttons are addressing. We can't afford to forget them in our efforts, indeed they might be more crucial than the rest.

The Unloved HTML Button

Thus I find myself turning back to that good friend of ours: the unloved html button.

It really doesn't get much love.

No one likes the standard HTML buttons and the other form elements. More precisely no one except users who are just trying to get on with things, and even they just see them as a means to ends that can range from awful bureaucratic process paperwork to buying that seductive, new-and-improved, ecommerce gizmo.

The first thing that Geoffrey UI Designer wants to do when he meets them is to change the appearance of html buttons. Designers just don't like them, they want to style them with cooler looking images or they want things to be hyperlinks instead. The stereotypical designers have come from the background of rich desktop applications where all sorts of interface excess has been possible. Also inevitably everyone wants to create "lickable" interfaces that make you drool. Not to be pejorative, but deep down every designer fancies themselves an aesthete ala Kai Krause or Steve Jobs and very few have looked to Web design patterns. Those Human Interface Guidelines of mundane standardization that made things like the Macintosh user interface much beloved by users everywhere are beside the point. Users might have liked them since after using just a few applications one would know how to use that darn computer thing without requiring expensive "training courses". But there was a sameness in the land and even Apple, prompted by that returned prodigal and effete Jobs, now breaks its own guidelines with increasing frequency.

"We want chrome! We want skins!", chanted the crowd as the unloved HTML button was dragged out for display.

As an application developer I like to get as close to the metal as I can and don't like having too many layers between me and the technology that I work with. Thus I often cuddle up in my midnight hours next to plain old HTML forms and buttons. In the land of the Long Tail of Application Authoring however, most people will use a framework to "program" their web site.

I would note that every web application framework has its own ideas about how forms and buttons should behave. Just in the past 6 months, the assortment of Three Letter Acronym frameworks that have been foisted on me (WCL, JSF and ODC) have each had their differing conceptions of how forms and buttons work. Needless to say, I've suffered mightily and all of these frameworks have caused much head-scratching. They leak mightily and that is because they are engaged in a war with our html forms and buttons.

In my weekend missive I inveighed, "read Joel Spolsky on Leaky Abstractions (more on that below). Let's not fight against the underlying architecture; let's understand what we're building on. The tradeoffs that were made in the complex system that is the web were not made without care."

When I got into the brave new world of XForms, I assumed that all of these lessons had been learned. Thus it was to my surprise that the first deviation from the XForms spec in IBM's first pass at an XForms Processor (on AlphaWorks) was a non-standard implementation of an image button trigger and a slider control. Now that processor was written as a guinea pig to provide input to the XForms 1.0 specification and indeed was an attempt to fit in with existing browsers. But some cunning UI designer or Framework Developer had gotten to them and they were trying, and failing I might add in these cases, to make more snappy UI widgetry within the confines of the native browser widgetry and infrastructure. Hmmm.

Now let's get concrete here ("You're so long-winded Koranteng. Boo. Hiss. Cut to the chase")

MBTA buttons

Since January 2002 and indeed just until yesterday, I haven't been able to purchase my monthly T bus Pass at the MBTA website. The web application framework that was being used in that site was only tested with Microsoft Internet Explorer. Having been true to Grandpa Netscape and Uncle Mozilla during the years in the wilderness, I would fire up the browser hoping to see a "Buy Now" button that simply never showed up in Mozilla. Thus 40 times in a row I was disappointed and tempted instead into my one monthly use of the great Internet Explorer (other of course than the frequent Windows Updates and the required testing of the products I develop). The story of Windows is of course another Book of Proverbs but that's for others to tell. I would hazard that eschatologists and numerologists everywhere would see some significance in the number 40. Presumably the Greek chorus of masses of unwashed Firefox users had more sway than my lowly monthly email missives to the MBTA tech support team about getting support for the aging Mozilla suite - again there's someone who doesn't get much love and who is being cast aside in this brave new firefoxy world.

Flickr buttons

In Flickr, I can't add a photo to a set or add a note because "To take full advantage of Flickr, you should install the latest version of the Macromedia Flash Player". Now I love Flickr, I have the greater part of the photographic record of my life on that service, but the very serious message they seem to be telling me is that they are above placing an ugly HTML button above my images. It is an affront to their sensibilities. I can understand that drag and drop organization of hundreds of photos might require Flash. But is it too demeaning to be able to simply click Add Note? It appears that they'd rather have the enhanced experience of Flash effects which can cause other issues as I've pointed out - see Cultural Sensitivity in Technology.

I can't blame them however, Gertrude and Felicia do have their seductive appeal, it does look prettier right?

Now that Buy Now button is one of those flashy mouseover-y kind of things. We're downloading 2 additional images instead of the five characters that came down with the page, slowing things up for those unfortunate to be on dial-up. There is no semantic value to the button. There's no tooltip to explain what it's for. The image doesn't have any alt text. It's less accessible wouldn't you agree? Users with different browsers had to beg for 40 months in order to be granted the courtesy to even click on it. If I had problems with my eyesight and needed to use a high contrast scheme, I couldn't leverage the operating system's built-in support for html buttons. If I had to use a screen reader, it would have been lost to me. As a developer, I would have had to write code to build keyboard navigation to the button to add tab indexes and the like. Ad nauseum.

I suppose I shouldn't complain, it is possible to style various html form elements many input or a submit buttons have lovely images. What gets me is when people don't use what facilities do exist and even worse go out of their way to avoid them.

What is wrong with a simple html button I sometimes ask?

But I lost that argument a long time ago. Indeed whenever I bring up the additional work required in the alternatives to HTML forms and buttons, since for example back in the old WebSphere Portal, I've had to clean up the accessibility and keyboard navigation messes of yore, I am treated as a wild-haired party-pooper claiming that the Emperor has no clothes. Recently I spoke of John the Baptist and Salome so perhaps this time I should say that I rather fear that a Delilah will crop my metaphorical RESTafarian dreadlocks, hence I tread carefully these days before I engage in Jeremiads...

Missing Blogger buttons

As a practical case in point of the perils of HTTP abuse, just fifteen minutes before I wrote this post, I had discovered a couple of broken links in my Best Left Unread post. Completist that I am, I was going through and adding technorati tags to my posts - the links were about the Completist Syndrome.

As a sidenote: you get a better idea of how to tag things with the benefit of hindsight. The categories or tags you place on things right after you've written something are not very good. Why is that?

Now it turns out that in Blogger's table listing of blog posts there are 2 links next to each other. Actually let's have a look at this:

2/24/2005

Edit

Best Left Unread

Koranteng

View

Delete

Let's leave aside the usability issue of why View and Delete are right next to each other. Deleting posts should typically be a rare occurence unless your former employer's lawyers object to your ruminations or more likely if the RIAA or MPAA come after you. But that's another story... Moving right along...

At 11pm, tired after a long day of work and with faulty muscle memory, I right-clicked on what I thought was the View link and opened it in a new tab. When a few minutes later, I switched to the tab I was a little perplexed by what I found. Thankfully, Blogger actually knew a little about idempotency and had a big "Are you really sure that you want to delete this post?" question with the post listed in its minor glory. But how was it possible for me to so easily get into this state? Why was it a link in the first place? I suppose that it's fair to put a trash icon next to a tag in Flickr, after all metadata is not that valuable. But a blog post?

Coincidentally, I sent the following enhancement request just yesterday to Monsieur Feinberg on a completely different issue:

Usability. At very first order right-align the "delete this post" link. In any case put it as far away from buttons that are typically used (Save and Cancel). Deleting shouldn't be a frequent activity. My own preference is to make the user have to look a little before deleting. There should be a little cognitive impedance before they delete. The system loses value when content gets deleted, let them work for it... Make them check a box and search for a button to click before deleting and make sure there's a great reason for them to do this...

Now as the Google Web Accelerator has made clear, this is not just an issue with parts of Blogger, Flickr or the MBTA. There is a fundamental problem with how people want to use forms, buttons and the user interfaces they build on the web.

HTML forms were indeed an afterthought. All the browser vendors wanted to lock you in their schemes of empire building and dreams of gold and glory. This meant that the forms that we did get were not as good as they could have been (they certainly aren't as pretty as they could be). I've gone through many midnight gymnastic sessions to try to get them to do things that Gertrude and Felicia asked. But they work, they are well known and their semantics widely understood. I would say to the my peers toiling away to fix their problem, let's tread very carefully and make sure the right lessons were learned.

Why Specs Matter and the Law of Leaky Abstractions

Your pedantic narrator actually reads and writes specifications. As you can tell, he doesn't just code or refer to himself in the third person, he can also write a lot. Indeed it is a pet peeve of his that not enough time is spent getting good specs together. Thus at this note's conception, he would write things like the following

It is sad fact of life that we don't get enough time to work on design and architecture; most of a developer's time is spent dealing with crazy schedules, task lists, status updates and the general drudgery of the "Software Process"... I was thinking about this during the rare design discussions during our meeting yesterday. So I thought I'd point out a couple of articles you might find interesting:

• Mark Pilgrim does some of the best technology writing and also implements of a lot of cool software on the web. Here's his latest piece, a short one on Why Specs Matter. His language can be a little strong at times, but he gets the point across. You can defintely do without specs and we are often tempted to do as much; but a good spec really does make a difference. Think of XML 1.0, HTTP 1.0 and 1.1 or TCP/IP which have bred entire industries.
• Similarly, think of 'leaky abstractions' the next time that someone tries to push their framework on you, whether it's EJB, WCL, EMF, SDO, JSF, Portlets or whatever the flavour-du-jour is. If you've ever had to spend an afternoon figuring out why the heck your tables or buttons don't do obvious things (the answer being that ultimately our output is html and no abstraction in an API can overcome the limitations of that underlying infrastructure), you'll know what I mean. Now understanding this is an argument for reducing the layers that you have in your software architecture. So for example in a case close to my heart XForms, if your underlying abstraction is HTTP, hyperlinks, XML Events and Schema and your output is HTML or some rich client UI, you should think very hard before introducing any additional layers with their own modeling and semantics since ultimately you're going to have to deal with that infrastructure. Joel Spolsky's Law of Leaky Abstractions is the final authority on that front. His canonical example is the ASP.Net framework's long crusade against my lamented HTML button.

My great friend Rob [redacted] (why don't you start a blog Rob instead of being a best-kept secret in [redacted subdivision of blue company]?) had this to say:

90% of everything is crap. That's Sturgeon's Law. Software is not excluded from this principle. We live in a mass-market, low-bid, first-to-market world. Our goal ultimately is to be less sucky than our competitors. Many of the quality things you point to, like XML Schema had amazingly long schedules, compared to our 8 releases a year, schedules so long that they could only be done by non-profits, or in a deep research group.

A written spec is key to giving an organization the flexibility to grow. Without it, adding new people to a project requires that the existing engineers take time out to bring the new members up to speed. This is the mechanism behind Brook's Law ("adding people to a late project only makes it later"). But a good set of project documentation can temper the effects of Brook's Law and provide some scalability. Imagine how much of an easier time we would have bringing new people on board, if we had a complete design doc for [redacted hotshot product].

The person in [redacted services organization] who wants to make a custom solution based on your component, the person in research who wants to use it as the base of a prototype, the co-op who wants to base a summer project on it, the lead of a new project in [redacted] who wants to reuse your code - all these people will seek information from you. You can either have a spec and a design document ready for them and be seen in a very positive light. Or you can come off looking like a fool. The difference is whether you are designing throwaway code, or code that has wings. Very little code goes far which does not have a spec or design document. You don't win an [redacted] Award for throwaway code.

Eventually we'll all move on to new challenges, and eventually active development of [redacted] will be canceled. Your code will be maintained by someone in [obvious redacted locations] who will have nothing but your spec and code to work from. And in 10 years, someone will try to revive part of your code, and without a spec, they'll be lost. Trust me, it happened to me, trying to revive parts of [redacted bemoaned product killed by monopolist] to write a [redacted useful feature] for [redacted new-and-improved hyped product]. So, if you don't write a spec, your name will be cursed in languages unknown to you in far away countries, and also by kids in middle school today when they try to figure out your code 10 years from now.

I can't add much more than that as far as development of software goes but that is sadly an unpopular perspective when it's often a case of aggressive, Real-Men-ship-code-and-batter-the-enemy warlike rhetoric (rest assured that Steve Ballmer types don't only exist at [redacted monopolist]). Sometimes a little estrogen is needed in the technology world. Further, as my own experience has shown, I know that specification-reading will likely remain an afterthought in the realm of application authoring.

View Source is the thing.

A Hyphenated Parable

I have a hyphen in my name. 2 generations back in the colonial Gold Coast, it was quite a popular thing to assert a family's identity and that is part of my story. Thus in modern Ghana you'd find many an Ofori-Adjei, Owusu-Ansah or Casely-Hayford. This assertiveness continues to this day. Naming is culturally important in my society; the outdooring ceremony of week old babies is their introduction to society and the ancestors are duly consulted so that the correct name is chosen. We pour Schnapps on the ground as the name is announced for the first time dressed as we our in ceremonial white and blue. A similar inventiveness in naming exists in those whose ancestors were 'invited' to cross the Atlantic Ocean in the past few centuries and, through various grisly legacies and traditions, I am now able to pursue 15 year searches for a certain Shaniqua who's got me woked. But I digress... In the French and Francophone traditions also, hyphens are big items: think Jean-François types. More generally in almost every culture, it is increasingly popular when people marry for a hyphen to unite the two families.

I like hyphens, they are promiscuous, sociable and attach themselves willy-nilly to all they encounter. Call me a hyphenphile if you will. It's no accident that my future wife has a hyphenated name (with the same initials no less); Freudians would say that this was a subconscious part of our mutual attraction. If we weren't patriarchal in our ethnic traditions, I might even be thoroughly modern and go for a quadruple-barreled billing for our children like Auntie Felicia.

The problem with hyphens is that well... Scratch that, let me tell you a bit about hyphens.

In computer science there is a general category of problems that have to do with delimiter characters (underscores, hyphens, colons, semi-colons, angle brackets and other special characters). Software is very concerned about structure and the parsers of our Tower of Babel file formats need to know where records begin and end. A similar issue is currently putting the tagging community into a tizzy with some favouring spaces (flickr, del.icio.us), commas (allconsuming) or semi-colons (furl) as delimiters. It's very confusing for someone who samples all these services and many an item has been mistagged by mistake.

I got my first credit-cards just as online ecommerce was picking up in the early 1990s so I have lived through the evolution of that industry's handling of hyphens.

I stopped using a certain Visa card, which was actually my introduction to Generation Debt, when it turned out that I couldn't use it for online purchases because certain backend systems couldn't handle the hyphen in my name. Circa 1999 however, this got sorted out. But that company lost the wool of the sheep I gifted to Uncle Amazon for half a decade. By and large these days, the credit card industry have fixed their issues, I am no longer forced to lose the hyphen when I order something online.

This is not the case with travel reservation systems however. The hyphen simply doesn't exist as far as they are concerned.

My very chatty travel agent was explaining all of this to me this past weekend, "The system doesn't take the hyphen. It's persona non-grata!", excited as he was to talk with someone who knew a little about the history of the Sabre system. I suspect that IBM built some of that core technology 50-60 years ago.

Most airline reservation systems handle hyphens gracefully but some don't, and, over the past few years, I've had instances where plane tickets that I thought had been purchased days earlier actually hadn't causing panicky travel agents to call me to figure out the mess so they could get their commission. I have literally lost hundreds of dollars when I've had to rebook the flights in question at higher rates. The curse of the hyphen struck repeatedly.

Thus I don't have my Delta frequent flyer number saved on Travelocity, Expedia or Orbitz. When I travel on that airline I have to remember to give my frequent flyer number at the check-in counter to get credit for mileage. As it is, I pretty much stopped flying Delta and indeed the last time I flew on Delta and gave my number, I was told that they had cancelled my frequent flyer account for non-activity... Such is life.

I booked a trip this past weekend and when I tried to check my itinerary on checkmytrip.com, I kept getting errors. I was worried and kept trying without success looking at my keyboard with bewilderment Caps Lock? No. Num Lock? No. Typo? No. etc. Then I remembered my conversation, checked my reservation slip, and realized that I had to log in with the hyphen removed from my name. Ofosu-Amaah became OfosuAmaah.

That's not the end of it however. I am regularly scrutinized by immigration or customs officials and of late, overzealous TSA officials on the lookout respectively for a certain class of economic migrant, drug smugglers and Al Qaeda splinter cells. I have always thought that my problems stemmed from the radioactive effects of carrying a Ghanaian passport, that reliable sign of economic desperation.

Another way to look at things however is that these officious officials are simply wondering if I am the hypenless person printed out on my plane ticket.

Thus they tilt their head askew as they scrutinize the face that I naively assumed soothingly said "trust me".

Hillary, when her husband's campaign made her become Rodham Clinton, chose not to use a hyphen and I think she's on to something. She may even accept campaign contributions from Delta Airlines as they struggle against bankruptcy. With some Schadefreude, I wonder if my double-barrelled hyphen boycott is having an effect on Delta.

Acela Blues

Similar fairy tales have been said about how the standards for rail gauges were developed in the US. Bob Frankston's sharp ears recently perked up when he heard about the current problems with the Amtrak's Acela trains and he speculated as follows: Acela -- A Casualty of Risk Aversion?

From the Boston Globe article on the Acela brake problems (22-Apr-2005)

Bombardier of Canada, the company that helped to manufacture the Acela, had to satisfy the Federal Railway Administration's "buy American" rules. This meant that parts for the train had to be designed for the United States. As a result, the Acela Express trains are twice as heavy as comparable European high-speed trains.

As I see it the issue is the constraints that lead to the trains being much heavier than the European trains. This is the price for risk aversion – it isn’t free. In the case of Acela trying to remove the risks by overbuilding creates its own problems and can increase the risk. Given their track record (sorry, I couldn’t resist) it seems that the Europeans made reasonable tradeoffs.

He backtracked a little with a possible correction a few days later

30-Apr-2005: Correction? A letter in today's Boston Globe noted that the heavier carriages were needed because unlike France and Japan the US trains work on existing rails. I can understand the design tradeoff between building new infrastructure and adapting to what is available. A reminder to be wary of stories that confirm ones expectations. Was it the right decision? Perhaps yes given a political climate that wouldn't accept the capital costs of a new rail line through the crowded Northeast Corridor.

And that was that you would say? But I don't think it ends there. It belies the question of why indeed the standard US railroad gauge is so different from those successfully used in continental Europe and Japan where the rail systems are models of efficiency. And this of course is fodder for historians of science and technology, train buffs and urban legend hoaxers (and debunkers alike) everywhere, nicely discussed here

The US standard railroad gauge (distance between the rails) is 4 ft 8 1/2 in (1.44 m). That's an exceedingly odd number.

Why is that gauge used? Because that's the way they built them in England, and the US railroads were built by English ex patriots.

Why did the English build 'em like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used.

Why did *they* use that gauge then? Because the people who built the tramways used the same jigs and tools as they used for building wagons, which used that wheel spacing.

[snip worryingly long 2,000+ year chain of plausible links]

So who built these old rutted roads? The first long distance roads in Europe were built by Imperial Rome for the benefit of their legions. The roads have been used ever since.

And the ruts? The initial ruts, which everyone else had to match for fear of breaking their wagons, were first made by Roman war chariots. Since the chariots were made by or for Imperial Rome they were all alike in the matter of wheel spacing (ruts again).

Thus we have the answer to the original question. The United States standard railroad gauge of 4 ft 8 1/2 in derives from the original military specification (MilSpec) for an Imperial Roman army war chariot. MisSpecs (and bureaucracies) live forever!

Now although this particular alternate history is something that many have tried to debunk, its essential appeal is that it serves as a fabulous object lesson about standards and how technology gets adopted when pragmatism and leverage is the key rule of thumb. Some things have longer lives than one would expect.

Update: Bob Franskton adds

You'd appreciate a show on the travel channel. If you take a train from China to Mongolia it goes through a stop where they change the wheel carriages for a difference in gauge and then the train moves on.

Perhaps I should ask my travel agent to book me a trip to Mongolia, I hope the rail reservations systems can handle hyphens.

Forms in Browsers

It seems to me that we have 2 ways forward to improve the experience of html forms on the web: the XForms and Web Forms 2.0 specifications.

If I were to return to my conceit, I would call them two tribes squabbling in the desert with Grandpa Mozilla feeding both sides at different times. On the one hand, you'd have the XForms buffs and there are many of them, who first saw the discord in the land: Gertrude and Felicia did have something of a point in that the Form family could be improved. Thus toiled mightily and tried to distill the kind of patterns that experience had shown were being solved in the wild.

Their advocacy problem is that they were tainted by their early association with that disreputable couple XSL and XML Schema from whom they adopted little XPath. Now XPath was a fair kid but would always be tarred by the brush of that loose XSL mother of hers. She had a few learning disabilities (or rather eccentricities) and insisted that all who entered her house take off their slippers and wear kimonos made of parentheses. Even visiting royalty, King True and Queen False from the land of Boolean were given her functional treatment.

Then there was the WHAT tribe, who were old browser calf types, now lean and mean, the stern and Operatic Håkon (screaming Howcome! Footprint! and Though shalt have no other solution except CSS and Javascript) along with latterday convert, the CSS prophet Hixie. The more pragmatic Hyatt who takes frequent Safaris may be receptive to the one but is a touch wary about how it might bite the Apple. The good Baron Brendan Eich is enigmatically philosophical about the whole thing as he nurtures the wily Firefox. Hopefully those grand viziers at the house of W3C will knock some heads together and all will learn to get along without suspicion. The jury is out for the next 18 months.

I have my hat working on the one but truth be told, I couldn't care which wins. I've pointed out some of the comprehension problems that might arise with XForms's choice of XPath see On XForms, XPath, CSS, Brevity, Syntax And More but even though I've been a heavy Javascripter I'd like to make sure that Jill Department Head doesn't have to learn script just to pull a survey together. Clearly this area remains a work in progress.

We are still in the baby years of the web, the idea is to do things right, to learn the lessons and fix problems quickly so that 50 or 5,000 years later people aren't hobbled in literal ruts about the descendants of HTML Forms.

Returning to the abuse of the buttons of my discursive tale, Phil Ringnalda devastatingly make a similar point

I wonder why buttons look like that:

(designers are looking for) an easy way of using JavaScript to tunnel their looks-like-a-GET link through POST.

Apparently in all the rush to read Section 9.1 of RFC 2616 and to misinterpret the meaning of SHOULD NOT, nobody is actually reading the part of Section 9.1 that says

This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Making the fire alarm look just like a light switch isn't an example of daring and innovative design, it's just dangerous. Pushing the table out of the way won't keep you from falling off the chair.

This is exactly Tim Bray's sentiment

"I can remember like yesterday a Content Management conference about 1997, a woman from a big computer company talking about how great it was when they switched their CM system over from custom clients to the browser: "It’s so great! The browser is so limited, so they had to throw away three-quarters of the buttons and sliders and pulldowns and options, and just do it with hyperlinks and simple forms... it was so much easier to use!"

The ugly duckling user interfaces of the web have worked to a surprising extent, if we do give them the extreme makeover treatment, I hope one will still recognise their fundamental utility. I can still see traces of little Michael Jackson in the face of the current train wreck.

Placing a cache closer to the user which is what Google have attempted is simply doing what Akamai have done at a different layer. And it makes sense, caches should be as close to the user as possible, the benefits in terms of the interaction experience are obvious.

I know that down at the ground level, one might be a designing a web site and the client might want prettified links instead of those unloved html buttons. The core of web user interfaces are not sexy yet they work, and users understand them. The visual cues about what may or may not be safe are well known.

As application developers we should ask for better forms, we should be demanding of browser makers things like XForms or Web Forms 2.0 to make sure that we can go beyond the kind of stilted usability that we currently have. Our users would appreciate our efforts in that vein but for now, they know what to expect. Until then application developers should push back when we are told to "do the wrong thing".

Pushing Buttons

Micah Dubinko who was one of the chief authors of the XForms spec has it right when he calls his blog push-button paradise. That is the nirvana we're aiming for: a Garden of Eden where Forms and HTML Buttons will finally get some love. Thus as I conclude my folktale, let me give you one glimpse of our teenager button. Go ahead click on him, he won't bite, there's nothing unsafe here, a few hormones perhaps. And I know a bit about idempotency so presumably I won't lose anything.

There. That felt good, didn't it?

See also Technical Arteriosclerosis and again On The Importance of Biting Satire

Update: James Snell drops further Proverbial Zingers in Not tonight honey, I'm having idempotency issues...

Update: Holy Serendipity Batman!. Those defending Hillary in the midnight hours, no doubt through an (idem)potent keyword-searching conversational engine brew or other, happened onto my hyphenated parable. My tags are accordingly updated. I do believe this land called Blogosphere is no Kansas. I love tomorrow.

(Enough already, with the puns. Like those buttons, get on with it.)

File under: whimsy, technology, adoption, standards, html, forms, software, button, xforms, web, satire, history, best practices, wit, parable, story, storytelling, programming, design, patterns, hyphens, delimiters, railroads, trains, REST, Google, Lotus, IBM, strategy, zingers, Hillary, serendipity, toli

On The Significance of Social Software

danah boyd posts the abstract of a paper she's writing on The Significance of Social Software for public criticism.

In this paper, I will explore the contributions of social software. I will argue that there have been notable technological advancements, but that their significance stems from the rapid iteration of development in ongoing tango with massive user participation. In other words, the advances of social software are neither cleanly social nor technological, but a product of both.

Social software represents a new generation of social technology development - a generation that is dependent on moving beyond the laboratory and into mass culture. Its manifestations are already staggering - ABC declared 2004 the Year of the Blog as blogging challenged everything from political discourse to identity production. Social networking services in the hundreds have motivated millions of people worldwide to construct and negotiate profiles and grapple directly with the social awkwardness of being more public than one thought. By allowing people to easily stumble upon the work of others, media sharing services have prompted new ways of organizing information and playing with the intention of producing media. These advancements complicate critical theoretical ideas about the nature of the public(s), the role of relationships in sharing, and the collective desire to organize information.

Flash in the pan or novel?

This certainly sounds like a paper that should generate much discussion and I can't wait to weigh in with my keyboard in dissecting it. I was reflecting on much the same question a couple of months ago in People, Processes and Things

The terms that have been used about software that aids collaboration have all been unsatisfactory. They have been mostly opaque terms (groupware, knowledge management etc) overloaded and hyped by marketing teams. Correspondingly also, lots of software in this area has been unsatisfactory even if very useful for some groups whether it's mailing lists, usenet. The flight to a quality term like "social software" that people like Clay Shirky have spurred in recent years is an exercise to escape the stigma of the reigning software. I heartily endorse that effort but when I pass the hungry salesmen in the corridor that are trying to sell software for my company, I know that that effort will be in vain. If it's between their year-end bonuses and calling something "social software", you know what's going to win. Thus I predict that our vocabulary for software that supports groups, organizations and communities will continue to be contaminated.

There is more than mere terminology here as danah points out; there is also the question of whether the newer sofware applications and the insight gained in developing them are significant.

From my standpoint, the only difference in the emergent software is that much of it is web-native and can leverage the delightful surprises and scale of the web platform (which thankfully has remained relatively open). Previously this type of software was typically on vertically-integrated platforms (e.g. Lotus Notes, Groove etc). Now if you lived in the ecosystems of those platforms, you would know that you can (in some cases) get much of the immediacy of the web. As an example, Notes has always had hyperlinks of a sort, there are database links, view links and doc links. Ray Ozzie even invoked Lotus Notes' hyperlinking fundamentals in a bid to save the browser from the Eolas lawsuit. The problem with Notes hyperlinks was that they weren't simple URIs - even if you could indeed copy and paste them in Notes; they were only useful in Notes clients. The ubiquity of the web could not be leveraged in other tools. I couldn't jot down the URI to a particular teamroom on a napkin or paste it in an instant messaging window to share. On the whole nobody cares what kinds of clients you use with web-native software.

Sociological Insight

When considering social software, you have to bring in the sociologists and hence I'd point to some older case studies to consider in this arena regarding the nature of the communities that the software in question is supposed to serve.

• Wellman, Boase and Chen: The Networked Nature of Community Online and Offline

  Communities started changing from groups to networks well before the advent of the Internet. Initially, people believed that industrialization and bureaucratization would dissolve community groups and leave only isolated, alienated individuals. Then scholars discovered that communities continued, but more as sparsely-knit, spatially dispersed social networks rather than as densely-knit, village-like local groups....
  
  Given the movement from the local and densely knit to the far flung and sparsely knit ... it is useful to define community as networks of interpersonal ties that provide sociability, support, information, a sense of belonging and social identity.

• Koku and Wellman: Scholarly Networks as Learning Communities: The case of TechNet

  "There's a shift from small groups to diffuse, variegated social networks. Boundaries are permeable, interactions are with diverse others, linkages switch between multiple networks, hierarchies are flatter and more recursive.... transient, virtual organizations.. work relations spill over nominal work group boundaries... even connecting to outside organizations"

The insight of such quotes is about the fluidity of the communities in this modern life of ours. They presage a notion of social networks with sometimes implicit rather than explicit webs of relationships. The kind of thinking required for networks needs to be flexible in order to deal with the diffuseness of our evolving patterns of discovery and social interaction. Handwaving a little, it is like the kind of shift in thinking that we have gone through in the move from desktop productivity applications (like the traditional office suites) to web applications that need to keep the network abstraction and usage patterns in mind.

On Metrics

I'd also throw in some Usage Statistics from Groove Networks but the details from that report seems to have vanished into the cyber ether although the summary is important in what it displays about how people actually use the software (as opposed to how the people who wrote the software thought it would be used). With appropriate metrics, those in the community can get measures of health (since as we know sometimes a group is it's own worst enemy - e.g. the kind of collaborative moderation on Slashdot). The metrics can also help those who are developing the community software.

Right now the server logs at del.icio.us, Flickr and Furl are among the most valuable pieces of property in the internet. Certainly for anyone interested in social software, the kind of insight that Joshua Schachter is gaining from his logs would be invaluable.

But this goes beyond research, potentially this is something that can be translated into features of genuine use by glue layer people or perhaps that can be monetized in some fashion (e.g. through advertising supported services). If you want to be intelligent in your design of social software, sometimes you need to go straight to the source and simply ask the users (e.g. the proliferation of "Report Spam" buttons in web mail clients). Enlist the users and get them to feed you their usage patterns (e.g. the Alexa toolbar). It's no wonder that Google is trying to do the same with the launch of its web accelerator.

Cross-posted at the Inside Lotus weblog.

File under: communities, social-software, social, networks, groups, software, technology, sociology, Lotus, IBM, language, metrics, web, internet, toli

Get On The Bus

An open note to my some of my favourite loosely-coupled people Phil Wainewright, Jon Udell, Sam Ruby, Tessa Lau and Monsieur Feinberg amongst others (connecting once again).

Glue Layer People | Technology Adoption and Systems Design | A lighter touch | The Soul of a Company | Get on the Bus | On the Local Bus | On the Chinatown Bus

Glue Layer People

You may not all know each other but in my folksonomy I've tagged you as "Those who live in the Glue Layer", fellow travelers for whom composition is second nature. Erik Benson has recently added music and movies to the books in the new allconsuming.net. Intriguingly he added an "Other material" category, I've been wondering if people will fit in that space.

Day after day in Bloglines and other venues, I see all of you pondering a whole host of buzzwords, trying to figure out whether there is depth there or if it is all breathless post-millennial hype (as opposed to the pre-millenium tension of yore).

This current note was triggered by watching some of you grapple with the WS-Fabric and Enterprise Service Bus, Service-Oriented Architectures and other complex frameworks. This is the kind of discussion that brings your systems architect stylings to the fore and I admire the healthy inquisitiveness you display as you roll your sleeves up and start to explore - and debunk.

On these last topics, WS-* and ESB, I suspect that there's a lot of work going on and certainly the stack of Powerpoint slides is impressive. Now I started my professional life working on Freelance Graphics and our convertors to and from Powerpoint were always 1 or 2 releases behind (darn those cunning monopolists), something always got Lost in Translation with the latest must-have version that was being pitched. And metaphorically speaking I am missing a few slides about many of these buzzwords.

I know that you and other folks are getting down and dirty in the code. You are all pragmatic types with a skeptical bent and can-do attitude. Life in the glue layer is about the outside-in. Pipes and filters are your abstraction of choice, you might dream of Markov chains, the calculus of design heuristics and those old standbys, the rules of thumb, as you attempt to put order and infer structure where there was none.

Down in the trenches however, a lot of these newfangled buzzterms (as Jon's felicitous coining goes) seems reminiscent of the futility of Esperanto, work that is prone to degenerate into a Tower of Babel. Closer to home I hear about roadmaps galore that often bear no relationship to the technical issues I am grappling with daily. Forgive me if I am similarly a touch skeptical about most of these buzzwords.

Thinking back, I can even remember having to fix a couple of bugs in that last bus that everyone wanted to get on 7 years ago. Remember the InfoBus from back when Java, thin clients and the Network Computer were the great bandwagons? True you might say that the InfoBus was addressing a different issue than this new "Enterprise Service Bus" but it was a bus nevertheless and everyone got off rather quickly.

Now I don't want to be too flippant; we all understand how these things work in the marketplace of ideas. As far as technology adoption goes, we can all play the standards game and some are actually useful (e.g. XML 1.0 was the last great specification that I've read and perhaps Atom will be the next), we know all about platform neutrality, no one wants to get locked in, we've learned heavy lessons about monopolies and so forth. Like David Clark said

We reject: kings, presidents, and voting.
We believe in: rough consensus and running code.

It's just data, right?

Suffice to say that if it is a matter of getting on the bus, my company will readily ship busloads of consultants your way. This past weekend, my uncle was talking about an upcoming jamboree or cruise that IBM's marketing folks were taking him on in coming weeks. Last year's pitch was SOA and Workplace (neither of which convinced him, he's a conservative kind of architect) but he was willing to listen to what they had to say and maybe with hard work we'll get there. Someone with his budget can afford to have 5 year plans like the old Soviet regimes and take a broader view on things. He was looking forward to revisions to the pitch this year, ESB and WS-* were on the cards he noted. O to be a fly on the wall of that pitch. Maybe I'll ask him to send the materials they give him; I'm curious to see the relationship of those marketing brochures to my daily work. Truth be told, he admitted that he was also looking forward to sampling their champagne.

Our services guys are chomping at the bit to fix your engine and to throw in lots of extras. Like mechanics at the autoshop, they will tune your Ford Escort forever and for a fee. Meanwhile those little Honda Civics are getting on with it...

Where Mel Brooks' 2000 year-old-man considered Saran Wrap the greatest invention, I suspect for you it's duct tape, spackle and wrenches (or spanners as my Brit-colonized ears would prefer). For you it's all Perl, Python, Ruby, shell scripts, URIs, bookmarklets and the like. I'm with you on a few of those but my facility with some of your tools of choice is suspect at best. I try, but it's a work in progress.

As an application designer my perspective has mostly been "inside out" and I've been forever amazed at the serendipitous magic that you glue layer people have been able to do with things I've built. My goal in life is to find a way to encapsulate and codify the design patterns that would make your jobs easier. I need to internalize that style as the best practices in what I develop. In my current work on forms, I've stumbled into a area where I have to start thinking about glue (at the very least I can handwave a little in that direction). Forms applications are indeed the glue of people and processes. The hope is that Bosworth's notion of simple, sloppy, standards that scale will be something that can be leveraged in this area; it is certainly something I'm working on. I'm coming to realize that the glue layer that you folks live in could become my kind of thing...

Technology Adoption and Systems Design

Jon recently quibbled with Rich Turner about his invoking the stupid network and the end-to-end argument in this tangled conversation. I actually think it is fair game; any question about technology adoption and systems design should start with the wonderful insight of Reed, Saltzer and Clark. Thus I have a rare disagreement with Jon, but here it is not for the reason that one would think.

One of my contributions to knowledge and my only good deed in the past few weeks (if you've noticed, I've been beaming like an idiot throughout), was to point Dan Lockton, who is doing a great PhD dissertation on Architectures of control in product design, in the direction of Andrew Odlyzko's work on price discrimination (pdf) architectures (pdf) and their economic implications for the Internet. The terrain of those papers is the history of telecommunications and transportation systems.

If you read Odlyzko, his basic line is that companies have forever been trying to price discriminate and that the internet affords much opportunity to continue in this vein. His is a more grounded and, to my mind, insightful version of Lessig's flashy Code and Other Laws of Cyberspace argument. Sometimes price discrimination can be beneficial, economists affirm that insight in their calculations of utility functions. At other times, for example with almost all DRM (and the obvious example of region-coding of DVDs), it is downright awful and the negative externalities that arise are roadkill for enthusiasts and grandmothers everywhere.

Arguing by analogy once again, I would say that although the ESB and the WS-* stack are being pitched as this loosely coupled utopia (along with things like SDO), I suspect rather that it is a play at building a complicated overlay network, a run-of-the-mill "Architecture of Control" in other words, on top of this sloppy, stupid network of ours, that wonderful horseless carriage web that Tom Coates speaks of.

Of course, I have a jaundiced outlook on things and have my own pet approaches that I quietly push. In my own fashion, I've even recently felt compelled to perform A REST Intervention. In that piece I tried to take a pragmatic look at those august composable "service oriented architecture" thingimijigs. I suggested changing the frame, and pointed to the value of simple resource modeling and the show me the code impulse. In that dissent by analogy, my position was that leverage is the thing and internalizing the web style is all about leverage. I don't know if that is a message that will resonate but it's worth a try.

There has to be a response in writing, if not in code. Ideas don't exist in a vacuum and I shouldn't take to some ivory tower, with Fielding's bible on hand, Prescod and Baker as prophets in the wilderness, and Bray as curmudgeon and loyal oppositionist-in-chief all the while pointing to Apache, Amazon, Yahoo, flickr, del.icio.us and others as favoured offspring and self-evident existence proofs. That's not a sufficient response.

A Lighter Touch

But there's another way to look at my words. Despite all my caveats, last Friday saw Monty Python come into things and it became a case of A REST Inquisition

Nobody expects the RESTifarian Inquisition!

Our chief weapon is surprise...surprise and tedium ...tedium and surprise.... our two weapons are tedium and surprise...and ruthless disregard for unpleasant facts.... Our three weapons are tedium, surprise, and ruthless disregard ...and an almost fanatical devotion to Roy Fielding

Bill de hÓra then laid in with REST and the dead WS spec Parrots

Mr. Praline: Never mind that, my lad. I wish to complain about this specification what I purchased not half an hour ago from this very boutique.
Owner: Oh yes, the, uh, the Big-Wizzdl...What's,uh...What's wrong with it?
Mr. Praline: I'll tell you what's wrong with it, my lad. it's dead, that's what's wrong with it! Owner: No, no, it's uh,...it's RESTing.
Mr. Praline: Look, matey, I know a dead specification when I see one, and I'm looking at one right now.
Owner: No no it's not dead, it's, he's RESTin'! Remarkable spec, the Big-Wizzdl, idn'it, ay? Beautiful appendix!
Mr. Praline: The appendix don't enter into it. It's stone dead.
Owner: Nononono, no, no! it's RESTing!

Michael Champion immediately rejoined that it was a case of The Semantic Knight

HACKER: What?
SEMANTIC KNIGHT: None shall pass without using all sorts of semantic meta-meta-meta-stuff that we will invent Real Soon Now!
HACKER: I have no quarrel with you, good Sir Knight, but I must get my work done on the Web. Stand aside!
SEMANTIC KNIGHT: None shall find anything on the Internet without semantic metadata!
HACKER: So be it!
HACKER and SEMANTIC KNIGHT: Aaah!, hiyaah!, etc.
[HACKER chops the SEMANTIC KNIGHT's first argument off by building efficent statistical/heuristic search engines]...

All of this hit too close to home for me even as I was laughing for an hour. I keep my hair short but some might call me a RESTafarian.

The Soul of a Company

James Governor recently called IBM a broad church that he respected, see IBM Software Group: The Baby Eating Starts Here. He added:

The more I think about what service oriented architecture means the more I realize loosely coupled has to go beyond lip service. Organizations as much as architectures must be decoupled, so they can be remixed. Its just so much horse manure to talk about SOA without a formal commitment to loose coupling. That is, open documented interfaces across granular components or services, with no funny business and hidden calls. Interoperability is not just a marketing term. You can't have SOA and attempt to drive lock in.

The more I think about the problems of SOA the more its clear the culture of a company will be as important in delivering it, from a vendor perspective, as any set of technical assets. Monoliths are not service oriented. But, we can't break them down without freedom of disassociation.

I responded that sometimes I felt like a prophet in the wilderness, someone who didn't know how to play the game, and indeed living at the ground level, you can be easily picked off by those with the broader picture and sharper elbows.

Governor's quick comeback was

Don't forget that both Jesus and Moses were once prophets in the wilderness. I am sure you don't want to be crucified, but the influence would be good ;-)

He has a point, those two were no slouches.

For another perspective on things however consider Pete Lyons who has definitively and succintly put things together in another look at the IBM software culture: Senior Technical $#1% Manufacturer.

Pete is a great loss to Lotus and to IBM. He is a prophet who simply couldn't handle not being recognized in his own village. He saw the writing on the wall about his John the Baptist stylings, and sensed the Salomes of this world lurking in the background, eyeing his head. He jumped ship and left on his own terms. I wish him well in his new endeavours.

Thus there is much food for thought in this conversation.

Where does the soul of a company lie? Where does it rest its head?

Get On The Bus

Spike Lee's 1996 film Get on the Bus was actually a return to form (Girl 6 was a disappointment even though it was visually wonderful; the Prince soundtrack was better than the film). But looking back at things with the hindsight of 9 years, it seems like much ado about nothing, a trifle, a bit of a damp squib in reality. I actually prefer his latest work (the great 25th Hour and even that male lesbian fantasy that was She Hate Me).

I mean the Million Man March was great and all. My barbershop even sent a delegation and they have the photos on the wall that we can point to whenever the conversation lags on Saturday afternoons and we become reflective. But let's not forget that it was Farrakhan who put that joint together. I hesitate to bring up that name since it has an inflammatory context in the US. My own exposure to Brother Farrakhan was in his fawning trips to the friendly rogues and dictators that proliferate in my sub-region - a case again of Strange Bedfellows. Thus I was a little skeptical about that bus episode.

On the Local Bus

I've been taking the 69 bus to work down the streets of East Cambridge for the past 9 years. It works for me but I'm aware that that kind of commute is not for everyone. And perhaps the following is illustrative...

Yesterday morning I was accosted by a nervous and scruffy man coming out of the Psychiatric Emergency unit of Cambridge Hospital which is right opposite my bus stop. Twitching constantly, and furiously smoking a cigarette, he was in his 40s, tall, lean and unkempt. He was a literal nervous wreck as he made a beeline for me and almost got hit by the passing traffic. The Portuguese and Haitian women who were waiting with me for the tardy bus instinctively crossed their arms and put their game faces on - the latter pulled the child she was babysitting close to her skirt.

His name was Charles, as I was soon to learn, and he is part Lebanese Christian, French-Canadian and New Englander. His education however was in the school of hard knocks of South Boston.

His problem is that "sometimes he acts out" and "not everyone understands him". Also, as he put it he "can see things that others can't".

Right after those preliminaries, he asked for a couple of dollars to head home, which I gave since I'm in a giving mood these days. In the calculus of weighing "madmen", sometimes you figure that people are just having a bad day. Thus sometimes you don't walk away and instead stand your ground and humour them. My Ghanaian equivalent of "Take Our Daughters To Work" day was to spend time visiting my uncle at work at the psychiatric hospital at Asylum Down in Accra. Much like African prisons, I would hazard that African asylums are not places fit for anyone let alone children. Still what was refreshing about those repeated visits was seeing the essential humanity in things: how people just got on with life despite being understaffed and overworked and having to deal with overcrowded, insanitary, and plainly harrowing conditions.

Thus encouraged, he felt he wanted to establish some bonafides. To impress me a little, he told of when some people tied his legs up with a belt and tried to throw him out of the window in Chelsea when he last had acted up. That must be his most shocking tale. I can certainly imagine such Mystic River episodes showing up in Dennis Lehane's next work. Then he segued into how he "hallucinate(s) frequently" and how "sometimes I'm scared of my shadow, you know". Every sentence he said in the next 15 minutes was eminently quotable. If it wouldn't have been rude, I would have taken out my little yellow pad and written notes.

For people like Charles, social conventions are a little difficult. He was completely oblivious to my wearing headphones and listening to the first track from my Mellow My Man playlist - the glorious horns of Pete Rock and C.L. Smooth's T.R.O.Y (They Reminisce Over You) which have to be heard loud.

His idea of small talk (the kind that David Weinberger praises) was to ask me out of nowhere whether I liked The Supremes. After a pause, "Is his maniac for real?", I replied that I liked most of Motown but not The Supremes. The Four Tops, The Temptations or Smokey Robinson and The Miracles perhaps, but not The Supremes. Hmm... For the next minute, as we felt each other out, we simply name-dropped. For his Otis Redding, I retorted Sam Cooke and then Bobby Womack - our man Bobby was "too modern for him". He came back with Anita Baker (thumbs up) but then spoilt it by using Natalie Cole on Unforgettable. I said "what about her father's version 40 years prior, why don't we go back to the source?"

Gaining confidence, he confided that "he thought he was black". To empathise with me he said that "You know, they say that the Lebanese are the sand-n*****s of the world". I have my own mid-Atlantic identity crises so I replied that the Lebanese were rather the great glue of the world, that they were the great merchants and that one can find them on every coast lubricating social intercourse and commerce. I don't quite think he'd ever been to Lebanon and or that he knew that some of my best friends growing up in Ghana were Lebanese (there's a huge and successful Lebanese population back home) or indeed that I had some pita bread and hummus in my lunch bag. I suspect there had been a lot of teasing about his ethnicity in the Southie playgrounds he grew up in, open wounds that still hurt 30 years on.

Thus once we got onto the bus he greeted each of the black teenage school kids that came on board with a "What's up bro?". Now that's a dangerous thing to say to some of the army fatigue and FUBU wearing kids (and the occasional obnoxious predators) that ply the streets of urban anomie that I tread daily. Sometimes even a little bump on the way to the back of the bus can bring out a bewildering display of testosterone-fueled aggression.

Much to the dismay of the others on the bus, he continued to perform. The bus driver had seen it all before at the hospital stop and wasn't about to intervene. Thus after a while, he came and sat next to me. Now I had gone and deliberately sat next to this short Latino guy so that I would be done with him. Undeterred, Charles came and menacingly stood right in front of the guy who promptly moved to greener pastures.

There was tart little smell to him; his teeth were yellow smokers' teeth. Snuggled up next to me and my bags, you could tell that he had indeed been through a lot in life. There were lots of wrinkles and the roots of his prematurely grey hair showed signs of stress.

He was an unattractive nuisance in other words.

Perhaps I should have behaved like that other Cantabrigian sandal-wearing woman with that awful Joseph-rainbow bag and Nepalese shawl who came on at a later stop engrossed in her headphones. Charles almost pinched her, he was so excited, "I keep running into her on my rounds... She's one of my women!". Anyway, in that slightly louder voice that all Walkman and now iPod people assume, she explained that she was listening to "the sounds of the wild", one of those nature cds that help her meditation. Thus she ignored him, and us all, and slipped back into trancendental environmental bliss.

Instead, over the loud beat of The Brothers Johnson McFadden and Whitehead in my headphones, "Ain't no stopping us now", which he started singing loudly, and despite my attempts to finish my novel ("You must be educated since you're reading, the brothers around here don't read"), we talked of art, his paintings and the time he was kicked out of the art class at the Cambridge Adult Education Center for acting up. "The professor was so intelligent but he didn't understand what I was about. I know I shouldn't have acted up but I couldn't quite help it".

We talked about the artists of the Renaissance, I drew a blank on the names he threw out (where he mentioned Antonnelli, I was thinking Angelina Jolie), but when he went further back to Narcissus, I of course knew all about the reflection in the pond. I worried a little when he asked "Does this all exist or is it just a dream?". Solipsism is sometimes a prelude to suicidal thoughts which I've had to deal with in the past in some dear friends. Thus without blinking, I told him that it's just life and that we simply have to get on with things. Instead I provocatively hipped him to the B-movie theory, Ronald Reagan and Gil Scot-Herons's take on things.

"And if you're sensing, that something's wrong,
Well just remember, that it won't be too long
Before the director cuts the scene. yeah."

"This ain't really your life,
Ain't really your life,
Ain't really ain't nothing but a movie."

That paranoid style actually resonated with him.

When I mentioned that he should draw Inman Square, that it and its denizens had a lot of flavour. He looked at me with newfound respect: "I see. So you've got the eye too."

Now perhaps I should have been alarmed when he asked repeatedly for my name and where I worked, but at that point Me'Shell NdegeOcello's Better by The Pound was ringing in my ears keeping me relaxed. And also, the kind of look that came on his face when it appeared that our great philosphical conversation was about to end as the bus reached Lechmere station would properly be said to have a hint of desperation about it. As we got off the bus, I noted that a canny MBTA marketing person had emblazoned the following slogan on the sign where the 69's destination would normally reside

Stay Cool on the T

Stay Cool indeed.

In parting Charles couldn't resist being provocative and outrageous, the last question he asked was "how do we know at what age women become sexually active?". Now I admit that at this last, I did look around to see if there were witnesses to our taking leave of each other and it was with some disquiet, or even panic, that I handed him the 5 quarters that I hastily managed to dig up from my bag, "for a coffee you know". In this vein, I made sure to give an alias, and to take a circuitous route to the office all the time checking that I wasn't being followed. Even though a sensitive soul like him is usually harmless, better be safe than sorry; one never knows. As I reached the office and unpacked my laptop, it was indeed shuffle serendipity that Jamiroquai's Virtual Insanity would be playing in my headphones. I listened to the lyrics before my thoughts went back to XForms and glue layers.

And nothing’s gonna change the way we live
Cos’ we can always take and never give
And now that things are changing for the worse,
See, it’s a crazy world we’re living in
And I just can’t see that half of us immersed in sin
Is all we have to give these

Futures made of virtual insanity
Now always seem, to be governed by this love we have
For useless, twisting of our new technology
Oh now there is no sound for we all live underground...

And now every mother can choose the color of her child
That’s not nature’s way
Well that´s what they said yesterday
There’s nothing left to do but pray
I think it’s time I found a new religion
Waoh it’s so insane to synthesize another strain
There’s something in these futures that we have to be told.

But that is all part of the territory. That's the sloppiness of life on the bus. I suspect that some of you prefer the convenience of the car, mobile phones and other creature comforts. The aesthetic of my kind of bus is very local, and low-brow some have said.

On the Chinatown Bus

I also regularly take the Fung Wah bus between Boston and New York. At $15 for a roundtrip it's a great deal. I'm a little disappointed that these days they leave from South Station rather than from the gates of Chinatown. Back when it was a lower budget affair, there were no announcements, no preliminaries and only plastic bags for you to dump your sandwiches and dogeared newspapers in. You bought your tickets at the back of a bakery and gathered at the side of the street and performed mime language with the drivers and the organizer, typically an old chinese woman who didn't speak english. One wondered if the drivers had licenses or were there illegally.

The kinds of buses that far too many people seem to be advocating (ESB, WS-* and SDO for example) are akin to the private jets of Enron or Tyco CEOs. I'd only note that Fung Wah is eating the lunch of Greyhound, Peter Pan and Amtrak these days. Their no-fuss utilitarian bent has attracted first those cheap college students and of late even mild-mannered housewives. Now they have a website and you can even book a ticket online! They are moving inexorably up-market like some others.

But anyway I digress...

I hope this has been a diversion. We've stretched our feet a little at the REST stop. I've gotten my Big Macs from the bored teenagers behind the counter, you probably got a caesar salad instead of fingerful chilis from Wendy's. We have to keep in mind that the Chinese bus driver is unemotionally apt to leave you behind in Connecticut if you don't pay attention and spend too much time navel gazing. Those Chinese will leave you behind.

In closing and as is my wont these days, I'll invoke the blog:

Lights Out.

Let's get back on the bus.

Koranteng (ducks)

P.S. I'm working on less frivoulous contributions to the debate and perhaps I will be able to share in coming weeks.

See also: On the Importance of Biting Satire

Update 2005-05-10: More Glue Layer People

See also: my other REST writings.

File under: technology, adoption, standards, systems, web, programming, design, architecture, glue, ESB, REST, web, services, whimsy, toli, Cambridge, life, soul, bus, Chinatown, music, movies