When Apple recently announced their new iPhone 4 at their World Wide Developer’s Conference, they said it would be available for pre-order or pickup reservation on June 15 in preparation for the June 24th launch date. And true to their word, sometime not quite an hour after midnight, Pacific time, the Apple website began allowing people to either pre-order phones for shipment or to make a reservation to pick up the new phone(s) at their favorite local Apple Store.

This worked pretty well, for perhaps a minute and a half or so.  Then the proverbial you-know-what hit the fan.

Almost as soon as the Apple website started processing orders and reservations, things started to go wrong.  A wide variety of problems started happening and it wasn’t long before your chances of winning the lottery were better than your chances of completing a transaction on their website.

I personally tried numerous times to make a pick-up reservation, starting at about 12:30 am, but the website simply could not complete the transaction.  I tried doing it with my iPad.  I tried with my PC and Internet Explorer, Chrome, and Firefox.  I tried with my iMac and Safari 5.  Nothing worked. 

I finally gave up and went to bed.  In the morning, I jumped out of bed and tried again.  No joy.   So I showered and got dressed and tried once again before leaving for work, but the only difference was that some of the error messages were different. 

Once I was at work, I started trying periodically to see if anything had changed, and finally at about 1:30pm I was able to complete the transaction for my reservation.

At least… I think I did.  Complete it, that is.  More on this uncertainty a bit later.

From what I’ve heard from others, it was late in the afternoon before the website started to work somewhat more properly.

There was something going around about a hacker attack on the AT&T website contributing to all the problems.  That may indeed have been a factor, but I don’t think it would have been such a big issue if the design of the system were more robust.  I haven’t heard any sort of official statement about the cause of the problem, but it’s not hard to spot several potential trouble spots with the design of the web pages and pre-order system.

How It Was Supposed To Work

First let’s go over the steps that were SUPPOSED to happen, then we can come back and look at what went wrong.

  • Step 1 — the user selects “Pre-Order” from the top right corner of the website’s “iPhone” landing page.
  • Step 2 — The user is presented with a screen where they specify more precisely which model they want.  For the moment, the choices are the 8gb 3GS, or else 16gb or 32gb, black iPhone 4.  The promised white model iPhone 4 is not yet available.  This step also shows you the ship date.  It originally said June 24, launch date, but as of now it’s saying July 14, so apparently Apple has already exhausted their initial stock.
  • Step 3 — The next step is for the user to specify their AT&T account status.  You tell them if you’re a new customer or an existing one, and also if you’re upgrading an existing phone or adding a line.
  • Step 4 — If you’re upgrading an existing phone, this step requires you to enter your mobile phone number, zip code, and last 4 digits of your SSN.  This information is used to determine your current phone plan and upgrade eligibility.
  • Step 5 — Now you get to see which price they’re asking for the model selected.  The price depends on your upgrade status and model.  Press CONTINUE again to get to the next step.
  • Step 6 — If you’re making a pick-up reservation, then you’ll see a list of your three closest Apple stores.  You can select one from the list, or enter a zip code to look up other choices.  Once you have the right store selected, you click “Continue” and…
  • Step 7 — This is the last page.  It tells you that you can go to the store any time after it opens on the 24th to pick up your new phone, and that you’ll need to bring your ID.

What Really Happened, And How It Might Have Been Avoided

So what really happened and why was it such a disaster?  Well, since I tried and and had it fail on me something like 40 times before it finally worked, I have some ideas on that subject.

I’m going to discuss the process of making a reservation to pickup the phone in-store.  Undoubtedly making a pre-order to have a phone shipped to you is somewhat different, although there is probably some overlap in the earlier steps of the process.

Steps 1-3 are more or less simple web pages without any significant processing going on.  The first big weak point with the whole setup happens at step 4, where Apple’s website has to send the data they’ve collected to AT&T’s server in order to retrieve your account status.  The issue here is that if AT&T’s server is slow to respond or fails altogether, then Apple’s website is unable to proceed.

This failure to get a timely response from the AT&T server is the primary cause of the whole problem, but it wouldn’t have been so bad if Apple had made a better attempt to recover from the error, rather than simply throwing up an “Opps, We’re sorry” message.  As the site’s currently designed, the problem essentially feeds on itself and makes itself worse and worse, like a snowball rolling downhill. 

Here’s the problem: as soon as errors start to occur, people go back to the beginning and start the whole thing over again, at least a few times.  This just makes the server load worse at a point where it’s already throwing errors.   And that means more failures, and more failures mean more and more people starting over and failing again, then starting over and failing again, etc. 

One preventative measure that could have helped to avoid these cascading failures would have been to cache the response from the AT&T server in step 4.  This could have been done very easily by placing a cookie on the user’s system, or by using server session variables.  Sure, there are some legal concerns here, and it may have required a paragraph or two of fine print, but I doubt most people wanting to pre-order the new iPhone would be too concerned about Apple and AT&T sharing information.  Most of those people probably expect that information is shared in the first place.

Also consider that better use of Ajax in these pages might have meant the information could be saved temporarily without the need for either cookies or server session variables, avoiding the legal concern altogether.

