Distributed Data Collection: Evaluating the Usability of ...

Distributed Data Collection: Evaluating the Usability of Wireless Communication in CyberTracker Lucien de Voux [email protected] Supervisors Edwin Blake [email protected]

Dominic Gruijters [email protected]

Submitted to the University of Cape Town as the requirements for the Computer Science Honours Project Final Write-Up

Department of Computer Science University of Cape Town

South Africa 2006

UNIVERSITY OF CAPE TOWN

L. de Voux

Acknowledgements My first acknowledgement goes to Christ, without whom none of this would be possible. My strength comes from You. To Professor Edwin Blake, for all your insight, guidance and time, both Computer Science related and otherwise, my sincere thanks. Your impact on me has been profound. To the rest of the team, Anthea Peacock and Robert Douman, you guys were awesome (in the true sense of the word). I look forward to working with you guys in the future. To the UCT Traffic Department, thank you all for the much needed assistance, I appreciate your time and suggestions. To Louis Liebenberg encouragement.

for

making

himself

available

and

providing

Justin Steventon for all the work you have put into CyberTracker and putting up with all the emails. To Cara Winterbottom for the delightful chat and the advice on the Experimental Design. To Dominic Gruijters for all your wise words. My parents, Anthea and Wilfred de Voux, you have shaped me to be all that I am. I could never repay you but I wish you all the happiness. Special thanks to Alex and Kieran who have taken the time to help make this work possible. You guys inspire me more and more each day.

-2-


L. de Voux

Abstract CyberTracker is software application for mobile devices which is used for distributed data collection. It consists of a mobile client and a desktop server. It has been used with significant success in previous years within various contexts. The most noteworthy being the collection of wildlife information in National Parks throughout Southern Africa. The application allows users to create data entry templates which is then used to record sightings on a mobile handheld computer. When the user wishes to view reports of the sightings, the device has to be physically docked and synchronised with the desktop application. With the data already being stored electronically, it is unfortunate that the information is not available sooner. In order to overcome this inconvenience, the application has been extended to enable wireless communication with the server. The application can now transmit information using technologies such as GPRS and WiFi to communicate data over-the-air, thereby eliminating the need to physically dock the device. Moreover, by enabling two-way communication between the client and server, the extension produces additional benefits which inadvertently broaden the range of applicability of CyberTracker. The paper looks at the how the extension has affected the usability of the application. It looks to discover areas which can be improved upon and which implementation strategies to avoid. It then provides motivation for the extension and supports its findings through usability evaluations.

-3-


L. de Voux

Table of Contents Glossary.............................................................................................................. - 6 1.

Introduction ....................................................................................................... - 7 -

1.1

Subject ............................................................................................................ - 7 -

1.2

Objectives.............................................................. Error! Bookmark not defined. 1.2.1

1.3 2. 2.1

Research Questions ....................................................................................................- 9 -

Scope and Limitations................................................................................... - 9 Background...................................................................................................... - 11 Small Screen Size......................................................................................... - 11 2.1.1 2.1.2

Representing Data ....................................................................................................- 11 Data Entry ................................................................................................................- 12 -

2.2

Limited Storage ........................................................................................... - 12 -

2.3

Slow Processor ............................................................................................. - 12 -

2.4

Lack of Security........................................................................................... - 12 -

2.5

Limited Battery Life.................................................................................... - 13 -

2.6

Physical Damage.......................................................................................... - 14 -

2.7

Connectivity ................................................................................................. - 15 2.7.1 2.7.2 2.7.3

Coverage ..................................................................................................................- 15 Using Multiple Platforms .........................................................................................- 16 Synchronisation........................................................................................................- 16 -

2.8

End-User Applications................................................................................ - 16 -

2.9

Acceptance ................................................................................................... - 17 2.9.1 2.9.3

Language ..................................................................................................................- 17 Symbolism................................................................................................................- 17 -

3. System Overview ................................................................................................. - 18 4.

Significant Design Decisions........................................................................... - 20 -

4.1

HTTP vs XML Byte Streams ..................................................................... - 20 -

4.2

UDP/IP vs TCP/IP....................................................................................... - 20 -

4.3

WiFi and GPRS ........................................................................................... - 20 -

GPRS Icons .............................................................................................................. - 21 4.6

GPRS connection......................................................................................... - 21 -

4.4

Sequence order ............................................................................................ - 22 -

4.7

Upgrading the IDE ...................................................................................... - 24 -

4.8

Remote Plant Identification vs Previous Tracker Positions.................... - 24 4.10.2 Previous Tracker Position............................................................................................- 25 -

4.11

Major design challenges. ............................................................................ - 25 -

-4-


5. 5.1

L. de Voux

Experimental Design ....................................................................................... - 27 Test Case - UCT Traffic Department........................................................ - 27 5.1.1 Preparation of Sequence ................................................................................................- 28 5.1.2 Preparation of Questionnaire .........................................................................................- 29 -

5.2

Results .......................................................................................................... - 31 5.2.1 5.2.2

Observation Results..................................................................................................- 31 Questionnaire Results...............................................................................................- 32 -

6.

Discussion......................................................................................................... - 35 -

7.

Conclusions and Recommendations .............................................................. - 37 -

7.

Future Work .................................................................................................... - 38 -

9.

References ........................................................................................................ - 39 -

Online References.................................................................................................... - 40 Appendix A: Building Instructions for the extension of CyberTracker v3.48 .. - 41 Appendix B: Resources Required.......................................................................... - 44 Appendix C: Traffic Questionnaire and Responses............................................. - 45 Appendix D: Deliverables....................................................................................... - 50 Appendix E: Traffic Ticket .................................................................................... - 52 -

-5-


L. de Voux

Glossary 1. Alternative charge: When the primary fine can be reduced by a secondary charge upon certain conditions. Eg. When a person accused of parking without a valid parking disk presents a valid disk, he/she may have the primary fine replaced by an alternative fine such as not displaying a valid parking disk. 2. Client: Application running on the mobile device used to display/manage sequences which are used to record data. 3. CyberTracker Desktop Application: The application running on a desktop computer or laptop which is used to create/manage sequences, elements and view/edit reports. 4. DSRC: Dedicated Short Range Communication 5. GPRS: General Packet Radio Service, a data transmission technique which does not set up a continuous channel but rather transmits and receives data in packets. This allows the connection to charge per packet and not relative to time. [ii] 6. GPS: Global Positioning System, an international radio-navigation system which uses satellites to track position. [v][vi] 7. Moving Map: allows the user’s position to be displayed electronically on a map. 8. PDA: Personal Digital Assistant, handheld computer. 9. Sequence: Set of screens which have been created and linked together using the CyberTracker desktop application 10. Server: The application on the desktop computer. It consists of the CyberTracker Desktop Application, relevant databases and a means to wirelessly send/receive data to/from the clients. 11. Smart-phone: A generic name for a voice centric mobile device with information capabilities. Any mobile handheld device which has both PDA and GSM capabilities. Often, this includes adding phone functions to already capable PDAs or putting "smart" capabilities, such as PDA functions, into a mobile phone. [i] 12. WiFi: Wireless Fidelity, IEEE 802.11b. Wireless Local Area Network (WLAN) limited range wireless protocol used to transmit information in wave format [iii][iv]. 13. Wireless Communication: This could denote various protocols. We restrict our study to GPRS, WiFi. There exist tools which can be used to simulate the performance of wireless networks under various conditions [4].

-6-


1.

Introduction

1.1

Subject

L. de Voux

Mobile computing devices have been around long enough for most people to feel comfortable using them in their daily lives. Whether it be personal or work related applications, wireless communication has proven to be beneficial to users all around the world. When considering the impact it has made in countries with a lack of wired infrastructure, the cost effectiveness makes it appealing to both providers and consumers. Moreover, the increased usage of web services has driven to the need to be connected at all times in order to gain access to valuable information and assistance. Very few sectors have been unaffected by the computerisation of daily tasks. Sectors which involve field operatives have already attempted to facilitate the execution of daily chores by incorporating mobile devices. Some examples of these sectors are medicine, public services, security and even agriculture. These mobile devices are often required to be compact and have access to the Internet or local network. Examples of these devices already in use are mobile phones, PDAs, smart-phones, laptops and many other task specific devices [8]. By enabling these devices to gain access to a network e.g. the internet, using technologies such as Wireless Fidelity (WiFi), General Packet Radio Service (GPRS) and Dedicated Short Range Communication (DSRC), it allows the client to connect to a server, enabling information to be downloaded or uploaded to or from a database. Being able to share information between a database and field operatives from arbitrary locations creates additional opportunities for applications to assist users. These applications include querying the database for relevant information or being able to keep track of the position of field operatives by having their position updated regularly. In order for these applications to be truly practical, they have to be usable. This however, is not always an easy goal to achieve. There are many more factors such as small screen size and battery life to consider when dealing with mobile devices that are perhaps not as relevant when implementing applications on a fixed work station. These will be elaborated on through the course of the paper. CyberTracker CyberTracker is a freely available software application which allows the user to create data entry templates which can then be used on handheld computers or PDAs. These templates now allow the user to collect and record information while out in the field. It consists of a desktop application which is used to create these data entry templates called sequences. These sequences are then displayed on the mobile device and allow the user to input details of the data which he/she is collecting. The desktop application is also used to view the results of the information captured by the mobile device. The reports can be represented in tabular format or graphically such as in the case of moving maps. The client application is ported to the mobile device from the desktop application by a synchronisation process. This process installs the necessary CyberTracker files and creates the appropriate sequences designed by the user. When the user of the mobile device wishes to record a sighting, he/she simply follows the options made available by the sequence on the application.

