Advanced Interactive Systems Design

Group Coursework

Rally System

Matthew Jakeman

Ben McCarthy

Ian Johnson

Lin Haiting

Rajesh Yadav

Proposed System

One member of our group is an avid motor-sports fan and brought to our attention the many advantages that a computer based system could bring to amateur rally driving. After studying the domain in more depth our group decided that the benefits such a system could provide were real and worth pursuing. The system we propose then is one which facilitates the sharing of information between all participating members of an amateur rally and its staff taking place at the Three Sisters race course in Wigan. In order to properly explain the proposed system, we must first describe the four users whom we have identified would directly interact with the system and what their roles would be, they are illustrated here in figure 1:

The process of running the system begins with the System Administrator, this user initially designs the layout of the race course for each stage of the rally and therefore would be the clerk of the course. Amateur rallies are divided into numerous stages (usually around twelve in total), after every stage is completed the layout (i.e. the direction and route drivers must follow around the course) can be altered to give the impression of driving on a different course. This then is the first point of contact with our system and would be provided by allowing the system administrator to click on the relevant sections of the course which are to be raced upon and which aren’t. This is illustrated in figure 2, the sections highlighted in blue are those to be raced on, those which are grey remain unused for that specific stage. It would not be possible to finalise a track layout unless it is made a complete circuit:

Figure 2: Course Design

Once the layout of the course and the direction the cars will travel in has been specified on the server by the system administrator, this information can then be disseminated wirelessly to all the other users of the system. At present this is done by hand drawing the course and handing out printouts of it to each of the identified users, making last minute course alterations using the present system inevitably results in the event being postponed whilst everyone receives the new handouts. With our proposed system any alteration to the course layout can be brought to the user’s attention immediately.

The user that would find this update in course layout most beneficial is the Co-driver, because once the course layout is known they can begin considering how best to approach the chosen circuit. The information about the new course layout would be sent to the stewards and emergency services teams as well, but it isn’t until the race is underway that they would begin to experience the systems specific advantages to themselves. Once the race has started GPS transceivers fitted to each of the co-driver’s handheld units would transmit their position to the systems central server, the server would then plot each of the cars position on the course and transmit this information to every user in real time as follows:

Figure 3: Course with car positions plotted onto it

This ability to identify the exact location of every racing car on the course would prove to be very advantageous to the Stewards and the Emergency services teams (the remaining two identified users) because it would facilitate the sharing of information (such as a cars location and type) between them during a crash situation. At present, when a crash happens at an amateur rally the stewards sustain radio contact with the Emergency services (if they are required) in order to advise them of a cars location and state. With the proposed system the steward would be able to specify exactly which car has crashed (and therefore via GPS its exact location on the course), this information would become immediately available to the relevant Emergency services team if they were required. What is just as important though is that this crash information would also be made available to the co-drivers and thus hopefully prevent any injury to stewards tending to the crashed vehicle. When a crash happens all users would be altered to the crash location as follows:

Figure 4: Course with car crash warning

In order to implement this system effectively we must consider the way in which the identified users will interact with it and attempt to provide the system in the most user friendly and user understandable way possible. To do this we will be utilising many HCI (Human-Computer Interaction) techniques in an attempt to gather as much an understanding about the people who will use the completed system and the way in which they will use it as possible. Hopefully, if we understand the people, their roles and the way in which they will interact with the system more thoroughly, then we can design a system which is quicker, easier and more intuitive to operate.

Personae

If we are to properly design a system for the users identified then we must properly understand the type of person these users are. One HCI technique we can use to help us realise the type of people we will be dealing with and what their individual requirements might be is to develop personae of typical users. By developing an actual persona for each of the users we can begin to think about specific user interaction and hopefully address problems which may have otherwise not been uncovered.

System Administrator

