As stated earlier, this dissertation describes the requirements analysis for all parts of the system. Development of one area - the multimedia computer-based interface - is then progressed to the prototyping and user evaluation stage, as detailed in this chapter.
The video click here to view - you may need to install Windows Media Player 9.
It was not practical, in the time allowed, to build a working prototype capable of being worn by a security officer in the course of his work. None-the-less, some captured images and sounds were needed in order to evaluate the prototype computer interface for examining the captured information. The purpose of the test was to see how well the display of captured information helped the security officer to reinstate the original context of an incident and thus recall the details not actually captured.
The ideal solution would have been to follow a security officer during a patrol, taking a tape recorder and stills camera. However, apart from the practical difficulties, the general use and publication of such recordings would present ethical problems. It was thus decided that the next best solution was to ‘stage’ an incident, recording both video (in the format of a television program - see Appendix D2) and stills (from the viewpoint of the security officer - see Attachment 3). This would allow a fairly realistic evaluation of the retrieval software, in that the evaluator could first witness an incident, and then attempt to recall the incident in detail, with the help of the software’s delivery of appropriately matching images and sound clips.
The original script (see Appendix D1) for the video (see Appendix D2) was based on information from the user group. It was recorded at the University of Sussex’s television studio, during which the actors were asked to improvise where they felt it appropriate in order to increase the realism of the finished product. The edited video and has since been digitised and made available here (see above) (Rudman,1998). This has allowed its use with all user and heuristic evaluations. (See Appendix D3 for further details of the process of creating the video.)
The paper prototype (see Attachment 2) shows only the timeline part of the proposed interface. The paper prototype was shown to one university and the hospital user groups. Few comments were made. They both liked it, but were reluctant to comment further. The two suggestions made were:
Problems with the timeline:
B2: Need the ability to mark / hide incidents already reported - agreed,
but problems with defining the start and end of each incident (see below).
Also, the users tested did not think making notes on the timeline was
necessary.
B3: Need the ability to find incidents if the time is unknown - this is a
major point and must be addressed (see below).
D1: Too much blank space when no data present - this too is very
important - a 12 hour shift would be too long to manage in one go.
Problems with the date and time input:
A4: Shift date input not restricted in length - agreed.
A5: Could default to today’s date - agreed.
C1: The date and time buttons could appear next to the date and time
information - agreed.
C3: Date input and display formats differ - agreed.
G2: Buttons could look more distinct - agreed.
Problems with the pictures:
A6: Larger picture could show time and location - agreed.
C2: Clicking a picture could play the matching sound - it is possible to
have several activations (each with a picture) with one continuous sound. This
could be confusing, but is worth further thought.
G3: The larger picture could be quite a bit larger - agreed, but not so
big as one has to scroll to see it all.
User: Want a command to print pictures on a form - agreed, but the
format would vary between users.
Problems with the sounds:
Users: Confusion over the meaning of the pattern in the audio boxes -
see below.
Problems with the set-up of the particular evaluation machine:
A1: ‘Tip box for buttons blank’ (the automatic help when the
cursor covers a button.) If this feature is supported in the software chosen
for the final version then it needs to give an accurate explanation of the
button.
A2: Length of sound clip doesn’t match the length given - machine
problem.
A3: Delayed response when ‘exit’ button presses - machine
problem.
Known problems / limitations of the evaluation version of the software:
B1: No ‘emergency exit’ - the large exit button is the
emergency exit. It is not yet functional.
The length of the timeline in particular needs attention. A way of finding incidents is needed in addition to specifying a time. One way suggested is to compress the timeline between incidents. However, this would be very confusing if it was done during an incident. Also, since detailed changes of location are stored it is unlikely that there will be any large areas of completely blank timeline. One possibility is to display a list of locations along with the number of activations at that location. This would provide a higher level ‘map’ of the more detailed timeline, which could be displayed by selecting a location entry.
The ability to mark incidents that have been dealt with would be useful. However, this highlights the problem of how to automatically identify the start and end of an incident (ie. first and last activation). Until a reliable way is found for the device to identify (and mark) the start of an incident at the time of recording (see Chapter 5 - ‘The Device’) perhaps the best way is to take any time periods over a certain length without an activation as evidence of an ‘inter-incident’ period. This will be easier to define when some real user data becomes available.
The users were confused as the meaning of the pattern in the audio boxes (see figure 7 and Attachment 3). The problem is likely to be in the source of this pattern; it represents the sound by displaying the electrical waveform it generated. This is the ‘engineering model’ (Gentner & Grudin, 1996), where function relates to how the system actually works. A much better alternative would be the ‘user-task model’. This is perhaps described in the words of one of the users: "It would be too much to get the speech written in there, wouldn’t it?" (Phil Claridge, see Appendix A3). Since speech recognition under such varied circumstances is not yet practicable, the pattern generated by the engineering model is perhaps as good as anything.
Figure 7 - Example audio box from the hi-fi prototype
| Next Section | Previous Section | Beginning | Contents | MSc home |