-7-


L. de Voux

The application has been used with significant success to assist illiterate and semiliterate trackers gather information on wildlife in National Parks. There exist many other relevant uses for the application such as education, farming, social surveys, disaster relief and more recently traffic control. In addition, the software has been used in over 50 different countries and is supported by many international organisations including European Commission, United Nations Information Technology Service and World Wide Fund for Nature (WWF). While CyberTracker provides a paperless solution, the information collected is still only made available when the device is docked and synchronised with the desktop application. By having the data already stored electronically, it seems disappointing not having the information available in sooner. This is currently unavoidable as the only means of updating the database with the information captured is by having the mobile device returned to base and synchronised. The project aims to expand the functionality of the current version of CyberTracker which is able to be used on PDAs and Smart-phones. As shown in Figure 1, the extension will consist of a TCP/IP connection which will allow the CyberTracker application to take advantage of wireless connectivity. This connection will exist on both the client and server. By making use of services such as GPRS and WiFi, the extension will provide a powerful wireless solution to distributed data collection. Existing System Cyber-Tracker Application Extended Application

External memory

TCP/IP

Figure 1: System Partitions showing the proposed TCP/IP extension

The use of GPRS and WiFi These technologies will enable the data gathered on the mobile device to be transmitted and captured on the back-end database from remote locations. The process of transferring information from the device to the database will no longer require a wired docking station. This allows the database to be continuously updated and ensures that the reports do not reflect outdated information. In addition to being able to download data to the database, it will also be possible to upload information from the database to mobile devices. Trackers will then have access to relevant information on the database such as surrounding wildlife and prior records. When a tracker is unable to connect to GPRS or WiFi due to their location (out-ofrange), the system will provide a store-and-forward service. This will allow records to be stored on the device until it can establish a connection with the server and transfer the data.

-8-


L. de Voux

Focus on Usability An important success factor for the project is whether the transmitting of data functionality is sufficiently usable. A means of testing whether the transition to smartphones is as seamless as anticipated will be investigated in the experimental design. Various issues may arise when altering the current paradigm of hardware specifications such as screen size, input devices and connectivity. With CyberTracker software being used by scientist, indigenous trackers, field workers, etc., each with a multitude of individual skills and cultures ranging from fully literate to illiterate, the usability of the interface is crucial. Also, with the introduction of mobile phones comes with it new hardware, which will alter existing paradigms. The new hardware may therefore need to be adjusted to allow the software to seamlessly fit into the new paradigm.

1.2

Research Questions

The research questions which were tackled through the course of the project were formulated to analyse the usability of the system. They provided motivation for the experimental design and directed the focus of the paper. The success of the project depends on the ability to provide answers to the proposed research questions, as these questions form the basis of the usability evaluation. The questions that the paper is attempting to answer are:

1.3

1.

How does porting CyberTracker to smart-phones affect the usability?

2.

Would having the smart-phones wirelessly communicate with the database have a major impact on the efficiency with which the application is being used?

3.

Does the extension of wireless communication create additional complexity in terms of usability?

4.

Should the data be sent automatically, without the user being aware of the procedure?

Scope and Limitations

This document is one aspect of a three team project and should be viewed as such. In order for the reader to gain a complete understanding of the extension it would be advised to read this document in conjunction with the other documents. As previously mentioned, this specific document deals with the usability of the extension and therefore has limited details of the technical aspects of the transmission of data. The biggest challenge when evaluating the system is finding adequate users for the experimental design. Within many of the National Parks, the application is being utilised by semi/illiterate trackers who have preserved their traditional tracking skills by having it passed on from one generation to the next. Unfortunately, these trackers are scarce in urban areas and it therefore proved too difficult to gain access to them. A contingency plan therefore had to be constructed. Other constraints which existed were due to limited resources. These scarce resources include mobile devices which would have allowed for simultaneous user testing. The most significant factor was the limited time given to perform the experimental evaluation. This was as a result of the short time provided for the project.

-9-


L. de Voux

In addition the experimental evaluation could only commence once a significant portion of the application had already been developed. This paper specifically focuses on the usability of the extension. The characteristics and decisions are therefore evaluated in terms of ease of use and the practicality of the solution. Section 2 provides insight into how similar problem were tackled and whether or not their solutions could be used to benefit the design of the CyberTracker extension. Sections 3 then goes onto describe details of the overall system. Section 4 considers some of the significant design decisions which needed to be made. It provides reasoning for the decisions and describes how they affected the outcome of the project. Section 5 covers the experimental design. It specifically looks at the UCT Traffic Department Test Case. It describes the preparation that had gone into the experimental design and explains the Observation and Questionnaire procedure. It also presents the finding of the experiment. Section 6 provides commentary on the results found in the project. It explores how the process was flawed and how it could have been improved upon. The research question are also answered in this section. Section 7 draws conclusion from the work done in the project. It also provides recommendations on how the extension could best be taken advantage of and gives a project analysis. Section 8 looks at the potential of the extension by considering the future work which would be of value in the project

- 10 -


2.

L. de Voux

Background

The paper will now focus on some of the existing work which has been done with regard to the usability of mobile devices. We especially concentrate on client/server systems which are wirelessly connected. The requirements and guidelines which have been extracted from these existing systems is then analysed and their applicability evaluated. According to Yuan-Hsiang Lin et al [13] the requirements for mobile devices used in monitoring the transportation of patients is as follows: 1) portable and lightweight

2) it should have power autonomy 3) a user-friendly interface 4) the ability to collect and display critical bio-signals (information) 5) ability to record patient information and data 6) support wireless communication Although these requirements are proposed for a specific application [13], it would not be too difficult to extend them for a more general case or adjust them to coincide with the specifications of CyberTracker. They therefore provide suitable guidelines when evaluating similar systems. Some of the difficulties presented by mobile devices such as PDAs and smart-phones are: •

small screen size

•

limited storage space

•

slow processors

•

limited input mechanisms

•

lack of security

•

limited battery life

In addition to the difficulties attributed to using a compact mobile device, there are connectivity issues such as being in a location where no GSM coverage is available or where interruptions are caused by unforeseen circumstances.

2.1

Small Screen Size

2.1.1

Representing Data

A small screen for a device compact enough to carry is unavoidable. Due to its size the mobile device is often unable to represent information such a large tables or graphs effectively. Information presented therefore has to be well thought out and done in a readable format [17]. One such solution would be to provide zoom functions which limit the amount of detail available on the screen.

- 11 -


2.1.2

L. de Voux

Data Entry

With some field operatives such in the case of wildlife tracking, making up to onehundred sightings per day is not uncommon and is therefore imperative that they can do so as efficiently as possible. The small screen however, reduces the possibility of effective text entry capabilities. The touch screen keyboard of a PDA is uncomfortable and clumsy, often resulting in incorrect input. Though handwriting recognition has come a long way, it is still not an effective input mechanism [17]. A less common form of input is a QWERTY keypad, either fixed to the device or those which can be attached and removed at will. According to [17], the most effective applications will be those which reduce the amount of text based input required by providing a useful GUI. It should provide check-boxes, radio buttons, drop down menus and require only minor text based input. This requires an in-depth knowledge of the all possible cases that may arise out in the field. This GUI coincides with the interfaces provided by the existing version of CyberTracker and will be maintained with the additional interfaces which will be provided to process interaction with the database.

2.2

Limited Storage

Due to it size, mobile devices often do not have near to the amount of storage space as a fixed desktop device. The storage currently ranges between 64MB – 128MB. They can also be increased via a memory card (up to 4GB), but these cards are considered additional expenses. One therefore has to make allowances for space constraints which reduce the capabilities of the application. It also requires the device to be synchronised with a database to prevent running out of space, resulting in memory loss. In order for the available space to be most effectively utilised, [17] suggests that data should be stored in files instead of a database on the mobile device since files require less memory. It also suggests that by having the desktop management unit handle most of the storage; it will free the mobile device of valuable resources. In addition, the application may delete any data which has been successfully transmitted to the database thereby freeing up memory.