Brian is an avid motor sport enthusiast and has been for many years, he used to take part in amateur stage rallying until a road accident when he was 34 left him unable to compete. He is now 42 and still plays a large part in the sport as a marshal until recently when he has been the clerk of the course on many events. He has 1 child, a boy who is 18 and enjoys the rally meetings also. His wife doesn’t particularly enjoy watching rally driving but she does enjoy going to the race meetings because of the good atmosphere and friendly people that always attend. Brian is fairly computer proficient as he requires the use of a computer on a regular basis at his job where he works as a data analyst for a large financial firm. He thinks that the current paper based system works well and is very fault tolerant but he likes some of the advanced features that could be offered if the system was computerised and thinks that as long as the system was very stable it could be a very useful tool to aid with the development of the sport.

Co-Driver

John enjoys various different motor sports and is looking to get into stage rallying more competitively as a driver but cannot afford to buy a car at present. He has no children and is presently not married. He is Co-Driving until he can afford to get his own car and enjoys this very much. He works as a mechanic for a Wigan based garage which is how he came to be interested in motor sport and how he met the driver who is the manager of the garage. He doesn't use computers very much but he says as long as it is straight forward to use the system could definitely add some benefits to the sport and make it much safer. He has concerns with regard to any system that would interfere too much and take any of the fun out of the sport.

Steward

Mike is 25 and currently has no full time employment, he works as a steward whenever there is a race meeting at the Three Sisters race track because of his love for motor sport. If Mike were to be offered a full time work position he is adamant that he would continue with his steward position as well because it doesn’t feel like work to him, he is amongst his friends and his free time would be spent at the track on race meetings anyway. Being a steward means he not only means he gets in free, he is also closer to the action. For this he is extremely grateful and fells lucky. Mike obtained 2 GCSEs (CDT and Maths); he didn’t continue with education and went straight into a job at 16. He lives at home with his parents where he has access to a Pc which he uses for general web browsing and playing network games. Mike has no children and no permanent girlfriend at present, he hopes one day to have enough money to run his own rally car, only then would he quit his position as steward. He excited at the prospect of the rally system because he likes gadgets and loves the idea of having his own PDA to operate during races.

Emergency Services -Fireman

David is 30 and holds a full time position as a fireman; he has a keen interest in motor sport but mainly follows motorbike racing. He had already volunteered to work at the motorbike meetings when he was approached to help out at the rally meetings, he reluctantly agreed, but has since developed a strong liking of rally sport. The work requires very little effort (as the incidence of fires occurring is not very high) and enjoys the atmosphere at the meetings (he knows everyone there well and is treated with a lot of respect). He has a wife and a child aged 3 and likes to get home to them as soon as possible, his wife light-heartedly objects to him volunteering to work at the track but understands how much he enjoys it. She also doesn’t object too much because she knows that the rallies never over run time wise because of a law which states that all race engines must be switched off by 6.00pm. David considers himself to be computer illiterate, this isn’t entirely true as he has access to a shared Pc at his fire station and has used it for some very basic web browsing and word processing, but nothing more. He admits he is nervous at the possibility of a computerised system being introduced, but he confesses he is only usually a technophobe until someone has shown him what to do; after that he usually picks things up quickly.

Emergency Services - Paramedic

Jane is 32 years old and works full time as a paramedic. She is not a keen motor sport enthusiast but her boyfriend regularly participates in amateur rallying and she volunteers as an MSA paramedic because of this. Despite never being a keen motor sport enthusiast she does enjoy the events and she gets to spend more time with her long term boyfriend. She has a basic knowledge of PC operation and uses the internet to keep up with information about events that she may be going to in her capacity as a paramedic. She thinks that the current radio system works very well but is not adverse to the computerisation of the system as long as it easy to operate and does not hinder her work.

Scenarios

Once a system design has been proposed and the prospective users of that system have been identified and analysed, it is then highly beneficial to think about the way in which those identified users will interact with the system. One effective technique that can be used to think about this interaction more specifically and thoroughly is to create scenarios. By creating scenarios of situations that will arise when users are interacting with the system, we are forced to consider each individual users requirements and concerns. For this purpose we created scenarios of the three most important situations that arise with the use of the rally system.

