The timing of the initial rollout of the new reservation pages was such that I did not have much of a chance to give them a workout for at least a few weeks. I still wouldn't say I've given them a "thorough" workout, but I've worked with them enough to assign a tentative grade, which I'll break into two components.
- For the design (how it looks): B-
- For the implementation: F
To those who complained upthread about speed issues: I retract, and offer a full apology for, my earlier comments in support of the performance of the new reservation page. It works well enough on some platforms, but not on others. If you don't have one of the recent ultra fast browsers, the new reservation page is virtually unusable. Below is a thumbnail image of a screenshot showing the absurdly high demand the new SWA pages place on the CPU when rendered in Firefox 2.0.0.20 on one of my computers:
Southwest
For comparison, here is SideStep running in the same browser:
SideStep
The spikes have labels indicating what action caused them, which you can read if you click the images to view the larger versions on PicasaWeb. If you do follow the links you can then right click to view the image at full resolution, if need be.
Although I didn't take the time to generate screen captures, I also looked at the CPU demand required to use the smart search features of marriott.com, choicehotels.com, google.com, and en.wikipedia.org. With the exception of marriott.com, CPU loads were all trivial, generally even less than shown above for SideStep.
Programmer egos often prevail over usability, bringing horrible features like multi-level rollout menus and Flash interfaces. I was
extremely relieved to see the redesign team avoid those sorts of problems. There is no excuse, however, for this serious performance issue not being caught in the beta test stage.
If you have trouble with the speed of the new primary reservation page, I advise using the
old page or the widget on the
main page.