2.3

Slow Processor

As in Section 2.2, mobile devices often have reduced processing power. It therefore does not make these devices appropriate for graphics and other complicated process hungry applications. [17] suggests that the system should be engineered such that very little data processing takes place on the mobile device and the bulk of the data be processed on the desktop system.

2.4

Lack of Security

Mobile devices such as PDAs don’t have the sophisticated encryption algorithms and facilities such as desktop systems. They are however more susceptible to attacks as there information is often carried over-the-air. Moreover, a mobile device is more vulnerable to being stolen or lost simply because of its nature. Great advancement has been made in terms of the security requirements of data in mobile devices and thus poses much less of a threat now than it previously had.

- 12 -


L. de Voux

The paper considers only a few solutions compared to the overwhelming quantity available, all of which have had empirical testing and have been published. In [13] it is required for all users to authenticate themselves by entering unique username and password. In addition, an encryption algorithm such as AES is used to allow end-to-end encryption between the mobile unit and the management unit. A more sophisticated model for specific applications is presented by [10] which provide security at the transport layer (point-to-point), the application layer and message level (end-to-end). According to [17] simple precautions can be taken such as having password enabled of the device and/or having sensitive data stored only on the desktop system. The various implementations are very much dependant on the specific application requirements and are occasionally not required at all. The sensitivity of the information is of prime concern when deciding of the extent of security required. The current implementations of CyberTracker had not required any additional security since the data being collected is not considered sensitive. However, with the introduction of sending data over-the-air, situations may exist which require the need for additional security such as encryption when transmitting sightings. Such an example may arise when using CyberTracker in criminal investigations.

2.5

Limited Battery Life

The majority of mobile devices consuming power run on batteries (others include solar panels and kinetic energy). Rechargeable battery power is the only feasible source of energy for PDAs and they often run on a combination of LiIon (Lithium-Iron – main battery) and NiMH (Nickel Metal Hydride – backup battery). Though these batteries have been considerably improved, the need for longer lasting batteries still continues. PDAs have colour screens which draw significant amounts of power. Also, if the device were to make use of services such as Bluetooth, GPRS, Wi-Fi, GPS or by simply using the telephone the power consumption increases significantly. Apart from the fact that a flat/uncharged battery renders the device useless, the most devastating consequence is that the device will reset lose its volatile memory, which may result in a loss of data. There is always the possibility of carrying a secondary battery or if possible a mobile charger. However, if the application is well designed this may not be necessary. One such design technique suggested by [16] would be to allow these additional services such as Bluetooth, GPRS and WiFi be set to sleep mode when not in use. They could then either be woken by a prompt from the server or be activated at regular time intervals to check whether the server wishes to perform tasks or if information needs to be sent/received [8]. Thereafter it could be switched back to sleep mode. Another case to consider is the fact that if any alarms or urgent notifications need to be sent/received the device needs to be activated immediately. Another way to reduce power consumption would be to decrease the data transmission by using a simple ACK protocol for UDP over IP [16] – Table 1 shows a list of power consumptions for various tasks [13] and Table 2 shows the battery life relation with the number of tasks [17].

- 13 -


L. de Voux

Table 1: Battery life of Pocket PC (HP iPAQ H5450) [13]

Table 2: Task Specific Battery Consumption

There is also a possibility to modify standards other than IEE 802.11 suggested by [16] which looks to take advantage the IEEE standard 802.15.4. IEEE 802.15.4 is specifically designed for low powered, low cost, wireless personal area networks. Another possibility is the use of suggested by [8] which implements Ultra-Low-Power networks for more specific tasks. Depending on the time the device will be required to be without charging, one or many of these solutions may be applicable.

2.6

Physical Damage

Due to the unpredictable and often harsh conditions when using a mobile device in an outdoor environment, devices often needs to be properly encapsulated [16]. For commercial products such as PDAs, smart-phones and laptops, off-the-shelve encapsulation merchandise is adequate. They are usually cost effective and easily obtainable.

- 14 -


L. de Voux

However, when considering more task specific devices which are not as common; a more elegant approach needs to be adopted. Although the encapsulation is more likely to suit the purpose of the objectives of the device it is considered and additional expense and also adds to the time required before the release of the final product.

2.7

Connectivity

The paper now considers some of the complications which arise due to the mobile device being wireless and possibly on the move. These devices are either connected via GPRS or WLAN (IEEE 802.11). In terms of usability, an interrupted connection could leave the user disorientated. The first precaution should be to prevent an interruption all together or reduce the possibility of the device being out of range. If however an interruption occurs or the device losses the connection due to reduced signal strength, the device should have appropriate protocols in place to handle the exceptions. 2.7.1

Coverage

As the most common reason for a loss in connection is lack of coverage, much needs to be done to ensure the location which is to be monitored is within range of the protocols being implemented. Fixed access points that have GPRS and WLAN 802.11 core networks are the most common means of wireless connection. The WLAN 802.11 access points however only function optimally on level terrain where line- Figure 2: Wireless telemedicine architecture [13] of-sight needs to be maintained. Another disadvantage of the WLAN 802.11 access points is that they occasionally be maintained. For this reason we propose GPRS is a better alternative for mountainous locations. However, often combinations of the two networks provide an adequate solution for areas which lack GSM coverage (Fig 2). Mobile access points are also a possibility as Figure 3: Combining Wireless LAN and GPRS [17] they can be attached to vehicles. Devices can connect to the internet via GPRS using the PPP protocol. Since the IP would be temporary one, it would be required to implement a dynamic address lookup service to resolve IP address issues [16]. Often when no coverage is available, the device uses a store-and-forward mode [13]. This involves the data to be transmitted being stored on the device until the appropriate conditions are satisfied. This is a valid solution when the information is not required to be transmitted in real-time and the periods of not being able to connect to a server are acceptable. The memory capabilities of the device once again come into play and may require expansion. This solution is also applicable as previously mentioned in section 2.5 when attempting to conserve battery power.

- 15 -


2.7.2

L. de Voux

Using Multiple Platforms

When implementing a system with multiple platforms one has to consider the handoff process very carefully. According to [9] the transition needs to be seamless and secure. This poses an interesting problem for the usability of mobile devices as one often crosses over from one platform to another when on the move. As discussed in section 3.1, combined networks are often attractive and therefore required some mention of how to interchange between them. [9] describes the design, implementation and performance of a Secure Universal Mobility (SUM) architecture. Alternatively [16] implement a simpler approach whereby the GPRS network nodes are assigned global IP addresses and the IEEE 802.11 use a private address space. These implementations are clearly suited to dissimilar systems as the [16] version, though simpler does not fulfil all the requirements of SUM and does not perform as well. Careful requirement analysis should be considered before deciding on a single approach. 2.7.3

Synchronisation

When a device is continuously synchronised with a database or server it constantly remains active. This therefore consumes additional power all the time. Also, in the case where synchronisation is lost the device attempts to reconnect by going into a high power state thereby shortening the battery life [8]. A better solution is having the device toggle between a state of active and sleep mode. This considerably conserves precious battery power. There are however times when real-time information is critical and it is essential for data to be sent continuously. Such a case is the one proposed by [13] whereby a patient’s physiological vital signals are being monitored. In cases such as this the device is only effective if it can be continuously in an active state.

2.8

End-User Applications

End user applications can be implemented using JSP web-based applications interacting with the middleware such as EJBs. Another possible solution would be to have console based client applications interacting with the EJBs [16]. [13] also implements MySQL database and a management unit on a Windows 2000 platform. This allows vital signals to be delivered in real-rime and plotted graphically. The application also allows some customisation and manipulation of the representation of the display such as the selection of leads, the replay of waveforms, analysis of the raw data and scaling of amplitudes and time. It therefore seems quite capable of handling sophisticated applications however this does not imply a similar system cannot be implemented using EJBs. The end-user application are often most beneficial when data can be represented in graphical or tabular format. The possibility of locations being plotted on a map could be one such example.

- 16 -


2.9

L. de Voux

Acceptance

An important aspect to consider when comparing available technologies is cost effectiveness. This is especially true for developing countries. When considering a technology such as GPRS which uses existing GSM coverage one has to realise the benefits. Also, GPRS is charged according to the amount of data sent or received. According to [7], the acceptance of a technology is determined by the perceived ease of use and the perceived usefulness. Thus the design of an application must always look to identify the potential benefit the application can provide to the user and how this can be done in the most understandable way. It should incorporate a high level of Human Computer Interaction techniques in an attempt to improve the usability of the product. It would be arrogant to assume that all human behaviour is governed by common blanket of social and cultural upbringing. However there are some contributing factors that would be impractical to ignore. The following are some brief guidelines which could assist the designer to understand the user of the system thereby making it more accepted, useful and beneficial to the user. 2.9.1

Language

Language is an important aspect when considering the implementation of an application. Not only does it aid the user in understanding the interface but it also encourages a sense of familiarity within the user. According to studies by [3] it also achieves an increase in productivity. 2.9.2

Symbolism

The interpretation of symbols is something that is often taken for granted in the Western world. Various cultures often have diverse understandings of symbols which can lead to confusion. While symbols remain an important part of communication, the interpretation is not something to be assumed [5]. Another interesting aspect of symbolism is that certain cultures have not been sufficiently exposed to abstract representation which reduces the capacity for metaphorical thinking. Other factors include ethnicity (cultural beliefs) [11], social classes [2], gender [12] and age [2].

- 17 -


L. de Voux

3. System Overview The paper now attempts to look at how the extension was made possible. Some high level technical aspects are considered as well as the technologies involved. The existing application will make use of the additional functionality which has been created to transmit information to a remote server (Figure 4). The server, which is currently made up of the desktop application and necessary databases will be expanded to receive remote data using a web service. The web service will consist of a listener which will spawn servers to handle request coming in from mobile clients. The data being received by the mobile clients will be managed by Enterprise Java Beans (EJBs) which will go on to update the database. These EJBs form the middleware of the application and provide a modularised, scalable solution to wireless distributed data collection. Figure 5 gives an overview of the technologies involved when communicating between the client and server.

Figure 4: Use Case Diagrams for transmitting and storing information

- 18 -


L. de Voux

Cellphone tower PDA Cellphone:

c++ client Use open protocols to connect cellphone client to the database

java implementation front end to database

Use of 3-tier database system

Database

Server

Figure 5: System Overview of the technologies involved

- 19 -


4.

L. de Voux

Significant Design Decisions

Through the course of the project, it was necessary for many decisions to be made when designing the extension. We look at the motivation behind these decisions and how they have impacted and affected the outcome of the project.

4.1

HTTP vs XML Byte Streams

One of the first decisions which needed to be made was whether the client and server would communicate using HTTP requests or XML byte streams. With HTTP it would be necessary to adhere to the specific syntax required by web-services which is complicated and confusing when making complex requests. In addition, none of the project team members had previously written complex HTTP requests. There was also confusion as to how the response would be represented. XML byte streams on the other hand is familiar to all the team members and had the data structuring necessary to transmit and translate sightings between the client and server. As in the case with HTTP request, XML is independent of platform and has been standardised, thereby promoting interoperability. After much discussion and consultation from the staff interoperability expert, it was decided that XML would be more suitable to the requirements of the task. In retrospect, this decision has paid off and the XML byte streams were used effectively.

4.2

UDP/IP vs TCP/IP

The decision whether to transmit using UDP or TCP comes down to weighing up the speed at which data is transmitted against the reliability. Initially it was thought that UDP would be the most suitable option as it consumes fewer resources and is more appropriate for real time services. It was however decided against as it provided insufficient built in functionality such as error checking and congestion control. In contrast TCP is more dependable and provides embedded functionality such as congestion control and error checking. This does however come at a price and delays can be expected whenever a bit error or packet loss occurs. The delay is due to the retransmission of broken packets. In terms of usability, this was perhaps not the most beneficial option as UDP would have reduced the amount time user would need to wait for responses from queries or data being transmitted. It is however necessary for the information to be accurate and is therefore necessary to employ TCP/IP [vii].

4.3

WiFi and GPRS

Although the extension can use both the GPRS and WiFi protocol to connect to a network, it was decided that more emphasis would be placed on GPRS due to its popularity. The GSM coverage in Southern Africa by far surpasses that of WiFi. Many of the evaluations and design decisions are therefore biased towards GPRS.

- 20 -


4.4

L. de Voux

GPRS Icons

When adding icons, screens or any other display, it was thought best to remain as consistent with the current application’s theme as possible. The GPRS icons were therefore designed in such a way that they had a similar feel to the existing icons employed in the current application, such as the timed GPS and animal icons.

Figure 6: GPRS Icons used in the GPRS Timer Setting screen and on the Send Data button

The G is the standard icon for mobile applications to connect to GPRS (Figure 6) and can be found on any GPRS enabled device. Even though GPRS would be a new concept to many using the application, it was found suitable to use the G as it is representative of the text “GPRS” and is easily distinguishable for the illiterate user. Also keeping in line with the existing icons, the time interval at which the application will attempt to update the database was written below the symbol. These icons were used to create a GPRS Timer Setting screen which can be seen in Figure 7 Figure 7: The GPRS Timer Settings

4.5

GPRS connection

When considering how the extension would impact the flow of the application, it became evident that their existed various points in the program where the sending of data would be appropriate. Of the few that were discovered, the three main possibilities are: after the completion of a sighting; manually at the discretion of the user or periodically. These could also be combined to allow more specific solutions. We look at these three cases independently and provide examples of when they would be appropriate. Consider the case where the information being collected is critical and the sighting is required as soon as possible. An example of such a case would exist if CyberTracker were to be used in Crime Prevention as proposed by Louis Liebenburg. In this situation, trackers would collect sighting of peculiar tracks on beaches where criminal behaviour is known to take place. This type of activity might not take place for extended periods of time, but when a discovery has been made it is vital that the information be handed to the proper authorities with great haste. In this case it would be appropriate to transmit data as soon as a sighting has been completed. The next case could be found in a district where only sporadic GSM coverage exists such as in the case of the Kruger National Park (Figure 8). In this case, if the application were to prompt the device to connect to the network, despite the lack of GSM coverage, it

- 21 -


L. de Voux

would be of no use and would waste possibly critical battery life. In addition, the store-and-forward service would be most ideal in such a situation. If the user where to gain prior knowledge or experience of the terrain, he/she would now be able to explicitly decide when to transmit data. A real life example of such a case would be in National Gaming Parks where GSM coverage would usually be found at the resorts but seldom anywhere else. The last case deals with the situation whereby CyberTracker could be used as a management tool as in the UCT Traffic Department case study. By setting the application to periodically transmit data, the GPS coordinates would be regularly delivered to supervisors and managers. The senior staff will now be able to track the locations of the officers out in the field and ensure that they are adequately positioned and covering sufficient ground over time. The screen used to set the frequency at which data is to be transmitted can be found in Figure 7. When considering the usability of the different mechanisms of transmitting data, there are certain factors to consider. These factors include the amount of control given to the user, with regard to the sending of data. In contrast we also need to consider the amount of complexity which needs to be hidden from the user. When data is sent periodically or after the completion of a sighting, the user no longer needs to concern them self with when the data is transmitted. Lastly, the user should have the ability to cancel the transmission at any time.

Figure 8: GSM coverage of Kruger National Park

4.6

Sequence order

When designing the sequences for the transmission of data, the following screens were derived from Figure 9: • Detecting Network (connecting to server) • Connected: Sending Data • Sending Failed • Sending Successful

- 22 -


L. de Voux

[User takes reading using system] Reading Taken

System Initialised

[Data Captured on system]

Data Stored to memory temporarily

[Stored information that must be sent]

[Connection Available]

[No Connection]

Sending Data

[Stored information that must be sent + Connection Available]

Sending Unsuccessful [Stored information that must be sent + No Connection]

[No Stored information that must be sent]

Figure 9: State Diagram representing the transmission of data

- 23 -


L. de Voux

During the early stages of the project, the sequences found in Figure 10 were created using the CyberTracker Desktop Application. The screens were created using a combination of GIF images, marquees, memos, title bars and elements.

Figure 10: Original screens created in the CyberTracker Desktop Application

4.7

Upgrading the IDE

One usability aspect unrelated to the actual usability of the application which was thought worth mentioning is the decision to convert all client projects files to Microsoft Visual Studio 2005 (MSVS 2005) projects. This was thought necessary as the code had originally required two separate IDEs when building the application. The ClientDLL.sln and CyberTracker.sln can now be opened in MSVS 2005 to create the Client.dll and CyberTracker.exe respectively. Moreover, a batch build can be configured to allow the two to be compiled simultaneously. If the client is to be open source in the future, this convenience would assist those wishing contribute to the application. There are however the loss of backwards compatibility with operating systems such as PocketPC 2002 [viii]. In order to compensate for this problem, MSVS 2005 allows the necessary Software Development Kits (SDK) to be freely downloaded at [x].

4.8

Remote Plant Identification and Previous Tracker Positions.

To illustrate capability of querying and receiving data from the database, an example query needed to be implemented. The possible queries were narrowed down to remote plant identification and previous tracker position. We discuss the factors which were considered when deciding to implement previous tracker positions and remote plant identification. 4.8.1 Remote Plant Identification When out in the field, trackers often encounter many unexpected situations. The memory available on the mobile device is usually insufficient for holding large databases of plant details (including a picture). It was therefore thought that the ability to query remote databases with a description of a plant would compensate for this lack of memory. The description would thereby provide details for the query such as leaf colour, texture, etc. which could be used to filter possible matches. This would allow the tracker to query very large databases not necessarily managed by CyberTracker. A graphical representation of the plant identification procedure can be found in Figure 11. - 24 -


L. de Voux

Remote Plant Identification CyberTracker Interface

CyberTracker Extention

Server

Top Package::User EnterConditions Pass Conditions transmitCond() transmitMatches&Categories() sendFormatedData() Select Match

findMatch()

formatData()

DisplayData SendMatch() SaveSighting() SendSighting() sendAck() successFeedback()

saveSighting()

deleteSighting()

displaySuccessfulTransmition()

Figure 11: Sequence Diagram of Remote Plant Identification

4.8.2 Previous Tracker Position When trackers are out in the field, they are often unaware of one another’s location. By enabling them to gain information about where others trackers have previously been they avoid duplicating previously collected data. The positions of the trackers have to be represented in a meaningful manner. Plotting the coordinates on a moving map would be most appropriate. By implementing this service, the efficiency of the trackers would improve as they would be more informed of their environment.

4.9

Major design challenges.

One of the biggest challenges when designing the screens for the GPRS functionality was the need for it to be hardcoded without the assistance of the CyberTracker Desktop Application. This is as a result of the GPRS functionality being independent of any sequences and only dependant on the Framework. Control classes therefore had to be created to generate dialogue screens. These dialogue screens are then called by a display method from the application. Details of the solution can be found in Appendix A. The original design of these screens can be found in Figure 10. The mobile devices that we made use of for this project are ones running the windows mobile operating system. In order to provide a scalable solution, the implementation made use of having servers spawned from a listener and as well making use of Java Entity Beans. This however causes complications as the languages in which the various components are implemented differ. - 25 -


L. de Voux

We therefore needed to make allowances, such as sending byte streams, due to the heterogeneous systems. In addition, the database currently being utilised by the software is a MS Access database which is not scalable. The CyberTracker system is an existing software application with very little documentation or comments. Understanding the existing software and integrating it with the extension has proven cumbersome and difficult. The representation of data being received also needs to be further considered. The procedure was unfortunately not completed and therefore did not allow the possibility of the usability to be explored. If a user were to cancel the transmission of information, appropriate mechanisms need to be put in place to ensure the user can go back to a previous state. Moreover, the system needs to recover from cases where transmission has been cancelled. This needs to be done quickly but more importantly correctly and without the loss of data. Another possibility would be to afford the user the option to delete the information which had been successfully transmitted rather than automatically deleting the data. With the interfaces of the transmission of data being modelled on the existing GPS implementation, great care has to be taken to ensure the two are not confused.

- 26 -


5.

L. de Voux

Experimental Design

In order to find answers to the questions proposed in Section 1.2, a test case was designed to extract information on the factors surrounding the topics. We consider these topics as a whole and elicit solutions to individual questions, each according to its merits. The trickiest part of the experimental design was not to get distracted by the issues surrounding the usability of the existing application and sequence design, but rather focus on the usability of the extension and the transmission of data. This being said, it is felt valuable to provide overall details of the experiments even when the matter in question has no direct link to the usability if the transmission of data. For completeness, all usability concerns raised were included in the results. The principles and techniques used to produce artefacts and evaluate the application were taken from Chapter 7, Pg195 of [20]. These principles have been carefully followed and been used appropriately through the course of the design and evaluation of the experiment.

5.1

Test Case - UCT Traffic Department

Date: 31 October 2006 Venue: UCT (Upper and Medical Campus) Invigilator: Lucien de Voux Assistant: Robert Douman

Figure 12: Close up of an Officer "writing-up” a ticket

The usability testing was initially planned using trained trackers who were preferably semi/illiterate. This however was not possible due to the lack of availability of the trackers in Cape Town. Moreover, the time constraints placed on the completion of the project also made it impractical to visit one of the national parks where some of the trackers are employed. The UCT Traffic Department was thought to be a suitable alternative to the animal trackers as they too were field operators. A set of sequences were created for the collection of information on illegally parked vehicles*. The Traffic Department was contacted a week previous to the experiments to request permission and to explain what would be required of them if they agreed. A superior officer was approached and agreed to the officers participating in the experiment and arrangements were made to meet the following week. On the day of the experiment, the volunteering officers were individually given a briefing as to how the experiments would take place and how they would be assisting us to find flaws in the application. It was made clear to them that it was the application which was being evaluated, not them, and that they were free to discontinue participating at their own discretion. They were then shown the device and were allowed to familiarise themselves with the CyberTracker application. Many of the officers had not previously had any contact with a PDA and were therefore shown a few basics.

*

The sequences titled traffic.MDB can be found on http://www.cs.uct.ac.za/~cybertracker/ldevoux

- 27 -


L. de Voux

Once the officer was sufficiently comfortable with the application, they were taken to the start screen and told that they were going to be disrupted as little as possible, but should feel free to ask any questions. These questions proved extremely useful when discovering usability problems with the system. The question were therefore immediately jotted down and later properly documented

Figure 13: Officer "writing-up" a ticket

The traffic officers were initially observed collecting information on illegally parked vehicles using their traditional means of writing out tickets to gain information on the current system in place. 5.1.1 Preparation of Sequence Information to be collected The following information was thought relevant and necessary after perusal of [21] and existing parking tickets (see Appendix E) •

Date & Time (automatically handled by application)

•

Fine Amount(s) – Alternative fines

•

Officer Number

•

Parking lot Code

•

Vehicle Make

•

Parking Bay Number

•

Vehicle Colour

•

Infraction(s)

•

Vehicle Registration Number

•

Additional Description

•

Parking Disk Number

•

Meter Number

The sequences allowed users to enter the information for the above fields. When possible, options where made available to the user in the form of checklists or radio lists. Moreover, appropriate icons were used in conjunction with the text.

- 28 -


L. de Voux

The options were ordered using Zipf’s* principle of least effort whereby selections were ordered by popularity, such that the most likely option was placed at the top and the rest followed as their likelihood decreased. Initially it was thought beneficial to record the time taken to capture parking violation information using the traditional way and compare them to the time using the CyberTracker application. If the efficiency of the entire application was to be evaluated, then perhaps this information would be useful, however this is not the case. The proposed technique was therefore rejected as it would have provided no results which could be used to draw inference on the usability of the CyberTracker extension. Users were not made aware that it was actually the usability of the sending of data that was being investigated. The users were under the impression that it was in fact the usability and completeness of the sequence. The need to inform them otherwise was not thought to be relevant and could possibly bias the study. Keeping up with the ideals of CyberTracker and [17], having as little textual input as possible was thought to speed up the ticketing process, however, this was not always possible, such as the case with vehicle registration number, bay number, etc. There were also allowances made for unexpected cases by enabling additional text input for most screens. Concessions made when creating Sequences •

Unofficial officer numbers

•

Periodic sending was disabled, as it would not affect the experiment. Under normal circumstances, data would be sent without user’s knowledge.

•

Limited vehicle makes, colours and infractions.

•

Unable to specify an alternative charge, however more than one fine can be made per vehicle in a single sighting.

•

GPS was disabled

•

Transmission Dialogue screens were not used and replaced with pop-up messages.

5.1.2 Preparation of Questionnaire Version 0.1 was made up of open-ended, Likert scale, single-choice and multi-choice questions. It did not however contain sufficient questions on the transmission of data but rather concentrated on the usability of the sequence and existing CyberTracker application. Version 0.2 removed all questions not directly relating to the elicitation of information on the transmission of data. This was suggested in [20], which clearly prohibits the inclusion of questions which do not directly benefit the questionnaire. This was proposed to Prof. Blake and it was then decided that some more of the open-ended questions were to be converted into a Likert scale format. *

Make frequent actions easier to achieve while allowing more unlikely ones to be less easier

- 29 -


L. de Voux

This was to gain quantitative information which could be more accurately analysed. Some of the questions also needed to be rephrased to ensure they were unambiguous. A redundant question was removed and replaced with a question which related to the usability of the sequence so as to provide the subjects with an opportunity to voice their opinion on the usability of the overall application. This was thought necessary to allow them to look past the usability of the application and be directed by the question that followed. The open-ended questions were used to try and identify whether any of the data transmission screens were confusing or troublesome.

Figure 14: Overview of UCT Traffic Department Sequence

- 30 -


L. de Voux

The final version (Appendix C) was reviewed by a Computer Science Ph.D. student who has experience in Psychology. Though nothing was changed, the discussion was extremely insightful. It was especially useful to discuss how requests for assistance in understanding the question were to be handled so as not to bias the study. What was also suggested was that consistency is extremely important when doing this kind of experiment. It was therefore decided to keep all factors as uniform as possible and document any variation which may occur, such as a change in location.

5.2

Results

5.2.1 Observation Results UCT Traffic Department Case Study The first significant observation that was made is that once an option was selected by the user, he/she waited for the sequence to proceed to the next screen. However, the original system was designed such that once an option is selected; the next button needs to be clicked as a means of confirmation before the application will proceed to the next screen. Since there is no documentation on the design of the original system available, one can only assume that the reason for this is that once an option has been selected, the user can modify the selection before proceeding to the next screen. By forcing the user to click the next button the system ensures that an input has not occurred erroneously or without the user having the opportunity to review their selection. One other reason is that a check lists allow multiple selections and therefore would not make sense to proceed to the next screen once a single option has been selected. A distraction which occurred when users were entering data is the predictive text. Because the application uses the input software of the device, when user entered two or more characters, the device attempted to predict the rest of the word/string. This caused confusion and two of the four users requested assistance in this regard. If this problem had been anticipated, the predictive text function would have been switched off. Unfortunately, switching it off during the experiment was thought to reduce the consistency. The next issue which arose is specific to porting the application to devices with GSM capabilities. This was due to interruptions being caused by SMS’ or incoming calls. There were also other forms of interruption such as GPRS connection being lost and unknown modem errors. These interruptions resulted in the user losing focus and jumbled screens. Unfortunately the CyberTracker application did not recover well from these interruptions and the application usually needed to be shut down and restarted. In some extreme cases the smart-phone had to be soft-reset. Because of the user’s lack of experience, it was required of the invigilator to perform these necessary tasks which disappointingly tainted the Observation process. Once in the CyberTracker extension one cannot check whether the device is connected to a network without exiting the application. If the user attempts to transmit data and the device is not connected, the procedure connecting the application to the server would eventually time out, and an error will be displayed. If the CyberTracker application were to be aware of whether the device is connected to a network and react accordingly, it would save the users time thereby making them more efficient and less frustrated. - 31 -


L. de Voux

The other possibility would be to enable CyberTracker to implicitly connect to an available network when a request has been made to send data. One insightful suggestion which came from the users was that it would be useful for them to know whether a vehicle had outstanding tickets or not. In fact, one user went as far as to illustrate the current procedure which entails radioing head office and having them call the database administrator. The officer then had to wait for a response and the entire procedure lasted almost 5 minutes. Moreover, the response turned out to be inaccurate due to human negligence. It is clear that if the CyberTracker application were able to query a database (which is one of the initial goals of the project) the functionality of obtaining outstanding tickets would then be attainable, without the need to go through any human channels. The user would be able to input a vehicle registration number and have a possible list of infractions returned to screen. According to the manager of the UCT Traffic Department†, this type of functionality would add immense value to the running of the department and would greatly reduce the number of outstanding fines which typically do not get paid. He also mentioned that at least one of the three data-capturers which are currently employed by the department would become redundant as the database would be updated remotely by the field officer. Another advantage that evolved from the discussion would be to utilise the application device as a “management tool” since the position and routes of the field officers could potentially be updated in real time. These could then be inserted on a moving map and used to locate employers out in the field. 5.2.2 Questionnaire Results Personal Information and Experience Of the four officers, there was a normal distribution of the ages between thirty-one and sixty. They all had a minimum of four years experience with only the supervisor exceeding fifteen years. All four owned a cell-phone but only one had previously used a PDA or smart- phone. Likert Scales: Please refer to the table below for the Likert Scale results. Likert Scale Questions: 5. Did you enjoy using the handheld computer? 6. Do you think this application would be useful to other traffic officers? 7. Do you think the information would be useful if it could be downloaded at the office? 8. Would it be beneficial to have the information sent to the office when out in the field? 9. Would you prefer if the information were to be sent automatically without you having to decide? 10. How quickly did the program respond to you? †

Mr. R. September

- 32 -


L. de Voux

Table 3: Likert Scale Results

Questions

Subjects

5

6

7

8

9

10

1

5

5

5

1

5

5

2

5

5

5

2

5

5

3

5

5

5

1

5

5

4

4

5

5

1

5

5

19

20

20

5

20

20

Question Totals

Individual Likert Scale Results 6 5 User 1

Rating

4

User 2

3

User 3

2

User 4

1 0 5

6

7

8

9

Question Figure 15: Bar Chart of Likert Scale Results

- 33 -

10


L. de Voux

Likert Scale Totals

Rating Totals

25 20 15 10 5 0 5

6

7

8

9

10

Question Figure 16: Likert Scale Rating Totals

Open Questions Coinciding with the Observations results, certain users wrote that they expected to proceed to the next screen when selecting an option and it frustrated them when it did not. The most useful feature had the most encouraging answer which was from an officer who patrols Medical Campus. He suggested that the ability to send data automatically and in real time was most useful. It was later discovered that the tickets which were written up by officers on satellite campuses had to be physically delivered to the head office on Upper Campus. It is suspected that officers on campuses other than Upper Campus may find the transmission of data especially useful as they are spread out as far as Cape Town CBD. Other useful comments were that the colour was helpful and that the application was found to be user-friendly. When asked whether any of the screens should be removed from the sequence, no one mentioned anything about the removal of sending data. Moreover, all except for one subject requested that they would like to be in control of when the information gets sent. All the users would like to be notified of the progress of the transmission and would like to be informed of whether data has been successfully sent and received. One user would have preferred a set time in the day when the work has been completed for the device to transmit the data.

- 34 -


L. de Voux

6. Discussion It is clear that the Observation was most beneficial as the officers did not seem to feel comfortable expressing themselves in the Questionnaire (Appendix C). Admittedly the majority of the answers in the Questionnaire are not very useful for our analysis. The open questions seemed to provide the most useful feedback from the Questionnaire. Although many of the answers were brief, there were those who elaborated in the answers and provided useful information. The ones which were most elaborated on were those where “yes” or “no” answers would not suffice. This is something which will be noted when preparing future questionnaires. From both the Observation and Questionnaire the research questions in Section 1.2 were tackled. How does porting CyberTracker to smart-phones affect the usability of the system? We first consider the transition from PDA to smart-phone and how the change in hardware would affect the usability of the system. The first thing to realise is that the interfaces for either device are identical. This is a result of CyberTracker being compatible and representing sequences indistinguishably on either platform. There does however exist other issues which require some attention such as the dissimilarity in the way interruptions can occur. These interruptions could be caused by incoming telephone calls or SMS’. Ideally, the operating system handles these interruptions by allowing CyberTracker to continue running in the background. However, there were bugs found in the software which caused interruptions to be repeatedly mishandled. Moreover, these additional services affect the battery consumption and therefore needs to be monitored more closely. Another difference is that there exist smart-phones which do not use a touch screen and stylus‡. The CyberTracker application is not compatible with these devices as it requires the use of a touch screen. Would having the smart-phone wirelessly communicate with the database have a major impact on the efficiency with which it is used? It would be unfair to draw blanket conclusions from a single case study. However, it is clear that there exist applications which would find a wireless connection with the database extremely beneficial. How well the functionality is used depends entirely on the specific task and the design of the protocols being implemented. Does the extension of transmitting data create additional complexity in terms of usability? No evidence could be found to support the theory that the transmission of data was less usable than any of the existing functionality. However, the users in our case study did not have experience using the CyberTracker application previous to the introduction of wireless communication and therefore had very little to compare the extension to. In fact, only one person had previously used a handheld computer and those with no experience using the device may have fallen prey to the “dancing bear”, whereby they were not

‡

i-Mate SP5

- 35 -


L. de Voux

concerned with how well the wireless database communication worked but were distracted by the mere fact that it was actually capable of working. Should the data be sent automatically, without the user being aware of the procedure? No definitive answer could be deduced for this, however it was found from this specific Questionnaire that these users preferred being in control of when data was sent. It was also clear that they wanted to be notified when data was being sent and received successfully. This would help the user discover transmission errors and whether an alternative means of synchronising with the database would be necessary to offload the information. If data were to be sent periodically the frequency of transmission would need to be further investigated. What is for certain is that CyberTracker has a broad range of applicability and it can therefore be assumed that the frequency at which data would need to be transmitted would be task specific and depend on whether the data is required urgently or not. It would therefore be required to implement all solutions for data to be transmitted both automatically and manually.

- 36 -


7.

L. de Voux

Conclusions and Recommendations