For the purpose of facilitating the explanation of the scenarios we have decided to include screenshots of the Graphical User Interfaces we designed, these interfaces were designed after we had utilised each of the HCI techniques documented in this report, but we feel they are best illustrated here.

Scenario 1: Course Design and Dissemination to all Users

The first scenario we must identify is way in which the system administrator designs and disseminates the layout of each stage of the rally course to each of the users.

1. The system administrator is the person who updates everything involved in the running of the circuit, he is the person who is responsible for maintaining each and every update sent to him from the relevant sources.

2. He first designs the relevant circuit for the particular stage. When this is done he then propagates this information to each and every user on the circuit including Co-driver, Stewards, paramedics and the fire services.

3. Once the stage has been passed to each and every person concerned then he can receive the updates from stewards on the circuit if they feel the course design is unsafe.

4. From the feedback he gets from these stewards on the circuit he can decide to abort the circuit (however such safety issues often don’t become evident until cars are actually racing, therefore stewards can report their recommendation for aborting the stage at any time).

5. The system administrator can change the layout of the course any time up until the race has begun, in case any safety issue appears that was before unseen. After a race has begun, the current stage must be aborted before it can be changed.

6. In the time between when a car has finished a stage and the system administrator has disseminated the new course design for the upcoming stage the Co-driver is presented with information about their car's performance in the previous stage. If the Driver and Co-Driver wish to exit the rally for any reason between stages, they are given the opportunity to do so.

Scenario 2: The occurrence of a crash during a race

If a car has crashed on the circuit

1. A Steward at the nearest watch point will notice the crash, then report the crash to the server by selecting the car involved in the crash on his PDA and then pressing the “Report crash” button.

2. The Steward will rush to the crash site to analyse the situation

3. After reaching the site the steward will analyse the situation and report to the server how serious the crash is. There are differing levels of severity that can be reported:

• Very severe requiring medical assistance, fire assistance or both.

• Non severe but not requiring emergency services assistance (i.e. the car has come off the track and is immobile) in this situation all the other co-drivers must be warned of the immobile cars presence.

• Non severe and the car has regained mobility and thus re-entered the course or cleared the area. In this case the steward must be able to cancel their selection.

If the Steward determines that emergency services assistance isn’t required then depending on the mobility of the crashed car or cars, the system either reverts back to normal running or displays a warning to other drivers to slow down near the stationary car. If emergency services assistance is required the scenario continues as follows:

4. If the Steward decides to request for paramedic help or fire services help or both, he can now simply push the appropriate button to call the required service and this warning will appear on the relevant emergency services PDA.

1. As soon as the emergency services personnel are called for help by a steward, the Fireman or Paramedic who will attend the crash will alert the server that they are making their way to the site.

2. In order to make this recognition, they will select the car they are tending to on the PDA and then press the “Attending crash” button on their. This ensures that the server administrator knows that a crash requiring assistance is being attended and which paramedic is attending which crash.

3. In the meantime if another crash happens then another paramedic will be required to attend that crash site.

4. On their way to crash site the emergency services personnel can access the details about the Driver and Co-driver such as there blood type, current medical conditions, past treatments, which drugs they may possibly use, whether they have any allergies and many more relevant details.

Details provided to Paramedic

Details provided to Fire Services

5. At this point the emergency services have been alerted, given the exact location of where they are required and provided with useful information. Any further requirement to utilise the rally system would prove to be a hindrance to the emergency services. Therefore any reporting of the crash condition is left to the stewards, the track is only registered as being clear once all vehicles and the stewards have cleared the crash site.

Scenario 3: Merging of cars at the starting point

In every rally held at the Three Sisters course, at some point a car approaches the section of track where starting cars come out onto at the same time as a newly started car. This section where the two cars meet is known as the “Merge” and is the cause of many crashes. Not however at the exact point where the two cars merge (as this section is often divided by barriers) but often at the first bend they approach. Because of the lack of visibility caused by the barriers two cars can often leave the merge section at the same time, travelling at the same speed and both attempt to take the same line through the oncoming bend. If the Co-drivers were alerted of a starting car’s presence when they approached the start point and given their speed relative to the other car, this could hopefully significantly reduce accidents.

