• Usability
  • Making Bookings
    • HCI Analysis
  
  
• Comparison With Requirements
  • Minimum Requirements
  • Objectives
  • User Requirements

Evaluation

There are many aspects of this project to evaluate. These include evaluating functionality, usability, and reliability of the site. Evaluation of the functionality is related to the functional requirements, and was covered in Chapter . Evaluation of usability and reliability tie in with quality requirements, [#!hughes_cot!#, page 13] and is the main focus of this chapter.

Additionally, this chapter will compare the finished system with the minimum requirements, the objectives, and the user requirements.

Usability

The evaluation for this section will be based around HCI principles, including the keystroke-level model [#!dix!#, page 246], and around timings of users performing simple operations such as making a booking on behalf of a user.

Note that any timings done will primarily focus on operations which would be carried out by a Sports Centre staff member, since it is more important that the system be fast to use for these users, than for sports users booking for themselves. In the former case, making an improvement of ten percent on a particular operation could save a significant amount of time during a working day, but in the latter case, most users are unlikely to notice such a small improvement.

The following sections will report the results for a number of common operations permitted by the system. All timings, except R (response) timings, are based on the sample timings for various operators in the KLM, [#!card_hci!#, page 264] [#!dix!#, page 248] as shown in Table . The R timings are based upon averaging out the time taken to download the requested page from the web server, using a non-interactive Perl script. An additional ten percent was added to each time to account for extra time taken by the browser to render the page. Time taken to download images has been ignored here, since for the vast majority of bookings, these images will be present in the browser's local disk cache, and therefore can be loaded in a negligible amount of time.

Table: Sample KLM timings [#!card_hci!#, page 264] [#!dix!#, page 248]

Operator Remarks Time (s) K Press key     good typist 0.12   average non-secretary typist 0.28   typing random letters 0.50   worst typist (unfamiliar with keyboard) 1.20 B Mouse button press     down or up 0.10   click 0.20 P Point with mouse     Fitts' law   average movement 1.10 H Home hands to and from keyboard 0.40 M Mentally prepare 1.35 R Response from system -- measure -

Making Bookings

HCI Analysis

• Entering new booking screen: H[mouse] PB[left] = seconds

• Stage 1: R(1.18) M PB[left] M PB[left] M PB[left]= seconds

  (Assuming the booking is for one of the four most popular activities, and is within the next four days.)

• Stage 2: R(1.21) H[keyboard] M 7K[username] H[mouse] M PB[left] PB[left] = seconds

  (Assuming the average username is seven characters long, the reception staff are average typists, and that on average a booking is for one slot only.)

• Stage 3: R(3.70) PB[left] = seconds

  (Assuming the user does not have to top up their credit.)

• Stage 4: R(1.17) = 1.17 seconds

The total time here is 26.27 seconds. The author estimates that a booking using the current system would take no more than 15 seconds, so at first sight the online system would appear to be require almost double the amount of time. However, the benefit comes from the assumption that many bookings will be made online, instead of at the Sports Centre reception. If 50% of bookings were made online, then this would reduce the average amount of time required by the Sports Centre staff to just 13.13 seconds per booking, which is already an improvement over the current system. Eventually, the number of bookings made online would almost certainly increase further.

Also, the time required by members to make bookings would decrease substantially. Most members will almost certainly use an Internet connected computer quite frequently, whether at home or in a university cluster. As they could make their bookings from any computer, the time taken to travel to the Sports Centre would not be included in the time taken to make a booking.

Comparison With Requirements

Minimum Requirements

The system correctly implements all of the minimum requirements (Section , page ).

Objectives

The primary objective listed (Section , page ), to handle bookings for any venue, was successfully implemented. Although the database at the time of writing does not include all venues, the system supports adding any venue to the database, so this feature is implemented correctly.

The second most important objective (periodic bookings) was partially implemented; such bookings could be entered, but they were not copied to the real bookings relation in the database. This was simply due to a lack of time towards the end of the project, and evaluation was considered more important at that point.

The remaining objectives were not implemented, also due to a lack of time. These objectives would all be fairly easy to implement, and are simply left as potential future improvements.

User Requirements

The most important user requirement (Section , page ) was simply to implement a working system, and this was successfully implemented. The only required feature which was not even partially implemented was periodic restrictions. Some features, such as periodic bookings, were only partially implemented, but completing the implementation of this particular feature would be very easy -- there was simply not enough time remaining at the end of the project to do it.

Many of the optional extra features listed in Section were not implemented, because the implemenation of the more important features, and the writing of the report, was more important and required more time than originally expected.