iHotelier: Demonstrating the Potential of Flash for Web App Design

In terms of delivering content to all different types of platforms, developers have seen some real advantages with HTML. Before HTML, they faced major challenges creating applications when users had a variety of hardware, operating systems, and software platforms. We’ve gotten very used to the comforts of browser independence.

However, that independence comes at a price. HTML is a very clumsy language when you’re trying to build something with a sophisticated interaction stream. For example, take something that should be a straightforward development task, such as making a hotel reservation. All you need is the dates of travel and either a room is available in the database or it isn’t. If it’s available, you get the credit card and other guest information and you’re finished.

But, translating this simple series of actions into HTML code can make things complex. HTML really was never designed to take on user experiences that require a back-and-forth exploration of a large information system.

From a design perspective, creating a successful hotel reservation system can be one of these more complex user experiences. Users booking a hotel room have many different questions: Are rooms available for their planned dates? Can they reserve more than one room? How much will the room cost? What do the rooms look like? Creating a design that answers these questions while making the reservation requires a sophisticated interaction model and the tools to support it.

Recently, we came across a user, Bill, as he was planning a spring vacation to Walt Disney World with his family. We observed Bill as he visited the Westin Hotel’s web site. He told us that he has happily stayed at Westin Hotels many times in past years and the Westin is the first hotel he thinks of when planning a trip.

When Bill visited the Westin.com web site, he found the Walt Disney Swan Hotel, located in Lake Buena Vista, Florida. After deciding to book a reservation, the site asked him to specify his trip preferences.

If Bill were doing this over the phone, the process would be easy and straightforward. However, online it was frustrating for Bill. Using the form provided, Bill filled out his trip specifications including check-in dates, the number of room nights, the number of rooms, the number of adults staying in each room, and bed type. After he finished entering his room requirements, he clicked the “Continue” button.

Once Bill entered his request and pressed Submit, he found out on the next screen that no rooms were available for his specified dates. To reserve a room, Bill had to play a game of ‘hide and seek’ with the server, guessing when rooms could potentially be available, clicking submit, and waiting to see whether his guess was right. After unsuccessfully guessing available dates three more times, Bill gave up. When we asked him how likely he was to stay at the Swan Hotel, he told us that, although he enjoyed his past visits to the Westin hotels, he was too frustrated to continue on the site and would try to reserve a room somewhere else.

Westin.com missed a huge opportunity, turning away a loyal customer. The developers chose to implement their application in HTML and, because of this design choice, users often end up without finding available rooms that match their requirements. With HTML, the client is a “dumb” browser with limited logic capabilities and the server handles control of the application. At the press of every button, the client must connect to the server and the server responds with a brand new page to display.

This is the origin of the frustration with developing HTML-based applications. HTML constrains developers to fit complex application interactivity into a linear, page-based process. A server-driven HTML database query operates like a search engine, with users entering their full query, clicking a button, and then waiting for the server to return relevant results.

Unfortunately, users can’t get immediate response to their specifications and have to adopt a wait-and-see attitude as to what information will come back. (Even when developers try DHTML or sophisticated JavaScript to increase their flexibility, users may suffer. Lack of solid specifications has caused cross-browser compatibility issues, resulting in unpredictable behaviors on different users’ computers.)

This is why we’ve become interested with Macromedia Flash and other tools like it. Where HTML leaves off, Flash has the opportunity to fill in. Flash offers real advantages for developers.

A Flash-based hotel reservation system that has recently caught our attention is iHotelier. The iHotelier application has generated tremendous buzz among Flash developers and usability professionals—for good reason. It is one of the first applications we’ve seen that demonstrates how Flash-based applications can deliver users positive experiences, while simultaneously eliminating many problems associated with HTML-based applications.

The developers of iHotelier chose Flash to reduce the entire hotel reservation process down to a single screen. “iHotelier was the first Flash-based application I ever built”, says Jim Whitney, iHotelier’s creator and Founder/CTO of Webvertising. Jim says he chose Flash because he was always frustrated with the limitations of HTML.

Jim liked Flash’s power to connect to back-end databases when integrated with server-side software like ColdFusion Server and JRun. While it is possible to create UI gadgets, such as a calendar, in HTML, Jim believes users would find Flash-based gadgets much easier to use.

The Broadmoor in Colorado Springs is one of the hotels that currently use the iHotelier application to reduce the entire hotel reservation process down to one screen. The single-screen interface includes room availability information visually displayed in a two-month calendar interface, as well as hotel room prices and registration processing information.

Users looking for information on available rooms at the Broadmoor highlight their preferred dates in the calendar. With a single mouse click, the application displays the available (and unavailable) rooms and their prices. When users adjust their specifications, such as number of rooms or number of people for the hotel reservation, the pricing information automatically updates.

The Broadmoor’s implementation of iHotelier eliminates Bill’s problem with the Westin’s site. By utilizing the capabilities of Flash, users have the flexibility of interacting and getting immediate responses to their queries.

We know that iHotelier isn’t the perfect application. We’re aware that users may encounter several usability problems when they try to reserve a room at The Broadmoor. For example, we noticed that the Flash movie might load slowly on low-speed connections. (The Broadmoor actually offers an HTML version for those who don’t want to load it.) It’s also possible that some users will find the two distinct activities—finding an available room and entering the billing information—confusing to be on a single screen. However, these issues do not undermine the huge potential of the iHotelier application.

With HTML, developers are limited to a static design that users can’t manipulate without the cost of new pages reloading. With tools such as Flash, developers can create applications with advanced capabilities beyond what is possible with today’s HTML. Flash’s real potential to get past some hard problems makes it something we should seriously investigate for future application development.