Why, Blog, Why?

A few months back I came away from TicketMaster.com with a really bad taste in my mouth, and 2 really expensive tickets in my pocket.

Unlike a traditional e-commerce site where you have time to evaluate your purchase before checking out, TicketMaster.com has unrealistic time limits on each step of the checkout. After searching for tickets, here's what they give you:

Confirm seating selection: 2 minutes
Log in or sign up for a new account: 1 minute

Complete purchase: 2 minutes

In the first step, it took nearly 2 minutes just to pull up the web site of the venue, find their seating chart, load their ridiculously slow Seating Chart Java applet, enter the section and row of the seats that TicketMaster was holding for me, and wait another 20 seconds for the 360-degree panorama to load. So by the time I did that and saw that they were really good seats I had just enough time to go back and click Continue. I had already been burned once by the time limit, so it felt like a pretty high-presure sale situation the second time around.

Next screen: sign up for an account in 1 minute. 7 fields (one of which is hidden until the end), 1 minute total, 8.5 seconds per field. That's crazy.

Last step: Checkout, 2 minutes, including billing and shipping info. Have you ever been rushed trying to enter a credit card #? You are guaranteed to make a mistake.

I was a bit shocked today to land on an Amazon.com product page and not recognize their new layout. Gone are the ubiquitous "tabs". Here's what I sent to them via their feedback form. (See the Functioning Form blog for a history of Amazon.com designs, including the new tab-less design.)

Every web design book that I've come across uses the Amazon "Tabbed Interface" as an example of "what works". It's ubiquitous as a design element that is simple, useful and compact. Certainly it has its limits as tabs are added (My Firefox browser is averaging upwards of 30 tabs and its difficult to wade through), but I would certainly argue that tabs are more user friendly than drop down lists (specifically non-UI-native, script based [JavaScript/CSS/whatever] drop-down lists) which are not always immediately intuitive and often quirky between browsers. I would prefer tabs - in fact I thought you had it right with the hybrid interface of most-often-used tabs with a drop-down overlay of other services. It allowed for easy access to (what I felt are) the most important sections, and everything beyond that was as close as a single click.

If the drop-down list must stay, please make it stay open on click (rather than a hover effect) with an explicit close/cancel button, otherwise I find myself chasing the menu with an over-zealous mouse. Older users may find the required precision difficult to master as well. Additionally, the target for showing the list should be bigger than the arrow graphic for the same reasons.

From Amazon's Q/A article on the design change it sounds like this has been something they've worked on for a while, so chances of them rolling back to the old design are slim. Still, given how often the tabs are cited as good design elements its sad to see them retired. I've yet to find a user interface that's as easy to use as virtual tabs.

A co-worker of mine just got back from the Webmaster Jam Session and relayed this metaphor for Sharepoint, Microsoft's CMS/Portal/EBTKS-ware, which we have been evaluating:

Implementing Sharepoint is a lot like building a house. It's like a friend of yours says, 'I know exactly what to do.' And, he drives you to a Home Depot, drops you off at the front door and says, 'Everything you need is here.'

Paraphrased from Jared Spool

Here's a link for all my developer friends:

HTML 5 is still being drafted, but here is an early list of differences from the current HTML 4 spec. There is some very interesting stuff being proposed for this version. One thing that caught my attention early on is that the specification won't be considered complete until there are at least 2 complete implementations of the draft - something very different from previous versions. Also, the input element will have a lot more choices for the type attribute available, such as date pickers and true combo boxes. It will be interesting to follow this through the draft process. And the specification will have two sets of guidelines - one for web developers/content writers and another for browser/user agent developers. (One reason why <font> is not dead in HTML 5 )

http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html

In related news, the W3C is calling on all web professionals to participate in the HTML 5 discussion.

Since I just spent the better part of Friday debugging this problem and then the better part of Friday night Googling for a work around, it's worth noting that there is a "bug" in the Firefox implimentation of the xmlHTTPRequest object when using it for synchronous calls (i.e. the rest of the script pauses and waits for the request to complete, unlike typical asynchronous AJAX calls). When using the xmlhttp object in a synchronous fashion, Firefox does not process the onreadystatechange handler. Thus, any libraries that are dependant on this (for running post processing functions for example) will fail to work under these conditions. Interestingly, having the Firebug extension installed causes the object to behave properly. So a secondary note is to always test your apps in a "clean" instance of Firefox.

Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem.

I've also set up a set of tests to demonstrate the problem. Try in both Firefox and IE to see the differences.