The goals to be supported in the new system will be to select a cinema from a number of locations. A film menu describing each film with various information such as duration, which would help in the selection process. A flexible payment method and options such as disability needs, information on seating will be made.
So from the manual task I would keep the first two tasks. Choosing the cinema and film would be a good idea. Telling the cashier is a task that will be thrown out, as you are selecting from the screen and there is no need for that. Task 4 would be redesigned, because the payment method would need to change for an online system. I would allow both methods of payment, as leaving the customer to use one payment method (card) will be limiting the audience, and I want the system to be flexible. I will describe this in the requirements gathering.
Requirements Gathering
From the task analysis I described how a manual task is completed to book a ticket, and listed a few requirements as to what the new system should do. I am now going to look at other sources of information that the system should do and look at constraints that are put on the system by the user. I have also compiled a statement of requirements that will be divided into ‘functional’ and ‘non-functional’ requirements, which describes the manner in which it operates.
System Description
The system when accessed should welcome the user to the website and introduce the system with a brief description on how to use it. We could introduce Cinema Simon from the Cinebooking System, as he describes what to do on each page. The user should then have various options as to how they would like to choose a film, either by location, which will include various information, by film, which will include more than just the film’s title and then the time of the film. Once that has been chosen you will be presented with various options of the type of ticket you want, adult, child, including disability needs like wheel chair access. Once that has been completed the payment method should be chosen either by card or cash, and the next step in the process is your confirmation, which can be printed out as a receipt, this will confirm all the options you have specified.
Functional Requirements
The system should allow the user to:
- Select a cinema on the screen
From the HTA on page 3, task 1, people consider a number of factors before deciding to go to the cinema. Some people may wish to go bowling or clubbing after a film, others might want to go for a quiet meal, with a description of local bars, clubs and restaurants would help in deciding the cinema. Another factor is distance and transport, with a list of local bus routes and the nearest train station will appeal to people who have no cars or prefer public transport. These are useful information and would go a long way in decision-making. Most functional requirements are quantitative, but I believe this one is qualitative, as it would provide user satisfaction, as they can plan a night out from the online system.
- Select a film on the screen
When we go to the cinema we normally know what film we want to watch before hand, as we have seen trailers or heard about it from friends. From the HTA on page 3, task 2, some people might not have a clue as to what has been released lately or may even be spoilt for choice. Other constraints might be that they don’t like long films, as the seats are uncomfortable, so a short description of the film, with a list of actors in the film and duration would help them in their selection process. It will go further than just listing the film’s title.
This is a quantitative function, you cannot measure the success of this requirement.
- Select films that are on various times
This requirement will allow the user to make a choice on what film he/she might want to view by the time of the show. So if the user selects 7pm, then a list of films will be shown for that time. This option is also used in the cinebooking system, which I tested in coursework 1.
- Choose ticket type and special needs option
As this system is to be used by a wide audience, most cinemas nowadays have disability access, with an option for disability needs which would be ideal. Different prices are used for children and adults so options for these tickets would be included. This is justified in the HTA and in sub task 3 briefly, on page 3. There should also be 3 different prices; adult, children and students to cater for all users. I believe the is a quantitative metric as you could record the number of key presses for each option. If all options are being selected regularly then we will know we are getting a wide range of users.
- Choose and tell how many seats are available
A problem with the cinebooking website was that after you have chosen the film and given your booking details, it would often say that this film is not available, which is a nuisance after the long process of booking the film. A better approach would be to tell the user the number of seats that are available and tell the user if the film is sold out before giving payment details, that is a more logical step than the one implemented by the cinebooking system. This idea came from my visit to the cinema, which is mentioned in the HTA on page 3 and task 3, which mentions book a ticket if only it is available. We could measure this if we knew how many selections were made on a sold out show. This would be error recording and is a quantitative measurement.
A problem with online systems is that there is usually only one method of payment, I have introduced two methods. The first payment method is similar to the cinebooking website, you enter the card details and the expiry date and you confirm the details. This is justified in sub task 4, so after you have selected the film you pay for it by card or either cash. You can check if this requirement is used as much by the number of times the card transaction has been completed.
This is the second form of payment, the user is asked what payment method they want to use, if its card enter in the details, if cash the system should ask for the users details and give them a booking number, the tickets will then be booked and ready for collection at the cinema, simply provide the booking number. This requirement will allow people without credit cards to use the system as well, this requirement is justified in sub task 4, where I can pay by various methods at the cinema. To see if this requirement is used as much as the card, simply count the number of times it is use as it is quantitative
When I went to the cinema and booked my ticket I got a receipt as a proof, also the ticket acts as a proof of purchase, but it is valuable if a refund is required or want to keep track of funds. So the system should confirm the actions carried out by the user, the cinema chosen, the film, the time, the ticket type and payment details, also a reference number or booking number which identifies the transaction, which then can be printed out as a receipt. This is also justified in sub task 4, where I receive my ticket and receipt. I could measure the system with this requirement by seeing how many times the print button is pressed on the system, this will tell me if the system is used to print out receipts.
Non-Functional Requirements
The system should:
- Introduce and explain the online system
As I walked up to the cinema I noticed the welcome sign, and the cine booking systems introduction of Cinema Simon. This gives the system a friendly feel and the user would appreciate this introduction and warmth. With Cinema Simon on each page explaining what to do, the user will get be able to use the system. You can’t measure this requirement, you are either welcomed or not, and the help, is either helpful or no help at all?
- Be easy enough so a novice user can at least select a film and book a ticket without training.
The system should be able to allow novice users to access the system with ease, and choose a film without any unnecessary waffle. The user then should be able to confirm their booking with no problem. Novice users normally take more time with new systems, so an ideal way to measure this would be the amount of time spent on the system.
- Be efficient enough so a expert user can choose through the various cinemas and films on show, and choose the most appealing choice to him/her.
The system should also cater for the expert user, they should be able to go through each step of the booking process, with ease, and wander around the various films on show and other areas of the system at their own leisure. We could measure this requirement by the amount of time spent on a system.
- The system should hide all the technical data such as errors from all users apart from the administrator.
A problem with the cine booking website was the error message that used to come up frequently. The system should hide all technical details from all users apart from the administrator, to prevent this we have to make sure that the production of the system is secure and all design faults are dealt with during prototyping. I assessed this fault in coursework one, when I was testing the cinebooking system, I listed the fault under Nielsen’s ten heuristics.
- Be flexible enough to allow various methods of payment
Following on from the pay by cash and card requirement, by allowing different methods of payment will make the system flexible. From the HTA you can see that at a cinema you can by two methods, either cash or card, so implementing this flexibility into the system will appeal to users. We can measure this requirement by the various amounts of a people that book a ticket, if we get a large number of people who pay by cash and card, then this requirement has been justified.
- Be competent enough so a wide range of audience may use it.
I have included all different types of tickets to be sold, such as child, adult, disabled, and with two methods of payment so the system is flexible and will hopefully appeal to those audiences. The system is to be made easy to use so the novice user can browse around the system with ease, also appealing to the expert user and hopefully will not be undermined by the advice on offer. Hopefully with descriptions of local pubs and clubs will appeal to a wide range of users as well as the older generation who simply want to go for a meal or a quiet drink. This requirement is justified by the selection process in HTA sub task 1, different people want to do different things, by offering them what is next to the cinema will encourage them in their selection.
- Sensible steps i.e. tell the user if a film is sold out before giving payment details.
A problem with the cinebooking system was the order in which the booking process took, if the film was sold out or not available the user was noted at the end of the process, surely it makes sense to do this before payment is required so the user can go back and select another film. From the HTA you can see in sub task 3 that only book a ticket if it is available, if not go back to sub task 2 and select a different film. You wouldn’t go to a cinema and tell the booking office what film you want to watch, then after you paid you are told if it is sold out, it would be nice to know before you pay that’s more sensible. You cannot measure this requirement, as you have to engineer this process in the design so hopefully, if a film selected we would also know the number of seats that are left on the system, so the user can then change his choice if they like.
I have mentioned the requirements of the proposed system, what has to happen on the system, what information is made available, what actions are carried out and what the user will expect from it. I will use this information to design the system in the next stage. These requirements have been justified from the HTA on page 3 and 4, with observations of the manual task, and the flexibility involved in booking a ticket, I will implement this characteristic in the system and hopefully have the same flexibility in the system as in the manual task.
Design
This design is based on the requirements gathering from the previous chapter. I am now going to produce a design for my proposed website, with a storyboard, showing and describing its main features. I will then argue why this website fulfils the functional and non-functional requirements in the previous chapter.
Storyboard 1 – Introduction
Storyboard 2 –Cinema Selection
Storyboard 3 –Film Selection
Storyboard 4 – Time selection
Storuboard 5 – Book a seat
Storyboard 6 - Payment method
Storyboard 7 - Confirmation
These storyboards show each page of the system, its appearance the order in which they will run and the layout. The firsts storyboard introduces the user to the system and Cinema Simon navigates the user around the system. This storyboard meets the requirements mentioned in the last chapter about Introducing and explaining the online system. This is a Non functional requirement, and Cinema Simon helps by getting to this objective. Another one of the requirements met from the previous chapter was the flexibility, so we could allow various methods of payment. I introduced cash payment and credit card payment so the user can choose from one of the options, you can see this in storyboard 6, where the user selects his/her payment type. From storyboard 5, I designed the various tickets types so you could select from a wide range, which would benefit the users of the system. From storyboard 5 you can also see the number of seats that are available for the show you selected, this will be deducted as soon as seats have been booked, this will allow the user to view how many seats are left before pursuing in their booking, and then they could go back and make another selection if seats are not available.
Carrying on from the number of seats available, another requirement met, is making sure sensible steps are taken in the system. i.e. tell the user if a film is sold out before giving payment details. The system does this by indicating how many seats are available before entering personal details.
The next two requirements, be easy enough so a novice user can at least select a film and book a ticket without training, is hard to justify and hope to prove in the prototyping. The system has been designed so it uses the same layout format through out the system, the button and selection menu at the bottom, so users will not get confused as easily as they did in the old booking system in coursework 1, because that used a number of selection tools, and help from Cinema Simon on each page will help the novice user. Then again the other requirement, be efficient enough so a expert user can choose through the various cinemas and films on show, and choose the most appealing choice to him/her, can be met, as each environment is the same in the system, it has the same feel, and with large buttons labelled, they should have no problems, they can go back and forth through the pages if they don’t like a selection they made. The general format is the introduction at the top on every page, navigation buttons at the bottom, and different selection criteria in the middle of the page, this is used on all the storyboards.
Those were the non-functional requirements mentioned in the last chapter.
The functional requirements to be met are selection of cinema on the screen, this is met as you can see various cinema listings on storyboard 2, you are given a brief description of each cinema, how to get there, and you then simply click on the one you want to go to. The same can be said of the other two requirements, selecting a film on the screen and selecting films that are on at various times. From storyboard 3 you can see a short description of each film along with age, and duration, this is better than just the film title, and timings are given on storyboard 4 so the user can choose a film by the time they would like to see it.
The user would like to know how many seats are available if they want to book a show, by telling them how many are available will help them in making there choice with greater confidence, as you don’t have to book a certain show If there are only a few seats left, this was a major fault in the previous system and storyboard 5 has helped overcome this fault by telling the user how many are available. Meeting disability needs is another requirement that has been met, as the booking screen in storyboard 5 has an option, so you can select if the user requires disability access, as more and more disabled people are going to the cinema, and booking online will mean they won’t have to stand in the queue waiting to get a ticket. So this system will be great use to them.
I wanted the system to have flexibility in payment, as not many people have credit cards. When I was a teenager I had a cash card, and you couldn’t use that over the counter so I had to take the money out before hand, then queue up and tell the cashier what I want to watch and the pay. The online system promotes flexibility, so you can pay by card or pay by cash, once your transaction has been completed just tell your reference number to the cashier, and if you selected cash, pay and receive your tickets, and if you pay by card just collect them with your details. You can see these two requirements on storyboard 6 and storyboard 7 where the user has to choose from the two options and then their booking is confirmed at the end with a reference number.
As there are three options to choose from on storyboard 1, the steps differ on each selection. This is a map as how the system will work after the different choices. This is the narrative of the storyboard and how it runs.
These are the various steps taken; if you book by film you choose the time of the show then the cinema. If you book by Cinema, you then choose the film and then the time. And last of all if you book by time, you then choose the cinema and then the film. The storyboard relates to each other, as they build up step by step the booking process. The introduction asks the user what booking criteria they would like to start of with, they then choose either by film, cinema or time, which then runs through the other steps labelled 2, 3. Once they have selected those, the next storyboard, number 5, they book their ticket. If they are a student and need two tickets, they would click on student and select two, and select NO on the disable section, if they don’t require it. They are then ready to choose their payment method which is on storyboard 6, they enter their details, with the payment type, click on cash for example, and they then confirm their ticket on the last screen, storyboard 7. Storyboard 7 will have all the information from storyboard 2 to 6, confirming their options, and this also acts as the receipt, which can be printed.
Evaluation by user observation
I have prototyped the design used in stage 3 by using HTML. The purpose of this prototype is to see whether the system meets the non-functional requirements described in stage 2, requirements gathering. I am going to test the users ability to fulfil some of the requirements mentioned in stage 2 and record my findings. I saved the HTML code on my hard drive, and viewed it through a browser at home, using Internet Explorer 5. I asked my older brother, younger brother and my dad to test my system. My Older brother is an expert user, whilst my younger is not an expert, but then again not a novice. My dad has very little experience with computers and I viewed how they got on.
My prototype is very easy, there is not much design to it, I have made it so it is easy and quick to change, and cheap as no web development tool such as dream weaver is being used. I sat each one of family members down one at a time behind the computer desk, and made them access the system on the web browser. I tested the user so I could evaluate if the non-functional and functional requirement mentioned in stage 2 are met. I designed a table with the requirements and wrote notes down on each one tested.
The functional requirements were all met with no problems at all. The system showed all the available information on the screen, and they were able to select different criteria to book thorough, be it by film, time or cinema. Options that were available were such as disability and various payment methods were also allowed, there were no problems, and all the information was displayed on the last screens confirmation page.
So the functional requirements stated in stage 2 were a great success. You can view the transcripts on the next page.
The non-functional requirements were the next requirements to be tested. My dad was a bit slow around the system, but soon gained speed as soon as he got a feel of the website. The other two had no problems and they knew what to do. I also noticed my dad reading the help from Simon a lot, whilst the other two didn’t take much notice. My little brother has a cash card so he chose cash payment, which he selected with no problems, whilst my brother and father entered in credit card details. These payment types were both used and confirmed at the end, which proves flexibility had been achieved. Another goal I achieved was the tickets on offer, my little brother selected child, and my older brother chose student, whilst my dad chose adult. Each one of their bookings gave a different price as they chose different types and that shows I achieved my goal, of reaching a wide audience.
The users could also view the number of seats that were available to them, I generated a random number between 1 and 100 so every time I they chose a booking a different number appeared. We got 0 on one of the selections, but used the back button to view another show.
So the non-functional requirements were also a great success, with all of the categories having no problems. You can see the transcript on page 18.
Summary
My website was a great success and I had no difficulties with the code or design. My website was very bare, had no colour to it and was exactly the same as the storyboard, with navigation buttons at the bottom. If I was to improve the system I would add some colour and style to the website, and probably use dream weaver or Flash to give it that professional touch.
However my main priority was to develop a website that would be easier to use than the previous version we tested in coursework 1. I believe I passed many of the factors that had aroused during testing in coursework 1, such as the annoying Simon introducing himself on every page, (once is enough), the different methods used to navigate around the system, and the illogical steps used. Along with my HTA I was able to design and prototype a usable system that would cater for whole range of users, but then again be flexible, just as you have the in flexibility in the cinema, by booking different tickets, and special needs. The old system limited you to just adult and child tickets, and no student fares, or any mention of disability help. So my system has catered for that. All in all I believe the system has been a great success and am pleased with the outcome and results from testing.
Transcripts
Functional testing
Non functional testing
CMT 2200 – Human Computer Interaction Page
