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