A consumer-oriented application, often referred to as an e-commerce application, needs to do a lot more than just be functional. In particular it needs to provide an attractive and persuasive showcase for the products—after all there's no salesperson standing behind the user to explain why they should purchase one of our cars.
So, as well as the functionality we've already seen in the previous chapters, we need to add a section that displays the cars and lets the customer choose which suits them, and how much it will cost. We also have to think about the way the application will work for our clients, for example, whether it will be responsive over their Internet connection, and whether will it work on their browser. And of course, can our server support the (hopefully) thousands of users that will be running it?
The first step is to think about how we can divide up our application. These divisions are not supposed to be visible to the user, who expects the entire site to be integrated and provide a consistent environment. Instead, they are designed to allow us to build and maintain the sections more easily, and interchange them in the same way as we would interchange components in the 'back end' processing parts of the application. Some general sections might be:
We might also have sections for customer feedback, support, inquiries, etc.—though for simplicity we haven't implemented these in our Wrox Car Co sample application.
If we're going to actually sell anything, we need to provide an interface that is attractive, responsive, and will persuade potential customers to part with their hard-earned cash. In the Wrox Car Co application, we open with a list of the cars and some small graphics, together with a simple animation to catch the eye:
Customers can select a car model and get more information about it by clicking the Details button. To make it more exciting we allow them to choose a color and see what the car looks like in that color. (OK, so our graphics are a little less sophisticated that you'd see in a professionally designed page, but you get the idea):
If you want to see just what is possible, take a look at the CarPoint site at http://carpoint.msn.com. It uses an ActiveX control called Surround Video, which lets you view and pan around the inside and outside of the cars.
We can also offer specially tailored finance packages on our cars. A simple page allows users to choose how they would like to pay for the car, and see what it will cost each month. This uses a combination of techniques, including the
component that we built earlier in the book: WCCFinance
If you're wondering why clicking on a car doesn't immediately open the Details page, it's done to allow user to select the Finance page instead if they wish.
We make it easy for users to place an order for a car with a button on the main page. This presents them with a choice: they can order via our secure site (which uses SSL and certificates to provide encrypted communication) or through the normal anonymous HTTP protocol. Many users are nervous about submitting information over the Web, and this helps to allay their fears. If they opt for the secure site, we use the contents of their client certificate to pre-fill some of the order details as well:
The order is submitted to our order processing components, and a response is returned to indicate if this was successful. Normally this part of the process is the most difficult to implement. However, because we've already created a complete DNA-compliant core order processing function as a set of components (which we used with the showroom application earlier in the book), we've already got everything we need.
This is, of course, one of the main reasons for sticking rigidly to a design philosophy like DNA—we reuse existing components and business logic functions without having to worry how they work. As was in fact the case with the Wrox Car Co Web application, the developer who builds the client interface section doesn't need to know anything about how the back-end business functions work.