The system being designed here has the potential to benefit a wide variety of user groups. Examples include:
For the purposes of this dissertation it was necessary to select one specific user group with whom to validate the design. Perhaps the people who could benefit most from such a system are memory-impaired individuals. Unlike other users, who can often fulfil their needs with existing devices, living with continuing memory deficit has the potential to benefit greatly from an automated memory assistant. It is hoped that future research will investigate this area. However, the problems of obtaining access within the short time-scales of the project did not allow this at the present time.
Informal discussions with secretarial staff suggest that their work is very office-orientated, with ready access to computer and paper-based information storage and retrieval facilities. Similar discussions with experienced police officers, however, suggest that the mobile and immediate nature of this work could make the security services an appropriate user group. A variety of private security operations were therefore contacted, with positive responses from three organisations (listed below). Interviews were conducted with a security officer from each organisation (see appendices A-C). These confirmed the suitability of the security services as potential users of the device.
It is important to prepare for a qualitative interview. Jennifer Mason (1996) writes that the success of a qualitative interview is in having a set of points to cover and steering the interview as far as possible through those points, while simultaneously picking up on any new and relevant areas that the interviewee may mention. Accordingly, the points it was intended to cover at each initial interview were planned in advance as listed below:
Note that there was an assumption that the officers’ job can be divided into two types of work - that done in the control room (watching the CCTV display, working the radio, filling in forms etc.) and time spent in the area of responsibility (‘on patrol’). The interviews showed this assumption to be correct.
In order to gain access to the user groups, permission was sought in writing from the head of security at the respective organisations. Two of the organisations required written evidence of the authors status as a student. It is very much appreciated that staff time was given to allow the interviews to take place, and that answers given were so candid. In return, it seems appropriate that the information gained is carefully assessed as to its status. Some information was given ‘off the record’ or in the course of conversation possibly without thinking of a wider audience than the interviewer. This information does not, therefore, appear explicitly in the dissertation, or appears without being attributed to any particular interviewee or organisation. It is also for these reasons that, although the interviews were recorded, the dissertation contains detailed notes, rather than full transcripts.
All users investigated have one continuously staffed control room. When outside this room all security officers carry a radio, allowing them to communicate with both the controller and other officers (all radios use the same channel). The security officer’s job consists basically of:
All security officers in the user groups studied require information from external sources (ie. not from their memory) as part of their work. The most important and widespread requirement is for the access codes for intruder and fire alarms. This appears to be an ongoing problem for all users in the study. The University security officers solve the problem by carrying a notebook with all alarm codes listed. However, they are always concerned that they may lose the book and thus dislike the notebook as a solution. Indeed, the hospital users do not consider it safe to carry codes on their person; they use an on-line system instead. When a code is required they radio a request to the control room who send the appropriate code to the security officer’s personal pager. However, this is not a system introduced by the hospital - it is on the initiative of the individual security officers. Thus while it works well as a system, it is not an ideal solution. A secondary problem is the problem of code changes - often users are not informed when a code is changed for some considerable time.
Actually finding the alarm panel in the first place is another important information requirement. All users have to deal with a large number of buildings; the hospital users are also key-holders for other organisations. Thus it is a regular occurrence that a security officer finds himself in a building for the first time - often at night - with the urgent requirement to locate the fire or intruder alarm control panel. This problem is currently addressed where possible by taking a map of the building to the site. However, this is often not possible, or is not as helpful as one might expect. A secondary solution is either to radio the control room for directions (which they may not have) or to simply ‘look around’.
Once the alarm control panel has been located, it will give information as to the location of the sensor that triggered the alarm. If there is no obvious problem (eg: smoke in the corridors) then the security officer will investigate the cause of the alarm. This requires finding the room or area covered by the sensor.
This process of moving around a building to locate first the alarm control panel and then the sensor often brings the security officer to a locked door. Electronic locks - and some mechanical ones - often require a code. Alternatively the officer must fetch the emergency key. Often this is held in a locked key cupboard, for which the officer carries a key. He must locate this cupboard and select the correct (numbered) key for the door in question.
All users interviewed have a responsibility for car parking, and especially need to be able to obtain information about registration numbers. All University of Sussex staff and students have to register with the university before they leave vehicles parked on the premises. The University security officers need to be able to find out the name and status (eg: 3rd year Psychology student) of the registered (with the university) keeper, in order to check either that the vehicle should be there, or that the person with the vehicle is supposed to be using it. This is currently done by radioing to the control room. However, this can take some minutes - the officers would like a faster system.
The hospital users look after a public pay-and-display car park. They are responsible for dealing with vehicles which do not display a valid ticket, or are parked illegally. They operate a "three strikes and you’re out" system. The first two times that a vehicle contravenes regulations a warning notice is prominently attached to the windscreen; on the third occasion it is wheel-clamped. This requires a database of vehicle registrations. Currently the database is held on a PC in the control room. The security officer on patrol radios the registration number to the controller who looks it up or adds it to the database. However, often the controller is busy and cannot respond to non-urgent matters. This can require the patrol officer to return to the control room and interrogate the database himself. By the time he has returned to the vehicle it may have been moved.
The University users need to be able to check the identity of people found in the building. Currently the University of Sussex keep a database of students on paper in the control room. Unlike the vehicle database, they seem reasonably happy at radioing the control room to check the identity of people.
Anything out of the ordinary that happens has to be comprehensively reported in written form. This is usually done on returning to the control room, especially at the end of a shift. Reports cover things noted, such as open windows, gas taps left on, etc. They also cover alarms investigated. Most complex are the reports of incidents involving people. (See the example ‘Violent incident report form’ - Attachment 1).
A good example of an incident report was given during one of the user interviews (see Appendix A3). Phil Claridge (security officer at the University of Sussex) described how he would report the incident portrayed in the video (see Appendix D2). The report is in story format. Crucial elements of the report are as follows:
The user group investigated could benefit from help with memory tasks in the areas of responding to alarms and report writing, specifically:
| Next Section | Previous Section | Beginning | Contents | MSc home |