It’s less clear if Apple’s site had to contact AT&T’s servers again for later steps in the overall process, but if so, then the same ideas apply to those steps as well. Caching the responses from AT&T wouldn’t matter when everything is working fine, but in a failure situation it would help reduce the overall load on the server, and that could have made all the difference in the world.

Another thing is, Apple should have had some mechanism in place to monitor the server load and take appropriate action if it was getting too high.  For example, for in-store pickup reservations, instead of this interactive step-by-step process, it could have simply collected the user’s data and saved it (along with a timecode) for later processing and confirmation via email.  This way, the server load for confirming the information with AT&T’s server could be independent of the number of people attempting to make reservations.

Apple’s webpages seem to have no idea how to deal with failure other than by giving the user an error message.  They should have had some built-in timeout and retry mechanism so that they could recover if the server did not respond the first time. There should have been some sort of more detailed indication given to the user about what was going on.  2 or 3 minutes of staring at the little rotating animated icon gets a tad boring.

And speaking of error messages, I cannot even begin to tell you how disgusted I am regarding this message I saw on the majority of my failed attempts last night and this morning.  After I’d sit patiently for several minutes waiting for Apple’s site to get a response back from AT&T”s servers or from their own servers, they had the unadulterated audacity to tell me that my session was closed due to inactivity!  Whose inactivity are they talkin’ about here?!   And aside from the inherent stupidity of the message in general, it’s compounded by the fact that you’d get this message within 4-5 minutes of starting the pre-order process.  Who the heck decided that 5 minutes was the ideal lifetime of these sessions?

Now if you tried the system and got as far as step 5, congrats.  Most of my failed attempts died in step 4.  However, at the step 5 to step 6 transition, we’re back to pinging the server for information.  Not sure what, except maybe the list of Apple stores nearest you.  And once again, this is information that should have gotten cached so that we don’t have to bang the server if we end up going through process a 2nd time.  Or a 3rd time.  Or a 33rd time.  And there’s really no excuse here, since this step didn’t involve sharing data with AT&T.

I got as far as step 6 on five occasions.  The first four times it failed.  The fifth time, it finally went on to the final page, telling me that my reservation was complete and that I needed to bring my ID with me when I came to pick up the phone.  However, when I tried to print the page, the browser (Apple’s Safari) crashed on me!

After the print attempt crashed, it occurred to me that there was no email confirmation of the reservation.  This seemed odd, especially since I’d just done a similar process a few months earlier when I reserved an iPad, and they DID send me a confirmation email that time. This lack of confirmation is why I had a degree of uncertainty about having successfully completed the reservation process.

This is an APPLE User Interface?

While one might make the argument that “web pages don’t count” or something like that, as a long-time Apple user I expect better user interface design than what we see in these pre-order pages, even when they’re working properly.

For starters, the overall process was broken up into too many steps, and some of those are unnecessary.  Why make the user go through any more steps than absolutely necessary?  Sometimes if you have a big, complex form, there’s a good argument that breaking it up into smaller chunks will make it easier for the user, but really that’s just not appliciable here. There’s really just not that much information collected from the user.

In step #2, you’re shown a choice of phones and must select a different “Pre-Order” button for each in order to proceed.  And yet, we see our choice again in step #5 and have to press “continue” to keep going.  I understand that step #5 is also verifying the price after your account information has been confirmed, but we could have combined that into step #6 quite easily.

Another thing is, verifying your account information isn’t strictly necessary for all of the steps that follow.  It’s really only needed so we can see the right price.  So why is this a synchronous process?  That brings up the point that this whole process was actually using multiple separate pages instead of a single page where everything was refreshed as needed via Ajax.  Making better use of Ajax would have made the pages worth more smoothly and also would have reduced the overall server load.  It also could have meant that the pages could remember the user’s input in step 3 for use later, without having to use cookies or session variables.

Last of all, I’m amazed that when I finally did get to the end of the process, there was no mention of any confirmation email being sent out (nor did I receive one anyway).  This is a big oversight.

Here’s how it should have worked:

Here’s what the process should have been.

Step 3 — Ask the user for their mobile phone number, zip code, and last 4 digits of SSN.  Also ask for their name and email address.  If this is not the user’s first time through this step, then these fields should be pre-populated with the information saved in a cookie or the server’s session information.

Step 4 — Send data off to AT&T for account validation, asynchronously.  While waiting for response, show the user price information based on the input from step 3.  Include a big note that this information is pending account confirmation. When the account information is validated or not, update the display.  Show a selection of Apple stores within 50 miles of the user’s zip code so they can select for in-store pickup.

If AT&T’s server fails to respond within a reasonable timeframe, then Apple should SAVE my information into its own database so that it can retry later and send me an EMAIL-based confirmation once it’s able to get a response.

Step 5 — User selects “continue” to confirm reservation.  Page posts transaction to the Apple server, and is updated with final instructions once the transaction completes.  We’re also told that an email confirmation will arrive soon.

We’ve eliminated two steps, made it easier for the user if this is a retry, reduced the server load, and given the user more peace of mind with a confirmation email.