Though the usability evaluations were conducted with too few participants to be statistically relevant, it has served a useful purpose of drawing out areas for improvement and getting ideas for potential applications. It has provided results which would lay the foundation for further evaluation. By providing the ability to remotely communicate with a central database, the paper has shown that the efficiency of the field users, database administrators and those requiring the data can be improved, thereby improving the overall distributed data collection procedure. One advantage is that field users who are not in the vicinity of the base station will no longer be required to take time out to physically go to the docking station. The application also provides management services such as allowing supervisors to maintain contact with the field operators and be able to view their positions on a moving map with as minimal latency as possible. From our results we can conclude that when shifting from one type of hardware to another, there are often subtle factors which may arise and complicate the process. The aim of the evaluation was to ensure that the transition would be as seamless as possible. It was however discovered that the handling of interruptions would be the biggest concern when moving to smart-phones. Though most of the implementation to handle these exceptions would not be in the hands of the CyberTracker application, there exist other means to reduce the number of interruptions. One would not be able to turn off the GSM connection as this would render the GPRS protocol worthless; however all incoming calls could be blocked by changing the settings in Call Barring Settings as well as having the network provider block incoming SMS’. The user evaluation has shown that by expanding the application, no additional usability problems have been introduced. The paper has also established that for our particular test case, users prefer to be in control of when data is to be sent. This would imply that there may exist specific periods when sending data would be appropriate as suggested by Subject 1. By extending the functionality of CyberTracker, it opens up a broader range of applicability. Previously, CyberTracker was not well-suited to many activities which required information to be made available in real-time. These applications are no longer unattainable and may provide a boost to the popularity of CyberTracker. In addition institutions no longer have to be restricted by location and are now able to receive information from anyone on the same network. It is unfortunate that all of our initial goals could not have been achieved before the set deadline. This was however unavoidable as too much time was spent sifting through the existing application which was not documented nor adequately commented. Moreover, there exist very few people who have actually worked on the software and therefore made it difficult to find assistance. Other stumbling blocks include having to hardcode the interfaces and integrating them with the client extension. Perhaps most difficult was having to complete the transmitting functionality before integration and testing could be possible.

- 37 -


L. de Voux

7. Future Work In order to complete the goals we had initially set out for the project, there are areas which require specific attention. The first area which requires attention is that there exists no formal way of representing the information received at the server using the CyberTracker Desktop Application. The information is currently stored in a MySQL database which would need to be converted to a MS Access database format. This would allow the Desktop application desktop to access the sightings and present it in the usual way. Alternatively, the desktop application could be modified to employ a MySQL database. This would eliminate much of the problems which currently exist. This however requires knowledge of Delphi and Pascal. The major section which would need to be tackled is the uploading of information to the mobile device. This process would need to be carefully thought out as there are many possibilities, two of which are considered and discussed in Section 4 (Remote Plant Identification and Previous Tracker Position) and one in Section 5 (Outstanding Tickets). What is evident is that there are many possibilities, most of which are task specific. In order to maintain the broad applicability of CyberTracker, generic Control Classes would need to be created to allow users to generate task specific screens to query the database. How the information received should be presented on the mobile device would need to be evaluated as many usability problems are anticipated. Moving maps were considered a useful means of representing information but the following would need to be considered: •

Would the map be transmitted from the server to the client?

•

Should the map be stored on the mobile device?

•

Should the mobile device or desktop application be used to plot the positions of significant events?

•

Is there a possibility of compression?

•

How useful is this service?

There is also the possibility to allow the desktop application to send information to the mobile device. The server would need to be extended to have an interface to send information. This would require the CyberTracker server code to be modified and again would require knowledge of Delphi and Pascal. Given more time and resources, a more extensive usability assessment would be possible. This would allow the findings of our initial Experimental Design to either be confirmed or refuted. A larger sample would be necessary for the experiment to be statistically relevant. The hardcoded data transmission screens could also be improved upon by using images. This has been mentioned as a major design challenge and could be overcome given more time and experience with the code.

- 38 -


L. de Voux

