Exploring techniques for robust management and …mdv/courses/CM30082/projects.bho/2008-9/BUR… ·...

Exploring techniques for robust management and retrieval of

personal information on a mobile platform

Daniel Burnham

Bachelor of Science in Computer Science with HonoursThe University of Bath

April 2009

This dissertation may be made available for consultation within the Uni-versity Library and may be photocopied or lent to other libraries for thepurposes of consultation.

Signed:

Exploring techniques for robust management and

retrieval of personal information on a mobile

platform

Submitted by: Daniel Burnham

COPYRIGHT

Attention is drawn to the fact that copyright of this dissertation rests with its author. TheIntellectual Property Rights of the products produced as part of the project belong to theUniversity of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone who consults itis understood to recognise that its copyright rests with its author and that no quotationfrom the dissertation and no information derived from it may be published without theprior written consent of the author.

Declaration

This dissertation is submitted to the University of Bath in accordance with the requirementsof the degree of Batchelor of Science in the Department of Computer Science. No portion ofthe work in this dissertation has been submitted in support of an application for any otherdegree or qualification of this or any other university or institution of learning. Exceptwhere specifcally acknowledged, it is the work of the author.

Signed:

Abstract

This project looks at how Personal Information Management (PIM) currently supportsusers in completing their everyday tasks. Most people ignore search functions in favour ofhierarchical folder navigation (Bergman, Beyth-Marom, Nachmias, Gradovitch and Whit-taker, 2008). The project considers the problems and potential design opportunities for per-sonal information retrieval on the move. A system has been created with a user-subjectiveapproach to system design to improve the process of personal information retrieval. Itautomatically adds context obtained from a mobile device to information as it is acquired.The file location metaphor is used to allow users to browse and retrieve information in thesame context it was previously used.

Contents

1 Introduction 1

1.1 Project Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Literature Survey 4

2.1 Personal Information Management . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 History of PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Mobile PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 PIM Tasks - Information Retrieval . . . . . . . . . . . . . . . . . . . 6

2.1.4 Email in PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.5 PIM Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Function Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Levels of Automation . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Design of Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Internet Information vs Personal Information Retrieval . . . . . . . . . . . . 14

2.4 Personal Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 Hierarchical Method (Navigation) . . . . . . . . . . . . . . . . . . . 15

2.4.2 Search Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.3 Predictions and Findings From the Search and Navigation Study . . 17

2.4.4 Possible Explanations for the Search and Navigation Study Results . 17

ii

CONTENTS iii

2.4.5 Conclusions and Future Directions from the Search and NavigationStudy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 The Strength of the Location Metaphor . . . . . . . . . . . . . . . . . . . . 19

2.6 User-Subjective Approach to PIM System Design . . . . . . . . . . . . . . . 20

2.6.1 Reasons for the User-Subjective Approach . . . . . . . . . . . . . . . 20

2.7 Current File Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.1 Windows Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.2 Mac OS X Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.3 iPod Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Requirements 25

3.1 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.3 Questionnaire Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2 Data Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.3 Environmental Requirements . . . . . . . . . . . . . . . . . . . . . . 41

3.2.4 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.5 Usability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Design 44

4.1 Conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.2 Interaction Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1.3 Interaction Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1.4 Expansion of the Conceptual Model . . . . . . . . . . . . . . . . . . 56

4.2 Physical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.1 Feasibility Study - Device Platform . . . . . . . . . . . . . . . . . . . 59

CONTENTS iv

4.2.2 Feasibility Study - Server Platform . . . . . . . . . . . . . . . . . . . 63

4.3 Design Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Implementation and Testing 66

5.1 Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3 System Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.1 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.2 Mobile Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.4.1 Release of the System . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.4.2 Test Frameworks Used . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6 User Evaluation 85

6.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2 Questions Asked and Data Collected . . . . . . . . . . . . . . . . . . . . . . 86

6.3 The Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.4 The Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.5 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.5.1 Adaption of Location Metaphor . . . . . . . . . . . . . . . . . . . . . 88

6.5.2 Reduction in Organisation Effort . . . . . . . . . . . . . . . . . . . . 89

6.5.3 Ease of Usability, But Lack of Integration . . . . . . . . . . . . . . . 89

6.5.4 Increased Use of Retrieval Tasks . . . . . . . . . . . . . . . . . . . . 89

6.5.5 Physical Implementation Bugs . . . . . . . . . . . . . . . . . . . . . 90

6.5.6 Overlooked Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7 Conclusions 92

7.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.2 Relationship to the Literature Concepts . . . . . . . . . . . . . . . . . . . . 93

CONTENTS v

7.2.1 User-Subjective Personal Information . . . . . . . . . . . . . . . . . 93

7.2.2 Storage and Organisational Problems . . . . . . . . . . . . . . . . . 94

7.2.3 Preference For Navigation . . . . . . . . . . . . . . . . . . . . . . . . 95

7.2.4 The Location Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.3 Strengths and Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.3.1 Comparison to Requirements . . . . . . . . . . . . . . . . . . . . . . 96

7.3.2 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.3.3 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A Requirements Questionnaire - Example Screenshot 107

B Paper Prototype - Example User Route 108

C Ethics Checklist 109

D Evaluation User Manual 111

E Client Code 113

E.1 File: PimText.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

E.2 File: BrowseView.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

E.3 File: PhotoView.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

E.4 File: DefaultAccessPointView.py . . . . . . . . . . . . . . . . . . . . . . . . 123

E.5 File: IndexInboxView.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

E.6 File: MakeUploadView.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

E.7 File: NoteView.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

E.8 File: ContextFunctions.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

E.9 File: StorageUploadFunctions.py . . . . . . . . . . . . . . . . . . . . . . . . 126

F Server Code 130

F.1 File: addItem.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

F.2 File: addLocation.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

CONTENTS vi

F.3 File: addUser.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

F.4 File: includes.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

F.5 File: jpg upload to url.php . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

F.6 File: retrieval.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

F.7 File: verfyUserExists.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

F.8 File: verifyFileExists.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

List of Figures

2.1 Navigational File Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Requirements Questionnaire - File Organisation Question 1 . . . . . . . . . 28


3.3 Requirements Questionnaire - File Organisation Question 3 and 4 . . . . . . 30


3.5 Requirements Questionnaire - File Organisation Question 6 and 7 . . . . . . 32





4.1 Prototyping Evaluation - Filter Based . . . . . . . . . . . . . . . . . . . . . 49

4.2 Prototyping Evaluation - Location Metaphor . . . . . . . . . . . . . . . . . 49

4.3 Prototyping Evaluation - Dates Not In A Taxonomy . . . . . . . . . . . . . 50

4.4 Prototyping Evaluation - Hierarchy Location In the Title . . . . . . . . . . 51

4.5 Prototyping Evaluation - Hierarchy Location In A Dedicated Screen . . . . 51

4.6 Prototyping Evaluation - Paper Prototype Device With Inefficient Date Se-lection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7 Prototyping Evaluation - Further Contexts Available as Well as InformationItems to View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2 System Architecture Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii

LIST OF FIGURES viii

5.3 Three-Tier Client Server Architecture . . . . . . . . . . . . . . . . . . . . . 69

5.4 Class Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.5 PimText View Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6 BrowseView User Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.7 BrowseView Navigation of Messages . . . . . . . . . . . . . . . . . . . . . . 76

5.8 Photo Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.9 Data Acquisition Methods for Images and Notes . . . . . . . . . . . . . . . 79

5.10 SimpleTest Test Case Example . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.1 Requirements Questionnaire - Example Screenshot . . . . . . . . . . . . . . 107

B.1 Paper Prototype - Example User Route . . . . . . . . . . . . . . . . . . . . 108

List of Tables

2.1 Sheridan-Verplank scale of human-machine function allocation in automatedsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ix

Acknowledgements

I would like to express my thanks to my project supervisor Dr Leon Watts for his supportand guidance throughout the project. I would also like to thank Hazel for keeping mecompany while I completed this dissertation. Finally I would like to thank my parents forgiving me the ink and paper on which this document is printed.

x

Chapter 1

Introduction

Personal Information Management (PIM) refers to the practice and study of the activitiespeople perform in order to acquire, organise, maintain, retrieve and use information itemseveryday to complete various roles (both in a working and social environment). An idealof PIM is the constant availability of correct information, in the correct place, in thecorrect form, with adequate completeness and quality to meet the current need, (Teevanand Jones, 2008).

This project sets out to examine the relationship between personal information and thecontext of mobile device usage. Personal information comprises calendar appointments,contact lists, to-do lists, address books, emails, pictures, documents and any other itemsthat allow people to complete both work and social related tasks.

1.1 Project Aims

The main aim of the project is to investigate if it is possible to improve the retrievalof personal information items with a user-subjective approach to Personal InformationManagement (PIM) system design.

In order to design a new PIM system with improved retrieval techniques it will be essentialto investigate the origins of PIM and relevant retrieval techniques. It will also be importantto look for information on the possible function allocation of the user and the device of apotential system.

It is important that this system is designed for a mobile platform, in order to fulfill themain aim of this project. There are two reasons for this; firstly, as PIM is part of a personseveryday life and the activities associated with PIM can (and the majority of the time do)occur in transit. Secondly, mobile devices offer the opportunity to automatically acquirecontext relevant to the information when it is being acquired. For example, the locationand time of acquirement.

1

CHAPTER 1. INTRODUCTION 2

1.2 Objectives

By extending the aims into potential objectives for the project, it is possible to define afocus for the work that will be undertaken. These objectives can be summarised as:

• The identification of the core concepts in contemporary literature in relevant domains,including Personal Information Management, information retrieval techniques and theappropriate system design approach.

• The identification of the scope of the project, to be able to appropriately implementa new PIM system where there is evidence that a potential idea could be successful.

• The identification of requirements based on the initial idea for a new personal infor-mation retrieval system and the relevant literature that has been gathered.

• The iterative development and evaluation of a new PIM retrieval system based on auser-subjective approach.

• On successful implementation, the assessment of the usability of the new system.

• The identification of future improvements, extensions or directions for the system.

1.3 Dissertation Structure

This section provides an overview of the chapters of this dissertation, which document thework that has been undertaken in this project.

• Chapter 2 reviews the literature relevant to the creation of a new PIM system. Thetopics covered include the history and role of PIM - especially in a mobile capacityand the possible implications of different levels of function allocation between humansand the machines running the system. Concepts such as the location metaphor, thefact that navigation is preferred to searching for personal items and the principlesinvolved with a user-subjective approach to PIM system design are also investigated.

The literature review concludes by arguing that it is necessary to design a user-subjective PIM system that is able to organise personal information items togetherthat are related by the same subjective topic. It is argued the system should includethe ability to retrieve items using the same context they were last used in. Just asimportantly, it is argued that the system should use dynamic directory structuresthat adapt to the context type (e.g. time or physical location) that the user wantsto use to retrieve the item.

• Chapter 3 builds on this literature review by taking the apparent need for a user-subjective PIM system that attempts to remove loss of control over the way personalinformation is managed when using a mobile device. By deriving a thorough set of

CHAPTER 1. INTRODUCTION 3

requirements from the literature gathered, a brief investigation of existing file browsersis conducted as well as the analysis of results gained from a questionnaire targetedat potential users of the system.

The chapter concludes by specifying a list of functional, data, environment, user andusability requirements that will be used during the design of the system in the nextchapter.

• Chapter 4 uses these requirements within various design activities that aim to workwith the users through prototyping cycles until a system is successfully constructed.Using the results from the many iterations of prototyping, the two types of design,conceptual and physical are considered. A conceptual model is chosen for the design,which is then expanded and a detailed description of the interface is developed forthe physical design.

The chapter concludes with a list of detailed design decisions that allow the imple-mentation phase to begin. A feasibility study is also conducted to determine the bestmobile platform to be used during development.

• Chapter 5 uses the design and requirements of the previous chapters, to develop asystem architecture and database structure. The system that has been implemented isthen described, including the mobile phone application (client) and web server scriptsthat interact with the database. The functions of both the client and the server aredescribed with justification. The implementation is broken down into different tasksthat user will perform within the new PIM system, such as context based retrievalusing an extension of the location metaphor, retrieval through dynamic directorystructures as well as the different tasks involved with information attainment.

The chapter concludes with a final description of the system that has been imple-mented, a description of the testing that has been carried out and the tools that wereused to do so. The process involved with preparing the scripts into one applicationfile is then documented. These could then be distributed to users for an evaluationthat will be conducted in the following chapter.

• Chapter 6 takes the system that has been built and evaluates it by conducting semi-structured interviews with participants that have been using the system for at least aweek. The results of this evaluation are then analysed in terms of the main conceptsidentified in the literature and the overall value of the final system is considered.

The chapter concludes that the new PIM system has generally been successful infulfilling the requirements of the users as well as implementing the key conceptsidentified in the literature. Therefore, providing results that can be used to determinethe success in which the project has met its original requirements.

• Chapter 7 concludes the dissertation by summarising the work that has been un-dertaken during this project. The system is put back into the context of the mainconcepts in this problem domain, with the evaluation of its strengths and weaknesses.Finally, considerations for future work are noted.

Chapter 2

Literature Survey

This project considers the creation of a new personal information system on a mobile devicewith the intention of improving problems that exist with current PIM techniques.

Before starting the development process, it is first important to investigate the key areasof interest, such as the current problems and research regarding PIM. The investigationwill be focused on methods of organisation and retrieval of information. The functionallocation of the system to be created will also be considered, determining the amount ofautomation the system should have over the retrieval of personal information, which willin turn influence the user’s control over the environment.

This research is necessary in order to gain a greater knowledge of the area, which can beused to re-define the scope of the project and help to understand the potential relevanceof the finished project to the rest of the PIM field.

2.1 Personal Information Management

Recall, that PIM refers to the practice and study of the activities people perform in order toacquire, organise, maintain, retrieve and use information items everyday to complete variousroles (both in a working and social environment). An ideal of PIM is the availability ofcorrect information, in the correct place, in the correct form, with adequate completenessand quality to meet the current need, (Teevan and Jones, 2008).

2.1.1 History of PIM

PIM is a relatively new research field stemming from ancient roots (Jones, 2007). Beforethe written word overtook from the oral, human memory was the primary means by whichinformation was preserved.

As information was increasingly being stored in documents, there became a need to find

4

CHAPTER 2. LITERATURE SURVEY 5

effective ways in which to manage them. Over time, many tools have been developed forthis purpose. An early example of an information management tool is the vertical fillingcabinet.

Actual information management dialog is thought to have begun at the end of World WarII with the essay As We May Think, Bush (1945). Bush argued that as humans turnedfrom war, scientific efforts should be shifted towards making previously collected humanknowledge more accessible. Bush hoped that technology might be able to be used to extendthe human ability to handle information and increase the exchange of this information.

At a similar time, Shannon and Weaver (1963) developed a theory of communication thatstated that the content of a message could be measured for its “capacity to reduce uncer-tainty”. Over time, this main point has been seen to be overly restrictive (Jones, 2007).However another point of the paper still remains today; that the value of information is“not absolute but relative to the context”. At the time of this paper, the context includedthe intentions of the sender, the method of delivery and the current state of the recipient’sknowledge. However, this line of thought can also be extended to include different contextand is still applicable today.

The term “personal information management” appears to have first been used in an articleby Lansdale (1988), which explored the potential of using the personal computer to enhanceand individuals ability to process and manage information at around the same time thefirst PIM tools appeared, providing limited management of appointments, scheduling, to-dolists, phone numbers and addresses.

In more recent times a growing PIM community has emerged. Teevan and Jones (2008)details the motivations of the community surrounding the PIM area. These can be sum-marised as:

1. PIM related research is scattered across exiting disciplines: For example, the informa-tion needed to complete a task is often scattered - used within in a different locationor application. PIM related research is scattered across many diverse disciplines suchas cognitive psychology, human-computer interaction, database management, artifi-cial intelligence, information and knowledge management, information retrieval andinformation science.

2. PIM concerns often fall through the cracks between these disciplines: Not only is thestudy of the information and the environment hosting the information important, butPIM also requires the study of people as they work in their own information environ-ments over a period of time. Therefore, it is generally not suitable to use a lab basedenvironment over a short period of time. PIM requires the investigation of all aspectsof the personal information lifecycle, from the acquisition of the information and itsorganisation so that it can be used repeatedly to the maintenance and archiving ofthe information.

3. PIM continues to increase in importance and relevance: PIM matters are appearingnot only in academic publications but more and more in the national press which


reflects the growing interest in PIM matters. Popular press articles will often containan article relating to a PIM topic such as information overload. For example, mostweeks it will be possible to find an article on RIM’s Blackberry features, Apple’siPhone features or the culture of the people that use the devices.

2.1.2 Mobile PIM

As previously mentioned, PIM is the process of acquiring, organizing, maintaining, retriev-ing, and using information that is relevant to its owner and their everyday life. With all ofthese activities occurring frequently in transit, whether its creating or altering some aspectof personally significant information, the use of mobile support is indispensable.

Wiberg and Ljungberg (1999) highlight that most research conducted into mobility hasbeen on such issues such as battery life, network connections, portability, discovery and therisk of data loss. But now user-centred research is an important field in its own right (e.g.Heath and Luff, 1991).

With people now having the ability to work away from their regular workspace, PersonalInformation Managers have moved onto mobile devices. Perry, O’hara, Sellen, Brown andHarper (2001) describes this as a new way of working, characterised by functioning anytime,anywhere.

Working only within an office space means that many of the difficulties associated withmobility and PIM are not encountered. This is largely to do with the fact that the officebrings familiarities that allow greater freedom in how things can be organised. Thesefamiliarities are in both the environment and the resources that are available in the officeenvironment. For example when something breaks in the office, it is generally known howto go about fixing it. This is because the technology and the structure of the information inthe office are well understood. The structure of the information provided should be suitedto the needs of the tasks that are being performed.

However, when out of the office, working anywhere with a mobile device, direct access tothe knowledge of who to seek to get support is not available. There is less control overthe configuration of the environment and therefore less control over the way that work ismanaged. An example of this within personal information organisation can be the wayin which the use of a static hierarchical directory structure means that control of theinformation environment is removed from the user.

2.1.3 PIM Tasks - Information Retrieval

An interesting approach to retrieval is the APDA2 (Associative Personal Digital Assist)(Falke, 2008) which attempts to address some of the existing problems. APDA2 is a PIMsystem that is based on an associative information network in which manual information aswell as automatically derived context is assigned to information to allow indexing to takeplace automatically.


Falke (2008) states that whilst many mobile solutions exist that attempt to support PIM,there is “no adequate solution yet”. They explain that this is due to many problems suchas hardware, usability and flexibility. The main reason for no complete solution is said tobe the lack of appropriate underlying information structure.

Cai, Dong, Halevy, Liu and Madhavan (2005) state how there is a problem with the “explo-sion of information” in digital form, and although it is a hot topic of research, it is focusedon the WWW and not so much on individual user’s collections of information. It is clearthat there is a “critical” need for good search and query tools for this purpose. This problemis “exacerbated by the proliferation” of varied electronic devices such as PDAs and mobilephones that can contain subsets or variations of personal data. SEMEX is a “SEManticEXplorer” that offers search-by-association as opposed to searching through directories orperforming a keyword search. This approach was used as the authors saw one of the largestproblems at the moment to be the mismatch between the current organisation of data andthe organisation that is required in order to naturally support services. This is due to thefact that at the moment, data is stored in static directory hierarchies. Bush (1945) illus-trated that our mind works by following associations between objects and formed the basisfor SEMEX; constructing a database of objects and the relevant associations between themto allow browsing by association. For example, by objects such as Person, Publication andMessage with associations such as AuthoredBy, Cites and AttachedTo.

APDA2 builds on this idea, retrieving information by traversing the network or searching inthe shared neighbourhoods of relevant items. Context information is then used for definingautomatic associations. Brown, Carter, Eldridge, Flynn, Lamming, Louie, Robinson andSellen (1994) and Lamming and Flynn (1994) have both shown that the context of an eventsuch as writing a document, can be easier to remember than abstract properties such asthe filename.

2.1.4 Email in PIM

The use of email plays an interesting role in PIM; created approximately 20 years agoto send electronic messages and not designed for PIM at all. However, for many peopletoday their email client is the only application that deals with all aspects of their personalinformation. Email can be useful in PIM as it is able to perform multiple functions, withthe ability to move data around in useful ways. Email is typically used for 3 PIM functions:

• Task Management

• Personal Archiving

• Contact Management

However, as email was invented without much consideration for PIM, there are several issueswith the use of email as a personal information manager. The main issues as highlighted


by Whittaker, Bellotti and Gwizdka (2006) are data fragmentation and the lack of directsupport for PIM functions.

Fragmentation

Fragmentation occurs in an email when messages are left in the inbox and not relocated tothe appropriate applications. Whilst there are a several reasons for doing this, it is mainlydue to the user viewing the movement as too much effort or that it would appear to themfor the message to be more meaningful to be kept in email.

A useful example of this is when a user has to deal with an attachment to an email. Theattribute that would most likely help us retrieve the attachment “the salient cue” is thesender of the email. But this attribute would be lost if the attachment was moved awayfrom email and put into the file system. However, an attempt to retain this contextualinformation can lead to its own problems. For example, duplicating the folder hierarchyof email could lead to related documents being stored separately in the file system andtherefore causing difficulties in the collation of the information.

Whittaker et al. (2006) identifies two (opposing) architectural techniques in order to addressthese problems: Centralisation and Information Extraction. Centralisation involves puttingall PIM functions in email, whereas Information Extraction is the opposite and attemptsto migrate everything to dedicated applications where email data is then accessible.

Centralisation

Centralisation is weak used as a technique with email clients, which do not handle all PIMfunctions well (Bellotti, Ducheneaut, Howard, Smith and Grinter, 2005), (Whittaker, 2005).For instance, accumulating messages in the inbox in a disorganised manner does not scalewell as the number of emails increases. This is due to the fact that the salience andaccessibility of each message decreases as the quantity of messages in the inbox increases.

Another strategy suggested is to group all messages into folders of related items, allowingyou to work more efficiently and coherently. However, this requires the user to keep tothe habit of putting the emails into the folders as they arrive and to keep checking thefolders as they check the inbox. Another strategy in-between these two is to classify theinbox, making it easier to process tasks as they would be related by a list, reducing theinformation clutter whilst increasing the task salience.

Gwizdka and Chignell (2004), Venolia and Neustaedter (2003) and Wattenberg, Rohall,Gruen and Kerr (2005) describe tree and flat representations of information that is relatedto tasks. They state how these are important visualisation techniques in representing inboxtasks. However, the representations rely on threads to determine whether a message relatesto a common task, which can be weak as topics can drift. Topics tend to drift using email asit involves social humans sending messages. To try to overcome the problem with threadsBellotti et al. (2005) came up with “Thrasks”, which are user customisable collections thatrepresent task collection as more than just a series of messages.


Dumais, Cutrell, Cadiz, Jancke, Sarin and Robbins (2003) looked at the argument thatthe solution to PIM will come in the form of search. They came to the conclusion thatsearch will only be form part of the solution as it is only good for accessing informationthat has already been identified as relevant. It is not able to remind the user, as remindingis “extrinsic”, instead of user initiated.

Data Extraction

Data extraction can also be useful for personal archiving and contacts management butnot so much for task management. This is shown by Blandford and Green (2001) as manyusers do not make use of dedicated task management software as they must consciouslyremember to use it. Personal archiving and contact management are not as closely tied tothe conduit function of email as task management is. Users know that they are going to beusing their email again and so they leave a message there to act as a reminder. Contextualinformation is also far too important to most users, so they will not extract it from theoriginal context.

The fact that retrieving is done using “associative reminding based on social and temporalcues” is also highlighted in Bellotti et al. (2005) and Whittaker, Jones, Nardi, Creech,Terveen, Isaacs and Hainsworth (2004). Normally, within email this is the sender, recipientor the date. Retrieval can also be done through sorting via one field and then triangulatingpossible results using another. For example, date and sender. Context can also be animportant cue; the salient cue might be a keyword for a topic.

The simplicity of the data extraction approach can be compromised by the need of the userfor context. For example, users may want to relocate the message in its entirety (or eventhe entire thread) rather than using the file system. Whittaker et al. (2006) comes to theconclusion that a combination of both approaches is required to improve dedicated supportfor PIM.

Task Management

Email is used for task management in a variety of ways by the user. A very commonapproach by the user is to leave messages and information in the inbox so that when theinbox is re-opened the information is seen again when a quick scan of the inbox takes place.This technique is also extended by the ability to be able to send messages to yourself toact as reminders of useful information.

Personal Archiving

Email is also important for information storage, although it is also problematic. Firstly,the archiving can be done using folders and manual classification so that everything isavailable later. However, to be able to do this users need to be able to predict future usagecontexts. This is cognitively difficult and can lead to the folders being inconsistent andusers forgetting about the entire folder - or just as problematic, forgetting the context of


each folder. For example, a folder might end up with many different types of messages orthere might be many different folders with similar messages in each.

Segal and Kephart (1999) put forward a solution of using software to derive folders andmake recommendations using learning techniques. The testing of this solution showed thatthis approach was effective, but only if folders had already been created. The softwarecould not create folders for you as it had no way of knowing the context in which youwanted to organise the folders.

Searching and sorting is also proposed as a solution for personal archiving. The techniqueworks well for users to find information if they can remember partial information such asthe sender or the date, but this is an indirect approach (Dumais et al., 2003). GoogleDesktop is seen as an improved PIM tool as it is able to reduce fragmentation by searchingboth email and the file system of a machine. However, this does not help the fact thatdefining a search query is as difficult as classifying information into folders. Although thenewer desktop search tools can be seen as an improvement in information retrieval, theylead to increased inbox clutter and as a result will reduce task management abilities.

Email can also be useful to look at as a lot can be learned from previous literature. However,it is treated slightly different from some other PIM items because it directly affects others- it is a messaging system on which other people might be relying on for a response. Thereis also the fact that emails can lack context as lots of personal information is self generatedand received emails are not which can make them harder to react appropriately to. It isalso key to note that email generally requires constant processing, otherwise the user maycause delays for others if they do not reply - a backlog may build up that will start todemand personal attention.

2.1.5 PIM Potential

There is a view of looking at PIM such that the pace of improvements in various technologiessuggest that certain earlier ideals of PIM may be realised in the near future (Jones, 2007).

It could be argued that you could just keep a record of everything that has been encoun-tered, including non-conventional information such as photographs and full motion film.Using this view, better search support would be require in order to be able to correctlypinpoint information. The fact that data storage is increasing in capacity whilst decreas-ing in size helps the ubiquity of computing make it possible to take information with uswherever we go and stay connected to a much larger world of information.

However, it has been shown that technology and tool developments with the potential forimprovements can create new problems and can even exacerbate old problems. Whilst thenew tools can provide targeted help, they can still end up further complicating informationmanagement. It is clear that information that was once only available in paper format isnow available in multiple digital formats. The digital information itself further scattersinto information islands.


Now that PIM problems and some of the current strategies to address these problemshave been investigated, the literature survey will now look at how much sorting of theinformation will be required by the machine in order to develop the most efficient retrievaltechnique.

2.2 Function Allocation

In the previous section it was determined that there is a clear relationship between thecontrol the user has over their environment and the control they therefore have over theirpersonal information. This part of the literature survey will investigate how much of thesorting of information the system should do and how much the user should do manually.

Over 30 years ago, major reviews were conducted into the use of the human operator inprocess control. However, these reviews considered the manual control of large complexsystems and contained many hundreds of references to the role of the human operator.Due to the advancement of automation, this relation of humans and machines needs to bere-examined.

Automation is considered to be present when a function is performed by a machine thatcould have been performed by a human and is used to make systems more efficient.

The role of human operators is a great concern, as frequently system failures are blamedon “human error” rather than hardware faults. A simplistic approach would be that it isimportant to try and ’design out’ human operators and therefore reduce the possibility ofhuman error and increase productivity, removing the need to retain humans in the system.

By looking at modern automisation it can be seen that this approach is not valid, bothresearch and industry practice emphasise human operator qualities rather than their weak-nesses. It has been shown that humans are needed firstly, as the last line of defence inhazardous operations and secondly to improve productivity.

Improvement of productivity is something that is relevant to the project and the area thatit will be focused on. It is somewhat surprising that humans can increase productivityas during automation, systems are designed to perform in a mathematically optimal way.However, it can be shown that often the combination of humans and machines can exceedthe performance of mathematically optimised machines - this combination is more powerfulthan either entity alone.

A point that should be noted, is that even if a fully automated system was created, it wouldnot remove the opportunity for human error and only change the area in which human errorcould be introduced. An increased burden would be placed on the system designer, whowould have to predict every possible failure state and design the automated system to beable to cope with all of them.

According to Bainbridge (1983), at any stage of development there is a limit to whatengineers can automate. He pointed out that with increasing automation, the operators


role becomes increasing difficult because the functions that are not automated are thosethat were too difficult to implement.

From 1950 until 1980, the design of human-machine systems were dominated by the ’MenAre Best At - Humans Are Best At’ approach. From an ergonomic viewpoint, the theoryof design was following task analysis - that characteristics of humans and machines shouldbe reviewed to see which can perform better. Chapanis, Frick, Garner, Gebhard, Grether,Henneman, Kappauf, Newman and Williams (1951) and Hancock P.A. (1998) generated’Fitts Lists’; comparative lists of abilities where allocation of function could be made on arational basis.

However, it would appear that these lists are no longer appropriate - if sufficient moneyis available then any human ability can be at least approximated. Sensing and actionscan be mimicked electronically, with perception increasingly being emulated and complexdecisions being mimicked by expert systems.

Today’s preferred approach appears to be the emphasis on the co-operation of human andmachine, combining their capabilities. The current problem is to decide how to realise sucha combination.

2.2.1 Levels of Automation

The following table shows several levels and modes in which humans and automation mightwork together.

This scale has been extended by Parasuraman, Sheridan and Wickens (2000), who pointedout that it can be applied to data acquisition, decision making and the choice of actionseparately. For example, data acquisition might be performed at level 8 whilst decisionmaking at level 2 and control at level 9.

