• No results found

A Suite of Three Programs

In document Context-Aware Software (Page 110-117)

Chapter 3: Ecology Fieldwork Tools

3.2 Generic Fieldwork Tools for Data Collection

3.2.3 A Suite of Three Programs

The software for the PalmPilot was designed and developed as three separate applications: the StickePad to create new stick-e notes, StickePlates to create new stick-e note templates, and the StickeMap to visualise stick-e notes containing location context elements via a map display. Although separate, the three programs work in harmony by operating on the same database of stick-e notes and by communicating with each other through a common area of storage. The reasons for the division are discussed in this section.

Chapter 3: Ecology Fieldwork Tools

The user interface of the first prototype centred around one main screen where both current context and stick-e note information could be accessed. The central feature of the interface was the view-by control that allowed the user to select which context element was used to orient the view of the main screen. The current and simulated values of the selected context element were displayed and also a series of icons representing the stored stick-e notes, ordered according to their proximity with the current value of the context element.

Two of the main information elements of the screen, the current context value and the list of stick-e notes, were typically used independently of each other. For example, the user may want to find or check their current position, in which case the current context

value element would be used, or to search for a pre-recorded stick-e note, in which case

the nearest stick-e notes element would be used. Although convenient to have all these facilities in one place, this further reduces the already limited screen size for each information element. This results in a somewhat cramped display where the information is displayed in a small form to suit the screen rather than in the most accessible form to suit the user. For example, instead of the small textual readout of location (or other context element) it would be preferable to visualise this in the form of a map (or another context element visualisation) to make navigating easier. The nearest notes could also be plotted onto such a map display giving the user more information about where they are and the proximity of notes to their current location. The main reason that the display of the first prototype took the form it did was that the nearest notes list was designed to serve two purposes: (1) to order stick-e notes by proximity and (2) to allow editing access to a list of pre-recorded notes. The result was a compromise that served neither task particularly well. To remedy this situation we decided to separate ordering by proximity and editing access into two separate displays. In fact, we went further and partitioned the displays into two different programs, so creating the StickePad and StickeMap.

The StickeMap provides a grid-based map onto which the user’s current position is plotted along with that of any nearby stick-e notes. It provides information on current context and nearby stick-e notes in one display. Although these two pieces of information tend to be sought independently of each other (the user tends to seek the

current location or the nearest stick-e notes at different times) combining the two gives a better sense of the context of either by illustrating them in relation to one another. Some simple map functionality is provided such as zooming and scaling. Also by clicking on a stick-e note icon the user is transported to an editing screen for that note, though for the most part the user will edit notes directly through the StickePad. Note that we could have supported a background image on the StickeMap to allow scanned paper maps to be utilised. However, as all of our field trials were to be carried out in areas with no available maps we chose not to implement this feature for the time being.

Shows the number of stick-e notes displayed out of the total number that have a location field. A stick-e note icon. Clicking on it

launches the StickePad with that particular note automatically opened for editing.

Indicates the current position of the user. Note: the icon appears bolder if the GPS is attached and functioning.

Buttons to update the cursor

position from a GPS reading, re- center the map on the user’s

current position, and also to

zoom in or out.

Figure 14. Screenshot of the StickeMap program.

The StickePad is used for creating new stick-e notes and viewing and editing stored ones. Unlike the first prototype, where searching for a pre-recorded note was literally a hit and miss affair (clicking randomly through the line of nearest note icons), in the second prototype a little more information is given to the author to enable them to better hone in on the note that they desire. This information is presented in the form of a scrollable list of stick-e notes represented by their associated sequential number, time and date of creation, and, optionally, a summary of the note’s context element fields. A separate StickeMap application for visualising and manipulating the location context element could be perceived as going against the general philosophy of the updated stick-e note concept in which each context element field is considered equal to all the others, with no special treatment of one over the other. However, the principle of uniform treatment across all context element fields applies to their processing rather than their representation in the interface. Different types of context elements inherently have different display requirements, e.g. there are a lot of visualisation possibilities that

Chapter 3: Ecology Fieldwork Tools

can help the user manipulate location data, but there is little that can be usefully done to visualise the number of giraffe except displaying the numeric value. The first prototype’s view-by control was conceived out of the idea of treating context elements equally, which should indeed be the case for trigger-checking and other processes, but for viewing data the different context elements inherently require different approaches to visualisation.

List of recorded stick-e notes.

Button to create a new stick-e note.

Figure 15. Screenshot of StickePad main screen.

When creating and editing stick-e notes, the StickeMap program is not required. The plain location data, in the form of latitude and longitude, can be worked with directly. The StickeMap is intended as a supplemental program to provide some useful context- aware features that focus on one particular context element, i.e. a map display for showing the location of the user and stick-e notes. We view the StickeMap as being similar to helper applications in Web browsers, providing a display service for a particular type of data, or, in the case of the fieldwork tool, a particular type of context element. In future work we hope to develop (and encourage others to develop) more helper applications for the fieldwork tool in order to support the visualisation and manipulation of other types contextual element.

In the first prototype we found that we required a more sophisticated method of defining the context element fields of a stick-e note. In particular the ecologists had interests in several distinct sets of context elements rather than in one single universal set. This was addressed in the second prototype by introducing the concept of stick-e note templates. A template enables the definition of a common set of context element fields from which stick-e notes can be constructed. This added a great deal more complexity to the StickePad user interface than the simple “define fields” menu item in

