A High-Level View

I l @ ve RuBoard

The Books for Geeks team has already developed a set of wireframes for the proposed Web site. Often the wireframes are produced by the HTML design team (either the client's team or an in-house team working with your group ). These people are usually somewhat savvy about usability issues and the limitations of the Web, so you, as developer, stand a pretty good chance of being able to use the design as is.

Occasionally, however, you get handed something that's totally unusable. Either the site flow is awkward , it requires the technology to do something that just isn't possible, or it opens up security holes. You could end up going through several iterations with the design team to get an acceptable set of wireframes.

With these principles in mind, you can look at the requirements for Books for Geeks (BFG). To begin, take a look at Figure 4.1, which shows an overview of the site flow based on the wireframes we've been given.

Figure 4.1. The BFG site flow.

In this site, all roads hopefully lead to a purchase. Customers enter the site, navigate to products that they want to buy, eventually check out with their shopping cart by giving payment and shipping information, and leave as happy shoppers.

In addition, the site should have some functionality to allow customers to maintain lists of addresses and credit cards so that they don't have to type in this information every time they visit.

Usually, you'll have a slew of questions for the client before you even begin to look at specifics, and building this site is no exception.

In the case of the BFG site, you'd want to know some things simply based on previous experience using or developing e-commerce sites:

• Is the customer allowed to purchase items before logging into the site? For that matter, do you require customers to have a registered account on the site before completing a purchase? In the BFG example site (as in most modern sites) the customer may register before buying, register as a part of the first purchase, or choose not to register and purchase the items as a one-shot transaction. As a result, you will need to handle all of these possibilities in the code.

• Where should the Buy button take the user ? On some sites, the Buy button is actually coded as a targeted form or HREF, which brings up an invisible target page that then adds the item to the cart without disturbing the main page. This can be very useful for allowing the customer to purchase many items from a page without having to hit the Back button. Other sites bring the customer to the cart view with each purchase. In the BFG case, the client wants to use the second method, adding the items by stealth using a target page.

• How technically savvy are the people who will be maintaining this content? Can they be trusted to create the right links for the Buy buttons ? How much technical handholding will they need? This will determine how much automation you might have to build into even a "static" page to make sure that the functionality is maintained .

These are just a few of many questions that you should have investigated up front because the answers inform the rest of the design process. For example, if the Buy button actually takes the customer to another page, do you need to have a way to navigate back to the previous page so that the customer can make other purchases from the same page? If the Buy button is an off-screen event, this isn't a factor.

When these type of questions are out of the way, you're ready to begin your examination of the site design in detail.

The Entry Page

A typical user experience starts with the entry page. Figure 4.2 shows a wireframe of the entry page. The entry page is statically maintained by the customer's creative department; it will be used to highlight one or more featured books, will offer navigational links into product categories, and will offer access to the customer's profile.

Figure 4.2. The BFG entry page.

When we say that the page is maintained statically, this means that the content on the page is placed there by HTML designers explicitly. In contrast, some of the pages deeper into the site are created almost purely by JSP operating against database data.

If you've visited many e-commerce sites, this will be familiar. The entry page is often highly stylized with many complicated design elements whose purpose is to entice the customer to purchase specific products. As you navigate down into product categories, the pages begin to look more like lists and less like a designed advertisement.

Sites are organized this way because it's very person- intensive to design pages by hand; this treatment is usually reserved for the top strata of the site. The more specific sections don't need to sell product as much because if you're on one of these pages, you presumably have an interest in the product already. Thus, the complex design is saved for the very few pages that serve as a first introduction to the products available.

This page includes a mini-cart, as do most of the pages on the site. The mini-cart gives a synoptic view of the current shopping cart contents, which is typically the number of items in the cart and the total price. Whenever you have content that will be replicated throughout multiple pages of the site, you want to immediately think about using server-side includes to isolate the content on functionality into a single file for maintainability.

You also need to think about the likelihood of mishaps when you have a page that has both complex JSP content and HTML content that will be frequently updated by nondevelopers. It's a very easy thing for an HTML designer to mistype an edit and break programmatic functionality embedded in JSP. That's why it's good practice to clearly demark JSP sections of the pages. Luckily, more people in the creative side of the business are familiar with JSP and know how to avoid breaking it.

Because there are individual products on the entry page, it is possible for a customer to click on the Buy button and directly add an item to the cart. In fact, the customer will be able to purchase items on any number of pages, so the buy functionality is another good candidate for a server-side include.

The Category View

Assuming that the customer doesn't want to purchase the featured item on the front page, several paths can be taken. The first path is to navigate down into one of the product categories, via either the drop-down menu or the sidebar. The sidebar, by the way, is another piece of reused content that should be considered for an include.

The category pages (see Figure 4.3) are an amalgam of static text and template-driven content. The item at the top of the page (the featured or "hero" product) is HTML copy hand-generated by the creative department, but the full listing of books in the category being displayed is produced by a database query.

Figure 4.3. The BFG category view.

The Product View

Along with the same "buy now" functionality available from the entry page, customers can navigate from the category page (or featured products on the entry page) to a detailed view of a specific product, as shown in Figure 4.4.

Figure 4.4. The BFG product view.

The page in Figure 4.4 is really just an extension of the "JSP page as a database-publishing template" model that is used for the catalog detail page. In other words, it's a JSP page that can be edited for look and feel but that actually gets the content from the database. As has already been mentioned, doing things this way means that you design most of the pages only once, for the master copy, and the actual pages are displayed by populating the master with the specific details of each product. In a site with a few thousand products, this is the only way that you can realistically get the site up.

An issue that needs to be addressed with the customer at this point is that of saved URLs in browsers. Will you expose the category or product IDs in the URL of the specific category or product pages? If not, you're looking at a totally different architecture (probably using the MVC model that you'll see in Chapter 16, "The Struts Application Framework").