It can clearly be seen that different systems require different levels of human-machine co-operation. There will be a heavy mental load for the human at low levels and massivecomputation within a system with a high level of automation - this could be a factor toconsider when deciding on automation on a mobile platform. The middle of the scale con-tains the opportunities for genuine co-operation, where there are information processingabilities from both sides that are used for mutual benefit. However, there is a price topay. Both the computer and the human must now communicate and interpret informationthat is received from the other as well as processing information gathered from the systemenvironment. This may mean that the result of automation and the communication over-head is a heavier workload. Wiener E.L (1980) and Bainbridge (1983) talk about ’clumseyautomation’ which is a well known problem in this area. One of their examples is thatof automation on an aircraft. Useful on long-haul flights as not much happens, howeversevere overload can occur during approach and landing due to the need to reprogram theautomation rapidly. Also there is the difficulty in understanding what the automation isintending to do at a time when the pilot workload is at its highest. Many crashes haveoccurred when automation has adapted itself but not signalled clearly to the human what


Table 2.1: Sheridan-Verplank scale of human-machine function allocation in automatedsystems1 The human does the whole job of planning, selecting options, and preparing the

machine, up to the point of switching on the machine to carry out the actions2 The human does everything except to ask the computer to help in suggesting possible

options3 Computer helps to select possible options and suggests to the human one that may

be the best4 Computer selects a course of action, and it is up to the human to decide whether or

not to do it5 Computer selects the action and carries it out if the human approves

6 Computer selects the action and tells the human in plenty of time for the human tostop it if the human disapproves

7 Computer does the whole job but necessarily tells the human what it has done

8 Computer does the whole job and tells the human what it has done if it, the computerdecides that the human should know

9 Computer does the whole job and tells the human only if the human asks what isgoing on

10 The computer does everything, including deciding whether to do it, and decidingwhether or not to tell the human

state it was in.

The need for clear feedback is vital, not only is there visual feedback but auditory, kines-thetic and tactile. Without feedback in highly automated systems operators may feel thatthey are controlling the interface rather than the underlying system.

2.2.2 Design of Displays

There is an important distinction between data and information, data simply being the rawnumbers of the system and information the meaningful combination of data that indicatessystem state with minimal mental calculation and manipulation of the data. Bennett K.B.(1992) showed how the design of a simple system can change the balance between data andinformation. An important distinction is made between values that are shown explicitlyand those that must be deduced or calculated by the observer.

Problems will arise if there is a large amount of variables displayed in the form of raw data.There will also be problems if high order encodings of data are presented as information,the meaning of the system will become incomprehensible to humans.


The same article (Bennett K.B., 1992) suggested approaches to finding displays that providedirect perception of relations among the variables rather than leaving the discovery to theoperator. They considered how to represent both the values of variable and the relationsamong them.

2.2.3 Conclusion

Given that a fully automated system is frequently not an option, it is therefore absolutelyessential that human operators are provided with a cohesive set of tasks, and are able tomaintain a high degree of situational awareness, (Cook C., 2001). This is an importantpoint when considering development of a mobile PIM system as items such as appointmentsare time sensitive. Users need to be aware of the next appointment coming up or thedependencies between various appointments.

The process of function allocation has become more critical within system design. Allowingeverything that can be automated to be automated and the operator given the remainingfunctions to perform manually will inevitably result in system failure. Only by carryingout considered allocation of function can the automation boundary be optimised.

2.3 Internet Information vs Personal Information Retrieval

There have been many developments in web access relatively recently where by searchsystems like Google completely dominate information retrieval when compared to servicessuch as Yahoo categories (Kobayashi and Takeda, 2000).

A user retrieving information from the Internet may take a completely different approachwhen compared to retrieving personal information. This is because personal informationhas been acquired by the user, unlike general information on the Internet which has usuallybeen acquired by someone else.

Web navigation is different from folder navigation as users do not create and organisethe information. Users are less familiar with the information than their own personal filestructures, and tend to become more familiar with a link trail as they repeatedly use it.(Bergman et al., 2008)

2.4 Personal Information Retrieval

It is important to remember that the main reason for PIM is to make a persons personalinformation items available for retrieval later. Generally there are two main ways in whichitems are retrieved, either searching or navigating.

Within the ACM Transactions on Information Systems 2008 there is the publication of apaper that evaluated a study by Bergman et al. (2008) that is now described and evaluated


why the conclusions and future directions of the paper will be important to the researchfor this project.

The paper tested whether recent improvements in desktop search have changed the fun-damental aspect of Personal Information Management. Bergman et al. (2008) tested bycarrying out two studies using modern desktop search applications.

2.4.1 Hierarchical Method (Navigation)

Navigating is a process that involves users traversing the organisational hierarchy until thelocation that contains the desired item is found. Next the user will have to find the itemwithin the directory / folder by sorting the items.

The nature of navigation means that (unlike search) hierarchical storage is required inwhich users are required to create their own directories to store the information items -there is required preparation for future retrieval.

Hierarchical storage was first introduced to actual users in the 1960’s with the Multicsoperating system before being included in the Unix operating system. In 1981 the XeroxStar introduced digital folders that were (and still are) a visual metaphor for location,(Bergman et al., 2008). These folders could also be manipulated in ways that resembledreal life with the ability to drag and drop. This helped to make the location metaphor evenclearer as users could see items inside folders.

Location-based storage to this day is still used almost exclusively (Microsoft, Unix, Linuxand Apple) without significant modifications.

However the hierarchical method is not without some disadvantages.

Kidd (1994), Malone (1983) and Whittaker and Sidner (1996) illustrate how informationcan be hidden from the user due to its classification, and therefore reduce the chances ofquick retrieval or reminding.

(Dumais et al., 2003), (Malone, 1983), (Whittaker and Hirschberg, 2001) and (Whittakerand Sidner, 1996) show that users may find categorisation challenging and therefore hardto categorise information that could be stored in more than one category. This is becauseat retrieval time users need to remember how the information was initially categorised(Lansdale, 1988).

As seen in the email section above Whittaker and Sidner (1996) showed how faced withmany categories users found it difficult to choose a location to store the email and weremore likely to create new and soon to be unused folders.

Due to these problems with navigation there has been much PIM research into search as amethod of retrieval.


2.4.2 Search Method

Search is a process where users generate a query that specifies a property of the desireditem that includes at least one word of the name of the information item. (Or at least oneword of the document if a full-text search is being used). After the query is executed a setof results is returned in which the user must choose the relevant item.

Looking at the disadvantages of the navigation method it would appear that search hasadvantages such as being more flexible and efficient at retrieval. Lansdale (1988) explainshow users only need to supply any attribute they can remember into their search queryinstead of remembering the correct storage location. Also information can be retrieved viaone query rather than potentially many operations to navigate to the correct location.

A main advantage of search over navigation would be because of the way that search worksit removes the need for organisation by the user of the hierarchy structure as they will notneed to anticipate future retrievals.

Even though search would appear to better suit users needs (Lansdale, 1988), Fertig, Free-man and Gelernter (1996) states that even though there are advantages with search, nav-igation is still preferred over search due to the limitations in search technology, and thatwith improvements navigation would be replaced by search.

The problems listed by Bergman et al. (2008) of search engines could be summarised as:

• Being too slow

• Being too difficult

• Only operating on file names

Search Improvements

However since (Fertig et al., 1996) the following improvements and features have been addedto many desktop search engines. Bergman et al. (2008) describes many of the improvementswhich are listed below:

• Cross-format search

• Faster retrieval

• User-centered design

• Incremental Search


2.4.3 Predictions and Findings From the Search and Navigation Study

The predictions of the evaluation were:

• Based on Lansdale (1988) and Fertig et al. (1996). Search is more efficient and flexiblefor retrieval and therefore the relatively recent improvements in search should leadto a “substantial increase in file search and eventually a preference for search overnavigation”

• Based on Kidd (1994) users are known to have problems organising files effectivelyfor retrieval. Search allows retrieval without manual organisation therefore “searchshould lead to a reduced use of filing strategies in preparation for later retrieval”.

The main results from the evaluation suggest that the recent improvements in search enginesdo not seem to affect retrieval and storage. This is shown to dis-prove Fertig et al.’s (1996)theory on retrieval that the “prevalence of improved search engines” would lead to morepreference for search over navigation. Lansdale’s (1988) suggestion that there would be areduced reliance on folders was also shown to not be true.

(Bergman et al., 2008) results show a strong overall preference for navigation. Users inthe study estimated that they used navigation for a 56% - 68% majority of their retrievalevents. While the average estimated search percentages were between 4-7% and 11-15%depending what search engine was used. As noted by Bergman et al. (2008) these figuresconfirm previous observations from Barreau and Nardi (1995).

The findings note that “it is clear that the use of improved search engines did not challengenavigation preference”. This is consistent with what was noted earlier from Dumais et al.(2003).

The findings were also compared to results from Barreau and Nardi (1995) who also foundthat search use seemed to be rather infrequent and only used when a file location wasforgotten. Barreau and Nardi (1995) described search as a “last resort” and this wasbacked up by the fact that 73-82% of people in the Bergman et al. (2008) study stated thatthey used search when they did not know where their files were located. Between 83-97%of the time search was used it was only as a last resort. Only between 0-3% of the time wassearch used when the location of the file was known. It was also shown that when usersdidn’t know the file location they still preferred not to search for them, but use navigation.

Only 2% of the study said that using newer / improved search engines meant that theywere less organised and able to use fewer folders - this was used to indicate that improvedsearch engines did not lead to less reliance on hierarchical storage.

2.4.4 Possible Explanations for the Search and Navigation Study Results

As one of the predictions of the Bergman et al. (2008) study was based on Fertig et al.’s(1996) observation that search would be the preferred method if the search engine technol-


ogy could be improved it could be argued that the search engines are still not sophisticatedenough. However, as Fertig et al.’s (1996) observation was made 12 years before Bergmanet al.’s (2008) study and as seen previously search engines have indeed improved sinceFertig et al.’s (1996) observation, having many new features as listed above.

Bergman et al. (2008) quoting Shneiderman (1997) explain that a possible reason for thesuccess of the hierarchical method is the fact that it is “boringly consistent” as files arestored in locations that do not move unless chosen to by the user. Shneiderman (1997) seesconsistency as being key, as a consistent human computer interaction that confirms userexpectations. Even though navigating to a file can take more steps than searching usersconsistently take the same steps. Bergman et al. (2008) argue that search’s benefit of beingflexible may well compromise its consistency because not only are different terms are ableto be used to retrieve the same file, the same term may produce a different list or a list ina different order of results.

One of Bergman et al.’s (2008) main points for why there appears to be a greater preferencefor navigation as apposed to search is that navigation is based on recognition and search isbased on recall. Tulving E. (1973) states that cognitively less effort is required to recognisethan to recall, as searching users are required to generate a set of terms (recall of filename orattributes) which can be challenging. While navigating however, the user goes down eachlevel of the hierarchy and is provided with visual and contextual feedback (recognition)about the navigations success as well as gaining clues to the next choice of folder (Teevan,Alvarado, Ackerman and Karger, 2004).

It can be seen that search and navigation differ in how information for retrieval is provided- all-at-once or over the course of an interaction where incremental feedback is received.

Bergman et al. (2008) also highlight how different types of memory are used to searchor navigate. Searching with a specific term requires the need to know that a certainword appears in a file, this requires declarative memory. While navigation uses proceduralmemory to be able to know how to navigate to the file. Barreau and Nardi (1995) suggeststhat as well having a visual recognition of a files location, users may also “retain a motormemory”.

Navigation may also be preferred as users are browsing in a self-created, familiar, constantenvironment. This could mean that less cognitive attention is required and the process maybecome automated. Bergman et al. (2008) even go as far as saying that when navigatingusers do not need to take their mind off the work that they are doing to be able to retrievethe file, and therefore the assumption that time is lost navigating compared to searchingmay not actually be the case because time is saved as the user can continue to think of theproject they are working on at the time.


2.4.5 Conclusions and Future Directions from the Search and NavigationStudy

The main conclusion from the study shows that for personal information retrieval there ispreference for navigation over search even when using modern, improved search engines.The report does however state that search is the “PIM fire escape” and is still importantwhen users cannot remember where their file is located.

Due to the main conclusion of the paper and the implication that there is a strong relationbetween user memory for file location and the use of search, it is observed that there is aneed to develop more sophisticated models of the “relation among navigation, search andretrieval” including how metadata manipulation can possibly influence retrieval.

A (user-subjective) design approach (2.6) developed by Bergman, Beyth-Marom and Nach-mias (2003) specifically for PIM systems, has design schemes to assist navigation. Insteadof attempting to replace the hierarchical method the approach takes advantage of the factthat in PIM the user trying to retrieve the information is the same user who stored theinformation. Therefore it suggests that to be able to help with future retrieval PIM systemsshould use user specific (subjective) attributes that were associated with the informationduring the “user-information interaction”.

This suggestion could also be a potential solution to the problem that Kidd (1994), Malone(1983) and Whittaker and Sidner (1996) identified - that the act of categorisation is itselfcognitively challenging as users find it hard to categorise information that could be storedin more than one category.

2.5 The Strength of the Location Metaphor

Files within an operating system are not really within folders - location is a metaphor forfile organisation. Bergman et al. (2008) references a conversation about Lakoff G. (1980)which suggested that location does not have to be the best possible metaphor.

Cutrell, Dumais and Teevan (2006) and Jones, Phuwanartnurak, Gill and Bruce (2005)both state that folder organisation serves as a useful way to conceptualize information evenif it is not useful for retrieval.

The reason the metaphor works so well is because it seems natural to the user. Bergmanet al. (2008) even refers to Piaget (1928) in stating how from an early age children storeitems in physical locations and expect to find them when required. This is why themetaphor works, regardless of the retrieval options users like to know where their informa-tion is stored.

Jones et al. (2005) states that where PIM is concerned user’s folders “represent an emerg-ing understanding of the information within”. This understanding should become greatereverytime that a user navigates to that information.


2.6 User-Subjective Approach to PIM System Design

Bergman et al.’s (2003) new approach to PIM system design advocates that PIM systemsrelate to the subject value-added attribute that the user gives to the data stored in the PIMsystem. The attributes should facilitate system use to help the user find the informationagain, recall it when needed and be able to use it efficiently in the next interaction.

Bergman et al. (2003) has derived 3 principles from the user-subjective approach:

1. Subjective Classification: All information items related to the same subjective topicshould be classified together regardless of their technological format.

2. Subjective Importance: The subjective importance of information should determineits degree of visual salience and accessibility.

3. Subjective Context: Information should be retrieved and viewed by the user in thesame context it was previously used.

For the third principle Bergman et al. (2003) references A.D. (1982) and Tulving E. (1973)to state that information items are “better recalled when stored in context that it waslearned”.

2.6.1 Reasons for the User-Subjective Approach

Bergman et al. (2003) explains how there are many current PIM limitations:

Often PIM systems fail to decrease the load on memory and facilitate retrieval. This canbe due to the fact that users have difficulty remembering where (physical or computer) fileshave been placed.

The author also refers to many studies that show how PIM system procedures are notused. For example the correct procedure would not be to have you work pile high (bothphysically and in an email inbox) yet this occurs for many people. In many cases it wouldalso not be the correct procedure to be sending emails to yourself.

Bergman et al. (2003) states how it is difficult keeping found things found in PIM because,unlike General Information Management (GIM), GIM relies on general attributes that areadded to make retrieval more useful and has information professionals such as librarians orwebsite designers who add objective (and general) attributes that cater for different needs ofpeople who vary in the context they want to use the information. However PIM serves onlyone user and therefore should make use of subjective attributes given to the informationby the user while iterating with it. The attributes will be “episodic and idiosyncratic” innature and can be meaningless to others - however that will not matter as the informationis “personal”.


The approach “clearly needs to be subjective” because unlike GIM, acquiring, organising,storing as well as retrieving, recalling and reusing the information will be done by the sameperson.

2.7 Current File Managers

As the project will be assisting file retrieval on a mobile device it is important to look atalready successful File Managers (also known as File Browsers) and their common traits.

All the file managers examined in this section provide a graphical user interface (using thelocation metaphor, 2.5) to work with the underlying file system. The examples also displaythe files and folders in a hierarchy and are known as ’Navigational File Managers’ as anavigational metaphor is used to represent file-system location.

All Navigational File Managers have a display of the location currently being viewed. Thislocation can be manipulated by the user, for example another folder can be opened whichwould change the current location that is being viewed (and generally does not open a newinstance of the file manager). Files and folders are represented by icons or text.

2.7.1 Windows Explorer

As well as the features listed above for Navigational File Mangers it is also worth notingthat Windows Explorer is able to be extended to support non-default functionality. Alsonotice the folder icons which represent directories. See figure 2.1(a).

2.7.2 Mac OS X Finder

An interesting feature of Finder is the “Columns” view (see 2.1(b)), which is an implemen-tation of the Miller Columns visualization technique. The Miller Columns allow multiplelevels of the hierarchy to be open at once, and provide a visual representation of the currentlocation.

2.7.3 iPod Browsing

Another example of an implementation of Miller Columns is on the iPod. The iPod is amobile device with a relatively small screen. Navigating the audio id3 tags on an iPod isextremely like column browsing, however due to the screen size only one column is visibleat a time. However there are 2 dedicated buttons which take the user up or down a levelin the hierarchy. See figure 2.1(c)


(a) Windows XP file manager - Windows Explorer

(b) Mac OS X file manager - Finder (c) iPod browsing mechanism

Figure 2.1: Navigational File Managers

2.8 Conclusion

This chapter has reviewed the main issues relating to personal information managementand issues relating to PIM in a mobile context. This is in preparation for the next chapterthat involves deriving requirements for a new PIM system that should make use of subjec-tive attributes for retrieval of information. The literature review has involved looking atwhere PIM has come from, the current problems such as categorisation when storing theinformation and retrieval method when items need to be used again.


The literature survey has shown that within PIM there are some really important ideas.These ideas include that:

• The value of information is not absolute but relevant to the appropriate context suchas the sender of a message.

• PIM activities frequently occur at anytime and anywhere.

• When users try to manage their personal information outside of a static environment(such as an office) they will have less control over the environment and therefore lesscontrol over how their information is managed. This can be a result of using statichierarchical directory structures.

• Static directory hierarchy’s also cause a mis-match between current information or-ganisation and what is required to naturally support services.

• There is a relationship between the salience of cues and the the quantity of informa-tion. As higher quantities make it harder to look for an individual item. HoweverPIM by its very nature will involve many thousands of items.

• That two strategies to try and deal with PIM retrieval problems have their own issues.Centralisation (decreasing salience) and data extraction (lack of context for retrieval).

• Lots of task management software is unused because it requires items to be consciouslyremembered to be retrieved. This is due to the fact that retrieving is done throughsocial and temporal remindings.

• The level of organisation of information needs to be split carefully between machineand human as if not calculated correctly there will be too much work for the user tobe able to determine which item is correct for retrieval, or the user will not be ableto find what they are looking for at all.

The key ideas (which are not independent of the list above) will be taken forward into thenext chapter with the highest priority for the new system:

• Personal information is personal and has been acquired by the user. This informationwill only serve one user and should therefore make use of the available subjectiveattributes.

• There are problems when folders are used for storage. Most notably the categorisationfor the content of the the folder. Users can find it difficult to choose the appropriatefolder to store the information item. As well as finding it difficult to create the folderinitially. Users do not want to lose control over the environment.

• Even though there are categorisation issues navigation of folders is still overwhelm-ingly preferred to search where personal information is concerned.


• The location metaphor is entirely metaphoric. Location is not a location at all, buta convienent way of organising information because users like to know where theirinformation is stored. In the same way that it seems natural to the user to storeitems in physical locations.

These ideas together with the 3 user subjective design principles for PIM systems (section2.6) illustrate that it is necessary to design a PIM system that is able to organise allpersonal information items together that are related by the same subjective topic. Thesystem would also need the ability to retrieve information items using the same contextthey were last used in. This should be implemented using dynamic directory structuresthat adapt to the context type (e.g. time or physical location) that the user wants to useto try and retrieve the item.

This literature review will now be used in the requirements chapter to assist in documentingthe process of gathering and defining the requirements that will enable design processes tobegin.

Chapter 3

Requirements

The literature review conducted in the previous chapter, considered an overview of theconcepts and processes relevant to personal information management, more specificallyinformation retrieval and the mobile capacity for PIM.

It was determined that a PIM system should be designed that would create a user-subjectivepersonal information manager. This system should not only classify information itemsbased on the subjective topic but also allow the user to be able to retrieve items in thesame context in which they were last used. In order preserve control over the environmentand the way that information is managed - which can occur when static directory structuresare used, it was recommended that dynamic directory structures should be implementedthat are able to adapt to the context type the user would like to use as a salient cue toretrieve the item.

In this chapter, the literature gathered is used to document the process of gathering anddefining the requirements for the system. It is essential to the project that there are clearrequirements which provide focus for the work to be completed. It is also important to findout about the users, their processes and the context that the processes will be carried outin.

3.1 Requirements Analysis

The project will need to produce its own requirements mainly as there are no predefinedinitial requirements from a customer. This does not mean that the users’ needs and expec-tations are any less of a priority in the requirements. The requirements will be discussedand probably refined by gaining an understanding of the users, their capabilities, theirtasks, the conditions that the tasks will be completed and the constraints that will be onthe systems performance.

Interaction design is naturally iterative, (Preece, 2002). Therefore it would not be sensibleto keep separate the activities of the requirements, design and evaluation as they are inter-

25

CHAPTER 3. REQUIREMENTS 26

twined. This project will have its design and requirements generated through an evolutionof evaluation and redesign. A user-centered approach will be taken to try to avoid gettingthe requirements of the project application wrong. Hopefully creating a system that hastaken into account users’ needs and expectations.

3.1.1 Objectives

The requirements will originate from the overall goal that guides the whole project: toinvestigate the techniques for robust management and retrieval of personal information ona mobile platform.

Using this objective a literature survey was conducted to investigate the scope of theproject. During the initial literature investigation the scope of the project was re-defined.The project was then focused on the organisation and retrieval of personal informationmanagement and should produce a user subjective PIM system that aims to remove cate-gorisation problems associated with folders as well as using a dynamic folder structure toenable the navigation of folders by different subjective contexts.

3.1.2 Data Gathering

To create stable requirements appropriate data must be collected. As there were no initialrequirements it was especially important to get the scope of the project correct. The datagathering will find out about how people currently interact with PIM systems, their goalswhen using them, the context they are in when performing tasks, and the rationale for theway things currently take place.

After the literature review was completed there was also the use of a questionnaire.

Literature Review

The literature review produced some good ideas which were analysed and refined into keyconcepts that should be used create a new PIM system, (see section 2.8). The main findingof the literature review was that it is necessary to design a PIM system that is able toorganise all personal information items together that are related by the same subjectivetopic.

The system would also need the ability to retrieve information items using the same contextthey were last used in. By implementing these concepts using dynamic directory structuresit would allow the user to choose which context type (e.g. time or physical location) to useto retrieve information items.

When the literature review was completed it provided a good base for the creation of a setof initial requirements. The initial requirements were conceptualised from Bergman et al.’s(2008) findings that users prefer to navigate to retrieval their personal information items.


Bergman et al. (2008) also concluded that there should be more research in the navigationarea of retrieval - search technology has seen massive improvements over the last decadeand used almost exclusively when retrieving general information from the Internet, but itis not chosen for use when personal information is concerned.

Another key paper that delivered the foundation for the initial requirements was Bergmanet al.’s (2003) paper describing a new approach to PIM system design: a user-subjectiveapproach.

Questionnaire

A series of questions were designed to elicit information about users and their personalinformation organisation and retrieval. 50 questionnaires were distributed via email andfacebook (the social networking website) messages that contained a link to the Universityof Bath’s hosting space.

Depending on the choice made (the possible answers were in the form of a link) the userwas redirected to the appropriate survey at www.polldaddy.com. Out of the 50 links sentthere were 36 completed responses, and 2 incomplete responses that were disregarded.

Making full use of the features of the polling site the questionnaires had a dynamic structurethat could change what future questions appeared depending on previous answers. Forexample if the user did not take photos or edit documents on their mobile device they werenot asked questions relating to how they stored or retrieved these items.

It was important that the questionnaires had questions that were easy to understand andunambiguous. No demographic information such as age, sex or location was asked for as itwas considered unnecessary for the needs of the questionnaire.

Questions were focused on collecting specific user data with regards to their interaction withthe organisation and retrieval of their personal data. The questionnaires were reviewed andusers with appropriate answers and had indicated were available for prototyping had theirdetails noted.

3.1.3 Questionnaire Analysis

The questionnaire had 3 main sections that illustrated what it was trying to find out - howusers organise their personal information, how users retrieve their personal information andhow a mobile device is used to organise and retrieve their personal information.

Organisation (using a desktop machine)

1. Do you keep your personal information files (photos, documents, lists etc) in. . .a) Just one or two main folders


b) Multiple folders and / or sub folders

File Organisation StatusNo folders 11Multiple Folders 23Total 34

Figure 3.1: Requirements Questionnaire - File Organisation Question 1

Question 1 Discussion

The purpose of the first question was to be able to get a broad estimate of thenumber of users who actively organise their personal files by arranging them intomultiple folders. This question was a branching point for the users questionnaires,the answer to the question would determine what the next question could ask aboutthe users motivation for file organisation.

2. Why do you not keep your information items organised in folders?a) I don’t need to, I can always find what I need laterb) I would like to but I don’t have time to re-organise everythingc) I did organise everything once, but over time the categories have become inappro-priated) I find it hard to categorise my information, I feel items belong in more than onecategorye) I find it hard to categorise my information, I am scared that I will not be able tofind the information again


The second question was only asked if users stated that they did not have theirpersonal information organised into multiple folders. The responses of question 1and 2 combined show that only 1/34 (3%) saw no need for organising their personalinformation using the file location metaphor. While half the users that don’t organisetheir personal information find it difficult to choose the categories. The other halfwho currently have no file organisation did initially attempt to organise their personal


File Organisation Reason For No MotivationNo Need 1No Time 0Digressed Over Time 5Hard to Categorise - Multiple Categories 1Hard to Categorise - Fear of Losing information 4Total 11


information, but over time their choice of categorisation became redundant / nolonger maintained. Question 1 and 2 combined illustrate that 97% of users requiresome sort of organisation for their personal information even if they don’t currentlyuse any folder organisation.

3. How are these folders arranged?a) By the type of file, e.g. a pictures folder, a documents folder, etcb) The subject of the file e.g. a work folder a social folderc) The time time period in which the information was acquired / created? e.g. “Lastyear’s stuff”d) In another way / combination:

4. When are these folders created?a) When there are so many items in one folder I have to create a new one because itbecomes difficult to find thingsb) Every now and then I have a sort outc) I create new folders as and when I need them e.g. when saving an item an appro-priate folder will be created if there is nothing suitabled) I have tried to create folder categories for all my items

Question 3 and 4 Discussion

The third and fourth questions were asked to users who indicated that they did


File Organisation CategorisationType 5Subject 5Time 5Other 8Total 23

File Organisation Folder Driving ForceExisting folders become difficult to navigate 2Periodic organising 8Created as needed 10Created for all possibilities 3Total 23

Figure 3.3: Requirements Questionnaire - File Organisation Question 3 and 4

participate in at least a minimal amount of organisation of their personal information.Interestingly there was an even split of users that organised their information itemsby type, time and subject (all 22%). Of the 35% who responded “other” the majorityof the responses were a combination of 2 or more of time, type or subject. Anexample was “uni stuff” - “2008” - “photos”. One respondent interestingly saidthat their personal information was organised depending on whether they needed todo anything to the information or not, for example folders where called “unfinisheddocuments”, or “to-sort photos”.


Regarding the creation of the folders it would appear to be the case that users createnew folders when the previous setup became too much for them to handle or theyperceived that their performance was going to decrease if they did not re-organise assoon as possible.

Retrieval (using a desktop machine)

5. If you wanted to retrieve / open a document that you created in the past. . .a) I would look on the desktop / “My Documents” folderb) I would open the desktop / “My Documents” folder and then look for the nextappropriate folderc) Use a search tool and search for the document

File Retrieval Primary MethodSingle Folder 9Sub Folders 20Search Mechanism 5Total 34



The first retrieval question shows a correlation with Bergman et al.’s (2008) findingsthat the majority of users prefer to navigate to find their personal information insteadof searching. In this sample only 15% indicated that they would initially turn to asearch tool for retrieval. This matches Bergman et al. (2008) who found that the useof Google Desktop was 11-15% and the use of Windows search was 4-7%.

6. For personal photos could you tell me. . .a) Roughly WHERE they were taken?. . . yes. . . nob) Roughly WHEN they were taken?. . . yes. . . no


7. For documents that you have created / edited could you tell me. . .a) Roughly WHERE the document was edited?. . . yes. . . nob) Roughly WHEN the document was edited?. . . yes. . . no

File Retrieval Photo ContextKnown Location Context

Yes 30No 4

Known Time ContextYes 27No 7Total 34

File Retrieval Document ContextKnown Location Context

Yes 28No 6

Known Time ContextYes 31No 3Total 34

Figure 3.5: Requirements Questionnaire - File Organisation Question 6 and 7

Question 6 and 7 Discussion

Both question 6 and 7 clearly show that users can remember the context in whichthey acquired or created their documents and photos. Location was slightly morememorable within photos and time more memorable for documents.

Mobile information organisation and retrieval

8. Do you own a mobile device?a) Yes b) No

Unsurprisingly 100% of users (34/34) sampled own a mobile device.

9. What do you use you mobile device for?a) Just for social communicationb) Just for work communication


c) Social communication and to organise e.g. Calender, pictures, other files such asdocumentsd) Work communication and to organise e.g. Calender, pictures, other files such asdocumentse) Both reasons c and d

Mobile UsageSocial Communication 2Work Communication 9Social Communication and Organisation 3Work Communication and Organisation 5Communication and Organisation for Social and Work 15Total 34



Question 9 illustrates how mobile devices are used for organisation of multiple itemsas well as communication by over two thirds (68%) of the sample. Which impliesthat there is a need to investigate methods for organisation of personal informationon mobile devices.

