لطفا منتظر باشید ...
Internet User Interface
Let's look in detail at the public Internet user interface. This illustrates many common issues in building J2EE web applications.
Basic Workflow
Although I've used UML state diagram graphics, each box represents a screen presented to a user successfully choosing a performance and purchasing a number of tickets, rather than a state. The following diagram shows an Internet user successfully booking seats:
Users are initially presented with the welcome screen, a list of all genres (such as Opera) and shows (such as Wagner's Tristan und Isolde) playing at the X Center (see Application Screens below for screenshots). Users can then proceed to the display show screen, which shows all performance dates for a given show, along with the types and prices of seat on sale and the availability of each type of seat. This screen should indicate only whether each type of seat is available or sold out, not the number of seats remaining. This meets the needs of most users while avoiding disclosure of sensitive business information – for example, those tickets to a particular show might be selling poorly. Users can request a number of seats of a given type for a particular performance, in which case these seats are reserved to allow time for online credit card payment.The system distinguishes between the concepts of reservation and confirmation/purchase in the booking process. The user can reserve seats for a performance for a period of time (typically 5 minutes), which will be held in system configuration. Reservation protects these seats from being shown as available to other users. Confirmation occurs when the user provides a valid credit card number, at which point a reservation becomes an actual purchase. Reservations are held in the database and in the user's session state. Reservations must either:
Progress to bookings as a result of confirmation.
Expire, if the user fails to proceed to purchase in the given time. These seats will then be available to other users. However, the user who made the reservation may still purchase the seats without seeing an error message if they are still free when (s)he submits the payment form.
Be cleared, as the result of user activity other than continuing on to purchase. For example, if a user makes a reservation but then navigates back to the display show screen, it is assumed that (s)he does not want to proceed to purchase these seats, and that they should be returned to fully available status.
Error Handling
In the event of a system error (such as the J2EE server failing to connect to the database), the user should be shown an internal error screen consistent with the current branding. This should advise the user to try again later. Support staff should be notified by e-mail and through the log file record in the event of serious problems. The user must never see a screen containing a stack trace, "500 Internal Error" or other technology or server-specific error message. A user requesting an invalid URL should see a screen consistent with the current branding advising that the requested page was not found and containing a link to the welcome page.
Application Screens
Let's now take a closer look at workflow in the public Internet interface. The following diagram is a more detailed version of the previous diagram, and shows all screens available to the Internet user, and the transitions between them:
The additional detail concerns failures to complete a booking and the optional user registration process. The user can fail to proceed to reservation or confirmation under the following circumstances:
The user requested the display show screen and left a long delay before following one of the links to the book seats screen. By the time they proceeded to this screen many more seats had been sold and requested type of seat was no longer available.
The only seats that can be offered to the user are not adjacent. The user does not wish to accept this, and follows the try another date link back to the display show screen. The unwanted reservation should be cleared and the user must begin the booking process again.
The user made a registration, but failed to submit a credit card number in the lifetime of the reservation. This is not a problem unless the seats have been reserved or purchased by another user. In this case, the problem is explained to the user, who is reassured that their credit card was not debited and offered a link to the display show screen.
The user enters a credit card number in a valid format, but the transaction is declined by the credit card processing system. In this case, the user will be informed that the credit card payment was declined and that the reservation has been lost. The reservation is cleared, and the user must begin the reservation progress from scratch.
The registration process is optional. It allows users to enter a password to create an account that will save them entering their billing address and e-mail with each purchase (other premium services may also be offered to registered users in the future). Users should not be forced to register to purchase tickets, as the management feels that this may reduce sales.Registration will be offered after a user who is not logged in, and who has provided an e-mail address not already associated with a registered user, has made a booking. The user's username will be their e-mail address, which is entered in the course of the booking process. When a user registers and the application detects that the user's browser is configured to accept cookies, their username will be stored in a persistent cookie enabling the application to recognize their registration status on subsequent visits and prompt for a password automatically. This prompt will be introduced into the registration process through a distinct screen between the reservation and payment details screens. The following rules will apply:
If the user is logged in, billing address and e-mail address (but not credit card details, which are never retained) will be pre-populated on the payment details form.
If a persistent cookie containing the user's e-mail address is found but the user is not logged in, the user will be prompted to enter a password, before proceeding to the payment details form. The user can choose to skip password entry, in which case the persistent cookie will be deleted and the user will see an empty payment details screen.
If the user isn't logged in and doesn't have a persistent cookie, there should be a link on the show reservation page to allow the user to try to log in by entering both username and password before seeing the payment details screen. In the event of successful login, a persistent cookie will not be created.The screenshots that follow the table present all the controls and information required on each page. However, they do not fully define the presentation of the application: for example, these screens might be used as the content well, with a custom header and side columns being added. There may be more than one such branding: it is a business requirement that the technical architecture allows this cost-effectively.The discussion of each screen concludes with a summary of the required handling of some common issues with web interfaces, in the following format:
Screen | name The name of the screen as discussed in this chapter and shown in the diagrams above. The table describes the outcome of a request that will lead to this screen if successful. |
Purpose | What the page does (for example, "display user profile"). |
Alternative screens | Alternative pages that may result from a request that would normally produce this page (for example, the behavior resulting from invalid form input). |
URL | URL of the page within the web application, such as /welcomel. Note that although the chosen extension is html, all pages are dynamic. |
Data displayed | The data displayed on this page, and where it comes from (database, user session etc). |
Requires existing session state | Yes/No. |
Effect on existing session state | What happens to existing session state (such as a seat reservation) following a request to this page? |
Effect of refresh/resubmission | What happens if the user refreshes this page? |
Effect of the back button | What happens if the user hits the back button? |
Parameters required | Lists the names, types, and purpose of the parameters required. |
Effect of invalid parameters | What happens if the expected request parameters are missing or invalid? |
This summary will be valuable as a basis for testing the web interface.
Welcome Screen
This page provides an index of all shows and performances currently available. It may also include static information and links about the X Center. The aim is to minimize the number of pages the user has to work through to perform common tasks, so this page allows direct progress to information about each show, without making the user browse intervening pages:
The page must be dynamic: genres and shows must not be hard-coded in HTML. The number of genres will not be so great in the immediate future that having a separate drop-down for each genre is likely to become unworkable. However, the system architecture must support other interfaces, such as splitting this page by having a separate page for each genre, if the number of genres and shows increases significantly. The user's first impression of the system is vital, so this page must load quickly:
Display Show Screen
This screen will allow the user to choose a performance date for a show in which they are interested, and proceed to make a booking. It will also provide information about the show in question such as the history of the work being performed and cast information. It is expected that some users, reluctant to use their credit cards online, will only use the Internet interface to this point, before calling the box office to purchase tickets on a given date; this is an additional reason for providing comprehensive information on this page:
No support is required for pagination in Phase 1 (although this is a potential refinement later); the user may need to scroll down to see all performances. For each performance, there is normally a hyperlink from each type of seat to the booking page. A superscript is used in place of a hyperlink to indicate that the given class of the given performance is sold out:
Book Seats Screen
To arrive at this screen, the user selects a performance date and ticket type by following a seat type link – in the screenshot above, one of the AA, A, B, or C links in the table on the right:
Show Reservation Screen
This screen results from the successful reservation of the number of seats requested. This is the first operation resulting in the creation of session state:
Payment Details Screen
Note that the password prompt or login page may appear before this page, and may result in pre-population of address and e-mail fields for logged in users. Credit card details will always be blank, as they are not retained under any circumstances:
On an invalid submission, this page will be redisplayed, with the missing or invalid field values highlighted and an error message for each field explaining the problem. The exact means of highlighting errors is a detail to be decided later. However, the system should support different styles of highlighting.All fields are mandatory except line 2 of the address. The following validation rules are to be applied on submission of the form on this page:
Credit card number is 16 digits.
Credit card expiration date is 4 digits.
Postal code is a valid UK postcode format (for example SE10 9AH). However, no attempt will be made to check that this is a real postcode (Submissions that look like UK postcodes may be syntactically correct but semantically meaningless). It is the user's responsibility to enter their address correctly. In subsequent releases, other countries must also be supported, and postal code validation must be implemented based on the country selected from a dropdown. Only a fixed subset of countries will be supported, as the cost and reliability of posting tickets to some countries is considered unacceptable.
E-mail address must pass simple validation checks (that it looks like an e-mail address, with an @ symbol and dots in the right place). However, the transaction can still succeed even if the e-mail address does not prove to work; ticket purchase should not block while a test e-mail is sent.
No attempt will be made to validate the credit card number's checksum. This is a matter for the external credit card processing system.
Confirm Reservation Screen
This screen confirms the user's ticket purchase and provides an electronic receipt:
