Considering some hypothetical contexts that an ecologist may be interested in we began to think of context elements as being divided into two categories. Firstly, commonly used context elements that could be built into a data collection program (e.g. the current location) and secondly, activity specific context elements (e.g. the species of bird currently being observed) which, due to the sheer diversity of possibilities, would have to be defined at runtime. Values of the former type of context element may be automatically obtainable by communicating with a sensor device (e.g. communicating
Chapter 3: Ecology Fieldwork Tools
with a GPS receiver to obtain the current location). However, the latter type of context element would have to be supplied by the user (e.g. the user may enter “Chough” to specify the type of bird currently being observed). In the prototype we initially built in support for location, time and temperature common context elements (although only location and time values could be automatically obtained) and provided a facility to represent application specific context elements in a general manner using simple numeric and textual data types.
Figure 10. Editing one of the context element fields included in a stick-e note.
Specifying the sub-set of context (including common and application specific elements) of interest in a particular fieldwork activity is carried out by defining the set of context element fields to be recorded in a stick-e note, as illustrated in Figure 10.
A user-defined context element field is created for each unit of data that the ecologist is interested in collecting. These fields are created by specifying a name and a context element or simple data type to represent the value (currently limited to location, temperature, and time for common context elements, and number, line of text, and notepad for simple data types). The user can tailor the field further by indicating if it should be used in the trigger checking process and if it should be displayed when reviewing the note. This is useful as some context element fields may be used more for triggering and be of less interest when reviewing a note, whereas others may not be useful for triggering but do contain data of interest when reviewing a note. These are not mutually exclusive attributes, i.e. a context element field can be used for both triggering and reviewing. The attributes make the functioning of the program more efficient as they remove the need to check certain context elements in the triggering process and remove unwanted data from the screen when reviewing a note. In the user
situation checkbox determines if the field forms part of the situation that the stick-e note is recording, i.e. if it is a field that the note can trigger on. The display checkbox specifies if the field value should be displayed if the stick-e note is triggered. Using a combination of these two attributes, fields can be defined that are:
Both situation and display. Where the field forms part of the situation that is being recorded and is also displayed as part of the triggered stick-e note.
Just display. Where the field is used to store information to display when the note triggers, in effect augmenting the situation.
Just situation. Where the field forms part of the situation (so it is used in the trigger-checking process) but is not displayed in the triggered note.
Neither. Where the data is recorded for later reference in a different program and perhaps on a different computer. Such fields, in our experience, are uncommon. The field definitions can be added, removed or changed without affecting any of the previously recorded stick-e notes because each note keeps a copy of its field definitions. The main display constructs its list of available context elements by combining the set of built in common context elements, which are always available, with the set specified in the context element field list that defines the structure of a stick-e note. Selecting one of the available context elements causes the main display to show that context element’s current value, simulated values, and notes nearest the current value. The program maintains this information for each context element irrespective of whether it is an application specific one modelled by a simple data type or a common one represented by a real context element.
We originally intended to add a graphical view mode for the common context elements to support the visualisation of the current and simulated context element values and the distribution of stick-e notes around those values. This was not done, but we still believe it to be a useful feature. For example, for the location context element a graphical map view could be displayed showing the current value, simulated values, and location of recorded stick-e notes, all plotted onto the map display. Such visualisations would be limited to the built-in common context elements as the user-defined context elements
Chapter 3: Ecology Fieldwork Tools
are represented by general-purpose numeric and textual data types that would be difficult to make a sensible visualisation of without more knowledge of the application specific data that they represent.