10. What are the top 4 types of personal information that you use on your mobile device?a) Photosb) Messagesc) Documentsd) Calender entriese) To-Do listsf) Videosg) Notesh) Musici) Meetings / appointment reminders


Mobile Information UsagePhotos 25Messages 30Documents 3Calender Entries 9To-Do Lists 9Videos 5Notes 24Music 19Meetings / Appointments 12Total 34 * 4 = 136



Photos, messages, notes and music are the top 4 information items used on mobiledevices out of the 9 listed. Any mobile PIM system to organise and help retrievalshould work on these data items.

11. (Excluding Music items) Are the items on you mobile device organised in any otherway other than file type? E.g. Is there any other organisation than photos in a photosfolder, videos in a videos folder, notes in a note folder etca) Nob) Yes. How are they organised?. . .


Almost two thirds (65%) stated that there was no organisation of the personal infor-mation on their mobile devices other than categorisation by type. Of the 35% whostated there were other forms of organisation on their mobile device the majoritylisted the ability to list messages by sender or time.

There was also a response stating that when transferring pictures from a mobile deviceon to a desktop machine the pictures were (on the desktop machine) stored in foldersorganised by month.

12. If you wanted to retrieve a text message, note, video, photo etc, would you do anythingdifferent than opening the folder/application that contains the text message, note,video, photo and scroll through the items until you found what you were looking for?a) Nob) Yes. What would you do differently?


Mobile OrganisationNo 22Yes 12Total 34


Mobile Organisation ProcessNo 21Yes 13Total 34



When retrieving personal information from a mobile device more than 6 out of 10users (62%) did nothing other than open the appropriate folder that was arranged bytype and then scroll through the items one by one until they reached the item theywanted to retrieve. From the responses that stated they did something differently,only one stated that photos were arranged by month and even then they had to scrollthrough in a manor that involved going through all the photos of that month one ata time until they found the required photo. The rest of the ’Yes’ responses cited the


fact that their mobile device allowed them to navigate through messages one-by-oneas described in the question, or use a ’thread’ or ’conversation’ function which allowedthen to find the sender of the message and then view all the messages that have takenplace between the two recipients.

3.2 Requirements Specification

The functional (what the system should do) and non functional (system properties andconstraints) requirements are specified in this section.

The requirements need to be clear and unambiguous, therefore the Volere process will beused to list the requirement definitions, Robertson and Robertson (1999). Each require-ment will have a unique identifiable number, a statement of intention (description), anexplanation as to why the requirement is necessary (rationale), an explanation of wherethe requirement was raised (source) and a priority.

Requirement priorities are important to illustrate what is key to the solution of PIM re-trieval problems. The different priorities also allow features to be distinguished to theextent that development time and effort can be distributed using the priorities as appro-priate constraints. The requirement priorities of the system will be numbered 1, 2 or 3.

• Priority 1 indicates the requirement is critical for the operation of the PIM system

• Priority 2 indicates that the system can operate without the requirement but thetasks associated with the requirement may not perform well

• Priority 3 indicates that the requirement would be nice to have but is not be essentialfor the operation of the new PIM system

Preece (2002) states as non-functional requirements cover such a broad range of require-ment types, non-functional requirements should be further decomposed. Therefore therequirements can be categoried as follows:

• Functional Requirements What the system should do.

• Data Requirements Capture the type, volatility, size/amount, persistence, accuracyand value of the amounts of the data required.

• Environmental Requirements Are the context of the use of the system. They refer tothe circumstances in which the interactive system is expected to operate (physical,social, organisational and technical environments)

• User Requirements Capture the characteristics of the intended user group.

• Usability Requirements Capture the usability goals and measures for the new system.


3.2.1 Functional Requirements

1. The system must only show personal information to its ownerRationale: Users do not need, and should not be able to view other peoples personalinformation. Not only for security reasons, but retrieval would become more difficultof the personal information if there is other information in the system that does notbelong to the user.Source: The definition of Personal Information Management (see section2.1)Priority: 1

2. The system must be able to acquire photosRationale: A camera is a key feature of modern mobile devices that is used day today by users as can be seen from the questionnaire results.Source: This was illustrated during the questionnaire analysis, (see section 3.1.3).The results from question 10 show a strong score for “Photos”.Priority: 2

3. The system must be able to acquire notesRationale: Notes are a basic but highly effective type of personal information thatare used in many different ways on a mobile device in much the same way they areused with paper and pen. “Notes” functionality is fundamental to a PIM system sothat users can use the Notes in any way they wish. E.G. as a reminder, or a quickmethod for taking down information etc.Source: This was illustrated during the questionnaire analysis, (see section 3.1.3).The results from question 10 show a strong score for “Notes”.Priority: 2

4. The system must be able to organise incoming sms messagesRationale: Text messaging is integral functionality for a mobile device - being themost used type of personal information in the questionnaire.Source: This was illustrated during the questionnaire analysis, (see section 3.1.3).The results from question 10 show a strong score for “Messages”.Priority: 2

5. The system must be able to assign time context to all acquired informationitemsRationale: Time has shown potential to be useful for context based retrieval, tosome extent users are already familiar with time to organise their files as indicatedby question 3 of the questionnaire.Source: Bergman et al.’s (2003) definition of a user-subjective PIM system design(see section 2.6) and the results from question 6 and 7 in the questionnaire analysis(see section 3.1.3) show that users are able to remember the time that photos anddocuments were created.Priority: 1


6. The system must be able to assign location context to all acquired infor-mation items apart from sms messagesRationale: The physical location of a user when they were acquiring their personalinformation has potential to be a great retrieval cue.Source: Tulving E. (1973) states that information items are better recalled whenstored in the context they were learned (see section 2.6). As well as the results fromquestion 6 and 7 of the data gathering questionnaire (see section 3.1.3) that showsusers are able to remember the location that photos and documents are created.Priority: 1

7. The system must be extensible for multiple platformsRationale: Even though implementing a multi-platform system is beyond the scopeof this project it would be sensible to build a system that has the potential to work onmany different platforms in the future. Especially as personal information is acquiredand retrieved from many different devices - even by the same person.Source: The nature of PIM means that personal information will be acquired inmany different places using different devices (see section 2.1.2)Priority: 3

8. The system must behave like a regular file hierarchy, folder navigationsystem that implements the location metaphorRationale: The location metaphor has been successfully used for all types of fileorganisation for many decades since the introduction of the Multics operating system.Source: The many reasons why the hierarchical methods have been successful (seesections 2.4.1 and 2.4.4), the strength of the location metaphor (see section 2.5) aswell as the findings from the data gathering questionnaire, questions 1 and 5, (seesection 3.1.3).Priority: 1

9. The system must be able to go backwards and forwards (up and down thehierarchy) when navigating for retrievalRationale: It is intuitive to be able to go up and down a folder hierarchy, will extendthe users experience as well as being familiar to the users from other file managementsoftware.Source: The description of the “Hierarchical Method” (see section 2.4.1) as well asthe properties of current navigation systems (see section 2.7)Priority: 2

10. The system must always tell the user where they are in the folder hierarchyas they are navigatingRationale: It is intuitive to be able to know where you are in the folder hierarchy,will extend the users experience as well as being familiar to the users from other filemanagement softwareSource: The description of the “Hierarchical Method” (see section 2.4.1) as well asthe properties of current navigation systems (see section 2.7) as well as the results


from the prototyping evaluation (see 4.1.1)Priority: 2

11. The system must implement the 3 principles from Bergman et al.’s (2003)user-subjective approach to PIM system designRationale: Bergman et al. (2008) suggests Bergman et al.’s (2003) user-subjectiveapproach as a possible way to improve personal information retrieval.Source: The reasons stated when reviewing Bergman et al. (2003) (see section 2.6)as well as the future directions from Bergman et al. (2008) (see section 2.4.5)Priority: 1

12. The system must allow the user to retrieve an item using time as a retrievalcue without needing to recall the exact time the item was acquiredRationale: When a user navigates they are recognising folder names - which iscognitively less effort than recalling, therefore exact time will not be required but theuser should be able to build a route to the information within their mind.Source: The possible reasons for why navigation is preferred over search for personalinformation (see section 2.4.4) and the results from question 6 and 7 of the datagathering questionnaire (see section 3.1.3) that show users can remember roughly thetime of acquisition of photos and documents.Priority: 1

13. The system must allow the user to retrieve an item using location as aretrieval cue without needing to recall the exact location the item wasacquiredRationale: When a user navigates they are recognising folder names - which iscognitively less effort than recalling, therefore exact time will not be required but theuser should be able to build a route to the information within their mind.Source: The possible reasons for why navigation is preferred over search for personalinformation (see section 2.4.4) and the results from question 6 and 7 of the datagathering questionnaire (see section 3.1.3) that show users can remember roughly thelocation of acquisition of photos and documents.Priority: 1

14. The system should allow the user to use multiple context information tobe able to retrieve their information itemsRationale: Given that the user will not have to remember exact details about certaincontexts and the fact that a lot of information may have been acquired in one locationit will improve retrieval to be able to use multiple contexts to retrieve informationitems.Source: The description of the “Hierarchical Method”, (see section 2.4.1)Priority: 2

15. The ’folders’ of the location metaphor must not exclude / hide any dataRationale: The folders containing further sub hierarchies and the information itemswill not actually contain the physical representation of the information, but will


appear to in the form of links. The folders will be generated dynamically each timethe user tries to navigate, therefore together the folders will contain all informationitems that the user has acquired.Source: The description of the “Hierarchical Method”, (see section 2.4.1)Priority: 1

16. The system must be able to present all of the information items at anypoint during the navigationRationale: To help improve the efficiency of the retrieval users should be able toaccess their information items at any stage of the navigation, there should be no needto navigate all the way to the bottom of the hierarchy.Source: The description of the “Hierarchical Method”, (see section 2.4.1)Priority: 2

17. The system must be extensible for adding further data typesRationale: Even though Messages, Photos and Notes have been selected for use inthis project due to the fact that they scored so highly in the user questionnaire (seesection 3.1.3) there were 6 other information items listed which all received reasonableresults as well as the fact that mobile devices are becoming used for more and moretypes of information.Source: Data gathering questionnaire (see section 3.1.3), question 10Priority: 3

18. The system must be extensible for adding further context typesRationale: It is sensible to design the system to be extensible so that if any of thechosen contexts are not as successful as thought they can be removed and / or newcontexts can be added if at a later stage new contexts are being considered.Source: Tulving E. (1973) states that information items are better recalled whenstored in the context they were learned (see section 2.6)Priority: 3

3.2.2 Data Requirements

19. The system must work on the users most up-to date personal information:Rationale: Users will not tolerate a system for personal information organisationand retrieval if it is not acting on all of the users information.Source:While prototyping (see section 4.1.1) it became apparent that the users wouldnot stand for a system that lost any information they had collectedPriority: 2

20. The system must support different types of dataRationale: The personal information of all of the users will be in more than oneformat.Source: The data gathering questionnaire (see section 3.1.3), question 10Priority: 2


21. The system must present any information retrieved with 100% accuracyRationale: Users will not tolerate their personal information being corrupted, changedor presented in a different manor to which it was stored. Source: While prototyping(see section 4.1.1) it became apparent that the users would not stand for a systemthat changed any information they had collected without their knowledgePriority: 1

3.2.3 Environmental Requirements

22. The system must be able to be used wherever a mobile device is used toacquire or retrieve informationRationale: The system is to be a mobile PIM system and therefore needs to beable to collect and retrieve information whenever and wherever the user can, just ascurrent mobile devices do at the momentSource: PIM activities can occur wherever the user is (see section 2.1.2) and thedata gathering questionnaire (see section 3.1.3), question 9.Priority: 1

23. The system should be able to cope with multiple users, but asynchronously- each users data must be kept private from other users viewRationale: Personal information by its definition is personal and therefore belongsto the individual user. There is no need for multiple users to use the system at thesame time on the same device. However it would be advantageous for multiple usersto have the option to use the same device at different times.Source: Personal information is personal, not general, (see section 2.6.1)Priority: 3

24. The System must be able to be used without ’live’ supportRationale: As the system will be dealing with personal information and will bein transit with the user it must be intuitive to use without the need to consult anydocuments or request help. Just by looking at the introductory document and usingthe system should the user be able to use the system.Source: PIM activities can occur wherever the user is (see section 2.1.2) and datathe data gathering questionnaire (see section 3.1.3), question 9.Priority: 1

25. The system must be able to run on mobile devicesRationale: The technology environment will be a mobile platform. A feasibilitystudy will be conducted to determine what mobile technologies the product will runon, be compatible with, and what limitations are appropriate. Source: PIM activi-ties can occur wherever the user is (see section 2.1.2) and data gathering questionnaire(see section 3.1.3), question 8 and 9.Priority: 1


3.2.4 User Requirements

26. The system must use language and terminology that is appropriate forusers familiar with basic handheld mobile devicesRationale: As the system is intended for people to use with their own personalinformation there should be no need for experience of anything more than to be ableto use the features of the average phone and to be able to navigate a folder structure.Source: During prototype iterations (see section 4.1.1) it became apparent that usersfound it much easier to use a system in which they were familiar with the terminologyused.Priority: 1

27. The system must allow the user to complete tasks in an order that theychooseRational: The system will be acquiring and retrieving personal information. It istherefore important that users are able to use the system as appropriate to theircurrent situation.Source: The definition of a PIM system (see section 2.1)Priority: 2

3.2.5 Usability Requirements

28. The system must provide the user with appropriate, meaningful feedbackRationale: Without timely feedback the user will may be waiting on the systemfor no reason, or they may be trying to use features of the system that are notappropriate at the current time. Feedback is essential so that the user knows thestate of the system and will reduce the chances of trying to move to an error state ofthe system.Source: During prototype iterations (see section 4.1.1) it became apparent thatusers needed to know where they were in the system and what features are availableto them.Priority: 2

29. The system must provide the user with appropriate information on thecurrent system stateRationale: Informing the user of the current system state will help to prevent themfrom trying to perform tasks that could lead the system to an error state.Source: This can be see from prototype evaluations see section 4.1.1) and currentfile management systems (see section 2.7)Priority: 2

30. The system must prevent errors and deal with any issues as soon as pos-sibleRationale: If the user encounters errors while using the system they may not use thesystem or become confused with the system. Users will be able to perform their tasks


more efficiently with less errors. Source: Current file managers operate successfullyin this way (see section 2.7)Priority: 1

31. It must be easy to navigate the hierarchy when retrieving personal infor-mation. The movement around the system must be unambiguousRationale: Existing file location navigation systems (see section 2.7 and 2.4.1) arerelatively unchanged over the last 30 years, no guidance is required to use them, theyare intuitive enough to be used.Source: Current file managers (see section 2.7) and the fact that the locationmetaphor has remained virtually unchanged over 30 years (see section 2.5)Priority: 2

3.3 Conclusion

A requirements specification has now been successfully defined that will shape the designand implementation of the user-subjective PIM system. The requirements specified willfacilitate the system to use dynamic directory structures to arrange information items andthe navigation hierarchy by the context the information was last used as well as classifyingall personal information items together that are related by the same subjective topic. Therequirements have also been derived so that the user should have more control of theenvironment and the way that their information is stored.

The design chapter will now document the design activities as the requirements have beenestablished. However the design will emerge iteratively through design-evaluation-redesigncycles and may therefore return to the requirements to make changes.

Chapter 4

Design

Following the creation of requirements of the system in the previous chapter, section 3.1,itis now possible for design activities to take place that aim to work with potential usersof the system to satisfy the requirements through prototyping cycles until construction.It is important that the system designed will, as the requirements state, be able to giveusers control over their personal information by removing the problems associated withcategorisation that were discovered in the literature review. The system must also bedesigned with a user-subjective approach, (Bergman et al., 2003), so that information canbe retrieved in the same context that it was last used and related items can be classifiedtogether regardless of their file type.

A user-centered development approach will be taken. Users will be involved in the eval-uation of the system as well as contributing to the design itself. This will ensure thatdevelopment continues to take users activities into account. Throughout the design sectionthe 8 users involved were found by asking users who showed suitable usage of their mobiledevices and the PIM features they contained, (from the data gathering questionnaire - theusers also had to have indicated that they were happy to be contacted again). By using atleast a sub-set of these users again in the later evaluation of the implemented system it willpossible to tell if user expectations of the system have been managed. User expectationsshould not exceed the features of the system and therefore users will not feel disapointedwith the system.

There are two types of design: conceptual and physical, (Preece, 2002). Conceptual designdevelops a model that captures what the product will do and how it will behave. Physicaldesign is concerned with details of the design such as screen and menu structures. Thedesign will emerge iteratively through repeated design-evaluation-redesign cycles involvingusers.

However there is no rigid border between conceptual design and physical design. Due tothe fact that interaction design is iterative some detailed design issues will be consideredduring conceptual design as well as the fact that decisions made during the conceptualdesign may well be changed in the physical design.

44

CHAPTER 4. DESIGN 45

4.1 Conceptual Design

Preece (2002) describes a conceptual model as “a description of the proposed system interms of a set of integrated ideas and concepts about it should do, behave, and look like,that will be understandable by the users in the manor intended”.

To transform the requirements that were created into this set of user tasks that the systemwill support a conceptual design process was undertaken. The conceptual model emergedfrom data gathering - low fidelity prototypes were used that enabled rapid feedback to bereceived followed by another iteration. This meant that it was a lot harder to forget aboutthe users and the context they would be using the system in.

To start the design process it was decided to continue with the user centered approachedto interaction design by carrying out iterations of prototyping and evaluating until therecan be reasonable confidence that the requirements will be met. This is because what hadbeen learnt from the iterations of prototyping and evaluating should be put into the finalimplemented product. By considering alternatives insights were gained into what the userswould need from the new PIM system.

4.1.1 Prototyping

Throwaway prototyping was the method chosen for the prototypes to be created. Therewere many reasons for this. Firstly it was very early in the design stage and the prototypeswould have to be low fidelity prototypes. Using throw away prototypes meant that testingwas not necessary at every stage, (unlike evolutionary prototyping that would of requiredrigorous testing at every iteration). This meant however that testing would have to beconducted at a later stage. Preece (2002) states that even though this approach could leadto lower quality final system, it is not so much an issue if the product is an innovation.This is because it is more important to secure market position (or be ready for evaluationof the project and concept) than to complete the project to a higher level of quality but tobe 2 months late.

It was important that it was not forgotten that even though the prototyping gave extensiveuser evaluation, there would be no testing for quality, robustness or error free operationand this must be completed later for the actual system.

The part of the system to be created with direct user interaction will be on each users ownmobile device. Therefore paper based outlines of the screens will be created that provide asimulation of a task. This allows the users to interact with a potential PIM system to gainexperience of using it in a realistic setting and be able to explore possible uses. While theusers are exploring the prototype like this they will be watched and evaluated while usingeach prototype to make sure it is noted what was or was not successful so that the findingswill make their way into the final PIM system.

The process of users interacting with prototypes is not only useful as an aid for discussingthe ideas of the new PIM system with the users but will be an effective way to test the ideas


in development. Preece (2002) quotes Schon (1983) stating that in building the prototypesyourself, a designer is encouraged to reflect on their design.

All the prototypes that were created throughout the entire design stage were to answerquestions and support the decision in choosing between alternatives. No instance wasthis more true than the first set of alternative prototypes as it would influence the overallmechanism for retrieval of personal information on the mobile device.

Process

Prototyping was used to be able to answer questions and support the design decisions bychoosing between alternatives. Each time a user was presented with a paper prototype thefeasibilty of the idea (or user based ideas in the later iterations) in-front of them was tested.For the project this meant that the system was able to receive user testing feedback andevaluation that would be fed back into the system for further prototypes or to ultimatelytake forward into the implementation of the actual application.

The early stages of the prototyping involved more concept testing rather than being tooconcerned with the physical details of the system. This allowed me to check that the overalldesign direction of the application was compatible with the rest of the system development.

After a few iterations focusing mainly on the concept of the system the prototypes weremore suited to clarify how users perform personal information retrieval. The prototypesillustrated that even though this was a paper based prototype, the proposed mobile devicewould be able to support the system as the intended functions, buttons, labelling as wellas positioning of items were considered.

It was deemed sufficient for these prototypes to investigate the scenarios and determinewhich items and functions were appropriate. However as the prototypes are paper basedthey are not testing factors such as system response speed.

Low-fidelity

As stated previously throw-away prototyping was used instead of evolutionary prototypingas it was early in the design stage and extensive testing was not appropriate at the time.

The low-fidelity paper prototypes will never be integrated into the product, they take amore explorational role. The prototypes are evolutionary in the fact that they do buildon each other - from iteration to iteration they support the exploration of alternate designideas as they are cheap and and quick to modify. However, they will not lead into a PIMretrieval solution themselves as the materials are very much different from the intendedfinal version.

During the early conceptual stage of conceptual design the low-fidelity prototypes wereimportant for exploring ideas as they were extremely flexible and therefore it was possibleto modify the designs extremely quickly for further evaluations.


Storyboarding

Storyboarding was used in the form of a series of sketches showing how the user wouldprogress through the tasks of retrieving various personal information items using the systemthat was being developed.

The storyboarding involved alternative series of sketched screens. This was due to the factthat the system would be GUI based.

Scenarios were prepared for the users to try and complete while using the prototypes, forexample: “retrieve the photo of a dog that you took in Bath sometime last May”. Duringthe first few prototypes while the concept was being evaluated more than the details of thesystem itself, users were able to describe what they would do next or to touch the screenon the icon that they would like to follow.

Later in the prototyping a paper mobile device was used in which users had to navigatethe system by pressing buttons on the paper mobile device - only then would the paperscreen be changed. These prototypes and storyboards together allowed the users to role-play with the prototype - which meant that the users were interacting by stepping throughthe scenario.

Both the conceptual prototyping as well as the more physical design prototyping screenswere a take on prototyping with index cards as screens were replaced in the print out of amobile device emulator. Each card was the representation of one screen. As the evaluationstook place the users stepped through the tasks as cards were replaced pretending to interactwith the user.

The fact that low-fidelity prototypes were used meant that there was a much lower devel-opment cost, multiple design concepts could be evaluated and they could work as a proof ofconcept. There were however navigational and flow limitations, as when users selected thefolder they wished to access they would have to wait for the paper screen to be replacedwhich meant that a feel for the speed of the system could not be obtained.

Using the low-fidelity prototypes meant a compromise was involved as being paper basedthe system did not actually work. The design choices that could be evaluated were slightlylimited, but the prototype was built, evaluated and re-built with the key issue of evaluatingthe context based retrieval and location based metaphor in mind.

The prototypes were acting vertically evaluating the functionality of retrieving personal in-formation using the location metaphor and context associated with the information. Verti-cal prototyping was suitable as the main focus of the project was to investigate the retrievalof personal information, there was less need for horizontal prototyping that acted over abreadth of functionality.

There were no compromises to the user that involved the inner workings of the system asthe prototypes were low-fidelity and required the screen to be changed by hand after everyuser interaction, there was no danger of the user believing the prototypes were a real system.


Evaluating the Prototypes

All of the users were being watched while using the prototypes. They were also told whatthe system they were testing was trying to do. Notes were made on each set of tasks(scenario) that they tried to complete, as well as any extra notes that were relevant to theuser. Such as using the system in a certain way that was not picked up by the notes andfeedback from the scenario tasks, the users were then encouraged to give any feedback thatthey could think of. All notes and feedback were then evaluated, (see 4.1.1).

Evaluation of the Prototyping Process

All of the prototype screens were sketched by hand. Preece (2002) quotes Verplank (1989),stating that icons do not have to be denoted by anything more than simple boxes. Thismethod of drawing the icons without worrying too much about the appearance of thedrawings enabled rapid creation of prototypes that in turn enabled more feedback to beobtained withing the time period.

Findings from Prototype Evaluations

First Iteration

For the initial round of prototyping 2 alternative methods were produced for the user to beable to retrieve their personal data. Explicit searching was not presented as an option dueto the findings from the evaluation of (Bergman et al., 2008) and the results of the earlyquestions in the data gathering questionnaire 3.1.3).

The first iteration of prototyping the retrieval methods included a filter based mechanism(figure 4.1) and an alternative that gave the appearance of a directory with sub-folders thatcould be accessed.

Overwhelmingly users found the filter method “too fiddly”. This appeared to be becausethe users were trying to complete all of the filters or just one. This meant that it wouldtake the users a tedious amount of time for retrieval as they would have to use a lot ofcognitive effort to think about what to select in each drop down box (almost approachingsearch levels of query creation as the contexts had to be rather more specific). The userswho only used one filter found that they were presented with far too many informationitems in the results for retrieval and it was approaching levels where the information mightas well have not been categorised in more than 1 or 2 folders.

Second Iteration

The next iteration contained alternatives that were all based on the location metaphor(see section 2.5). They each contained a directory / folder structure that the user couldnavigate down to try and retrieve their information. However one alternative used foldericons throughout the hierarchy and the other used different icons for the different folders.For example folders containing sub folders of locations had icons that resembled a globeand folders that contained sub folders of different times contained icons of clocks.


Figure 4.1: Prototyping Evaluation - Filter Based

Figure 4.2: Prototyping Evaluation - Location Metaphor

The design with just the folder icons was kept as users appeared to become confused withthe different icons for the folders. They did not grasp that even though they had differenticons all the items were infact just folders. Some users did not know what to expect ifthey selected for example a location that had an icon of the globe and were then presentedwith clock icons. Whereas with just folder icons users appeared to understand that theywere opening and navigating folders that would contain either more folders or informationitems.


Also within the second iteration of prototypes it was determined clearly that the contextsshould be broken down into sub folders and categories. This became apparent as the userswere given two different prototypes, one in which “location” listed all the town names theinformation items had been acquired in, and within “time” listed all the occurrences thatinformation had been acquired. The other prototype broke the location and time contextsdown in a taxonomy like classification. Instead of just a list of towns or time instances therewere folders that broke down location, e.g. country, county, city, town and year, month.

Figure 4.3: Prototyping Evaluation - Dates Not In A Taxonomy

This would appear to be for the same reason as noted in section 2.4.4 as users are ableto build up a cognitive map in their mind of the folder structure and hierarchy as well asresults from the data gathering questionnaire (see section 3.1.3) that showed the majorityof users would not allow their information items to be organised in such a way that itbecame difficult to quickly identify and retrieve items from the folder that the items werein.

Third Iteration

The third iteration of the prototypes was the last in which the system was not so muchconcerned with the physical buttons of the device, but the concept of the idea. When userswere asked to find an information item, then half way to finding it asked to find somethingdifferent a few users had trouble being able to navigate to the new item without goingback the the start (the root of the hierarchy). So the current position in the hierarchy wasplaced at the top of the screen in the place of the title.


Figure 4.4: Prototyping Evaluation - Hierarchy Location In the Title

After incorporating the current position of the hierarchy into the title for the next iterationof prototyping and evaluation some users were still having trouble being able to rememberhow for down the hierarchy they had gone, (and which route they had taken). Due to factthat there was still confusion within a few users an extra screen was added that wouldinform the user exactly where in the retrieval hierarchy they were.

Figure 4.5: Prototyping Evaluation - Hierarchy Location In A Dedicated Screen

In order for the users to be able to use the new screen effectively for evaluation as well asbeing able to get a more realistic idea of how the system would work on a real device nowthere had been many iterations on the concept itself the prototype screens were incorporatedinto a paper device. Users would now have to select the appropriate buttons to be ableto navigate through the system, unlike the previous iterations of prototyping in which the


users said or touched the part of the screen that they would like to go to.

Fourth Iteration

The first thing that was changed in the design when using the paper device as well as thepaper prototype screens was the date filtering. The time context had already been brokendown into a taxonomy categorisation previously and now worked on year, month and aselection of days - the user would choose a day in the month and then an offset of howmany days to include in the set of results.

Figure 4.6: Prototyping Evaluation - Paper Prototype Device With Inefficient Date Selec-tion


However this proved to take too much effort on behalf of the user. They did not like, andin some cases would even go ’back’ to avoid completing the day section. The users seemedto have no trouble quickly moving forwards and backwards through the system. This wasinspiration to change the day selection to a list of all the days in which information hadbeen acquired on. This was much more successful. When users were asked to find an itemof person information that they acquired on “roughly the 15th March” they would navigateto the list of days, find the day that was closest to the 15th, go ’into’ that folder and comeback out before trying another folder, this approach was treated much more favourablythan navigating to a field to type in a date and an offset.

The design was next changed as it became apparent users found it frustrating and slightlyunintuitive to be have to select “menu” then “back” each time they were to up the hierarchy.Which happens to be an essential part of navigating for information, and what infact helpsto make it more advantageous over searching for personal information. So to help withthis problem users were told that they were aloud to touch the left or right buttons onthe paper prototype to navigate up or down the hierarchy respectively. Even though theresults of this change may not become fully appreciated until the application is running ona phone (as the paper screens still had to be changed after every button press) it made adifference to the users. Not having to press 2 buttons every time to go back meant thatthe users were a lot happier to navigate to where they thought the information item theywere after was located and easily back up with one (intuitive - left) button press. Onceusers were using the left button to go back they also started using the right button to godown the hierarchy which appeared to show that dedicating these 2 buttons to navigationwill be beneficial to the system as it will make navigate a more intuitive process for users.

Final Prototype Iteration

Within the final set of prototypes it was determined that information items should bemade available for access sooner. However users must not be presented with long list ofinformation items. What this meant practically for the prototype was that users shouldnot have to either navigate through 3 different types of context or be presented with alist of items to large to be able to quickly and easily retrieve what they were after. So acouple of alternative prototypes were made that differed in when actual information itemsbecame available to select. The most successful was the prototype which, after a user hadnavigated one context was then able to not only see further context folders to navigate,but to see the items that were available at this point, see 4.7. Contexts and folders havebeen kept always at the top of the list so they are the first icons which the users sees whennavigating.

4.1.2 Interaction Mode

Activities as a base for conceptual Models

Even though the activities that users will engage in are not mutually exclusive the projectcould fall into the categories of activities of “manipulating and navigating” or “exploring


Figure 4.7: Prototyping Evaluation - Further Contexts Available as Well as InformationItems to View

