E-community system for walkers and hikers Matthew Uttridge

E-community system for walkers and hikers
Matthew Uttridge
BSc Computing
(2006/2007)
The candidate confirms that the work submitted is their own and the appropriate credit has been given
where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered
as plagiarism.
(Signature of student)
Summary
This report details the plan and actions taken to produce a web based system providing walk groups
in the United Kingdom with a service allowing them to publish their activities and walks online.
The system needed to provide a registration system for users and groups and means by which users
can join groups in a manner meeting the requirements of both parties. In order to allow groups to publish
their activities a directory of walks is required, maintained and utilised by the public.
Because the public has such a large input into the content of the system it is necessary to include security measures to protect the interests of the site and prevent abuse. Likewise the privacy requirements
of a group must be upheld along with necessary legal considerations.
In order to accomplish the aims of the project a strict project management plan was required. As
expected problems and changes were encountered which were dealt with in a professional manner ensuring the plan was able to reach its milestones.
A key emphasis of this project was placed on emerging web development techniques and Human
Computer Interaction issues as required by the target audience, a demographic with low computer experience.
i
Acknowledgements
I would like to thank my family for their support during my time at university. In particular my
mother for her ’pep-talks’, my dad for his support and my brother for his advice.
A big thank you is owed to Dr Shaw for his time and effort during our meetings and for all the
walking information he has imparted to me. Also Mr Blackwell for his time and considerations when
demonstrating the system.
Many thanks to my project supervisor, Dr Hill, for her counsel and guidance during the course of
this project.
ii
Contents
1
2
Introduction
1
1.1
Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Project Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5
Relevance To Degree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.6
Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.7
Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.8
Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Background Research and Analysis
5
2.1
Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Current Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
Problem Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.3
External Existing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Choosing a Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
Methodology Shortlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.3
Justification of Chosen Methodology . . . . . . . . . . . . . . . . . . . . . .
13
2.2.4
Revision of Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Software Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.1
14
2.2
2.3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
2.3.2
Justifiying use of a Framework . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.3
Choosing a Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.4
Framework Shortlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.5
Justification of Chosen Framework . . . . . . . . . . . . . . . . . . . . . . . .
18
Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.1
Java Database Connectivity (JDBC) . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.2
Hibernate/ IBatis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4.3
Justification of Chosen Persistence . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4.4
Wicket/Hibernate Integration . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.5
Human Computer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6
Additional Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.1
Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.2
Google KML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.6.3
Weatherbug API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4
3
System Build
24
3.1
Learning Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.2
Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1.3
Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.4
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.5
Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.6
Data Access Object (DAO) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.7
Mock Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.1.8
Data Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.1.9
Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1.10 Wicket Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.1.11 AuthorisationStrategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.1
Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.2
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2
iv
3.3
4
5
3.2.3
Logic (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2.4
Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Further Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Testing
40
4.1
Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2
Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Evaluation
42
5.1
Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2
Aim, Objectives and Minimum Requirements . . . . . . . . . . . . . . . . . . . . . .
44
5.2.1
Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2.2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.2.3
Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3
System Acceptence Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.4
Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.5
Effectiveness of Background Chapter . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.6
Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.7
Project Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.8
Summary and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Bibliography
52
Appendices
54
A Personal Reflection
55
B Project Plan
57
C Sample Agenda
63
D Jakob Neilsons HCI Heuristics
67
E Model View Controller (MVC)
69
F System Pages
70
v
G Walk Finder
77
H Super Page
81
I
Unit Testing
82
J
Sample Usability Report
87
K User Feedback
89
vi
Chapter 1
Introduction
1.1
Aim
The project aim is to create an electronic system allowing walking groups to plan and communicate
their activities online, benefiting from techniques not available from their current system. This is to be
achieved through an understanding of emerging web development techniques, in order to develop new,
important skills in this area of Computing.
1.2
Objectives
• Establish the problem to be solved and the requirements of the user.
• Conduct background research on technological and sociological issues to ensure that the right
solution is produced and that it meets all the needs of the user.
• Formulate a schedule, detailing all necessary tasks, which allow for deliverables to be produced
on time.
• Carry out the procurement of the solution involving the necessary feedback from the users to
ensure that new requirements are captured and that software purpose remains on track.
1
1.3
Minimum Requirements
Minimum Requirements can be classified in distinct two areas:
• Group Leader Requirements
– A service which allows genuine group organisers to publish the group’s activities electronically.
– A service which can store and retrieve walk route information in a combined textual and/or
graphical manner.
– A service which provides group leaders with a directory of member contact details.
• Group Member Requirements
– Allowing registered members to join their group and have access to that group’s activities.
– A service which allows registered members to add, discuss and develop walking routes to a
persistent store.
– A service which allows registered members to review and comment on walks made by the
group.
– A service to allow abusive content to be reported by members.
1.4
Project Enhancements
Upon completion of the minimum requirements, possible enhancements include:
• An access system which allows group leaders to grant different access rights to group administrators allowing different levels of publishing rights within the site.
• Allowing registered members to upload media such as pictures and video of walk footage. These
could possibly be combined with the map in a way to pin photos to parts of the map.
• A mobile version of the solution allowing information to be viewed using hand held devices.
• Up to date weather information incorporated based on walk dates and locations.
• Advanced map interactivity allowing the creation of routes, features, points of interest and variations.
2
1.5
Relevance To Degree
The solution required relies upon all of the skills developed during the course of studies at the University of Leeds. In particular Building Distributed Systems (SY33) which formed a basis for designing
servlets. The project requires the storage of domain information which builds upon Database modules
(DB11) and (DB21). Introduction to Human Computer Interaction (GI11) plays an important role facilitating usability within the system. Finally a culmination of all the programming modules (SE10 SE24) provide the array of skills needed to implement the system.
1.6
Project Schedule
The project schedule is an essential tool needed to ensure that goals and milestones are achieved.
Scheduling for certain tasks, such as learning new tools, is difficult due to their undeterminable nature. Drawing and revising a Gannt chart can help to maintain perspective and provide targets to ensure
all areas receive the time and resources they need [5]. Microsoft Project allows the production of Gantt
charts detailing the Work Breakdown Structure (WBS). This allows a graphical intepretation of all task
needs, their dependencies with each other and their relation to the milestones of the project.
Appendix B shows the initial plan and its progression as challenges were faced requiring reprioritising of resources. Figure B.4 shows a significant schedule change due to the adoption of a new
methodology as discussed in Section 2.2.4. The 2007 semester has a larger number of tasks to reflect
the external workload of the student due to the choice of a 70:50 split of modules. This split was a
decision made in order to provide maximum resources to the crucial milestones of the project.
3
1.7
Milestones
Table 1.1 details all of the milestones set out in the project plan, and it’s revsions, in order to complete
the project. (See Appendix B)
Milstone
Description
Comment
Mid-Project Report
Submission of background chapter
Analysis / Design
Completion of design
Persistence
Completion of persistence mechanism.
Added to the project plan as a
de-escalation measure
Progress Meeting
Assessment of progress with Dr PM Hill and
Professor AG Cohn
Table of Contents
Submission for approval by Dr PM Hill
System Build
Completion of system
Testing
Completion of system testing
Evaluation
Completion of system evaluation
Report Due
Final submission of assessed report
Table 1.1: Milestones of the project
1.8
Deliverables
There are two deliverables for this project:
• The software system.
• The project report.
4
Chapter 2
Background Research and Analysis
In order to produce a valid solution a set of criteria defining the problem is required. Initially the problem is explicitly established through critical analysis and field research. This includes an examination
of existing services to see what is currently available to Walkers and Walking groups. Requirements are
established using Dr Shaw’s University Walking group as a case study. Once the problem has been defined, understanding the technical options and the factors which influence design along with a reasoned
choice of methodology will produce a clear path to the solution.
2.1
Problem Definition
Section 2.2.1 discusses agile workshops as an ideal solution to conducting system analysis. Perspective
Users can highlight the problem and help define requirements for a solution. The Walking domain is
well suited to workshops as they provide a way of establishing open lines of communication through
discussion and quick documentation using marker pens, post-it notes and flip boards [21].
5
The agile workshops take place over the course of the project to:
• Discover the problem and need for a system
• Discover the functional requirements of the system
• Discover the non-functional requirements of the system
• Provide a means of monitoring implementation
• Provide critical feedback for the interface of the solution
• Evaluate the implemented system
2.1.1
Current Implementation
Each month Dr Shaw organises a number of walks in the area for his group, the University of Leeds
Staff Walking Club. He produces an agenda containing the walks which are going to take place and the
details of each walk including meeting times, transport and availability of provisions along the walk.
Each walk has one or more leaders responsible for navigating the walk. This agenda is written in a word
processor and then emailed to his member list. Dr Shaw advised that the club’s members consisted of a
wide range of ages. Specifically he expressed a concern that an electronic system would need to allow
the older members to adapt comfortably to a web based medium.
The walks he organises can be categorised into three types; ambles, walks and hikes, which are
determined on length. He has kept paper records on such walks undertaken by the group for the last
twenty years. At the moment he does not use any electronic service for finding walks but was not aware
of such a service. He often has trouble locating walks of a certain nature, as an example he used ten mile
walks. This was primarily due to large numbers of five mile walks and large numbers of fifteen mile
length. Underlying trends dictating the numbers of walks of a certain distance are based on clusters of
abilities among walkers [26].
6
2.1.2
Problem Establishment
Upon discussion of the idea of publishing this agenda electronically, Dr Shaw seemed very interested
in the potential benefits. Instead of publishing an agenda he would simply have to select or add the
walks his group were going to be doing that month. The agenda would be formatted by the service. By
using the World Wide Web his agenda would be accessible by any one of his members anywhere in the
world with a web browser. Also this would provide a much better feedback mechanism on the walks
his groups undertake. A walk review system would allow walkers to add their comments and possibly
pictures on the walk that has been undertaken. If the reviews were not limited to the group, Dr Shaws’s
walk decision could be based on the opinions of anyone using the site.
He expressed a concern that some of his members might struggle using an web based electronic
service. In order to accommodate this two actions must be completed. Firstly in Section 2.5, Human
Computer Interaction (HCI) issues are examined in depth in order to ensure that the system excels in
usability and accessibility. It is essential that the design does not prohibit any users from being able
to use it. Trying to make the site as user friendly as possible would not be enough as some members
still would not be able to overcome the initial barrier of using the web. If Dr Shaw would still have to
produce an agenda anyways the purpose of the project would be somewhat defeated. Therefore it is important to incorporate a feature to generate a downloadable document from the agenda data. This could
be circulated to certain access-restricted members or provide users with a hard copy for reflection at a
later time. Judging from the visited sources, how walks are categorised is a matter of personal taste. The
system should not limit user searches in any way. An important heuristic of a walk is its difficulty. For
example Dr Shaw classifies difficulty as an amble, walk or hike. A group should be able to incorporate
feedback on walk difficulty aiding future users on the suitability of the walk.
Dr Shaw also disclosed the hierarchy of his group of which he was at the top as the administrator.
Each walk can have a number of leader(s) who are responsible for navigating the walk. He liked the
idea of maintaining a privilege system in the proposed electronic version. This would allow Dr Shaw
the ability to control which members could contribute to the system. For example, for a given member
he could grant leader privileges to manipulate data on a walk by walk basis. A feature he would like to
see is a reviewed database of walks to aid planning in the future.
7
Exisiting service
Walking to Health
Ramblers
RouteCards
My Service
Free
24
Free
Free
News/Info
?
?
?
Walk Group Locater
?
?
Joining Fee (£)
?
?
Create Walking Group
Walk Route Directory
?
Basic Maps
?
?
α
?
?
?
β
Advanced Maps (interactive)
?
Walk Reviews
?
?
Walk Organiser
α Walk searching may be achieved by adding links to other services.
β Advanced maps are a possible extension of the system.
Table 2.1: Summary of services provided by market leaders.
2.1.3
External Existing Services
Google provides an extensive list of walking related websites on the internet making an excellent starting place to research the walking field. Below are the most popular services and a summary of what
they provide can be found in Table 2.1.
Walking The Way To Health [9] offers a means of finding walking groups in the local area. By
entering a postcode, a list of local services are presented. They also offer news and events on national
walks and excursions.
The Ramblers [2] is a service allowing anyone to enter either grid references or post codes to find
a local walk. Walks are displayed in text format once located, and available walk dates are presented.
This service is aimed at people wanting to come along to a walk.
RouteCards [29] offers a comprehensive list of walks in the UK. This service seems popular due to
its extensiveness. However all routes are displayed in text without a ratings or any graphics.
8
Finding a Walk
Index
Example
By Area
Cumbria
By Specific Location
DN21 4F3
By Difficulty
Amble
By Length
15miles
Table 2.2: Finding a walk.
From Table 2.1 it is clear that the main competitor is the well established The Ramblers. This site
does have some overlap with the services provided with this project. However that product does not
compete with this project’s main goal which is allowing groups to plan their activities online. The Ramblers is a group in itself, organising national walks. It has to be taken into account that The Ramblers
is a premium subscription service. By offering free registration, competing services and greater level of
usability a competitive advantage can be established.
Looking at one of the most popular walking books available [26] and based on the websites visited,
searching for walks seems to be categorised in a number of ways as shown in Table 2.2. It should be
noted that example services indicated in Table 2.1 allow for search by any number of these descriptors
in any order.
2.1.4
Conclusion
The output of meetings with Dr Shaw defines a clear problem for walking groups needing an web
based system allowing groups to publish their walking agendas online. Dr Shaw’s group provide the
perfect case study for gathering the requirements of the system whilst ensuring the solution is not over
specialised to the groups specific needs. Forming trust with potential users provides them with ’Sense
of Purpose’ and the chance to benefit from the proposed system. This can improve the quality of the
analysis they provide, increasing the potential for a successful system [23]. The system’s functional
requirements form the minimum requirements and enhancements found in Chapter 1. Non-functional
requirements place strong emphasis on usability and accessibility. Careful attention is needed to ensure
not a only a working solution but one which translates into a successful service.
9
2.2
Methodology
2.2.1
Choosing a Methodology
There are various methodologies which can be employed to solve a software problem. They have specific advantages and disadvantages, the processes involved vary and ultimately will affect the success
of the project. By researching current techniques and analysing their possible adaptation to the project,
the most suitable methodology can be justified and selected. Methodologies can be defined into several
categories according to Scott W. Ambler [12] as shown in Table 2.3.
Code and Fix
Serial Rigorous
This technique invloves no methodology. In-
As suggested by the title, this category in-
stead a hands on and build first ask ques-
volves a serial progression of steps followed
tions later approach is taken. This results in a
by the developer.
chaotic system build which is often unplanned
through a mechanism between phases. The
and hard to schedule.
Waterfall Methodology is such an example.
Feedback is available
Iterative Rigourous
Agile
Similar to serial rigourous, there are a series
Agile approaches are people orientated. This
of steps to be followed out by the developer.
places a great emphasis on the needs of the
However these are followed in an iterative
user. User processes are modelled in great de-
manner. The first iteration is often used to
tail to ensure their tasks can be accomplished.
capture standard requirements and
The Agile Unified Process is such an example.
‘flesh out portions of the system’
[12].
Table 2.3: Methodology Classification
Code and Fix offers little help in getting the solution right or a framework for getting tasks done on
time. It is often used for micro projects. The other three categories all offer their own features and are
examined through example in more depth in Section 2.2.2.
10
2.2.2
Methodology Shortlist
Waterfall Model
The Waterfall model is one of the first conceived methodologies and an example from the serial rigorous
category. It was one of the first models used and its principles are still relevant to project management
today, as discussed by Leffingwell [23, Chapter 3]. A set of steps are defined to guide through the design
and build of a system. There is an element of backflow allowing a return to the previous step to address
problems discovered by the current process. This would allow the critical feedback needed from walkers
to influence the system at every stage. Larman [3] explains that integration and testing occur late in this
model and that an iterative approach includes these earlier, reducing chances of project failure. The Waterfall model places large emphasis on documentation of requirements through the analysis stage which
can be disregarded by more hands on, such as agile, methodologies which focus on getting something
working right away [21]. For the Walk system getting the requirements right is essential which bodes
well for this model.
Iterative Model
An Iterative model involves following the steps of the Waterfall model analysis, design, implementation etc. The difference being a sub group of these steps are cycled through a number of iterations
(Figure 2.1). ‘This allows the development team to demonstrate results earlier on and obtain valuable
feedback from system users ’[15, P. 4]. For the walking site this would prove valuable as the users don’t
have a system for comparison. Feedback is vital for discovering what the user really wants, and the
sooner this is done the better. An iterative approach is risk-driven but can be more resource-expensive
[3].
Figure 2.1: Iterative Waterfall Process
11
Prototyping
Using a prototyping methodology the developer straight away creates a prototype. This in turn is used
to provide feedback which is directed into the next prototype and so forth. This allows users to take part
in the construction process identifying problems early on, ensuring the finished product can integrate
well with users [21]. A common reason for project failure is due to a change in the user requirements
between the analysis and build processes [12]. Prototyping doesn’t clearly separate the analysis and
build stages allowing requirement changes to be integrated easily. This improves the chances of project
success. However, prototyping does not set out a plan of action or deadlines. This can be difficult for a
project such as the walking system which needs to tightly couple with a schedule [3]. As the developer
has the largest input to the system it may be hard to set about creating a walk system prototype with
limited prior knowledge. This may result in an unneeded iteration incorporating analysis which should
have taken place first.
Agile Modelling
Unlike the waterfall process, agile modelling does not prescribe a set of procedures to follow for software development. It focuses on modelling the problem and documentation through face-to-face analysis of the problem. McGovern [12] makes the analogy that agile modelling is more of an art than a
science. It is used as part of other larger models like the Rational Unified Process which fill the system
development gaps like programming and testing. Requirements are captured through informal meetings
and discussions using props such as white boards and post-its. This is very suited to the meetings with
Dr Shaw and can provide vital guidance.
12
2.2.3
Justification of Chosen Methodology
An iterative rigorous approach would be suited to this project as the design stage will need to incorporate
feedback from the systems users. This might suggest that prototyping would be the most appropriate
methodology. However, as pointed out, the prototyping model can encourage bad design habits and
ignore important factors involved in the design [3]. For this reason the iterative waterfall cycle will be
used. This methodology provides the useful steps needed to ensure the product is developed correctly
but also allows for learning between iterations. Because the software will be developed using a framework with which there is no experience, a framework exploration task will need to integrate with the
methodology to acquire the necessary skills (Appendix B.1). If the standard Waterfall model was used,
important design decisions need to be taken early, affecting the end outcome. Between iterations the
positives will be enhanced and the negatives removed and replaced. I intend to adapt the model to incorporate the attractive requirements techniques shown by agile models. In particular agile workshops
will be used to visualise the problem with walkers.
2.2.4
Revision of Methodology
During the beginning of the first iteration the chosen development framework, Wicket, showed signs that
fitting in with three iterations would be difficult. This is because the nature of the system build combined
itself with the framework exploration stage (Appendix B.3). Setting out to acquire the skills needed prior
to the build is an unfeasible task due to the size of the framework. Instead the build is structured around
learning and developing segments of the project. Because of this the three iterations are flattened into a
single Waterfall model. Larman describes a Waterfall model with evolutionary qualities [3]. He makes
the analogy between the system and a house which has a set of blueprints. When adding a service
or an extra room the entire house does not need to be rebuilt. This ties in much closer to the nature
of the chosen development framework, Wicket. Some problems can arise when rooms or services are
heavily interactive but as long as the blue prints specify the ’plumbing’ between them there should be no
difficulty. Because Wicket is object orientated all of the dependencies are resolved between the objects
which eliminates such ’plumbing’ problems. This change is reflected in Appendix B.4.
13
2.3
2.3.1
Software Solution
Introduction
The internet is the obvious medium on which the software will be published due to its undeniable popularity making it a highly accessible source allowing users access anywhere with a web terminal. The
World Wide Web is the application operating on the internet which will be used as an interface to the
software. This section looks into the various possibilities for publishing on the web.
Hyper text mark-up language (HTML) was created as a language for displaying documents sent
over the internet for viewing in a web browser. Traditionally these documents were static, pre-written
and transferred from a server to the client’s browser via the internet using the hyper text transfer protocol.
By allowing persistence of data on the server using a database and performing server side scripting to
dynamically create documents, a more interactive environment emerged. Scripting tools such as for
Hypertext Pre-processor (PHP) and Active Server Pages (ASP) execute on the server, allowing database
interaction, to return documents to the user. However, such tools are low level and as a result are code
intensive and can be difficult to scale to larger applications. Emerging frameworks provide a higher
level of abstraction allowing developers to concentrate on business logic and let built-in functionality of
mature programming languages take care of low level processing [16, Chapter 1].
2.3.2
Justifiying use of a Framework
• Most frameworks are object orientated. This allows Structured Query Language (SQL) mapping
between system objects and their persistent storage. This can be used to abstract database details
from the developer. Using mature persistence modules software benefits from expert experience
making more secure, scalable systems [4, p. 39].
• Built in libraries allow complicated components to be utilised instead of working from scratch.
Asynchronous JavaScript and XML (AJAX) is such an example which allows silent transfer of
information between client and server without page reloading.
• Frameworks and Application Program Interface’s (API) are created because of flaws or problems
with previous techniques. As a result frameworks have the potential for much more secure systems
than their predecessors.
14
• Frameworks are the result of experienced developers producing an answer to unsolved problems.
Utilising an already developed framework allows a new developer to benefit from an already
established standard.
• The learning curve for gaining skill in a new framework varies. Justfiying this can be questionable
when it is alternatively possible to produce a solution using primitive methods. However part of
the aim of this project is to explore new, emerging areas of Computing.
2.3.3
Choosing a Framework
Choosing the correct framework is difficult due to the large variety available. It will determine the time
needed and ease of the build process as well as putting in place a structure which needs to be updateable
and usable in the future. There is a large divide between those based in Java or Python and component
based or all encompassing frameworks. Turbo Gears [32] is a front to back-end framework taking care
of presentation, logic and persistence. Wicket [8] however is component based, leaving persistence
and presentation to the developer. Choosing a framework based on the fact that it is the latest or most
popular is unwise. Many frameworks have been created with specific uses in mind and can focus on any
number of factors in the system build. Before looking at a specific framework, establishing criteria is
essential in such a market.
• As applications grow, it is much simpler to separate application logic from the presentation. The
obvious way to do this is through the industry standard Extensible Markup Language and Extensible Style Language Transformation (XML/XSLT). They work similarly to the concept of
HTML and Cascading Style Sheets (CSS). That is that HTML/XML contain the raw data and
that CSS/XSLT shape the way the data is displayed. This is particularly useful as one of the possible extensions of the project is the GoogleMaps API which requires custom creation of XML
documents.
• Traditional development is done using standard text editors. However because some frameworks
are built in more developed languages they can be constructed using an Integrated Development
Environment (IDE). Eclipse is a good example of this for Java based applications. IDEs exist to
assist developers in generating software using build automation tools [33].
15
• Among the range of frameworks there is a large distribution of learning curves, as some are
light weight like Wicket, allowing users to generate web applications quickly. However Tapestry
[19] is a heavy duty framework which takes longer to become accustomed to using many XML
configuration articles.
• The frameworks vary in their hierarchical design. TurboGears is a front to back-end solution in
that the software is complete and handles all parts of the Model-View-Controller (MVC) design
pattern (See Appendix E). Most of the Java based frameworks use different modules to handle
various aspects of the application.
2.3.4
Framework Shortlist
TurboGears
TurboGears is hailed as a mega framework. This is because it brings together a number of mature components which are bound together by TurboGears application code. This binding is a step not present in
the other frameworks. It allows for the quickest get up and go time as it is installed as one application
providing TurboGears specific commands with all components under central control. It features excellent documentation and community help. Because it is bound together it is not as easy to customise the
modules within it. A drawback is that there is no possible integration with an IDE. It has an individual
and relatively simple deign technique consistent with the MVC design pattern (Appendix E). The model
in this case is the SQL Object relational mapper which instantly takes care of object persistence. The
view is handled by a plain HTML template system which is reviewable in a web browser and finally the
control is handled by Python functions.
Django [28]
Django is another popular Python based framework which roughly follows the MVC pattern. Full separation of the view and logic is provided similarly as TurboGears. In this case the view is the HTML
seen by the user and the logic would be processing of walk information for insertion on a page. Because it was developed for a news room environment it maintains a strong emphasis on dynamic content
and manipulation of different views to show the user what is required. Django benefits from an object
relational mapper to mediate between the Python objects and the relational database. One of the main
benefits of Django is the automatic administration interface. For example my application will need an
16
area for people to create walks through a data capture form. Django has built in functionality to code this
for the developer based on the object relational mappings. As a developer, Java knowledge far exceeds
that of Python. Although this is not a determining factor it must be considered. Although possible in
Python, Java is far more suited to Object Orientated (OO) design and perhaps is more suitable for this
project.
Wicket
Wicket is a lightweight framework which utilises HTML, as presentation layer, and Java code to render
wicket tags within the HTML. This allows pages to be developed separately from application code and
viewed in a web browser. It allows pages and content to be realised in an OO manor. This allows object inheritance from pages and seamless creation of clever page behaviours. A 1:1 mapping between
HTML and Java pages whilst allowing independent HTML creation eases the build process. Wicket
can be plugged straight into the familiar Eclipse IDE and deployed as a servlet using a web container.
This allows quick and easy development/deployment of applications. Wicket has built in functionality
to maintain the state of all objects on a page meaning that sending and retrieving messages from the
user doesn’t have to be coded by the developer. Finally, by maintaining a Plain Old Java Object (POJO)
mentality, all objects including pages and page elements can be re-used, reducing the need for redundant
code and hence development time.
Tapestry
Tapestry is a heavy duty component based Java framework. The installation alone was a demonstration
of the depth and breadth of the modular design. The learning curve is much higher for Tapestry as each
page is distributed between three levels, a feature not entirely necessary for this project but perhaps for
larger ones. The time taken to build the Hello World application was much longer comparatively to
Wicket.
17
2.3.5
Justification of Chosen Framework
Choosing a framework is extremely difficult and research alone is not enough to warrant such a large
decision. The only way to get a true feel for a framework is to create a basic prototype in each. In some
cases producing the first Hello World application is enough of an insight to remove it from the short
list as was the case for Tapestry. Wicket stands out, with its simplistic approach. It is based on a similar
structure to the familiar Swing framework used to create Graphical User Interfaces (GUI) in standard
Java applications as taught within the University. Python and Java pose no major advantages comparatively. However the previous development experience in Java is a key advantage. An introduction to
servlets is available in SY33 which gives a good foundation for Java web development. Both of these
additional factors confirm the choice of Wicket as the chosen framework. This choice will be considered
in the evaluation of the project.
2.4
Persistence
Wicket is a Java based framework which does not provide its own persistence strategy. Therefore it is
up to the developer to choose the correct implementation. Persistence in Java is a polarising topic in
which developers have split into different directions. It is necessary to examine the available options to
choose the most suitable method.
2.4.1
Java Database Connectivity (JDBC)
For a large proportion of the most popular databases, their developers have provided JDBC drivers which
act as an API for querying their database. In such a system the database is created and the necessary
JDBC driver imported to the program. This gives the developer access to query the database using
standard SQL. Java aids this development through the use of Prepared Statements which provides the
programmer with a way of encapsulating the main queries of the program for reusability. Also Prepared
Statements provide a safe way to query the database stopping attack techniques such as SQL injection
which is used to insert deviant code into a query. JDBC is often used when a database is already in place
and Java code is being written to query it, referred to as Database First [4, Part 1].
18
2.4.2
Hibernate/ IBatis
Open source projects like Hibernate and IBatis provide object relational mappings for systems where
the model has been implemented before the persistence has been considered. They provide much more
than JDBC, by allowing a natural object query language more in tune with the way objects are perceived
in the system. Such projects include their own drivers to configure themselves with a given database.
However unlike JDBC the model is independent of the database and therefore can be integrated into
any database platform given the correct driver. This decouples the persistence from its database choice
and provides a more portable system. Another attractive feature is that the developer does not have to
write their own SQL functions to join tables. Minimum additional code is required to annotate the Java
classes to allow them to be stored correctly.
This technique does require configuration with the given Java program, in this case Wicket. Although this can be difficult the Wicket community has several open source projects to act as a starting
point for understanding their interaction. Such implementations are referred to as Java First [4, Part 3].
2.4.3
Justification of Chosen Persistence
JDBC, the simplest option, is more code intensive and primitive. Construction is needed for all possible
necessary queries to operate the program. The object relational mapping by Hibernate provides a clean
solution, removing the need for so many complicated queries. The analysis stage provides a clear
set of objects such as Walk, Event, User which are easily intepreted in Wicket. It makes sense that
the OO mentality is carried through in the choice of persistent storage. As discussed above there are
configuration challenges which may be time consuming. However the benefits heavily outweigh the
setup challenges. Because there is no initial database set up, Hibernate allows the database to grow
and change in a natural way performing all structural changes automatically. Changes in the model are
instantly reflected in the database. This makes the system more flexible to possible changes in the future
without the need for database administration. As stated in the aim of the project, using new techniques
is attractive although not to the detriment of the project. The School of Computing at Leeds provides
a PostgreSQL which will be used to develop the application. The protable nature of Hibernate allows
continued development away from the School using a MySQL database by only changing two lines of
code.
19
2.4.4
Wicket/Hibernate Integration
The Spring Framework is a powerful programming model built around POJOs such as those used by
Wicket. Essentially it provides a way of managing objects in the system and taking care of the ’plumbing’ between persistence and presentation through the use of object factories [20, pp. 149]. In order for
Hibernate to work with Wicket, Spring must be incorporated to provide this middle service. Gurumurphy explains the difficulty in doing so.
• Wicket is an unmanaged framework which allows instantiation of objects from anywhere within
Java code using the new operator. Many frameworks are managed and do not allow this, including Spring, which controls the manner in which objects are created. In order to overcome this
mismatch an XML configuration file details which objects are controlled by Spring and these are
instantiated separately by Spring when the application is launched [20, pp. 150].
• Wicket objects are serialisable so they can be transferred and deserialised for storage in a session
object for a given user. Because Spring injects dependencies on objects they also get serialised.
This is undesirable as dependencies often have their own dependencies which in turn get serialised
causing a cascade which could cause failure due to memory over consumption. An open source
project targeting integration of the two has overcome this problem to create a SpringWicket
application replacing the standard Wicket application [20, pp. 151].
20
2.5
Human Computer Interaction
Hewett [11] defines Human computer interaction as ‘a discipline concerned with the design, evaluation
and implementation of interactive computing systems.’ The way the user perceives, navigates and interacts with the service is very important. Usability is a determining factor in the success of a system.
If the users can not find a successful path through the system it will not be used and fail. Therefore a
Walker needs a clear path to each of their goals.
Nielsen [25] provides a framework consisting of ten heuristics or principles which provide rules
of thumb for producing successful usability through a system (See Appendix D). These ten rules will
be used when designing the system interface to help reduce the effort needed by the user. Usability will
also help to determine partial success of the system through the feedback of testing users.
Shneiderman [30] says ‘Accommodating a broader spectrum of usage situations forces researchers
to consider a wider range of designs and often leads to innovations that benefit all users’. Bearing that in
mind it will be very important to carry out thorough research into the possible tasks of the system. This
is achieved through the agile workshops set out by the methodology to provide an interactive discussion
into what walkers and walk leaders need to do and the ways in which they can be achieved. By procuring
constant feedback from the users, innovations can be incorporated before design has progressed past the
point of plausible modification.
One of the biggest problems facing this project is the transition of the member from a paper/email,
word processed based agenda to the electronic service. The GNOME Usability Study Report [14] identifies the advantage taken from building a match between the system and the real world. ‘By using
metaphors and familiar ideas, and by making them simple and straightforward, the user can apply their
experience with the old system to navigate the new.’ [14] This will be essential in providing a swift
transition to the electronic service. This can be done using the sample agenda provided by Dr Shaw
along with discussions with walkers (See Appendix C).
The internet provides a series of tools which analyse and report on a web sites accessibility encouraging access by the largest possible audience. This will also help form part of the evaluation.
21
2.6
2.6.1
Additional Tools
Google Maps
GoogleMaps [7] is a service which allows maps to be displayed as interactive objects within a webpage.
Google provides an API which allows such maps to be embedded within a web page. On top of the basic
map, any number of controls to be added. This allows the map to be displayed as either a road map,
satellite picture or a hybrid of the both. This can allow users to view the actual location of the walks and
perhaps see how far away they are from it. The API is extensive not only allowing full control on how
the map is displayed but what the user does to it. For example the application can look at where the user
navigates on the map. Figure 2.2 is an example of the API in action using a polyline, blue, and markers,
red. In this example the polyline could be the walk route and the markers could be points of interest.
Figure 2.2: Markers and Polyline example
Figure 2.3: Expanded marker with information box
22
2.6.2
Google KML
‘KML, or Keyhole Mark-up Language, is an XML grammar and file format for modelling and storing
geographic features such as points, lines, images, and polygons for display in Google Earth, Google
Maps’ [6]. This builds on the functionality provided by the Maps API but would allow the production
of walk documents in XML format. Because XML is universal and not just a way of using Google Maps
it is future proof and is transferable to any platform.
KML documents can specify icons, labels, and locations. The entire KML language is designed
for Google Earth and only a subset of the feature is compatible with Google Maps. However all the
features needed to produce a walk are available. The KML documents are combined with the map as
an overlay to produce maps like those in Figure 2.3. By storing KML elements in a database further
user based information can be linked to markers on the map. This could be used to link user photos to a
certain marked location.
2.6.3
Weatherbug API
The WeatherBug API [22] allows up-to-date and accurate weather readings. This will add even further
value to the service. Take the example of Dr Shaw deciding to organise a walk on the 17th of October
using the online group agenda system. If he enters geographical data on the walk route the WeatherBug
API could be used to draw together live weather information for the area of the walk and possibly in
the future weather predictions. Unfortunately some of the main functionality is only available in the
United States of America. In the future this could be added possibly as an extension of the project if the
preliminary tasks succeed.
23
Chapter 3
System Build
This chapter documents the build process, which created the final system as set out by the project plan.
A large part of the construction was learning the chosen framework, Wicket. The learning experience is
largely mirrored by the examples and lessons from the book ProWicket [20].
The implementation of the services upon which the system is built follows. The feedback from
walk users proves crucial to re-design, evolving the interface. Many obstacles stood in the way of the
build process but strict project planning and task management prevailed to produce the working solution.
3.1
3.1.1
Learning Wicket
Introduction
Wicket is a Java framework based on the Java 2 Platform, Enterprise Edition (J2EE) which is used to
create server side Java applications [13]. As discussed in Section 2.3.3, Eclipse will be used as the IDE
to code the solution. In order to run a Wicket Application it must be launched in a web container which
provides the run time environment needed by the Wicket servlet. Tomcat [18] is such a service which
has a useful plug-in for Eclipse which allows publishing from within the Eclipse IDE for viewing in a
web browser.
24
A servlet is launched through its web.xml configuration file and Wicket is no exception. Web.xml
tells Java where the main application is, along with any other useful information such as that mentioned
for Spring (Section 2.4.4). A Wicket application specifies a class which extends a Wicket WebApplication. By doing so abstract methods must be implemented which specify a home page class which is
rendered and displayed to the browser.
3.1.2
Principles
Because Wicket is a technology not familiar to the developer, a learning process took place before
and during development. ‘Pro Wicket’ [20] gave an excellent introduction to the principles behind
Wicket through explained examples. It is a component based framework analogous to the way the Swing
framework behaves in Java GUI applications [20, Chapter 1]. Within the Wicket object hierarchy, all
the HTML components such as a page, form or textbox are types of components which can be treated
with normal Java behaviour. This has major advantages:
• Using inheritance, components such as pages can inherit from a super class page which maintains
a default look and feel. This can help from a HCI point of view allowing the user to become
quickly accustomed with the service. (Nielsen’s heuristics - Appendix D)
• Re-using code reduces the development period by allowing quick system-wide changes. For
example, if a developer is using a login form in many places, they merely need to change the
login form object to update the behaviour of its use throughout the entire site.
• An object orientated approach allows for the development of a future-proof system. Objects can
be naturally extended or changed without the need to modify dependent code. By programming
to interfaces the key roles of an object are clarified and the way which they are carried out hidden.
This allows the programmer to change or swap implementations of an interface without needing
to modify objects which use them [31]. This technique is used in the persistence of the walk
service as seen in Section 3.1.5.
Traditionally, web based solutions have tended towards the MVC architecture (See Appendix E).
Instead Wicket is event-driven, attaching listeners to components which monitor the actions of the user.
This allows for a much more responsive system and one which steers away from the stateless nature of
the internet.
25
Figure 3.1: How the HTML and Java files work together
3.1.3
Pages
Section 3.1.2 explains how the Java side of Wicket works. An equally important issue is how the page
gets rendered. Each wicket page is composed of two main articles; the Java class representing the business logic and the HTML file which contains details of how the page is rendered as shown in Figure 3.1.
One of the most attractive features of Wicket is the full separation of logic and presentation. Wicket uses
vanilla HTML files, as shown on the right, which means they do not contain any platform specific Java
scripting or code [8, Section 2]. Instead a simple wicket:id attribute is attached to HTML components
which have a 1:1 correspondence with wicket components specified in the matching Java file. Gurumurphy [20, Page 8] explains how when a Page object is requested, its render() method is called, which
locates the corresponding HTML file delegating rendering responsibility to the connected components,
skipping those attributes not containing the wicket attribute.
In practice this technique allows the Java and design teams to work in complete separation with out
needing detailed knowledge of each other’s implementations. This does not apply for the purpose of this
project as the designer is the coder. However it means that the design and HCI, highlighted as important
through the agile workshops, can be developed and modified separately from the logic implementation.
26
Figure 3.2: Effective use of a compound property model
3.1.4
Models
The final lesson to Wicket’s methodology is the model. A model is an object which acts as a data source
for a component, specified upon construction, allowing a component to store and edit its state or value.
This can be explained using an example as shown in Figure 3.2. It shows a form whose purpose is
to capture input creating a new User object. In such a system a User class would be defined to store
details such as name, address etc. In order for the form to capture data it needs to store the field values
somewhere. Gurumurphy [20, Page 15] explains how to do this in two manners. The first, expensive
way, combines the form and the model in the same class by creating form components and variables to
store their values through respective getters and setters. The second, better way is to create a User object
and set it as the form model by way of a CompoundPropertyModel. This removes the redundant code
of replicated getter and setter methods on the form. Wicket then associates the component and model
through their names. When the developer wishes to analyse the state of the form they simply obtain the
model, cast it to desired object and use the native getters to ascertain its state.
27
An important structure feature of Wicket is that models must implement Serializable which is a
standard Java feature, allowing them to transfer as a byte stream. This is because Wicket stores both
components and their models in memory through a Session object. This can have scalability issues for
server load when many users are storing sets of objects. Wicket does however have a solution for this in
the form of Detachable Models as discussed in section 3.1.8.
3.1.5
Business Objects
Employing Wicket’s POJO methodology, the data which is captured, manipulated and displayed in the
application will be used as Java business objects. Analysing the problem domain with Dr Shaw produced
the following objects:
• User, for storing the user profile.
• Group, for storing details of the group.
• Walk, for storing deatils of walk route.
• Review, for storing a review of a walk route.
• Event, for storing details of a walking event. E.g. walk route, day, time.
These objects are constructed in the same way any Java object would be. This invloved declaring
the instance variables for the object and then providing a series of getter and setter functions to access
and change the state of the variables. The only addition to these business objects was the annotation of
the variables which allows Hibernate to create the required mappings from the objects to their persistent
store in the database. This is discussed in more detail in Section 3.2.1.
3.1.6
Data Access Object (DAO)
Alur [10] discusses J2EE design patterns to solve certain problems. Patterns are useful as they are
proven, re-usable expressive techniques to solve problems encountered frequently [24]. A core set of
functionalities are required to handle the persistence and retrieval of the business objects. Instead of
mixing this code with the actual business logic a better practice is to encapsulate object functionality
in a DAO [10, Chapter 8]. Decoupling business and persistence logic provides a more flexible system
capable of plugging different persistence units as and when requirements change. It also allows for a
28
smaller granularity of tasks allowing services to depend on persistence instead of implementing it. For
the application a DAO was created for each of the business objects mentioned in section 3.1.5. Each
DAO defined an abstract class describing the functionality an implementation must provide. As an
example the WalkDao describes methods which store and retrieve walk object(s). The WalkDaoImpl
implements that DAO providing Hibernate methods in accordance with the interface.
3.1.7
Mock Objects
When developing the first Wicket applications, having a fully functional DAO implementation can be
overwhelming so during the Framework Exploration stage mock objects were used. This demonstrates
the benefit of designing to interfaces, as primitive DAO implementations can be created carrying out the
desired functionality in a simple way. The most basic DAO implementations stored business objects in
an ArrayList. This simple solution initialises objects into an ArrayList when the application starts up.
Once the application restarts the ArrayList is initialised again, losing any changes. The Java ArrayList
has built-in functionality suitable to a DAO to allow sorting and selection of the objects it contains. This
technique allows the developer to concentrate on other parts of the system dependent on a DAO without
having a final implementation finished.
3.1.8
Data Providers
Section 2.3.4 mentions that Wicket places key emphasis on re-usability of code. Wicket has a series of
Java archives (JAR) containing not only the core API but also a series of extension packages. Among
these are an important set of repeater components. As suggested by their title they iterate over a set
of objects to create a tabular output. An example of this is the table containing all the Walk objects
allowing users to view and select a walk. Wicket Data Providers, which implement IDataProvider, act
as an iterator over a subset of data [20, Page 79]. So a WalkDataProvider would be used to return an
iterator on a set of Walk objects which could be displayed by a Repeater Component.
One such implementation uses a Filter object to control the subset of data. An example of this is
shown through the walk finding service (Figure 3.3). In this example a table of walks is displayed and
at the head of each column a user entry is available. These user entries combine to form a special Walk
object called a Filter. When the table is updated this object is passed to the Data Provider which it uses
to select only walks which match the filter, for display in the table.
29
Figure 3.3: Implementation of a Filter object and DataProvider
Repeater components give built-in functionality designed by the people who built Wicket, such as
sortable columns and pagination of data. Of course such functions as the Filter object require matching
DAO methods to retrieve appropriate objects. It would be feasible to return a full list of objects and
then crop them based on the Filter object. However this requires much more memory to serialize all
Walk objects and as the database grows this could be inefficient resulting in long wait times for users.
As mentioned, Wicket stores components and their models in memory. To stop this from becoming a
performance problem Detachable Models are provided as a lightweight wrapper. Such models remove
a large section of an object’s state reducing its memory footprint by merely maintaining a minimal
amount of information such as an ID. When an object is in this state it is detached, re-attachment is
then possible via the persistent store through the ID [20, Chapter 3].
3.1.9
Validation
Validation of user input is crucial to ensuring data integrity, whether it is someone’s email address or
the distance of a walk. In order to validate input some form of checking logic is required to ensure the
data is as expected and secondly a method of providing feedback to the user is needed to inform them
of errors. Wicket provides a very basic repeater component called a FeedbackPanel which can be used
to display types of message to the user such as an error message on a form submission. As for the logic
there are several options.
30
• A Form object has an overridable method onSubmit which is called when the user submits the
form. It is possible to obtain the values from the user by analysing the form model and then
passing a message to the FeedbackPanel using an info( ) or error( ) method. This method mixes
validation with form submission code which is undesirable.
• A better way is to use a validation listener component which can be attached to a Form component
during page contruction. When a form is submitted a validation procedure takes place before the
form reaches the onSubmit method. This allows cleaner code using the onSubmit method for it’s
true purpose which is processing data such as storing a Walk object to the database. The Wicket
API has many built in validators for defining the input type such as String or Float and range
checkers for numbers. All validators implement the IValidator class which allows the developer
to create their own validation classes which are re-usable. This technique was used to ensure
email addresses were valid on the new User form.
3.1.10
Wicket Session
All servlets have an underlying HttpSession which is used to handle communication requests between
the Server and Client. Wicket developers decided not to allow direct access to this session but to develop
individual application sessions implementing the IWebSession interface, which in turn gets placed into
the HttpSession by Wicket. The main Wicket application file defines which session object to use, in
this case a custom WalkSession. All Wicket objects can gain access to the session object through the
getSession method.
When a user logs in, their User object is placed into the session so that the application can have
quick access to information used for customisation such as welcome greetings and user specific menus.
Some pages require the user to be logged in as discussed in Section 3.1.11. Accordingly, a WalkSession
object was created which allowed a User object to be placed into memory. A supporting method was
implemented which returns a Boolean reflecting whether the current visitor is logged in. This makes
more sense than storing temporary session information into the database. This prevents any user from
masquerading as someone else preventing malicious actions of users trying to jeopardise groups which
is an anti-abuse requirement of the project.
31
3.1.11
AuthorisationStrategy
An important security feature of Wicket is allowing ComponentInstatiationListeners to detect when
an object is created. This allows custom rendering of a page depending on a User session variable
such as whether they are logged in. Page objects can be instantiated anywhere unless they contain
Authorisation annotation. In such a case the Wicket Authorisation Strategy is consulted to see whether
it should be allowed to be rendered. The IAuthorisationStrategy is an interface defining the following
methods:
• isObjectAuthorized - This checks the object in question for annotation dictating a need to authorise.
• isAuthorized - This checks whether the current user has the necessary credentials to authorize
a secure object’s instantiation. In the case the walk project, this looked at the User object in the
session to see if they are logged in.
• onUnauthorizedInstatiation - This method details the action to be taken if the user fails the
authorization requirements [20, Chapter 3].
An AuthorisationStrategy implementation was created to handle pages which require a user to be
logged in. To further simplify development a second abstract, generic Walk page (See Section 3.2.2) was
created for implementations of secure pages. This meant when constructing a page it either extended
the WalkPage class or the SecureWalkPage class. The SecureWalkPage class contained extra annotation
to be used within the Authorization Strategy. When a user tried to instantiate a secure page without
the correct credentials a RestartResponseAtInterceptPageException is thrown which directs users to the
home page to login. If and when the User does log in this Exception is completed and the user is
automatically redirected to the action they were trying to complete. If the user was trying to comment
on a walk without being logged in such an Exception would be thrown. The advantage of this exception
is that once they are logged in the walk review form submission would automatically conitinue without
them having to re-write the review.
32
3.2
3.2.1
Implementation
Persistence
A DAO needs to be accessible from many places within the application. However it does not make
sense to instantiate a new DAO every time it is needed. This could result in a large number of DAOs
being placed into memory causing performance and scalability issues. Secondly and more importantly,
although hidden from the developer, the DAO manages database transactions through Hibernate. In
order for this to work correctly it needs to be able to keep track of what queries have been processed and
the state of the DAO. In order to do this the DAO must be kept open which does not fit in with Wicket’s
object life strategy. The solution is to have Spring objects declared through the web.xml file and created
by Spring. Within the Wicket Java classes these objects are then defined as instance variables but not
instantiated. Instead they are either annotated or defined in another xml file. Wicket can use these objects even though it did not instantiate them. Behind the scenes Spring provides a proxy which allows
access to the specified objects, without ever having to serialise them. Spring needs to be aware of the
relationships of the objects to be instantiated, which are detailed in the ApplicationContext.xml file.
This document also contains Hibernate configuration details which are needed to access the database.
This includes the database URL, user name, password, SQL dialect and the database driver.
Configuring Spring and Wicket proved very difficult due to the complexity and poor documentation, leading it to be the largest problem encountered during the build. All other parts of the development
were from within Wicket using the provided API which proved much simpler. From both the Wicket
and Spring development websites it was obvious that is a current problem, with solutions changing and
being updated regularly. Each release of Wicket and Spring needs a slightly different method of integration which lead to many failed attempted implementations.
Although the theory behind the Spring/Wicket integration was eventually digested through the literature and examination of examples from the web, finding a working solution began to prove difficult.
As the project plan progressed it became obvious that this problem was beginning to swallow resources
and other areas of the project were beginning to suffer. After consultation with Dr Hill another deadline
was added to the project plan in order to limit the resources available to the problem (See Apendix B.5).
After that, persistence would have to be carried out in a primitive manner as described in Section 2.4.1,
33
or removed from the scope of the project. Taking time to assess the problem led to the solution through
the use of a Wicket project called Qwicket [1]. Qwicket is designed to help start Wicket project developers by producing all of the configuration code automatically and is ready to work with Spring. Qwicket
structures the project slightly differently from the way the design had been sofar implemented, however
it could be modified to incorporate the work which had been done so far. This solved the persistence
problem allowing continued development of the rest of the project.
Once Spring was integrated the Hibernate DAO implementations could be created. This was simple as their methods had been defined in the DAO interfaces and all that was required was implementing
the methods to query the database. Hibernate uses its own Hibernate Query Language (HQL) which
is independent of any database implementation. A database driver is used to transform the HQL into
the required SQL query for the given database, in this case PostgreSQL. HQL queries, although new to
the developer, are simpler due to their natural language qualities, similarity to SQL and simplification
due its object orientated nature. The Qwicket project utilised an AbstractHibernateDao which formed
the basis of all DAOs. The abstract class defined common functionality for all DAOs such as saving
and finding objects. By making the class as generic as possible an implementations definition informs
the AbstractHibernateDao of the type of object it deals with. This allowed a single save method to be
applicable to all DAOs reducing code.
The final step was making Hibernate aware of the database schema by documenting which objects
need to be persisted. The ApplicationContext.xml file documents a list of business objects. To create
the actual mapping between instance variables and table fields the developer can either use an XML
document or annotate the object classes. Although this implementation could not avoid XML, Wicket
was designed to. Keeping with that ideaology the annotated method was chosen. Each variable declaration is accompanied by a line defining column details such as size and any other desired constraints.
It also defines which variable is the primary key of the table. When the application launches it checks
the database for the existence of the required tables and if not present takes care of their construction
automatically.
34
3.2.2
Presentation
Nielson states that applying consistency and standards to an application allows users to become accustomed with a service quickly allowing recognition rather than recall D. Accordingly it was decided
that a consistent look and feel should be implemented across all of the pages. Wicket’s hierarchical
nature enables this through the use of abstract classes. A abstract class extending a Wicket WebPage
was designed which laid out the toolbars, options and menus but held no content. Service pages extend
the template to add their own specific content (See Appendix H). This is a familiar concept from Java
programming, however HTML does not naturally fit this solution. Wicket overcomes this through the
use of the < wicket : child/ > tag which is placed in the abstract class HTML page. When a service
page is loaded it inserts its own HTML replacing this tag with its own code. < wicket : extend > tags
are used to surround the code to be inserted. This allows the HTML developer to insert supporting code
around content for design purposes to develop the service page in a browser. When the page is rendered
by Wicket this supporting code is ignored.
Programming this way allows system wide changes to be made through editing just the abstract
class which proved valuable when feedback from users required alterations to the ergonomics to make
the system more user friendly. HTML standards are used to ensure the validity of the code. Doing so
requires the removal of all page style into a separate CSS file which tells the browser how to render each
component. Again this allowed a system wide CSS file which dictated how all common components
should be styled ensuring consistency and familiarity for the user. These techniques were used to provide pages to carry out the required facilities. A full list of the pages, their jobs and screenshots can be
found in Appendix F.
Wicket allows for complete separation of HTML and Java so that their respective developers can
work independently. The HTML coding takes significantly less time than the underlying Java but holds
just as much importance as it is the interface to the system. It also is responsible for guiding the user to
accomplish their goals. Section 3.2.3 explains how services were implemented in turn. When this took
place the HTML was coded first and provided a quick prototype to present to perspective users. Making
alterations at this stage was much easier than after it was functional. Once satisfied with the presentation
of a service, the underlying Java code was implemented, providing the logic.
35
The abstract page class is responsible for displaying the correct links for a given user which varies
for each user logged in. To accomplish this a series of Wicket Panels were developed containing links
for a given section such as Events or Groups. Wicket Panels work much in the same way as the <
wicket − extend > tags. The abstract class page analyses the member in the session and renders
only the relevant panels. This allows personalisation of menus for a given user which again improves
usability. Situating this code in the abstract page meant that service pages really only concentrated on
the service.
3.2.3
Logic (Services)
Figure 3.4: Gotcha, Captcha
The services set out by the requirements were built using the evolutionary project methodology.
Firstly the structure was implemented providing the frame onto which services could be plugged in. This
involved creating the business objects of the system and providing the necessary DAOs to manipulate
them. Although the services could be added independently they depend on the correct structure being
in place (Section 2.4.4). The first service to be added was the User system. This allowed a visitor to
become a registered member. Preventing abuse of the system was a highlighted need from Dr Shaw.
Figure 3.4 shows a generated image containing text only viewable with a browser. When a visitor
decides to sign-up they are required to enter the text as shown in the graphic which prevents someone
from creating a script to automatically sign up members.
36
In accordance with the analysis, a member can either be a:
• Unconfirmed registered member
• Confirmed registered Member
• Group leader
• Unconfirmed group member
• Confirmed group member
• Walk leader
In order for a member to be confirmed they must reply to an email sent to the address provided on
the sign up form, this ensures that the user is valid and again an anti-spam feature. If someone wanted
to abuse the system they would have to complete these steps before being allowed to publish any information. This service is dependent on a forwarding mail server and hence disabled in development.
The next service is aimed to allow a member to create a Group and become a Group leader. This
involves creating a Group object and changing the status of the member to group leader. Once a group
was created the leader can access the Group homepage. From there they can view all members in a
sortable repeater component, allowing filtering to give them a search mechanism. From this page they
can also confirm a member or change them to a Walk leader. In order for a user to join they must apply,
which then registers them on the leader’s member table. They can not access the Group home page
until they have been confirmed. During one of the feedback meetings Dr Shaw requested the member
confirmation feature as an addition so that a group has the option to make its agenda private.
The walk service needs to allow the adding, viewing and searching of walks. After implementing
capture techniques for the User and Group objects, creating the Walk form was easy following the specification produced by the analysis. Using the HTML first approach described in Section 3.2.2 feedback
was obtained allowing the uncovering of a problem before the full implementation. Dr Shaw immediately noted that a Walk can take place in more than one county. Using this system an extra attribute
was added to allow a finishing county. Displaying a selected Walk was simply a case of presenting the
object appropriately using a series of HTML components. Providing the Walk finder required a repeater
37
component which allowed searching on any number of the Walk fields. Providing a suitable DAO search
function was a complicated task which involved anticipating a complex HQL query. The query needed
to check for the presence of a sort parameter indicating the user selecting a column to organise the walks
upon, for example by distance. It then needed to analyse the Filter object and check for the presence of
any field to filter the walks by. For example, if the user wanted walks only starting in Cheshire. Finally,
because the repeater component is paginated it needed to check the number of walks to be returned and
the starting point, for example, the user selected page 5 of results. A screen shot of this table and the
required DAO function can be found in Appendix G.
Constructing the first three services brought experience with Wicket which meant implementing
the Event system and Review system became much more routine. The Event object acts like a wrapper
for a Walk object giving it a date and time. The capture for this was simple which just left displaying them chronologically on the group home page. Date capture was made simple using a custom
DatePicker component which gives a much better look and feel, similar to that of the operating system
(See Appendix F for screenshots).
Adding reviews utilised much of the knowledge acquired through the work already done. An extra
feature of the requirement was the use of a StarBar component which allows AJAX selection of the
walk rating by clicking and selecting the number of stars (See Figure G). Reviewing a walk requires
the user to be logged in to stop vandalism of the site. Should malicious content be published a flagging
system was implemented so that users can report a walk as having an abused review. Once flagged any
user attempting to view the walk is presented with a screen explaining that someone has reported foul
content before giving them option to no longer proceed.
3.2.4
Feedback
As shown by the project plan whilst the build was going on a constant line of communication was open
between the developer and the prospective users. As demonstrated throughout the build documentation,
this feedback lead to a number of problems being overcome and improvements being implemented
without significant scope-climb. Scope-climb is described by Alan as the user seeing more potential in
the system leading to a rise in requirements beyond that which was originally defined [12]. This has
been known to cause escalation problems resulting in project schedules collapsing and system failure.
38
3.3
Further Developments
After the requirements were achieved a highlighted additional feature was implemented allowing group
leaders to grant certain members with walk leader status. This gave those members the ability to edit
walk events of the group. In order to do this the User object required additional functionality. The
User object had already been prepared for this in preparation during the analysis stage although its
implementation was optional. Before the project build took place any structural changes to implement
further developments were considered and included to ensure their addition was as simple as possible.
Once a user had been granted this level of status their member home page alerts them and makes them
aware of walks they are able to help perform. At this stage in the schedule a brief evaluation of the
remaining build time concluded that additional services could not be implemented.
39
Chapter 4
Testing
The system must be fully tested before evaluation. This ensures that any bugs in the system are fixed.
This is essential in producing a system that achieves its goals and works properly in an error free fashion.
To make sure that no errors occur unit testing tests the functionality. This is done in a black box and
white box fashion. Sample user input will test the workings of the functionality by testing the boundaries
of acceptable input. The services of the system will be tested to ensure Walks, Events and Users transist
between data capture, persistence and logic as they should. Accessibility will be tested using a web
service analysts tool which compares the quality of the code with web recognised standards.
4.1
Unit Testing
One of the reasons for the web’s success has been attributed to the fact that browsers can still render
web pages even if syntax is incorrect. This has allowed new and inexperienced developers to publish
content quickly, without necessarily giving the attention to ensure the validity of their content. While
this is useful for the publishers, it has wreaked havoc on the browser market which is why web standards
are such a hot current topic. On the contrary, Java ensures code is valid before allowing compilation. Its
integration to web development goes some way to ensuring competence. The Eclipse IDE has built in
validation for HTML syntax ensuring that the specification is met ensuring maximum browser support.
40
Compiled code can be prone to exceptions which is why unit testing is important to ensure any
value or action is forseen by the developer and its consequences addressed. By forseeing all possible
actions from the user unforseen errors can be reduced. Boundary value testing is shown in Appendix I.
This technique uses carefully chosen value inputs which test the extremities of user values. This process
finds unforseen errors such as that shown by the distance field of the new walk form, which caused the
program to crash upon the user entering a negative value.
4.2
Usability Testing
Usability of the system was highlighted as a key area during the analysis. Making the web service as
accessable as possible is vital to system success. Neilson’s guidelines had been adhered to as set out in
Section D but testing of their success needs to be done in two ways. Adobe offer a free website analysis
tool which looks in detail at the structure of the pages and generates a list of problems and remedies for
page design [27]. A sample of this report can be found in Appendix J. The report suggested the use
of ’alt’ text which is attached to images. Some users do not use graphical browsers and for that reason
they fail to view graphics. Using ’alt’ text allows them to get a textual representation of the graphic.
The report highlighted some errors which were unavoidable, including the use of Javascript which is
code embodied in the HTML document. Wicket uses Javascript to perform certain client side operations without the need to reload the page. Some browsers allow the disabling of Javascript or simply do
not support it. In order to test to what extent this limits the effectivness of the system the service was
viewed with Javascript switched off. Fortunately it only effected two drop down menus in which the
code was not critical to the operation of the task at hand. This resulted in a still fully functional system.
41
Chapter 5
Evaluation
The final section of the Waterfall methodology is evaluation. Although all implementation has been
completed at this point it is a vital stage in assessing the success of the system. Evaluating the build
decisions and the management of the project helps form a reflection of the project experience and points
to ways of improving the process for new projects. The system lifecycle is far from over after implementation. Ensuring the future direction through careful consideration of every stage completed is needed.
This project involved many different aspects from technology to methodology. Accordingly, a set of
criteria must be justified to create a framework for evaluating the project. The results of these criteria
are summarised and concluded in Section 5.8.
5.1
Evaluation Criteria
Chapter 1 documents the aim, objectives and minimum requirements of the project. These describe the
problem to be solved, what the system must provide to warrant a solution and other goals of the system.
When evaluating the success of the system these headings provide a checklist for the developer which
the implementation must meet.
42
A large portion of this project involved researching current web techniques and technologies in
order to find the appropriate platform for building the solution. The effectiveness of this review influenced nearly all of the major decisions taken during the project such as using Wicket and choosing a
way to persist system data. The conclusions of the background chapter must be evaluated in terms of
the methods they dictated.
This project used Dr Shaw’s Group as a case study. The agile workshops formed the analysis
which dictated the requirements and functionality of the system. In order to evaluate the preparation of
the solution, through analysis, and the finished system, Dr Shaw can provide vital feedback.
Usability was highlighted as a key non-functional requirement of the project. Analysis showed
that producing a successful system not only relied on the services it provided but ensuring their usage
through HCI sensitive design. Feedback from new users of the system through the Beckingham Rambling Group allow critical usability evaluation.
All project proceedings have been dictated by the management which has allocated time to tasks,
had to overcome problems and implement the methodology. Management ultimately decides the effectiveness of the time and resources available over the course of the project. The way it was conducted
must be evaluated as it an independent factor to the project success and provides critical feedback for
future undertakings.
Evaluating the implemented system will always uncover areas which need refinement. Systems
development evaluation is not the last step but should allow direction for the future of the project,
ensuring its continued success and fulfillment to its users. User evaluation highlights many key areas
which will need focus for the system to reach it’s full potential. The final criteria must examine the
future of the system and offer such guidance to achieving long term goals.
43
Evaluation Criteria Summary:
• Aim, objectives and minimum requirements
• Effectiveness of background chapter analysis
• Prospective user evaluation
• Usability evaluation
• Project management
• Project future
5.2
5.2.1
Aim, Objectives and Minimum Requirements
Aim
The aim of the project set out to create an electronic walking system for walkers. Analysis showed that
in order to accomplish this the system had to provide users with services not available from the current
pen and paper solution or exisiting external services. Table 2.1 clearly states the features needed to separate the solution from existing services. Reflecting back on that table, although the map functionalities
were not implemented the system still offers the key niche service of creating walking groups and their
agendas.
Mr Blackwell runs Beckingham Rambling group and had not taken part in the analysis stage.
During implementation he was informed of the developing system and became very interested. In order
to establish whether the system added value to groups and walkers he was kind enough to allow me to
attend a group meeting and demonstrate the software. Mr Blackwell and the walkers were extremely
excited about the system and seemed keen to explore its capabilites. The users had been previously
unaware of the other existing competition available which made it hard to explicitly confirm that it
offered an advantage. However the background research shows clearly that none of the exisiting services
offer what the implemented system is now capable of.
44
The project aim intended to examine and gain experience in emerging web development techniques in order to give the developer an array of skills to carry beyond the University course into the
Computing profession. The background chapter of this project was vital and a technology review examining the history of the web and its future gave an excellent insight into the direction of the web.
An understanding of the various web development techniques has been acquired. Learning characteristics and developing simple applications in a selection of these techniques has forced the developer into
understanding the principles behind them and how they suit different developers needs. By evaluating
existing technologies an understanding of how to choose the right framework for a given project can be
made. The School of Computing has taught modules on networks and the internet and now this project
has developed a specialisation in a key field through careful understanding and investigation.
5.2.2
Objectives
The objectives of the system are concise and their evaluation simpler. A brief conclusion on their
achievement can be found below:
• Formulate a schedule, detailing all necessary tasks, which allows for deliverables to be produced on time.
The schedule was a project tool which allowed a high level perspective on the project. This was
a useful insight as a developer can get overly involved in low level implementation. The break
down of tasks allowed a path to completion providing the means to meet each of the required
deadlines. Creating a plan is simple but creating a feasible plan which can gauge the importance
and scale of tasks at the beginning is not. The schedule allowed all deadlines and milestones of
the project to be achieved.
• Establish the problem to be solved and the requirements of the user.
Through the background chapter and careful analysis a problem definition was formulated and
solution requirements examimed. Section 5.2.1 clearly proves the problem is valid, establishing
that this objective was met. Establishment of the requirements is looked at in more detail through
user acceptence in Section 5.3.
45
• Conduct background research on technological and sociological issues to ensure that the
right solution is produced and that it meets all the needs of the user.
The research conducted was critical and provided the necessary platform onto which project decisions could be made. The solution could have been procured in any number of technologies but
in keeping with the aim of the project the right choice was justified. Further evaluation of this
background chapter is found in Section 5.5.
• Carry out the procurement of the solution involving the necessary feedback from the users
to ensure that new requirements are captured and that software purpose remains on track.
The agile meetings with Dr Shaw highlighted many issues with the design interface. These issues
were solved using the Design Before Logic method described in Section 3.2.3. The feedback
available enabled the highlighting and efficient remedying of problems before testing and evaluation. This certainly improved the acceptance of the users as many problems were already excluded. There are criticisms of user involvement during the implementation cycle as discussed by
Larman [3]. He discusses how this can lead to a upwards slope in requirements as the user watches
the the system develop and begins to see more potential. Minimum requirements lose their appeal
as the user sees basic implementation taking place and begins to look forward to what the project
can do next. This could be used to explain Dr Shaws wish to see the map functionalities as he
explains in his evaluation in Appendix K.
46
Minimum Requirement
How It Was Met
A service which allows genuine group organisers
By allowing registered members to create
to publish the groups activities electronically.
groups. From there they can create or use a
walk to create an event viewable by all confirmed
members.
A service which can store and retrieve walk route
Registered Users can create Walks using geo-
information in a combined textual and/or graphi-
graphical and descriptive information, stored and
cal manner.
viewable by all visitors
A service which provides group leaders with a
A member directory is available showing all
directory of member contact details.
members, their status, details and a selection of
actions.
Table 5.1: The minimum requirements of the system.
5.2.3
Minimum Requirements
Section 3.2.3 documents the implementation of the minimum requirements. Table 5.2.3 and 5.2.3 detail
the services in place to meet the minimum requirements.
5.3
System Acceptence Evaluation
Dr Shaw provided a critical evaluation through the result of an agile workshop, available in Appendix K.
An external opinion was offered by Mr Blackwell’s Beckingham Rambler Group. Dr Shaw was extremely satisfied with the services and stated his intention on using the system once live. However, he
identified the need for further details to be stored for each walk. A verbal description is not sufficient for
a group to carry out the walk. Such implementation had been captured during analysis but deemed to
be a further requirement. Dr Shaw’s evaluation suggests that in order to maximise the solution it should
be added in the next stage of development.
47
Minimum Requirement
How It Was Met
Allowing registered members to join their group
Once a member applies to join a group the leader
and have access to that groups activities.
must confirm them as a valid member. Upon confirmation they gain access to all of the groups activities.
A service which allows registered members to
A User can create walks by entering data on the
add, discuss and develop walking routes to a per-
Create Walk page. This adds the Walk object
sistent store.
to the database allowing retrieval and search at
a later date.
A service which allows registered members to re-
Once logged in the Users can add their own re-
view and comment on walks made by the group.
view of a walk discussing benefits, pitfalls and
features of the walk. This may include pubs and
areas of interest as highlighted by the analysis.
A service to allow abusive content to be reported
In order to add or review a Walk a User must
by members.
be logged in which involves creating a valid account. Such an account is verified by email.
Should a member abuse the review system other
members have the option to flag a walk. When
a User views a flagged Walk they are warned of
the sensitive content with the option to not view
it. All reviews are recorded by the User who created them allowing abusive members to be highlighted.
Table 5.2: The minimum requirements of the system.
48
An issue was highlighted with the difficulty rating of the walks. Initially, the agile meetings had
discovered a rating system of amble/walk/hike to determine the type of walk. Classifying a walk in
this way is not always simple and a numerical rating system would be better suited. Such ratings are
relative to the user classifying the walk. Because of this an extra page is needed to help guide users on
the numerical scale of the difficulty. Because of the Wicket implementation such changes were simply
implemented.
Mr Blackwell’s group showed enthusiasm for the system and enquired as to when such a service
would be available. They had not mentioned the need for further mapping services but when discussed
they immediately saw the further potential from such a system.
5.4
Usability
All prospective users were pleased with the usability of the web site. The logo and considerate design,
in particular, led to an ease of use. The meeting with Mr Blackwell allowed the system to be used by
older members of the group for whom the usability was a key issue. Such users, once given guidance
on accessing the service, were able to become members and use the services. It was apparent that the
service itself was less of a barrier than the computer and internet. Some members were not comfortable
with a mouse and had not previously used the web. This had not been identified during analysis which
is perhaps slightly ignorant of a developer who uses computers everyday.
The testing section of the project has undoubtedly ensured that from a web browser point of view
the system has excellent accessibility. The online website test identified ways to ensure the code was
compliant with web standards, allowing users with all browsers and even screen readers to access the
system.
5.5
Effectiveness of Background Chapter
The background chapter examined the feasibility of the project and formed a basis for deciding the
methodology and technologies to be used. The initial methodology justification failed as it had not considered the implications of the system in enough detail. This suggests that more time should have been
spent applying the literature to the system. Fortunately a management decision was made early enough
49
to change the methodology in order to ensure a continued structure to the development. Careful consideration presented an evolutionary model which tied closely with the Wicket ideology. This proved
fruitful and allowed the successful implementation of the system.
The technology review provided a history into web development and allowed educated conclusions to determine which framework should be chosen. The choice of Wicket was calculated from a
consideration of available frameworks and proved a successful choice allowing a smooth build using
the provided API. The research highlighted the problems of meshing together Wicket, Hibernate and
Spring. However this problem nearly caused project failure and perhaps needed more attention through
a proof-of-architecture to ensure that the mesh up of these systems was possible.
5.6
Project Management
The project schedule was built in accordance with the chosen methodology to formulate a series of
tasks resulting in the meeting of all deadlines. Creating a plan from the outset was difficult and required
flexible management to identify problems in order to ensure a workable plan still existed. When the
methodology failed early on, careful management was needed to combine what had already been done
with a feasible route to accomplish all goals. With help from the project supervisor this was achievable.
The plan had rigid time frames for tasks which perhaps led to the need of subsequent revisions as shown
in Appendix B. Perhaps a more anticipated expectance of task resource fluctuation would have been
wise. Section 3.2.1 describes the difficulty involved in implementing the persitence element of the
project. It was decided to limit the time for this task. This de-escalation measure ensured that partial
failure did not lead to full system failure. This report has been written in LATEX according to the template
provided by Fores [17]. This additional skill allowed management of the citations made and provides a
useful skill in document preparation.
5.7
Project Future
Evaluation has presented a need for improved functionality, offering the ability to store more detailed
information on the route of the walk. User evaluation has highlighted the need for such an extension,
possibly before the system goes live. The background research into the technology used has highlighted
Google Maps as a strong contender as the solution allowing maps to drawn interactively whilst recording
50
intricate geographical positions on behalf of the user. The functionality provided so far, presents a
platform on to which the additional features could be added. However part of the reason the developer
did not incorporate such services is due to resources available. Project management underestimated the
time needed to create the architecture for the minimum requirement, which left less time for such an
extension. The project already required the acquisition of an array of skills ranging from Hibernate to
Wicket, meshing a further API required more resources than were available. Such an extension would
make an excellent project in the future for this developer or for a student next year. The user clearly has
a need for such a service and the platform built by this project would make an excellent starting point.
5.8
Summary and Conclusion
The objectives of the project were well defined and met by the solution. Application of the reviewed
literature presented a schedule and methodology to ensure that all tasks and targets could be met. The
minimum requirements were soundly gathered allowing a solution which was met with positive reviews
from Dr Shaw, who helped design the system and Mr Blackwell’s group, who provided an indpendent
review. Despite the success of the system it is clear that work is still needed to fufill the remaining needs
of the user. The further introduction of a service allowing users to store details, particularly maps and
pictures is needed. Beside the services, strong emphasis was placed on ensuring usability. The evaluation of the users shows that careful design considerations have produced a neat interface.
The technological choices made in the project were ambitious and nearly caused it’s undoing.
However, strong project management dealt with such issues, allowing the creation of a workable solution. This project has given the author the chance to develop and apply skills learnt within the University. In particular the author has developed an understanding of new Java web technologies specifically:
Wicket, Hibernate and Spring. Project management is a vital skill which has been significant in the
completion of this project.
51
Bibliography
[1] Antwerks.
Qwicket
-
Because
you
don’t
like
boilerplate
code
either.
http://www.antwerkz.com/qwicket/, March 2007.
[2] National Ramblers Associaition. The Ramblers. http://www.ramblers.org.uk, November 2006.
[3] V.R. C.; Basili. Iterative and incremental developments: a brief history. IEEE Computer Society,
2003.
[4] G. King C. Bauer. Heart of England Walks. Cicerone Press, 2005.
[5] J. Davidson. Ten Minute Guide to Project Management. Alpha Books, 2000.
[6] Google Developers. Google kml. http://earth.google.com/kml/, Nov 2006.
[7] Google Developers. Google maps. http://www.google.com/apis/maps, Dec 2006.
[8] Wicket Developers. Wicket - Features. http://wicket.sourceforge.net/Features.html, April 2007.
[9] Natural England. Walking to Improve Health. http://www.whi.org.uk, November 2006.
[10] D. Alur et al. Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall / Sun
Microsystems Press, 1998.
[11] H. Hewwet et al. ACM SIGCHI Curricula for Human-Computer Interaction. ACM Press, 1992.
[12] J. McGovern et al. A Practical Guide to Enterprise Architecture. Prentice Hall, 2003.
[13] J. McGovern et al. Java 2 Enterprise Edition 1.4(J2EE 1.4) Bible. Wiley Publishing, Inc, 2003.
[14] S. Smith et al. Gnome usability study.
http://developer.gnome.org/projects/gup/ut1report/reportmain.html, Dec 2001.
52
[15] Center for Technology in Government. A Survey of System Development Process Models.
[16] N. Ford. The Art of Java Web Devlopment. Manning Books, 2003.
[17] S. Fores. Latex Template for Final Year Projects. University of Leeds, 2001.
[18] The Apache Software Foundation. Apache Tomcat. http://tomcat.apache.org/, Nov 2006.
[19] Apache foundation (Tapestry). What is Tapestry. http://tapestry.apache.org/, Nov 2006.
[20] K. Gurumurthy. Pro Wicket. Apress, 2006.
[21] B. Hughes. Software Project Management 3rd edition. McGraw-Hill, 2002.
[22] MR ICT. Build Your Own Weather Applications. http://www.weatherbug.com/api/default.asp,
December 2006.
[23] D. Leffingwell. Managing Software Requirements: A Use Case Approach, Second Edition. Addison Wesley Professional, 2003.
[24] Sun Microsystems.
Guidelines, patterns, and code for end-to-end java applications.
http://java.sun.com/blueprints/patterns/, December 2007.
[25] J. Nielson. Designing Web Usability: The Practice of Simplicity. New Riders Publishing, 2005.
[26] R. Noyce. Heart of England Walks. Cicerone Press, 2005.
[27] Lift Online. Usability report. http://www.adobe.com/macromedia/accessibility/tools/lift.html,
March 2007.
[28] Django Project. What is Django. http://www.djangoproject.com, Dec 2006.
[29] RouteCards. Walk Route Service. http://www.routecards.co.uk, November 2006.
[30] B. Shneiderman. Strategies for Effective Human-Computer Interaction. Addison Wesley, 4 edition,
March 2004.
[31] R. J. Simon. Teach Yourself Object-Oriented Programming with Visual Basic .NET in 21 Days.
Sams, 2nd edition, 2002.
[32] TurboGears team. What is TurboGears. http://www.turbogears.org/, Nov 2006.
53
[33] IBM The Eclipse Foundation. Eclipse - an open development platform. http://www.eclipse.org/,
March 2007.
[34] Y. Wu. Testing and Quality Assurance for Component-Based Software. Artech House, 2003.
54
Appendix A
Personal Reflection
Finding the right project is a difficult and important task. Even with a clear desire to find a project
exploring web development, finding a suitable problem did not come easily. A great deal of time was
spent developing ideas and looking for the right project whilst fellow students progressed. My tutor
was of great help and was the source of the project idea. I feel the time spent matching a problem to
my needs was justified. Having such a strong personal interest in the field of this project has helped
dramatically from a motivational point of view. In that respect I would recommend spending as much
time as possible choosing a project which is suited to a students skills and interests. The momentum
gained by the right choice can sustain the project as a whole.
Implementing systems in a new technology using new skills is a risk which comes with its own
rewards and pitfalls. I now know that I have the ability to learn new things in a time sensitive situation.
However, it does have an impact on the time available during the project. The framework exploration
stage was quite vague, perhaps because I was unaware what or how much it would really entail. It
ended up consuming a high level of resources leaving less time for minimum requirements and even
less for further enhancements. Specifically a proof of architecture would have discovered the technical
bottle neck caused by meshing multiple software systems. Pro-active and robust project management
facilitates discovery of such problems earlier allowing for a more flexible use of remaining resources.
55
The project has taught me the most important areas of system development might not necessarily
have anything to do with implementation. Deciding upon requirements is crucial as it dictates the feasibility of the work to be done. The quality of the requirements dictate the level to which the problem
will be solved. I feel unambiguous minimum requirements allows clearer goals, implementation and
evaluation. This provides a good basis for the achievement of non-functional requirements and further
enhancements. For this reason the analysis and background chapter really do play a vital role to the
project. The requirements are products of those areas which must be ascertained correctly. Perhaps this
is why the mid-project report is a deadline required by the University to ensure that the foundation of the
project is sound. For a student starting this project next year I would implore them to give this interim
assessment the time and resources it deserves.
The Walk system has been a valuable project which has been frustrating and time consuming but
ultimately rewarding. The help of those around me including my tutor and voluntary walking community members has been overwhelming and made the course of my final year enjoyable. Maintaining a
good repore with Dr Shaw throughout has allowed me to utilise the high level of feedback his group has
produced to deliver a better system. Great client interaction can directly benefit a project and watching
their requirements fluctuate is a valuable lesson.
The methodology and project schedule are important tools which are not just sections of the report. They are tools which are there to help the project and the developer. Finding the right tools is a
difficult task which needs systematic application to the project and not just picking one that seems right.
Soon into this project I decided to change the methodology for precisely that reason. I had chosen an
iterative waterfall approach because it seemed to provide the steps and time frame required. However
it did not fit the implementation and trying to mould the tasks into the methodology would be counter
productive. Making the change was important to ensure the projects continued strategy even though the
choices available were limited as the project was already under way.
56
Appendix B
Project Plan
57
Figure B.1: The Original Project Plan
58
Figure B.2: An extension to the Explore Framework stage was needed due to a lack of resources resulting from an underestimated work load in the first semester. This required a reduced time span for the
build stage.
59
Figure B.3: The first iteration’s time span was not feasible and therefore extended. Ultimately the three
iterations were flattened to one evolutionary build period as shown in figure B.4 and explained in section
2.2.4.
60
Figure B.4: As discussed in section 2.2.4, this Gantt chart reflects the change in methodology.
61
Figure B.5: The final revision took place as a de-escalation decision. The persistence mechanism needed
by the system was draining resources and could have resulted in an overall failure. At this deadline the
project had to move on, with or without persistence in place.
62
Appendix C
Sample Agenda
STAFF WALKING CLUB - 2007(i)
ADVANCE NOTICE
WEEKEND IN THE LAKES (19/20 MAY)
As previously announced, we’ve booked the weekend May 19/20 at Derwentwater
YHA, in the Lake District. This 200-year-old mansion, just ouside Keswick, has
extensive grounds, good parking and stunning views across the lake. Many members
will remember the eventful weekend we spent there in 2003. Since the Hostel is
holding 20 places for us (tell all your friends!) they would like us to confirm - and
pay - by mid-February.
63
Please note
While every attempt is made to keep to the programme as published, it is occasionally necessary to
change at short notice the starting time, meeting place or grading of a given walk. Please inform the
leader beforehand if you intend to join a walk.
Footnote to previous programme
Please note that, after the New Year’s Eve walk (31 January: Harewood & Eccup), Mike and Jenny
Willison are very kindly inviting all participants back to their house in Headingley for tea.
From Ambles to B Walks
As many will know, Jane Burch, inspirer of the ’Ambles’, has recently had hip surgery. As we went to
press, she didn’t know what her walking future would be: so the Ambles have gone temporarily into
abeyance. They are being replaced by B WALKS, which will usually be around 6 miles in length and
less strenuous than the time-honoured ’Saturday’ and ’Sunday’ walks.
PLEASE NOTE
• P = Pub possibly available at lunch time: bring packed lunch anyway.
T = Tea (shop) possibly available at end of walk.
TT = Tea (shop) possibly available at lunch time and end of walk. Rare.
PP = Pub available at at lunch time and end of walk. Even rarer.
• Members of the Club are reminded that the programme is now available on the Web. From the
University’s homepage, click on ’Academic and support services’, then ’Senior Common Room’.
Scroll down to ’Walking Club’ and click on ’Current Programme’. You can also get a three-day
weather forecast.
• If you would be happy to access our programme exclusively via the Web, please let Fiona know
(f.w.jackson@leeds.ac.uk).
• The grades given (1 [very easy], 2 [easy], 3 [moderate], 4 [strenuous], 5 [very strenuous]) are
subjective estimates for average walkers in good conditions. Poor conditions could justify a higher
grade.
64
SATURDAY 6 JANUARY: HARDCASTLE CRAG & CRIMSWORTH DEAN (9 miles)
Description:
Grade 2 A gentle walk on sylvan, riverside and moorland paths.
With a visit to a splendidly isolated Dales pub. PT.
Meet:
09.30, Hardcastle Crag car park (GR 988292)
Directions:
M62 junction 26; A58 Halifax; A646 Mytholmroyd, Hebden
Bridge; A6033 towards Oxenhope; after about 1 mile, fork left
on minor road leading to Hardcastle Crag car park.
Leader:
Adrian Smith (w-343 5531 / h-225 7214 / 275 6657[messages])
SUNDAY 14 JANUARY: BURLEY, BAILDON & HAWKSWORTH MOORS (9 miles)
Description:
Grade 2 Moorland tracks, field paths and walled lanes on the borders of Leeds and Bradford with extensive views of Airedale and
Wharfedale.
Meet:
09.30, lay-by at GR 148 454
Directions:
A660/A65 to Burley-in-Wharfedale; L at T-junction in centre of
village; turn R at Burley Woodhead. Lay-by on L in about mile.
Leader:
Mike Willison (h-275 6011)
SATURDAY 20 JANUARY: YORKSHIRE WOLDS (11 miles)
Description:
Grade 2 A circular walk based on the remote village of Thixendale. Docile paths along dales, hills with modest gradients, sections of the Wolds Way, a Roman road and tantalising glimpses
of earthworks, disused pits and Fridaythorpe sewage works. T.
Meet:
09.30, Thixendale School (GR 842 612).
Directions:
A64(York); A166(Bridlington); approx. 9 miles on, at top of Garrowby Hill, turn L(sign Thixendale) on narrow lanes Thixendale.
Leader:
Ken Brookes (h-289 2753)
65
• While every effort is made to ensure the safety of participants, anyone taking part in our activities
does so at his/her own risk.
WEEKEND IN THE LAKES (19/20 MAY)
To: Fiona Jackson
I/we would like to the party at Derwentwater YHA in the evening of Friday 18 May 2007.
Please reserve for me/us − − − − − − −. place(s)
I enclose a deposit cheque for − − − − − − −(@ 38.40 per person: ’LU Walking Club’)
I am responding before 19 February 2007.
Signed − − − − − − − − − − − − − − −
Name − − − − − − − − − − − − − − −
Department − − − − − − − − − − − − − − −
66
Appendix D
Jakob Neilsons HCI Heuristics
Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback
within reasonable time.
Match between system and the real world
The system should speak the users language, with words, phrases and concepts familiar to the user,
rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked emergency exit to leave
the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing.
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in
the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
67
Recognition rather than recall
Minimize the users memory load by making objects, actions, and options visible. The user should not
have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators unseen by the novice user may often speed up the interaction for the expert user such that
the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative
visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and
constructively suggest a solution.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide
help and documentation. Any such information should be easy to search, focused on the users task, list
concrete steps to be carried out, and not be too large.
As defined by Nielson [25].
68
Appendix E
Model View Controller (MVC)
MVC is a structural design pattern used to separate data and it is represented. Because a change in data
would result in a change in its view and vice versa it made sense to de-couple them.[16, p. 8-10]
• Model This defines the data used by the system and the rules it must abide by.
• View This is responsible for the display of data to the user.
• Controller This is the method by where the view and data communicate.
Ford makes the comparison to a spreadsheet where the Model is the numbers and formulae, the View is
the numbers and charts seen by the user and the controller would be the keyboard or mouse.
Figure E.1: The Model View Controller Structure
69
Appendix F
System Pages
Table F lists the pages implemented in the system and their respective jobs.
Page Name
Job
Home
The home page which greets users
Join
A sign-up page allowing users to register for the service
Confirmation
Used to detail to the user how to confirm registration
Find Walks
Used to present the user with a list of availble walks
Add Walk
Used to add a walk to the database
View Walk
Used to view a walk and read/add reviews(s)
Member Home
Once logged in this page displays member status and links to member services
Create Group
Used by a member to create a group
Join Group
Used to join a group and agree to the groups conditions
Group Home
The group home page displaying upcoming walks and agenda
Create Event
Used by a group leader to create an event
Edit Event
Used by a group leader or walk leader to edit an event
Member List
Used for group leaders to view members and update their privaledge level, e.g.
confirm as a member
70
Figure F.1: Home Page Screen
71
Figure F.2: User Registration Screen
Figure F.3: User Confirmation Screen
72
Figure F.4: Member Home Page
Figure F.5: Create a New Group
Figure F.6: Join a Group
73
Figure F.7: Add a Walk
Figure F.8: Find a Walk
Figure F.9: View Group Members
74
Figure F.10: Create a Walk Event
75
Figure F.11: Walk Review with StarBar feature
76
Appendix G
Walk Finder
The Walk finding service required a complicated matching algorithm to select only walks required by
the Users constraints. A screenshot of the servive can be found in Appendix F. The DAO code needed
to retrieve the selected walks can be found below.
/**
* builds a query object to statify the provided parameters
*
* @param qp
*
sorting and paging criteria
* @param filter
*
filter criteria
* @param count
*
true if this is a query meant to retrieve the number of rows
* @return query object that satisfies the provided criteria
*/
protected Query buildFindQuery(QueryParam qp, Walk filter, boolean count)
{
77
StringBuffer hql = new StringBuffer();
if (count)
{
hql.append("select count(*) ");
}
hql.append(" from Walk target where 1=1 ");
//County start
if (filter.getStartCounty() != null)
{
hql.append("and upper(target.startCounty) like (:startCounty)");
}
//County end
if (filter.getEndCounty() != null)
{
hql.append("and upper(target.endCounty) like (:endCounty)");
}
//Stab at distance
if (filter.getDistance() != null)
{
hql.append("and target.distance < (:distance) ");
}
//start location
if (filter.getStartLocation() != null)
{
hql.append("and upper(target.startLocation) like (:start)");
}
//end location
if (filter.getEndLocation() != null)
{
hql.append("and upper(target.endLocation) like (:end)");
78
}
//sortable
if (!count && qp != null && qp.hasSort() && qp.getSort().equals("distance"))
{
hql.append("order by target.").append(qp.getSort()).append(
" ").append((qp.isSortAsc()) ? " asc" : " desc");
}
if (!count && qp != null && qp.hasSort()&& !qp.getSort().equals("distance")) {
hql.append("order by upper(target.").append(qp.getSort()).append(
") ").append((qp.isSortAsc()) ? " asc" : " desc");
}
//convert to sql
Query query = createQuery(hql.toString());
//set query parameters
if (!count && qp != null)
{
query.setFirstResult(qp.getFirst()).setMaxResults(qp.getCount());
}
//county start
if (filter.getStartCounty() != null)
{
query.setParameter("startCounty", "%"
+ filter.getStartCounty().toUpperCase() + "%");
}
//county end
if (filter.getEndCounty() != null)
{
query.setParameter("endCounty", "%"
+ filter.getEndCounty().toUpperCase() + "%");
}
//distance
79
if (filter.getDistance() != null) {
query.setParameter("distance",filter.getDistance(),Hibernate.FLOAT);
}
//start
if (filter.getStartLocation() != null) {
query.setParameter("start", "%"
+ filter.getStartLocation() + "%");
}
//start
if (filter.getEndLocation() != null) {
query.setParameter("end", "%"
+ filter.getEndLocation() + "%");
}
return query;
}
80
Appendix H
Super Page
Below is a screen shot of the super page which was extended by service pages to add content.
Figure H.1: Super page defining layout and content.
81
Appendix I
Unit Testing
Ye Wu [34, Chapter 3] discusses the importance of boundary testing as an efficient technique for indpendant developers who don’t have the benefits of working in a team based environment. The table
below shows a break down of the boundary and limit testing ensuring the success of controlled failure
of all user input.
82
New User Form
Field
String fields
Phone Number
Gotcha Capcha
Input
Example
Expected Result
Pass/Fail
20chars
abc. .tqv
Accept
PASS
Null Test
null
Flag field
PASS
21chars
abc. .tuvw
Flag field
PASS
Valid Phone
01427-848861
Accept
PASS
Invalid Phone
xy12
Flag field
PASS
Null Test
null
Flag field
PASS
Actual text
3fre32a
Submit
PASS
Invalid text
zzzzz
No Submit
PASS
Null Test
null
No Submit
PASS
Valid email
jay@hay.com
Accept
PASS
Invalid email
2a
Flag Field
PASS
Quick email
1@1.
Flag Field
PASS
Null Test
null
Flag Field
PASS
Valid post code
DN10 4TS
Accept
PASS
Invalid post code
111 11111
Flag Field
PASS
Null Test
null
Flag Field
PASS
Email
Post Code
83
Comment
New Walk Form
Field
Input
Example
Expected Result
Pass/Fail
Valid (int)
7
Accept
PASS
Valid (float)
3.3
Accept
PASS
Negative Distance
-2
Flag Field
FAIL
Null Test
null
Flag Field
PASS
Valid County
Cheshire
Accept
PASS
Null Test
null
Flag Field
PASS
Comment
Distance
*
Start/End County
New Group Form
Field
Group Name
Input
Example
Expected Result
Pass/Fail
20chars
Leeds Uni
Accept
PASS
21 chars
abc..uvw
Flag Field
PASS
Null Test
null
Flag Field
PASS
County Selected
Cheshire
Accept
PASS
Null Test
null
Flag Field
PASS
20chars
abc. .tqv
Accept
PASS
Null Test
null
Flag field
PASS
21chars
abc. .tuvw
Flag field
PASS
Comment
Area
Location
Table I.1: * Simple rectification by implementing a sign check before processing.
84
Adding A Walk To The Walk Searcher
Field
Start County
End County
Input
Example
Expected Result
Pass/Fail
Cheshire
Cheshire
Find
PASS
Yorkshire
Yorkshire
Not Find
PASS
Null Test
null
Find All
PASS
Cheshire
Cheshire
Find
PASS
Yorkshire
Yorkshire
Not Find
PASS
Null Test
null
Find All
PASS
12
12
Find
FAIL
12
13
Find
PASS
12
8
Not Find
PASS
Null Test
null
Find All
PASS
Doncaster
Don
Find
PASS
Doncaster
caster
Find
PASS
Doncaster
Linc
Not Find
PASS
21chars
abc. .tuvw
Flag field
PASS
Null Test
null
Flag field
PASS
asc. test
a/m/z
Working Sort
PASS
desc. test
a/m/z
Working Sort
PASS
Max Distance
Location
Sort
Table I.2: The tests above were accomplished by creating the necersary walks.
* Walk Dao needs to look for walk distance using ≤ operator instead of < - fixed
85
Comment
*
Joining a Group
Field
Mandatory Waiver
View Application
Input
Example
Expected Result
Pass/Fail
No Tick
Not Agreed
Flag waiver
PASS
Yes
Tick
Apply for Group
PASS
Null Test
null
Flag Field
PASS
Comment
Several members were created in order to allow them to apply
for a vartiety of groups. The circumstances included a number of
users applying for a group at once and all concievable combinations of applications.
Grant Membership
In all of the above scenarios the group leader then went ahead
and confirmed the member as a valid user. As confirmation the
users were then logged in to confirm that membership had been
achieved as shown on their members status providing a working
link to the diary only possible upon confirmation.
Table I.3: The tests above were accomplished by creating and registering necersary users and groups.
Joining a Group
Field
Mandatory Waiver
View Application
Input
Example
Expected Result
Pass/Fail
No Tick
Not Agreed
Flag waiver
PASS
Yes
Tick
Apply for Group
PASS
Null Test
null
Flag Field
PASS
Comment
Several members were created in order to allow them to apply
for a vartiety of groups. The circumstances included a number of
users applying for a group at once and all concievable combinations of applications.
Grant Membership
In all of the above scenarios the group leader then went ahead
and confirmed the member as a valid user. As confirmation the
users were then logged in to confirm that membership had been
achieved as shown on their members status providing a working
link to the diary only possible upon confirmation.
Table I.4: The tests above were accomplished by creating and registering necersary users and groups.
86
Appendix J
Sample Usability Report
This Appendix features a sample from the usability test conducted on the walk service.
87
88
Appendix K
User Feedback
This appendix details the feedback from users of the system, mainly Dr Shaw who was kind enough to
give his time and effort during the analysis stage and provided crucial information used to formulate the
requirements of the system.
Concept: a database of walks defined, graded and recommended by local groups, covering
the whole of England and available by county.
• I think this is, overall, a most commendable initiative: useful, well-conceived and having great
potential. As a walker myself, I look forward to using it.
• My understanding is that this system is based on new(ish) computer techniques designed to make
it more user-friendly and easier to make future amendments. That’s good news.
89
• Because, as it stands, more development work is clearly necessary in order to turn a promising
prototype into a practical tool. For example, we are currently offered just a verbal description of
each walk. In addition to this, some kind of sketch map of the route will be necessary in each
case. I’m informed this should be relatively easy to add. I trust this would not require advanced
IT skills and that the result would be sufficiently legible/detailed for it to be readily transcribed
onto a 1:25000 OS map.
• I didn’t quite follow the need for a list of registered members. My fault entirely: I’m sure you
described it well, but I was beginning to think about my next appointment! I know you said
this would be restricted to local groups and that there would be no national list of subscribers: I
applaud this. But why have any lists of members at all? Would it not suffice to have a list solely
of affiliated groups, such as my own?
• One trivial improvement would be a change to the proposed grading system. I think the proposed
system(’Ambles/Walks/Hikes’) is seriously ambiguous. I suggest ’Easy/Moderate/Strenuous’
would be better, perhaps with the option of +/- in each case.
• I think you at least need to ask the question concerning liability which I raised with you. It may
well be that this doesn’t arise in this context: we are constantly told that, in the ’blogosphere’,
no-one takes responsibility for anything. And you mentioned your intention of adding a waiver
before this system ’goes live’. But, as I told you, I am reliably informed by a lawyer that the
waiver I put on our programmes does not absolve me from a duty of care and the need to get
things right. I imagine the crucial distinction may be that I provide leaders and your system is
more akin to a large and flexible electronic guidebook. But the question is still worth asking.
• I see this system as being particularly useful to experienced walkers on holiday, or whatever,
in a different part of the country. Guidebooks are fine but nothing beats walks reconnoitred,
recommended and updated by local groups. In this context, as I said, whoever takes this system
further, should consider interesting a national umbrella body for walkers, the obvious candidate
being the Ramblers Association. As a member myself, I would certainly use such a resource,
when suitably refined.
90