9. References [1] Baron, R.A. and Byrne, D. Social Psychology: Understanding Human Interaction. 5th Ed. Massachusetts: Allyn and Bacon. (1987) [2] Baruth, L.G. and Manning, M.L., Multicultural Counseling and Psychotherapy : A Lifespan Perspective. New York : MacMillan. (1991) [3] Bodley, G.J.H. Design of Computer User Interfaces for Third World Users. Unpublished masters dissertation, University of Port Elizabeth. (1993) [4] Caporuscio, M., Carzaniga, A., Wolf. An Experience in Evaluating Publish/Subscribe Services in a Wireless Network, Dipartimento di Informatica Universit `a dell’Aquila, Department of Computer Science, University of Colorado. , WOSP '02, ACM, 2000, ISBN 1-1-58113-563-7 [5] Casson, W.C. Language, Culture and Perspectives. New York: MacMillan.( 1981)

Cognition:

Antropological

[6] Chen, M., Chen, J.C., Lan, C., Chang P. The Development of SmartPhone-Based Home Care Evaluation Support System. Department of Industrial Engineering, Chung Yuan Christian University, Institute of Health Economics and Policy, National Yang-Ming University, Institute of Health Informatics and Decision Making, National Yang-Ming University. IEEE (2005). [7] Davis, F.D. Perceived Usefulness, Perceived Ease of Use, and End User Acceptance of Information Technology, MIS Quarterly, 13 (1989), 318339. [8] Dugas, D. Configuring and managing a large-scale monitoring network: solving real world challenges for ultra-lowpowered and long-range wireless mesh networks, Int. J. Network Mgmt (2005) 269–282 [9] Dutta, A., Zhang, T., Madhani, S., Taniuchi, K., Fujimoto, K., Katsube, K., Ohba, Y., Schulzrinne, H. Secure Universal Mobility for Wireless Internet, Telcordia Technologies, Piscataway, NJ, Toshiba America Research Inc., Piscataway, Computer Science Department, Columbia University, Mobile Computing and Communications Review, Volume 9. [10] Hoa, Y., Qiang, F., Chuang, L., Zhangxi, T., Rong, D., Yishu, L., Yanfei., F. Mobile Police Information System Based on Web Services, Department of Computer Science and Technology, Tsinhua University, National Natural Science Foundation of China. (10 June 2004) [11] Kim, S., Interdisciplinary Cooperation. In Baeker, R.M. (Ed.), Readings in Human-Computer Interaction: Toward the Year 2000. San Francisco: Morgan Kaufmann, (1995) 305-311. [12] Kling, R., Controversies About computerization and the Organization of White Collar Work. In Baeker, R.M. (Ed.), Readings in

- 39 -


L. de Voux

Human-Computer Interaction: Toward the Year 2000. San Francisco: Morgan Kaufmann, (1995) 305-311. [13] Lin, Y., I-Chien, J., Chow-In, P., Chen, Y., Wong, J., Jan, G. A Wireless PDA-Based Physiological Monitoring System for Patient Transport. IEEE, (VOL. 8, NO. 4, Dec 2004), 439 – 447 [14] Marsden, G., Cherry, C., Haefele, A. Small Screen Access to Digital Libraries, Collaborative Visual Computing Group,Department of Computer Science, University of Cape Town, (April 20-25, 2002) , in Proceedings of CHI 2002, (1Feb 2004) ACM 1-58113-454 [15] Stander, A., Rossouw, SF. Wireless Communication for Data Access in Developing Countries, Dept of Information Systems, University of Cape Town [16] Thorstensen, B., Syversen, T., Bjørnvold, T., Walseth, T. Electronic Shepherd – A Low-Cost, Low-Bandwidth, Wireless Network System, Telenor R&D, ACM 1-58113-793-1, MobiSys’04, (June 6-9, 2004) 245 – 255. [17] Yu, P., Yu, H., Lesions Learned from the Practice of Mobile Health Application Development, School of IT and Computer Science, University of Wollongong, School of Biomedical Science, Chongqing Institute of Technolog. (COMPSAC’04), IEEE 0730-3157/04 (2004). [18] Jones, M. Marsden, G. Mobile Interaction Design. John Wiley & Sons, Ltd. 2005. [19]

UCT Traffic Rules: Students

Online References [i]

en.wikipedia.org/wiki/Smartphones

[ii]

www.xilinx.com/publications/glossary.htm

[iii]

www.crtc.gc.ca/dcs/eng/glossary.htm [iv] highered.mcgrawhill.com/sites/0072464011/student_view0/chapter6/glossary.html

[v]

www.nitronex.com/education/glossary.html

[vi] dspvillage.ti.com/docs/catalog/dspplatform/details.jhtml [vii] wand.cs.waikato.ac.nz/pubs/19/html/node6.html [viii] Steventon, J. Building CyberTracker.htm [ix] Steventon, J. http://www.steventonconsulting.com/CyberTrackerSDK.aspx [x]

http://www.microsoft.com/downloads/details.aspx

- 40 -


L. de Voux

Appendix A: Building Instructions for the extension of CyberTracker v3.48 Scope and Limitation This document provides a detailed explanation of the build procedure for the extension of CyberTracker v3.48 by adding the Wireless Communication GPRS functionality. In addition the client platform considered is WinCE (not PalmOS). The document should therefore be used in conjunction with [18] and [19] for complete build instructions. In order to implement GPRS the only code that was required to change is those used to create the Client.dll and the CyberTracker.exe. The rest of the files were left unchanged and therefore have their build instructions excluded from this document. The files which are not required to be changed were simply used from the previous version (v3.48) of the application. Required Software: Visual Studio 2005; Microsoft Visual Studio .NET 2003; ActiveSync; Windows Mobile PocketPC 2003 SDK. Required Hardware: PocketPc running Windows Mobile 2003 or later with a wireless internet connection. Overview 1. Compile Client.sln/Client.vcw to create Client.dll. This is the dynamically linked library which the server will use. 2. Compile CyberTracker.sln to create CyberTracker.exe. This is the mobile application which will be installed on the mobile device. 3. Run build.cmd to create the .cab files and insert them and other the necessary files into the CT3\Build directory. 4. Remove the existing CyberTracker client application from the mobile device you wish to install the new version of CyberTracker onto. 5. Run C:\ct3\Builds\Make\ct3.exe. This will open the CyberTracker server/desktop application. 6. When synchronising with a mobile device for the first time, the desktop application will first install the CyberTracker.*.CAB on the mobile device. The second synchronise will then installed the prepared sequences. Build - Copy the CT3 folder to the root of the C drive. CyberTracker.exe 1. Open the C:\ct3\Client\Host\WinCE\CyberTracker.vcw in either Embedded Visual C++ or C:\ct3\Client\Host\WinCE\CyberTracker.sln Visual Studio 2005*.

*

Visual Studio 2005 will require the .vcw project to be converted to .sln.

- 41 -


L. de Voux

2. Under Project > Settings > C/C++ > Category, change the default to Preprocessor and add the following line to the Additional include directories. ..\..\Framework,..\..\\Host\WinCE\GarminIQUE,..\..\Controls,..\..\Host\Common,..\..\Host \WinCE,..\..\Main 3. Go to Build > Rebuild All. This will create Cybertracker.exe and insert it into the output folder (default - C:\CT3\Client\Setup\WinCE\Build\ARMV4Rel). Client.exe 1. Open C:\ct3\Client\Host\ClientDll\Client.sln in Microsoft Visual Studio 2005. 2. In Project Settings > C/C++ > General > Additional Include Directories, add the following line: ..\..\GPRS\InternetConnector;..\..\Main;..\..\Framework;..\..\Controls;..\..\Host\WinC E\GarminIQUE;..\..\Host\Common;..\..\Host\WinCE;..\..\GPRS\;..\..\GPRS\Message 3. In Project Settings > Linker > Input > Additional Dependencies, add the line: winsock.lib Uuid.lib Ws2.lib Wininet.lib? 4. One can now create Client.dll by clicking Build > Rebuild Solution Build.cmd 1. Run C:\ct3\Builds\Build.cmd from the command line and enter ‘Y’ at the prompt. The created version of CyberTracker C:\ct3\Builds\Make\ct3.exe

can

now

be

run

by

executing

Problems arising when building Their existed some complications when building the CyberTracker application for the first time. The biggest issue was the fact the when building the projects, the compiler had trouble locating certain files. The first problem was that when including files using the #include command, the path to the file was not relevant to the file calling the additional file. Initially we attempted to solve the problem by manually inserting the correct path to the file to be located. What was later discovered is that the directories can be made available by adjusting the project settings. This can be done by adding the appropriate directory paths in Project Settings > C/C++ > General > Additional Include Directories. The compiler also had problems locating files such . This was caused by Embedded Visual C++ not having them in the standard include path. Another complication that arose was due to the fact that the IDEs installed on the computers which we were working on were inconsistent with the ones originally used when developing CyberTracker v4.38. This resulted in certain unexpected behaviour from the compiler and had undesired consequences. This problem was overcome by acquiring the necessary IDEs or converting existing project files. Many problems which can be found when extending the current implementation of CyberTracker is due to lack of concrete software engineering principles. This made

- 42 -


L. de Voux

understanding the program unnecessarily complicated and breaks down the consistency expected when developing product of this magnitude. Due to the fact that no documentation for the application existed, the comprehension of the system was prolonged. It proved extremely difficult understanding how the classes interacted and which sections were responsible for which aspects of the final solution. Moreover, the lack of adequate commenting made certain functions tedious to fully understand. Very little could be done to overcome this challenge except to request assistance and persevere. The next unanticipated challenge is the due to the fact that the interfaces for the control classes which have been developed, have to be manually hardcoded into the source code. This requires an in depth understanding of the control classes and meticulous programming as the interfaces cannot be imported from the server. Moreover, there are internal class methods which need to be generated to allow protected and private variables to be assigned values.

- 43 -


L. de Voux

Appendix B: Resources Required Computers with internet access JCreator for developing Java Beans JBoss as a container for the Java Beans Embedded C++ for developing C++ cell phone client Microsoft Visual Studio .NET Microsoft Visual Studio 2005 2 smart-phones running the Windows Mobile Operating System with GPS and WiFi capabilities. 2 sim cards Cell phone airtime to allow access to the GPRS network

- 44 -


L. de Voux

Appendix C: Traffic Questionnaire and Responses Master Copy 1.

Age:

2.

For how long have you been a traffic-officer (yrs)?

Under 20

Under 1 yr

20 - 30

1- 3

31 - 40

41 - 50

4 - 8

9 - 15

Yes

No

3.

Do you own a cell-phone?

4.

Have you previously used a PDA or smart-phone?

5.

Did you enjoy using the handheld computer? not at all

6.

51 - 60

Over 60

Over 15

Yes

1

2

No

3

4

5

very much

Do you think this application would be useful to other traffic officers? not at all 1 2 3 4 5

very much

7.

Do you think the information would be useful if it could be downloaded at the office? not at all 1 2 3 4 5 very much

8.

Would it be beneficial to have the information sent to the office when out in the field? not at all 1 2 3 4 5 very much

9.

Would you prefer if the information were to be sent automatically without you having to decide? not at all 1 2 3 4 5 very much

10. How quickly did the program respond to you?

Fast 1

2

3

4

5 Slow

Please provide a reason reasons for your answers of the following questions. 11. Was there anything which frustrated you about the program? _______________________________________________________________

12. Which feature did you find most useful? _______________________________________________________________ 13. If you were able to remove any of the screens, which would it be? _______________________________________________________________

- 45 -


L. de Voux

14. Would you like to decide when the information gets sent? _______________________________________________________________ 15. Would you like to be notified while the information is being sent? _______________________________________________________________

- 46 -


L. de Voux

Test Subject 1

- 47 -


L. de Voux Test Subject 2

- 48 -


L. de Voux

Test Subject 3

- 49 -


L. de Voux

Test Subject 4

- 50 -


L. de Voux

Appendix D: Deliverables Project presentation to staff – 15 August 2006 Hand in of final report – 3 November 2006 Poster, web page and research paper due – 10 November 2006 Project demonstration to supervisors and second readers – 13-17 November 2006 Final Project Presentation – 20-24 November 2006

- 51 -


L. de Voux

Appendix E: Traffic Ticket

- 52 -

Distributed Data Collection: Evaluating the Usability of ...

Distributed Data Collection: Evaluating the Usability of ...

Suggest Documents

Smartphone-Based Distributed Data Collection

EVALUATING USABILITY-SUPPORTING

Distributed Privacy Preserving Data Collection ... - Semantic Scholar

Energy-efficient Adaptive Distributed Data Collection

Evaluating the Usability of Mashups Applications - UPV

Evaluating web usability - Florence Martin

Data Diversity of a Distributed Honey Net Based Malware Collection ...

Evaluating Usability of Information Visualization ... - Semantic Scholar

Evaluating Software Usability of Geographic Information ... - CiteSeerX

Evaluating Usability of Information Visualization ... - Semantic Scholar

Evaluating the Usability of the Mobile Interface of an ... - CiteSeerX

Evaluating the Usability of the Mobile Interface of an ... - CiteSeerX

Evaluating the Scalability of Distributed Systems

Evaluating the Performance of Software Distributed ... - Infoscience

Evaluating the performance of Distributed Ledger

Evaluating the Usability of the Scale Metaphor for ... - CiteSeerX

Evaluating the Usability and the Communicability of Grid ... - ThinkMind

The Challenge of Distributed Data Mining and Distributed Data ...

The Challenge of Distributed Data Mining and Distributed Data

Creating a Data Collection for Evaluating Rich ... - DORAS - DCU

Evaluating a mobile data-collection system for production information ...

Evaluating On-Demand Data Collection with Mobile ... - IEEE Xplore

Distributed Data Collection through Remote Probing in ... - CiteSeerX

distributed data collection: archiving, indexing, and analysis - LASS