and browsing”. Different parts of the system will fall into different categories, however, forthe fundamental mode of the system - retrieving personal information using the locationmetaphor theses categories would be most suitable.

“Manipulating and navigating” could be used as it is based on allowing users to manipulateand navigate through an environment of virtual objects that shares properties with thephysical world. The location metaphor was developed from the fact the virtual folderscontain files just like they would in a filing cabinet within a physical office.

“Exploring and browsing” could be used as it is based on the system providing a structurefor the user to find things without the need to use specific questions on the system. Thisis suitable as Bergman et al. (2008) even states that browsing a directory structure is thepreferred method of retrieval for personal information over search as formulating a searchquery requires more cognitive effort.

Manipulating and Navigating

The project will follow direct manipulation, (first developed by Ben Shneiderman 1983) asthe system:

• “Will require continuous representation of the objects and actions of interest”

The system will need to constantly display the representation of the virtual folders aswell as the actions of opening and closing the folders to go up and down the hierarchyrespectively

• “Will require rapid reversible incremental actions with immediate feedback about the


object of interest”

The user must be able to navigate the system by drilling down the folder hierarchiesan instantly be able to see what the next options are. As the user will be navigatingfor personal information they must have the option to be able to go back up eachlevel that they go down.

• “Will require physical actions and button pressing instead of issuing commands withcomplex syntax”

As shown by Bergman et al. (2008) and as partial motivation for the project the userwill not be generating search queries that take greater cognitive effort but navigatingfor everything they want to retrieve. This will be done by choosing 2 physical buttonson the device to represent moving up and down the hierarchy.

Using direct manipulation interfaces means that beginners should be able to learn the basicfunctionality of the system more rapidly. This is a requirement of the system as the userwill be retrieving their own personal information, it is therefore important that they canstart using the system as quickly as possible. It also means that users who have becomefamiliar with using the system to retrieve their information should be able to work rapidlyand not have to put much thought into what they are doing, like regular navigation (seesection 2.4.4) experienced users should be able to continue on what they are working onwhile navigating for the information.

Due to the fact that there should be incremental actions that can be reversed and do notrequire complex syntax (selecting folders and navigating) there should not be much needfor many error messages which will hopefully lead to users gaining confidence and feelingin control of the system.

Most importantly for this system using direct manipulation interfaces is that users cansee immediately if their action of navigating to a sub folder has furthered their goal ofretrieving their personal information item or not. If it has not they should be able to gostraight back up the hierarchy.

4.1.3 Interaction Paradigm

The design philosophy that the system being developed is best suited too (after considera-tion of requirements and constraints) is “Pervasive Computing” as the user will be carryingaround their own copy of their folder hierarchy. This builds directly upon the current expec-tations and experience of both physical filling cabinets and the hierarchy without differentautomated contexts on users desktop machines. The system will allow individuals to keepa copy of their personal information on their own mobile device as well as being connectedto the a server that allows access from other devices at different times.


4.1.4 Expansion of the Conceptual Model

As it has been decided through generating the requirements and the decision to follow thepervasive computing paradigm that the system will need to operate on mobile devices.Therefore a feasibility study will be carried out (see 4.2.1).

System Functions

Section 2.2 shows that it is important to decide what tasks the system will perform andhow the functions of the task are divided between human and machine.

The tasks that will be performed, the modes in which humans and automation might worktogether, the relationship between tasks and the required information for each task are:

• Browsing (navigating) for personal information items already received

Function Allocation

The human will do everything except to ask the computer to help in suggestingpossible options - 2/10 on the Sheridan-Verplanck scale of human-machine functionallocation (see section 2.1)

The human will do all the navigating of the directory structure, but the folder nameswill be generated dynamically and presented by the system.

Relationship to other tasks

Browsing must be completed without any distractions for the user, the browsingfunction must take priority of the screen and only tasks that do not interrupt theuser viewing the file hierarchy may take place in parallel, in the background. Useof this task will be constrained if another task that is going to distract the user isalready in process.

Information required

The browsing task will need the lists of files as well as the associated contexts thatcome with the information items so that it is able to display the folder structure andtherefore have the users navigate the hierarchy

• Take photos

Function Allocation

The computer selects a course of action, and it is up to the human to decide whetheror not to do it - 4/10 (see section 2.1)

When the users wish to take a photo (acquire a personal picture) the system will openthe viewfinder, but the user has the ultimate say of when the photo will be taken.



Taking photos requires the user to be looking at what they are going to be shooting.Therefore it cannot take place in parallel with anything that could potentially stopthe user from being able to use the viewfinder on the device.


The only information that will be required is where to store the image once it hasbeen taken.

• Make Notes

Function Allocation

The human does the whole job of planning, selecting options and preparing the ma-chine, up to the the point of switching the machine on to carry out the actions. 1/10(see section 2.1)

Users notes will be personal to them, and simply a textual representation of whatthey are trying to use the note for, for example a list or reminder. They will writethe note using the mobile devices’ input.


The user will be trying to transfer their thought processes onto the note that theyare trying to write so it would not be appropriate for any other task to distract theuser while they are writing the note. Therefore making notes cannot take place inparallel with anything that could potentially stop the user from being able to createthe note they intended to make.


The only information that will be required is where to store the note once it has beencreated.

• Receive SMS messages

Function Allocation

The computer does the whole job and tells the human what it has done if it, thecomputer, decides that the human should know - 8/10 (see section 2.1)

Users will not generally know that they are about to receive a message or sendmessages to themselves, therefore it will be up to the system to manage the handlingof the incoming messages


As receiving an sms message could happen at any time the process to deal with themessage should be able to happen in parallel with any other task and not interferewith anything that the user is currently doing.


The only information required to organise the sms messages is where to store thereceived message.


• Acquire the context surrounding the acquisition of personal information

Function Allocation

The computer does everything, including deciding whether to do it, and decidingwhether or not to tell the human - 10/10 (see section 2.1)

Whenever the user will acquire personal information all of the associated context willbe gathered by the mobile device automatically and will only inform the human if itcannot gather one of the contexts.


The acquisition of context relating to the information items that have been createdcan happen in parallel with any other task as the process should run in the back-ground, the user should not notice the results until they attempt to retrieve theinformation using the context at a later time.


The purpose of the task is to take the information item that has just been createdand to assign a time and location to the information. The task will be required toretrieve the time and physical location of the device from the device.

• Upload the personal information and context

Function Allocation

Computer selects the action and tells the human in plenty of time for the human tostop it if the human disapproves - 6/10 (see section 2.1)

Users may not want their information being sent to a server for any number of reasonsincluding privacy or network charges. Therefore users be able to stop any informationfrom being uploaded by changing the system-wide setting as well as being asked bywhich method they would like to connect by when they first make a connection.


Can happen in parallel with any other task as the process should run in the back-ground, the user should not notice the results until they attempt to retrieve the at alater time.


This task cannot take place for each information item until the relevant context hasbeen acquired and the user has indicated that they approve the item can be uploaded.

4.2 Physical Design

The physical design is a more concrete, detailed section describing the interface. Howeverthere is no rigid border between the conceptual and physical design of this system. Alot of the physical design decisions were taken during the prototyping of the system (see


section 4.1.1). Even though the design decisions were taken tentatively at first duringthe initial prototype-evaluation cycles as the iterative process continued more concrete,detailed decisions were made. Interaction design is inherently interactive, therefore, whileprototyping, the initial conceptual design ideas were re-visited and molded in to morephysical constraints (see section 4.1.1). This allowed initial freedom and creativity todevelop without being tied to any physical constraints, before later adding the physicaldetails to the design.

As the system will follow the pervasive computing paradigm there is potential for conflictbetween the environment, data, user and usability requirements and the functionality ofthe mobile devices used. The system requires a lot of functionality but is constrained bythe resources and small screen size of a mobile phone. This means that the display ofinformation may be limited leading to restricted views of the information. A feasibilitystudy has been carried out to find the most suitable platform for the needs of the projectbased on the decisions and choices of the design so far.

4.2.1 Feasibility Study - Device Platform

Windows Mobile

Windows Mobile is an operating system that comes with basic applications from Mi-crosoft. Third party software development is available for the mobile devices runningWindows Mobile. In February 2009 Windows Mobile was shown to have 14% marketshare, http://www.linuxdevices.com/news/NS3224130040.html.

Due to the high end devices that Windows Mobile is targeted at there would be no issuesof lack of functionality required for the software product.

To develop a third party application for the Windows Mobile all code would have to bewritten in the native Visual C++ or in the .NET Compact Framework, either of whichwould take a considerable amount of time to learn.

Regarding evaluating the application, there are not a wide number Windows Mobile devicesaround compared to other operating systems. This could make finding participants in anevaluation hard to come by as it would be far too expensive for the project to purchasemultiple windows mobile devices.

Google Andriod

Android is an operating system for mobile devices that is based on the Linux Kernel.Development can be officially completed using Java.

The Andriod platform itself was only announced in late 2007, within the UK at the momentthere are only 2 mobile devices released on the platform. Even though there is a lack ofuptake for the platform at the moment, and will therefore be hard to come by participants,


the platform has a lot of potential for any future work. This is because the entire platformhas been available, open source since late 2008.

The devices are once again high end so functionality would not be a problem. HoweverAndriod will not be used due to the lack of handsets and high number of bugs and lack ofdocumentation owing to the fact that the platform is in its infancy.

Java Platform, Micro Edition (J2ME)

Java ME is a subset of the Java platform which provides a collection of API’s for thedevelopment of software on resource constrained devices, such as mobile devices.

Java ME is a popular platform for development on mobile devices as it is relatively cheapto develop for as they can be easily emulated on a personal computer before being copiedto the mobile devices.

If the project was to be made using J2ME then the MIDP (Mobile Information DeviceProfile) would be used. MIDP contains a subset of Java-class libraries and is a type of“Connected Limited Device Configuration” (CLDC). The MIDP would be able to providethe system with a GUI API as well as other basic libraries and virtual machine featuresnecessary to run the application.

Almost all mobile devices on the market currently come with a MIDP implementation,finding participants would not be a problem at all.

J2ME will not be used for the development of the application. Firstly the system willheavily reliant on GPS and networking modules, which although exist on the platform arenot the most stable and reliable. Secondly there are many reports of discrepancies of defectswhen using applications made with J2ME on multiple devices. Usually not too complexwork-arounds can be developed by customising the application for different device. Eventhough this appears to not be too complex it would appear to be time consuming withdifferent fixes required for each device.

iPhone OS

The iPhone is itself a smartphone produced by Apple Inc that is aimed at the high end ofthe consumer market as it is Internet connected and utilises a multi-touch screen.

The operating system’s user interface is based on the concept of direct manipulation sowould appear to make a great match with the system being developed. Existing applicationson the operating system appear to to give immediate feedback to user input and providesan extremely fluid interface.

To be able to release any applications they have to be installed through Apples App Store.Even though the (well documented and incredibly well designed) SDK is free to obtain,a machine running Apple’s OS X would be required. Not only this but there would be a


iPhone Developer Program fee to be paid to Apple to be able to install the applicationonto devices.

iPhone OS would be the platform developed on if it was not for the high costs involvedof the device itself, the development machine and the developers program fee. The deviceand OS are extremely well built, documented, packed with features and functionality andare growing in market share all the time.

Symbian C++

Symbian OS is an operating system designed for mobile devices with suitable libraries thatare optimised for devices with very few resources.

Until very recently the operating system was owned by the leaders of the industry (Nokia,Ericsson, Sony Ericsson, Panasonic and Samsung) as well as being licenced on devices ofmany other manufacturers. June 2008 saw Nokia purchase 100% of the operating system,however they have declared that the OS will now become open source together with theiruser interface for the platform, Series 60, see 4.2.1.

The operating system was built from the ground up with the intention of running on mobiledevices. The three design rules for the OS and third party development are that integrityand security of user data is paramount, user time must not be wasted and all resources arescarce. Applications and the OS follow an object-oriented design of model, view, controller.The OS is optimised for battery saving with a callback approach to services.

As of November 2008 Symbian OS had a 46.6% share of the smartphones shipped in thethird quarter of 2008 as well as having over 200 million smartphones shipped in total,http://www.informationweek.com/blog/main/archives/2008/11/apple beats rim.html.

To get applications onto a Symbian device they need to be signed. This done for some ofthe same reasons as Apple with their application store - to stop malicious programs beingreleased. However Symbian do not charge for signing. Additionally Symbian will allowcertain applications to be “self-signed” if they only use certain basic capabilities. What iseven more appealing is the fact that www.symbiansigned.com will allow developers to “devsign” their applications. The process for ”dev signing” involves uploading your applicationand an IMEI number (every mobile device has a unique IMEI number). Your applicationis then emailed back and will only be able to installed on the device with the IMEI thatyou supplied. This is incredibly advantageous over Apple’s developer programing, as therewill not be any fee’s involved with testing the application and the application will be ableto be signed in almost real time.

The native language of the Symbian OS is a non-standard implementation of C++. Thereare 2 main platforms based on Symbian OS that provide their own SDK, see 4.2.1 and4.2.1. These SDK’s contain the documentation, header files and library files needed tobuild Symbian OS software. The SDK’s also contain an emulator for development, howeverthe emulator is limited in certain telephony functions.


UIQ

UIQ is a software platform based upon Symbian OS. It acts predominantly as a GUI laythat provides additional components to the core OS. UIQ allows for the development offeature rich applications.

The UIQ platform will not be used for development of the system. This is because theSymbian OS has been purchased by Nokia and UIQ is owned by Sony Ericsson. The OSwill become open source through the Symbian Foundation but UIQ will cease to exist asS60 is the choice of platform for the Symbian Foundation.

S60

S60 is also a platform that sits as a GUI layer of Symbian OS. It is currently the leadingsmartphone platform in the world based on market share. Nokia own S60 and are planningto open source the platform with Symbian OS which has recently been purchased by Nokia.S60 is designed for fully-featured mobile phones with large colour screens making it suitablefor this project. S60 is probably the most powerful platform that is available to thisproject for development on, however S60 will not be used directly due to the reasons listedimmediately below.

Native Symbian C++ will not be used as programming in this language has a steep learningcurve - Symbian requires the use of special techniques such as using the cleanup stack anddescriptors. This means that compared to other environments listed in this feasibilitystudy even simple programs would be harder to implement. Also Symbian although wellestablished was created at a time when mobile devices had much more restrictive hardware.The techniques required for Symbian development may not even be needed on today’smobile hardware and may just be causing unnecessary complexity in the source code.Programming appears to be more focused on low level routines rather than applicationspecific features.

Python for S60

Python for S60 is Nokia’s port of the general Python programming language to the S60software platform.

It is clear that the Symbian platform gives the developer the broadest power. For thisreason PyS60 (Python for S60) was chosen for development as it is not only interpreted bySymbian (and able to harness the development power of the platform) but is extensible,agile and easy to learn - making it suitable for rapid prototyping. PyS60 provides accessto many of the mobile devices smartphone functions such as camera, contacts, calendar,audio recording and playing, TCP/IP and Bluetooth communications, simple telephonyand location based functions.

PyS60 is open source, because of this there is now a strong and dedicated communitysurrounding the platform.

PyS60 has its own SDK that sits on-top of the S60 SDK which means development and


testing can take place in the emulator of developers machines. There is also an interpreterwhich can be signed and installed to a mobile device for development. Using the interpreteron the mobile device means that scripts can be pushed to the device and executed withoutthe need for re-signing after every change. The interpreter on the mobile device can alsobe accessed from an interactive Bluetooth console on the developers machine. There arealso a range of tools that can be used for testing.

Once development has been completed and is ready for testing on more devices the applica-tion can be packaged as a standalone application using the tool ensymble. If the users S60device comes with Python then they just the application needs to be installed. Howeverif the users mobile device does not have Python on it the developer can use ensymble tomerge both Python and the project application into one standalone application.

4.2.2 Feasibility Study - Server Platform

As it was determined and stated in requirements the system must be extensible for multipleplatforms. This means that the data items acquired and context associated with the itemswill need be stored where not only the device can access them but will be available fordifferent devices in the future to access them, such as different mobile devices or a desktopmachine with a different client.

The context associated with the acquired information will need to be efficiently stored. Thebest way to do this will be by using a relational database management system. MySQLhas been chosen for this task as there is knowledge of creating and maintaining databasesusing this program as a server providing multi-user access to databases. MySQL is alsofree to use and there are many opportunities for access to servers with databases availableto use.

To effectively interact with the MySQL databases the PHP scripting language will be used.This is because there is knowledge of using PHP, PHP is extremely widely used and generalpurpose, it can produce dynamic web pages while being embedded into HTML - this meansthat the mobile devices will be able to easily make requests by calling a URL and thenparsing the results that are displayed on a HTML page.

4.3 Design Summary

Now that the design process is coming to a stage where the implementation can beginit is suitable to consider the look of the system. The system will be made up of mostlypredefined widgets. The set of widgets will be the Python for Series 60 style guide usingthe appuifw module. This style guide dictates the look and feel of the interface howeverfollowing the feasibility study it is assumed with a reasonable amount of confidence thatPyS60 will be sufficient for the tasks.

The appuifw module that will be used is an interface to the S60 UI application framework.


• Screen Design

PyS60 allows for three different types of screen: normal, large or full. The system(as determined by the later prototypes) will use ’normal’ screens as they allow for atitle to always be present at the top of the screen. A title at the top of the screenwas discovered to be important so that users could determine where in the system /folder hierarchy they were. ’Normal’ screens also allow for application menus to beused, see immediately below.

• Menu Design

There will be two types of menu used within the system, appuifw Listbox’s that oc-cupy the entire body of the screen and appuifw application menu’s which are activatedwhen a softkey of the device is pressed.

Listboxes will be used to display the main menu of the application as well as eachlevel of the folder hierarchy including the lower levels which will contain links to theinformation items,

Application menus will be used for various options and settings around the system.For example to change the settings of a photo while looking through the viewfinderor to move up or down through the folder hierarchy.

• Input Design

Query widgets will be used to confirm user decisions (when in ’query’ mode). Theuser will be asked to confirm or cancel a selection. Query widgets in ’text’ mode willbe used to input short text such as usernames. Query widgets in ’code’ mode will beused to enter short sensitive information such as a password.

For longer items of text such as entry of a note the user will be presented with anappuifw field. Fields can have their permissions changed for reading or writing andcan easily be hooked onto calling a function when closed or saved.

• Notification Design

When relatively small amounts of information need to be displayed to the user appuifwnotes will be used. The notes will either be of type ’info’ simply to inform the userwhat is happening (e.g. using the network is taking longer than expected). Or thenotes will be of type ’error’ to indicate that an error has occurred or the user hasmade a mistake.

For larger amounts of information the same appuifw field will be used as is usedfor text input, however the permissions on the field will be different as to not allowchanges to the text.

• Icon Design

Due to the intuitive nature of Listbox’s on the S60 platform icons for individual itemswill not be used. The Listbox’s on the platform list items on the screen in such a waythat the entire horizontal area of the screen where the item is placed will be selected


and it is extremely clear that the selection can be changed by moving position in thelist. Even though folder icons were used in the later prototypes the platforms Listboxis incredibly intuitive. Also it was discovered that different icons confused users inearlier prototypes 4.1.1.

4.4 Conclusion

A system has now been provisionally designed that will address retrieval issues in PIM thatwere highlighted in the literature review such as users loss of control over their informationmanagement due to static directory structures. The design also incorporates the fact thatnavigation is overwhelmingly preferred over search and there is a need for a user-subjectivePIM system that will allow for retrieval through the context in which the information waslast used.

Many conceptual and physical prototype-evaluation iterations were carried out to aid thedesign process by testing the ideas generated from the requirements analysis.

In the next chapter the implementation and testing of the system will be detailed. Theborder between design and implementation is not fixed, and therefore it is possible for somedesign refinements in the implementation section.

Chapter 5

Implementation and Testing

Following the design phase conducted in the previous chapter, it is now possible to not onlydevelop a system architecture, but to document the process of building a user-subjectivePIM system. This system will include the ability to retrieve information based on thecontext it was last used and classify information items (regardless of its type), by imple-menting dynamic directory structures that use the location metaphor. The system willalso use the detailed design description that concluded the previous chapter to implementfunctions with the ability to organise the user’s inbox and acquire photos and notes.

The aim of this chapter is to describe how the findings from the literature review, therequirements and the user centered designed were used to develop and implement a newPIM system using Bergman et al.’s (2003) user-subjective approach.

Recall, that a feasibility study was carried out in the design section (section 4.2.1) thatgives an introduction to Python for the S60 platform and the reasoning for its choice asthe mobile development environment.

5.1 Database Structure

The relational database structure has been created using the learnings of the previouschapters. It was determined that tables would be required for:

• User credentials:

Every user will have a user account in which the username and password will bestored here for verification of the user as well as to use as a reference with the contexttable to determine all of the information items that belong to the user

• Each context that could be used within the system:

This version of the system contains time, type and location tables with all of therelevant contextual information as well as a foreign key referencing the context table

66

CHAPTER 5. IMPLEMENTATION AND TESTING 67

which is a unique identifier for every information item the user owns.

• The actual location of the information item:

This is not a generated location based on the location metaphor but where the itemresides on the system.

• A context table that gives each information item its own unique identifier

This is a junction table that supports many one-to-many relationships. Each infor-mation item has 1 unique contextID which can be used to obtain the file location,the owner of the information, type of item, time item was acquired, the location theitem was required as well as potentially any other contextual information.

It is worth noting that there is no table for the hierarchy of the information items that ispresented to the user. This is because the hierarchy is generated dynamically dependingon which attributes have been selected previously.

5.2 System Architecture

The system is structured into 3 layers; Presentation, application processing and data man-agement. The presentation layer ensures that the users can view their information in whatlooks and feels like a consistent directory structure as well as managing the user interactionto be able to navigate the hierarchy. The application processing layer implements the logicorganising the information for the presentation layer. The data management layer managesall database operations. This layering is important, so that in future it will be possible todistribute the different layers to different devices, whether mobile or not.

A client-server architectural model has been used in which communication occurs acrossthe Internet using either a GPRS, 3G or WIFI connection between the mobile device andthe web sever, which in turn sends SQL queries to the Database Server.

The clients know the name of the server as well as the services that are available. The clientsmake http requests to the web server. The server does not need to know the identity ofthe physical devices, however the client will not have access to any services until it hasbeen verified that it is acting on behalf of a registered user of the system after the suppliedusername and password is compared with the user credentials stored in the database. Theclients make requests to the server and wait for the appropriate reply or are presented witha suitable message that is dealt with by the client.

A fat-client model is used as the database server is only responsible for the data managementand retrieving various lists of information items from the database. The server acts as atransaction server managing the database transactions. The application logic involved inorganising the information as well as the implementation that handles interactions withthe user occurs away from the server.


Figure 5.1: Database Design

Figure 5.2: System Architecture Layers

Due to the fact that the system is in 3 layers the implementation is scalable as it wouldbe relatively easy to add new web servers if the number of users increased dramatically.Structured Query Language is used to handle the retrieval of information from the database.


Figure 5.3: Three-Tier Client Server Architecture

5.3 System Development

The following sections will describe how both the web server and mobile client operate andinteract with each other. The client will send requests to the server to initially accept aninformation item. If this requested is completed successfully then the client will supplementthe upload with a request to store the relevant context in the database. While there areinformation items stored on the webserver and context in the database, the client, in theprocess of ”browsing” from information items will issue requests for lists of attributes andinformation items. The client will then use these lists to build the directory structures thatform the basis for navigation by the user for retrieval.

5.3.1 Web Server

The webserver contains many php scripts that act as an interface to the services of thesystem. The scripts are broken into two categories. One category manages and verifiesthe uploading of the various information items. The other category manages all databaseaccess which includes dealing with user credentials, adding contexts, adding a record ofuploaded information items, and all of the functionality of dealing with retrieving lists ofpotential hierarchies.

Scripts for uploading of Information Items

The process of uploading an information item is initiated by the client on a mobile device,(it is the first contact that the server may have with a client). When the client has acquiredinformation a request is made to ..\up\<file type> upload to url.php to try an upload thefile onto the server.


If the request is successful upload to url.php will then store the item in the appropriatefolder (..\up\<file type>\). The item will be assigned a unique, random filename. All in-formation items stored on the server are random so that there is no identifiable informationassociated with the each item. If upload and storage has been successful the filename isreturned to the client. If unsuccessful an appropriate error is sent back to the client.

Later in the process when the client tries to assign context to the information item or toretrieve the item \up\verifyFileExists.php is used. The script simply indicates whether thecombination of type and file name exist or not.

Scripts for database interaction

..\db\addItem.php

The role of the addItem script is to add all the relevant information and context of acquiredinformation items to the database and associate the item with the appropriate user.

The process is as follows

1. Connect to the relevant database

2. Verify user exists and password is correct, return appropriate message if not (usingverifyUserExists.php)

3. Verify that the information item exists on the server, return appropriate message ifnot (using verifyFileExists.php)

4. Begin a database transaction so that the database can be rolled back if an errorshould occur

5. Insert username into context table to generate a unique identifier for the informationitem

6. Insert the type of file and and filename into the appropriate table

7. Insert the time information into the appropriate table

8. Insert the location information into the appropriate table (using addLocation.php)

9. End the transaction by either committing successfully, or rolling back the database

..\db\addLocation.php

The role of the addLocation script is to take a longitude and latitude from addItem.php- which obtained them from the mobile device (client) and turn them into a taxonomyof location areas. e.g. use 51.5846357, 0.0441026 to obtain: United Kingdom, GreaterLondon, Redbridge, Ilford.


The process is as follows:

1. Connect to the Google maps API using the systems API key

2. Pass the maps API the longitude and latitude and receive a json encoded page ofresults

3. Decode the json results and extract all the necessary location information

4. Prepare the location information for insertion into appropriate table using the appro-priate unique information item identification number.

..\db\addUser.php

The addUser script adds a users credentials to the appropriate table.

..\db\includes.php

The includes script is included by any script that needs access to the database. It containsthe details required to connect to the database so that they can be easily changed in thefuture if required. The script also acquires the connection to the database.

..\db\retrieval.php

The retrieval script is used to build SQL queries, execute the queries and return the resultsto the client so that hierarchies of contextual information can be built and presented to theuser as folder structures.

If the script is being called for the purpose of retrieving the initial options for the user tostart navigating on the phone (i.e. the mobile device requires the options for the root andone level below the root) then the script will return all of the options for the highest levelof the taxonomy, such as years, countries and file type.

If the request is for anything other than the root of the hierarchy then the script willtake the name of the “folder” (attribute) that the user wants to access and a list of what“folders” (attributes) the user has previously selected. It will iterate through the list (andinclude the wanted attribute) building the query. When the query has been built it willexecuted and the results returned.

..\db\verifyUserExists.php

The verifyUserExists script ensures that the user trying to access the system is who theysay they are by comparing the supplied username and password with the credentials thatare stored for that user in the database.

5.3.2 Mobile Client

Once the design section was completed and the role of both the client and the serverwas determined as well as the interactions between the two entities, work began on theimplementation of the client. Figure 5.4 shows the class structure of the mobile client.

CH

AP

TE

R5.

IMP

LE

ME

NTA

TIO

NA

ND

TE

ST

ING

72

Figure 5.4: Class Structure


PimText.py

PimText is the main script of the application that contains the main class. When run,the script will determine where it is situated in the mobile device’s storage and createappropriate directories if they do not already exist.

The first thing the user will be presented with is a list of available access points to set asthe default method for connections.

Then the main class is instantiated - all other system views are initialised at this point.

If there is no account associated with the device the user is asked whether they would liketo create an account or to enter the details of a previously created account.

The user will see the main menu listing all of the possible tasks available to then. Fromthis screen the user can exit the application or select the task they would like to perform.When the user selects an item from the list the appropriate view is activated and is givecontrol of the GUI.

(a) The Main Menu presented tothe user, selection of an item fromthe Listbox will activate the ap-propriate view

(b) Available access points, dis-played as the application starts aswell as when the appropriate op-tion is selected from the PimTextmain menu

Figure 5.5: PimText View Screens

BrowseView.py

BrowseView is activated when the user wants to retrieve personal information items. Whenthe user selects “Browse” from the main menu they are presented with the root of thehierarchy: a list of all the possible contexts that can be used to act as the root of the folderstructure.


From here the user can navigate down the taxonomy of folder names relating to the context.The contexts implemented are the physical location that the information was acquired in,the time it was acquired, the type of item it is and where appropriate the sender of theinformation. The user can ’open a folder’ by selecting it with either the center button onthe mobile device or by pressing the right button on the device. The user can go up thehierarchy by selecting ’options’ and then ’back’ or simply go back by pressing left buttonon the mobile device.

Once the user has navigated down one context they are presented with the contexts thathave not yet been navigated as well as a list of the information items that are applicable tothe location in the hierarchy that they are currently in. The user can keep navigating untilthere are no more context types to navigate by. When this occurs the user is presented withjust the list of available information items (which by this point is usually much reducedthan the higher levels). The user can tell where they are in the system because the title ofthe application is dynamically updated to reflect where they are in the system.

Where the users messages are concerned the location context is not available as it is notappropriate. The salient cue when trying to retrieve a message is the sender of the message,or a combination of the sender and the time the message was received.

When the user selects an information item to view the appropriate viewer is launched. Seefigure 5.9(a) for the viewing of notes and messages. However when retrieving an alreadywritten message the title contains the route the user took to navigate to the note or message.Pictures are viewed in a dedicated picture viewer see figure 5.3.2 that also displays the routethe user took to navigate to the picture.

When the user exits any of the viewers that displays the information item they are takenback to the location in the hierarchy in which they selected the information from.

The retrieval mechanism

Below is a brief description of how the mechanism for retrieving the list of items and thenproducing the updated folder hierarchy occurs:

• When the BrowseView is activated by the user the details of the top levels of thecontext taxonomy are retrieved and stored in lists of their own types, e.g. a list ofyears, countries and file types.

• The ListBox GUI widget has a callback function (handle select) that is called when-ever the user selects a folder (either using the center button or the right button on themobile device). The callback function calculates what attribute was selected when ei-ther button was pressed. There is also another function (handle back)) that is calledevery time the user goes back up the hierarchy by selecting ’back’ from the menu orpressing the left button on the mobile device.