1. The Co- driver has the map for the stage from the server and the driver awaits their turn to start at the starting point.

2. At the start of the race the co-driver and driver have to be aware of the possible merging traffic, because cars which have already started might be already on the track and there is every chance that when they are coming out of the track then there could be another car passing at the same time from that start point. They have to take care in this situation and check on the PDA that when they are going to start, whether there is some car is passing that point at that time. What they are interested in knowing is:

1. How many cars will be passing at that point in that interval when they are supposed to start?

2. What is the speed of any particular car approaching that point?

3. If the system recognises that one or more cars are approaching the start point at the same time as the next car is about to start, it will display the speeds of each cars involved in the merge to each of the co-drivers in those cars.

4. Once the Co-driver has all this information they can then update the driver about the situation and the driver can act accordingly (either increasing their speed if they feel it will be possible to out run the approaching car or slowing in-order to let the other car/cars pass).

Task analysis

After identifying specific user interaction scenarios that will occur with the Rally System, we can now focus more specifically on the tasks involved within these scenarios in order to further determine the most effective way to implement the system as possible.

Task 1 Design of the Course

Why this task needed

Once the layout of the course and the direction the cars will travel in has been specified on the server by the system administrator, this information can then be disseminated wirelessly to all the other users of the system. With our proposed system any alteration to the course layout can be brought to the user’s attention immediately without any delay, which usually happens in present system by handing out printouts.

Hierarchy description

0. sys. admin. makes the course known to users

   1. designs course layout on computer

   2. issues the course to all users

   3. receives acknowledges from users

and plans,

Plan 0: do 1-2-3 in that order

Parse Scenario Using HTA

Diagrammatic HTA

Task 2 Reporting Crashes

Why this task needed

A crash is a usual occurrence in any motor-sport, e.g. an amateur rally in which our proposed system will be used. If a crash occurs, it tends to involve many workers with different jobs to deal with it, such as a steward, the system administrator who reports it to users of the system, paramedics and firemen about to attend it, and drivers about to attempt to prevent any injury to stewards tending to the crashed vehicle. As we know, the function of reporting crashes is one of the most important in the proposed system.

Hierarchy description

0. in order to report crashes

   1. one crash happens

   2. steward reports to Sys. Admin.

   3. Sys. Admin. Reports to users

3.1. reports to all to cancel race

3.2. reports to co-drivers

3.3. reports to paramedic

3.4. reports to firemen

4. another crash happens

and plans,

Plan 0: do 1-2-3 in that order, if at any time 4 occurs, another steward will report the crash and follow the model.

Plan 3: if the race can’t continue, do 3.1; else in any order do 3.2, 3.3 if someone is injured and 3.4 if car on fire.

Parse Scenario Using HTA

Diagrammatic HTA

Task 3 Deal with merging cars at the start point

Why this task needed

We need a mechanism for our system to address the problem of one car or more, which is approaching the start point, being likely to merge with the starting car.

Hierarchy Description

0. in order to deal with merging cars at the start point

   1. system recognises one car or more about to merge at starting point (one car must be about to start)

   2. calculate and display cars speeds to co-drivers

   3. approaching co-driver looks at the map

   4. co-driver warns driver and tells him of speed

   5. driver will make a decision

5.1. slow down

5.2. speed up

6. system stops calculating and displaying speed, once merge is completed

and plans,

Plan 0: do 1-2-3-4-5-6 in that order

Plan 5: do 5.1 if starting car is a little faster, or do 5.2 if starting car is slower

Parse Scenario Using HTA

Diagrammatic HTA

Navigational Structure of the System

As previously mentioned there will be four specific types of interface in the Rally System, each one tailored for a particular type of user.

Three of these interfaces will be interactive, these three interfaces being for the System Administrator, Stewards and Emergency Services. When designing an interactive system, it is useful to think through the way in which the user will interact with the system, and what affect the user’s input will have on the system.