from that of creating stick-e notes. We therefore separated all the template creation and maintenance functionality into the third and final program, called StickePlates. This program allows the user to create a set of stick-e note templates and to define the set of context element fields that constitute each one, as illustrated in Figure 16.

Buttons to create new templates and add context element fields. The stick-e note template’s context

element fields. The selected stick-e

note template.

Figure 16. A template called “Field Notes” defined in the StickePlates program.

This separation left the user with a much simpler interface to the StickePad program where the infrequently-used template functions were removed, so avoiding any cluttering of the interface. In fact, the StickePlates program could even be removed from the PalmPilot altogether in some circumstances. This could be done to save space on the PalmPilot when using a standard or tried and tested set of templates that need no in-field modification. It can also be useful to remove the StickePlates program when equipping a group of people with a standard set of data collection templates: in this way they are prevented from modifying the templates in any way.

The rationale for separating the stick-e note software into the three separate programs, StickePad, StickePlates, and StickeMap, can be distilled into four main points:

It reduces the apparent complexity of the small display by segmenting the program into functionally disparate areas, i.e. functions for defining a stick-e note template, creating and editing a new stick-e note, and visualising the collection of recorded stick-e notes (corresponding to the function of the StickePlates, StickePad, and StickeMap programs respectively).

Separating the template definition into an independent program allows a data collection manager to define a standard set of templates which are given to the fieldworkers with the StickePad and StickeMap but, importantly, without the

Chapter 3: Ecology Fieldwork Tools

StickePlates program. In this way the fieldworker is prevented from altering the template definitions.

The spirit of stick-e note technology is to treat all context elements as equal and as such there should be the potential to visualise the stick-e note data by a variety of different context element views, not just a map for location context elements. By separating the location visualisation function from the main program a precedent is set whereby ‘helper’ visualisation programs based around other context elements may be developed and added to the system.

The resource limitations of the PalmPilot on which the prototype was developed (and, indeed, other handheld hardware) favour a model whereby a selected group of small programs can be uploaded to perform a specific task rather than one monolithic program that is likely to include features which are redundant in some tasks.

In addition to improving the definition, editing, and visualisation of stick-e notes as a whole, the support for individual context elements and simple data types were also extended to include the following:

Bearing. Specifies a direction in degrees 0 - 360. A range option is provided to allow a bearing range to be specified, e.g. from 67 to 92 degrees or even 350 to 10. Boolean. Provides an on/off, yes/no, or true/false checkbox.

Date. A date or date-range, whose precision (e.g. dd+mm+yy, mm+yy, mm+dd, etc.) and format (e.g. USA or UK) can be specified.

List. Facilitates the recording of any of the other supported types in a list (except for another list type). Provides the option of recording timing information with individual entries. The properties of the list element type may be adjusted just as if dealing with a single type.

Location. Records location (currently only in the form of latitude and longitude). Notepad. Gives the user a display like the PalmPilot’s built-in MemoPad

Number. An integer or real number, or number range, for which an upper and lower valid limit can be specified and a step increment defined, e.g. an integer that lies between 5 and 78 and which increments in steps of 4.

Time. To record an actual time, a single duration of time, or a range of time, with a specified accuracy (hours, minutes, seconds).

Location, date, time and bearing provide context element support, whereas boolean, number, and notepad provide simple data type support enabling the representation of application specific context elements through generic types (similarly to the way a programming language allows data to be represented with generic types – though the range of base types required is larger). The remaining list type facilitates the storage of an undefined number of values for one context element, e.g. a list of people present in a room.

Simulated values and triggered notes were mostly omitted from the second prototype.

Simulations were only implemented in the form of being able to simulate the current location in the StickeMap program in order to preview stick-e notes in an area different to the current one. The simulated location value was not used in the StickePad in creating stick-e notes, etc. (though the user could override the sensor input and enter a value manually; useful for sensor failure conditions), nor were simulations of other types of context element supported. The simulations feature was scaled back as it seemed likely that it would not be widely used by the ecologists in the field (though it may have uses later on in the desktop-based data analysis software). The trial of the first prototype indicated that most of the context element fields would be constantly changing from note to note rather than retaining a stable value (stable values are needed in order for simulated contexts to be useful in the automatic entry of data; otherwise there is no advantage over typing the new value directly into a new stick-e note’s field). The triggering mechanism was also omitted from the second prototype design. As with simulated values, the feature did not seem to be particularly useful to the majority of ecology fieldwork as the activities were based around the creation of stick-e notes rather than in their automatic retrieval (even in long running projects, whilst in the field the work generally focuses on recording new data and not inspecting previously recorded data). The concept of stick-e notes popping up on screen whilst roaming

Chapter 3: Ecology Fieldwork Tools

through different contexts would be more attractive to tour guide applications that concentrate on retrieving data appropriate to the user’s current context rather than in fieldwork data collection that concentrates on storing context information appropriate to the user’s current task. A more suitable feature for the fieldwork environment is a means of gaining a new and perhaps broader perspective on the data that is being recorded, e.g. viewing the distribution of stick-e notes recorded around the user’s current location via the StickeMap.

The emphasis of the second prototype is on exploiting context-awareness to capture, manipulate and visualise data (e.g. extracting GPS location data that can be used to fill in a stick-e note field or to view the user’s current location on a map) rather than to use it as a way of automatically recalling information associated with the current context (i.e. triggering). This reflects the data collection nature of the work. However, rather than discarding the notions of triggering and simulations, the trial of the second prototype provided a good opportunity to consider how they could be exploited in such a setting, and how these concepts could be incorporated in future prototypes.

In document Context-Aware Software (Page 110-117)