• handle select maintains a list of every folder the user has selected so far. The list isadded to every time another attribute is selected. The list is also popped everytimethe user goes ’back’.


(a) The root of the folder struc-ture

(b) One folder down from the“root”. This is the top of the timecontext / taxonomy

(c) The bottom of the locationtaxonomy, notice location is theonly context that has been usedso far

(d) A location hierarchy and timehierarchy has been navigated,only time is left to navigate

(e) Only a time hierarchy hasbeen navigated, there is the optionto navigate the two other contexts

(f) A time hierarchy has been ex-hausted, and a location hierarchyhas been navigated to a certainpoint, but can still be navigateddeeper

Figure 5.6: BrowseView User Navigation

• Whenever the list of attributes navigated through is added to, a request is made tothe server in which the list is passed to the server interface. Two lists are returned.One contains the names of the attributes and information items. The other list ofthe same size states what the corresponding items in the first list are, and of whattype they are in the context taxonomy.


(a) The available types to browsewhen ’Type’ is the first context se-lected

(b) The two contexts in whichfolders of messages can be navi-gated

(c) Browsing messages by sender

(d) The messages of an individualsender on an individual day

(e) Messages arranged by foldersof the sender where the time of themessages to retrieve has alreadybeen selected

Figure 5.7: BrowseView Navigation of Messages

• Whenever and item is removed from the list of attributes navigated through han-dle back will make the same request to the server that handle select does when anitem is added - it will pass the list of attributes navigated through to the server. Twolists are returned. One contains the names of the attributes and information items.The other list of the same size states what the corresponding items in the first listare, and of what type they are in the context taxonomy.

• The items are arranged in the correct order, folders first then any actual information


Figure 5.8: Photo Viewer

items. They are then displayed on the screen. The title of the application is alsoupdated to show the user where they are in the system.

• If handle select detects that an information item has been selected it will call theappropriate viewer.

ChangeModeView.py

When the user selects Batch / Continuous Mode from the main menu (PimText class) theuser is informed what mode they are in and whether their information items are beinguploaded as they acquire them or whether they are being stored in a queue and waiting forthe user to select “Make An Upload” from the main menu. If the user changes from batchto continuous they are asked whether they would like to clear the upload queue “now” orwait until the next information item is acquired.

ChangeUserView.py

When the user selects “Change User” from the main menu they are asked for the usernameand password to switch too. If the client cannot get verification from the server that the


new user exists then the error is communicated to the user and the user is informed whatthe current username that has just been reverted back too is.

IndexInboxView.py

This view becomes active when the user selects “Organise Inbox” from the main menu.Due to the fact that the user will have already acquired sms messages before they installedthe PIMText application it is necessary to index messages that are already on the phone.When the user asks for the inbox to be organised they are informed that indexing the inboxcan take a few minutes if they have over 500 messages and are required to confirm thatthey would like to proceed.

While the inbox is being indexed the user is displayed with the percentage of messagesthat have been indexed. The indexing process involves the phones message inbox beingiterated through and having the contextual information extracted. If the application is incontinuous mode the information about each message will be uploaded as it is obtained.If the application is in batch mode nothing will be sent to the server until the user selects“Make an Upload” or switches to continuous mode.

MakeUploadView.py

When the user selects “Make An Upload” the contents of the queue containing all theinformation items and associate context that has been acquired since the last upload willbe uploaded to the server. The user is presented with a percentage progress bar while theupload is taking place.

NoteView.py

When “Add Note” is selected from the main menu the user is presented with the appropriatetext fields to complete a note. The note will be saved is the user selects “Save” from themenu, otherwise the user will be asked if they would like to save the changes when theyexit the note view.

When the note is saved the type and location of the note is passed to a utility functionassociates the mobile devices location and time to the note. The note is then added tothe upload queue. The note will be uploaded as soon as possible if the application is incontinuous mode. If the application is in batch mode it will be uploaded when the userselects “Make an Upload” or switches the system into continuous mode.

PhotoView.py

PhotoView is activated when the user selects “Take Photo” from the main menu. It takescomplete control of the GUI of the device and presents the user with a viewfinder use to


(a) A completed personal notewith the option to save the note

(b) The PhotoView - Viewfinderin background, settings in theforeground

Figure 5.9: Data Acquisition Methods for Images and Notes

take photos. Enough functionality has been implemented to create a camera applicationthat is comparable to the devices camera application. The PhotoView class makes use ofthree classes from an opened sourced application, see section 5.3.2.

When a photo is taken the type and location of the photo is passed to a utility functionassociates the mobile devices location and time to the photo. The photo is then added tothe upload queue. The photo will be uploaded as soon as possible if the application is incontinuous mode. If the application is in batch mode it will be uploaded when the userselects “Make an Upload” or switches the system into continuous mode. When the userexists the “camera” all the GUI widgets are returned to their previous states.

OpenSourceCamera.py

An application was found from symbian freeware.com (2009) which contained suitablefunctionality for taking and storing photos on the device. The code for this application wasstripped of all unnecessary functionality and left with three classes, Keyboard, Camera andCameraView. Camera contained the functions to take photos and was extended so that thetype and filename of the photo is added to the upload queue so that the location and timecontexts can be associate to the photo. Keyboard maps keys to functions of the camera.CameraView was the interface to the camera.


ContextFunctions.py

ContextFunctions contains two methods. The first returns the current time in an array ofthe year, month, day, hour, minute and epoch.

The second method obtains a longitude and latitude from the devices “cell ID” through amethod of GSM localisation. The method takes advantage of the service providers networkinfrastructure to identify the location of the handset. In order to operate on the networkthe mobile device knows its cell identification number what location area code it is in. Themethod takes these two identifiers and sends them to a Google maps API that returns alongitude and latitude. The accuracy of this network based technique is closely depen-dent on the concentration of base stations, with urban environments achieving the highestpossible accuracy.

This method of GSM localisation was used instead of GPS positioning as many fewerdevices have GPS capabilities (GSM localisation techniques are much less intrusive). Alsoit was determined that the additional accuracy GPS provides would not be required.

StorageUploadFunctions.py

StorageUploadFunctions contains four method essential to the operation of the application:

• add to queue

Whenever an information item is acquired (a photo, a note or a message) the filenameand type are passed to this method. The relevant context is obtained at this point byusing methods from the ContextFunctions module (see section 5.3.2). A queue itemis then created that contains the file location of the information item, the type ofitem it is, all the relevant contexts (time, location etc) as well as the users usernameand password. The queue item is then added to “QUEUE” which is a private textfile that lists all of the items that need to be uploaded. At the end of the methoda check is made to see what mode the application is running in, if it is continuousmode, then batch upload is called to upload the queue straight away.

• batch upload

batch upload reads in the “QUEUE” of information items and the relevant detailsthat are waiting to be uploaded. As each item is removed from the queue it is passedto add to db that manages the uploading of both the file and the context. If add to dbuploads both the item and its details successfully then the item removed from thequeue. If not the information item and its details are left in the queue.

• add to db

add to db first tries to upload the information item by passing the file location toupload file, if it has been successful it calls the relevant server scripts to add therelevant information to the database.


• upload file

upload file takes the file location of the item to be uploaded and sends it to theappropriate server side script based on the file type.

SystemFunctions.py

SystemFunctions contains two functions that allow the systems GUI appearance to bestored and then restored later. They are used as the application moves from one view toanother and then back again. E.g. the GUI appearance of the application stored while themain menu is in use, just before the camera is loaded. When the camera is closed and thesystem wants to display the main menu again the GUI appearance is restored.

UserAccountFunctions.py

UserAccountFunctions contains all of the functions relevant to creating, selecting and usingan account for the system.

The methods include:

• Hashing passwords

• Reading user details from file

• Returning the stored username

• Returning the stored (hashed) password

• Saving using details

• Requesting account creation on the server

• Requesting a check for account validity from the server

5.4 Testing

The system that has been implemented has been developed as a proof of concept. Seesection 6 for a user evaluation.

For this reason there was no need to follow a strict test plan. Testing was still relativelyimportant as it enables determination of how close the system behaviour is to ideal be-haviour. Testing should be able to detect any deviations in behaviour that indicate thepresence of a bug.

Testing still took place, but on a smaller scale than a typical system.


5.4.1 Release of the System

Once the implementation had been completed to a sufficient level and it was suitable todistribute the system to users for testing the Python scripts were collected and a sis filecreated. A sis file is a single file that users can use to install the application on theirphone. For security reasons sis files cannot be installed onto a device without being signedby www.symbiansigned.com. Applications are defined by the capabilities that they have.The system implemented uses many lower capabilities, that, on their own would meanthat the system could be “self signed”. However GSM localisation was implemented withfunctionality that falls under the location capability, see section 5.3.2. This meant that theapplication had to be “developer signed” for testing. Every user that tested the applicationhad to supply their IMEI number. The application would then be signed using the IMEInumber supplied and sent to the appropriate device.

Users performed many tasks using the user guide and evaluation brief as the only doc-umentation to help them, see appendix D. As problems were reported at various stagesfeedback was obtained which guided additional implementation to fix the bugs. If appro-priate users were sent a new sis file. All of the new sis files could be installed without lossof the information items that the user had acquired, the improved applications were datacompatible.

If the system was to be publicly released and fully integrated into users mobile devicesthen a detailed test plan would need to be developed. The test plan would state how idealexhaustive testing would include a test case for every path through the system (white boxtesting). However this would be impractical so the aim would be to use black box testingto examine the behaviour of the system and select a set of test cases as close to the idealas possible.

5.4.2 Test Frameworks Used

SimpleTest for PHP

SimpleTest is a testing framework built around test case classes. Each test is written toinvoke assertions that is expected to be true of the system. If the expectation is correctthen a successful report is returned, if any tests fail a description of the failing assertion isreturned, see figure 5.10.

SimpleTest has been used on the server for both unit and integration testing. The functionsof the scripts are tested to ensure that the correct behaviour occurs each time and manyof the testing scripts can act as regression tests that can be used to determine any bugsintroduced when changes are made to the system. Examples of some of the testing carriedout are:

• A test user is added, tested for, removed, and tested again (it is asserted that theuser will not exist)


• The location scripts will be passed a predetermined longitude and latitude and it willbe asserted that they obtain certain location details

• A test information item will be added, tested for, removed, and tested again (it isasserted that the file will not exist), this test is an example of a test that determinesthe behaviour of the integration of many scripts.

Figure 5.10: SimpleTest Test Case Example

PUTools for Python and mobile devices

PUTools is a Python shell over Bluetooth with the ability to synchronise files between thedevelopment environment and the target mobile device. PUTools has been used to deployand test new Python code.

Testing has been conducted by automating testing units of functionality by testing variousfunctions. As stated previously, if the system was to be publicly released a more substantialtest plan would need to be produced that includes more testing, including substantialintegration testing.

As described in the system development above (section 5.3.2) the mobile application hasbeen broken into modules containing the classes for the tasks of the system. Test functionshave been created for each module that reside within the module but are not included whenthe application is wrapped into a sis file and released to a user.

Listing 5.1: Example Code extracted from a PUTools test scriptimport NoteView . py


NoteView . run puTest ( )

Listing 5.2: Example stack trace from a PUTools terminal windowTraceback ( most r e c ent c a l l l a s t ) :

F i l e ”c :\ r e s ou r c e \ h t t p l i b . py ” , l i n e 355 , in connectsocke t .SOCK STREAM) :

F i l e ”c :\ r e s ou r c e \ socke t . py ” , l i n e 229 , in g e t a d d r i n f o r h o s t =gethostbyname ( host )

IOError : [ Errno socke t e r r o r ] (0 , ’ g e taddr in f o f a i l e d ’ )

5.5 Conclusion

In this chapter the creation of the user-subjective PIM system has been successfully com-pleted, that is able to acquire photos and notes as well indexing the users inbox. Aneveryday information item has multiple contexts associated to it so that it can be retrievedby the user in the same context that it was acquired. Dynamic folder structures have alsobeen implemented that allow the user to take different routes in order to retrieve theirinformation based on the order they would like to navigate the context taxonomy. Theneed for folder categorisation (and the associated problems) has been removed. Thereforeuser does not need to maintain or create any folders in the location metaphor as the foldersare generated dynamically as the user navigates for items using subjective attributes asretrieval cues.

The system has now been successfully tested and packaged to a level that allows for theapplication to be distributed to users. An evaluation will now be carried out and analysedin the next chapter. Users will have the application running on their own devices for aperiod of days before returning feedback in the form of an interview discussion.

Chapter 6

User Evaluation

In the previous chapter, a new PIM system was implemented which uses a user-subjectiveapproach to PIM system design. Key problems associated with PIM retrieval such as thelack of control over the environment and therefore lack of control over the way informationis managed have also been addressed. This has been done by implementing a system inwhich folder hierarchies are created dynamically (a dynamic implementation of the locationmetaphor, see section 2.5), so that the user can browse for the information item they wishto retrieve using the context the item was last used in. All of the information items underthe control of the system are classified in many different groups depending on the contextsurrounding the information item. The items are also grouped by context no matter whatthe type of file is.

Evaluation has already occurred throughout the design phase, where numerous prototypeswere created to answer questions regarding the initial design and to support early designdecisions 4.1.1.

Now that the system has been ’signed’ and packaged for installation on users mobile devices,it is suitable to perform a final user evaluation for this project. A user evaluation of thefinished application is important to ensure users’ needs have been taken into account duringthe development process whilst attempting to improve personal information retrieval.

The fact that personal information, by its definition, is personal and frequently occurs intransit means that it is appropriate for the evaluation to occur in the natural settings of amobile PIM system. The natural environment for a mobile PIM application involves theuser running the application on their own device and over a period of time to be able toexperience situations in which the new system can be used to its full potential.

This evaluation is carried out to ensure that users can successfully use the product, (includ-ing features such as the mechanisms by which to retrieve information) and to determinetheir views on certain aspects and the system as a whole.

85

CHAPTER 6. USER EVALUATION 86

6.1 Objectives

The primary objective of the evaluation is to determine whether there is any value in theideas that have been implemented, including dynamic use of the location metaphor tocreate a user-subjective PIM system. The derived objectives can be summarised as, to:

• Determine whether the system built is capable of being used intuitively, i.e. the userwill only have been required to read the user manual when initially installing theapplication (see requirement 24).

• Determine the positive features of the concepts that have been implemented, i.e. theuser-subjective approach at the centre of the PIM system that implements a dynamiclocation metaphor in which information can be retrieved by the same context it waslast used.

• Determine the negative features of the concepts that have been implemented.

• Determine the success of the physical design in implementing the solutions to thePIM retrieval problems.

• Determine any aspects of the implementation that users feel could be changed orextended.

• Determine if the implementation was useful in performing daily PIM tasks.

6.2 Questions Asked and Data Collected

As the user evaluation is not in the form of an experiment, there are no hypotheses whichare required to be proved. Instead, a series of questions will be put to users of the systemwho have at least a week’s experience of the application on their mobile device. To ensurethat the users are not put into a particular mindset, the interviews will start with a freequestion and became more specific as the interview develops. This ensures that the pointsraised by the users have not been influenced.

Due to the constraints of the project, a “quick and dirty” approach to evaluation will beused (Preece, 2002), to obtain the feedback from the users. The use of a semi-structuredinterview is hoped to be highly informative and the data collected descriptive and informal,documented using a series of notes. The questions that will act as a guide for the semi-structured interview are listed below, although the interviews are flexible and new questionsmay be brought up as a result of what the interviewee has said. In general, the questionsbelow will be used in order to start a thread of questions, that can branch off until it isdeemed necessary to return to the question guide.

• How did you find the system to use?


• Did you find any problems when using the system?

• Were there any points at which it was unclear how to use the system to retrieve aninformation item?

• What were your favourite aspects of the system and why?

• Is there anything that you would like the system to include that it does not already?

Following the completion of these interviews, the procedure taken and the results foundcan now be outlined.

6.3 The Participants

The participants involved in the evaluation were found from asking a selection of users fromthe data gathering questionnaire (section 3.1.3), who had stated that they were happy tobe contacted in the future for an evaluation of a new system as well as taking part inprototype evaluations. As some of the participants were involved in both evaluations, itwas possible to gain an insight into how user expectations had been managed.

The only constraint on selecting participants (other than the fact that they left contactdetails indicating that they would be happy to be contacted later) was that they must owntheir own Nokia or Samsung mobile device that runs on the Symbian platform. This wasdue to the fact that the client application was built specifically for this platform. Due tothe nature of PIM, a user evaluation of the system would only be suitable if users were ableto use the system in a natural environment and therefore use the features of the system forthe acquisition and retrieval of their own personal information.

6.4 The Procedure

As Symbian applications need to be signed before they can installed on consumer phones,the participants were contacted in order to obtain their IMEI numbers. The applicationswere then signed so that they would only work on the individual devices that they werelinked to.

The application installation file was then sent to the users with the appropriate user manual(see Appendix D) that not only described how to use the system but explained what thesystem was for. Once it had been determined that installation and account creation hadbeen successfully completed, the users were left to use the system for a week in their naturalenvironment.

After approximately a week, the users were contacted as arranged and the semi structuredinterview took place, the results of which can be seen below.


6.5 Results and Analysis

This results section illustrates the findings of the user evaluation. All of the feedback wascollected in the users own words through an interview format (whether in person or overthe phone).

In order to analyse the results effectively, comments were collected from all participants ofthe study and are collaborated below by theme. These themes are explained by how thekey points from each interview were understood. This interpretation can be considered rea-sonably accurate, with the comments from users gathered directly during a semi-structuredinterview that was flexible and allowed new questions to be asked. For example, in orderto clarify any points that had been made.

6.5.1 Adaption of Location Metaphor

In general, the dynamic nature of the system’s directory structure was seen as a positivefeature. Users were able to use different attributes at different times, or multiple attributesat the same time to effectively retrieve the information they were trying to find. Responsesincluded: “Its great that I don’t have to type things in on the phone” and “the foldersmeant that it didn’t take me ages to find my text messages or photos”. Users stated howthey could go “straight there” instead of having to scroll through long lists of items. Usersalso appeared to have no problems getting used to the location and time taxonomies usedto organise the information in various hierarchies.

On the whole, retrieval of information on the mobile devices involved less effort for theuser than they were previously used to. One user, however, made the remark that “Iknow that my picture was taken in Loughton, [a town, therefore near the bottom of thelocation taxonomy] but I have to go to UK, Essex, Epping Forest before I am in Loughton”.Overall, it would appear that the predefined levels of context attributes, (e.g. country,county, city and town) have been suitable for the majority of users, with one user stating“I like the way the folders are broken down, they remind me what I’ve done. . . also I don’thave to remember the exact place it was stored on the phone”. However, there were toomany location attributes for one user which meant they became annoyed with having tonavigate down four folders even though they knew that the item they were looking forwas “Loughton”. This raises an important issue related to what the system was in partdesigned for; to deal with the problems associated with lack of control over the environmentdue to the fact that static directories can remove control (Cai et al., 2005). Arising fromthis point is also the issue of whether the function allocation of the system was correct.Due to the majority of positive responses, it would appear that it was. However, theorganisation of folders for retrieval could move along the Parasuraman et al. (2000) scale ofhuman-machine function allocation by allowing users to change the default attributes thatare used in creating the directory structure. For example, a user could remove the countrylevel from (or add a postcode level to) the location taxonomy.


A couple of users also noted how navigation of the hierarchy was much like using musiclibrary software, in which they could browse by different attributes of the music dependingon how they wanted to retrieve their music. This shows that the choice of context forretrieving information items (location, time and sender) is appropriate for the system asthe context is relevant to the items, just as attributes such as artist, album and genre arerelevant to music items.

6.5.2 Reduction in Organisation Effort

It was noted by a fair percentage of users that they “didn’t have to care about where tosave the file”, being able to rely on the system to categorise their information for them andlearning that they would be able to retrieve the information in the same context in whichit was used. Messages were especially praised. Users were extremely fond of not having tocreate copies, or move messages just so that the content of the message would not get lostin a huge list of messages. Users were impressed that no matter how many messages theywere receiving (or photos they were taking), they did not think that they would encounterany issues retrieving the items again as they would just be able to navigate to roughly thecorrect area, usually about half way down the appropriate taxonomy, such as a sender, cityname, or month and then be able to refine their navigation choices once they had seen thenext set of available options.

6.5.3 Ease of Usability, But Lack of Integration

Additionally, many users commented on how easy the system was to navigate; “when inthe system I was able to find my way around the different parts”. It seems apparent thatmoving around the different areas of the application was not an issue. However, users notedthat they “had to use the new camera application” or they “kept forgetting to write thenotes in the new application”. These results suggest that the system appears to requireintegration with the native applications of the mobile device in order to remove these issues.Integration would also help to include of all information items that were acquired on thedevice. Integration would be possible on the same devices if native Symbian C++ wasused for development. However, as stated in the feasibility study, it was not suitable forthis project due to the time constraints, the steep learning curve and the special techniquesrequired.

6.5.4 Increased Use of Retrieval Tasks

Many users also commented on how they found they were able to confidently attemptto retrieve information items. There were responses such as “I have been able to showeveryone the pictures I have been taking - the new application means that I know I shouldbe able to find my pictures again quickly”.


Retrieval of sms messages was stated by most users as being the task that they had increasedperformance of the most. Many users were rather positive about the idea that they couldto access their existing messages in ways that they had never been able to in the past. “Ihave been pulling up stuff that I was looking for not only a couple of days ago, but I’vebeen able to retrieve things that I knew was stuck in old messages”. After further questionsit was determined that these items were often over a year old. “For example I knew thepassword to the wireless router was in a message rick sent me last year, but I never scrolledthrough the 1000’s of messages to find it. The system let me browse by month, person orboth, I found that really great”.

6.5.5 Physical Implementation Bugs

Users of different devices noticed varying problems with certain aspects of the implementa-tion. Issues were frequently raised with camera related functionality on certain devices butnot on others. “the picture appears to take, and its stored in the right place in the locationand time folder, but when I open it, it’s just a black image” - but users with different devicemodels did not experience these issues.

A notable bug, that would mean that requirement 21 is not satisfied, is that especiallylong sms messages are not being represented as they should be. Whilst users were able tolocate and open the messages, if the message length was larger than that of one standardmessage, the message viewer would only display the first 160 characters. Although this isa serious issue as user information has (as far as the user is concerned) been altered, only asmall percentage of evaluation users were affected. However, those affected have not beenimpeded from using the location and retrieval mechanisms and the issue would only requirea minor code fix to resolve.

It was also noted that some tasks such as making a batch upload or connecting to theserver to be able to browse should provide more messages detailing what the system wasdoing. For example, one user noted: “I didn’t realise it was still uploading, I was browsingfor my items and I did not realise that the upload had not finished yet, it didn’t take longto upload, but I was confused as to why the browse tool did not have all of my items atfirst”.

A final interface note is that although information items were distinguishable from thecontext in which they were being retrieved, i.e. it was possible to tell the type of file, whenit was last used and where it was last used, the icon for the file itself could have been used,especially for messages and notes to preview the actual content.

6.5.6 Overlooked Features

As seen above, navigation of the dynamic hierarchy was well received, enabling users to beable to retrieve their information items efficiently using the interface the system providedto the hierarchy. However, one user commented on the fact that although they did not


find the navigation concept difficult they suggested that the interaction of the system couldbe improved so that they would be able to go back up the hierarchy without launching amenu. After brief investigation, it was discovered they had not read the user manual andthe section in which the dedicated keys were described. The user was pleasantly surprisedwhen they were told that this feature was already in place. Even though the dedicated keysfeature was not intuitively discovered, it was encouraging to see that the core functions ofthe system could be discovered and used without the need for any user manual.

6.6 Conclusion

In general, the feedback received in the evaluations has been positive. It has been deter-mined that the system created has been able to be used intuitively and the system waseven used by one participant who had not read the user manual at all - although dedicatedfunction keys were not determined.

Several features of the system received positive feedback, most notably, the ability toretrieve messages using the location metaphor with different contexts and users statingthat although they did not need to actively consider where items were going to be saved,they felt in control of the environment and how the information was being managed.

Negative feedback included bugs in the detail of the physical design and certain areaslacking in system status updates. Despite the bugs identified, the physical design itselfwas reasonably well received. One user even stated that after using the application for areasonable amount of time, they found themselves attempting to use two of the dedicatedfunction keys within other applications on their mobile device.

Regarding the success of the system in performing daily PIM tasks, the system was foundto be useful in what it did. However, this did not cover all aspects of users PIM tasks withonly photos, notes and message data types available for use in the system.

Overall, it is clear from the results, that the system appears to have some value in havingimplemented a user-subjective PIM system. Following this evaluation, it is now appro-priate to conclude this project; summarising the work undertaken, the relationship to theliterature concepts and the success of the system in terms of the original requirements.Work with the potential to be considered in future will also be discussed.

Chapter 7

Conclusions

Now that the system has been implemented and the user evaluation has been successfullycompleted, with analysis of the feedback received, it is possible to conclude this projectwith a summary of the work that has been undertaken and its relationship to the keyconcepts that were raised during the literature review. The strengths and weaknesses ofthe project are also identified with an outline of potential work that could be consideredin the future.

7.1 Project Summary

Overall, a user subjective PIM system has been created in which dynamic folder hierarchiesassist users in the retrieval of their personal information items within the context thatthey were last used. A taxonomy of context types have been combined with the locationmetaphor in order to provide a natural method by which users can find the informationthat they require. As PIM, by definition, is personal and frequently managed in transit,the system is implemented on a mobile device in order to not only aid retrieval but harnessthe relevant context of the environment.

This project began with an investigation of the problem domain and the establishment ofthe main aims and objectives of the project. A literature review was then conducted inorder to explore the origin of PIM and its current problems. Following this, the scope of theproject was redefined with methods for retrieving personal information explored in furtherdetail. Finally the potential benefits of using the location metaphor and a user-subjectiveapproach were considered.

The results of the literature review in conjunction with a user questionnaire were thenused to extend the objectives of the project and provide an initial list of requirements.Through the use of iterative design-evaluation-redesign cycles with low-fidelity prototypingat a conceptual and physical level, a system was provisionally designed with the ability toretrieve information based on the context in which it was last used and classify information

92

CHAPTER 7. CONCLUSIONS 93

using dynamic directory structures that utilise the location metaphor.

This design was then implemented creating functions by which a user’s inbox could beindexed and both notes and photos acquired on a mobile platform. Initial testing was thencompleted followed by the distribution of the application to several users, who were requiredto gain experience running the system for at least a week. A follow up evaluation was thencompleted in the form of a series of semi-structured interviews with each individual user.These results will now be used here to determine the success of the system and its relationto the original concepts.

7.2 Relationship to the Literature Concepts

Recall that the key concepts in this problem domain were identified in the literature reviewto be that:

• Personal information is personal (user-subjective) and has been acquired by the user.This information will only serve one user and should therefore make use of the avail-able subjective attributes.

• There are problems when folders are used for storage. Most notably the categorisationfor the content of the folder. Users can find it difficult to choose the appropriate folderto store the information item as well as finding it difficult to create the folder initially.Users do not want to lose control over the environment.

• Whilst there are categorisation issues, navigation of folders is still overwhelminglypreferred to search where personal information is concerned.

• The location metaphor is entirely metaphoric. Location is not a location at all, buta convenient way of organising information because users like to know where theirinformation is stored. In the same way that it seems natural to the user to storeitems in physical locations.

It is important to link the results found from this project back to these concepts in orderto determine the implications for PIM systems in a mobile context.

7.2.1 User-Subjective Personal Information

Bergman et al. (2003) developed the idea of a user-subjective approach to PIM systemdesign, which focused on several of the current limitations with PIM. These included thefact that many PIM systems fail to decrease the load on memory and facilitate retrieval aswell as missing the fact that personal information is personal and therefore the attributesof the system will be “episodic and idiosyncratic” in nature - valuable to the user butmeaningless to others.


Throughout the project this idea has been a key focus; the system itself has been designedwith a user-subjective approach in mind, following two of its main principles:

1. Subjective Classification: The system was designed so that all information itemsrelated to the same subjective topic, such as the time, location or sender of theinformation are classified together regardless of their technological format.

2. Subjective Context: The system has been designed so that information can be re-trieved and viewed by the user in the same context it was previously used. For ex-ample using salient cues such as the sender of the information, the location in whichthe information was acquired and the time at which the information was obtained.

During the evaluation it became clear that the ability of the system to retrieve informationitems in the context they were last used was a feature that was well received by the users.It was also illustrated that information items were discovered by the users that mightotherwise have been lost in the categorisation of the folders in the file system. This thereforeconfirms Bergman et al.’s (2003) claim that PIM system design needs to be subjectivebecause, unlike general information management, acquisition, organisation and retrieval ofpersonal information is carried out by the same person.

7.2.2 Storage and Organisational Problems

Kidd (1994), Malone (1983) and Whittaker and Sidner (1996) stated that information canbe hidden from the user due to its classification and therefore reduces the chance of quickretrieval or reminding. Users can find categorisation challenging and therefore hard tocategorise information that could be stored in more than one category. Cai et al. (2005)explain how this problem can occur due to a mismatch between the current organisationof data and the organisation that is required to naturally support services which is causedby static directory hierarchies.

This has been incorporated throughout the project as all information acquired or indexedin the new system appears to the user as if it is stored in all of the appropriate categories.Issues of data redundancy are avoided as there are not actually multiple versions of thedata, but categories that are created dynamically as the stores or attempts to retrieve theinformation item.

The evaluation showed that users embraced this feature and utilised the fact that they didnot have to worry about categorisation as it would be taken care of automatically, with theirphotos, notes and messages available for retrieval in many different places. This thereforeconfirms the findings from Cai et al. (2005) that static directory structure removes controlover how the information can be managed.


7.2.3 Preference For Navigation

It was concluded by Bergman et al. (2008) that there is an overwhelming preference fornavigation methods over search and a need to develop more sophisticated models of relationamong navigation and retrieval. Bergman et al. (2008) stated that the preference fornavigation may be due to the fact that navigation is based on recognition and requires lesscognitive effort than recall (which forms the basis for searching).