To help us properly design the user interaction elements of the system we will draw hierarchical diagrams, which show the structure and nesting of user accessible screens within the system. Also, we will draw State Transition Network diagrams, which show the different states (or screens) within the system, and the actions and events associated with the transition from one state to another.

These diagrams are useful in a number of ways. Firstly, they help the designer to visualise structures they have in their minds and break them into manageable chunks. Secondly, they could be handed back to the customer to help verify that the user interaction design that the designer has created is suitable. Also, they could be handed to other members of the development team such as the main systems designer or code developer, to help ensure a coherent knowledge of the design across the board.

The fourth interface in the Rally System is the Co-driver Interface. This interface does not have “two-way” interactivity with the Co-driver, rather it actually presents real-time information to the co-driver “one-way”, without any buttons or other input methods for the co-driver to use. Therefore, for the co-driver interface we do not need to draw diagrams for structure of menus or effect of user input, as there is none.

Navigational Structure: Steward interface: Hierarchical diagram

Navigational Structure: Steward interface: State Transition Network

Navigational Structure: Emergency Services: Hierarchical Diagram

Navigational Structure: Emergency Services: State Transition Network

Crash reported state

Navigational Structure: System Administrator (clerk): Hierarchical Diagram

Navigational Structure: System Administrator (clerk): State Transition Network

Normal State

Internal Architecture of the Rally System

The diagram below illustrates the internal architecture of the system. It models the 4 different hardware components of the system and the different software components that are used.

As is shown in the diagram, the central component in the system is the server; it is responsible for constantly monitoring all aspects of the system and disseminating information to all of the users and their underlying client software. If any of the clients present on the system require information it is retrieved from this server, the only exception being the Co-Drivers client which also retrieves information from the GPS unit within the car. The server maintains constant communication with all 3 clients using wireless networking. This means that the clients and the server can maintain constant two way communications.

The server also constantly monitors the position of every car. Each car has a GPS tracking unit inside which is connected to the Co-Drivers client. This constantly updates the server as to the cars whereabouts whilst it is on the track. The server can therefore maintain a list of every car and where it is positioned. This means that if an accident occurs, when a steward has reported the incident it can be flagged at the server and every client is then alerted to the fact that there has been an accident and whereabouts it has occurred. If medical or fire assistance is required the emergency services clients can then be notified and they can make their way to the accident site.

There are three hardware components that maintain communications with the server, the Co-Drivers’ E-Papers, the marshals’ PDAs and the emergency services’ tablet computers. Each of these has its own client. While a lot of the functionality on the clients is the same (i.e. the map being displayed and dynamically refreshed as the cars move), each client also has its own specific functionality. For example, in the event of a crash site being identified as requiring medical assistance or fire assistance, the co-driver’s and the steward’s clients needn’t retrieve any information, whereas the emergency services client is required to retrieve the driver’s details or details of the cars involved in the crash from the server. The server contains a database storing this information, at the point when a paramedic or fireman specifies they will be tending to the crash the emergency services client contacts the server. The server already knows the car or cars involved in the crash and therefore can query the database to obtain the car or driver details prior to the emergency services personnel specifying that they are attending the crash site. Meaning the details can then be relayed back to the client as soon as they are requested.

There will be multiple 802.11g wireless access points positioned around the stages making sure that these cover 100% of the area in which the cars will be located 100% of the time so they can be in constant communication with the server. The 802.11g standard can easily support the maximum bandwidth the system would require meaning that all the cars can be constantly and immediately updated about any incidents that occur.

Conclusion

The Rally System project illustrates how by using various HCI techniques, it is possible to think deeply about user requirements and the way they will interact with a system, even with a theoretical model. We felt that when utilising these techniques we examined certain areas which we may not have analysed as closely otherwise and consequently could have implemented a less effective system. When used in a theoretical sense as we did with the Rally System, these techniques were obviously beneficial. However when used in a real life situation, coupled with user interviews, these techniques (and others) are indispensable for enabling developers to truly consider the end user.