Requirements Analysis

Information Migration and
Presentation for Leeds CAMRA
Thomas Macey
BSc Information Systems
Session 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
The aim of this project was to produce a system that would enable information on licensed premises
in Leeds to be maintained and edited synchronously by Leeds CAMRA members. Background
research and investigations into wiki software was carried out, to determine the best platform upon
which to build a solution.
The final solution builds on the MediaWiki platform having obtained the requirements through a
series of requirements gathering techniques. The final solution incorporates a data importing facility
to take existing spreadsheet based information and convert it into MediaWiki. A reporting facility is
also developed to extract information from MediaWiki. The system evaluation is based on how well
it met the requirements, usability standards and user feedback.
i
Acknowledgements
I would like to thank my supervisor, Tony Jenkins, for his valuable input and support throughout the
project. I would also like to thank Vania Dimitrova for her advice on writing a good report.
Thanks to all the Leeds CAMRA members, especially Dave Ansley, for contributing to and
evaluating the project.
I would also like to thank my family for proof reading the report, and their continued support
throughout my time at University.
Finally, thanks to all my housemates who provided useful ideas and helped evaluate the solution.
ii
Contents
SUMMARY ........................................................................................................................................... I
ACKNOWLEDGEMENTS ................................................................................................................ II
CONTENTS ....................................................................................................................................... III
1 INTRODUCTION ............................................................................................................................. 1
1.1 THE PROBLEM ............................................................................................................................... 1
1.2 AIMS AND OBJECTIVES ................................................................................................................. 1
1.3 MINIMUM REQUIREMENTS............................................................................................................ 1
1.4 DELIVERABLES ............................................................................................................................. 2
1.5 SCHEDULE ..................................................................................................................................... 2
1.6 RELEVANCE TO DEGREE PROGRAMME ......................................................................................... 3
2 BACKGROUND RESEARCH ......................................................................................................... 4
2.1 METHODOLOGIES .......................................................................................................................... 4
2.1.1 Waterfall Model..................................................................................................................... 4
2.1.2 Prototyping............................................................................................................................ 4
2.1.3 Iterative System Development ............................................................................................... 4
2.1.4 Chosen Methodology............................................................................................................. 5
2.2 WIKIS ............................................................................................................................................ 5
2.3 SIMILAR PROJECTS ........................................................................................................................ 6
2.4 SUMMARY ..................................................................................................................................... 7
3 REQUIREMENTS ANALYSIS ....................................................................................................... 8
3.1 EXISTING SOLUTION ..................................................................................................................... 8
3.2 DATA GATHERING TECHNIQUES ................................................................................................... 8
3.3 SEMI STRUCTURED INTERVIEWS .................................................................................................. 8
3.3.1 Objectives .............................................................................................................................. 9
3.3.2 Participants ........................................................................................................................... 9
3.3.3 Results ................................................................................................................................... 9
3.4 SAMPLE DOCUMENTS ................................................................................................................. 11
3.5 RESEARCH ................................................................................................................................... 11
3.6 USER REQUIREMENTS ................................................................................................................. 11
3.6.1 Essential .............................................................................................................................. 11
3.6.2 Desirable ............................................................................................................................. 12
3.7 SYSTEM REQUIREMENTS............................................................................................................. 12
3.8 USABILITY REQUIREMENTS ........................................................................................................ 12
3.9 SUMMARY ................................................................................................................................... 12
4 SOCIAL AND COLLABORATIVE SOFTWARE ...................................................................... 13
4.1 WHAT IS SOCIAL AND COLLABORATIVE SOFTWARE? ................................................................ 13
4.2 POSSIBLE SOLUTIONS ................................................................................................................. 13
4.2.1 Blogs.................................................................................................................................... 13
4.2.2 Email Lists........................................................................................................................... 14
4.2.3 Google Documents .............................................................................................................. 14
4.2.4 Custom System..................................................................................................................... 14
4.2.5 Content Management Systems............................................................................................. 15
4.2.6 Conclusion........................................................................................................................... 15
4.3 SUMMARY ................................................................................................................................... 16
5 SELECTING THE RIGHT WIKI SOFTWARE ENGINE......................................................... 17
5.1 EVALUATION CRITERIA OVERVIEW............................................................................................ 17
iii
5.2 TIKIWIKI ..................................................................................................................................... 18
5.3 WIKKAWIKI ................................................................................................................................ 19
5.4 PBWIKI........................................................................................................................................ 20
5.5 MEDIAWIKI ................................................................................................................................. 21
5.6 CHOSEN WIKI .............................................................................................................................. 22
5.7 SUMMARY ................................................................................................................................... 22
6 DESIGN ............................................................................................................................................ 22
6.1 CHOICE OF TECHNOLOGY ........................................................................................................... 22
6.2 INITIAL DESIGN ........................................................................................................................... 23
6.3 ITERATIVE DESIGN ...................................................................................................................... 23
6.4 SUMMARY ................................................................................................................................... 24
7 IMPLEMENTATION ..................................................................................................................... 25
7.1 FIRST ITERATION......................................................................................................................... 25
7.1.1 Data Inspection and Conversion......................................................................................... 25
7.1.2 Installing and Investigating MediaWiki .............................................................................. 25
7.1.3 Development of Wiki Syntax Script ..................................................................................... 26
7.1.4 MediaWiki Data Storage Investigation ............................................................................... 27
7.1.5 Testing ................................................................................................................................. 27
7.1.6 Summary.............................................................................................................................. 27
7.2 SECOND ITERATION .................................................................................................................... 27
7.2.1 Development of XML Import............................................................................................... 27
7.2.2 Data Development............................................................................................................... 28
7.2.3 Preliminary Reporting Facility ........................................................................................... 29
7.2.4 Editing the MediaWiki Namespace ..................................................................................... 29
7.2.5 Tailoring MediaWiki ........................................................................................................... 30
7.2.6 Testing and Feedback.......................................................................................................... 30
7.3 THIRD ITERATION ....................................................................................................................... 31
7.3.1 Expansion of Data............................................................................................................... 31
7.3.2 InfoBoxes............................................................................................................................. 31
7.3.3 Stubs .................................................................................................................................... 32
7.3.4 Reporting Facilities............................................................................................................. 33
7.3.5 Map Integration................................................................................................................... 35
7.3.6 MediaWiki Tailoring ........................................................................................................... 35
7.4 MIGRATION TO LEEDS CAMRA SERVER ................................................................................... 36
7.5 TESTING ...................................................................................................................................... 36
7.6 SUMMARY ................................................................................................................................... 37
8 PRODUCT EVALUATION............................................................................................................ 37
8.1 EVALUATE AGAINST ESSENTIAL REQUIREMENTS ....................................................................... 37
8.2 EVALUATE AGAINST DESIRABLE REQUIREMENTS....................................................................... 39
8.3 USABILITY EVALUATION ............................................................................................................ 41
8.4 USER FEEDBACK ......................................................................................................................... 42
8.5 POSSIBLE IMPROVEMENTS .......................................................................................................... 44
8.6 SUMMARY ................................................................................................................................... 44
9 PROJECT EVALUATION............................................................................................................. 45
9.1 EVALUATION AGAINST MINIMUM REQUIREMENTS. .................................................................. 45
9.2 EVALUATION AGAINST ADDITIONAL REQUIREMENTS ............................................................... 45
9.3 EVALUATION OF THE PROJECT STAGES ...................................................................................... 46
9.4 DELIVERABLES ........................................................................................................................... 47
9.5 FURTHER WORK.......................................................................................................................... 47
9.6 PROJECT CONCLUSION ................................................................................................................ 47
iv
REFERENCES.................................................................................................................................... 49
APPENDIX A – PERSONAL REFLECTION................................................................................. 53
APPENDIX B – PUB WATCH SURVEY ........................................................................................ 55
APPENDIX C – SYNTAX COMPARISON..................................................................................... 56
APPENDIX D – FINAL SOLUTION USABILITY ANALYSIS ................................................... 58
APPENDIX E – WIKI USABILITY EVALUATION ..................................................................... 60
APPENDIX F – INTERFACE DESIGNS ........................................................................................ 73
APPENDIX G – TEST PLAN............................................................................................................ 82
APPENDIX H – USER FEEDBACK................................................................................................ 84
v
1 Introduction
1.1 The Problem
The Leeds branch of CAMRA, the Campaign for Real Ale, is required to maintain a database of
licensed premises in its area. The information is used annually to complete CAMRA’s ‘Pub Watch
Survey’ (see Appendix B) containing the number of Pubs, whether they are rural or urban and details
on pub closures.
The information is extremely volatile and covers a large geographical area. Keeping the information
up to date is a daunting task for one individual, and requires input from a large number of CAMRA
members.
The project aims to provide a solution to the collection and maintenance of licensed premises
information. The project will investigate and evaluate existing data management systems in order to
produce a solution. The system should enable users to retrieve and edit stored information.
1.2 Aims and Objectives
The aim of this project is to produce a system that will enable information on licensed premises in
Leeds to be maintained and edited synchronously by Leeds CAMRA members.
To achieve the aim the following objectives will have to be met
•
Understand current practices in order to derive system requirements
•
Choose suitable software
•
Produce a viable system
•
Migrate existing data into new system
•
Evaluate the final solution
•
Make system available to CAMRA members
1.3 Minimum Requirements
The minimum requirements for the project are:
•
Produce a tool for migrating existing data to new system
•
Tailor system to meet Leeds CAMRA user requirements
•
Produce a tool that will enable Leeds CAMRA administrators to obtain management
information from the system
Possible extensions to the minimum requirements are:
•
Produce a tool for the automated creation of the pub watch survey
1
•
Produce a system that integrates with mapping software to plot the location of licensed
premises
1.4 Deliverables
In order for the project to be a success the final software solution needs to be delivered along with the
final report.
1.5 Schedule
Figure 1.1 shows the original schedule for the project and Figure 1.2 shows the milestone schedule for
the project.
Activity
Background Research
Mid Project Report
Complete First Iteration – Initial investigation into
collaborative tools, user requirements, wikis and
documentation of ideas
Complete Evaluation of Available Software
Complete Second Iteration – Installation, setup and
configuration of chosen wiki software, make sure minimum
requirements have been met
Complete Table of Contents and Draft Chapter
Complete Third Iteration – Add certain desirable features,
gain feedback from CAMRA members, make
additions/changes based on feedback
Make Final Changes to Software
Complete Evaluation
Complete Report Writing
Start Date
10/10/06
12/11/06
20/11/06
End Date
08/12/06
18/12/06
08/12/06
08/12/06
20/12/07
20/12/06
16/02/07
26/02/07
16/02/07
19/03/07
30/03/07
30/03/07
30/03/07
06/04/07
06/04/07
06/04/07
25/04/07
Figure 1.1 Project Schedule
Milestone
Complete First Iteration
Complete Mid Project Report
Complete Evaluation of Wikis
Complete Second Iteration
Complete Draft chapter and Table of Contents
Complete Third Iteration
Complete Evaluation
Complete Software
Complete Report Writing
Date
08/12/06
18/12/06
20/12/06
16/02/07
19/03/07
30/03/07
06/04/07
25/04/07
25/04/07
Figure 1.2 Milestone Schedule
There were a number of changes to the schedule during the project, the majority of changes came as a
result of changing the content of each iteration and the addition of a separate wiki software evaluation
section. This change was deemed necessary so that the iterations could concentrate on the
development of the product rather than researching different software engines. A number of the
2
planned deadlines slipped due to the pressures of additional modules, and some teething problems
with server setups. Figure 1.3 shows the final revised project schedule with figure 1.4 showing the
revised milestone schedule.
Activity
Background Research
Mid Project Report
Investigate Wiki Alternatives
Investigate Various Wiki Software Offerings and Choose
Wiki Software
Complete First Iteration – Installing of chosen wiki
software, inspection of wiki syntax and importing facilities
Complete Second Iteration – Developed mass import
facility, preliminary reporting facilities
Complete Third Iteration – Add certain desirable features,
gain feedback from CAMRA members, make
additions/changes based on feedback
Complete Table of Contents and Draft Chapter
Implement and Evaluate
Complete Report Writing
Start Date
10/10/06
12/11/06
12/11/06
22/11/06
End Date
08/12/06
18/12/06
22/11/06
08/12/06
08/12/06
08/01/07
08/01/07
28/02/07
01/03/07
20/04/07
26/03/07
30/03/07
01/04/07
18/04/07
23/04/07
25/04/07
Figure 1.3 Revised Project Schedule
Milestone
Complete Background Research
Complete Evaluation of Wikis
Complete Mid Project Report
Complete First Iteration
Complete Second Iteration
Complete Draft chapter and Table of Contents
Complete Third Iteration
Complete Implementation and Evaluation
Complete Software
Complete Report Writing
Date
08/12/06
08/12/06
18/12/06
08/01/07
28/02/07
18/04/07
20/04/07
26/04/07
25/04/07
25/04/07
Figure 1.4 Revised Milestone Schedule
1.6 Relevance to Degree Programme
During this project the developer is expecting to use and develop the skills learnt in a number of
School of Computing modules. The software development skills learnt in SE20 and SE24 will be
essential in planning and developing the solution. The human computer interaction skills introduced
in GI11 and developed in GI32 will be drawn upon for the evaluation of the wiki software, these skills
will also form the basis of evaluating the solution. Finally skills learnt throughout the database
modules will be required to understand the underlying data structure and in order to manipulate data.
3
2 Background Research
This chapter investigates various methodologies that the project could follow, and decides on the most
appropriate. The chapter also looks at some background information on Wikis and identifies similar
projects which may provide valuable input during the development of a solution
2.1 Methodologies
2.1.1 Waterfall Model
The waterfall model outlines a series of activities, or stages, which should occur when building a
system. Each activity has to be completed in order, to provide the necessary input for the following
activity. There is no easy way to change previous stages without returning to the immediately
preceding stage.
Using the waterfall model introduces problems to system building due to the focus on deliverables
produced at each stage to initiate the next. The waterfall model is also guilty of not taking in to
account more modern methods for systems development: “It takes no account of evolutionary
development and prototyping” [1] this indicates the waterfall model is probably not suited to the
development of a modern collaborative system.
British Telecom recently stated how they are adopting agile development methods in order to get
away from the traditional waterfall model: “…we are encouraging development teams to get away
from waterfall development models and work closer with the business and customers.” [2]
The waterfall model suits projects where requirements are clear and well understood, to avoid
expensive re-specification.
2.1.2 Prototyping
Prototyping is generally part of rapid application development (RAD) and can be defined in many
different ways dependant upon the type of project. The main emphasis of prototyping is to get
systems produced quickly by producing incremental solutions that are evaluated at each stage by the
users then throwing away the un-useful parts. User requirements only outline the most essential of
functionality, with “…no detailed system specification…” [3]. There are a number of pitfalls to
prototyping these including management problems due to a lack of paper deliverables and
maintenance problems due to constant changes to prototype structure.
2.1.3 Iterative System Development
Iterative development involves going over the systems development cycle a number of times, in this
case iterating over the waterfall model. Each iteration is often seen as “a self-contained mini-
4
project…” [4] with each iteration done quickly to enable the system to develop adding value at each
stage.
2.1.4 Chosen Methodology
Research would suggest that the Waterfall model is ideally suited to well defined user requirements,
and systems that are unlikely to stray from the set deliverables. The project has reasonably static
minimum requirements, however during development additional ‘desirable’ requirements are likely to
be catered for and there might be a need to revisit stages in the model. Therefore the iterative system
development methodology will be followed as this will enable development to follow stages but
enable change to occur throughout the development life cycle. Due to integrating and essentially
experimenting with existing software there is likely to be a need to produce a number of prototypes.
Prototypes will be used for testing by the developer with the user only getting shown a small number
of prototypes.
2.2 Wikis
The project proposal indicated that a solution might well involve the evaluation and use of existing
wiki software. This section gives a brief introduction to what a wiki is, how they are used today and
the benefits & drawbacks.
The word wiki is short for the Hawaiian term wikiwiki – meaning fast. Wikis were invented by Ward
Cunningham in 1995 who: “…was looking to create an easy authoring tool that might spur people to
publish.”[5] The key point Ward was trying to make is that it must be easy because anyone should be
able to publish and edit anything. A wiki is usually a web based system that enables communities to
develop information collaboratively using simple page creation, editing and commenting.
In order to edit pages very little technical knowledge is required, Appendix C has a comparison of
four wikis’ syntax compared with writing HTML. In each case less writing is required and the syntax
used is easy to learn/understand.
The ease at which anyone can edit content poses a considerable risk of important information being
lost or incorrect information being posted, a number of wiki developments have page histories to
enable information to be rolled back prior to ‘vandalism’. In the case of Wikipedia [47], arguably the
most widely used wiki, the community has established polices and a mature community in order to
make it error free: “…when mistakes occur or vandals strike, the collaborative efforts of the group set
it straight, usually very quickly” [5]. Many of the latest wiki developments incorporate a page history
to enable changes to be rolled back, it may be necessary to have such facilities in the Leeds CAMRA
solution if it is made available to the public.
5
Wikipedia is not, contrary to popular belief, the only successful Wiki available on the web. Many
organisations like Disney, McDonalds, Sony and BMW [5] have wikis managing documents and
information. There are wikis for just about everything you can imagine from travel
(http://wikitravel.org) to star trek (http://memory-alpha.org). There are also a number of hosted
services offered by companies which offer to set up wikis for free or at a cost dependent on
customisation and features.
The benefits of using wikis as a form encyclopaedia have recently been highly publicised. The
Independent reported that the Wikinews project [48] was hailed for its coverage of the London
bombings and hurricane Katrina due to the collective newsgathering by communities [6].
Demonstrating how quickly wikis can develop and rival traditional news sources, nature publishing
recently compared the accuracy of Wikipedia with the Encyclopaedia Britannia. The article reported
that the accuracy between Wikipedia and The Encyclopaedia Britannica was just about on a par, with
both having the same number of major flaws and Wikipedia only having a slightly larger number of
minor flaws [7]. The findings demonstrate the potential for a community to develop both accurate and
up to date information, which is the ultimate aim of the project.
Linux magazine [8] published a review of several small scale wiki applications which do not require
extensive databases or configuration. These wikis are ideal for sites with no more than a few hundred
articles, which rules out their use for the Leeds CAMRA project as there is likely to be approximately
1000 articles (based on the current excel spreadsheet). The article does however highlight the recent
advances in wiki technologies and how they can be use for even small scale projects.
2.3 Similar Projects
Investigating similar projects can provide a valuable insight into the type of information stored by
similar organisations, and the way in which they use software to manage information. This section
looks at two solutions to storing/managing pub data without using a wiki and one solution, in a
different field, which utilises the popular MediaWiki [28] software.
The East Surrey Pub Guide [9], part of the East Surrey CAMRA website, is an online database which
enables users to search by pub name, postcode, beer type and OS reference. The database returns a
list of applicable licensed premises, dependant on your search, each link details the pubs location with
occasional pictures and further information. This is the type of information that needs to be stored for
the Leeds region, however it needs to be collaboratively managed with many members and possibly
the public contributing to the site.
The online UK pubs guide [10] was set up in summer 2005 with the aim of having a vast database
with information on the majority of pubs in the UK. At present the online UK pubs guide lists 400
6
pubs in the Leeds area [10], however only displays the address of each establishment. The ability to
write a review on pubs has been temporarily disabled due to abuse by users, which highlights the risks
of opening a system to the general public. The principle of the UK pubs guide is sound, and with more
input could develop into a concise pubs reference, however at present it appears to be similar to a
yellow pages listing for pubs.
LyricWiki [11] is a free wiki that enables users to view, edit, and create pages containing lyrics for
any song from any artist. At present LyricWiki has over 240,000 pages of legitimate content and has
attracted in excess of 5 million page views [11]. Developed in MediaWiki LyricWiki demonstrates
how scalable the wikis are, without requiring a community as large as Wikipedia in order to offer a
service. There is potential to have a UK wide pubs wiki which could probably expect similar usage
levels.
2.4 Summary
This chapter has investigated and decided upon a development methodology for the project. Wikis
have been introduced in order to give the reader some background information on how they work and
are used. Similar projects have been highlighted in order establish whether a system exists that could
serve Leeds CAMRA’s needs along with identifying the pros and cons of existing systems. The
following chapter investigates the detailed requirements of the new system in order to determine what
needs to be done for the solution to be successful.
7
3 Requirements Analysis
Requirements provide the basis for all projects [14] they need to be gathered in order to know what
needs implementing for the project to be deemed a success [12]. This chapter uses various
requirements gathering techniques to determine the essential and desirable features that should be
implemented for the solution to be a success. The chapter outlines the existing solution so it can be
used as a basis for the development of requirements.
3.1 Existing Solution
The current solution used by Leeds CAMRA is a Microsoft Excel spreadsheet containing over 900
rows of data on licensed premises in Leeds. The spreadsheet is maintained by one member of the
campaign, with other members providing details using various media. The current system presents a
number of problems for data management.
There is only a single point of contact for members if they have some new or updated information, in
order for the information to be added members must remember to inform the controller and the
controller must then remember to add it to the spreadsheet.
The current system makes it difficult to distribute, update and validate information due to it being held
locally by the data controller. Due to its format it is also currently impossible to share this data with
the public. The current solution also lacks any ‘rich’ information i.e. detailed descriptions and user
opinions, rather it contains simple yes/no answers which limits its use to statistics rather than a guide.
3.2 Data Gathering Techniques
There are several ways of gathering data in order to determine system/user requirements. A number
of techniques are usually used in unison to gather a detailed set of requirements. The most common
techniques for gathering data are; analysing sample documents, questionnaires, interviews, research
and observations. The acronym SQIRO is often used to reference these techniques, however the order
of using the techniques does not have to follow the acronym [13]. Questionnaires and Observations
were ruled out as data gathering techniques due to a lack of users and silo type current system.
3.3 Semi Structured Interviews
Semi structured interviews provide rich qualitative information to be gathered about the subject area,
due to the ability of the interviewer to change questions based on their relevance [44]. Interviews also
enable the interviewer to probe the interviewee further if they believe information is relevant to the
project. Interviews are especially relevant to this project as there is only one single ‘lead’ for the
project with a small group of others contributing. Conducting a semi structured interview would
8
enable both the lead individual and other members of the group to be interviewed in a relaxed
atmosphere. Dix et al highlight the need to involve users in requirements gathering to ensure that the
system is useful and accepted by users [15].
3.3.1 Objectives
•
Determine current system format
•
Establish reason for suggesting the use of a wiki in the original proposal
•
Determine existing process for submitting, updating and retrieving information from the
current system
•
Identify criticality of information
•
Establish target user group
•
Determine if there are any information reporting requirements
•
Obtain a copy of the current system (if viable)
•
Establish the target user group(s)
3.3.2 Participants
This project was developed in conjunction with the Leeds branch of the Campaign for Real Ale
(CAMRA) the lead for the project, Dave Ansley, was the main focus of the interview. Tony Jenkins,
project supervisor, was also an active contributor to the interview. Also present were 3 other
CAMRA members who contributed some useful ideas to the discussions.
3.3.3 Results
In order to assess whether the interview was a success the information gathered needed to be assessed
against the objectives of the interview.
Determine current format – Dave demonstrated the current system which was in the form of a large
Microsoft Excel spreadsheet. The spreadsheet contained over 900 rows of information, with various
personalised notes. The demonstration covered the meaning of each column heading, additional notes
stored in the spreadsheet and finally how the reporting was generated using the system.
Establish reason for suggesting the use of a wiki in the original proposal – The original proposal
suggested the use of a wiki as an ideal solution. The interviewer probed the reasons behind this, in
order to determine whether there was a need to look at other solutions. It became apparent throughout
the interview that a wiki solution had been suggested based on the interviewees previous experience
with Wikipedia. Dave and Tony were keen to stress that they were not ruling out the use of other
systems, but liked the features offered by Wikipedia. Specifically they were drawn to the ability for
9
anyone to contribute to information along with the ability to constructively discuss the changes being
made by users.
Several ideas were put forward for existing software that might serve the needs of Leeds CAMRA e.g.
forums, blogs etc. however each of these needed to be judged on its own merits and assessed against
the final requirements. The interviewer had to steer discussions away from existing software in order
to prevent people from having their judgement clouded.
Determine existing process for submitting, updating and retrieving information from the current
system – At present only Dave has access to the spreadsheet, therefore any updates/insertions have to
come through him. This has led to a lot of out dated information remaining in the spreadsheet due to
a lack of input from other CAMRA members. The other members in attendance also highlighted the
many potential areas for information to be ‘lost’ these included; people forgetting to tell Dave of
changes, Dave forgetting to update the spreadsheet, people forgetting to verify changes, changes
being applied incorrectly and the spreadsheet rarely being checked by other members.
Identify criticality of information – Basic premises information i.e. name, address, post code, type of
premises, whether they sell real ale and whether they are part of the national inventory are all critical
to the current system. The idea of the new system would be for it to contain the current spreadsheet
data in user readable form as a starting block for further information to be added on each premises.
Tony and others expressed some concerns that the information provided by the new system might not
represent that of Leeds CAMRA as a campaign, therefore any new system should enable changes to
be reversed and appropriate disclaimers to be in place.
Determine if there are any information reporting requirements – Dave was keen to highlight that he
had not envisaged the new system to be a direct replacement for his existing spreadsheet rather a
resource he could use to enhance and update his spreadsheet. After some discussions between
CAMRA members it was agreed that the new system could be a direct replacement if it reported the
numbers required for the CAMRA Pub Watch Survey (Appendix B).
Obtain a copy of the current system (if viable) – Dave kindly provided a CD with the current
spreadsheet and sent a copy of the pub watch survey.
Establish the target user group(s) – Dave highlighted that to start off with only registered and then
verified users should be able to edit the information in the system. However the public should be able
to view the information and where necessary contact the campaign to highlight an issue.
10
3.4 Sample Documents
The interview led to one output document becoming available in the form of the CAMRA pub watch
survey (Appendix B). This form outlines the information required by CAMRA as part of the
reporting facility of any new system. The only other document which is used in the current system is
the Excel spreadsheet. The spreadsheet would be the input document for a new system and is an
integral part of the current information handling process.
3.5 Research
It became clear after the interview that a lot of research into wikis and other collaborative tools would
be required, this research is detailed in the following chapters. In order to have a sound basis of what
CAMRA was involved in and how it goes about campaigning the Leeds CAMRA website was
analysed along with the national CAMRA website. Both these sites revealed a lot of useful
information about what the campaign does, this information could contribute to the effectiveness and
type of information stored in the new system. The most useful research involved looking at solutions
other CAMRA areas have in place for listing licensed premises. One that was specifically mentioned
by Leeds CAMRA members and later investigated was that of the Surrey CAMRA branches [9].
3.6 User Requirements
Based on the information retrieved through the investigation into the existing solution, interviews,
documents capture and research a comprehensive list of requirements was drawn up for the new
system. These requirements were mainly gathered from the interview, however some implied
requirements were gathered from further research – these requirements were confirmed with Dave.
3.6.1 Essential
•
The system should store basic name, address, postcode, premises type, national inventory
status and real ale status. Based on the information currently stored in the Leeds CAMRA
spreadsheet
•
The system should enable multiple users to view and change content, occasionally at the same
time.
•
Editing should be restricted to authorised users
•
Ability to store images of premises
•
Ability to change modifications easily, to help prevent incorrect information
•
Reporting facilities
•
Web accessible
11
3.6.2 Desirable
•
Different user rights for various member levels and the public
•
The ability to plot premises on maps
•
The ability to group premises by different criteria (similar to auto filter on excel)
•
Be expandable for other CAMRA regions
•
Automated creation of CAMRA pub watch survey
3.7 System Requirements
The planned system will have to be hosted on the Leeds CAMRA web server, the general consensus
was anything free and apache web server compatible could be installed on the server. The specs at the
start of the project were:
•
Apache Web Server
•
MySQL version 4
•
PHP version 4
3.8 Usability Requirements
During the interviews with CAMRA members it became clear that the majority of users would not be
computer experts. When discussing possible ideas with members the main points made were that the
system must be intuitive and easy for all to use. With this in mind any new system would have to
meet various usability guidelines in order for the system to be a success. The usability analysis will
have to be carried out both before and after system completion. During integration with the existing
system it will be important not to detract from current usability standards and where possible aim to
enhance the usability.
3.9 Summary
This chapter has looked at the collection of information in order to gather requirements for the new
system. These requirements will be used as the basis for identifying, adapting and configuring a
system to serve the users needs. The requirements gathered will provide the basis for evaluating the
success of the final system. The next chapter will look at possible alternatives to the suggested wiki
platform.
12
4 Social and Collaborative Software
The original project proposal and interviews with Leeds CAMRA members leaned towards a solution
that would utilise a wiki. The reason for suggesting the use of wiki software was based solely on the
use of Wikipedia by CAMRA members. During the interviews with CAMRA members they made it
clear that using wiki software was purely a suggestion and other software should be considered. This
chapter looks at what social and collaborative software is and compares various popular engines with
wikis. In this context collaborative is defined as more than one person working to develop
information both synchronously and asynchronously.
4.1 What is Social and Collaborative Software?
Social software is defined by Teten & Allen as “…websites and software tools which help you to
discover, extend, manage, enable communication and/or leverage your social network.” [16]. The
Berkshire Encyclopedia of Human-Computer Interaction indicates that the term social software
applies to tools that support “rich multilateral communication and allow patterns of social interaction
to emerge” [17].
Collaborative software enables information to be worked on by numerous parties either
synchronously or asynchronously. Collaborative software takes many forms but most common are
web based collaboration systems as they often enable both synchronous and asynchronous
collaboration. Tools such as email, messenger systems and forums are in everyday use both at work
and socially. Many companies make use of Computer Supported Cooperative Work (CSCW) tools in
order to solve location issues as employees can conduct meetings and conferences without the need to
be in the same place.
Interestingly literature often puts example software in both categories as they enable users to
collaborate to complete tasks whilst building an online social community.
4.2 Possible Solutions
This section investigates the other possible systems that could be customised to meet Leeds CAMRAs
requirements, the possible solutions will be compared against the research done into Wikis in the
previous chapter.
4.2.1 Blogs
A Blog is generally a website which contains an individual’s posts in chronological order, the type of
information stored in a blog is down to the individual owner. Blogs become a social tool as they
13
enable anyone to view and in most cases add comments to the information posted. This information
can be accessed using searches, by scanning through the main page or by using a permalinks (direct
links to a post). M Brady [18] highlights permalinks and comments as been one of the main reasons
blogs have become a popular alternative to a personal homepage. This is due to the ability for people
to contribute to posts and allow them to access posts even when they have ‘fallen off’ the main blog
page.
Blogs are not an ideal solution for Leeds CAMRA as they are generally used by individuals wanting
to post about their own news. Blogs are not the best medium for storing and editing data, plus very
few blog software packages enable more than one person to edit the main subject material.
4.2.2 Email Lists
Email lists are one of the earliest forms of collaboration on the internet. They are used to send
information to multiple recipients and enable each recipient to send to everyone else on the same list.
Due to the way email lists operate every member has to receive information that is sent, which can
lead to wasted inbox space and users becoming irritated with the large quantities of unwanted mail.
There are also portability issues as many people still use non web-based email addresses. Mailing
also lacks search facilities, the ability to edit information and a central storage point.
4.2.3 Google Documents
Google’s recent acquisition of Writely [19] coupled with Google spreadsheet developments enable
users to create and share documents online with the ability for several users to collaborate
development of the documents. Google has added version/revision controls and the ability to see who
is currently editing or is online.
The use of Google spreadsheets would enable Leeds CAMRA to use the existing excel spreadsheet
with many users adding information. This would however require members to sign up to Google
services and also runs the risk of Google starting to charge for the service. The main disadvantage
would be that the excel spreadsheet would remain in the same format with little ‘rich content’ to be
added, such as images, long descriptions and mapping. It would also be difficult to open the
spreadsheet to the public, without risking CAMRA members’ personal details/contact information
being obtained.
4.2.4 Custom System
A custom system would enable Leeds CAMRA to have a system developed to meet their exact
requirements for importing, displaying, manipulating and reporting on premises.
Development of a custom system is likely to take months due to the need for more complex and in
depth requirements. This would have to be coupled with greater user involvement (which is unlikely
to be available as Leeds CAMRA members do this in their own time). Developing a secure, fully
14
tested, standards complying and supported system would require greater resource than available for
this project.
4.2.5 Content Management Systems
The term content management system (CMS) is often used for tools that enable the managing of a
website with the content separated from the presentation [20]. CMS can come in many forms
(including; forums, wikis, blogs etc.) however this section is concentrating on the specific open source
‘portal’ CMSs currently available. Two of the most popular CMSs available are Joomla [21] and
Mambo [22], these CMSs enable the collaborative development of website content using standard
templates. CMSs enable more than one user to change the content of a site, or for each user to be
given rights to edit a certain sections. CMSs are ideal where there are specific sections under the
control of certain users.
The downsides of using a CMS to solve the Leeds CAMRA issue are that they require users to
develop knowledge of the editing and publishing facilities offered by the software, this can become
quite complex due to the content structure and ways of assigning content to publishing styles. CMSs
are also generally geared towards a structured number of users and associated rights, with users
expected to look after certain sections rather than contribute to anything/everywhere. Dependent on
the chosen CMS software there is unlikely to be an effective page history and retrieval system as
editors are expected to have been registered, validated and trusted.
4.2.6 Conclusion
This chapter has looked at possible alternatives to using wiki software as the basis of a solution to the
problem. Both Google documents and email lists offered a quick and fairly easy solution to the
problem, as they would enable the existing spreadsheet to be circulated to a number of members for
them to contribute to. These solutions however would have meant that any ‘rich’ information such as
descriptions and images would have been limited, along with features such as searching, mapping and
the ability for the public to see the information.
The use of blog software was investigated but deemed unsuitable due to the emphasis on a single
poster with others simply able to comment on posts.
The possible development of a custom system was discussed but discounted due to the time
constraints on CAMRA members, the provision of ongoing support after the project had been
completed and finally the likelihood of a completed system adhering to standards.
Content Management Systems were considered as a viable alternative to a wiki (wiki software is often
quoted as being a CMS) the investigation looked at open source CMSs but found that users would
15
have to develop a greater understanding of the CMS software than is generally necessary with wiki
software, plus the user management and history options are not likely to meet the requirements of
Leeds CAMRA.
Based on these investigations and the requirements of Leeds CAMRA it was decided that the
development of a solution should be based on an existing wiki software package.
4.3 Summary
This chapter has introduced the idea of social and collaborative software tools. The chapter has
looked at potential alternatives to developing a solution based on wiki software. As this chapter has
concluded the use of wiki software is likely to be the best option to solve the Leeds CAMRA problem,
the next chapter will look at selecting the most appropriate wiki for the job. The information used to
discount other possible solutions could also play a part in evaluating the success of the finished wiki
based solution.
16
5 Selecting the Right Wiki Software Engine
This chapter compares four popular wiki engines in order to determine the most suitable for solving
the project problem.
5.1 Evaluation Criteria Overview
As discussed in the background research of the report rigorous evaluation of existing wikis is required
in order to select a suitable engine. The usability criteria for evaluating each wiki engine will be
based on the ten web guidelines outlined by Brinck, Gergle & Wood[23]. To summarise the ten web
guidelines are; Content and Scope, Speed, Navigation, Appropriateness to Task, Visual Design,
Compatibility, Simplicity, Consistency and contrast, Error Handling, and Respect for the user.
Complementing these ten general guidelines Jakob Nielsen’s Ten Usability Heuristics[24] will also be
used to evaluate the wiki engines. The ten usability heuristics are; Visibility of system status; Match
between system and real world; User control and freedom; Consistency and standards; Error
prevention, Recognition rather than recall; Flexibility and efficiency of use; Aesthetic and minimalist
design; Help users recognize, diagnose and recover from errors; and Help & documentation.
Usability is an essential feature of the wiki for Leeds CAMRA as it is likely that novice computer
users will be contributing to the system. The full usability evaluation of each wiki is in Appendix E
an overview of the findings is given below.
Along with usability evaluation, documentation will be assessed, the quality of documentation will
determine how well supported a system is and aid in the development of the solution. Compatibility
is essential as the Leeds CAMRA server has specific software and environment compatibility.
Community support will be an essential factor that will influence the final wiki engine decision, a
strong active community means developments are ongoing and support is available whenever needed.
Additional features that will enhance the project and help in achieving desirable user requirements
will be considered.
The wikis to be evaluated are TikiWiki [25], WikkaWiki [26], PbWiki[27] and MediaWiki[28]. The
wiki engines were selected based on the choice wizard offered by wikimatrix.org [29]. The
wikimatrix.org choice wizard compares wiki engines based on technical requirements i.e. language,
history requirements, hosting type, database type and cost.
17
5.2 TikiWiki
Overview
TikiWiki is a feature rich internationally developed CMS/Wiki developed in PHP [25]. In
development since 2002 TikiWiki combines several independent services, such as galleries, blogs and
forums, into one fully functioning content management system.
Usability
TikiWiki scored well on compatibility, use of real world navigation, feedback to user and respect for
the user. It was let down by a lack of accelerators and an effective search facility – especially for
users that are not logged in.
Documentation
TikiWiki documentation consists of over 1,100 pages of information, guides and useful tips [25]. The
documentation, like the software, is developed by the community and therefore is constantly growing.
As with many open source developments TikiWiki points users to support forums and mailing lists for
any un-answered questions or queries with new developments. The documentation is contained
within the wiki which enables users to develop their skills whilst searching the documentation, there
is also a PDF version available.
Compatibility
The minimum requirements for TikiWiki are [25]:
-
PHP v 4.1 (or higher)
-
MySQL v 4.0.x (or higher)
-
Web server with 512MB RAM, 100MB free disk space and a 32MB PHP memory limit
The Leeds CAMRA server meets these minimum requirements so there shouldn’t be any
compatibility issues.
Community Support
TikiWiki is developed by its community which boasts over 300 active developers. On top of the
development community there are forums, mailing list and IRC channels. The project is registered on
SourceForge [30] which also has mailing lists for the TikiWiki community. TikiWiki uses its strong
community as a major ‘selling point’ of the software, stating it as one of the main reasons for fast
stable releases of one of the most advanced CMS/Wiki engines.
Additional Features
TikiWiki boasts a large range of standard and additional plug-ins for the engine. Add-ons include
mapping capabilities, file galleries, calendars, chat, 3D capabilities, even integration with ebay and
18
the use of flash games. A number of these add-ons could be seen as gimmicks and would not add
value to the project.
5.3 WikkaWiki
Overview
WikkaWiki is a lightweight, standards compliant wiki engine written in PHP with a MySQL backend
[26]. WikkaWiki forks from the WakkaWiki engine, which is no longer produced.
Usability
WikkaWiki scored well on its minimalist design and layout, unfortunately it was let down by its poor
search facility and a number of issues with the creation/editing of pages.
Documentation
The WikkaWiki project website has a dedicated documentation section with limited information about
various aspects of the wiki engine. There is a new documentation server under construction which
will enable a greater number of the community to add information to the documentation. At present
the documentation is lagging behind development and the information available through the
community.
Compatibility
WikkaWiki has low system requirements due to its lightweight design and operation, the current
version requires [26]:
-
Access to a web server with at least 1Mb of free disk space (a fresh Wikka install takes
around 700Kb of disk space)
-
PHP 4.1 or above
-
MySQL 3.23 or above
The CAMRA server can easily accommodate the WikkaWiki engine as PHP and MySQL are both
installed and available for use.
Community Support
WikkaWiki has a reasonably large community which supports development, user queries, and
enhancements. There are over 700 sites in 36 languages using WikkaWiki plus the engine has an IRC
channel for users to discuss wiki issues, developments and post queries. A comments system on their
website for users to post views/solutions is used, along with the previously mentioned documentations
system which will enable users to contribute. There does not appear to be a forum for users to discuss
wikka related topics.
19
Additional Features
There are a number of community developments that can be integrated into WikkaWiki, these vary
from Wikka based forums which might be useful for public contribution to the project to Google
Maps integration.
5.4 PbWiki
Overview
PbWiki is the largest consumer wiki farm in the world with over 100,000 wikis [27]. PbWiki hosts
your wiki for free, gives a customised URL (e.g. pubswiki.pbwiki.com) and enables wikis to be
created quickly by anyone. PbWiki offer two versions of their software; a free limited use version
and a premium pay for version with additional features.
Usability
PbWiki impressed with its quality of help and interactive tutorials. The major drawbacks were the use
of advertising on the wiki pages and a lack of features on the free account.
Documentation
PbWiki offers a useful help section for the basic features of the software and offers a ‘tour’ for new
users. There is a FAQ and forum for users of the PbWiki system. Due to the nature of PbWiki there
appears to be no documentation on the implementation of the software.
Compatibility
As PbWiki is a hosted solution there are no compatibility issues, as these are the responsibility of the
host. It does however mean that the idea of having the system hosted on CAMRA servers will not be
realised. There may be issues with the data restraints on the free account offered by PbWiki
(currently 500Mb data), in which case Leeds CAMRA would have to pay for upgrades to the account.
Community Support
The majority of support is provided by the developers of PbWiki, however there is an active forum
[31] where users can post questions that has over 2500 users . Paying for the PbWiki premium
service would offer additional support streams from the developers.
Additional Features
Any advanced features for example: User Restrictions, Advanced Backups, Traffic and Statistics,
Removal of Ads, Lockable Pages etc. All require an additional yearly fee to be paid ranging from
$9.95 to $34.95 a month.
20
5.5 MediaWiki
Overview
MediaWiki [28] is a free, server based wiki distributed under the General Public License. MediaWiki
was originally written for the Wikipedia project but is now used by a number of projects of varying
sizes. MediaWiki is optimised for server farms and uses PHP/MySQL technology.
Usability
The design and layout of MediaWiki was aesthetically pleasing and simple which scored highly in the
evaluation. The use of accelerators and the flexible skin options also scored well. MediaWiki’s
drawbacks were caused by a lack of system status information, and little or no inline help for users.
Documentation
MediaWiki provides code documentation for the software, which is accessible directly from their
homepage. There is a public domain of help pages for users to look up problems and add their own
solutions this is, however, in development. Media wiki also provides a useful FAQ and help desk
facility for users.
Compatibility
As MediaWiki is an actively developed wiki engine there are constantly new releases and changes in
the system requirements. The latest version of MediaWiki requires PHP 5 and MySQL version 4, the
PHP version might present a problem for Leeds CAMRA as they currently run on version 4. It is
however possible to use the previous versions and update when possible. As the software is
distributed under the General Public License there are no licensing issues for Leeds CAMRA to
consider.
Community Support
MediaWiki has an active mailing list for users to post questions and solutions regarding MediaWiki.
There is also an IRC channel for users to sign upto. A quick search on Google also returns a number
of third party open forums.
Additional Features
Due to the popularity of MediaWiki and its emphasis on open source developments there are a
number of additional extension available for MediaWiki. Specific ones that may be useful for Leeds
CAMRA are Google maps integration and Image Galleries. As standard MediaWiki also has page
restriction capabilities which would enable pages to be locked and only have the ‘discussion’ section
edited by the public.
21
5.6 Chosen Wiki
MediaWiki was chosen as the wiki to use for the Leeds CAMRA development, the decision was
based on the high usability scores, quality of community support and the wealth of additional features
available. Second choice was TikiWiki due to its high usability scores and large community support
network, the number of additional features could also have proved beneficial to Leeds CAMRA. The
main down point to TikiWiki was its lack of an effective search facility. PbWiki was discounted due
to the emphasis on advertising, WikkaWiki was discounted due to the number of page creation and
editing difficulties.
5.7 Summary
This chapter has looked at various wiki engines on the web and used various techniques to evaluate
wikis in order to choose the best one for the Leeds CAMRA problem. The next stage is to design how
the solution will be implemented based on MediaWiki.
6 Design
This chapter looks at the interface and data structure design aspects of the solution, as the solution
builds on MediaWiki there was no need to carry out detailed design analysis of the underlying system.
The chapter investigates the technologies used to implement the additional features that interface with
the existing Mediawiki structure, the visual design of the interfaces and the visual layout of pages
within the wiki.
6.1 Choice of Technology
PHP was chosen as the scripting language due to its support for MySQL integration (the backend db
used by MediaWiki) and the ability to use PHP with HTML to create dynamic web pages. As PHP is
a well supported object-orientated language it was deemed ideal for the author to use the language as
there are many parallels with the authors experience with Java. PHP is also the language MediaWiki
is written in therefore using PHP should enable integration between MediaWiki and the additional
interfaces to go smoothly.
JavaScript was chosen to add validation to the statistics generation and reporting interfaces. HTML
will be used as the mark-up language for the interfaces, along with PHP functions.
MySQL was used as the database behind the excel spreadsheet import, this was mainly forced upon
the development as it was the only viable solution offered by the servers which would be used for
22
development. The only other option would have been to use PostgreSQL as the database, as this is an
open source development which could have been installed on a local machine for testing, but this
would have obvious access and portability issues.
6.2 Initial Design
Having investigated the underlying data structure of MediaWiki and discovering the reporting
requirements of Leeds CAMRA, Figure 6.1 gives and overview of what will be produced and how the
sections will interface with each other.
Import Tool
MediaWiki
Reporting Facility
Tool for importing
existing data from
Excel spreadsheet to
MediaWiki
Database
MediaWiki tailored
to meet the
requirements of
Leeds CAMRA
Tools to extract
information from
the wiki and display
in format that meets
Leeds CAMRAs
requirements
Figure 6.1 – Initial Structure Design
The initial design sketches for the additional interfaces are shown in Appendix F with annotations
showing the heuristic design considerations. The design was kept simple as the interfaces would be
used purely by management to generate statistics and import data meaning there was no need for
logos or graphics to make it appeal to the general public. The design also ties in well with Nielsen’s
“Aesthetic and minimalist design" heuristic [24].
The design of the MediaWiki pages was originally based around the existing static information being
displayed in a sensible way with appropriate headings for the various types of information. The
original design ideas gave a good starting point for displaying the data, however it became necessary
to use iterative design techniques during the development of the wiki.
6.3 Iterative Design
Iterative design involves taking an existing design and then reworking it a number of times so that it
meets the customer’s needs. The key to iterative deign is to quickly produce prototypes which
provide good feedback but are also open to major changes [32]. This was deemed the best way of
designing the layout and templates for displaying premises information within the wiki. The design
23
changes generally followed the iterative system development, however there were some occasions
where the design was changed based on a number of prototypes within an iteration.
The iterative design process was based on the original designs shown in Appendix F. As the system
developed the wiki page design changed a number of times, many of these changes were minor (e.g.
adding an additional line or extra piece of information). The major changes are documented in
Appendix F, which shows the gradual development of the wiki page layouts.
The general layout of MediaWiki menus would remain the same however it was decided, after
consultation with CAMRA members, to apply a skin to the wiki in order to distinguish it from the
standard Mediawiki monobook layout.
6.4 Summary
The choice of development software was quite limited due to the hosting provided for the testing, and
the limitations on the current Leeds CAMRA server. The design of the additional features followed a
very simplistic approach due to the nature in which they will be used by administrators to view
statistics and import information. The design of the wiki pages has developed considerably over time
in order to reflect the type and style of information that Leeds CAMRA wanted on the wiki. The
majority of the changes are illustrated in Appendix F with additional information in the following
implementation chapter.
24
7 Implementation
This chapter outlines the implementation of the Leeds CAMRA solution, the solution is a wiki based
system with information imported from the existing excel spreadsheet. The aim of this chapter is to
outline the implemented functionalities of the system along with changes to the design and reasons for
the changes. The chapter will also describe any difficulties that had to be overcome during the
implementation. The chapter is split into three iteration sections which cover the implementation part
of each of the three iterations.
7.1 First Iteration
This section outlines the parts of the system implemented as part of the first iteration within the
development process.
7.1.1 Data Inspection and Conversion
The Excel spreadsheet was inspected for data quality and integrity to make sure any anomalies were
not carried over into the new system. The process involved using the auto filter function within Excel
to check for duplications and un-expected blanks. Of the few anomalies to be detected these were
cross checked with Dave and appropriate action taken. The next step was to convert the Excel
spreadsheet into a format that would enable it to be queried and formatted into MediaWiki syntax. It
was decided that converting the excel spreadsheet into MySQL would enable easy interaction between
test MediaWiki installs and enable standard PHP code to be developed. The process of converting an
Excel spreadsheet to MySQL often requires the purchasing of third party software [33], fortunately a
process was discovered which utilises Microsoft Access and MySQL ODBC drivers to achieve the
desired results. The process involved downloading and configuring the ODBC driver, converting the
excel spreadsheet into access format then using access and the ODBC driver to export to MySQL, the
process followed is a WebThang tutorial [33].
7.1.2 Installing and Investigating MediaWiki
The advantages of having a comprehensive install document became apparent when installing
MediaWiki, the documentation [34] offered various different setting depending on versions and
offered setup instructions for the database. Once MediaWiki had been installed investigations took
place into the basic database structure behind the wiki in order to gauge any possible areas to import
and export data. The LocalSetting.php file contains most the configuration settings for
MediaWiki this file had to be moved and was inspected to get an idea of what it contained as part of
the installation.
25
7.1.3 Development of Wiki Syntax Script
In order for the current information stored in the converted Excel spreadsheet database to be of use it
needed to be presented in MediaWiki format. In order to do this it was necessary to first decide on the
desirable article style (Design Chapter, Appendix F) then use a sample premises and manually create
the page in the wiki. Once this had been completed the syntax formatting could be analysed, in order
to determine what needed adding to the current data for styling.
Connections were made to the MySQL database using the mysql_connect and
mysql_select_db PHP functions. This enabled database queries to be constructed and carried
out using standard MySQL within the mysql_query function. Using the mysql_query
functions meant the results could be stored in a variable and then looped over row by row. The next
step was to return the individual fields within a row and add the necessary wiki syntax. This required
a combination of the PHP echo function and assigning each row to a variable using the
mysql_fetch_array function. To display and make use of the wiki formatted information the
output was put into a HTML form lifted from the MediaWiki page edit source. This would enable
users to import the data into the wiki using the syntax directly from the database, and check the
rendered output in MediWiki.
Figure 7.1: Wiki Formatted Form Input to MediaWiki
Figure 7.1 shows an example of the formatted wiki text generated from the custom wiki.php script,
and the rendered output when saved into MediaWiki.
26
7.1.4 MediaWiki Data Storage Investigation
At this stage it was important to look at how MediaWiki stored the data provided, in order to
determine the best way of preparing the input data for use when reporting. Using phpMyAdmin[35]
the database tables were investigated to discover which ones contained data that could be used as the
basis for management reporting. The MediaWiki database was made up of 29 tables most contained
information that would not be useful for reporting required by Leeds CAMRA (e.g. ipblocks). The
tables of interest were page and categorylinks - page contained (amongst other things) page
titles and unique ID number, these could be interlinked with the cl_from and cl_sortkey stored
in categorylinks to determine page titles that contain specific category links. This meant that
statistics and pages could be returned based on the categories it contained in its wiki page.
7.1.5 Testing
The first iteration was mainly data manipulation and storage investigation therefore the testing was
done in parallel with development by the developer. Testing took the form of data integrity testing
and making sure the rendered output represented the original design.
7.1.6 Summary
The implementation aspect of the first iteration involved looking at the existing data and transforming
it so that MediaWiki syntax could be applied. The process involved converting the existing Excel
spreadsheet into a MySQL database, then using PHP functions to query the database and add
MediaWiki formatting to the data. The resulting data was then fed into MediaWiki using a form
based input tool. The next stage in the implementation would involve improving the data importing
tools and producing reporting facilities.
7.2 Second Iteration
This section looks at the main aspects of the system that were implemented as part of the second
iteration.
7.2.1 Development of XML Import
The data importing solution implemented for the first iteration was ideal for small scale importing, but
would be very labour intensive for the initial Leeds CAMRA Excel spreadsheet import. It was
necessary to look for a solution that would enable a large quantity of pages to be inserted at once
(approx 900 in the case of Leeds CAMRA). The only purpose built script MediaWiki had for
importing data was importTextFile.php however this script is only available on MediaWiki
releases after 1.7, Leeds CAMRA development was in 1.6.8 due to system specification. MediaWiki
did however have an XML backup and import script (discovered after weeks of investigations),
27
inspection of which suggested that the XML could be adapted and added to. The layout and syntax of
the XML dumps created by MediaWiki were dissected to reveal the parts required for each page.
Pages were displayed in the XML dump as a series of tags with MediaWiki formatted text (see Figure
7.2). This created the opportunity to automatically generate the XML page structure using tags and
formatted wiki text.
Figure 7.2: Example Standard MediaWiki XML Page
This raised a problem of how to generate XML from the existing data without having the browser
interpret the script as html tags (e.g. <title> is a HTML tag). After experimenting with a number
of methods, using PHP to create the tags and formatted wiki page information was decided upon.
Generating the XML this way would enable the page source to be viewed to extract the fully
formatted XML. Implementing the XML solution required a number of obstacles to be over come,
these included replacing invalid characters (é and &) with appropriate alternatives (e and &amp;).
Page numbering had to be worked out in order to avoid clashes, this involved the use of a global
variable and for loops. XML requires there to only be one top level element, therefore creating 900
pages required the resulting XML to be imported into the original XML dump which used the
<mediawiki> tag as the top level element. Figure 7.3 shows an example premises in XML format
after the running of wikixml.php (the implemented xml creation script). Once the full XML script
had been created it was uploaded to the maintenance directory of the wiki install, from here command
line PHP script execution was used to run the importDump.php and rebuilall.php scripts –
these scripts import the XML ‘dump’ and rebuild the search indexes.
7.2.2 Data Development
Having discussed the current MediaWiki page layout and data content with Leeds CAMRA members
it was decided that more information should be taken from the excel spreadsheet for presentation in
the wiki, this would be required to meet the stipulated data requirements. The PHP script used to
create the new XML importing script was modified to include some simple logic which would add
ownership information and more detailed contact information, where given. The data was presented
in the style outlined in the second iteration design template (Appendix F). Based on the investigation
in iteration one the categories to be used as part of the reporting facility were discussed with CAMRA
28
members, and related to the existing pub watch survey to determine the categories. Figure 7.3 shows
an example premises with the new ownership information and various categories.
Figure 7.3: Example Premises Based on New Data and XML Layout
7.2.3 Preliminary Reporting Facility
The importing of the Excel database into MediaWki facilitated the development of some preliminary
reporting facilities to be developed. As discussed in the previous sections the reporting would be
based round the categories a premises has been added to. The reporting facility takes each of the
unique categories currently in the wiki database and populates a drop down list. An item in the drop
down list can be selected and the number of applicable articles with their page title is displayed. This
implementation lacked some functionality in that it would be useful to use more than one criteria to
filter results (e.g. Pubs in the Boston Spa district that are open), to do this additional drop down boxes
were added. The main problem with implementing more than one selection box was constructing
MySQL queries that would only return results where all the conditions are true. The implementation
involved validating whether a selection had been made then using where clauses and the group by
function to return results.
if ($firstcat != "" and $secondcat != "" and $thirdcat != ""){
$result = mysql_query("select * from categorylinks where cl_sortkey in(
SELECT cl_sortkey FROM `categorylinks`
where cl_to = '$firstcat'
and cl_sortkey in(
select cl_sortkey from categorylinks
where cl_to = '$secondcat')and
cl_sortkey in (select cl_sortkey from
`categorylinks`
where cl_to = '$thirdcat')
) group by cl_sortkey")
or die(mysql error());
Figure 7.4: MySQL Statement to Generate Reporting Facilities
Figure 7.4 demonstrates the MySQL statement required to produce accurate results.
7.2.4 Editing the MediaWiki Namespace
As the data represented in the wiki has the potential to be edited by a number of users, Leeds
CAMRA wanted a disclaimer displayed on each page. The disclaimer would point out that the
information may not represent the views of Leeds CAMRA. In order to add this to MediaWiki the
namespace had to be edited, this was done by accessing the ‘System Messages’ and adding HTML to
29
the ‘Page Modified’ system message. Using this method saved the need to edit the CSS of each of the
skins available on MediaWiki. Along with the need for a disclaimer there were some features in the
standard MediaWiki sidebar that were not appropriate to the Leeds CAMRA wiki (e.g. Donations and
Community Portal) these were removed by editing the MediaWiki:Sidebar namespace.
7.2.5 Tailoring MediaWiki
The standard install of MediaWiki is open for anyone to create/edit articles which can lead to
vandalism and lots of false information. One of the requirements of the system is that editing should
be restricted, this was implemented by creating user groups and disabling the standard rights. In order
to make the changes LocalSettings.php was edited to include user rights management, this
required user groups and actions to be created then set to either true or false using the format shown in
figure 7.5.
$wgGroupPermissions['camra' ]['move']
User Group
= true;
Action
Value
Figure 7.5: Creating User Groups and Assigning Rights
Further tailoring was made to LocalSettings.php to enable and configure uploads for premises
images. Figure 7.6 shows the completed layout of the articles in MediaWiki based on the changes
made in the second iteration.
Figure 7.6: Example Page After Second Iteration
7.2.6 Testing and Feedback
Parallel testing during development was carried out to ensure the changes made to the data importing
process did not lead to false data representation. Tests were carried out by using the random page
generator (part of MediaWiki) and comparing the returned data with the original Excel spreadsheet.
Testing of the reporting function followed a similar pattern with selections being made and the results
cross referenced with the Excel spreadsheet, using the auto filter function in Excel.
30
Informal feedback was sought via email and conversations with Leeds CAMRA members to highlight
the positive and negative aspects of the MediaWiki design. The main points raised were; the list type
display of data which might put users off expanding articles and a lack of enhancements to the data.
7.3 Third Iteration
This section looks at the implementation as part of the third iteration in the system development
process.
7.3.1 Expansion of Data
Feedback from users on the second iteration highlighted the need to expand on the spreadsheet
information. With this in mind a PHP string parser was used to extract the first part of the post code
i.e. LS6 1**, in order to create a category that links all pubs in a postcode area. Leeds CAMRA
members suggested that this would allow visitors to an area to get information about pubs before
visiting to make an informed choice. Additional categories were added for Real Ale Sellers and
National Inventory Pubs. To complement this wiki links were added to the importing script to link
directly to Owners, Brands, and Run By wiki pages to enhance the user’s experience.
7.3.2 InfoBoxes
Verbal feedback on the layout of information in the second iteration led to infoboxes being considered
as an alternative to listing information on the wiki page. Infoboxes were designed for use on
Wikipedia, they are constant formatted tables for use with articles on a common subject [36]. The use
of infoboxes in the Leeds CAMRA wiki would put all standard premises information in a separate
table template, leaving the article body to be filled with ‘rich’ user information and experiences. The
development process for the final Leeds CAMRA infobox was done through a number of rapid
prototypes. The first prototype infobox followed the basic design of the Wikipedia documentation
example [36]. This provided a static infobox which would display compulsory premises information
e.g. Name, Address, District. The initial infobox did not cater for optional information for example if
a field was not provided by the database then the title would remain and the field would displayed as
blank.
Figure 7.7: Initial Infobox Design
31
Figure 7.7 shows the template design, the template in use and the template in use with a field missing.
The missing field, although not ideal, is ok for a small sample of data however there was a need to
expand the amount of possible data fields to cater for a wider range of premises. A number of
prototypes were developed in an attempt to add logic to the infobox so that when a value wasn’t
present the data would not be displayed.
In order to do this ParserFunctions and an understanding of their syntax was required,
ParserFunctions are extensions applied to the wiki with changes made to the
LocalSettings.php file [37]. The installation of the ParserFunctions followed the
procedure documented on the WikiMedia Meta-Wiki [37]. The initial use of ParserFunctions
was not fruitful due to a lack of syntax knowledge Use of the MediaWiki mailing list was required to
overcome the problem, which stemmed from the inability to encode ‘|’ without utilising a template.
The resulting infobox only had the name, first line of address and postcode as compulsory fields all
others were optional. Figure 7.8 shows the final infobox implementation for a premises with little
information and one with almost all fields, the figure also gives a code extract from the complete
infobox template. The full infobox source can be viewed by entering
Template:Infobox_Premises in the solution deliverable search facility
{{ #if: {{{district|}}} |
! District:
{{!}}{{!}}
{{{district|}}}
}}
|{{ #if: {{{owned|}}} |
! Owned By:
{{!}}{{!}}
{{{owned|}}}
Figure 7.8: Sample Infoboxes
As with all changes to the page layout, these changes had to be added to the XML dump script and
then imported into MediaWiki for the changes to take effect. This required further logic to be
implemented in the wikixml.php script so that only data that existed added to infobox fields.
7.3.3 Stubs
To complement the introduction of infoboxes and to encourage the CAMRA community to develop
articles, stubs were introduced. The term stub is used to describe an article that contains only a small
amount of paragraphs, and needs expanding [38]. Stubs follow the same template type
implementation used for info boxes. An example stub template was created which alerts the user that
32
the article is considered as a ‘stub’ and what the article type is, the stub then invites a user to expand
the article. Once the initial stub had been designed it was further customised by utilising a
background colour to highlight the alert, and an appropriate image was added. The stub then had to
be integrated into the XML script which involved identifying the premises type and automatically
adding the edit page link. Figure 7.9 shows an example stub for pub related articles, the source code
used to generate the sub can be viewed by typing Template:Pub-stub into the deliverable search
facility.
Figure 7.9: Stub
7.3.4 Reporting Facilities
The existing reporting facilities using the dropdown boxes used no validation to check for selections.
Validation was added by utilising JavaScript to check that the first dropdown box had been selected
before enabling another to be selected, figure 7.10 shows the final implementation of the statistics
generation interface and diagram figure 7.11 shows the resulting query matches.
Figure 7.10: Statistics Generation Page
Figure 7.11: Statistics Query Results
33
A desirable extension for the project was to have an automated pub watch survey creation facility.
This was implemented using MySQL queries on the categorylinks table within the MediaWiki
database to determine the numbers required for each of the pub watch survey fields. The results were
presented to the user in a html form, where they can edit the figures if they wish, figure 7.12 shows
the form input populated from the database.
Figure 7.12: Pub Watch Survey Generation Form
After the user has completed the form input a PDF pub watch survey is generated, based on the
original in Appendix B. The implementation of the PDF generation required the integration of FPDF
[39] which is a free to use PHP class that enables PDFs to be created using PHP. The development of
the PDF creation took the form of a number of prototypes. The prototype development enabled an
understanding of how FPDF and its syntax worked to create simple pages. The first few prototypes
were based on simple layout and style changes to PHP generated PDFs. These prototypes developed
over time into taking variables from the form and displaying them in a formatted PDF file, which
represented that of the CAMRA pub watch survey. Figure 7.13 shows the formatted PDF outputted
from the pub survey generation form.
Figure 7.13: Automatically Generated PDF Output
34
7.3.5 Map Integration
Map integration was highlighted as a desirable extension to the solution, some preliminary
investigations took place during the first two iterations as to the viability of using Google Maps[40].
Google Maps proved relatively simple to integrate with the wiki, but was deemed useless due to the
need for Long and Lat coordinates on every premises. An alternative solution to mapping premises
was implemented through integration with MultiMap [41]. MultiMap allows web developers to direct
users to their site based on a customised hyperlink. The hyperlinks consisted of the standard
MultiMap URL with a premises postcode appended to the end, this required further changes to the
XML import script to add postcodes to the MultiMap link for ever premises. Although this solution
requires the user to access a third party site to obtain the location of a premises, it saves Leeds
CAMRA having to pay to geocode premises for Google Map integration
7.3.6 MediaWiki Tailoring
A number of small changes were made to the underlying MediaWiki install to make it more suitable
for users, and to differentiate it from other wikis. A third party skin by Rilgrey [42] was integrated
with the existing install to offer a new custom look to the wiki, Figure 7.14 shows the final main page
using the new skin. The sidebar navigation namespace was edited to include an admin section that
would directly link to the importing and reporting facilities developed for the project (see comments
on Figure 7.14). A simple logo was developed and modified to suit the new skin.
Admin Link
Figure 7.14: Main Page
35
7.4 Migration to Leeds CAMRA Server
The development of the wiki had taken place on a test server, installing MediaWiki and importing the
data would have to be done on the Leeds CAMRA server. The system requirements changed at this
point due to a PHP upgrade on the server, this had knock on effects for the MediaWiki install as the
new 1.9.2 version could be installed. In order to make sure the XML dump would work a test XML
dump was taken from 1.9.2 which revealed that the page id numbering was completely different.
Variables were introduced to the XML document to enable it to work with the new number scheme,
this would also make changing back to 1.6.8 possible if needed. The MediaWiki install was carried
out by a third party, then configuration was carried out via email to make sure all the necessary rights
were in place – this became a particular issue when running the XML import scripts. The import
scripts would fail during the database update, the problem was diagnosed as a MySQL database rights
issue in that the database user did not have rights to alter or drop tables, which is an integral part of
the import scripts. The XML import worked seamlessly with the new version, as did the customised
user groups and the third party skin.
There were a number of technical issues with migrating the administrator area across to the Leeds
CAMRA server. The majority were ironed out, however at the time of writing this report the
automated PDF creation fails at the user input point. This is thought to be a MySQL client difference,
but due to limited access to the Leeds CAMRA server this has not been resolved as yet. The solution
is linked on the main wiki site sidebar, but hosted elsewhere to enable Leeds CAMRA to use the
facility.
7.5 Testing
Testing of the solution was carried out based on the test plan in Appendix G. The testing centred
around; data integrity, the additional interfaces (importing/reporting), page displays and the tailoring
done to the basic MediaWiki. It was decided that testing of the core MediaWiki software would not
be necessary as this was done as part of its development within the MediaWiki community [43]. The
testing revealed a number of validation issues with the additional importing and reporting facilities,
these were solved by introducing JavaScript validation on the form inputs. To improve usability an
additional search results warning was added alerting users that certain search terms and terms less
than three letters would not return results – this was caused by a global MySQL setting that could not
be changed due to the performance impact it would have on searches.
36
7.6 Summary
This chapter has given an overview of the main implementation of the project, the chapter was
structured to follow the system development methodology in order to demonstrate the progression.
There were a number of obstacles that had to be overcome during the implementation of various
aspects of the system, such as the complex SQL queries, the need to develop an understanding of
ParserFunction syntax and implementation of the PDF creation. The following chapter aims to
evaluate the product using various proven techniques.
8 Product Evaluation
This chapter will examine the final solution in order to determine whether the software products are
effective and meet their purpose. The evaluation will also strive to understand whether users will use
and like the system [44]. The solution is evaluated against the essential requirements identified in
chapter 3 to determine whether the solution can be deemed a success. The solution is also evaluated
against usability rules, the same used to identify the chosen wiki, in order to ensure that the additions
don’t detract from the MediaWiki usability score. To help determine whether users will embrace the
system the solution is evaluated against the desirable requirements identified in chapter 3 and user
feedback is sought. The chapter concludes by offering possible improvements/extensions to the
product and summarising the findings.
8.1 Evaluate against essential requirements
This section details the essential requirement, identified as part of chapter 3, then discusses whether
the requirement has been met including any reasons for not meeting or partially meeting the
requirement.
The system should store basic name, address, postcode, premises type, national inventory status and
real ale status. Based on the information currently stored in the Leeds CAMRA spreadsheet – The
XML import script and form based import tool take the information listed from the converted excel
spreadsheet and convert it into MediaWiki syntax. The name, address, postcode and premises type
are all displayed within the infobox (see figure 7.8). National inventory and real ale premises have
categories assigned to them automatically using categories.
37
The system should enable multiple users to view and change content, occasionally at the same time
– By default unregistered and un-confirmed users are unable to create or edit pages. If the user has
appropriate rights to edit an article and someone else is editing the same article when a save is made
MediaWiki highlights the change conflict, figure 8.1 shows the warning that is presented to users.
Users then have the option to save their changes or leave the current article contents.
Figure 8.1: Highlighting Differences in Multi User Editing
There are no rights in place to prevent unregistered users from viewing information within the wiki.
Editing should be restricted to authorised users – As stated above only authorised users can create
and edit pages within the wiki. The ‘camra’ user group was created as part of the implementation
which enables members of the group to edit and create pages. System operators (admins) can assign
users to the user group using the MediaWiki user rights special page, as displayed it figure 8.2, this
ensures that system operators can validate users before they are able to edit pages.
Figure 8.2: User Rights Management
Ability to store images of premises – Images can now be displayed as part of the article infobox or as
additional standard MediaWiki images. The storage of images was enabled and configured as part of
the LocalSettings.php file within MediaWiki
Ability to change modifications easily, to help prevent incorrect information – MediaWiki has a
page history function which enables authorised users (System Operators) to compare revisions of
articles then rollback if necessary (see figure 8.3).
38
Figure 8.3: Page History
The need for history should have been minimised by the implementation of user rights constraints.
Reporting facilities – The implementation of the statistics generation (figure 7.10) and automated pub
watch survey (figure 7.12) has given Leeds CAMRA administrators the ability to construct complex
queries. The reporting facilities enable administrators to select categories to query then returns a list
of applicable wiki pages, with a results counter. Unfortunately due to the way MediaWiki stores page
data, in BLOB format, searching for page text and reporting on the results is made difficult.
Web accessible – The final solution is currently hosted at http://test.leeds-camra.org. Leeds CAMRA
hope to have the solution linked on their main page and with a suitable sub domain soon.
8.2 Evaluate against desirable requirements
The requirements gathering in chapter 3 highlighted a number of desirable features that Leeds
CAMRA would like to see in the system. This section looks at each of the desirable requirements and
identified whether they have been met and discusses reason for not meeting the requirement. Where
requirements have not been met, possible solution are discussed.
Different user rights for various member levels and the public- At present the user rights consist of;
anonymous and registered users who have no rights to edit or create pages, camra members who have
rights to create and edit pages, bureaucrats who have the right to change user rights, bots are for
scripts and Sysops who have unrestricted access. This structure could be added to be editing the
LocalSettings.php file and creating new user groups. Issues might arise if automated user
group assignment was required, in which case an extension to MediaWiki would need developing.
The ability to plot premises on maps – During the implementation of the system a direct link to
MultiMap[41] was created using the premises postcode, this requires the user to click on a link and
load up an external page. During the implementation stage a number of experimentations were
carried out to try and integrate Google Maps [40] with the articles, this centred on integrating the
39
google maps extension [45]. In order to integrate Google maps a key had to be obtained from Google
[45], this had to be done on a per-directory basis which can make moving servers/installs difficult.
The Google maps extension was installed and used in one of the test prototypes, but it proved difficult
to accurately map premises as the longitude and latitude is needed or a geocode to be carried out on
the postcode. Geocoding can be done for free up to the second part of the postcode, anything after
that requires a license. In order to test the extension implementation a geocode was obtained, through
MultiMap, for the Library pub. The resulting integration is displayed in figure 8.4, implementing this
solution for all the premises would not have been possible due to the need to manually obtain
coordinates.
Figure 8.4: Example Google Map Integration
To make full integration successful bulk geocoding would have to be investigated, or an alternate
solution that used existing postcodes.
The ability to group premises by different criteria – This requirement was to use the existing
information in order to group premises (like Excel auto filter), or expand on the data to group
premises. The drop down selection boxes enable premises to be grouped by multiple criteria, and the
categorisation used within the wiki enable premises within a certain category to be grouped. The
XML creation script assigns categories at the import stage based on the information obtained from the
Excel spreadsheet which means grouping can take place straight away. With regards to expanding
groupings this has been done for finding pubs within a similar area by parsing the postcode fields to
an acceptable level and creating a category (e.g. Category: LS6 1 area). A similar kind of data
manipulation could be carried out on other fields to expand the groupings, but this would be limited
by the existing information. Categories and groupings could develop over time through the
community.
40
Be expandable for other CAMRA regions – The wiki could easily be expanded to cover other
CAMRA regions. There are several options open if this were required, the two most obvious would
be to implement a generic website with a sub domain containing a wiki for each CAMRA region,
alternatively a single wiki could be used containing every CAMRA region premises.
Automated creation of CAMRA pub watch survey- As shown in the implementation section this has
been completed and offers the option for Leeds CAMRA administrators to automatically create pub
watch surveys. The final PDF could be improved by offering the ability to add and remove fields for
the future expansion of the pub watch survey.
8.3 Usability Evaluation
During the wiki software selection process there was a heavy emphasis on the usability of the system,
as this was highlighted during the requirements gathering as an important factor in getting users to use
the system. The same usability and heuristic evaluation used in selecting a wiki was used to assess
the final product, these being Brink et al’s Ten usability Guidelines [23] and Nielsen’s Ten Web
Heuristics [24]. The evaluation concentrated on the additional features that were implemented as part
of the solution rather than the underlying MediaWiki install.
Appendix D details the full usability and heuristic analysis, the main points raised from the evaluation
were the simplistic layout of the administrator section with a lack of colour scheme and static
navigation bar. This led to a very plain looking interface with little visual interaction with the user.
The general navigation of the administrator section was simple and easy to follow, but could have
been improved by the addition of a static navigation bar that detailed where the user currently is and
links to other parts of the system.
The speed of use of the system seemed excellent, this was probably enhanced by the lack of
bandwidth hungry graphics and images. There was no improvement on the system status information
for the wiki, but the administrator section does alert the user if connections cannot be made to the
underlying databases.
It would appear from the analysis that the implementation of the administrator section and the
customising of the wiki skin have not detracted form the MediaWiki software. The careful selection
of colours and layout within wiki pages has created easy to understand articles.
The usability analysis was carried out by the developer and therefore could be restricted by the
additional exposure the developer has had to the system. With this in mind there was a need to get
feedback from external users on the general use of the system, the next section details what was done.
41
8.4 User Feedback
The evaluations so far have been carried out by the developer, which is ideal for technical and
methodology based evaluation however they are not a replacement for actual testing with the people
who will use the system[15]. There are various methods for carrying out user based evaluation these
range from conducting laboratory studies to setting scenarios for users to work through.
Unfortunately due to other commitments the main Leeds CAMRA contact for the project was unable
to participate in a thorough user evaluation. To overcome this issue a semi structured approach was
used to gain user feedback, this approached involved pointing users to the completed system with a
small set of general questions. The users were encouraged to use the system and provide as much
qualitative information as they wished this would give them the freedom to answer questions as they
saw fit. The evaluation was carried out by three users closely representing the expected user
population as suggested by Dix et al [15]. The participant sample size of three was chosen based on
Neilsen and Landauer’s findings that suggest usability test with one person uncovers approximately
one third of the issues, and that there is no gain testing more than five users [46].
User A was the
lead CAMRA member, User B was a computer novice who would represent the general public and
User C was a user with a HCI background. To aid the users a copy of the existing spreadsheet was
given to them in order to compare the systems. The full findings transcripts can be viewed in
Appendix H summarised answers to each question are discussed below. Note that the leads CAMRA
member was asked an additional question regarding his intended use of the system.
How well does it meet the general needs of Leeds CAMRA for storing and displaying information
on premises
User A was impressed with the way information was displayed in a concise manner and that it all
seemed to tie in with the spreadsheet data.
User B commented on the lack of information, this is due to there being no community contribution
yet. User B also noted the need to login to pages in order to make changes and the use of images on
some pages, which will expand over time.
User C liked the layout of wiki pages and thought the infoboxes had been used well to display the
data. User C commented on how the admin area was quick aesthetically simple and that nontechnical users might struggle to understand what it does.
Is the system easy to use and intuitive?
User A suggested that users who are not familiar with wikis might struggle to get the hang of the
system, but did point out that once they had some experience of the system it became easy to use and
navigate.
42
User B found the statistics page a little confusing and was unsure of the effects of using the import
facility, non-technical users are unlikely to use the administrator area but with a small amount of
training should be able to use it effectively. The user also noticed that the search facility did not
return some pages, caused by the MySQL setting as discussed earlier.
User C reported that they expected anyone who had used Wikipedia before to easily use the system,
but there might be some issues when using the wiki syntax. The user also suggested that an online
user guide would help. A user guide was considered outside the scope for the project, and could be
developed by the community.
Do you think non-technical members would use the system?
User A suggested that the concept of a wiki would probably be strange to non-technical users and
therefore they may take some time to get used to the system.
User B pointed out that he was able to use the system and classes himself as ‘non-technical’, but did
admit to having used Wikipedia before.
User C suggested that a what you see is what you get (WYSIWYG) editor would help non-technical
users to create and edit pages. The user also pointed out that the admin section could probably be
picked up by non-technical users fairly quickly.
Can you suggest any improvements?
User A suggested that some pointers should be given to users on the front page – telling them to use
the search to find pages. User A also suggested that a customised search facility that enables users to
search on different criteria e.g. Postcode – this is, however, available through standard searching.
User B suggested some Google Map and YouTube integration, as they had seen them before on
Wikipedia. The user also thought the admin section could be more aesthetically pleasing.
User C came up with a number of possible improvements; Dynamic homepage, WYSIWYG editor,
Google Maps, RSS feeds and sorting the search facility.
Do you think the system would be used by Leeds CAMRA in conjunction with, or instead of, the
existing spreadsheet? (Asked to User A only)
User A stated that they would use the wiki to update the existing spreadsheet, which would become
more of a backup facility.
Feedback Summary
The user feedback provided a good basis to evaluate whether the system is likely to be used, and the
improvements that still need making. The quality of the feedback could have been improved by
setting a more concise set of questions or through further interviews. Interviews were, however, ruled
out due to the timescale and commitments of the participants.
43
8.5 Possible Improvements
During the evaluation a number of possible improvements have come to light, some of which could be
implemented without much more work but the majority are extensions that would require a large
investment of time.
The ‘simple’ changes that were identified are:
•
Sorting the search facility so that terms < 3 letters long are returned – Full admin privileges
would be required to the MySQL server, possibly a standalone server implementation would
make this viable
•
Adding pointers for users on how to use the site and its facilities
•
Make the admin section more aesthetically pleasing – Through the use of CSS and attractive
colour scheme
•
Improving the navigation on the admin section – The implementation of a standard navigation
bar similar to MediaWiki could be considered
•
Allow members of the public to contribute to discussions – Use of additional extensions and
changes to the LocalSettings.php file should enable this to be implemented
The more advanced changed, which are likely to require a lot of further work were:
•
Full map integration – this would require geocoding to be carried out on the existing
information
•
Using the MediaWiki look and feel for the admin section – this would require a special page
to be created or the parsing of HTML/PHP to be done within a wiki page.
•
Interactive displays of pub information – Type of interaction and interfacing with the wiki
would have to be considered, along with storage requirements
•
WYSIWYG editor – Currently in development with the MediaWiki community, but yet to
release a ‘stable’ version.
8.6 Summary
This chapter has evaluated the final solution against the essential and desirable requirements laid out
in chapter 3. Along with evaluating against the requirements a usability evaluation was carried out in
order to ensure the customisation and addition to the wiki had not detracted form the original
usability. User feedback was obtained to grasp whether the system is likely to be a success if
implemented by Leeds CAMRA. The four evaluation techniques have reflected positively on the
product, and generally suggest that the solution should be a success, of course this can only be judged
over time as to whether the solution is used. This chapter has concentrated on evaluating the solution,
the next chapter will evaluate the project as a whole.
44
9 Project Evaluation
The previous chapter evaluated the solution to the problem, this chapter evaluates the project process.
The project will be evaluated against the minimum requirements and extensions to the requirements,
the project stages are evaluated with suggestions for further work.
9.1 Evaluation Against Minimum Requirements.
Produce a tool for migrating existing data to new system – Chapter 7 of the report reveals the
implementation of two tools for migrating existing data to MediaWiki. The first tool to be developed
was a form based import tool that enables premises to be imported one-by-one, this tool formatted
Excel fields into MediaWiki syntax ready for saving as a wiki page (see Figure 7.1). The second
migration tool built on the form import tool but utilised the XML dump facilities of MediaWiki. The
script wikixml.php was implemented to convert the Excel spreadsheet data into a MediaWiki
formatted XML dump (see Figure 7.3).
Tailor system to meet Leeds CAMRA user requirements – Through careful requirements gathering
and continual correspondence with Leeds CAMRA members, a system has been implemented that
meets the requirements laid out by Leeds CAMRA. These requirements were gathered in chapter 3
and the project is evaluated against them in chapter 8. Tailoring such as the namespace changes, skin
and user rights are all documented in chapter 7 of the report.
Produce a tool that will enable Leeds CAMRA administrators to obtain management information
from the system – Chapter 7 details the statistics generation tool that was developed as part of the
solution (see Figures 7.10 and 7.11). The tool enables administrators to query the information stored
within the MediaWiki database to generate statistics. The tool also proves useful for correcting data,
as anomalies can be identified by using multiple criteria within a selection.
9.2 Evaluation Against Additional Requirements
Produce a tool for the automated creation of the pub watch survey – Chapter 7 detailed the
implementation of an automated pub watch survey creation, using PDF technology. The
implementation allows Leeds CAMRA administrators to add/change the figures produced
automatically in the survey. The implementation required integration with FPDF [39] and expanded
on the MySQL queries required for the statistics page. The implementation could be improved by
allowing the admin users to add or remove fields without the need to change the underlying code.
45
Produce a system that integrates with mapping software to plot the location of licensed premises –
This additional requirement was partially met by automatically generated links to MultiMap [41],
however this requires users to leave the wiki to view the information. Experiments were carried out
to integrate Google Maps [40] with the wiki and the present information. The integration was
achieved, but plotting the points could not be done with the existing postcode information due to the
need for long and lat coordinates.
9.3 Evaluation of the Project Stages
Methodology – The iterative methodology chosen suited the project well as it enabled large chunks of
work to be completed and then evaluated with Leeds CAMRA. Any improvements and changes
identified were then designed and implemented. Within the iterative approach there was a heavy
reliance on prototyping – especially when developing features with new un-tested syntax. It might
have been more appropriate to adopt a prototype methodology for the whole project, however that
may have led to unsuitable requirements gathering.
Background Research – Chapters 2 and 4 covered most the background research required for the
project. The research centred around wikis and their alternatives in order to make a balanced
judgement on which software engine to base the solution on. Finding literature on modern systems,
such as wikis and blogs, was a difficult task due to only becoming popular in the last 24 months. A
number of potential sources had to be discounted as they were personal views or not reputable
sources.
Evaluation of Wikis – The evaluation of four different wikis carried out in chapter 5, to determine
the most appropriate wiki software, worked well due to the broad range of features evaluated.
Respected usability analysis was carried out on the wikis and investigations into the documentation,
features and support all created a sound evaluation of the wikis. The evaluation could have been
improved by getting Leeds CAMRA members involved with the wiki evaluations, unfortunately this
wasn’t possible due to their other commitments and the time required to carry out such an evaluation.
Requirements Capture – The requirements capture followed a structured approach of interviewing
Leeds CAMRA members to obtain a basic outline of the current system, its problems, and
requirements for a new system. To back up the interviews further requirements were implied from the
existing system, research and similar projects.
46
Design – The initial design of the system was limited due to a lack of in depth MediaWiki knowledge
and the need to develop the system iteratively. Design sketches were carried out for each iteration in
order to progress the system implementation.
Implementation – The implementation aimed to follow three distinct iterations and used a lot of
prototyping within the iterations. The implementation had a natural progression and worked well.
There were a number of issues during the implementation that had to be ironed out and often required
liaising with Leeds CAMRA members. It was important to ensure the essential requirements were
met in order for the system to be a success, so developing prototypes enabled CAMRA members to
get an understanding of how things would work and piece together.
Evaluation Criteria – Evaluating against the essential and desirable requirements ensured that Leeds
CAMRA should be able to use the system. Usability evaluation was carried out to ensure that the
changes and additions to the wiki did not detract from the existing high usability score. Finally user
feedback was sought to get an honest view of the system and to see whether Leeds CAMRA were
likely to make use of the system. The evaluation could have been improved by asking users to
complete a usability walkthrough, however this was not possible due to time constraints on behalf of
Leeds CAMRA members.
9.4 Deliverables
The deliverables for the project have been met in the form of this report and the final wiki system,
currently available at http://test.leeds-camra.org.
9.5 Further Work
The current solution is limited to use with the Leeds CAMRA Excel spreadsheet of licensed premises,
a possible extension to this work would be for a generic tool to be devised for importing spreadsheet
data onto MediaWiki.
At present the system is limited to Leeds CAMRA, a further extension to the work would be to
expand the system to cope with the requirements of other CAMRA regions.
Finally some of the features mentioned by users in their feedback, such as interactive pub guide,
videos and map integration could also be integrated with the wiki.
9.6 Project Conclusion
The project has shown an existing system can be used as the basis for a customised solution that
meets specific user requirements. The project has investigated various software packages and wikis in
order to determine the most appropriate one that meets the users’ needs. The project has
demonstrated that customising and integrating with existing systems can be an arduous task especially
47
when documentation is limited. The project has delivered its objectives and revealed that MediaWiki
can be a useful tool for managing information on licensed premises in Leeds. The solution could be
expanded to other CAMRA regions or used for other applications requiring the capture and
synchronous editing of information.
48
References
[1] LF & MAM Capretz, (1996), Object-oriented Software: Design and Maintenance, World
Sciences.
[2] J Murray, (2006), BT cuts costs with service-oriented architecture. IT Week, 11 August 2006.
[3] I Sommerville, (2004), Software Engineering, 7th Edition, Addison Wesley.
[4] C Larman, (2004), Agile and Iterative Development: A Manager's Guide, Addison-Wesley.
[5] W Richardson, (2006), Blogs, Wikis, Podcasts and Other Powerful Tools for Classrooms,
Corwin Press.
[6] Ana Kronschnabel, (June, 2006) New Media: Who are the real winners now we've all gone Wikicrazy?, The Independent, 26th June 2006
[7] J Giles, (2005), Internet encyclopaedias go head to head, URL:
http://www.nature.com/news/2005/051212/full/438900a.html [10th April 2007]
[8] F Wieduwilt, (2006), Quickie Wikis, Linux Magazine, Issue 73 December 2006
[9] East Surrey Pubs Guide, URL: http://www.beerpage.co.uk/espg/search.php, [10th December
2006]
[10] Online UK Pubs Guide, URL: http://www.onlineukpubguide.com, [10th December 2006].
[11] LyricWiki, http://lyricwiki.org/Main_Page, [22nd April 2007]
[12] I Sommerville & P Sawyer, (1997), Requirements Engineering: A Good Practice Guide, John
Wiley and Sons Ltd.
[13] S Bennett, S McRobb & R Farmer, (2005), Object-oriented Systems Analysis and Design
Using UML, McGraw Hill Higher Education
[14] E Hull, K Jackson & J Dick, (2004), Requirements Engineering, Springer-Verlag London Ltd
49
[15] A Dix, J Finlay, G Abowd & R Beale, (2004), Human-Computer Interaction, 3rd Edition,
Pearson Education Ltd.
[16] D Teten & S Allen, (2005),Virtual Handshake: Opening Doors and Closing Deals Online,
Amacom
[17] W. S. Bainbridge, (2004), Berkshire Encyclopedia of Human-computer Interaction,
Berkshire Publishing Group
[18] M. Brady, (2005), Blogging: personal participation in public knowledge building
on the web, Chimera Working Paper Number: CWP-2005-02, Colchester: University of Essex.
[19] C James, (2006), Google merges Writely and spreadsheet tools, URL:
http://www.computing.co.uk/vnunet/news/2166208/google-merges-writely, [23rd April 2007]
[20] J Patrick, (2006), A nonprofit’s guide to content management systems, Common Knowledge –
Making the right choice series.
[21] Joomla CMS Homepage, URL: http://www.joomla.org/, [23rd April 2007].
[22] Mambo CMS Homepage, URL: http://www.mamboserver.com/, [23rd April 2007].
[23] T Brink, D Gergle & S Wood, (2002), Usability for the Web: Designing web sites that work,
Morgan Kaufmann Publishers.
[24] J Nielsen, (2006), Ten Usability Heuristics, URL:
http://www.useit.com/papers/heuristic/heuristic_list.html [10th November 2006].
[25] Tiki Wiki Homepage, URL: http://tikiwiki.org/ [13th March 2007].
[26] Wikka Wiki Homepage, URL: http://wikkawiki.org/HomePage, [13th March 2007].
[27] PbWiki, URL: http://pbwiki.com/, [13th March 2007].
[28] MediaWiki, URL: http://www.mediawiki.org/wiki/MediaWiki, [23rd April 2007].
50
[29] WikiMatrix – Compare them all, URL: http://www.wikimatrix.org/wizard.php, [5th March
2007].
[30] SouceForge, http://sourceforge.net/, [23rd April 2007].
[31] PbWiki Forums, http://forums.pbwiki.com/, [23rd April 2007].
[32] D Van Duyne, J Landay & J Hong, (2002), The Design of Sites: Principles, Processes and
Patterns for Crafting a Customer-centered Web Experience, Addison Wesley
[33] S Nagra, (2004), Converting Access / Excel to MySQL, URL:
http://www.webthang.co.uk/tuts/tuts_dbase/convert/convert.asp [5th April 2007].
[34] MediaWiki Installation Documentation, URL:
http://meta.wikimedia.org/wiki/Help:Installation, [23rd April 2007].
[35] PhpMyAdmin Project Page, URL: http://www.phpmyadmin.net/home_page/index.php [23rd
April 2007]
[36] Wikipedia InfoBoxes Documentation, URL: http://en.wikipedia.org/wiki/Help:Infobox, [12th
April 2007].
[37] ParserFunction, Wikimedia -Meta Wiki, http://meta.wikimedia.org/wiki/ParserFunctions,
[12th April 2007].
[38] Wikipedia Stubs Documentation, URL: http://en.wikipedia.org/wiki/Wikipedia:Stub, [14th
April 2007].
[39] FPDF Library – PDF Generator, URL: http://www.fpdf.org/, [20th March 2007].
[40] Google Maps API Documentation, URL: http://www.google.com/apis/maps/, [12th Feb 2007].
[41] Multimap, http://www.multimap.com/, [24th April 2007].
[42] Rilgrey - MediaWiki Extension Homepage, http://demo.rilnet.org/wiki/RilGrey_01, [02nd April
2007].
51
[43] MediaWiki Testing and Bug Reporting, http://www.mediawiki.org/wiki/Bugzilla, [20th April
2007].
[44] H Sharp, Y Rogers & J Preece, (2007), Interaction Design: Beyond Human-computer
Interaction 2nd Rev, John Wiley and Sons Ltd.
[45] E Miller (2007), Google Maps MediaWiki Extension, URL:
http://www.mediawiki.org/wiki/Extension:Google_Maps, [22nd April 2007].
[46] J Nielsen and T.K. Landauer, (1993), A mathematical model of the finding of usability problems,
Proceedings of ACM INTERCHI’93 Conference, Amsterdam the Netherlands, 24-29th April 1993.
[47] Wikipedia, http://en.wikipedia.org/wiki/Main_Page, [22nd April 2007].
[48] WikiNews, http://en.wikinews.org/wiki/Main_Page, [25th April 2007].
52
Appendix A – Personal Reflection
After having early reservations about the project it has grown on me, and I am now both pleased and
relieved to have completed it. As the project developed I became more and more interested in how
wikis worked and how versatile they can become. It was refreshing to be given a task with few
boundaries and the opportunity to express the skills learnt over my four years at University.
The first lesson I learnt was how difficult it was to develop existing software, and how this is made
increasingly difficult if no one in the ‘community’ has attempted to solve a similar problem. There
were many a day spent crawling over code and scripts to find the solution to a problem. Finding
solutions was often a painstaking a frustrating task, this was made increasingly annoying when the
eventual solution would be relatively simple. The task of customising MediaWiki was just as difficult
due to the need to develop an understanding of the strange syntax used to code templates and special
pages. The use of forums and mailing lists proved priceless for answers to basic queries that didn’t
seem to be documented.
Secondly I learnt the importance of developing code using an Integrated Development Environment
(IDE). Having spent months coding on a server based text editor and having endless numbers of
useless error codes (quite often no error codes), the use of an IDE would have enabled the
development and debugging to go far smoother.
Thirdly I found it very difficult to find suitable literature on modern web based systems such as wikis
and blogs. There were plenty of pages written in Wikipedia and the like, but it took a lot of research
to find relevant written or reputable web based material.
Finally I once again learnt the lesson of time management. When you start the project there seems to
be so much time, and a lot of little bits are done rather than concentrating on a section. This leads to a
mountain of work in the second semester, which has to be done along with modules. I would
normally put this down to bad planning, but that wasn’t the case – rather it was a distant deadline that
seemed to relieve pressure.
With regard to third parties it is important to realise that they have their own problems and jobs to do.
I learnt it was very important to keep third parties informed of project progress so that they don’t
‘forget’ what is being done. It was important for me to respect that third parties time was often
precious and I should not expect them to drop everything to answer my questions.
53
Based on the lessons learnt from this project I would recommend the following three points to a
student who was considering developing an existing software package:
-
Sign up to lots of forums and mailing lists that are concerned with the software you are
developing, they are a font of knowledge – make sure you respect their input.
-
Try to find a reliable IDE that you can use for developing your scripts, this will make finding
and solving bugs much easier
-
Finally, when developing with ‘new’ software e.g. wikis expect it to be difficult to find
appropriate literature, and remember to check the sources of web pages to make sure they are
not purely someone’s website about wikis.
54
Appendix B – Pub Watch Survey
55
Appendix C – Syntax Comparison
In addition to the web design guidelines and the heuristic evaluation of each site, a syntax comparison
was carried out between the four wikis to determine if any lent itself to greater usability.
The sentence will use standard bold, italic and links in order to determine how similar/different
syntax is. The sentence, when rendered should look like:
At the end of the war, before the election that he lost in 1945, "The Times of London" prepared an
editorial suggesting that he campaign as a nonpartisan world leader and retire gracefully rather
soon afterward.
The editor first informed Churchill that he was going to make these two points. "Mr. Editor,"
Churchill said to the first point, "I fight for my corner." And, to the second: "Mr. Editor, I leave
when the pub closes."
Churchill Insurance
Main Page
The syntax will be compared against writing the above in HTML, the standard web mark-up
language, which looks like:
<p>
At the end of the war, before the election that he lost in 1945, <b><i>"The Times of
London"</b></i> prepared an editorial suggesting that he campaign as a nonpartisan world leader
and retire gracefully rather soon afterward.
<br>
The editor first informed <b>Churchill</b> that he was going to make these two points. "Mr.
<i>Editor</i>," <b>Churchill</b> said to the first point, "I fight for my corner." And, to the
second: "Mr. <i>Editor</i>, I leave when the pub closes."
<br>
<a href= http://www.churcill.co.uk>Churchill Insurance</a>
<br>
<a href=http://pubswiki.co.uk/wiki/index.php>Main Page</a>
</p>
In TikiWiki syntax the sentence is constructed using the following syntax:
At the end of the war, before the election that he lost in 1945, ''__"The Times of London"__''
prepared an editorial suggesting that he campaign as a nonpartisan world leader and retire
gracefully rather soon afterward.
The editor first informed __Churchill __that he was going to make these two points. "Mr.
''Editor''," __Churchill __said to the first point, "I fight for my corner." And, to the second: "Mr.
''Editor'', I leave when the pub closes."
[http://churchill.com|Churchill Insurance]
((Home Page))
56
In WikkaWiki the sentence looks like:
At the end of the war, before the election that he lost in 1945, //**"The Times of London"**//
prepared an editorial suggesting that he campaign as a nonpartisan world leader and retire
gracefully rather soon afterward.
The editor first informed **Churchill** that he was going to make these two points. "Mr.
//Editor//," **Churchill** said to the first point, "I fight for my corner." And, to the second: "Mr.
//Editor//, I leave when the pub closes."
[[http://www.churchill.com Churchill Insurance]]
HomePage
In PbWiki the sentence looks like:
At the end of the war, before the election that he lost in 1945, ''**"The Times of London"**''
prepared an editorial suggesting that he campaign as a nonpartisan world leader and retire
gracefully rather soon afterward.
The editor first informed **Churchill **that he was going to make these two points. "Mr.
''Editor''," **Churchill **said to the first point, "I fight for my corner." And, to the second: "Mr.
''Editor'', I leave when the pub closes."
[http://churchill.com/|Churchill Insurance]
FrontPage
In MediaWiki the sentence looks like:
At the end of the war, before the election that he lost in 1945, '''''"The Times of London"'''''
prepared an editorial suggesting that he campaign as a nonpartisan world leader and retire
gracefully rather soon afterward.
The editor first informed '''Churchill''' that he was going to make these two points. "Mr. ''Editor'',"
'''Churchill''' said to the first point, "I fight for my corner." And, to the second: "Mr. ''Editor'', I
leave when the pub closes."
[http://www.churchill.com Churchill Insurance]
[[Main Page]]
Summary
After constructing the sentence in each wiki it became apparent that the syntax used by the wiki
engines was very similar. In each case there were tools to assist in adding syntax and the overall
sentence was constructed with no knowledge of the native wiki syntax. Overall producing articles is
probably less time consuming than writing HTML and the additional tools offered by each wiki
engine made writing articles very easy.
57
Appendix D – Final Solution Usability Analysis
Brink et al - Ten Web Guidelines
Content and scope
The implemented solution has been shown to meet the essential requirements outlined as part of the
requirements gathering. The system has also shown the potential for the information to grow and
develop over time.
Speed
The statistics generation is very quick, due to the need to only call one table within the wiki database.
The overall speed of the wiki doesn’t spear to have been affected by the increase in information, With
multiple users there may be a performance hit.
Navigation
The use of sensible links to and from the main administrator’s page help the user navigate to the
appropriate statistics. The administrator’s area lacks a constant static navigation bar which would
improve the users experience and help them recognise where they are within the system. The sensible
creation of categories and links within the wiki help the user to navigate to appropriate/ interesting
topics.
Approaches to Task
The available tasks and what they are is clearly represented by the use of sensible naming and small
snippets of helpful text within the administrator’s area. The information displayed within the wiki is
well laid out with clear distinctions between sections, infoboxes, links and categories.
Visual Design
The implementation of the additional features took a very simplistic approach with the functionality
coming above the visual design. The simplistic design helps the user focus on the task and navigate to
where they need to go. The layout doesn’t however follow the wiki as a whole. Wiki pages are
presented well with infoboxes to tidy up general information, and plenty of space for additional
information.
Compatibility
The additional areas have been tested on both firefox and internet explorer with no adverse effects.
Work needs to be done to pass w3c validation.
Simplicity
The use of infoboxes and categories to tidy up the information ensures that the user isn’t confused or
presented with strange, out of context data. The administrator area uses a very simple layout with
clear instructions of what is happening.
Consistency and Contrast
The consistency of the wiki remains throughout with boxes on the right, categories to the bottom,
stubs at the bottom of the free text area and general information in the centre of the page. The
administrator area uses the same basic colour scheme and general text layout throughout the add-ons,
baring the PDF which is formatted to resemble the pub watch survey.
Error Handling
Basic validation and error handling has been implemented to prevent users from entering
inappropriate data. The error messages advise the user what has gone wrong and provide information
on how to solve the problem.
58
Respect for the User
This section probably doesn’t apply to the addons or the additional information added as there is no
unnecessary functionality, or signup requirements.
Nielsen’s Ten Heuristics
Visibility of system status
No additional system status information has been added to the system, however there are messages
displayed if the connection to MySQL databases fails
Match between system and the real world
The use of infoboxes and stubs are in parallel to the ones often seen in the popular Wikipedia online
system. The use of standard form inputs in the administrator area should help the user familiarise
themselves with the system.
User control and freedom
Validation is used to make sure users only enter valid information into the statistics generation
options. The wiki pages don’t detract from the existing control and the use of the underlying
MediaWiki.
Consistency and standards
The consistency of the wiki remains throughout with boxes on the right, categories to the bottom,
stubs at the bottom of the free text area and general information in the centre of the page. The
administrator area uses the same basic colour scheme and general text layout throughout the add-ons,
baring the PDF which is formatted to resemble the pub watch survey.
Error Prevention
To help prevent users form crashing the system validation is used on the drop down boxes to prevent
users from selecting categories in the wrong order. In addition to this validation is used to prevent
incorrect data from being entered into forms.
Recognition rather than recall
All options are clearly linked on every page throughout the administrator area. The wiki page links
are clearly identifiable and colour schemes used to alert users when information needs adding.
Flexibility and efficiency of use
No additional accelerators were added to the administrator area as they weren’t deemed necessary due
to the need for users to enter information from drop down boxes or form inputs. The wiki itself had
another skin applied to it, the user can change the skin if they wish.
Aesthetic and minimalist design
The implementation of the additional features took a very simplistic approach with the functionality
coming above the visual design. The simplistic design helps the user focus on the task and navigate to
where they need to go. The layout doesn’t however follow the wiki as a whole. Wiki pages are
presented well with infoboxes to tidy up general information, and plenty of space for additional
information.
Help users recognize, diagnose and recover from errors
Basic validation and error handling has been implemented to prevent users from entering
inappropriate data. The error messages advise the user what has gone wrong and provide information
on how to solve the problem
Help and documentation
No additional documentation other than small help tips have been added to the system.
59
Appendix E – Wiki Usability Evaluation
Introduction
An integral part of the new Leeds CAMRA system is usability, throughout the requirements gathering
it has become obvious that usability will have a big impact on whether members will use the system.
The majority of CAMRA members are computer novices, therefore any system that is developed must
be easy to use and provide information in a way that they want.
In order to assess the usability of the four wiki engines chosen for evaluation the usability for the web
criteria outlined by Brinck, Gergle & Wood[23] and Jakob Nielsen’s ten heuristics for user interface
design[24]. Each wiki engine will be assessed on the 20 categories and a mark out of five given to
each section, starting with Brink et. al.. The marks will be added to a matrix and the resulting scores
will determine which engines are the best from a usability perspective. In order to assess the usability
it will be necessary to use both ‘clean’ installs and examples of fully functioning wikis.
Brink at al Ten Web Guidelines
TikiWiki
Content and Scope
When first installed TikiWiki offers very little content to an unregistered user, there is little detail
about TikiWiki and no where to search for content. There is no obvious scope for expansion as there
is no add page – or even a register button. When logged in as an admin user things become more
obvious and there are various settings which can be enabled. There are lots of menus with each
section giving a brief description about what it does.
Score: 3
Speed
The speed is hard to judge in test, and due to the availability of broadband speed is becoming less of
an issue. However it is still important to have software that will not require extreme high
specification servers to run (due to the cost implications). TikiWiki makes good use of text and CSS
in order to reduce the need for graphics and intense processing. There is also a handy footer which
shows the current memory usage, server load and execution time. At present these are all low and
performance seems very good, examining other sites based on TikiWiki also show no signs of
performance issues.
Score: 4
Navigation
The navigation bars used by TikiWiki is clearly laid out with text styles used to differentiate between
the sections and sub sections. TikiWiki makes good use of dividers to distinguish between sections.
The main drawback is the lack of an obvious search facility when not an admin user. One of the first
things look for is a useful search facility – especially when users may not be sure what they are
looking for.
Score: 2
Approaches to Task
60
TikiWiki fails to make it clear what a user is expected to do and what they can do with a page. There
is no obvious highlighting of where a user is in the process of using the wiki. There are some useful
buttons when logged in which indicate the tasks that can be carried out (dependent on group
permissions).
Score: 3
Visual Design
The page layout seems quite simplistic with the navigation separated from the page content. The
colours and font are easy to read, plus the limited number of icons represent similar everyday
operating system icons e.g. folders. There is some clutter due to the number of menus and options
available, however there are ways of minimising these.
Score: 4
Compatibility
The site is designed to work across a number of platforms and browsers. There are also a number of
addons to enable further expansion and to convert for different languages. Different themes can be
applied to suit user preferences, also the use of standard w3c code should ensure further compatibility.
Score: 5
Simplicity
TikiWiki scores well on simplicity there are clear distinctions between categories and only a couple of
words maximum are used to represent each menu link. It could be possible to remove some of the
logos and information in the footer, plus the TikiWiki assistant form the sidebar.
Score: 4
Consistency and Contrast
The layout, colours and font remain consistent throughout TikiWiki, also the CSS complies with w3c
standards. The effective use of bold and background colours help show how sections contrast.
Score: 4
Error Handling
Due to the nature of these tests very few errors have been found, of those found a simple error
message is displayed to show the user what the issue is.
Score: 3
Respect for the User
There are no compulsory fields for mailing lists or any intentional trapping onto paths. It is however
necessary to register in order to create and edit pages, there is no requirement to register in order to
view pages. As this is an open source community development there is little need for commercial
traps or gain. There are some subtle links to the software and development homepages but these are
not designed to trap the user.
Score: 5
WikkaWiki
Content and Scope
61
Under a new install there is little content regarding the subject area, however there is some default
content which points the user at how to add to the wiki. The main page details the installed version
and links to wiki pages that deal with formatting, documentation, etc. This enables a first time user to
learn the basics to creating new pages and formatting them. The main feature that WikkaWiki seems
to lack is an easy GUI based way to create a page, instead the page has to be entered into the URL.
Score: 3
Speed
WikkaWiki uses valid XHTML and CSS to w3c standards which should help keep download speeds
to a minimum. The pages contain very few images, with the majority of information presented as
structured text using CSS formatting. As a useful indication of speeds WikkaWiki prints the time
taken to generate the page in the bottom right.
Score: 5
Navigation
There are two standard navigation bars that remain throughout the use of WikkaWiki, these are used
to access important automatically generated pages such as PageIndex. The PageIndex lists every
page inside the wiki, there appears to be the only alternative to using the search facility to find pages.
The search facility is very poor in that it doesn’t seem to work – this could be an installation issue, but
makes using the wiki very difficult. WikkaWiki also makes navigation worse by requiring the user to
enter the URL of pages that they wish to create.
Score: 2
Approaches to Task
Basic tasks such as editing, adding comments and looking at the history of pages are clearly shown by
the wiki through the use of sensible naming and standard links. WikkaWiki is once again let down by
the lack of a GUI to create new pages.
Score: 3
Visual Design
There is a standard layout to all the pages in WikkaWiki and the colours are used well to make
information clear. The layout is kept simple with no cluttering, dividers and borders are used well to
enhance the visual appeal.
Score: 4
Compatibility
As WikkaWiki conforms to w3c standards it should work across a multitude of browsers. The
PubsWiki example install was tested on both Linux and Windows with various browsers with no
obvious ill affects. The lightweight approach to WikkaWikis development should reduce loading
times on low bandwidth connections and also reduce the need for a high spec machine to run/view the
wiki.
Score: 5
Simplicity
The general layout and presentation of WikkaWiki is very simple. The use of capital letters instead of
spaces in page names might put some users off. The interface is easily to follow and understand.
Once again WikkaWiki is let down by there being no obvious page creation tool.
Score: 3
62
Consistency and Contrast
The use of carefully selected shades of colour and the use of bold helps the user understand where
they are in the wiki. The use of standard CSS should help ensure that WikkaWiki is consistent with
external sites too
Score: 4
Error Handling
Throughout the usability testing of WikkaWiki the only obvious error is the search facility which
never seems to work – or display errors. Otherwise there have been errors where pages have not
existed or the incorrect naming convention has been used, in these cases WikkaWiki details the issue
so the user can take appropriate action.
Score: 4
Respect for the User
There are no compulsory fields for mailing lists or any intentional trapping. It is necessary to register
in order to create and edit pages, there is no requirement to register in order to view pages. There are
some subtle links to the software and development homepages but these are not designed to trap the
user, in fact this is more likely to assist the user with developing content.
Score: 5
PbWiki
Content and Scope
Pb Wiki appears to have the standard features you would expect from a self-installed wiki. Once an
account is created the main page details how to start developing content and the wiki. There are also
useful tutorials and demos on how to make changes to get the most from your wiki. The creation of
pages, editing, history and commenting are all as expected. The only obvious problem is the inability
to add additional registered users (without paying for an upgrade).
Score: 4
Speed
As Pb Wiki is hosted by a third party and contains lots of rich information e.g. demos the site can
occasionally run slowly. Generally the speed is similar to a custom install, but during peak periods
the speed and performance can be impacted. As it is not possible to view the source there is no way
to check if Pb Wiki complies to standards.
Score: 3
Navigation
The navigation to standard features such as creation and editing of pages remains easy to access on
every page. Unfortunately there are a number of adverts on the wiki (in order to finance the site)
which detract from the navigation bars. The search facility works well by returning all pages that
contain the search criteria. A number of additional, but not essential, navigation boxes are on each
page but are smaller to indicate their less frequent use.
Score: 3
Approaches to Task
63
The information and demos available through the Pb wiki would help a new user understand what
they need to do in order to create wiki content. The flow from one task to another is obvious and
variations to buttons distinguish between tasks.
Score: 4
Visual Design
The design of WikkaWiki is consistent, with the important navigation buttons featuring heavily on
each page. Unfortunately the page is cluttered with adverts, additional features and un-necessary
information.
Score: 2
Compatibility
The wiki works in a number of different browsers and seems to display without issues. As the
solution is hosted there shouldn’t be any future equipment issues from a hosting aspect as these will
be handled by the company. It is reliant on internet access, so would be no use for an internal LAN
deployment if there was to be a need by CAMRA.
Score: 4
Simplicity
The core features are simple to use and navigate to, the language is clear and icons (where used) are
appropriate. Once again Pb Wiki is let down by the additional clutter generated form adverts,
highlighting of features and additional (non essential) features. The wiki was very easy to set up as all
the configuration is done by the Pb Wiki admin team.
Score: 3
Consistency and Contrast
The layout of navigation bars, page content and adverts remain consistent throughout the viewing of
pages. The colours used generally work well, apart form the background colours which probably
need to vary more in order to achieve contrast between sections.
Score: 3
Error Handling
As this is a retailed solutions there don’t appear to be an errors in the system operation. If the user
tries to do anything untoward an appropriate message is displayed alerting the user to the problem,
and in most cases how to solve the issue. On top of this if there are any issues the system
administrators can be contacted.
Score: 5
Respect for the User
The sign up procedure for Pb Wiki only requires the user to enter the desired wiki name and an email
address. There are then several attempts (directly and indirectly) to get you to upgrade your account.
There attempts aren’t particularly frequent, but still distract from the free version of pb wiki.
Score: 2
MediaWiki
Content and Scope
64
Once installed MediaWiki has a fairly simple main page which details resources for users to use when
editing/creating content. There are clear navigation tools for editing and adding comments to pages.
Both a toolbox and getting started section are available to the user to start off with – additional help is
available via mailing lists and FAQs provided by MediaWiki.
Score: 4
Speed
There is no indication on the install as to whether the MediaWiki code adheres to w3c standards, nor
is there a visual display of how long pages took to generate. The general use and searching of
existing projects using MediaWiki appear to be quick, however each new version utilises the most
upto date software – this may impact on some serves performance.
Score: 3
Navigation
When editing pages the navigational tools at the top of the site are used, these options are available on
each page the user has editing access to. Navigation to standard pages within the wiki are accessed
using the two separate navigation boxes that appear on the left hand side. The use of tabs is used to
identify where the user is whilst editing a page, for standard pages the title of the page is displayed at
the top of the page and in the tab. The searches search for both page titles and text within a page, the
search results are sectioned of to enable the user to identify the most relevant result.
Score: 4
Approaches to Task
The tasks available to the user are clearly identified using sensible names for the action buttons in the
navigation bar. All the basic page functions can be easily identified, when searching for pages
additional options such as creating a page are clearly identifiable.
Score: 4
Visual Design
The look of MediaWiki remains throughout the site, as does the colour scheme and text style.
MediaWiki uses a simplistic uncluttered approach, enabling the page content to dominate the page
rather than the wiki software. The clean use of colours means that the message of the page content is
not lost or detracted from.
Score: 5
Compatibility
MediaWiki has been tested in both Linux and Windows with various browsers without any issues.
There are also a number of additional plug-ins and extensions which enable MediaWiki to be
distributed over a number of platforms in a number of languages. As the source for MediaWiki is
freely available and developed continuously by the community any compatibility issues found are
soon put right.
Score: 4
Simplicity
MediaWiki adopts a very simple approach to doing the basics, there is a need to develop wiki syntax
skills if the user wants to create rich content. The limited use of logos and careful use of
coloured/bold text helps the user distinguish between sections.
Score: 4
65
Consistency and Contrast
The manipulation toolbar at the top of each page is easily distinguishable from the standard navigation
links to the left due to the use of tabs as opposed to hyperlinks. The use of bold and outline border
colouring helps the user identify the stage they are at in the current process. The pay layout remains
consistent throughout MediaWiki, even for standard system information pages.
Score: 5
Error Handling
MediaWiki aims to deal with any invalid information that is entered by the user for example
MediaWiki details faults that often occur when entering invalid search terms. There is also the ability
for system administrators to add additional information to pages to assist users when errors occur.
Score: 4
Respect for the User
There are no compulsory fields for mailing lists or any intentional trapping. It is not necessary to
register in order to edit pages, however this can be changed by admins. There are some subtle links to
the software and development homepages but these are not designed to trap the user, in fact this is
more likely to assist the user with developing content.
Score: 4
Scoring Matrix
Content and Scope
Speed
Navigation
Approaches to Task
Visual Design
Compatibility
Simplicity
Consistency and Contrast
Error Handling
Respect for the User
Total
TikiWiki
3
4
2
3
4
5
4
4
3
5
37
WikkaWiki
3
5
2
3
4
5
3
4
4
5
38
Pb Wiki
4
3
3
4
2
4
3
3
5
2
33
MediaWiki
4
3
4
4
5
4
4
5
4
4
41
Nielsen’s Heuristics
TikiWiki
Visibility of system status
TikiWiki displays the execution time, memory usage, number of database queries and server load to
inform the user of the current system status. The left hand bar changes depending upon the status and
rights of the user too.
Score: 4
Match between system and the real world
66
The menus are constructed in a similar tree-like way to many operating systems which should help
users when navigating the site. Unfortunately the site uses some technical terms in some of the
menus. However the basic controls are simple and easy to understand with standard icons used for
tools (e.g. Bold and Italic icons).
Score: 4
User control and freedom
TikiWiki has a history for each page which enables unwanted changes to be reversed, there is also the
ability for administrators to restrict page access to help prevent unwanted changes. As this is a web
browser based system standard back, stop and forward buttons work which also help aid the user.
Score: 3
Consistency and standards
TikiWiki adheres to CSS and RDF standards, the page navigation layout remains the same throughout
the wiki.
Score: 4
Error Prevention
As an administrator very little is done by the system to prevent you from performing tasks that may
cause errors, however as a standard user most options are hidden from users. General help is offered
to users for wiki formatting to help prevent rendering errors.
Score: 3
Recognition rather than recall
TikiWiki uses a standard navigation bar to the left hand side which enables users to easily identify
where they would like to go next. The use of smilies and ‘quicktags’ enable users to write in
TikiWiki format without having to remember the syntax.
Score: 4
Flexibility and efficiency of use
There don’t appear to be any accelerators in TikiWiki, once a user has developed a knowledge for the
syntax then the tags may not be needed – therefore speeding up interaction. There are no obvious
keyboard shortcuts to help accelerate use. Some simple functions like the ‘quick page edit’ facility is
available to anyone and would probably be a standard tool for developers.
Score: 2
Aesthetic and minimalist design
There are clear distinctions between the different navigation sections, which can be minimised by the
user if they wish. The general layout is quite minimalist, however there are a number of ‘powered by’
icons at the bottom of the page and tips which may distract the user.
Score: 3
Help users recognize, diagnose and recover from errors
The error messages given by TikiWiki are generally a brief overview of the problem then a reference
to a TikiWiki module or page for the solution, this system may confuse novice users.
Score: 3
67
Help and documentation
TikiWiki uses both inline help (e.g. syntax help) and additional help through documentation on the
tiki site.
Score: 4
WikkaWiki
Visibility of system status
WikkaWiki provides an page generation time to the user at the bottom of the page, this gives an idea
of system performance/status. WikkaWiki also states whether you are logged in or not.
Score: 3
Match between system and the real world
The naming convention used by WikkaWiki uses standard English without spaces and capital letters
used to distinguish between words, this is a fairly simple format to follow. The navigation doesn’t
seem to follow and real world standards or conventions.
Score: 3
User control and freedom
WikkaWiki is fairly open to editing without advance access controls being set for each page by the
wiki owner, this can lead to unwanted information being added or users finding themselves in
situations which are unclear. The ‘create page’ links also appears to be hit and miss as to whether it
works.
Score: 2
Consistency and standards
The consistency of WikkaWiki remains constant throughout plus it adheres to XHTML and CSS
standards.
Score: 4
Error Prevention
WikkaWiki seems to have a number of errors with creating and editing pages caused by URL
encoding. The errors shown by the system provide little help as to how to overcome the issues.
Score: 1
Recognition rather than recall
The standard functions offered by WikkaWiki e.g. page editing remain on each page in the same
position and same naming reducing the amount of recall required by user. Tools such as
automatically adding syntax also saves the user from having to remember syntax.
Score: 4
Flexibility and efficiency of use
Advanced users can use direct URLs to create and edit pages rather than using the WikkaWiki
functions. There are no apparent keyboard shortcuts however advanced users who become familiar
with the syntax should be able to create pages quicker than novices as they don’t rely on using
WikkaWikis icons.
68
Score: 3
Aesthetic and minimalist design
The design of WikkaWiki is very simplistic with only basic functions and standard pages linked
through the navigation bars. There is no unnecessary clutter or icons that detract from the page. The
colour scheme and layout are pleasing to the eye.
Score: 4
Help users recognize, diagnose and recover from errors
The error messages created by WikkaWiki provide an overview of the problem, but rarely highlight
how the user can solve the problem. There is some inline help offered to users for syntax and page
creation.
Score: 3
Help and documentation
WikkaWiki offers inline help for syntax editing and also links on the main page to the WikkaWiki
documentation pages. WikkaWiki also has a sandbox for users to test their page editing and
navigation.
Score: 4
PbWiki
Visibility of system status
As PbWiki is a hosted solution the only system status given is whether the server is running and the
website is accessible. The wiki also tells the user whether they are logged in, and in turn, the options
available to them.
Score: 2
Match between system and real world
PbWiki uses familiar terms for navigation and for basic functions of the site. There is some use of
icons that represent similar items in the real world. As PbWiki is commercial and renowned for ease
of use this is echoed throughout the use of the wiki.
Score: 4
User control and freedom
Changes to the wiki can only be made by the administrator and users are alerted to enter the wiki
password before making changes. As a tested customer orientated system there is little a user can do
to ‘break’ the system, any edits can be reverted using the page history.
Score: 4
Consistency and standards
The page layouts remain consistent throughout pbwiki, with clear distinction between what is and is
not editable. As PbWiki is closed source and there is no indication of standards compliance no
judgement can be made to the standards compliance.
Score: 3
69
Error Prevention
There appear to be no obvious errors in the PbWiki system, issues with user rights are displayed to the
user and advise given on how to solve the problem.
Score: 4
Recognition rather than recall
The standard functions for pages remain in the same place throughout the wiki, however when editing
these options disappear. There are tags that can be used for creating the wiki syntax along with the
ongoing development of a WYSIWYG editor.
Score: 3
Flexibility and efficiency of use
There aren’t any obvious shortcuts or accelerators on the PbWiki system, this is probably due to the
limited number of features and simple design. It is unlikely that on the basic free package any
accelerators could be used to speed up the system.
Score: 3
Aesthetic and minimalist design
Unfortunately due to the commercial aspect of PbWiki the site has a number of compulsory adverts
which detract from the site (these can be removed at a cost). Other than the adverts the design is
minimalist and there are four skins for users to chose from.
Score: 2
Help users recognize, diagnose, and recover form errors
Error messages are few and far between, all errors appear to be rights related which is indicated to the
user with suggestions on how to solve the issue.
Score: 4
Help and documentation
There are numerous help sections and interactive videos that help users complete tasks. The quality
fo help is very good however it can be intrusive which puts some users off.
Score: 4
MediaWiki
Visibility of system status
MediaWiki doesn’t offer any read out to the user stating execution times, server loads or any status
information. MediaWiki does however offer version and general statistics for the user.
Score: 3
Match between system and the real world
The layout and use of standard English helps the user to easily navigate pages in the wiki. Standard
functions remain constant throughout the wiki, with the use of tabs like in many real world systems.
Score: 4
70
User control and freedom
User rights and controls can be implemented to prevent users from making unwanted changes to
articles, along with this pages can be protected by system administrators. Pages have a full history
with the contributor marked, reverting back to an old version is very easy. If a user tries to edit
protected or system messages appropriate warnings are given to guide the user.
Score: 4
Consistency and standards
The layout and colour scheme of MediaWiki remains the same throughout, the page contents is easily
distinguishable form the navigation bars and system information. Having run MediaWiki through the
w3c validator it adheres to XHTML standards.
Score: 4
Error prevention
The implementation of MediaWiki appears to be well thought out with sensible error checking and
useful error messages. Sensible error messages are shown whenever there is an issue, which seem to
be few and far between.
Score: 4
Recognition rather than recall
All the standard actions available remain in the same position throughout the wiki and are sensibly
name to reduce the need for recall. The layout remains consistent throughout also aiding recognition.
Score: 4
Flexibility and efficiency of use
MediaWiki has a number of keyboard shortcuts that can be used by advanced users to accelerate their
usage. The general design lends itself to speedy and effective use. The basic syntax is also easy to
use and likely to be utilised without the need for MediaWikis editor.
Score: 5
Aesthetic and minimalist design
The general design and colour scheme is aesthetically pleasing which will increase the users
enjoyment of the system. The skin used by MediaWiki by default is minimalist, but there is an option
for users to change the skin if they wish.
Score: 4
Help users recognize, diagnose, and recover form errors
Whilst using MediaWiki very few errors have occurred, standard user rights issues have been
displayed and appropriate messages shown. When search results don’t show results appropriate
messages are displayed.
Score: 4
Help and documentation
There is a wealth of online help and documentation available to users through the official MediaWiki
site. To accompany this support there are also mailing lists and forums for users. MediaWiki lacks
some inline help for standard actions such as basic syntax formatting.
Score: 3
71
Scoring Matrix
Visibility of system status
Match between system and the real
world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose,
and recover from errors
Help and documentation
Total
TikiWiki
4
4
WikkaWiki
3
3
Pb Wiki
2
4
MediaWiki
3
4
3
4
3
4
2
3
3
2
4
1
4
3
4
3
4
3
4
3
3
2
4
4
4
4
4
5
4
4
4
34
4
31
4
33
3
39
72
Appendix F – Interface Designs
Diagram 1: Main Page Layout
Title (Main Page)
Navigation Links/Buttons
Link to Wiki
Statistics
Generate Pub Watch Survey
Import from Excel DB
Create XML
Back Button
Diagram 1 shows the main page of the additional admin section that will be added to and integrated
with MediaWiki. The admin section will enable administrators to both import into and extract data
from MediaWiki.
73
Diagram 2: Statistics Selection Page
Title (Statistics)
Drop down selection boxes for
selection criteria
Submit Query
Back Button
Diagram 2 shows the statistics query page, this page will enable the user to query the MediaWiki
database in order to retrieve management information. The selection box contents will be drawn
directly from the MediaWiki database, with queries carried out on the database in order to return
results to the user.
74
Diagram 3: Statistics Results Page
Title (Results)
List of results, with hyperlinks to wiki page
Total No. Results
Back
Main Page
Diagram 3 shows how the results to users’ queries will be displayed. Each premises returned will be
hyperlinked so that administrators can check the validity and make changes where necessary. A
counter will be used to show the total number of results for the user, this can also be used to cross
reference with the wiki and the current spreadsheet.
75
Diagram 4: Generate Pub Watch Survey
Title (Generate Pub Watch Survey)
List of criteria for the pub watch survey, with validated fields for user to input updated
numbers where necessary. Provisional numbers for fields will be taken directly from
Mediawiki database.
Generate
Back
Diagram 4 gives the general layout of the pub watch survey creation page, the page will list each of
the criteria for the pub watch survey with a form input used to take the number of premises that apply.
Validation will be used to ensure that only numbers are entered into the appropriate fields, and that no
fields are left empty.
76
Diagram 5: Import from Converted Excel Database
Title (Import from Excel DB)
Brief explanation of the process
From: (Numerical Input)
To: (Numerical Input)
Import
Back
Diagram 5 shows the layout of the import from excel database, the interface will use form inputs for
the user to select an import range (which directly correlates with the excel spreadsheet).
77
Diagram 6: Import Completed Forms
Title (Check Info and Import)
Number of Pages and reminder of range
Series of forms with MediaWiki formatted text
taken directly from the excel database. User had
to click submit to import data, page at a time.
Submit Page
Back
Main Page
Diagram 6 shows how the form input will be displayed with wiki formatted text in each input box,
which will need to be submitted one-by-one by the user.
78
MediaWiki Page Layout
Diagram 7: Original MediaWiki page layout
Page Title (Pub Name, Address)
Pub name followed by contact details (taken from the excel spreadsheet). Lots of space for
additional information to be added by users.
Categories
Diagram 7 shows the initial page layout for wiki articles, based on the information from the excel
spreadsheet. Design does not show the standard MediaWiki navigation bars, there is a great deal of
‘empty’ space for users to add information. The categories section will be automatically created by
MediaWiki when the premises is tagged as being in certain categories.
79
Diagram 8: MediaWiki page layout for second iteration
Page Title (Pub Name, Address)
Pub name and Contact Details
Image – Where
available
Where available pub ownership information
Categories
Diagram 8 shows the second iteration design of the wiki pages, this incorporates more information
from the excel spreadsheet and the ability to include pictures within the design.
80
Diagram 9: Final wiki page design
Page Title (Pub Name, Address)
Pub name and additional details
InfoBox containing
most the information
(where available) from
the excel spreadsheet.
Includes thumbnail
picture of premises
(where available)
Stub asking users to expand
Categories
Diagram 9 shows the final wiki page design, the final design uses stubs and infoboxes. The stubs are
used to alert users that additional information is needed on the premises, and invites the user to add
information. The infobox provides a ‘one stop’ fact box for each premises detailing various things
from ownership information to web addresses.
81
Appendix G – Test Plan
Test
Data Integrity
Using the ‘Random
Page’ generator access 6
premises cross reference
data with excel
spreadsheet
Use the search facility
to find 3 pubs you know
well, check the data
against the excel
spreadsheet
Using the Statistics
Reporting Page, carry
out 3 different queries
cross reference results
with excel spreadsheet
Use the Pub watch
generation page to
create statistics,
compare with latest
spreadsheet (subtotal
can be use on excel auto
filter)
Using the import script
select a range of pubs to
import, cross reference
results with spreadsheet
Additional Interfaces
Load the main page and
check the navigation
links lead to where they
should
In the statistics page
attempt to select a
second term without a
first
Create a set of results in
using the statistics page,
then navigate to the
results using the
hyperlink, then test the
links back to the query
Outcome
Passed
(Y/N)
Remedial Action
Resolved
(Y/N)
Data matched in each
case.
Y
N/A
N/A
Data matched in 2 of the
three cases, one search
did not return results
(‘New Inn’)
N
Y
Data matched in each
case
Y
Caused by MySQL
setting that only
returns results for
search terms greater
than 3 letters. Unable
to rectify without
serious performance
hit. Added warning to
search result page
with pointers to find
pages.
N/A
Data mismatched in
every case
N
Wrong spreadsheet
was been used for
comparison, correct
updated spreadsheet
solved problem
Y
Cross match successful
Y
N/A
N/A
Link to wiki incorrect,
going to older test
version
N
Changed link
Y
Validation prevents
conditions being entered
without the first being
selected
All linked correctly
Y
N/A
N/A
Y
N/A
N/A
N/A
82
and main page
Enter invalid
information into the pub
watch survey generation
page
Check the created PDF
contains all the correct
details and in the correct
format, compare
original with Pub watch
survey
Enter invalid
information into the
import range selector
Attempt to save a page
using the import method
Page Displays
Select 3 premises and
check the layout
matches the design
templates
Check for the disclaimer
at the bottom of each
page
Tailoring
Try to edit a page when
not logged in, should be
restricted
Try to edit a page once
registered, should be
restricted
Log in a WikiSysop and
change registered users
user rights to ‘camra’
group, check that
articles can be created
and edited
Using camra account try
to edit main page,
should be restricted
Login as sysop and try
to edit main page and
user rights
Accepts false
information, including
letters and numbers
N
Layout and data similar
to original
Y
Failed to verify
information
N
Edit conflict error
displays, unable to save
directly
Add JavaScript
validation to check
that entries have been
made and that they are
only numerical
N/A
Y
N/A
N
Add JavaScript
validation to check
entries are numerical
Standard MediaWiki
conflict check, page
already present not a
fail
Y
Matches
Y
N/A
N/A
Displayed on every
article
Y
N/A
N/A
Unable to edit
Y
N/A
N/A
Unable to edit
Y
N/A
N/A
Able to edit and create
pages
Y
N/A
N/A
Unable to edit
Y
N/A
N/A
Works
Y
N/A
N/A
83
Appendix H – User Feedback
User: A – CAMRA Member (Dave Ansley)
1. How well does it meet the general needs of Leeds CAMRA for storing
and displaying information on premises?
All the required information seems to be there and is reasonably
presented in a concise manner and thus seems to fulfil the general
needs.
2. Is the system easy to use and intuitive?
For someone like myself who is not used to using a Wiki it took some
time to get the hang of it, but once I had done so it was reasonably
easy to navigate around.
3. Do you think non-technical members would use the system?
I think that non-technical members would probably struggle with using
this, but that is more to do with the fact that the concept of a
Wiki would be strange to them, rather than this specific one.
4. Can you suggest any improvements?
I think it would be useful to indicate on the main page that users
should use the search facility to find a specific pub or pubs in area
etc, maybe with a list of things you can search on e.g. Pub Name,
Location, Postcode, Urban/Rural.
Another useful addition on the front page, if possible, would be a drop
down list of Districts to select from.
5. Do you think the system would be used by Leeds CAMRA in conjunction
with, or instead of, the existing spreadsheet?
I would expect to use it in conjunction with the spreadsheet taking
the information gained from the Wiki and updating the spreadsheet as a
backup.
84
User: B – Novice Computer User (Anthony Bentley)
1. How well does it meet the general needs of Leeds CAMRA for storing
and displaying information on premises?
The information displayed on the wiki pages doesn’t seem to go into much depth, but
seems to resemble the spreadsheet. Adding to the pages seems to be easy when logged in,
I was unable to edit the pages without logging in…? I found some pages with images
which improved the look of the pages.
2. Is the system easy to use and intuitive?
I found the ‘statistics’ page a bit confusing and I didn’t want to use the import facility just
in case I overwrote something. The general website was fairly easy to use, but I have
used Wikipedia before which helps. The searches didn’t return results sometimes.
3. Do you think non-technical members would use the system?
I found it quite easy to use and I don’t consider myself to be an IT expert. Navigation and
editing is relatively simple some people might struggle with adding bold, italic, links etc
of they haven’t used Wikipedia before.
4. Can you suggest any improvements?
It needs more information, and some of the pages in the navigation bar don’t have any
information in them. I have seen other wikis with all sort of fancy things like google
maps and youtube – maybe that is an option? Make the admin section more aesthetically
pleasing.
85
User: C – Technical User with HCI Background (Andrew Phillips)
1. How well does it meet the general needs of Leeds CAMRA for storing
and displaying information on premises?
- Information presented well within the wiki
- Good use of info boxes to display standard information
- Administrators area is quite simple
- Non- technical users might not understand the admin area
- Comparing with the spreadsheet the information seems consistent
2. Is the system easy to use and intuitive?
- Anyone who has used Wikipedia will find it very easy
- Some novices might find it difficult to grasp the syntax
- Navigation buttons all make sense, nothing misleading
- Could do with the help page having information for novices
3. Do you think non-technical members would use the system?
- Depends how non-technical they are, my grand parents probably wouldn’t use it!
- Anyone who knows how to use a computer should be able to navigate and search for
pubs
- Editing and creating pages might not be as easy, might benefit from a WYSIWYG
editor
- The admin section could probably be learnt by a non technical user quite quickly
4. Can you suggest any improvements?
Experience with Wikipedia shows that just about anything is possible
- Dynamic homepage?
- Google Maps?
- RSS Feeds?
- WYSIWYG Editor?
- Better search facility, it seems to miss things?
86