These ideas have been incorporated into the design of the system. During the prototypingstage, a variety of designs were presented to the users that included navigation, filtering andsearch methods. Out of all the possible approaches, navigation based designs received thebest feedback from the users. In the final system that has been implemented, navigationis the only method available by which users can retrieve their personal information.

In the evaluation it was shown that users could successfully exercise the navigational tech-niques to traverse the organisational hierarchy until the location that contained the desireditem was found. This showed that users were able to retrieve information items successfullyeven though they did not know its exact location. This, when combined with the results ofthe prototyping confirm Bergman et al.’s (2008) findings that navigation is the preferredmethod of retrieval in PIM systems.

7.2.4 The Location Metaphor

Within a file system, the items stored are not physically within folders, however as Cutrellet al. (2006) and Jones et al. (2005) state, folder organisation serves as a useful way toconceptualise information. The use of the location metaphor works well because it seemsnatural to the user.

The idea of a location metaphor is vital to this project and forms the core of the implemen-tation; dynamic folder organisation is generated as the user retrieves information items.The folders to be displayed will be chosen based on the navigational route that has beentaken through the folder structure.

It was found in the evaluation that users had no problem using this approach. The dynamiclocation metaphor implemented was found to ease the cognitive effort required by the userto find and select information. An example of this was that large lists of items werebroken down into various manageable classifications, derived from a taxonomy of contexttypes. This confirms Jones et al.’s (2005) view that a user’s personal information foldersrepresent an emerging understanding of the information within. As people naturally dealwith locations in the physical world, they are familiar with the concept that things existin a spacial relationship to one another and so find this approach easy to pick up.


7.3 Strengths and Weaknesses

In addition to relating the work undertaken in this project to the key concepts of theexisting literature, it is also necessary to consider the overall success of the system througha comparison to the requirements that were intended to be fulfilled and the identificationof any notable strengths and weaknesses that it possesses. Determining any weaknesses ofthe project will also allow the future directions of this work to be successfully recognised.

7.3.1 Comparison to Requirements

Due to the fact that interaction design is iterative the requirements initially stated havebeen modified as feedback has been received, for example during the prototype iterations.Therefore, whilst it is not appropriate to consider the achievement of all specified require-ments, those considered key to the project will be briefly examined here. Where require-ments have not been completely met, they are instead discussed in the appropriate sectionsfollowing this such as Weaknesses and Future Work. This will help to avoid repetition.

1. The system must only show personal information to its owner

This requirement has been successfully implemented through the use of a user login whichsecures personal data to the appropriate username.

2. The system must be able to acquire photos

This requirement has been successfully implemented through the use of a camera module.

3. The system must be able to acquire notes

This requirement has been successfully implemented through a note creation and viewingmodule.

5. The system must be able to assign time context to all acquired informationitems

This requirement has been successfully implemented through a context function that ac-quires the current time.

6. The system must be able to assign location context to all acquired informa-tion items apart from sms messages

This requirement has been successfully implemented through a series of context functionsthat acquires the current cell identification of the network, translates it into a longitudeand latitude before storing in a taxonomy of locations.

8. The system must behave like a regular file hierarchy, folder navigation systemthat implements the location metaphor

This requirement has been successfully implemented as the “Browse” view of the systemallows the user to navigate dynamically generated folder structures.


9. The system must be able to go backwards and forwards (up and down thehierarchy) when navigating for retrieval

This requirement has been successfully implemented as users are able to go up and downthe dynamically generated folder structure.

10. The system must always tell the user where they are in the folder hierarchyas they are navigating

This requirement has been successfully implemented as the “Browse” view changes thetitle of the application to display where the user is in the dynamically generated folderstructure.

11. The system must implement the 3 principles from Bergman et al.’s (2003)user-subjective approach to PIM system design

It was decided in the design stage that two out of the three main principles would beimplemented, which has been completed successfully. See Weaknesses, section 7.4, for adiscussion of the third.

12. The system must allow the user to retrieve an item using time as a retrievalcue without needing to recall the exact time the item was acquired

This requirement has been successfully implemented as users are able to find items bynavigating the time classification.

13. The system must allow the user to retrieve an item using location as aretrieval cue without needing to recall the exact location the item was acquired

This requirement has been successfully implemented as users are able to find items bynavigating the location classification.

14. The system should allow the user to use multiple context information to beable to retrieve their information items

This requirement has been successfully implemented as users are able to find items bynavigating both the time and location classification at simultaneously.

15. The ’folders’ of the location metaphor must not exclude / hide any data

This requirement has been successfully implemented as users are able to find all of theirinformation items when the correct context is used.

17. The system must be extensible for adding further data types

This requirement has been successfully implemented as the generic nature of the designand implementation allows for additional types to be included.

18. The system must be extensible for adding further context types

This requirement has been successfully implemented as the nature of the database structuremeans that additional context types can be added without much effort; by creating tablesthat reference the context table.


20. The system must support different types of data

This requirement has been successfully implemented as the system can deal with photos,notes and sms messages.

22. The system must be able to be used wherever a mobile device is used toacquire or retrieve information

This requirement has been successfully implemented as an application has been createdthat can be installed and run on Symbian S60 devices.

23. The system should be able to cope with multiple users, but asynchronously- each users data must be kept private from other users view

This requirement has been successfully implemented as the user login prevents access toother user’s data, whilst allowing multiple users to access their own information on thesame device.

24. The System must be able to be used without ’live’ support

This requirement has been successfully implemented as the evaluation illustrates users wereable to utilise the functionalities of the system on their own with only the initial manualavailable for guidance.

25. The system must be able to run on mobile devices

This requirement has been successfully implemented as an application has been createdthat can be installed and run on Symbian S60 devices.

26. The system must use language and terminology that is appropriate for usersfamiliar with basic handheld mobile devices

This requirement has been successfully implemented as the evaluation illustrates users hadno difficulty understanding how to use the functionalities of the system.

29. The system must provide the user with appropriate information on thecurrent system state

This requirement has been successfully implemented as the title of the application adjuststo inform the user of their location both in the system and within the dynamic directorystructure.

30. The system must prevent errors and deal with any issues as soon as possible

This requirement has been successfully implemented as the system takes advantage ofvarious exception handling techniques and deals with the worst case scenarios by safelyclosing the system with appropriate error messaging.

31. It must be easy to navigate the hierarchy when retrieving personal infor-mation. The movement around the system must be unambiguous

This requirement has been successfully implemented as the evaluation illustrates the feed-back of the user’s experience of navigating the hierarchy as positive.


It is clear from both the user evaluation and the number of successfully fulfilled requirements(especially of those at priority 1 and 2) that the system has achieved the goals that haveevolved during the project.

7.3.2 Strengths

It is clear that the system that has been designed and implemented holds several strengthsas a new PIM system.

Firstly, the system successfully implements and explores the main concepts that were iden-tified during the literature review. The design-evaluation-redesign cycles that have takenplace harnessing users’ thoughts and ideas of the system, mainly through prototype itera-tions, have ensured that the system implemented was focused towards their needs.

It has also become clear from the user evaluation conducted that the following functionalityof the concepts used were well received:

• The ability to retrieve items using the context they were last used in

• The ability to use a combination of contexts to retrieve items

• The ability to index the inbox of the device and navigate received messages usingorganisations that were not previously available

• The ability to navigate directory structures intuitively using functionality such asdedicated left and right buttons to move the user up and down the hierarchy

• The ability when navigating to see all items below the current level in the hierarchyand still be able to navigate further, removing irrelevant items

Finally, the implementation and evaluation conducted within this project have allowed theideas surrounding the main concepts, identified in the literature review to be confirmed.

7.3.3 Weaknesses

Several weaknesses of the project should also be noted, specifically where it has beeninfeasible to meet requirements, which are outlined below with recommendations for howthese could be met in future work where appropriate.

4. The system must be able to organise incoming sms messages

Symbian applications are required to be signed before they can be publicly released. In thecase of this project, the scripts have been wrapped into an installation file and “developersigned” 5.4.1. Even though developer signing has allowed the application to perform themajority of its tasks, it is not possible to have the application running robustly in the back-ground of the device, handling messages. This is due to the security constraints Symbian


place on 3rd party applications. This functionality could be implemented if the system wasto be extend and released publicly.

19. The system must work on the users most up-to-date personal information

Due to the inability of fulfilling requirement 4 above, the system was unable to work onthe most up-to-date list of user messages without “re-indexing”.

21. The system must present any information retrieved with 100% accuracy

This requirement has been fulfilled to the extent possible within the time constraints ofthis project. As noted in the evaluation long sms messages were incomplete due to theunforeseen limitations of the widget used. In future work it would be feasible to considerextending this widget to cope with longer sms messages.

28. The system must provide the user with appropriate, meaningful feedback

Overall, the system has provided appropriate feedback. However, as noticed in the userevaluation, there are times at which the system is processing in the background, whilstallowing the user to continue interacting with GUI. This could be improved by the selectionof appropriate status indicators and the further use of system locking.

7.4 Future Work

In addition to the recommendations for removing weakness in the system, the followingaspects could also be considered as extensions and enhancements to the current function-ality. These are firstly related to requirements that have not been successfully fulfilled andthen extended to work outside the scope of the project.

7. The system must be extensible for multiple platforms

This requirement has only partially been met. The server would be extensible as any deviceis able to make and receive http requests. However, to be able to move the client applicationto multiple platforms, multiple ports of the code or re-writes would be required. A possiblebenefit of using multiple platforms with the same server would be that information acquiredon one device could be retrieved using another

11. The system must implement the 3 principles from Bergman et al.’s (2003)user-subjective approach to PIM system design

As previously noted, only two of the three principles have been successfully implementedwithin this project. The remaining principle; Subjective Importance was chosen not to beimplemented as the determination of the importance of information and then the assign-ment of a suitable visual salience as well as the design and implementation of the othertwo user-subjective principles would be outside the scope of this project. In the currentsystem, dynamically generated folders representing context attributes always remain atthe top of the screen while they are still applicable, then the actual information items arelisted below. A future development of the system could be to implement the Subjective


Importance principle of Bergman et al.’s (2003) user-subjective approach by investigatinginformation ranking techniques.

In addition to fulfilling these requirements the following extensions can also be noted:

• Adding further contexts: Allowing users to be able to navigate for information itemsusing additional contexts. This could add value to the retrieval mechanism. Anexample might be the people present when acquiring or using the information. Apossible implementation of this might use Bluetooth technology to recognise who isin the vicinity as information is stored.

• Adding further data types: PIM is not confined to photos, messages and notes.The system could be extended by adding further PIM information types, such asappointments, documents and videos. This could also add value the overall user-subjective system.

• Integration with the device’s native applications: If the system was to be released toa wider audience it would be sensible to ensure that the system could add contextto information items acquired using the device’s native applications. For examplea camera or calendar application. This should increase the potential usage of thesystem.

• User setting to determine taxonomy levels used: As noted by one user in the evalua-tion, they may not want to navigate through context attributes that they know theresult of. An enhancement of the system would be to allow the user to change thecontext attributes that are included in the folder structure and therefore adjust thedepth of the navigation. This could improve the efficiency of retrieval, for examplea user could choose to by-pass country and county attributes - UK, LONDON andSOUTHWARK to just SOUTHWARK.

• Adding backup functionality: An extension outside of the scope of the project wouldbe to utilise the server of the system in a backup capacity. This would add value tothe system.

7.5 Summary

Overall, it is clear that the system implemented has been successful in fulfilling the require-ments of the project. The system produced has not only received positive feedback butallowed the main concepts of the literature in this problem domain to be confirmed. Ulti-mately, the system has verified Bergman et al.’s (2003) assertion that PIM system design“clearly needs to be subjective”. It has also provided further information regarding Storageand Organisational Problems, the Preference For Navigation and The Location Metaphor.

The system has shown a positive move towards Teevan and Jones’s (2008) ideal that thereis always the correct information, in the correct place, in the correct form, with adequate


completeness and quality to meet the current need as the system enhances the efficiencyof performing retrieval techniques. It is hoped, that by completing the extensions outlinedfor future work this ideal could become a reality.

Bibliography

A.D., B. (1982), ‘Domains of recollection’, Psychological Review 89(6), 708–729.

Bainbridge (1983), ‘Ironies of automation’, Automatica pp. 775–79.

Barreau, D. and Nardi, B. A. (1995), ‘Finding and reminding: file organization from thedesktop’, SIGCHI Bull. 27(3), 39–43.

Bellotti, V., Ducheneaut, N., Howard, M., Smith, I. and Grinter, R. E. (2005), ‘Qualityversus quantity: e-mail-centric task management and its relation with overload’, Hum.-Comput. Interact. 20(1), 89–138.

Bennett K.B., F. J. (1992), ‘Graphical displays: implications for divided attention, focusedattention and problem solving’, Human Factors pp. 513–33.

Bergman, O., Beyth-Marom, R. and Nachmias, R. (2003), ‘The user-subjective approach topersonal information management systems’, J. Am. Soc. Inf. Sci. Technol. 54(9), 872–878.

Bergman, O., Beyth-Marom, R., Nachmias, R., Gradovitch, N. and Whittaker, S. (2008),‘Improved search engines and navigation preference in personal information manage-ment’, ACM Trans. Inf. Syst. 26(4), 1–24.

Blandford, A. E. and Green, T. R. G. (2001), ‘Group and individual time managementtools: What you get is not what you need’, Personal Ubiquitous Comput. 5(4), 213–230.

Brown, P., Carter, K., Eldridge, M., Flynn, M., Lamming, M., Louie, G., Robinson, P. andSellen, A. (1994), ‘The design of a human memory prosthesis’, The Computer Journal37, 153–163.

Bush, V. (1945), ‘As we may think’, The Atlantic Monthly .

Cai, Y., Dong, X. L., Halevy, A., Liu, J. M. and Madhavan, J. (2005), Personal informationmanagement with semex, in ‘SIGMOD ’05: Proceedings of the 2005 ACM SIGMODinternational conference on Management of data’, ACM, New York, NY, USA, pp. 921–923.

103

BIBLIOGRAPHY 104

Chapanis, A., Frick, F. C., Garner, W. R., Gebhard, J. W., Grether, W. F., Henneman,R. H., Kappauf, W. E., Newman, E. B. and Williams, A. C. (1951), Human engineeringfor an effective air-navigation and traffic-control system, Technical report, Ohio StateUniversity, Washington, D.C.

Cook C., C. C. (2001), ‘Function allocation: Optimising the automation boundary’, SystemsDependency on Humans, IEE One-day Seminar .

Cutrell, E., Dumais, S. T. and Teevan, J. (2006), ‘Searching to eliminate personal informa-tion management’, Commun. ACM 49(1), 58–64.

Dumais, S., Cutrell, E., Cadiz, J., Jancke, G., Sarin, R. and Robbins, D. C. (2003), Stuffi’ve seen: a system for personal information retrieval and re-use, in ‘SIGIR ’03: Pro-ceedings of the 26th annual international ACM SIGIR conference on Research anddevelopment in informaion retrieval’, ACM, New York, NY, USA, pp. 72–79.

Falke, E. (2008), The associative pda 2.0, in ‘CHI ’08: CHI ’08 extended abstracts onHuman factors in computing systems’, ACM, New York, NY, USA, pp. 3807–3812.

Fertig, S., Freeman, E. and Gelernter, D. (1996), “‘finding and reminding” reconsidered’,SIGCHI Bull. 28(1), 66–69.

Gwizdka, J. and Chignell, M. (2004), ‘Individual differences and task-based user inter-face evaluation: a case study of pending tasks in email’, Interacting with Computers16, 769–797.

Hancock P.A., S. S. (1998), ‘Allocating function in human-machine systems’, AmericanPsycological Association .

Heath, C. and Luff, P. (1991), Collaborative activity and technological design: task coordi-nation in london underground control rooms, in ‘ECSCW’91: Proceedings of the sec-ond conference on European Conference on Computer-Supported Cooperative Work’,Kluwer Academic Publishers, Norwell, MA, USA, pp. 65–80.

Jones, W. (2007), Keeping Found Things Found: The Study and Practice of PersonalInformation Management, Morgan Kaufmann.

Jones, W., Phuwanartnurak, A. J., Gill, R. and Bruce, H. (2005), Don’t take my foldersaway!: organizing personal information to get ghings done, in ‘CHI ’05: CHI ’05extended abstracts on Human factors in computing systems’, ACM, New York, NY,USA, pp. 1505–1508.

Kidd, A. (1994), The marks are on the knowledge worker, in ‘CHI ’94: Proceedings of theSIGCHI conference on Human factors in computing systems’, ACM, New York, NY,USA, pp. 186–191.

Kobayashi, M. and Takeda, K. (2000), ‘Information retrieval on the web’, ACM Comput.Surv. 32(2), 144–173.

BIBLIOGRAPHY 105

Lakoff G., J. M. (1980), Metaphors We Live By, University of Chicago Press, Chicago, IL.

Lamming, M. and Flynn, M. (1994), Forget-me-not: intimate computing in support ofhuman memory, in ‘Proceedings FRIEND21 Symposium on Next Generation HumanInterfaces’.

Lansdale, M. (1988), ‘The psychology of personal information management’, Applied Er-gonomics 19(1), 55–66.

Malone, T. W. (1983), ‘How do people organize their desks?: Implications for the designof office information systems’, ACM Trans. Inf. Syst. 1(1), 99–112.

Parasuraman, R., Sheridan, T. and Wickens, C. (2000), ‘A model for types and levels ofhuman interaction with automation’, Systems, Man and Cybernetics, Part A, IEEETransactions on 30(3), 286–297.

Perry, M., O’hara, K., Sellen, A., Brown, B. and Harper, R. (2001), ‘Dealing with mobil-ity: understanding access anytime, anywhere’, ACM Trans. Comput.-Hum. Interact.8(4), 323–347.

Piaget (1928), Judgement and Reasoning in the Child, Routledge and Kegan Paul, London,UK.

Preece, R. S. (2002), Interaction Design: Beyond Human Computer Interaction, Wiley.

Robertson, S. and Robertson, J. (1999), Mastering the Requirements Process, Addison-Wesley Professional.

Segal, R. B. and Kephart, J. O. (1999), Mailcat: an intelligent assistant for organizinge-mail, in ‘AAAI ’99/IAAI ’99: Proceedings of the sixteenth national conference onArtificial intelligence and the eleventh Innovative applications of artificial intelligenceconference innovative applications of artificial intelligence’, American Association forArtificial Intelligence, Menlo Park, CA, USA, pp. 925–926.

Shannon, C. E. and Weaver, W. (1963), A Mathematical Theory of Communication, Uni-versity of Illinois Press, Champaign, IL, USA.

Shneiderman, B. (1997), Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA.

symbian freeware.com (2009), ‘S60 viewfinder’. http://www.symbian-freeware.com/download-view-finder.html.

Teevan, J., Alvarado, C., Ackerman, M. S. and Karger, D. R. (2004), The perfect searchengine is not enough: a study of orienteering behavior in directed search, in ‘CHI’04: Proceedings of the SIGCHI conference on Human factors in computing systems’,ACM, New York, NY, USA, pp. 415–422.

BIBLIOGRAPHY 106

Teevan, J. and Jones, W. (2008), The disappearing desktop: pim 2008, in ‘CHI ’08: CHI’08 extended abstracts on Human factors in computing systems’, ACM, New York,NY, USA, pp. 3917–3920.

Tulving E., T. D. M. (1973), ‘Encoding specificity and retrieval processes in episodic mem-ory’, Psych 80(80), 342–373.

Venolia, G. D. and Neustaedter, C. (2003), Understanding sequence and reply relationshipswithin email conversations: a mixed-model visualization, in ‘CHI ’03: Proceedings ofthe SIGCHI conference on Human factors in computing systems’, ACM, New York,NY, USA, pp. 361–368.

Wattenberg, M., Rohall, S. L., Gruen, D. and Kerr, B. (2005), ‘E-mail research: targetingthe enterprise’, Hum.-Comput. Interact. 20(1), 139–162.

Whittaker, S. (2005), ‘Supporting collaborative task management in e-mail’, Hum.-Comput.Interact. 20(1), 49–88.

Whittaker, S., Bellotti, V. and Gwizdka, J. (2006), ‘Email in personal information man-agement’, Commun. ACM 49(1), 68–73.

Whittaker, S. and Hirschberg, J. (2001), ‘The character, value, and management of personalpaper archives’, ACM Trans. Comput.-Hum. Interact. 8(2), 150–170.

Whittaker, S., Jones, Q., Nardi, B., Creech, M., Terveen, L., Isaacs, E. and Hainsworth,J. (2004), ‘Contactmap: Organizing communication in a social desktop’, ACM Trans.Comput.-Hum. Interact. 11(4), 445–471.

Whittaker, S. and Sidner, C. (1996), Email overload: exploring personal information man-agement of email, in ‘CHI ’96: Proceedings of the SIGCHI conference on Humanfactors in computing systems’, ACM, New York, NY, USA, pp. 276–283.

Wiberg, M. and Ljungberg, F. (1999), Exploring the vision of anytime, anywhere in thecontext of mobile work, in ‘In Knowledge Management and Virtual’, Idea GroupPublishing, pp. 157–169.

Wiener E.L, C. R. (1980), ‘Flight-deck automation: promises and problems’, Ergonomicspp. 995–1011.

Appendix A

Requirements Questionnaire -Example Screenshot

Figure A.1: Requirements Questionnaire - Example Screenshot

107

Appendix B

Paper Prototype - Example UserRoute

Figure B.1: Paper Prototype - Example User Route

108

Appendix C

Ethics Checklist

This document describes the 13 issues that were carefully considered before participantswere used for the collection of information as part of the project.

See overleaf for document.

109

APPENDIX C. ETHICS CHECKLIST 110

vgu

Appendix D

Evaluation User Manual

The user manual and evaluation briefing given to participants before they took part in theevaluation can be seen overleaf.

111

APPENDIX D. EVALUATION USER MANUAL 112

v j

Appendix E

Client Code

See chapter 5 for a description of the code that has been implemented. Due the vast lengthof the code listing, only a selection of files are displayed here. However, all files can befound on the cd included.

113

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

114E.1 File: PimText.py

import appuifw , e32 , u r l l i b , os , inbox , time , socket ,g raph i c s

o l d t i t l e = appuifw . app . t i t l eappuifw . app . t i t l e = u”PIMText”

#DOMAIN = ” h t t p ://www. pimtext . co . uk”DOMAIN = ”http : //213 . 175 . 192 . 36/˜ pimtextc /”

PATH = unicode ( os . getcwd ( ) )TMP = PATH + u”tmp . txt ”SETTINGS = PATH + u” s e t t i n g s . i n i ”QUEUE = PATH + u”queue . txt ”

NOTEPATH = PATH + u” notes\\%s . txt ”PICTUREPATH = PATH + u” images\\%s . jpg ”SMSPATH = PATH + u”smss\\%s . sms”

UPLOADMODE = ”batch”

class MainApp :def i n i t ( s e l f ) :

global SETTINGSs e l f . l o ck = e32 . Ao lock ( )appuifw . app . e x i t k ey hand l e r = s e l f . e x i t k ey hand l e r

#i f there i s no user a s soc i a t ed with the#dev i ce then crea t e an account or#as so c i a t e e x i s t i n g account with dev i ce

i f not os . path . e x i s t s (SETTINGS) :su c c e s s = u”no”suc c e s s = s e l f . f i r s tRun ( )while su c c e s s != u” suc c e s s ” :

i f appuifw . query (u”Exit ? ” , ”query” ) :s e l f . e x i t k ey hand l e r ( )break ;

else :s u c c e s s = s e l f . f i r s tRun ( )

i f su c c e s s == u” suc c e s s ” :s e l f . i n i t i a l i s e V i e w s ( )s e l f . setup ( )

else :

s e l f . i n i t i a l i s e V i e w s ( )s e l f . setup ( )

def i n i t i a l i s e V i e w s ( s e l f ) :global PATH, UPLOADMODE, SETTINGS, QUEUE, NOTEPATH,

TMPfrom PhotoView import PhotoViewfrom NoteView import NoteViewfrom IndexInboxView import IndexInboxViewfrom ChangeModeView import ChangeModeViewfrom DefaultAccessPointView import

DefaultAccessPointViewfrom MakeUploadView import MakeUploadViewfrom ChangeUserView import ChangeUserViewfrom DebugDeleteView import DebugDeleteViewfrom BrowseView import BrowseViews e l f . photo view = PhotoView ( s e l f , PATH)s e l f . note v iew = NoteView ( s e l f , PATH, UPLOADMODE,

SETTINGS, QUEUE, NOTEPATH, TMP)s e l f . index inbox v iew = IndexInboxView ( s e l f , PATH,

UPLOADMODE, SETTINGS, QUEUE, SMSPATH)s e l f . change mode view = ChangeModeView( s e l f , TMP,

QUEUE, UPLOADMODE)s e l f . d e f a u l t a c c e s s p o i n t v i ew =

DefaultAccessPointView ( s e l f )s e l f . make upload view = MakeUploadView ( s e l f , TMP,

QUEUE, UPLOADMODE)s e l f . change user v i ew = ChangeUserView ( s e l f , SETTINGS

, PATH, TMP)s e l f . debug de l e t e v i ew = DebugDeleteView ( s e l f , PATH,

SETTINGS, QUEUE, TMP)s e l f . browse view = BrowseView ( s e l f , TMP, SETTINGS)

def setup ( s e l f ) :s e l f . v iews = [ s e l f . browse view , s e l f . photo view , s e l f

. note view , s e l f . index inbox view , s e l f . change mode view ,s e l f . d e f a u l t a c c e s s p o i n t v i ew , s e l f . make upload view ,

s e l f . change user v iew , s e l f . debug de l e t e v i ew ]s e l f . mainMenuList = appuifw . Listbox ( [ u”Browse” ,

u”Take Photo” , u”Add Note” , u”Organise Inbox” , u”Batch /Continuous Mode” , u” Defau l t Access Point ” , u”Make AnUpload” , u”Change User” , u”Debug Delete ” ] , s e l f .h a nd l e s e l e c t )

def hand l e s e l e c t ( s e l f ) :

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

115global UPLOADMODEindex = s e l f . g e t cu r r en t ( )i f index == 4 :

UPLOADMODE = s e l f . v iews [ index ] . a c t i v a t e ( )else :

s e l f . v iews [ index ] . a c t i v a t e ( )

def g e t cu r r en t ( s e l f ) :return s e l f . mainMenuList . cur r ent ( )

def run ( s e l f ) :appuifw . app . body = s e l f . mainMenuLists e l f . l o ck . wait ( )s e l f . c l o s e ( )

def ex i t k ey hand l e r ( s e l f ) :s e l f . l o ck . s i g n a l ( )

def c l o s e ( s e l f ) :appuifw . app . e x i t k ey hand l e r = Nonedel s e l f . browse viewdel s e l f . photo viewdel s e l f . note v iewdel s e l f . index inbox v iewdel s e l f . change mode viewdel s e l f . d e f a u l t a c c e s s p o i n t v i ewdel s e l f . make upload viewdel s e l f . change user v i ewdel s e l f . debug de l e t e v i ew

def f i r s tRun ( s e l f ) :import ChangeUserViewglobal SETTINGS, PATH, TMPs e l f . i n i t i a l c h a n g e u s e r v i ew = ChangeUserView .

ChangeUserView ( s e l f , SETTINGS, PATH, TMP)

i f appuifw . query (u”Create a new account ? ” , ”query” ) :c r ea ted = s e l f . i n i t i a l c h a n g e u s e r v i ew .

c r ea t e ac count ( )

i f c rea ted == None :appuifw . note (u”Unable to be r e g i s t e r e d ” )del s e l f . i n i t i a l c h a n g e u s e r v i ew

e l i f c rea ted == ” i n s e r t f a i l u r e ” :appuifw . note (u”Username a l ready taken , choose

another ” )del s e l f . i n i t i a l c h a n g e u s e r v i ew

else :appuifw . note ( c r ea ted + u” s u c c e s s f u l l y

r e g i s t e r e d ” )del s e l f . i n i t i a l c h a n g e u s e r v i ewreturn u” suc c e s s ”

else :us ing = s e l f . i n i t i a l c h a n g e u s e r v i ew .

change s e t t i n g s ( )

i f us ing == None :appuifw . note (u”Unable to connect to s e r v e r ” )del s e l f . i n i t i a l c h a n g e u s e r v i ew

e l i f us ing == ” s e l e c t f a i l u r e ” :appuifw . note (u”Unable to va l i d a t e username” )del s e l f . i n i t i a l c h a n g e u s e r v i ew

else :appuifw . note ( us ing + u” s u c c e s s f u l l y va l i da t ed ” )del s e l f . i n i t i a l c h a n g e u s e r v i ewreturn u” suc c e s s ”

try :import SystemFunctionsfrom DefaultAccessPointView import ∗

GUIBackup = SystemFunctions . backupCurrentUI ( )

i n i t i a lA c c e s sPo i n t = DefaultAccessPointView (u” i n i t i a lA c c e s sPo i n t ” )

i f i n i t i a lA c c e s sPo i n t . a c t i v a t e ( ) == 0 :appuifw . note (u”You can choose a d e f au l t a c c e s s po int

l a t e r from the menu” )del i n i t i a lA c c e s sPo i n t

mainApp = MainApp ( )i f os . path . e x i s t s (SETTINGS) :

mainApp . run ( )

SystemFunctions . r e s toreCurrentUI (GUIBackup)

except :import sysimport t raceback

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

116import e32import appuifw# Restore screen to normal s i z e .appuifw . app . s c r e en=”normal”# Disab l e focus c a l l b a c k .appuifw . app . f o cus=Nonebody=appuifw . Text ( )# Create and use a t e x t con t ro l .appuifw . app . body=bodyapplock=e32 . Ao lock ( )def qu i t ( ) : applock . s i g n a l ( )# Override s o f t k e y handler .appuifw . app . e x i t k ey hand l e r=qu i t# Override app l i c a t i on menu .appuifw . app .menu=[(u”Exit ” , qu i t ) ]body . s e t ( unicode ( ”\n” . j o i n ( t raceback . f o rmat except ion (∗