Typically, JSP pages pass all of their information using form data and POST methods , as well as state information saved in session variables (for example, I'm currently looking at the catalog.) This method results in a single URL for the entire site, which has the advantage that the customers don't bookmark a page that would break if it was the first one encountered during a session. For example, this would be an issue if a customer bookmarked a page for editing account information and then tried to access it before he had logged in.

The countering argument about exposing arguments on the URL links is that sometimes it's useful to be able to save a URL that goes directly to a product or category. For example, if one customer wants to be able to pass on a pointer to a specific product to a friend, there's no way to do it when all the navigational cues are hidden from the URL. So, clearly, there are trade-offs in both directions. In the case of the BFG site, the client wants the category and product navigation to be exposed and wants the rest of the site ( especially the account editing) to use POST methods, to try to get the best of both worlds .

The Shopping Cart View

After the customer has filled his basket with a load of goodies , he may either go directly to checkout or review his cart on the full-blown order review page (see Figure 4.5).

Figure 4.5. The BFG shopping cart view.

Unlike the mini-cart that appears on each page, the shopping cart view lets the customer see the full details of the order, including promotional discounts , and gives the customer the ability to make changes in quantity or remove items altogether.

TODAY ONLY, 10% OFF!

Promotional discounts are an interesting part of an e-commerce Web site. I recently completed work on a site that had seven separate classes of promotions that could run in any combination, from BOGOs (buy one, get one free) to percentage discounts on categories of items.

Promotions can be a real challenge to implement. The site in question also wanted to be able to implement things such as "buy two items from a given manufacturer, get one free," which made the design of the rules engine quite complicated. In the Books for Geeks sample site, the client has asked for a relatively simple promotion model involving fixed-amount discounts on specific items. This is just enough to show the details of how promotions look and feel and how they can be implemented. In this case, a promotional value is shown by a cross-out on the normal price, and the promotional price is shown in red below it (as can be seen in Figure 4.5).

Here's another important point, one that clients often forget to think about: If you are going to have things like promotions on products and categories, this data presumably will be stored and implemented from a database. How does the client enter the data?

Administrative support can turn into as large-scale of a programming effort as the main consumer site itself. Many a project can be sunk by having these last-minute considerations appear as an "oh, by the way" item at the 11th hour .

In the case of the BFG site, the client has a savvy DBA who will manually maintain all the tables needed to keep the site happy. Trust me that there is basically nothing to be learned from actually showing the implementation of an administrative interface; it is basically a subset of the tricks that you use to deploy the main site.

The Checkout Page

After the customer approves the order or goes directly to the checkout page (see Figure 4.6) from the main site, he will need to fill in his customer order information, such as billing and shipping addresses, shipping details, and payment information. The customer order information is by far the most complicated part of most sites, including this one. There are a few different reasons for this:

• This page contains a lot of validation of data and error checking, and it might require the customer to return to the same page several times to fix bad entries.

• It must integrate with another part of the application ”the address book. This allows a logged-in and registered customer to avoid retyping the same information every time he makes a purchase.

Figure 4.6. The BFG checkout view.

When the customer has successfully filled out the checkout page, the application does a number of things behind the scenes. First, it uses a tax calculation application (which is stubbed out in the sample) to compute the proper tax. Next, it uses a third-party shipping application to calculate the shipping charges.

Third-party applications such as tax, shipping, and credit card validation can often remain undecided upon for the first few weeks of a project, as you and the client investigate different products for compatibility and price. The reason that no one in their right mind does them in-house is that they are incredibly complicated in anything but the simplest cases, and good (if sometimes expensive) third-party solutions already exist for them. This is another important reason to provide a good API between the rest of the code and these applications. I've worked on projects in which the tax application was changed three times during the course of the project.

The Order Confirmation Page

When the purchase information is filled out, the customer is taken to the order confirmation page (see Figure 4.7) to verify the order and shipping information one last time. Then the customer presumably will proceed to place the order, although a surprising number of customers "bail out" of an order at the last moment.

Figure 4.7. The BFG order confirmation view.

The Order Receipt

If the order is confirmed, many things occur between that page and the order receipt page (see Figure 4.8), specifically these:

• The application calls a third-party credit card authorization package (stubbed out here) to validate and charge for the order.

• The order details are written into the database.

• If the customer entered a new credit card or address and requested that this information be saved into his profile (assuming that this customer has created an account), this information spills back into those tables.

Figure 4.8. The BFG order receipt view.

If, by some miracle , all of this goes as planed, the customer is given a printable receipt. But suppose that it doesn't. Something could go wrong in so many places in the order pipeline just described, from a failure in a third-party application to a full database failure. You will need to work out with the client exactly how these failure notices should be displayed to the customer and what steps the customer can use to retry the operation.

In this sample BFG application, all roads of failure lead to a general "ooopsie" page that makes no attempt to return the customer to the road of virtue. A customer's only recourse is to hit the Back button and try again.

Account Maintenance

Another section of the site is devoted entirely to allowing the creation and maintenance of customer accounts. It begins on the main customer account page (see Figure 4.9).

Figure 4.9. The BFG customer account view.

This page is basically an informational and navigational tool. From here, the customer can do the following:

• Edit and create new shipping addresses (so that he can add a list of friends to buy gifts for).

• Edit a list of credit cards, each of which has an associated billing address.

• View his order history. This brings the customer to the order receipt page for specific orders. For the convenience of nonregistered customers, this page can also be reached from another form that lets the user enter an order number.

A NOTE ON SECURITY

The last item on the previous list, letting the customer view the order by entering an order number, is essentially a security hole, especially if order numbers are sequential.

It doesn't take a super-hacker to figure out that if someone can enter his own order number, he can enter others just as easily. For this reason, the order receipt page certainly doesn't want to display the credit card information ”at least, not more that something of the "**** **** **** 1234" variety. But even displaying the name , address, and books ordered allows anyone to invade the privacy of someone who thought that a private order was being placed. Even if you blank out the shipping information, a competitor could use a script to sequentially view every order on your site and know exactly what you're selling.

In these kinds of situations, you have explicitly exposed the method of your potential destruction, but a clever hacker could do this behind your back in lots of ways. For example, if you support a hidden form field value to pass the order number from the confirmation page to the receipt page, a hacker could save the confirmation page to disk, edit the order number to be one higher or lower, and then resubmit the form. If you don't write things just right, that hacker could view the order receipt. Worse, if you are a little bit too clever, the site might recognize that the hacker's order has already been placed and kick the hacker back around to the checkout page with the real customer's credit card information displayed.

Additional Questions

Just as you might want to know a number of things before you begin to examine the site, a number of questions might not be apparent until after you've completed a first walkthrough of the design:

• If the customer is not registered and checks off the appropriate box on the checkout page, is a new user account created for him? Yes, in the case of this site, even though this adds more complexity to the final order checkout process.

• We haven't talked about how registered users are identified. Usernames are complicated. Either you end up having the site generate names that no customer can remember (I'm JTurner234234 on www.geekbooks.com and JTurner435545 on www.nerdbooks.com), or you let the customer chose and then go through the cycle of selecting different names until he finds an unused one. In the BFG example, this username problem was avoided by using e-mail accounts as customer usernames. This can cause users in a household with multiple people but a single e-mail address to share an account, but those are a rarity and this doesn't pose much of an issue.

• The client might not have mentioned that e- mails go out when an order has completed successfully, when changes are made to the account, or when a user requests that his password be mailed (the infamous lost password page).

• Some pages (such as the lost password page) weren't included in the wireframes shown here. We'll do them on the fly during the development process.

I l @ ve RuBoard