sys . e x c i n f o ( ) ) ) ) )applock . wait ( )# Wait f o r e x i t key to be pressed .appuifw . app . s e t e x i t ( )

appuifw . app . t i t l e = o l d t i t l eappuifw .menu = None

E.2 File: BrowseView.py

import u r l l i b , appuifw , UserAccountFunctions , e32 ,g raph i c s

#DOMAIN = ”http ://www. pimtext . co . uk”DOMAIN = ”http : //213 . 175 . 192 . 36/˜ pimtextc /”

SETTINGS = NoneTMP = None

APP LOCK = None

c l a s s BrowseView :de f i n i t ( s e l f , MainApp , passedTMP , passedSETTINGS ) :

g l oba l SETTINGS, TMPs e l f . MainApp = MainAppSETTINGS = passedSETTINGSTMP = passedTMP

#Request l i s t s f o r the top a t t r i b u t e s o f context

#hierarchy ’ sde f g e t i n i t i a l l i s t ( s e l f ) :

s e l f . year = s e l f . i n i t i a l a c q u i r emen t (u” year ”)s e l f . typename = s e l f . i n i t i a l a c q u i r emen t (u”typename ”)s e l f . CountryName = s e l f . i n i t i a l a c q u i r emen t (

u”CountryName”)#Send reques t f o r l i s t o f r e s u l t s based on#”ques t i on ” a t t r i bu t e , e . g . year or countryCode

de f i n i t i a l a c q u i r emen t ( s e l f , que s t i on ) :g l oba l DOMAIN, SETTINGSusername = UserAccountFunctions . g e t l o ca l u s e rname (

SETTINGS)password = UserAccountFunctions . g e t l o c a l pa s swo rd (

SETTINGS)

params = u r l l i b . ur l encode ({ ’ username ’ : username ,’ password ’ : password , ’ quest ion ’ : ques t i on })

f u l l U r l = DOMAIN + u”/ p r o j e c t /db/ r e t r i e v a l . php?” +s t r ( params )

u r l l i b . u r l r e t r i e v e ( f u l lU r l , TMP)remote response = open (TMP) . read ( )

s e l f . temp = ( unicode ( remote response ) . s p l i t ( ” | | \ t ” ) )#to a l low f o r s p l i t that occured on# ’ | | ’ around f i n a l items e l f . temp . remove ( ’ ’ )f o r t in s e l f . temp :

s e l f . data . append ( t )s e l f . type . append ( ques t i on )

re turn s e l f . temp#Send reques t f o r l i s t o f r e s u l t s based#on ” ques t i on ” a t t r i bu t e , b u i l t r eque s t#us ing prev ious nav igat i on route

de f main acquirement ( s e l f , want , got , chosenAttr ibute ,d i s t i n c t ) :

g l oba l DOMAIN, SETTINGSusername = UserAccountFunctions . g e t l o ca l u s e rname (

SETTINGS)password = UserAccountFunctions . g e t l o c a l pa s swo rd (

SETTINGS)

i f s e l f . excludesms == u”no ” :params = u r l l i b . ur l encode ({ ’ username ’ : username ,

’ password ’ : password , ’want ’ : want , ’ got ’ : got ,

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

117’ chosenAttr ibute ’ : chosenAttr ibute , ’ d i s t i n c t ’ : d i s t i n c t })

e l s e :params = u r l l i b . ur l encode ({ ’ username ’ : username ,

’ password ’ : password , ’want ’ : want , ’ got ’ : got ,’ chosenAttr ibute ’ : chosenAttr ibute , ’ d i s t i n c t ’ : d i s t i n c t ,’ excludesms ’ : s e l f . excludesms })

f u l l U r l = DOMAIN + u”/ p r o j e c t /db/ r e t r i e v a l . php?” +s t r ( params )

u r l l i b . u r l r e t r i e v e ( f u l lU r l , TMP)remote response = open (TMP) . read ( )

s e l f . temp = ( unicode ( remote response ) . s p l i t ( ” | | \ t ” ) )#to a l low f o r s p l i t that occured#on ’ | | ’ around f i n a l items e l f . temp . remove ( ’ ’ )f o r t in s e l f . temp :

s e l f . data . append ( t )s e l f . type . append (want )

re turn s e l f . temp#Handles v i ewers f o r ac tua l#in format ion items

de f l i s t i t e m s ( s e l f , cu r r ent ) :i f cu r r ent . s t a r t sw i t h (u”Note : ” ) :

f o r f i l e in s e l f . f i l e L i s t :i f f i l e [ 0 ] == current :

s e l f . no te v i ewer ( f i l e [ 1 ] )s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )re turn

i f cur r ent . s t a r t sw i t h (u” Pic ture : ” ) :f o r f i l e in s e l f . f i l e L i s t :

i f f i l e [ 0 ] == current :s e l f . j pg v i ewer ( f i l e [ 1 ] )s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )re turn

i f cur r ent . s t a r t sw i t h (u”sms : ” ) :f o r f i l e in s e l f . f i l e L i s t :

i f f i l e [ 0 ] == current :s e l f . sms viewer ( f i l e [ 1 ] )s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )re turn

#Work around f o r day and#month c l a sh

de f month day f ix ( s e l f , currentType ) :i f l en ( s e l f . time ) == 1 :

re turn u”day”e l s e :

r e turn currentType#Return human readab le month

de f month view ( s e l f , month ) :i f month == u”1” :

re turn u”January”e l i f month == u”2” :

re turn u”February”e l i f month == u”3” :

re turn u”March”e l i f month == u”4” :

re turn u” Apr i l ”e l i f month == u”5” :

re turn u”May”e l i f month == u”6” :

re turn u”June”e l i f month == u”7” :

re turn u” July ”e l i f month == u”8” :

re turn u”August”e l i f month == u”9” :

re turn u”September”e l i f month == u”10” :

re turn u”October”e l i f month == u”11” :

re turn u”November”e l i f month == u”12” :

re turn u”December”e l s e :

r e turn month#return machine readab le month

de f month funct ion ( s e l f , month ) :i f month == u”January ” :

r e turn u”1”e l i f month == u”February ” :

r e turn u”2”e l i f month == u”March ” :

re turn u”3”e l i f month == u” Apr i l ” :

r e turn u”4”e l i f month == u”May” :

re turn u”5”e l i f month == u”June ” :

r e turn u”6”

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

118e l i f month == u”July ” :

r e turn u”7”e l i f month == u”August ” :

r e turn u”8”e l i f month == u”September ” :

r e turn u”9”e l i f month == u”October ” :

r e turn u”10”e l i f month == u”November ” :

r e turn u”11”e l i f month == u”December ” :

r e turn u”12”e l s e :

r e turn month#l o g i c o f the app l i c a t i on , c a l l e d#everyt ime user nav iga te s through the h i e ra r chy

de f h and l e s e l e c t ( s e l f ) :got = u””chosenAttr ibute = u””oldToList = s e l f . t oL i s t [ : ]

i = s e l f . l i s t b o x . cur r ent ( )cur r ent = s e l f . g e t t e x t ( )cur r ent = s e l f . month funct ion ( cur rent )s e l f . c ho i c e s . append ( cur rent )

#load viewer i f a c tua l in fo rmat ion itemi f cur r ent . s t a r t sw i t h (u”Note : ”) or cur rent .

s t a r t sw i t h (u” Pic ture : ”) or cur rent . s t a r t sw i t h (u”sms : ” ) :s e l f . c ho i c e s . pop ( )s e l f . l i s t i t e m s ( cur rent )re turn

#i f no context s have been navigated yets e l f . t oL i s t = [ ]i f l en ( s e l f . context ) == 3 :

s e l f . context . remove ( cur rent )i f cur r ent == ”TYPE” :

s e l f . t oL i s t = s e l f . typename [ : ]e l i f cu r r ent == ”LOCATION” :

s e l f . t oL i s t = s e l f . CountryName [ : ]e l i f cu r r ent == ”TIME” :

s e l f . t oL i s t = s e l f . year [ : ]#i f 1 context has been navigated

e l i f l en ( s e l f . context ) == 2 :i f s e l f . excludesms == u”no” and ( cur rent == u”TIME”

or cur rent == u”SENDER” ) :

s e l f . context . remove ( cur rent )i f cur r ent == u”TIME” :

r e s u l t s = s e l f . g e t o p t i o n l i s t (u” year ”)i f cur r ent == u”SENDER” :

r e s u l t s = s e l f . g e t o p t i o n l i s t (u”CountryName”)s e l f . t oL i s t = r e s u l t s [ : ]

e l i f cu r r ent == ”TYPE” or cur rent == ”LOCATION” orcur rent == ”TIME” :

s e l f . context . remove ( cur rent )i f cur r ent == ”TYPE” :

r e s u l t s = s e l f . g e t o p t i o n l i s t (u”typename ”)e l i f cu r r ent == ”LOCATION” :

r e s u l t s = s e l f . g e t o p t i o n l i s t (u”CountryName”)e l i f cu r r ent == ”TIME” :

r e s u l t s = s e l f . g e t o p t i o n l i s t (u” year ”)s e l f . t oL i s t = r e s u l t sf i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

e l s e :index = s e l f . data . index ( cur rent )currentType = s e l f . type [ index ]

#f i x f o r day and month c o n f l i c t i n gi f currentType == ”month ” :

currentType = s e l f . month day f ix ( currentType )

s e l f . soFar . append ( [ currentType , cur r ent ] )

i f currentType in s e l f . time :s e l f . time . remove ( currentType )i f l en ( s e l f . time ) == 0 :

s e l f . t oL i s t = s e l f . context [ : ]f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

e l s e :r e s u l t s = s e l f . g e t o p t i o n l i s t ( s e l f . time [ 0 ] )i f currentType == u”year ” :

count = 0f o r month in r e s u l t s :

r e s u l t s [ count ] = s e l f . month view (month)count = count + 1

s e l f . t oL i s t = r e s u l t s

i f currentType in s e l f . l o c a t i o n :

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

119s e l f . l o c a t i o n . remove ( currentType )i f l en ( s e l f . l o c a t i o n ) == 0 :


e l s e :r e s u l t s = s e l f . g e t o p t i o n l i s t ( s e l f . l o c a t i o n [

0 ] )s e l f . t oL i s t = r e s u l t s

i f currentType in s e l f . t ypeL i s t :s e l f . t ypeL i s t . remove ( currentType )i f l en ( s e l f . t ypeL i s t ) == 0 :

i f cur r ent == u”sms ” :s e l f . context . remove (u”LOCATION”)s e l f . context . append (u”SENDER”)

s e l f . t oL i s t = s e l f . context [ : ]s e l f . excludesms = u”no”

e l s e :s e l f . t oL i s t = s e l f . context [ : ]f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

#I f two context s have been navigatede l i f l en ( s e l f . context ) == 1 :

i f cur r ent in s e l f . data :index = s e l f . data . index ( cur rent )currentType = s e l f . type [ index ]


currentType = s e l f . month day f ix ( currentType )

i f currentType == u” sender ” :currentType = u”CountryName”


i f s e l f . excludesms == u”no” and ( currentType ==u”CountryName” or currentType == u”day ” ) :

i f currentType == u”CountryName ” :s e l f . context . remove (u”TIME”)r e s u l t s = s e l f . g e t o p t i o n l i s t (u” year ”)

i f currentType == u”day ” :s e l f . context . remove (u”SENDER”)

r e s u l t s = s e l f . g e t o p t i o n l i s t (u”CountryName”)s e l f . t oL i s t = r e s u l t s

e l i f cu r r ent == ”TYPE” or cur rent == ”LOCATION” orcur rent == ”TIME” :

i f cur r ent == ”TYPE” :s e l f . context . remove ( cur rent )r e s u l t s = s e l f . g e t o p t i o n l i s t (u”typename ”)s e l f . t oL i s t = r e s u l t s

e l i f cu r r ent == ”LOCATION” :s e l f . context . remove ( cur rent )r e s u l t s = s e l f . g e t o p t i o n l i s t (u”CountryName”)s e l f . t oL i s t = r e s u l t s

e l i f cu r r ent == ”TIME” :s e l f . context . remove ( cur rent )r e s u l t s = s e l f . g e t o p t i o n l i s t (u” year ”)s e l f . t oL i s t = r e s u l t s

e l s e :






s e l f . t oL i s t = r e s u l t sf i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

i f currentType in s e l f . l o c a t i o n :s e l f . l o c a t i o n . remove ( currentType )i f l en ( s e l f . l o c a t i o n ) == 0 :



0 ] )s e l f . t oL i s t = r e s u l t s

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

120f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

i f currentType in s e l f . t ypeL i s t :s e l f . t ypeL i s t . remove ( currentType )i f l en ( s e l f . t ypeL i s t ) == 0 :

i f cur r ent == u”sms ” :s e l f . t oL i s t = [ u”TIME” , u”SENDER” ]

e l s e :s e l f . t oL i s t = s e l f . context [ : ]f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

#I f a l l context s have been navigatede l i f l en ( s e l f . context ) == 0 :

i f cur r ent in s e l f . data :index = s e l f . data . index ( cur rent )currentType = s e l f . type [ index ]


currentType = s e l f . month day f ix ( currentType )i f currentType == u” sender ” :

currentType = u”CountryName”



f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )




s e l f . t oL i s t = r e s u l t sf i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

i f currentType in s e l f . l o c a t i o n :s e l f . l o c a t i o n . remove ( currentType )i f l en ( s e l f . l o c a t i o n ) == 0 :

f i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )


0 ] )s e l f . t oL i s t = r e s u l t sf i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )

i f s e l f . t oL i s t == [ ] :appuifw . note (u”There are no in fo rmat ion items to

browse ”)s e l f . c ho i c e s . remove ( cur rent )s e l f . context . append ( cur rent )s e l f . t oL i s t = oldToList [ : ]s e l f . l i s t b o x . s e t l i s t ( o ldToList )

e l s e :s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )

#r e t r i e v e the l i s t o f opt ions g iven a context#at t r i bu t e , e . g . month

de f g e t o p t i o n l i s t ( s e l f , want ) :got = u””chosenAttr ibute = u””f o r sF in s e l f . soFar :

got += ( sF [ 0 ] + u ” | | ” )chosenAttr ibute += ( sF [ 1 ] + u ” | | ” )

r e s u l t s = s e l f . main acquirement (want , got ,chosenAttr ibute , u” yes ”)

re turn r e s u l t s#r e t r i e v e the l i s t o f in fo rmat ion items#depending on l o c a t i o n in h i e ra r chy

de f g e t f i l e l i s t ( s e l f ) :s e l f . f i l e L i s t = [ ]got = u””chosenAttr ibute = u””f o r sF in s e l f . soFar :

got += ( sF [ 0 ] + u ” | | ” )chosenAttr ibute += ( sF [ 1 ] + u ” | | ” )

f i l enames = s e l f . main acquirement (u” f i l ename ” , got ,chosenAttr ibute , u” yes ”)

forReturn = [ ]f o r f i l e in f i l enames :

i f f i l e . endswith (u ” . txt ” ) :niceNames = f i l e . s p l i t (u”\\”)temp = [ u”Note : ” + niceNames [ l en ( niceNames )−1] ,

f i l e ]

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

121s e l f . f i l e L i s t . append ( temp)forReturn . append (u”Note : ” + niceNames [ l en (

niceNames )−1])i f f i l e . endswith (u ” . jpg ” ) :

niceNames = f i l e . s p l i t (u”\\”)temp = [ u” Pic ture : ” + niceNames [ l en ( niceNames)−1

] , f i l e ]s e l f . f i l e L i s t . append ( temp)forReturn . append (u” Pic ture : ” + niceNames [ l en (

niceNames )−1])i f f i l e . endswith (u ” . sms ” ) :

niceNames = f i l e . s p l i t (u”\\”)temp = [ u”sms : ” + niceNames [ l en ( niceNames )−1] ,

f i l e ]s e l f . f i l e L i s t . append ( temp)forReturn . append (u”sms : ” + niceNames [ l en (

niceNames )−1])#pr in t s e l f . f i l e L i s tr e turn forReturn

#Photo viewerde f jpg v i ewer ( s e l f , f i l ename ) :

s e l f .APP LOCK2 = e32 . Ao lock ( )s e l f . o ldHandler = appuifw . app . e x i t k ey hand l e rs e l f . oldMenu = appuifw . app .menus e l f . oldJBody = appuifw . app . bodys e l f . o ldJScreen = appuifw . app . s c r e en

appuifw . app . e x i t k ey hand l e r = s e l f . j p g e x i tappuifw . app .menu = [ ( u”Back” , s e l f . j p g e x i t ) ]

img = graph i c s . Image . open ( f i l ename )appuifw . app . s c r e en = ’ normal ’appuifw . app . body = canvas = appuifw . Canvas ( )

w, h = canvas . s i z ecanvas . b l i t ( img , t a r g e t = (0 ,0 , w, h ) , s c a l e = 1)s e l f .APP LOCK2. wait ( )

#c l ean e x i t o f photoviewerde f j p g e x i t ( s e l f ) :

appuifw . app . e x i t k ey hand l e r = s e l f . o ldHandlerappuifw . app . body = s e l f . oldJBodyappuifw . app .menu = s e l f . oldMenuappuifw . app . s c r e en = s e l f . o ldJScreens e l f .APP LOCK2. s i g n a l ( )

#message viewer

de f sms viewer ( s e l f , f i l ename ) :t i t l e = UserAccountFunctions . g e t l o ca l u s e rname (

f i l ename )body = UserAccountFunctions . g e t l o c a l pa s swo rd (

f i l ename )s e l f . note v iew = NoteView ( s e l f )s e l f . note v iew . a c t i v a t e ( t i t l e , body )

#note viewerde f note v i ewer ( s e l f , f i l ename ) :

t i t l e = UserAccountFunctions . g e t l o ca l u s e rname (f i l ename )

body = UserAccountFunctions . g e t l o c a l pa s swo rd (f i l ename )

s e l f . note v iew = NoteView ( s e l f )s e l f . note v iew . a c t i v a t e ( t i t l e , body )

#return the text o f the s e l e c t e d itemde f g e t t e x t ( s e l f ) :

r e turn s e l f . t oL i s t [ s e l f . l i s t b o x . cur r ent ( ) ]#prepare the h i e ra r chy f o r immediate i n i t i a l#nav igat i on

de f a c t i v a t e ( s e l f ) :import u r l l i b , appuifw , UserAccountFunctions , e32 ,

g raph i c sappuifw . app . t i t l e = u”UK/Bath and NE Somerset /Bath/”import key codess e l f . soFar = [ ]s e l f . c ho i c e s = [ ]s e l f . excludesms = u”yes ”

s e l f . f i l e L i s t = [ ]

s e l f . context = [ u”TYPE” , u”LOCATION” , u”TIME” ]s e l f . time = [ u” year ” , u”month” , u”day ” ]s e l f . l o c a t i o n = [ u”CountryName” ,

u”AdministrativeAreaName ” , u”SubAdministrativeAreaName ” ,u”LocalityName ” ]

s e l f . t ypeL i s t = [ u”typename ” ]

s e l f . o r i g i na lCont ex t = [ u”TYPE” , u”LOCATION” , u”TIME” ]s e l f . o r i g ina lT ime = [ u” year ” , u”month” , u”day ” ]s e l f . o r i g i n a lLo c a t i o n = [ u”CountryName” ,

u”AdministrativeAreaName ” , u”SubAdministrativeAreaName ” ,u”LocalityName ” ]

s e l f . o r i g i na lTypeL i s t = [ u”typename ” ]

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

122s e l f . t oL i s t = s e l f . context [ : ]s e l f . l i s t b o x = Listbox = appuifw . Listbox ( s e l f . t oL i s t ,

s e l f . h a nd l e s e l e c t )

s e l f . data = [ ]s e l f . type = [ ]oldBodyActivate = appuifw . app . bodyo l dT i t l eAc t i v a t e = appuifw . app . t i t l eo ldHandlerAct ivate = appuifw . app . e x i t k ey hand l e ro ldScreenAct ivate = appuifw . app . s c r e enAPP LOCK = e32 . Ao lock ( )t ry :

s e l f . g e t i n i t i a l l i s t ( )canvas = appuifw . Canvas ( )canvas = s e l f . l i s t b o x

canvas . bind ( key codes . EKeyLeftArrow , s e l f .handle back )

canvas . bind ( key codes . EKey4 , s e l f . handle back )

canvas . bind ( key codes . EKeyRightArrow , s e l f .h a nd l e s e l e c t )

canvas . bind ( key codes . EKey6 , s e l f . h a nd l e s e l e c t )

appuifw . app . body = canvasappuifw . app .menu = [ ( u” S e l e c t ” , s e l f . h a nd l e s e l e c t

) , (u”Back” , s e l f . handle back ) ]appuifw . app . e x i t k ey hand l e r = s e l f . e x i tAPP LOCK. wait ( )

except :appuifw . app . s c r e en = o ldScreenAct ivateappuifw . app . t i t l e = o ldT i t l eAc t i v a t eappuifw . app . body = oldBodyActivateappuifw . app . e x i t k ey hand l e r = oldHandlerAct ivatere turn

appuifw . app . s c r e en = o ldScreenAct ivateappuifw . app . t i t l e = o ldT i t l eAc t i v a t eappuifw . app . body = oldBodyActivateappuifw . app . e x i t k ey hand l e r = oldHandlerAct ivate

#s i g n a l to re turn back to the main menude f e x i t ( s e l f ) :

APP LOCK. s i g n a l ( )#l o g i c o f the app l i c a t i on , c a l l e d everyt ime#user nav iga te s back up the h i e ra r chy

de f handle back ( s e l f ) :

i f l en ( s e l f . context ) == 3 :s e l f . e x i t ( )r e turn

got = u””chosenAttr ibute = u””l a s t = s e l f . c ho i c e s . pop ( )i f s e l f . excludesms == u”no” and l en ( s e l f . context ) ==

0 and ( l a s t == u”SENDER” or l a s t == u”TIME” ) :i f l a s t == u”SENDER” :

s e l f . context . append (u”TIME”)i f l a s t == u”TIME” :

s e l f . context . append (u”SENDER”)

i f l a s t == ”TYPE” or l a s t == ”LOCATION” or l a s t ==”TIME” or l a s t == ”SENDER” :

s e l f . context . r e v e r s e ( )s e l f . context . append ( l a s t )s e l f . context . r e v e r s e ( )s e l f . t oL i s t = s e l f . context [ : ]

s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )e l s e :

i f s e l f . excludesms == u”no” and l a s t == ”sms ” :s e l f . context . remove (u”SENDER”)s e l f . context . append (u”LOCATION”)

index = s e l f . data . index ( l a s t )

lastType = s e l f . type [ index ]s e l f . t ypeL i s t . append ( lastType )

s e l f . soFar . pop ( )

f o r sF in s e l f . soFar :got += ( sF [ 0 ] + u ” | | ” )chosenAttr ibute += ( sF [ 1 ] + u ” | | ” )

r e s u l t s = s e l f . main acquirement ( lastType , got ,chosenAttr ibute , u” yes ”)

s e l f . t oL i s t = r e s u l t ss e l f . excludesms = u”yes ”

s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )

e l s e :index = s e l f . data . index ( l a s t )

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

123lastType = s e l f . type [ index ]

i f lastType in s e l f . o r i g ina lT ime :s e l f . time . r e v e r s e ( )s e l f . time . append ( lastType )s e l f . time . r e v e r s e ( )

i f lastType in s e l f . o r i g i n a lLo c a t i o n :s e l f . l o c a t i o n . r e v e r s e ( )s e l f . l o c a t i o n . append ( lastType )s e l f . l o c a t i o n . r e v e r s e ( )

i f lastType in s e l f . o r i g i na lTypeL i s t :s e l f . t ypeL i s t . append ( lastType )

s e l f . soFar . pop ( )

r e s u l t s = s e l f . g e t o p t i o n l i s t ( lastType )i f lastType == u”month ” :



s e l f . t oL i s t = r e s u l t sf i l enames = s e l f . g e t f i l e l i s t ( )s e l f . t oL i s t . extend ( f i l enames )i f l en ( s e l f . t oL i s t ) == 1 and s e l f . t oL i s t [ 0 ] ==

u”SENDER” :s e l f . t oL i s t . append (u”TIME”)s e l f . context . append (u”TIME”)

i f l en ( s e l f . t oL i s t ) == 1 and s e l f . t oL i s t [ 0 ] ==u”TIME” :

s e l f . t oL i s t . append (u”SENDER”)s e l f . context . append (u”SENDER”)

s e l f . l i s t b o x . s e t l i s t ( s e l f . t oL i s t )

E.3 File: PhotoView.py

import appuifwfrom openSourceCamera import ∗

PATH = None

c l a s s PhotoView :de f i n i t ( s e l f , MainApp , passedPATH ) :

g l oba l PATHs e l f . MainApp = MainAppPATH = passedPATHi f not os . path . e x i s t s (PATH + u” images ” ) :

os . mkdir (PATH + u” images ”)de f a c t i v a t e ( s e l f ) :

oldBody = appuifw . app . bodyo l d t i t l e = appuifw . app . t i t l eo ld hand l e r = appuifw . app . e x i t k ey hand l e ro ldScreen = appuifw . app . s c r e eni f name == ’ main ’ :

s e l f . appLock = e32 . Ao lock ( )appuifw . app . s c r e en = ’ f u l l ’appuifw . app . e x i t k ey hand l e r = s e l f . e x i ts e l f . camView = CameraView ( )s e l f . camView . setViewOn ( )s e l f . appLock . wait ( )appuifw . app . s c r e en = oldScreenappuifw . app . t i t l e = o l d t i t l eappuifw . app . body = oldBodyappuifw . app . e x i t k ey hand l e r = o ld hand l e r

de f e x i t ( s e l f ) :s e l f . camView . d e l ( )s e l f . appLock . s i g n a l ( )

E.4 File: DefaultAccessPointView.py

import socketc l a s s DefaultAccessPointView :

de f i n i t ( s e l f , MainApp ) :s e l f . MainApp = MainApp

de f a c t i v a t e ( s e l f ) :a c ce s sPo in t = s e l f . s e t a pp d e f a u l t a c c e s s p o i n t ( )

i f a c ce s sPo in t == 0 :re turn 0

de f s e t a pp d e f a u l t a c c e s s p o i n t ( s e l f ) :apId = socket . s e l e c t a c c e s s p o i n t ( )i f apId != 0 :

t ry :

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

124apo = socket . a c c e s s p o i n t ( apId )socke t . s e t d e f a u l t a c c e s s p o i n t ( apo )

except :r e turn 0

re turn apId

E.5 File: IndexInboxView.py

import appuifw , os , inbox , time

PATH = NoneUPLOADMODE = NoneSETTINGS = NoneQUEUE = NoneSMSPATH = None

c l a s s IndexInboxView :de f i n i t ( s e l f , MainApp , passedPATH ,

passedUPLOADMODE, passedSETTINGS , passedQUEUE ,passedSMSPATH ) :

g l oba l PATH, UPLOADMODE, SETTINGS, QUEUE, SMSPATHs e l f . MainApp = MainAppPATH = passedPATHUPLOADMODE = passedUPLOADMODESETTINGS = passedSETTINGSQUEUE = passedQUEUESMSPATH = passedSMSPATHi f not os . path . e x i s t s (PATH + u”smss ” ) :

os . mkdir (PATH + u”smss ”)de f a c t i v a t e ( s e l f ) :

i f appuifw . query (u” Indexing the inbox may take a fewminutes , cont inue ?” , ”query ” ) :

s e l f . indexNow ( )de f indexNow ( s e l f ) :

g l oba l UPLOADMODE, SETTINGS, QUEUE, SMSPATH#s e l f . appLock = e32 . Ao lock ( )s e l f . count = 0box = inbox . Inbox ( )tota lMessages = len ( box . sms messages ( ) )appuifw . note (u” Indexing ” + s t r ( tota lMessages ) + u”

messages ”)#s e l f . appLock . wait ( )s e l f . f i v ePe r c en t = tota lMessages / 20

s e l f . a c tua lPercent = 5f o r sms id in box . sms messages ( ) :

content = box . content ( sms id )smstime = box . time ( sms id )sender = box . address ( sms id )

sms t ime l i s t = time . gmtime ( smstime )smsEpochString = s t r ( smstime )sender = s t r ( sender )

f = f i l e (SMSPATH%smsEpochString , ’w+ ’)t ry :

f . wr i t e ( s t r ( sender ) + u”\ t ” + s t r ( content ) )StorageUploadFunctions . add to queue (TMP,

SMSPATH%smsEpochString , ”sms” , SETTINGS, QUEUE,UPLOADMODE, smst ime l i s t , smsEpochString , sender )

#pr in t senderexcept :

p r i n t s t r ( sms id )#s e l f . appLock . s i g n a l ( )

f . c l o s e ( )s e l f . count = s e l f . count + 1i f s e l f . f i v ePe r c en t != 0 :

i f s e l f . count % s e l f . f i v ePe r c en t == 0 :appuifw . note ( s t r ( s e l f . a c tua lPercent ) + u”%

indexed ”)s e l f . a c tua lPercent = s e l f . a c tua lPercent + 5

#s e l f . appLock . s i g n a l ( )appuifw . note (u” Indexing Complete ”)

E.6 File: MakeUploadView.py

import appuifw , StorageUploadFunctionsTMP = NoneQUEUE = NoneUPLOADMODE = None

c l a s s MakeUploadView :de f i n i t ( s e l f , MainApp , passedTMP , passedQUEUE ,

passedUPLOADMODE) :g l oba l TMP, QUEUE, UPLOADMODEs e l f . MainApp = MainApp

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

125TMP = passedTMPQUEUE = passedQUEUEUPLOADMODE = passedUPLOADMODE

def a c t i v a t e ( s e l f ) :g l oba l QUEUE, UPLOADMODEi f appuifw . query (u”Upload a batch o f in fo rmat ion now?” ,

”query ” ) :StorageUploadFunctions . batch upload (TMP, QUEUE,

UPLOADMODE)

E.7 File: NoteView.py

import appuifw , os

PATH = NoneUPLOADMODE = NoneSETTINGS = NoneQUEUE = NoneNOTEPATH = NoneTMP = None

c l a s s NoteView :de f i n i t ( s e l f , MainApp , passedPATH ,

passedUPLOADMODE, passedSETTINGS , passedQUEUE ,passedNOTEPATH, passedTMP ) :

g l oba l PATH, UPLOADMODE, SETTINGS, QUEUE, NOTEPATHs e l f . MainApp = MainApp

PATH = passedPATHUPLOADMODE = passedUPLOADMODESETTINGS = passedSETTINGSQUEUE = passedQUEUENOTEPATH = passedNOTEPATHTMP = passedTMP

i f not os . path . e x i s t s (PATH + u” notes ” ) :os . mkdir (PATH + u” notes ”)

de f a c t i v a t e ( s e l f , v i ewTi t l e = None , viewBody = None ) :g l oba l SETTINGS, QUEUE, UPLOADMODE, NOTEPATHs e l f . o ldHandler = appuifw . app . e x i t k ey hand l e rs e l f . saved = Falsei f v i ewTi t l e i s None or viewBody i s None :

f i e l d s = [ ( u” Subject ” , ’ text ’ ) , (u”Body” , ’ text ’ ) ]e l s e :

f i e l d s = [ ( u” Subject ” , ’ text ’ , v i ewTi t l e ) , (u”Body”, ’ text ’ , viewBody ) ]

form = appuifw . Form( f i e l d s , f l a g s=appuifw .FFormEditModeOnly )

form . save hook = s e l f . saveform . execute ( )

i f s e l f . saved == True :i f form [ 0 ] [ 2 ] == u”” :

t i t l e = u”no t i t l e ”e l s e :

t i t l e = form [ 0 ] [ 2 ]i f form [ 1 ] [ 2 ] == u”” :

body = u”no content ”e l s e :

body = form [ 1 ] [ 2 ]tempNote = save temp note ( t i t l e , body , NOTEPATH)StorageUploadFunctions . add to queue (TMP, tempNote ,

” txt ” , SETTINGS, QUEUE, UPLOADMODE)s e l f . saved = Falseappuifw . app . e x i t k ey hand l e r = s e l f . o ldHandler

de f save ( s e l f , arg ) :s e l f . saved = Truere turn True

de f save temp note ( t i t l e , contents , NOTEPATH) :( year , month , day , hour , minute , epoch ) =

ContextFunctions . g e t cu r r en t t ime ( )note name = s t r ( year ) + u’− ’ + s t r (month) + u’− ’ +

s t r ( day ) + u’−−’ + s t r ( hour ) + u’− ’ + s t r ( minute ) + u’−−’+ s t r ( epoch )

f = f i l e (NOTEPATH%note name , ’w+ ’)f . wr i t e ( t i t l e + u”\ t ” + contents )f . c l o s e ( )re turn NOTEPATH%note name

E.8 File: ContextFunctions.py

import timede f g e t cu r r en t t ime ( ) :

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

126year = time . gmtime ( ) [ 0 ]month = time . gmtime ( ) [ 1 ]day = time . gmtime ( ) [ 2 ]hour = time . gmtime ( ) [ 3 ]minute = time . gmtime ( ) [ 4 ]epoch = time . time ( )re turn year , month , day , hour , minute , epoch

de f l o c a t i o n f r om c e l l ( locationAreaCode , c e l l I d ) :from s t r u c t import pack , unpackfrom s t r i n g import r ep l a c efrom h t t p l i b import HTTPpage = ”/glm/mmap”content type = ’ app l i c a t i on /binary ’http = HTTP(”www. goog l e . com”)

r e s u l t = NoneerrorCode = 0

locat ionAreaCode = in t ( locat ionAreaCode )c e l l I d = in t ( c e l l I d )

body = pack( ’> hqh 2 s h 1 3 s h 5 s h 3 sB i i i h i i i i i i ’ , 21 , 0 , 2 ,’ in ’ , 13 , ”Nokia N95 8Gb” , 5 , ” 1 . 3 . 1 ” , 3 , ”Web” , 27 , 0 , 0 ,3 , 0 , c e l l I d , locationAreaCode , 0 , 0 , 0 , 0)http . putrequest ( ’POST’ , page )http . putheader ( ’ Content−Type ’ , content type )http . putheader ( ’ Content−Length ’ , s t r ( l en ( body ) ) )http . endheaders ( )

t ry :http . send ( body )errcode , errmsg , headers = http . g e t r ep l y ( )

except :t ry :

http . send ( body )errcode , errmsg , headers = http . g e t r ep l y ( )

except :t ry :

http . send ( body )errcode , errmsg , headers = http . g e t r ep l y ( )

except :http . send ( body )errcode , errmsg , headers = http . g e t r ep l y ( )

r e s u l t = http . f i l e . read ( )

http . c l o s e ( )

i f ( e r r code == 200 ) :( a , b , errorCode , l a t i t ude , long i tude , c , d , e ) =

unpack(”> h B i i i i i h ” , r e s u l t )l a t i t u d e = l a t i t u d e / 1000000.0l ong i tude = long i tude / 1000000.0

re turn l a t i t ude , l ong i tude

E.9 File: StorageUploadFunctions.py

import u r l l i b , h t tp l i b , os , codecs , l o ca t i on , e32 , appuifwfrom ContextFunctions import ∗

#DOMAIN = ”http ://www. pimtext . co . uk”DOMAIN = ”http : //213 . 175 . 192 . 36/˜ pimtextc /”

de f add to db (TMP, type , fi leToAdd , locationAreaCode ,c e l l I d , username , password , year , month , day , hour ,minute , epoch , smsSender = None ) :

t ry :( f i l ename , type ) = up l o a d f i l e ( type , f i leToAdd )

except :r e turn u” f a i l − upload”

e32 . a o y i e l d ( )

i f type == ”sms ” :params = u r l l i b . ur l encode ({ ’ username ’ : username ,

’ password ’ : password , ’ type ’ : type , ’ f i l ename ’ : f i l ename ,’ smssender ’ : smsSender , ’ year ’ : year , ’month ’ : month ,

’ day ’ : day , ’ hour ’ : hour , ’ minute ’ : minute , ’ epoch ’ :epoch })#params = u r l l i b . ur l encode ({ ’ username ’ : username ,#’password ’ : password , ’ type ’ : type , ’ f i l ename ’ :#fileToAdd , ’ smssender ’ : smsSender , ’ year ’ : year ,#’month ’ : month , ’ day ’ :day , ’ hour ’ : hour , ’ minute ’ : minute , ’ epoch ’ : epoch })

e l s e :t ry :

( l a t , lon ) = l o c a t i o n f r om c e l l (locationAreaCode , c e l l I d )

except :t ry :

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

127( l a t , lon ) = l o c a t i o n f r om c e l l (

locationAreaCode , c e l l I d )except :

t ry :( l a t , lon ) = l o c a t i o n f r om c e l l (

locationAreaCode , c e l l I d )except :

r e turn u” f a i l − upload”

#l a t = 51.382645#lon = −2.354228e32 . a o y i e l d ( )params = u r l l i b . ur l encode ({ ’ username ’ : username ,

’ password ’ : password , ’ type ’ : type , ’ f i l ename ’ : f i l ename ,’ l a t ’ : l a t , ’ lon ’ : lon , ’ year ’ : year , ’month ’ : month ,

’ day ’ : day , ’ hour ’ : hour , ’ minute ’ : minute , ’ epoch ’ :epoch })#params = u r l l i b . ur l encode ({ ’ username ’ : username ,#’password ’ : password , ’ type ’ : type , ’ f i l ename ’ :#fileToAdd , ’ l a t ’ : l a t , ’ lon ’ : lon , ’ year ’ : year ,#’month ’ : month , ’ day ’ : day , ’ hour ’ : hour , ’ minute ’ :#minute , ’ epoch ’ : epoch })

f u l l U r l = DOMAIN + u”/ p r o j e c t /db/addItem . php?” + s t r( params )

t ry :u r l l i b . u r l r e t r i e v e ( f u l lU r l , TMP)

except :r e turn u” f a i l − upload”

remote response = open (TMP) . read ( )

de f u p l o a d f i l e ( type , f i l eToUpload ) :r e adF i l e = f i l e ( f i l eToUpload ) . read ( )

#conn = h t t p l i b . HTTPConnection (”www. pimtext . co . uk”)conn = h t tp l i b . HTTPConnection (

”213 .175 .192 .36/˜ pimtextc /”)

conn . r eque s t (”POST” , ”/ p r o j e c t /up/” + type +” up l o ad t o u r l . php” , r e adF i l e )

e32 . a o y i e l d ( )re sponse = conn . ge t r e sponse ( )e32 . a o y i e l d ( )responseData = response . read ( )conn . c l o s e ( )re turn responseData , type

de f add to queue (TMP, f i l ename , type , SETTINGS, QUEUE,UPLOADMODE, smstimeNice = None , smsEpoch = None ,smsSender = None ) :

oldQueue = u””i f os . path . e x i s t s (QUEUE) :

f = codecs . open (QUEUE, ’ r ’ , ’ ut f8 ’ )oldQueue = f . read ( )f . c l o s e ( )

username = ge t l o ca l u s e rname (SETTINGS)hashedPassword = ge t l o c a l pa s swo rd (SETTINGS)

i f type == ”sms ” :year = smstimeNice [ 0 ]month = smstimeNice [ 1 ]day = smstimeNice [ 2 ]hour = smstimeNice [ 3 ]minute = smstimeNice [ 4 ]epoch = smsEpoch

newItem = f i l ename + u ” | | \ t ” + type + u ” | | \ t ” +smsSender + u ” | | \ t ” + username + u ” | | \ t ” + hashedPassword+ u ” | | \ t ” + s t r ( year ) + u ” | | \ t ” + s t r (month) + u ” | | \ t ” +s t r ( day ) + u ” | | \ t ” + s t r ( hour ) + u ” | | \ t ” + s t r ( minute ) +u ” | | \ t ” + s t r ( epoch ) + u ” | | \ n”

newQueue = oldQueue + newIteme l s e :

( year , month , day , hour , minute , epoch ) =ge t cu r r en t t ime ( )

count = 0try :

(mcc , mnc , locationAreaCode , c e l l I d ) =l o c a t i o n . g sm locat ion ( )

except :t ry :

(mcc , mnc , locationAreaCode , c e l l I d ) =l o c a t i o n . g sm locat ion ( )

except :t ry :

(mcc , mnc , locationAreaCode , c e l l I d )= l o c a t i o n . g sm locat ion ( )

except :r e turn ”LocError ”

newItem = f i l ename + u ” | | \ t ” + type + u ” | | \ t ” +s t r ( locat ionAreaCode ) + u ” | | \ t ” + s t r ( c e l l I d ) + u ” | | \ t ” +

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

128username + u ” | | \ t ” + hashedPassword + u ” | | \ t ” + s t r ( year

) + u ” | | \ t ” + s t r (month) + u ” | | \ t ” + s t r ( day ) + u ” | | \ t ” +s t r ( hour ) + u ” | | \ t ” + s t r ( minute ) + u ” | | \ t ” + s t r ( epoch )+ u ” | | \ n”

newQueue = oldQueue + newItem

f = f i l e (QUEUE, ’w+ ’)f . wr i t e (newQueue )f . c l o s e ( )

i f UPLOADMODE == ” cont inuous ” :batch upload (TMP, QUEUE, UPLOADMODE)

de f batch upload (TMP, QUEUE, UPLOADMODE) :i f os . path . e x i s t s (QUEUE) :

f = codecs . open (QUEUE, ’ r ’ , ’ ut f8 ’ )oldQueue = f . read ( )f . c l o s e ( )count = 0totalNumber = oldQueue . count (u ” | | \ n”)f i v ePe r c en t = totalNumber / 20appuifw . note (u”Uploading ” + s t r ( totalNumber ) +

” items ”)ac tua lPercent = 5whi l e oldQueue != u”” :

f = codecs . open (QUEUE, ’ r ’ , ’ ut f8 ’ )oldQueue = f . read ( )f . c l o s e ( )i tems = oldQueue . s p l i t ( ” | | \ n”)items . r e v e r s e ( )item = items . pop ( )a t t r i b u t e s = item . s p l i t ( ” | | \ t ”)

l o c a lF i l e L o c a t i o n = a t t r i b u t e s [ 0 ]type = a t t r i b u t e s [ 1 ]i f type == ”sms ” :

smsSender = a t t r i b u t e s [ 2 ]username = a t t r i b u t e s [ 3 ]hashedPassword = a t t r i b u t e s [ 4 ]year = a t t r i b u t e s [ 5 ]month = a t t r i b u t e s [ 6 ]day = a t t r i b u t e s [ 7 ]hour = a t t r i b u t e s [ 8 ]minute = a t t r i b u t e s [ 9 ]epoch = a t t r i b u t e s [ 1 0 ]

e l s e :locat ionAreaCode = a t t r i b u t e s [ 2 ]c e l l I d = a t t r i b u t e s [ 3 ]username = a t t r i b u t e s [ 4 ]hashedPassword = a t t r i b u t e s [ 5 ]year = a t t r i b u t e s [ 6 ]month = a t t r i b u t e s [ 7 ]day = a t t r i b u t e s [ 8 ]hour = a t t r i b u t e s [ 9 ]minute = a t t r i b u t e s [ 1 0 ]epoch = a t t r i b u t e s [ 1 1 ]

i f type == ”sms ” :t ry :

done = add to db (TMP, type ,l o c a lF i l eLo ca t i on , None , None , username , hashedPassword ,year , month , day , hour , minute , epoch , smsSender )

i f done == u” f a i l − upload ” :appuifw . note (u”Connection

Problem , in fo rmat ion queued f o r l a t e r ”)re turn

except :appuifw . note (u”Connection Problem ,

in fo rmat ion queued f o r l a t e r ”)re turn

e l s e :t ry :

done = add to db (TMP, type ,l o c a lF i l eLo ca t i on , locationAreaCode , c e l l I d , username ,hashedPassword , year , month , day , hour , minute , epoch )

i f done == u” f a i l − upload ” :appuifw . note (u”Connection

Problem , in fo rmat ion queued f o r l a t e r ”)re turn

except :appuifw . note (u”Connection Problem ,

in fo rmat ion queued f o r l a t e r ”)re turn

oldQueue = u””f o r l e f tOve r in items :

i f l e f tOve r != u”” :oldQueue = oldQueue + l e f tOve r +

” | | \ n”

AP

PE

ND

IXE

.C

LIE

NT

CO

DE

129f = f i l e (QUEUE, ’w+ ’)f . wr i t e ( oldQueue )f . c l o s e ( )count = count + 1i f f i v ePe r c en t != 0 :

i f count % f i v ePe r c en t == 0 :

appuifw . note ( s t r ( ac tua lPercent ) +u”% of queue uploaded ”)

actua lPercent = actua lPercent + 5

i f UPLOADMODE == ”batch ” :appuifw . note (u”Queue Completely Uploaded ”)

Appendix F

Server Code

See chapter 5 for a description of the code that has been implemented. Due the vast lengthof the code listing, only a selection of files are displayed here. However, all files can befound on the cd included.

130

AP

PE

ND

IXF.

SE

RV

ER

CO

DE

131F.1 File: addItem.php

<?phpr equ i r e on c e (” i n c l ud e s . php ” ) ;connect ( ) ;

// check user e x i s t s / password c o r r e c t$ver i f i edUsername = f i l e g e t c o n t e n t s (” http ://www. pimtext . co . uk/ p r o j e c t /db/ ve r fyUse rEx i s t s . php?username=”.$ REQUEST[ username ] .”& password=”.$ REQUEST[password ] ) ;i f ( ( strcmp ($ REQUEST[ username ] , $ver i f i edUsername ) == 0)&& i s s e t ($ REQUEST[ username ] ) ) {

echo ”\nusername checks out : ” ;echo $ver i f i edUsername ;

} e l s e {echo ”\nUSERNAME OR PASSWORD BAD: ” ;echo $ver i f i edUsername ;

}

// v e r i f y f i l e o f that type e x i s t s$ v e r i f i e d F i l e = f i l e g e t c o n t e n t s (” http ://www. pimtext . co . uk/ p r o j e c t /up/ v e r i f y F i l e E x i s t s . php?type=”.$ REQUEST[ type ] .”& f i l ename =”.$ REQUEST[ f i l ename ] ) ;i f ( ( strcmp ( $ v e r i f i e dF i l e , $ REQUEST[ type ] . ” / ” . $ REQUEST[f i l ename ] ) == 0) && i s s e t ($ REQUEST[ f i l ename ] ) ) {

echo ”\ n f i l e e x i s t s : ” . $ v e r i f i e d F i l e ;} e l s e {

echo ”\ n f i l e does NOT ex i s t : ” . $ v e r i f i e d F i l e ;}

// i n s e r t i n to context username − use// my sq l i n s e r t i d to get the context id$query = ”INSERT INTO context ( username ) VALUES ( ’$ REQUEST[ username ] ’ ) ” ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ i n s e r t f a i l u r e at context ’ ) ;}$contextID = mysq l i n s e r t i d ( ) ;

// i n s e r t i n to type$query = ”INSERT INTO type ( typename , contextID ) VALUES( ’$ REQUEST[ type ] ’ , $contextID ) ” ;

$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ i n s e r t f a i l u r e at type ’ ) ;}

// i n s e r t i n to f i l e$query = ”INSERT INTO f i l e ( f i l ename , contextID ) VALUES( ’$ REQUEST[ f i l ename ] ’ , $contextID ) ” ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ i n s e r t f a i l u r e at f i l e ’ ) ;}

// i n s e r t i n to time$query = ”INSERT INTO time ( contextID , epoch , year ,month , day , hour , minute ) VALUES ( $contextID , ’$ REQUEST[ epoch ] ’ , ’$ REQUEST[ year ] ’ , ’$ REQUEST[ month ] ’ , ’$ REQUEST[ day ] ’ , ’$ REQUEST[ hour ] ’ , ’$ REQUEST[ minute ] ’ ) ” ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ i n s e r t f a i l u r e at time ’ ) ;}

// i n s e r t i n to l o c a t i o n i f not an smsi f ( ( strcmp ($ REQUEST[ type ] , ”sms”) != 0)){

$ l o c a t i o n r e s u l t = f i l e g e t c o n t e n t s (” http ://www. pimtext . co . uk/ p r o j e c t /db/addLocation . php? contextID=$contextID&l a t=$ REQUEST[ l a t ]& lon=$ REQUEST[ lon ] ” ) ;} e l s e {

$query = ”INSERT INTO l o c a t i o n ( contextID ,CountryName) VALUES ( $contextID , ’$ REQUEST[ smssender ] ’ ) ” ;


d i e ( ’ i n s e r t f a i l u r e at l o ca t i on ’ ) ;}

}?>

F.2 File: addLocation.php

<?phpr equ i r e on c e (” i n c l ud e s . php ” ) ;connect ( ) ;

AP

PE

ND

IXF.

SE

RV

ER

CO

DE

132$page = ”http ://maps . goog l e . com/maps/geo ?q=$ REQUEST[ l a t ] , $ REQUEST[ lon ]&output=j son&oe=ut f8&senso r=t r u e o r f a l s e&key=∗∗∗”;$ j son= f i l e g e t c o n t e n t s ( $page ) ;$decoded = json decode ( $ j son ) ;

$placemarks = $decoded−>{’Placemark ’ } ;$ f i r s tP la cemark = $placemarks [ 0 ] ;

$Point = $f i r s tP lacemark −>{’Point ’ } ;$ coo rd ina t e s = $Point−>{’ coord inate s ’ } ;$ lon = $coo rd ina t e s [ 0 ] ;$ l a t = $coo rd ina t e s [ 1 ] ;

$Addres sDeta i l s = $ f i r s tP la cemark −>{’AddressDeta i l s ’ } ;

$Country = $AddressDeta i l s −>{’Country ’ } ;$CountryNameCode = my sq l r e a l e s c a p e s t r i n g ( $Country−>{’CountryNameCode ’ } ) ;$CountryName = mysq l r e a l e s c a p e s t r i n g ( $Country−>{’CountryName ’ } ) ;

$Administrat iveArea = $Country−>{’Administrat iveArea ’ } ;$AdministrativeAreaName= mysq l r e a l e s c a p e s t r i n g ($Administrat iveArea−>{’AdministrativeAreaName ’ } ) ;

$SubAdministrat iveArea = $Administrat iveArea−>{’ SubAdministrativeArea ’ } ;$SubAdministrativeAreaName = mysq l r e a l e s c a p e s t r i n g ($SubAdministrativeArea−>{’SubAdministrativeAreaName ’ } ) ;

$Loca l i t y = $SubAdministrativeArea−>{’ Loca l i ty ’ } ;$LocalityName = mysq l r e a l e s c a p e s t r i n g ( $Loca l i ty−>{’ LocalityName ’ } ) ;

$Thoroughfare = $Loca l i ty −>{’ Loca l i ty ’ } ;$ThoroughfareName = mysq l r e a l e s c a p e s t r i n g ($Thoroughfare−>{’ThoroughfareName ’ } ) ;

$PostalCode = $Loca l i ty −>{’PostalCode ’ } ;$PostalCodeNumber = my sq l r e a l e s c a p e s t r i n g ( $PostalCode−>{’PostalCodeNumber ’ } ) ;

$query = ”INSERT INTO l o c a t i o n ( contextID ,

CountryNameCode , CountryName , AdministrativeAreaName ,SubAdministrativeAreaName , LocalityName ,ThoroughfareName , PostalCodeNumber , l a t , lon ) VALUES ( ’$ REQUEST[ contextID ] ’ , ’ $CountryNameCode ’ , ’ $CountryName’ , ’ $AdministrativeAreaName ’ , ’ $SubAdministrativeAreaName’ , ’ $LocalityName ’ , ’ $ThoroughfareName ’ , ’$PostalCodeNumber ’ , ’ $ la t ’ , ’ $lon ’ ) ” ;

$ r e s u l t = mysql query ( $query ) ;

i f ( ! $ r e s u l t ){d i e ( ’ i n s e r t f a i l u r e at l o ca t i on ’ ) ;

}?>

F.3 File: addUser.php

<?phpr equ i r e on c e (” i n c l ud e s . php ” ) ;connect ( ) ;$query = ”INSERT INTO user ( username , password ) VALUES ( ’$ REQUEST[ username ] ’ , ’$ REQUEST[ password ] ’ ) ” ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ i n s e r t f a i l u r e ’ ) ;} e l s e {

echo $ REQUEST[ username ] ;}?>

F.4 File: includes.php

<?phpfunc t i on connect ( ){

$con = mysql connect (”∗∗∗” ,”∗∗∗” ,”∗∗∗”) ;i f ( ! $con ){

d i e ( ’ Could not connect : ’ . mysq l e r ro r ( ) ) ;}mysq l s e l e c t db (” pimtextc PROJdpb24 ” , $con ) ;}?>

AP

PE

ND

IXF.

SE

RV

ER

CO

DE

133F.5 File: jpg upload to url.php

<?php// read the incoming image data handed over// from S60 phone$chunk = f i l e g e t c o n t e n t s ( ’ php :// input ’ ) ;

// c r e a t e a f i l ename based om time and a//random number$timestamp = time ( ) ;$random id = rand (0 , 1 0 ) ;$ f i l ename = $timestamp . $random id . ’ . jpg ’ ;

// wr i t e the f i l e to the s e r v e r in to the// jpg d i r e c t o r y$f i l epathname = ” jpg / $ f i l ename ” ;$handle = fopen ( $f i lepathname , ’wb ’ ) ;f pu t s ( $handle , $chunk , s t r l e n ( $chunk ) ) ;f c l o s e ( $handle ) ;

// re turn the f i l enameecho $ f i l ename ;?>

F.6 File: retrieval.php

<?phpr equ i r e on c e (” i n c l ud e s . php ” ) ;connect ( ) ;switch ($ REQUEST[ ques t i on ] ) {case ”typename ” :

$query = ”SELECT DISTINCT type . typenameFROM type , user , contextWHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = type . contextID ” ;$ r e s u l t = mysql query ( $query ) ;

i f ( ! $ r e s u l t ){d i e ( ’ i n i t i a l typename f a i l u r e ’ ) ;

}whi le ( $row = mysq l f e t ch a r r ay ( $ r e s u l t ) ){

echo $row [ ’ typename ’ ] ;echo ” | | \ t ” ;

}break ;

case ”CountryName ” :$query = ”SELECT DISTINCT l o c a t i o n . CountryName

FROM loca t i on , user , context , typeWHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = l o c a t i o n . contextIDAND context . contextID = type . contextIDAND type . typename != ’ sms ’ ” ;


d i e ( ’ i n i t i a l l o c a t i o n f a i l u r e ’ ) ;}whi le ( $row = mysq l f e t ch a r r ay ( $ r e s u l t ) ){

echo $row [ ’ CountryName ’ ] ;echo ” | | \ t ” ;

}break ;

case ” year ” :$query = ”SELECT DISTINCT time . year

FROM time , user , contextWHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = time . contextID ” ;


d i e ( ’ i n i t i a l time f a i l u r e ’ ) ;}whi le ( $row = mysq l f e t ch a r r ay ( $ r e s u l t ) ){

echo $row [ ’ year ’ ] ;echo ” | | \ t ” ;

}break ;

case ” sender ” :$query = ”SELECT DISTINCT l o c a t i o n . CountryName

FROM loca t i on , user , context , typeWHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = l o c a t i o n . contextID

AP

PE

ND

IXF.

SE

RV

ER

CO

DE

134AND context . contextID = type . contextIDAND type . typename = ’ sms ’ ” ;


d i e ( ’ i n i t i a l l o c a t i o n f a i l u r e ’ ) ;}whi le ( $row = mysq l f e t ch a r r ay ( $ r e s u l t ) ){

echo $row [ ’ CountryName ’ ] ;echo ” | | \ t ” ;

}break ;

}

f unc t i on g e t t a b l e ( $column ){switch ( $column ){case ” year ” :

$tableName = ”time ” ;break ;

case ”month ” :$tableName = ”time ” ;break ;

case ”day ” ;$tableName = ”time ” ;break ;

case ”CountryName ” :$tableName = ” l o c a t i o n ” ;break ;

case ”AdministrativeAreaName ” :$tableName = ” l o c a t i o n ” ;break ;

case ”SubAdministrativeAreaName ” :$tableName = ” l o c a t i o n ” ;break ;

case ”LocalityName ” :$tableName = ” l o c a t i o n ” ;break ;

case ”typename ” :$tableName = ” type ” ;break ;

case ” f i l ename ” :$tableName = ” f i l e ” ;break ;

}r e turn $tableName ;

}

i f ( i s s e t ($ REQUEST[ want ] ) ) {i f ( i s s e t ($ REQUEST[ excludesms ] ) ) {

$queryBody = ”FROM loca t i on , time , type , user ,context , f i l e

WHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = time . contextIDAND context . contextID = l o c a t i o n . contextIDAND context . contextID = type . contextIDAND context . contextID = f i l e . contextIDAND type . typename != ’ sms ’ ” ;

} e l s e {$queryBody = ”FROM loca t i on , time , type , user ,

context , f i l eWHERE user . username = ’$ REQUEST[ username ] ’AND user . password = ’$ REQUEST[ password ] ’AND user . username = context . usernameAND context . contextID = time . contextIDAND context . contextID = l o c a t i o n . contextIDAND context . contextID = type . contextIDAND context . contextID = f i l e . contextID ” ;

}

$want = g e t t a b l e ($ REQUEST[ want ] ) ;$want.= ” . ” . $ REQUEST[ want ] ;

i f ( i s s e t ($ REQUEST[ d i s t i n c t ] ) ) {$queryStart = ”SELECT DISTINCT ” . $want ;

} e l s e {$queryStart = ”SELECT ” . $want ;

}

$got = explode ( ” | | ” , $ REQUEST[ got ] ) ;$chosenAttr ibute = explode ( ” | | ” , $ REQUEST[

chosenAttr ibute ] ) ;$count = 0 ;$ r ebu i l d = array ( ) ;f o r each ( $got as $g ){

i f ( strcmp ( $g , ””)){$ tab l e= g e t t a b l e ( $g ) ;

AP

PE

ND

IXF.

SE

RV

ER

CO

DE

135$ r ebu i l d [ $count ] = $tab l e . ” . ” . $g . ” = ’

$chosenAttr ibute [ $count ] ’ ” ;$count = $count + 1 ;

}}

$queryEnd ;f o r each ( $ r ebu i l d as $rb ){

$queryEnd .=” AND ” . $rb ;}$query = $queryStart . ” ” . $queryBody . ” ” . $queryEnd ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ main r e t r i e v a l f a i l u r e ’ ) ;}whi le ( $row = mysq l f e t ch a r r ay ( $ r e s u l t ) ){

echo $row [$ REQUEST[ want ] ] ;echo ” | | \ t ” ;

}}?>

F.7 File: verfyUserExists.php

<?php

r equ i r e on c e (” i n c l ud e s . php ” ) ;connect ( ) ;$query = ”SELECT username FROM user WHERE username = ’$ REQUEST[ username ] ’ AND password = ’$ REQUEST[ password ] ’ ” ;$ r e s u l t = mysql query ( $query ) ;i f ( ! $ r e s u l t ){

d i e ( ’ s e l e c t f a i l u r e ’ ) ;} e l s e {

$row = mysq l f e t ch a r r ay ( $ r e s u l t ) ;i f ( strcmp ( $row [ ’ username ’ ] , $ REQUEST[ username ] ) == 0){

echo $row [ ’ username ’ ] ;} e l s e {

echo ” s e l e c t f a i l u r e ” ;}

}?>

F.8 File: verifyFileExists.php

<?phpi f ( f i l e e x i s t s ($ REQUEST[ type ] . ” / ” . $ REQUEST[ f i l ename ] ) ) {

echo $ REQUEST[ type ] . ” / ” . $ REQUEST[ f i l ename ] ;} e l s e {

echo ”does not e x i s t ” ;}?>

Exploring techniques for robust management and …mdv/courses/CM30082/projects.bho/2008-9/BUR… ·...

Documents

Transcript of Exploring techniques for robust management and …mdv/courses/CM30082/projects.bho/2008-9/BUR… ·...