|
This is the original M.Sc. Dissertation project concerning the UK League Snooker Community, it was completed in 4 months at the start of 2003, receiving the prize for 'The Best M.Sc Computing Dissertation 2003' from Staffordshire University. Since then the website has been expanded extensively with new functionality and refined to suit the needs of UK Snooker Leagues 1.6.2 Determining the User Requirements - Interviews,
questionnaires and observing.
10
2.1.1 Online Community Theory.
14
2.1.2.2 User and Task Analysis
16
2.1.2.4 Usability Evaluation.
17
2.1.3.4 Sociability and Usability.
19
2.1.4.1 Software Life Cycle.
20
2.1.4.4 Social Impact of Software Design.
22
2.2 Research Methodology -
Community-Centred Development.
23
2.2.3 Participatory design.
25
2.2.4 Assessing community needs and analysing user
tasks
26
2.2.5 Selecting technology and planning sociability.
26
2.2.6 Designing, implementing, and testing prototypes
26
2.2.7 Refining and tuning sociability and usability.
26
2.2.8 Welcoming and nurturing the community.
27
3 ASSESSING COMMUNITY NEEDS AND ANALYSING USER TASKS.
28
3.1 Requirements gathering.
28
3.2 Survey design and
distribution.
29
3.3 Analysis of the survey
results.
31
3.3.1 Demographics – Age, gender, location, years of
league snooker experience.
32
3.3.2 Current league information sources and
availability.
36
3.3.3 Internet – access, location, frequency, browser,
PC or MAC.
38
3.3.5 Willingness to participate in developing the
community.
44
3.3.6 Community features suggestions
45
3.3.7 Willingness to participate in the community once
it is developed.
47
3.4.1 League Administrators
49
4 SELECTING TECHNOLOGY AND PLANNING SOCIABILITY.
53
4.1.2.2 ASP (Active Server Pages)
56
4.1.2.3 PHP (Personal Home Page)
56
4.1.2.4 Perl (Practical Extraction and Report
Language)
56
4.1.2.6 Language comparison.
57
4.1.2.7 Database Management System (DBMS)
58
5 DESIGNING, IMPLEMENTING AND TESTING PROTOTYPES.
62
5.1 Entity Relationship
Modelling (See Figure 27)
62
5.2.2 League Administration Area (See Figures 28 and
29)
65
5.2.3 League Participants Area (See Figure 30)
65
5.2.4 Community Administration Area (See Figure 31)
66
5.3 Programming the
Interface.
71
5.4.1 Existing problems with the site design.
73
5.5 League Participants
view..
74
5.6 League Administrators
view..
74
5.7 Community
Administration view..
74
5.8.2 Usability Testing – Ethics
74
5.8.3 Usability Testing – Format
74
5.8.4 Usability Testing – Results
74
6 conclusions and further research.
74
6.1 Research Methodology –
Community-centred development.
74
6.4 Online Community Theory.
74
6.5 Further
Research/Activities.
74
6.5.1 League Committees and Administrators
74
6.5.2 Adaptation of the community.
74
FIGURES
Figure
2 - The three domains of Online Communities.
14
Figure
4 - Community-centred development.
25
Figure
5 - Questionnaire Source.
31
Figure
6 - Age of UK Snooker League Participants.
33
Figure
7 - The locations of the UK Snooker league survey respondents.
35
Figure
8 - League participation length.
36
Figure
9 - League information source.
37
Figure
10 - League information availability.
37
Figure
11 - League participants Internet access.
38
Figure
12 - Internet access location.
39
Figure
13 - How frequently participants access the Internet.
39
Figure
14 - Internet usage - Longevity.
40
Figure
15 – Computing skill – Paper survey results only.
41
Figure
16 - Internet access - Paper survey results only.
41
Figure
17 - League participant’s computer skills.
42
Figure
18 - Computing skill by age.
42
Figure
19 - Previous participation in an online community.
43
Figure
20 - Possesses an Email account.
44
Figure
21 - Willing to help test and refine the website.
45
Figure
22 - Website features suggestions.
46
Figure
23 - Preferred method of online community communication.
46
Figure
24 - Participants who would be willing to access league information via a
website
47
Figure
25 - How frequently would the participants access the website.
48
Figure
26 - Willing to participate in an online discussion Forum.
49
Figure
27 - The community Entity Relationship Model and Attributes.
64
Figure
28 – League Administrators pages (Part 1)
67
Figure
29 - League Administrators pages (Part 2)
68
Figure
30 – League Participants pages.
69
Figure
31 – Community Administrators pages.
70
Figure
32 – Prototype Template.
74
Figure
34 - League in Staffordshire.
74
Figure
35 - The Stafford and District Snooker League Home Page.
74
Figure
36 - The Stafford and District Snooker League - Division 3 Table.
74
Figure
37 - Player Statistics.
74
Figure
38 - Discussion Forum Topics.
74
Figure
40 - League Administration Home Page.
74
Figure
41 - Add a League Fixture.
74
Figure
43 – Delete a person.
74
Figure
45 – Community Administration.
74
TABLES
Table 1
- The leagues that the survey
respondents have played in………………………… 33 Table 2 - Semi quantitative comparison of features of four programming
environments…. 57 APPENDICES
APPENDIX
A Online Survey I APPENDIX
B Sample
of Paper Surveys – League participants II APPENDIX
C Paper Surveys – League administrators III APPENDIX
D Usability Tasks V APPENDIX
E Sample of the application code VI APPENDIX
F Database queries VII ABSTRACT
There are up to one thousand
snooker leagues that exist in the We
have worked for the last 2 years and still work on a website which acts as an
online portal for IT Companies throughout the world (http://www.tsanet.org),
during this time an understanding of the workings of an online community was
gained. We also have an interest in UK
snooker leagues and from playing in various UK snooker leagues for the past
twelve years we have identified a common problem, this being that there is a
distinct lack of information available to what is happening within the leagues
i.e. results, news, league tables, fixtures, etc. Snooker
leagues are widespread throughout the UK, how many we can only guess, there is
no single directory, according to the BBC website the county of Lancashire
possesses twenty eight snooker leagues alone, the population of Lancashire is
approximately one and a half million (3% of the population of the UK),
therefore an estimation can be made that there are up to one thousand snooker
leagues in the UK. Generally a league
consists of between one and seven divisions of snooker teams that are based on
a specific geographical area. There are
usually eight to twelve teams in each division, who play each other home and
away in a season, often during the winter months. The teams are based at a club, usually a
workingmen’s or social club, although actual snooker clubs participate within
the leagues. Each team generally
consists of between five and six players, who play a single frame of snooker
against an opponent during a match on a weekly basis. Alongside the league matches there are many knockout
competitions throughout a season, which involve teams, individuals, doubles and
even triple players. Many players take
part in the leagues as it gives them a chance to enjoy competing and
socialising on a regular basis. We
estimate that there are between one hundred thousand and one hundred and fifty
thousand players participating in UK snooker leagues each year. The
information availability varies greatly, the most typical source of information
is available from a local newspaper that is often published on a weekly basis,
but the detail of information is generally very poor. At the one extreme there is the West Midlands
snooker league which has an excellent website that is updated on a weekly basis
http://www.cued-up.co.uk. The site provides a wealth of information, as
detailed as individual player scores per match, although the majority of sites
are very poorly designed and not very usable.
While at the other end of the scale is the Stirchley and District Snooker
league also based in the West Midlands, who’s league information is made
available only once a month when the league committee convenes, thus league
participants have a very vague idea on what is happening within their league in
terms of league details, competitions and much more. Based on this knowledge, a good method of
addressing this problem would be to create an online community that can provide
information for any snooker league in the UK. “Although
definitions of an online community vary, a general definition of an online
community is a group of people who share a similar interest, share networked
resources, and communicate using a computer-mediated communication tool” (Lazar
and Preece, 2000, p.20). In the case of
the proposed online community there is certainly a common interest, but the
primary issue that needs to be addressed is the fact that at present the many
UK snooker leagues are greatly isolated, it will be relatively straight-forward
to develop an application to provide up to date information for the
participants, but it will be a far greater challenge to investigate the process
of developing and implementing a successful online community for UK snooker
leagues. The creation of a successful
online community in terms of uniting the isolated league participants in some
form may not be possible. Thus the
designing and building of online communities will be researched to establish
whether this is feasible. The
areas of research that are essential for building an online community are focused
on designing usability and supporting sociability. “In creating web-based resources, the focus
still needs to be on user-centred design” (Lazar and Preece, 2000, p.20). The methods employed for gathering user
requirements needs to be considered carefully, especially since the population
of the league participants are geographically dispersed throughout the UK. Traditional techniques of observation,
interviews and focus groups will not be possible on a national basis, so a
portion of the research will focus on establishing the most appropriate methods
of gathering user requirements. The
planning of sociability within an online community is not trivial, from the
research undertaken so far it seems that the greater the number of participants
the more successful the community becomes.
To plan sociability policies for: Membership, Codes of Conduct,
Security, Privacy, Copyright, and Free Speech, Moderators will need to be
considered and much more. From
the research carried out so far on online communities, Jenny Preece, Professor
of Information Systems at the University of Maryland and Jonathan Lazar
Assistant Professor in the Department of Computer and Information Sciences at
Towson University are the key authors in the chosen area of study. They have written many journal articles on
online communities and on occasions worked together on the same project, for
example, they both helped to research and develop an online community for
parents whose children have Down Syndrome.
Two papers in particular will be a very useful resource for our
research; they deal with the problem of gathering user requirements over a wide
geographical area. Jenny Preece has also
written a comprehensive book on Online Communities – Designing Usability, Supporting Sociability that is an excellent resource for this research
project. The
primary text we will use when considering the usability aspects of designing
the online community will be that of Jakob Nielsen’s, his 1993 book on Usability Engineering is a well-respected source on the principles of usability. The
aim of the project is to solve the problem of the lack of information available
to snooker league participants throughout the The
purpose of the study is: -
To research past and current work in the
area. -
To assess community needs and analyse
user tasks -
To select technology and plan sociability -
To design, implement, and test prototypes -
To refine and tune sociability and
usability -
To critically analyse the overall project -
To put forward the future of the online
community -
To adhere to ethical codes of conduct. Earnshaw
et al (2001) compiled a report on the related areas of human centred
interaction, online communities, and virtual environments. A key finding was that “directions for
research and development are needed that address usability and sociability
problems so that better online communities can be developed. There is a particular strong need to involve
social scientists as well as computer scientists. Successful online communities will result
from a blend of good usability and carefully guided social policies that
encourage social interaction. Theory and
better research methods are also needed to support Internet research and system
development” (Earnshaw et al., 2001, p.264).
This report, that involved leading authorities in the area, identified
the directions of key future research, the aim is to add to this ongoing
research by creating a highly usable and sociable online community that other
researchers can review and hopefully gain knowledge and understanding from the
work produced. The
nature of the problem suggests that a qualitative research method be taken to
address the issues of researching and developing an online community. The community will ultimately provide a
service for people; so the aim is to attempt to look through the eyes of the
people that will potentially use the community in order “to construe the
attitudes, beliefs and motivations within a subject” (Walliman, 2001, p.
203). The qualitative method demands
that the research “obtain an inside view of phenomenon, getting as close as
possible to the subject of the research in order to collect resonant, fertile
data to enable the development of a social construct through the dynamic
process of research” (Walliman, 2001, p. 203).
The quantitative method of research is quite the opposite, in that the
researcher chooses to remain distant from the users in order to collect hard,
reliable data. This method of research
is thus not suitable to what we aim to achieve, the key to building a
successful online community demands that we work closely with the users, in
order to establish their requirements. The
research methods that will be used during the project are: evaluation and
action research. (try putting “evaluation” and “action” in bold??) The evaluation
method is suitable because the method is “specifically designed to deal with
complex social issues” (Walliman, 2001, p. 94), thus suits the context of the
creating an online community. The action
research method can be utilised when conducting observation and behavioural
research, as in the case of observing a user using the prototype to gain
feedback on the applications usability
User requirements can be gathered locally in Figure
1
– Project Plan
-
A review of work in the subject area.
(put full stops after each of these deliverables) -
A theoretical background of Online
Communities. -
An assessment of community needs and
analysis of user tasks. -
Software selection and sociability plan. -
A generic database driven website
developed to suit the requirements of the diverse communities. -
A critical analysis of the project. -
A discussion of the ethical issues
involved in this dissertation. -
Dissertation document. There is no
single directory of
Special
consideration needs to be considered for users when usability studies are
conducted, the deepest respect for the users well-being and emotions will be
the most important factor during a usability test. The
information that is obtained from the The
research problem has been identified, and how to address the problem
proposed. The intellectual challenge can
be met through a structured research programme, by adhering to ethical codes of
conduct and by following the project plan.
Each project objective is met by a deliverable. The next chapter looks at the theory behind
online community development. Online
community theory needs to be addressed before a community is developed. Literature needs to be reviewed to identify
the key domains of designing an online community, and a research methodology to
provide online community development guidelines are identified in the following
chapter. The
literature review will critically evaluate the past and current work on the
researching and developing of online communities. The aim is to outline research possibilities
that have either been explicitly identified by authors or have possibly been overlooked
in the past, and also to identify research methods and strategies that may be
usefully applied to the research project.
The
project can be considered from the perspective of three domains – Usability,
Sociability, and Software Development (see figure 2). From the research done, these three domains
are the key areas that need to be considered when developing an online
community. We will look at the important
work that has been carried out in each separate domain, the work of the main
authors, models, the major theories, and examples of where the particular
domain fits into existing online communities.
The aim is to add value to the above by making a personal response to
past and current work by establishing our own view and position on the subject. Figure
2
- The three domains of Online
Communities
Each
domain will be critically evaluated; the intersection between each domain will
be identified with the conclusion summing up the intersection between all three
domains. Jenny
Preece, arguably the most well respected author on the subject of online
communities argues: “Many candidate
theories exist that are partially relevant to online communities. High-level theories are needed that are
directly relevant to online communities.
The value of such theories is to: §
Understand communication in different types of communities. §
Make predictions. §
Inform online community design. Current theories fall into the following three categories: §
One-to-one or small
group communication via different media. §
Social interaction and
community networks. §
Relationship between
software design and social behaviour”. (Preece, J
Chapter 17, Frontiers of human-centred computing, online communities and
virtual environments. 2001, p.270). Peter
Kollock, joint author to the book ‘Communities in cyberspace’ offers his
opinion on building online communities.
“There is no algorithm for community. That is, there is no step-by-step
recipe that can be followed that will guarantee a specific outcome. Building
community is a fundamentally different activity than writing computer code:
code does not write back and code does not respond strategically to one’s
actions” Kollock (1996), (
http://www.sscnet.ucla.edu/soc/faculty/kollock/papers/design.htm,
Last Accessed 14/01/03). Online communities are a relatively new phenomenon;
therefore theory is still in its infancy. Preece highlights the key areas that
are needed to understand sociability and inform online community
development. She believes the key areas
to create online community theory are: sociology, psychology, social
psychology, linguistics, communication research and psychotherapy. From our research Professor Jenny Preece’s
opinion is highly regarded, she is an established academic in the field of
Human Computer Interaction and has researched online communities extensively,
the aim is to utilise her work comprehensively during the project. Good
usability is a fundamental aspect of online communities, poorly designed
software can cause hours of endless frustration for users, often due to
developers making assumptions about how the interface they design will be
interpreted. Preece gives a good
definition of usability and why it is important. “Software with good usability supports rapid
learning, high skill retention, low error rates, and high productivity. It is consistent, controllable, and predictable,
making it pleasant and effective to use” (Preece, 2000 p.133). Good usability comes part and parcel of
designing online communities, especially because many of the users may be
novices, poor usability could stop a community from getting off the
ground. The
keyword that Preece uses is ‘Consistent’. Jakob Nielsen often described, as a
‘Usability Guru’ believes that consistency is one of the most basic usability principles.
He uses a quote by Lewis to emphasise his viewpoint. “If users know that the same command or the
same action will always have the same effect, they will feel more confident in
using the system, and they will be encouraged to try out exploratory learning
strategies because they will already have part of the knowledge needed to
operate new parts of the system” (Nielsen 1993, p.132). Our own research will focus strongly at
looking at examples of online communities and assessing how consistently they
are designed, and then using the better examples to influence the design of a
prototype application.
Hackos
and Reddish (1998, p. 7) claim that “designers who spend time with users,
observing how they work, understanding who they are, testing design concepts
and prototypes, are most likely to be successful in creating interfaces that
are a delight to use”. Although the aim is to design specific questionnaires
for the Nielsen’s
advice on usability engineering is renowned as being excellent, he illustrates
his ideas clearly and explicitly, and emphasises the importance of taking into
account a users actions and opinions early on in the usability lifecycle. He points out that “Individual user
characteristics and variability in tasks are the two factors with the largest
impact on Usability” (Nielsen, 1993 p.73).
We are firm believers in the importance of user participation when
designing a system. We have designed and conducted five usability tests in the
past two years following the methodology set out by Nielsen in his book Usability Engineering, in which users were given a number of tasks to complete and
then timed and observed whilst they performed the system tasks. This methodology proved to be an excellent
way of improving the usability of all the systems that we had helped to
develop. Usability
testing as detailed above consists of using metrics to test a system’s
performance, thus some of the information gathered tends to be
quantitative. “However, in order to
evaluate a system thoroughly it is necessary to gain qualitative information as
well” Faulkner (2000) p.137. Hewitt in
1986 produced a good paper that states that evaluation is iterative and should
therefore be conducted at the end of each design stage. He details two types of evaluation – Formative
and Summative. Formative and Summative
evaluations are an integral part of the design process. Formative evaluation is mainly concerned with
getting the opinions of the users, whilst Summative evaluation is more to do
with collecting quantitative data, its purpose is to assess “the impact,
usability and effectiveness of the system – the overall performance” (Faulkner,
2000 p.138). These two types of
evaluation have very different goals, and will be used at different stages of
the design process. The
purpose of an online community, its members, and policies all influence how
individuals interact and determine the character of the community. Jenny Preece introduces three components of
sociability – purpose, people, and policy.
The purpose of a community is what draws people to the community, people
are the pulse of a community, and policies are required to direct behaviour within
online communities. Based on these three
components, Preece gives detailed explanations of the importance of sociability;
the key issues for supporting sociability within an online community are
discussed below. The
purpose of the proposed community is to unite the greatly isolated UK snooker
leagues through an online community.
What will draw people to the community will be a common interest in the
sport snooker. The aim is not only to
provide members with information from their own particular leagues, but also to
encourage sociability on a national scale. Sociability
in online communities is achieved by looking primarily at the requirements of
people, and in the case of our research, migrating up to a thousand already
existing geographically dispersed physical communities into a single online
community. We need to discover how to
map the requirements of the people who participate in UK snooker leagues to a
computer-mediated communication tool – a Website. Jonathan Lazar and Jenny Preece, together,
have written two excellent papers in which they attempted to do the above. In the paper ‘Collecting User Requirements In
A Virtual Population’, they mention that there is an increasing number of
online communities that focus on special interest topics such as sport, “where
web-based resources are being developed for a focus population, but there is no
physical component to the population of the users” Lazar et al. (2000). The paper goes on to mention that the typical
methods of gathering user requirements cannot be adopted in such cases,
traditional techniques of observation, interviews and focus groups will not be
possible on a national basis, so a portion of our research will concentrate on
establishing the most appropriate methods of gathering user requirements. We
possess an inside knowledge of two UK snooker leagues because we have
participated in the two leagues for over twelve years, thus this gives a good
insight into the user requirements of the league participants. True sociability and proficient usability in
the proposed online community cannot be established until the many participants
are contacted to discover whether they would get any value from an online community,
if this is so, and we believe it probably is the case, the work of the authors
mentioned in this report can be utilised to create a usable, sociable online
community by designing software specific to the community member needs. Based
on the major author’s advice, (Jenny Preece), the aim is to devise several
policies. These may include: membership to those that are members of UK snooker
leagues only, a privacy policy to comply with the UK Data Protection Act of 1998,
and moderators to ensure that problems such as flaming do not occur. There will certainly be other policies
required, but more research is currently required. Preece points out
in the paper below, the intersection between usability and sociability, and how
important it is to understand the nature of the particular community that you
aim to create. “The relationships and
synergy between people, practices, and technology to achieve a goal is often
approached using combinations of research paradigms. The intersection of usability and social
structures - leads to fundamental questions about the nature of communities and
communication and applied questions derived from the 'build and test' paradigm
of engineering. For instance, the behaviour and needs of people in scholarly
discussion groups are different from patient support groups. Consequently,
understanding the focus and culture of each kind of community is important”
(Preece, J. 2000. Shaping Communities: Empathy, hostility, lurking, participation.
DIAC2000 Seattle). Amy Jo Kim backs up
Preece by stating that “to create a successful online community, you’ll need to
first understand why you’re building it and who you’re building it for” Kim
(2000). Sociability will be extremely
important if the community is to succeed. Sociability
and usability are closely related to each other, and can impact one another,
“for example, deciding whether to have a registration policy and what its
content should be is a sociability concern; determining how to present the
policy (deciding which font type and size and interaction style to use) are
usability concerns” (Preece 2000, p.269). Software
development needs to be carefully planned to create a successful online
community, it is crucial that when an online community is being researched and
developed that the users are at the heart of the project. Software implementation must be based wholly
on what the future members of an online community require. If this is not the case, and users begin to
use an online community and find it unusable or it does not satisfy their
needs, they will just stop using that community. Thousands of communities have
just disappeared due to their poor software design. Alan
Dix and others in their book ‘Human Computer Interaction’ give a detailed
explanation of the relationship between usability and software
development. They explain that modern
computer applications are highly interactive, in that, systems are no longer
solely designed for batch processing, but the advent of personal computers has
brought much more interaction between people and computers. They challenge the traditional software life
cycle by arguing that usability is a crucial aspect of the life cycle;
usability should not be segmented into a separate segment in the life cycle but
should be continually considered throughout the development process. The traditional life cycle is “in a somewhat
pipeline order. In reality, even for
batch processing systems, the actual design process is iterative” (Dix et al, 1993 p.157). Prototyping
is a very important part of the software development process and therefore we intend
to use this method extensively during the project in order to better understand
the requirements for the next stage of the software development process. The ‘W’ model put forward by John Harrison at
the Department of Trade and Industry (DTI) in 1992 (see figure 3) possesses a
number of features that can be utilised during the prototyping stage of the
project. Jenny Preece sums up the
advantages of the model, and where she uses the word ‘expensive’, we are
considering ‘time consumption’. “In this
model a single ‘design in miniature’ is undertaken and tested. Following this, the requirements are fixed
and a traditional approach to development is undertaken. The advantage of this model is that it is
less expensive than the spiral approach, as just one iteration is
undertaken. It also helps with project
control and in identifying accurately user requirements” (Preece et al, 1994,
p.359). Figure
3
- The W model of system development
(from a talk by John Harrison at the Department of Trade and Industry (DTI),
UK, 22 June 1992).
Source:
(Preece et al, 1994, p.359) There
are several software options that can be considered for the online
community. Software can be purchased,
downloaded for free, or developed in-house.
This is a list of the typical types of software used to enhance online
communities in terms of asynchronous and synchronous forms of communication
adapted from Preece (2000). Synchronous
means that community members would be communicating in real time, whilst
asynchronous communication does not have to be real time. Synchronous
Asynchronous Instant
Messaging Bulletin
Board Chat
Rooms Email Mutli
User Dungeons (MUD) List
Servs MOO’s
(Object Orientated MUD’s) Use
Net News Websites
Websites The
nature of a UK snooker league online community determines that the most
suitable software options are probably to use a bulletin board, email, and
website. Research will need to be
conducted to establish whether the above asynchronous forms of communication
are the most suitable for the community, but going off the opinions of the
authors Kim and Preece it seems likely that the above software options will be
a sound choice. Amy Jo Kim sums up the
reason why a bulletin board would be suitable.
“A message board can unite geographically distant people and enhance
their sense of belonging” (Kim, 2000, p.34). The
options available for developing a bulletin board need to be considered. Kim points out that online community builders
can download the software and configure it for themselves. “You can sign up for free, easy-to-use
services such as Delphi Forums (http://
www.delphi.com), eCircles (http://www.ecircles.com)
or Yahoo Clubs (clubs.yahoo.com)” (Kim, 2000, p.37). She points out that with free bulletin boards
your members would be required to register with the service thus your database
would be not be your own and that advertising comes part and parcel with free
services. Bulletin Boards can also be
purchased or built in-house; these options are good if you would like to have
more control over your interface and member database. Preece mentions that moderators can configure
a bulletin board to suit member needs, read messages before they are published,
and ban users in the case of abusive activity (Flaming). Preece
in her book ‘Online Communities: Designing Usability, Supporting
Sociability’ clarifies the social impact of software on online
communities. It may seem obvious that
the software that a developer designs influences how it is used. Less obvious
is that the impact of certain software design features online communities may
be far greater than recognised. For
example, a member of a community may wish to have a private conversation with
another member, if this is not possible, then the software design has had a
profound effect on its participants and how they communicate and interact with
each other. The
successful design and implementation of an online community demands that the
domains of usability, sociability, and software development are considered not
as single entities but as a whole.
Software design occurs alongside the usability and sociability aspects
of the iterative design process and vice versa.
One domain cannot be created without first consulting the other two
domains. Future
research is certainly essential because “physical communities will become
increasingly networked. Synergy between physical and virtual activities will
increase and the seams between being online and in the physical world will
become less obvious as many activities involve both” (http://www.eimc.brad.ac.uk/news/8_2.htm,
Last Accessed 14/01/03). Community-centred
development is the methodology chosen for the design of the UK league snooker community.
The reason the methodology was chosen was mainly due to Preece putting forward
this method for designing a successful online community. Preece is the leading
author in the field of online communities and so her opinions are, for obvious
reasons, highly regarded. She points out
that, “no clear formula for developing successful online communities has been
defined, but the community-centred development process paves a path to follow”
(Preece 2000, p.268). “Community-centred
development must focus on the community’s needs prior to making decisions about
the technology and social planning.
There are two main parts to the process: software design or selection and tailoring, and sociability
planning” (Preece, 2000, p.208). Both usability and sociability are important
to the success of the community, and become more and more closely linked as
development proceeds iteratively. Also
vital is the involvement of future users to test and refine the software built
for the online community. Preece
points out that community-centred development “borrows ideas from user-centred
design, contextual inquiry, and participatory design” (Preece 2000,
p.208). User-centred design concentrates
on the user rather than on software development, “contextual enquiry
emphasises the importance of understanding the user context” (Preece 2000,
p.209) and participatory design heavily involves future community
participants in the design process. Hix
and Hartson highlight the importance of the methodology, “user-centred design
has emerged as one of the most compelling mandates for developing user
interaction. It is closely related to
the notion of behavioural design, producing the interaction from the view of
the user, rather than the view of the system” (Hix and Hartson, 1993,
p.29). The authors go on to say that
what the user wants from a system is very difficult to achieve from a designers
perspective, this can be due to several reasons, for example a designer not
possessing sufficient programming skills to implement the users’ requirements,
and reasons such as these often lead to poorly designed systems. What user-centred design does is promote the
importance of producing a system that is clear and simple to use, this may take
twice as much time and effort to implement but it will produce a system that
will be much more efficient and productive for the future users. Observing
and analysing the league administrators’ tasks is an essential part of the
online community development strategy.
“The core premise of Contextual Inquiry is very simple: go where the
customer works, observe the customer as he or she works, and talk to the
customer about the work. Do that, and
you can’t help but gain a better understanding of your customer” (Holtzblatt
1999, p.41). In order to improve the way
that league administrators complete their tasks, it is crucial to observe them
in their work context, so that their tasks can be mapped into the software
application that will be developed. Once
the tasks are mapped, we can contemplate how to improve the way that league
administrators go about their tasks, ultimately aiming to reduce their workloads
significantly. Once this is achieved it
will hopefully encourage the administrators to utilise the league snooker
community as tool to go about their work. Participatory
design is a relatively new approach to software systems design, “in which
people destined to use the system play a critical role in designing it. It rejects the assumption that the goal of
computerisation is to automate the skills of human workers, instead seeing it
as an attempt to give workers better tools for doing their jobs” (Schuler and
Namioka, 1993, preface, xi). This is one
of the key aims of the project, the vast majority of league secretaries in UK
snooker leagues are most likely to be using such tools as spreadsheets and
notebooks to record and manipulate league data.
By involving administrators in the design process it can be established
whether a website can improve their current methods of recording and
manipulating data. Participatory design
has a proven track record in a variety of online community developments; hence
it would be beneficial to use the methodology during the design of the online
community. Preece
stresses the importance of community-centred development being an iterative
process of development and-test cycles.
Within the process are the five stages illustrated below in figure 4. Figure
4
- Community-centred development
Adapted
from Hix and Hartson, 1993 The
first stage of the community-centred development process involves understanding
the needs of the community. This will be achieved through a national survey of
UK league participants and administrators and by the actual observation of the
league administrators going about their tasks.
Through these measures, the community’s purpose can be defined, along
with who will make up the community itself.
This is very similar to requirements analysis, but it concentrates on
the community’s needs. (Preece, 2000) The
second stage involves mapping the community’s needs to generic technologies, as
in the case of say a discussion Forum that can be downloaded and installed on
the community’s server, new software can also be designed or a combination of
the two. “Sociability planning is done
in parallel, and policies and social structures are planned” (Preece, 2000,
p.210). In the
third stage the community’s needs are integrated “with the features of possible
software and the overall conceptual design is determined” (Preece, 2000,
p.210). Software is designed rapidly and
then tested with users to see if it is usable in small iterations of build and test. This helps to verify the community’s purpose
to the developer(s), discover different design ideas, and to test their design
by involving users in the design process. The
fourth stage is a refinement of the third stage, an attempt to iron out any
final problems before the community is released by formally conducting
usability tests and sociability tests. The
final stage involves publicising the community to encourage membership, and
later on offering support to the new members of the community. Help systems will need to be put in place to
deal with misunderstandings and software problems, along with the ability for
users to offer feature suggestions to the community developer(s). Database backups are going to be crucial to
the community. If hours and hours of data entries are lost, the community
itself may be lost. “Nurturing is
important not only early on in the community’s life, but throughout its
existence. Again, communities are dynamic,
and change as people join and leave, so ongoing support is necessary” (Preece,
2000, p.211). “Community-centred
development, as the name implies, focuses on the community rather than the
technology. Developing online
communities involves a blend of technical and social development” (Preece,
2000, p.229). It is crucial that the
future members of the community get involved in the development process.
Technical developers alone cannot design software to accommodate the needs of
an online community that they may know little or nothing about. The only way
the online community can be designed successfully is by testing and reviewing
the new community site with future members.
The next section assesses the needs of the community and analyses user
tasks.
It is essential to discover how to map
the requirements of the people who participate in UK snooker leagues to a
computer-mediated communication tool – a website. The research aims to migrate
up to a thousand already existing geographically dispersed physical communities
into a single online community. The
first task a developer must do is to find out who the users will be and what
they expect. Lazar and Preece (1999 and
2000) wrote two very useful papers on assessing community needs over a wide
geographical area, therefore their work was utilised for guidance. In 1999, Jonathan Lazar et al wrote a
paper on analysis and design issues in a hybrid virtual and physical community,
they point out that methods of gathering requirements and understanding user
needs have been established for many years, but new research is needed to
gather the requirements of users from an inaccessible population that is a
virtual community. So the researchers
set out to gather user requirements of such a community called the Quiz Bowl Community
in the USA. They highlight that there are three
traditional approaches for gathering user requirements “(1) ethnography (2)
interviewing users and (3) surveys” (Lazar et al. 1999, p.50). They believe that ethnography is not a suitable
method for gathering requirements for an online community because the method is
more suited towards researching ground breaking area’s where researchers become
“immersed in the community in order to experience it” (Lazar et al. 1999,
p.50). This could only be achieved to a
certain extent within UK snooker leagues; researchers would not have enough
time to take part in hundreds of separate snooker leagues throughout the
country. Although our twelve years
participation in two separate leagues gives a good insight into what league
participants would like to gain from an online community. “Interviews can gain large amounts of
data, however, users must be easily accessible and very cooperative” (cited in
Lazar et al. 1999, p.50). There are
several types of interview situations: structured, semi-structured, and
unstructured. Each type can be utilised
for different scenarios, depending on the situation. When Tony Keeling, a retired Stafford snooker
league administrator and Neville Ward the current administrator were
interviewed, the interview was semi-structured in that there were a “mixture of
questions with predefined answers as well as those where the respondent is free
to say whatever is liked” (Hague 1993, p.21).
This method was chosen because very specific information from the two
administrators needed to be obtained, for example how many years had they been
a league administrator and also to find out their opinions on the value of an
online community for UK snooker leagues. A. N. Oppenheim wrote a book in 1992 on
questionnaire design, the book is highly respected and provides useful
information for designing and analysing questionnaires. He explains that there needs to be logic
behind the strategy of the research so that valid conclusions can be drawn from
the questionnaire results. “Good
research design should above all make it possible for us to draw valid
inferences from our data in terms of generalisation, association and causality”
(Oppenheim, 1992, p.6). Hague backs this up by suggesting that the researcher
apply a relevance test to each question.
“Is the information nice to have or necessary to have? What will be done with the information when
it has been collected? If the question
fails on either of the these two counts, it is questionable that it should be
asked” (Hague 1993, p.37). Therefore
careful consideration was given to the questions that were asked in the
survey. Surveys according to Lazar et al are the
best method of gathering user requirements in a virtual population for an
online community. They are very good at gathering lots of information that can
be analysed in a short space of time, they can also be distributed online,
which will save on costs. A survey was
designed based on Oppenheim’s advice; our twelve years of inside knowledge of
UK snooker leagues and Lazar et al’s advice from the two papers. Particularly useful were the sample questions
listed in one of the papers that were used when they surveyed users of the Quiz
Bowl community. The survey targeted UK
snooker league participants and administrators, each group were given a
separate questionnaire, the league participants were questioned about
demographics, people’s needs in terms of information and communication, their
computing and Internet experience, willingness to participate in the online community,
and what features they would like to see in an online community (See Appendix
A). Whilst administrators were
questioned about all the above they were also questioned about their methods of
administrating their league’s information, and their skills/willingness to
input data into a website so that participants within their leagues could
access detailed information online (See Appendix C). The questionnaires that
were designed also offered users the opportunity to get involved in the
development process, by asking them if they were willing to test and refine the
new system. The
survey results were then collected through a number of mediums. Analysis of the results shows that an
online community for UK snooker league participants would be greatly valued
because it would combat the problem of the lack of information available to
league participants and also connect the isolated UK snooker leagues via a
Forum that could possibly lead to the organisation of inter-league
tournaments. Between the paper surveys
and the online surveys, a total of 49 survey responses were received. This number is satisfactory as certain
conclusions can be drawn from the response. Lazar and Preece received 112
responses to their survey, but this was from all over the USA, whose population
is five times greater than that of the UK.
The sample has pro’s and cons, the response is good in that it gets
information from a wide geographical area, but it fails in some respects
because a large proportion of the respondents already access information via their
own league websites, thus the lack of information problem is not so apparent. More surveys were filled in online, than
on paper, and therefore this has had dramatic effects on the analysis of the
results. Each effect will be explained in
the appropriate section below. Figure
5
- Questionnaire Source
The survey results can be grouped by: The goal of the first set of questions
was to determine whether the respondents to the survey truly represented the UK
snooker league participants. No
directory of league participants exists, so it’s impossible to establish how
many league participants there are.
“Since it would be impossible to statistically test whether the sample
represents the proportions in the actual population, no statistical comparisons
can be made” (Lazar et al. 1999, p.53).
Instead the demographic questions helped to determine whether the sample
was diverse and represented fairly the typical league participant. From the results this seems to be the case,
for instance 100% of the survey respondents were male, responses came from a
wide age range, 17 – 75 (see figure 6), the average age being 43, respondents have
played in 32 (see table 1) different snooker leagues all over England rather
than the UK, from as far south as Cornwall to as far north as Carlisle (see
figure 7). Figure
6
- Age of UK Snooker League Participants
The survey response did not cover the
whole of the UK, but covered a good sample of England as seen in figure 7. Here is a list of the 33 snooker leagues that
survey respondents have and currently participate in. Table
1 - The leagues that the individual survey respondents have played in 1 Alby and
District (North Norfolk) 2 Alby and
District Billiards and Snooker League, Fakenham Snooker League, Stiffkey
Billiards League, Norwich Snooker and Billiards League, South Norfolk League,
Norfolk Billiards and snooker super leagues 3 Camborne,
Redruth and district mining division snooker and billiards league,
Perranporth district snooker league 4 Carlisle and
District, Stafford League 5 Efficiency
League and Stirchley and District both in Birmingham 6 Exeter and
District Billiards and Snooker League 7 Hazel Grove
Conservative Clubs 8 Kings Lynn,
Wisbech and Norfolk Super Leagues 9 Manchester
Snooker League 10 Manchester
snooker league, hazel grove con club le 11 Markington and
District + Harrogate District 12 Newton Abbot
and District Billiards and Snooker League. Torbay Billiards and Snooker
League. 13 Perranporth
and District; Mining Division; 14 Redcar Games
League and currently the Cleveland Billiards League Snooker League (I am the
league secretary of the CBSL) 15 Sheffield 16 Sheffield And
District Association Snooker League 17St Blazey and District,
Newquay and District, Mining League - All in Cornwall 18 Stafford 19 Stafford 20 Stafford 21 Stafford 22 Stafford 23 Stafford 24 Stafford 25 Stafford 26 Stafford 27 Stafford 28 Stafford 29 Stafford +
West Midlands 30 Stafford
League 31 Stafford
League 32 Stafford
League 33 Stafford
League 34 Stafford
League 35 Stafford
League 36 Stafford
League 37 Stafford
Snooker league 38 Stafford
Snooker League 39 Stafford, West
Midlands League 40 Staffs and
West Midlands, Birmingham Efficiency League 41 Vic Harris 42 Vic Harris
District Snooker and Turlock Billiards League 43 Thameside
snooker league and The Vic Harris snooker league 44 West Midlands 45 West midlands
and Dudley leagues 46 West Midlands
Snooker League and Dudley Snooker League 47 West
Mids/Dudley and district 48 Westerham
Snooker League 49 Wirral,
Deeside (North Wales), Chester, Bebington Figure
7
- The locations of the UK Snooker league survey
respondents
The sample of users is certainly well
balanced; figure 8 below demonstrates that the survey respondents have
participated in UK snooker leagues from 1 – 40+ years. Figure
8
- League participation length
The most common league information
sources are local newspapers and from snooker leagues website (see figure 9).
The high proportion of participants accessing information from their leagues
website is not a representative result of the nation as a whole. The reason being is that we contacted a large
proportion of the league respondents via a league website directory, this directory
probably contains the majority of UK snooker league websites that exist, and so
the high number of respondents who filled in the questionnaire online (34/49)
typically access their league information via their own leagues websites. If a more representative sample of the
leagues on a national basis could have been achieved then a higher proportion
of league participants would access league information via the local press,
thus giving even greater value for a national UK snooker league online community
to be developed than the results from the survey suggest. Figure
9
- League information source
The majority of the survey respondents
said that league information is always available, but only 10% of those who
said that information was always available said that the source was the local
newspaper. The other 90% got the
information via a website, thus it seems encouraging that value would certainly
be gained from developing the community.
The great majority of respondents who said that information was either
sometimes or rarely available identified the source as the local press or
friends. Figure
10
- League information availability
Another encouraging result from the
survey is the high number of people who have access to the Internet (42/49)
(see figure 11), although this certainly would not be the average figure if a
better sample was taken of the leagues on a national basis, but the result
remains very high even so. The majority
of respondents access the Internet from home on a daily basis (see figures 12
and 13), thus the online community could potentially be regularly utilised by
future members. The overwhelming
majority of Internet users access the Internet using Internet Explorer (34/37),
thus the design of the site should be tailored towards this browser, although
the site will certainly need to be usable in browsers such as Netscape. Every single respondent who has access to a
computer uses a PC, thus again the design of the site can concentrate on how a
PC displays a website. Figure
11
- League participants Internet access
Figure
12
- Internet access location
Figure
13
- How frequently participants access the Internet
This group of questions was designed to
discover what computing and Internet experience league participants possess, to
discover what proportions of potential future members are able to utilise the
community. The result will not represent
the UK league participants’ skills accurately, due to the fact that many
respondents completed the survey online, thus their computing and Internet
skills already exist. If the majority of
the respondents possess little or no Internet experience then their usability
requirements will be different from those who do possess more experience. Figure
14
- Internet usage - Longevity
UK league participants on the whole have
less computing skills and Internet experience than the results from the survey
suggest, this is based on the results attained from the paper surveys that were
distributed in the Stafford league (See Appendix B), and also refer to figures
11, 15, 16 and 17 for comparisons. Figure
15
– Computing skill – Paper survey results only
Figure
16
- Internet access - Paper survey results only
The results in figure 17 below are
encouraging because a large proportion of the respondents believe that their
computing skills are advanced or average, thus they will possess the basic
skills essential to utilise an online community, these being the ability to
browse web pages, locate the information they desire to access, and post
messages to a discussion Forum. Figure
17
- League participant’s computer skills
The results in figure 18 below display
that the vast majority of younger league participants (17 – 50 years of age)
believe that their computing skills to be advanced or average. But surprisingly, many over 50 respondents
say that their computing skills are average, thus suggesting that the great
majority of the respondents should have no trouble using the future online
community. Figure
18
- Computing skill by age
It was
important to discover what proportion of the respondents had the experience of
being part of an online community previously (see figure 19). The results show that 20% of the respondents
possessed experience, this again was encouraging for future membership
participation, and we did not expect a percentage as high as this. Figure
19
- Previous participation in an online community
The results below display that the
majority of respondents possess email accounts, thus their computing skills are
to a basic standard. Figure
20
- Possesses an Email account
Community-centred development as outlined
in Preece, borrows ideas from contextual inquiry and participatory design, and
each of these areas demand that the designer works closely with the user to
produce a usable system. The high number
of people willing to participate in developing the community provides this
opportunity (see figure 21). Many people
from all over England offered to take part in testing and refining the site,
but the more local respondents to Stafford will be contacted so that usability
tests on the prototype online community can take place once it has been
developed. Figure
21
- Willing to help test and refine the website
This question was deliberately open ended
to discover what features future members would like to see (see figure
22). All the features can be achieved
through the online community, the main features are: -
Up-to-date league information -
Historical data -
Forum Inter-League competitions could be
organised through the website Forum, whilst fixtures and results could be
displayed in the website itself.
Coaching tips could be provided in the content of the site and youth
development promoted through the site.
Pictures of events, teams, individuals etc could easily be displayed on
the site. Figure
22
- Website features suggestions
The preferred method of community
communication is through a message board, this asynchronous method of communication
was the expected choice of the respondents (see figure 23). The community is probably going to be more
formal than informal, and therefore a Forum provides a more formal style of
communication for the future community.
Also, because a Forum offers the opportunity for communication to take
place over days or even weeks this would be more suitable for this particular
type of community. Figure
23
- Preferred method of online community communication
This was probably the most important
question on the survey, and the results speak for themselves (see figure
24). 42/49 people said that they would
access their leagues information via a website, this is everybody who has
access to the Internet who took part in the online community. Thus, those who do not have access to the
Internet are the one’s who cannot access information about their leagues
online. This is exactly the response
that was hoped for, thus value will be derived from the community. Figure
24
- Participants who would be willing to access
league information via a website
Leagues are based on a weekly meeting,
hence the results in figure 25 match the weekly update of information that
could be found in the community’s content, the other respondents who would like
to access the community more frequently would probably do so to participate in
discussion within the Forum. Figure
25
- How frequently would the participants access the
website
The result in figure 26 are encouraging,
the results show that the greatly isolated communities would certainly have a
good chance of uniting through a high proportion of the survey respondents
willing to utilise the Forum. Figure
26
- Willing to participate in an online discussion
Forum
This section looks at the tasks that
league administrators and participants undertake, once this is established the
tasks can then be mapped into the online community itself. Four league administrators were given a
separate questionnaire to the league participant questionnaire in order to
ascertain their role within their leagues, what duties they perform, and to
discover how much computing and Internet experience they possess. Their duties usually take from 3 – 8
hours per week to complete. They
generally keep both a soft and hard copy of the league information, using a
Microsoft Excel spreadsheet and in a notebook.
Their duties include: -
Organising the fixtures for the season -
Collating league results weekly -
Drawing and collating results for knock
outs for several competitions within the league, an example is the individual
Stafford snooker league championship -
Records individual highest breaks and the
most wins on a divisional basis -
Keeps hardcopies of the leagues results -
Sends information to the local newspaper
weekly -
Creates minutes at league committee
meetings -
Keeps historical records of the league’s
results, fixtures, tables etc The league administrator is the key
figure for the success of the online community as they are currently
responsible for collating all league information. They are also the central
repositories for all league information it seems logical that they become
responsible for updating information on the site on a regular basis. The many hundreds of league
administrators along with the snooker league committees themselves will need to
be persuaded to use the community as a tool for storing, retrieving, and
manipulating their leagues’ information if the community is to be a success. This can be achieved for two reasons; one
being that the most typical method currently being used by league
administrators to store information is antiquated, for example, the Stafford
league administrator records all the data in a 1000 line Excel
spreadsheet. When he was observed going
about his duties, it was discovered that he had difficulties using the
spreadsheet, he scrolled endlessly in an attempt to locate the information that
needed updating, and cut and paste teams above or below each other as they
moved up or down the league table.
Whilst performing the rearrangement of teams in the league table, teams
were often placed in the wrong position in the league table. This error, which
was witnessed, was evident in the local newspaper the following week.
Interestingly, players in the opposing team, which our team played against that
week, remarked that the league table was incorrect. The proposed website will be database driven,
thus the storing, retrieving, and manipulating of information will be much more
sophisticated than that of a spreadsheet and should reduce mistakes like those
mentioned above, and ultimately reduce the workload of the league
administrators. The other reason is that
if league administrators record all the league information online, then that
information will be readily available to every participant within their league,
and be much more up-to-date, thus solving the lack of information problem that
the league participants complained about in the survey results. Based on our extensive participation
within two separate snooker leagues in the UK, we possess a good understanding
of the tasks that league participants perform, these being, to access
information concerned with their particular snooker league, at present the
participants access the information via the local press, websites, word of mouth,
and possibly on club notice boards. The
types of information that participants wish to find need to be mapped into the
online community; participants would like to see up-to-date league tables,
news, results, fixtures, rules, player statistics, and various team and
individual cup information. The survey instrument designed for this
project utilised insights from the virtual community literature that Lazar and
Preece produced in 1999 and 2000; they explain the problems and issues of
gathering user requirements for virtual communities that are spread over a wide
geographical area. Virtual communities
are a relatively new phenomenon; therefore research on gathering their users
requirements is still in its infancy.
Lazar and Preece tackle this problem by looking at the various options
available, and then arriving at the conclusion that designing an online survey
to gather user requirements would be a viable solution. Therefore their work will be followed as a
guide to gather requirements for the proposed community. What can be drawn from the assessment of
the community needs? From the survey
responses there is certainly a lack of information currently available to
leagues in the UK, although the results do not highlight this problem fully
because many of the respondents can already access their particular leagues
information via their own leagues website.
From a national perspective, league information is not detailed enough
or readily available. The results are
encouraging because most of the respondents possess the Internet skills and
experience to utilise the online community, also Internet access should not be
a problem for league participants, especially as more and more people will be
going online in the future. It also
seems promising that the isolated leagues may unite through a Forum in the form
of the organisation of inter league competitions and through discussion of the
sport of snooker on a national basis.
The results from the league participants survey reveal that an online
community for UK snooker leagues would certainly be valued and utilised. In terms of the analysis of users tasks,
it is the league administrator who will be responsible for the inputting and
updating of data for their leagues. The
four administrators who responded to the league administrator questionnaire
highlight that their present methods of recording data are antiquated. By providing a tool in the form of a database
driven website, this would be a more efficient way of storing, retrieving, and
manipulating data, whilst at the same time providing detailed and up-to-date
information to players in the UK snooker leagues. The following section looks at selecting
technology and planning sociability for the UK league snooker community. Preece points out that “with the
community’s needs determined, the next steps are to identify software to
support the community and start sociability planning” (Preece, 2000,
p.220). In this chapter the aim is to
achieve this by looking at message board options, web site design and planning
sociability.
Based on the results from the survey,
(see figure 23) an asynchronous form of communication has been chosen,
therefore various options available for including a discussion Forum as part of
the online community were researched. In the book ‘Poor Richard’s Building
Online Communities’, the authors point out that if you want to add a message
board to a website there are three options.
“Link to a site that hosts message boards, contract with a site to run a
custom message board for you, or install your own message board software”
(Levine, 2000, p.232). Each option has
their own advantages and disadvantages, for example if you decide to link to a
site that hosts message boards, the advantage is that it is quick and
relatively simple and free, but the main disadvantage is that you cannot fully
customise the software to match the design of your website, thus users may get
confused about whether they are still using your online community website or a
totally different site all together. The book provides useful information
about message boards that you can download for free and then integrate into
your online community website. For
example, http://
www.discusware.com/discus
offers a free message board download, for this the online community developer
gets a well designed, professionally built application. The message board has been designed to
consider usability issues and looks simple and easy to use. The product offers a number of features
for the user:
The product offers a number of features
for moderators and the administrator: Source:
http://www.discusware.com/discus4/index.php Discus
Freeware offers many advantages to the project; firstly its free, it has been
downloaded and installed on several thousand websites, thus it has been tried
and tested, the product offers many features as listed above, in particular the
feature that allows you to customise the interface is impressive, the Forum can
be made to match the design of the rest of the site by changing the hex colours
of the discussion forum simply by using the forums appearance manager
interface. A discussion forum could be built
in-house, and this would maximise our control over the overall design and
maintenance of the site, but time is a real constraint, thus it was decided to
‘bolt on’ the Discus Freeware message board to the online community. Preece reassures any doubts we have by
highlighting that “assembling modules in a Web Site is becoming popular, and
has much to recommend it” (Preece 2000, p.221).
The new web site content, page design,
and navigation begins here. “Also useful
at this stage is to conduct reviews with community members to check that user
needs are being met and the overall conceptual design is appropriate” (Preece
2000, p.221). Russell Cox, a Global IT
Infrastructure Manager for Astra Zeneca completed the league participants
questionnaire online (Appendix A), he offered some useful advice on the
software selection for the community. “Supporting
software / tools - must be loads of duplication between leagues arranging Knock
out competitions. I'd like to see how other leagues handle common problems -
handicapping (individual or team). Bog
standard (vanilla) supporting database software which generates fixtures,
captures results, generates individual and league tables - how many god damned
spreadsheets are there around the UK which do this!” We
agree with Russell that the community website must be database driven so that data
can be stored, retrieved, and manipulated efficiently. This can be made possible through various web
technologies. A list of several of the popular technologies is shown below, we
will justify our particular choice of technology with which to build the
community.
Database
driven websites use scripting languages such as ASP, PHP, Perl, and Coldfusion
to build regular HTML pages, which can be output to any browser. These
languages allow data from a database to be displayed, inserted, updated, and
deleted using a web browser.
“Scripts in dynamic web pages
use input from users to access data from a database on the web server and then
builds or customizes the page on the fly before sending it to the requestor” (
http://www.intermed.dk/contentmanagement/datadriven.pdf
, last accessed 11/05/03). This
is exactly what the league administrators would need to be able to do if they
need to manipulate the content of the community. Below is a comparison of the four main
scripting languages. ASP is
a relatively easy language to program, especially when using a development tool
such as, Macromedia Dreamweaver MX to generate the ASP and HTML code. It is based on the Visual Basic scripting
language, on the Microsoft Windows platform using Internet Information Services
(IIS), although available for UNIX based platforms, with the use of for example
ChiliSoftASP. Originally developed in the UNIX
environment, but is now available on the MAC and Windows operating
systems. This scripting language is
available for free and is relatively easy to program as it can be embedded
within HTML. This language is very flexible because
many modules are available, but many people find that the language is difficult
to program, and so its popularity has suffered mainly because Perl cannot be
embedded within HTML. “ColdFusion (from Macromedia) uses a tag based syntax much like HTML and
is considered by many users to be easy to learn. What can be done in ColdFusion
may usually also be done in ASP or PHP” (
http://www.intermed.dk/contentmanagement/datadriven.pdf
, last accessed 11/05/03). Many developers choose Coldfusion because
they believe that website programming is faster with this language. Michael Schacht Hansen et al (2003) from the University of Aarhus,
Denmark produced
a
paper that compared the four languages in terms of their cost, ability to be
embedded within HTML, ease of use, database interface, text handling, and image
handling. See the results below. Perl PHP ASP ColdFusion Price1. Free
Free +
++ Embedded in HTML No Yes Yes
Yes Ease of use2 + +++ ++ +++ Database Interface +++ ++ ++
+++ Text handling +++
+++ +
++ Image handling3. ++ ++ +
+ Table 2 - Semi quantitative
comparison of features of four programming environments. 1. (+): ASP is an integrated as part of MS Windows IIS server. (++):
ColdFusion comes in three editions: two commercial (Enterprise and Pro) and a
feature limited free edition. 2. Based on learning curves and complexity of the code: +++: Easier +:
More difficult. 3. Based on power and availability of image handling modules Source:
(
http://www.intermed.dk/contentmanagement/datadriven.pdf
, last accessed 11/05/03). From the results, PHP came
out as the most proficient of the languages, the language is available as free
open source software and seems particularly easy to program. This language would seem the most suitable
with which to build the community but due to a lack of PHP knowledge, we cannot
afford the time to learn how to program using PHP. The author possesses two years ASP experience
thus this seems the best language choice for developing the community. In the future the community could be
re-written in PHP. Several DBMSs are available for the
online community; a choice needs to be made based on a number of criteria, the
main being complexity, cost, support, scalability, security, and effective and
efficient back up methods. When building
a database driven website the following DBMSs can be considered – MySQL, Oracle
9i, Microsoft SQL Sever 2000 and Microsoft Access. MySQL is free, but lacks support. Oracle 9i is very complex to administer and
extremely expensive and therefore seems unsuitable for the project. Microsoft SQL Server 2000 is a good option
because it is relatively cheap to purchase a license, offers automated backups,
and offers the vast support of the Microsoft Corporation. And finally Microsoft Access would from our
experience be the most suitable database for the project, it is relatively
cheap, it is an excellent prototyping tool because it is simple and easy to use
and more importantly it can be easily hosted for free by a web hosting company.
This is essential for the usability testing that needs to be carried out over a
wide geographical area. The future
database should be migrated to a Microsoft SQL Server DBMS, if the community grows,
the data will need to be made more secure, backed up frequently, and allow for
multiple users to access the data. Microsoft Access is a desktop application
whilst Microsoft SQL Server is a server application and can therefore offer
much more. Preece points out the importance of
planning sociability. “Careful social
planning, sociability, and well-crafted software, usability, can’t guarantee a
successful online community, but without them, almost certainly a community
will fail” (Preece 2000, p.268). She
emphasises the important role that the developer plays in community
development, that they have little or no control over community members but
they can help get a community off to a good start by producing usable software and
planning sociability carefully. She has
presented a number of guideline for proper planning sociability; sociability
planning should focus on three key principles – people, purpose, and
structure. The purpose of the community needs to be
defined clearly, the name of the community is important. It needs to be
meaningful and easy to remember. The
community name, ‘The UK Snooker League
Community’ was contemplated, but this sounds like that there is a single
snooker league for the UK, so the name ‘The UK League Snooker Community’ was
chosen because it denotes that the community is for snooker leagues in the UK,
thus the domain name
http://www.leaguesnooker.co.uk
was
registered. Preece advises that you
place a short description of the purpose of the community on the home page;
here is the description chosen: The
community is designed for three purposes: 1.
To provide players who play in Snooker
Leagues throughout the UK with up-to-date information from their leagues. 2.
To reduce the workload of league
secretaries, by enabling information to be input and stored efficiently. 3.
To enable players to communicate through
a Forum on a national basis. If you
want your league to join the community, don't hesitate to contact Richard
Ormiston. People will need to play different roles
in the community. The objective is to act as the community administrator, who
is responsible for creating new leagues in the database, and assigning usernames
and passwords to the league administrator so they can begin administrating
their leagues online. The community
administrator is also responsible for assigning the role of moderator to
people, the role is extremely important because they are responsible for
“initiating and guiding discussion, as well as acting as trouble-shooter when
there are interpersonal problems” (Preece 2000, p.271). Deciding whether to have a moderator is an
important consideration, a volunteer who plays in one of the UK leagues would
probably be asked to fulfil the role. Developers need to ensure that a correct
level of governance is achieved, too much will put users off, whilst to little
could weaken the community. For example if discussions are not guided they can
loose their relevance as spontaneous commentary breaks out. “The trick is to achieve the right balance of
structure and flexibility to launch a community on a steady course of growth”
(Preece 2000, p.271). Based on the community needs analysis in
chapter 3 it has been deduced that the community be open with no registration
policy for league participants. A closed
community with a registration policy is not necessary for several reasons: 1.
The registration process itself may deter
people from using the message board 2.
The Discus Freeware message board allows
for moderators to control problems such as flaming or spam if they occur. 3.
If other people from leagues that have
not joined the community can see the wealth of information that would be
available to them if there league did join the community then this would be a
great promotion for the community. As owners of the community and strongly
interested in the future of its development, we therefore assume responsibility
for the governance of the community.
Communities
that are voluntary tend to have a democratic form of governance and so free
speech should be offered to the forum participants on a trial basis, if abusive
language or racism occurs for example, a volunteer will be asked to moderate
the community. Trust is an important consideration for a
community, the nature of the community does not mean that trust is crucial as
in the case of an e-commerce or health community, but the option to keep
personal information confidential must be offered. The Discus Freeware message board gives
people the option of posting their email addresses to the forum, thus they have
the option to keep their anonymity if they wish to do so. To encourage trust a policy can be displayed
on the site. Policies need to be considered carefully
as they affect the usability of the community if software is involved. Policies also affect the purpose and people
in the community. The aim of this chapter was to identify
the software options available to community developers, and in particular
justifying the software selection for the UK league snooker community. Sociability has been discussed as being an
important domain of the online community, without supporting sociability properly
the community may not even get off the ground.
“A key way to achieve this is by planning policies that encourage
development of congenial and appropriate behaviour” (Preece, 2000, p.296). In the next chapter the third stage of
community-centred development is discussed. This
section outlines the important design decisions that were made whilst
designing, implementing and testing prototypes.
It is crucial that design decisions and reasoning behind them are recorded. If a team created the prototypes, the design
rationale provides a communication tool so that all members can understand the
decisions agreed and dispels any misunderstandings about the project. A prototype can come in many forms,
“traditionally prototyping approaches mainly take the perspective of the
designers and software engineers, and pay little attention to user involvement
in the design process” (Bodker, S and Gronbaek, K, Chapter 10, Design at Work.
1999, p.199); we chose to build the community directly as a web application in
an iterative manner by building and testing different design ideas, actively
involving users in this development process.
The methodology was very productive, each time we observed a user
performing several tasks using the interface it highlighted various problems
that were then corrected. Once the
problems were fixed another user completed the same or very similar tasks in
the next iteration. The first step was to design a relational
database that mapped the workings of any snooker league in the UK, because
snooker leagues throughout the UK are so diverse in their methods of scoring,
cups and awards (see appendix C) the entity relationship model needed to
reflect this in its design, in other words the database had to be generic on a
national basis. The design started by
researching other Entity Relationship Models, (ERMs), of sports leagues on the
Internet. An ERM for a squash league was
discovered and used as a basic reference, but after several days of thought and
discussion the ERM radically changed.
Through the league administrators’ survey and our knowledge of the
workings of snooker leagues eleven entities were eventually decided upon, but
this was not finalised until well into the programming of the interface, the
relationships between the entities were also being modified late into the
programming stage. This is not ideal way
of designing a database, but put this down to our basic knowledge of Entity
Relationship Modelling. Cascading
deletes have been put in place in order to stop the database from storing
orphaned records, for example if a team is deleted, all players within that
team are also deleted. Sixteen queries
have been created to help display data-driven content in the browser (see
Appendix F).
Figure 27
- The community Entity Relationship Model and
Attributes
5.2
Web Site Mapping
Microsoft Visio 2002 Professional was
used to produce a map of the web site.
The map displays 78 pages of the site and also the type of page, whether
it is ASP, HTML, or a page linking to another website. For example there is a
link to
http://www.streetmap.co.uk
,
which is used to display a map of a snooker club location, based on the passing
of the postcode of the club as a parameter, which is stored in the
database. The map does not show every
single hyperlink that each page contains but it does display how pages
generally link to each other. Once the
map is produced it is much easier to program the web site because the map acts
as a plan that can be followed methodically, although some adjustments did need
to be made to the site design. The map
displays the three levels of the web site, the league administration area,
league participant’s area, and the community administration area. 5.2.2 League Administration Area (See Figures 28 and 29)
There are 46 pages that a league
administrator can use to administer their particular league. Firstly a league administrator needs to
log in to their area, once they have logged in, they are taken to a league
administration home page (see figure 40) where they can administer teams,
clubs, divisions, seasons, news, team KO’s, player KO’s, division results,
division fixtures, division tables, and player details. At the next level down the administrator can
perform the three database actions of insert, update, and delete for most of
the higher levels. For example ‘Update a Players details’ (see figure 41). 5.2.3
League Participants Area (See Figure 30)
There are 23 pages that are publicly
available to league participants, not including all the pages that are
available inside the Discus Freeware forum (see figure 38). At the highest level is the home page (see
figure 33), which states the purpose of the community and displays a map of the
UK. This map allows a user to click on a
county, which takes them to a page that displays all the snooker leagues in
that particular county (see figure 34), the users can then click on their
particular league which then directs them to their league home page (see figure
35). From the league home page, the user
can then access the wealth of information that they seek, this being league
tables (see figure 36), fixtures, results, players statistics (see figure 37),
rules, news, team KO fixtures and results, player KO fixtures, and results and
the club directory, which displays a link to the
http://www.streetmap.co.uk
to
show the location of each club in their league.
5.2.4
Community Administration Area (See Figure 31)
There are 9 pages available for the
community administrator to access (see figure 45). The pages allow the community administrator
to add and edit a league, followed automatically by the creation of a season,
division and a user for a league. The
reason this occurs is because programmatically league administration cannot
take place until these three attributes are inserted into the database. The area also allows the community
administrator to add more than one league administrator or delete a league
administrator. 5.3 Programming the
Interface
Macromedia Dreamweaver MX was chosen as
the web application design tool mainly because we possessed extensive
experience of using the tool to develop database driven websites and also
because it can generate ASP and HTML code very quickly, although a certain
proportion of the code needed to be created manually. The tool was used to build several iterations
of a template that would direct the overall look and feel to the site, and also
to create the main forms of navigation for the site. The tool also provides an interface to link
to a database, creating the code for record sets, inserts, updates, and
deletes. Macromedia Fireworks 4 and Adobe
Photoshop 6 were used to produce the various graphical images that exist within
the site. 5.4
Web Site Design
Ben
Schneiderman’s eight golden rules of interface design were consulted for
guidance during the construction of the web site. Schneider man points out that consistency
is the most violated of the eight rules.
Consistent terminology, fonts, colour, layout, and capitalisation have
all been employed in the site design.
The terminology used in the site is familiar to snooker league
participants and the content of the site is based on the assessment of
community needs and our personal knowledge of the snooker leagues. Shortcuts have been placed strategically
throughout the site to enable frequent more experienced users to complete tasks
quicker. Feedback has been designed so
that “for frequent and minor actions, the response can be modest, whereas for
infrequent and major actions, the response should be more substantial”
(Schneiderman, 1998, p.74). An example
of this is when a league administrator deletes a team or person; they click on
a ‘Delete’ hyperlink that takes them to a ‘Are you sure’ screen (see figure
43). The system is designed so that
users cannot make serious errors and that actions are reversible, for example
if a league administrator inserts an incorrect team name into the database he
has the option to change the teams name using an update page. Schneiderman emphasises that user anxiety
should be kept to a minimum by not introducing any surprising actions, tedious
sequences of data entries, the inability to obtain necessary information, and
the inability to produce the desired action in the system design (Schneiderman,
1998). Finally, it is important to keep
the design simple so not to overload human short-term memory. The vast majority of Schneiderman’s golden
rules of interface design have been followed in the sites design, if they have
not all been followed, it is due to a lack of experience, producing a community
by one person rather than ideally in a team and time constraints. A template was created that was based on
many thousands of typical web site designs, a banner at the top and a navigation
bar at the top left corner of the screen.
Several prototype templates were created that evolved into the present
template, the current template looks far more professionally designed than the
template seen in figure 32, this is due to several design ideas being produced
and evaluated. The screen layout in the
content area of the page is based on HTML tables that suit the context of the
site that primarily displays statistical data in a tabular format. The site has been designed so that it fits an
800 x 600 pixels screen resolution; therefore there is no horizontal scroll bar
at the bottom of the page. This is still
the most commonly used screen resolution, but this is shifting to 1024 x 768
pixels. The colours chosen are greatly pastel in
tone because they seem easy on the eye. The green background was chosen to
signify the sites association with the sport of snooker i.e. the cloth on a
snooker table is green. There are 5 colours used in the template area and 3
colours used in the content area; this choice is based on Nielsen’s advice;
“Don’t over do it. An interface should
not look like an angry fruit salad of wildly contrasting, highly saturated
colors. It is better to limit the design
to a small number of consistently applied colors” (Nielsen, 1993, p.119). The hyperlinks in the navigation area are
constantly coloured black whether they are clicked or not in contrast to the
content area of the site where all hyperlinks are constantly coloured blue
whether they are clicked or not, this is an attempt to distinguish the two
areas. The colours of the discussion
forum were set to the same colours that are used within the web site, which is
royal blue and light yellow. This was possible through the forum administration
interface. The home page states the purpose of the
community, and displays a map of the UK split into counties and regions. A user can click on their particular county
to drill down to the detail of their particular league. The map is a key part of the design of the
community because it displays to members and future members that the community
is nation wide. The many existing
snooker league websites are based on one particular league, it is essential
that the community be instantly distinguished from such a site when someone
visits. If the community is to be
successful, it must encourage membership from all over the UK. Importantly, the county of Staffordshire is
pointed out as being the location of a working example of a snooker league that
has joined the community, this is important because prospective members need to
be able to see what the community has to offer.
A search facility is also available from the home page for league
participants to find people, clubs and teams, and it is also possible to search
within the forum. Historical data is a fundamental part of
the site and database design based on the feedback from the requirements of the
community. Season dates are stored in
the database and displayed in java script jump menus in the browser, enabling
users to access past data. League
administrators have the ability to add, edit and delete seasons. 5.4.1
Existing problems with the site design
At present there are security and help
facility problems that exist in the web site design. No help facility is available because of time
constraints, but because this is a crucial feature of a web site, a help
facility will certainly be needed to be designed, implemented and tested in the
future, along with the ability for users to report problems with the site and
offer feature suggestions. At present the site is not secure, once a
league administrator logs into the site they can try inputting various
parameters into the URL address string (see figure 40), and would eventually
gain access to another leagues data, they could then start deleting and
inserting rogue data into and from the database, this is certainly not
acceptable. To combat this serious flaw
in the sites design, the many parameters being passed through the URL address
string will be encrypted and decrypted. No data protection agreement has been put
in place yet, this is a legal requirement because personal details are being
stored in the database, each league administrator will need to agree to a data
protection statement before they can start using the community to administer
their league, therefore when an administrator first logs into the site they
will be directed to a page that allows them to agree to the terms of data
protection consent. Certain
features need to be added to the site design, for example different snooker
leagues possess many knock out competitions, at present the site allows for a
team and individual knock out competition’s fixtures and results to be recorded
in the database. But most leagues possess
many more competitions, for instance the Clitheroe and district snooker league
has a doubles knock out, and the Sheffield snooker league has a triple player
knock out competition. These features
will be designed and implemented in the future to allow for individual leagues
needs to be catered for.
Figure
32
– Prototype Template
5.5 League Participants view
Figure
33
– Home Page
Figure
34
- League in Staffordshire
Figure
35
- The Stafford and District Snooker
League Home Page
Figure
36
- The Stafford and District Snooker
League - Division 3 Table
Figure
37
- Player Statistics
Figure
38
- Discussion Forum Topics
Figure
39
- Post a reply
5.6 League
Administrators view
Figure
40
- League Administration Home Page
Figure
41
- Add a League Fixture
Figure
42
- Edit a Player
Figure 43
– Delete a person
Figure
44
– Season List
5.7
Community Administration view
Figure 45
– Community Administration
5.8 Usability Testing
Several users were contacted from the
survey that said that they were willing to test and refine the prototype
community (see figure 21). Usability
testing was then carried out to involve the future users of the community in
the design process, the testing not only gave the users a chance to voice their
opinions about the design of site, but also provided us with the opportunity to
see users work through over forty tasks.
The forty tasks formed the majority of the typical tasks that both a
league administrator and league participant would perform whilst using the
application, the tasks could be described as being benchmark tasks. “A
benchmark task is a typical,
representative task a user will perform; measuring a user’s performance on a
benchmark task provides an objective usability metric for the related
usability attribute” (Hix and Hartson, 1993, p.225). Users were timed each time they performed a
task. 5.8.1 Pilot Testing
It is essential that pilot testing be
carried out prior to formal usability testing with a sample of users. Pilot tests are designed to discover flaws in
the design of the usability test so that issues can be remedied before the main
usability testing takes place, it is important that the main usability testing
runs as smoothly as possible so that the data collected is consistent and
useful to the redesign process. “The
experimental tasks should be completely run through at least once, using the
intended hardware and software by someone other than the person(s) who
developed the tasks, to make sure for example, that the prototype supports all
the necessary user actions and that the instructions are unambiguously worded”
(Hix and Hartson, 1993, p.225). Thus two
users were asked to perform the pilot testing.
The pilot study highlighted a number of
problems, especially in the actual wording of the tasks, for example a user was
asked to change a season’s dates, they were not told what to change the date
to, and this then later caused significant confusion in the latter part of the
test. If such problems were not
discovered then it would impede the consistency of the results of the main
usability testing. The pilot testing was
useful in that it gave the tester the chance to practice observing, recording
and timing the actions of the users. 5.8.2
Usability Testing – Ethics
Usability testing is essential for the
successful design of an interface, but tests should be conducted with deepest
respect for the users emotions and well-being. Users can “feel a tremendous pressure to
perform, even when they are told that the purpose of the study is to test the
system and not the user” (Nielsen, 1993, p.181). Therefore, users were made as comfortable as
possible during and after the test by stating that they could leave the test at
any point, ask for help if they were struggling, that it was the system being
tested not themselves, that there results would remain confidential and that
they should expect to make a number of mistakes because the system was still a
prototype. At the start of the test the aim was to
give users a little confidence by almost guaranteeing that they successfully
complete the first task. After the test
the user was de-briefed about the problems that they had uncovered during the
test and allowed to make comments about the system, it was pointed out that
they had contributed to the development of the community and thanked for their
time.
5.8.3 Usability Testing – Format
Whilst users performed the test, they
were observed very closely, notes being taken on the problems that they
encountered, whether they needed help or not and whether they failed to
complete a task. 5.8.4
Usability Testing – Results
Each time a user performed the usability
test a great deal was discovered because users highlighted problems in the
sites design by completing the forty tasks, the list of problems were recorded
in an observational schedule, and then corrected ready for the next iteration
of build and test. Each user uncovered different problems that the interface
possessed, thus it was very useful to get several users to participate in the
test. The ultimate goal was to test and
refine the interface sufficiently enough so that users with basic Internet
experience and skills could go about their tasks with little or no
training. Users made most of the mistakes whilst
performing the tasks of the league administrator, mainly because many tasks
need to be completed to administrate a snooker league. Users had to get to grips with a navigation
method that was totally new, thus there was a lot to learn and remember, but
encouragingly as the test progressed users performed much better as they began
to learn how to navigate through the system. A usability concern uncovered was with
the many jump menus that exist within the site, users generally expect menus in
websites to be drop down, so when they first started to use the jump menus they
did not expect the content of the page to change, this problem would be
accentuated even more so if the Internet connection was slow. A possible solution to this problem would be
to place a ‘Go’ button next to the menus so that users can select a season or
division then press ‘Go’ to change the content of the page. The screen layout design in the league
administration area needed to be iterated many times; it was a difficult task
to design the navigation structure of the 46 pages in the area. For example, a blue cross is used to
distinguish the location of the league administration home page (see figure
44), but this was not implemented until after several usability tests. Also many pages possessed a season jump menu
so that users could see and change league details for different seasons. When a user did change a season and then
continued with the test they often became confused because the data that they
had just input into the database was no longer visible, therefore a decision
was made so that users could only change a season at one location – The league
administration home page (see figure 40). Several database design problems have
made the interface design suffer, for example, league administrators have to
add teams and points to a league table, this could prove to be quite an
overhead on their workload. If the
database had been designed more proficiently league administrators would only
need to insert league results into the database, and then league tables could
be generated automatically from the data in the database. Future work on the community will concentrate
on correcting this issue. The system still possesses minor software
bugs; for example, a user can try and insert a false date into the database
e.g. 31 April 2003, and a page cannot be displayed error appears in the
browser. A large proportion of the users had
problems posting to the Discus Freeware discussion forum. There is a piece of text next to the username
and password fields (see figure 39) that many users failed to read, therefore
when they attempted to post to the forum an error occurs. This is a real usability and sociability
concern, at present the forum is public therefore users do not need a username
and password to take part in the forum, if this policy changes in the future
the sociability of the community will change, participation levels would drop
but problems such as flaming would also reduce.
In the case of usability, if each user possesses a username and password
the problem of posting to the forum that was evident during the testing would
diminish. 5.9
Summary
This section has discussed the designing,
implementing and testing of prototypes.
This process has been achieved by following the sequence of designing a
relational database, creating a web site map, programming the interfaces and
involving the future users of the community in an iterative manner of build and
test. The process has highlighted the
importance of user involvement. Without user input, developers would have to
make huge assumptions on how to satisfy a community’s needs. The community’s design has reached a standard
that displays its future potential; this standard is not good enough for the
community to start accepting members, the problems discussed in this section
will need to be addressed firstly. This
can be achieved within a relatively short time span; the community will then be
released to the many UK snooker leagues. The
next chapter concludes this project by summarising the community-centred
development process, the findings, offers contributions to online community
development, and finally summing up the future of the ‘UK League Snooker
Community’. 6 conclusions and further research
This chapter’s
objective is to critically analyse the approach taken with regard to the
research methodology – community-centred development, the community design,
usability testing, and online community theory, suggesting further
research/activities of the community. 6.1 Research Methodology –
Community-centred development
The
methodology put forward by Preece is not an established method with a
successful proven track record; therefore we would like to offer our
contribution towards this methodology.
Preece follows the general rules of IT projects by borrowing ideas from
user-centred design, contextual enquiry, and participatory design. These three methods were chosen because they
are highly focused on the users needs rather than software engineering. We strongly agree that Preece has made some
careful and right decisions by borrowing ideas from three user-centred approaches.
Evidence of this was found whilst assessing the community’s needs, during the
design, implementation, and testing the prototype stages. The online survey provided a wealth of
information about future users needs and requirements over a wide geographical
area; combined with face-to-face interviews and observations we believe that
users needs have been successfully mapped into a prototype online community. There
are problems with the community-centred development process that would exist
with any methodology. Involving users in
the development of the community as put forward by Preece is difficult but
essential, but it is difficult to find future users of the community who
possess the time to help in its development.
For example, Russell Cox, a Global IT Infrastructure Manager for Astra
Zeneca offered some good advice about software selection when he filled in the
survey online, but when asked to get involved in the usability testing stage he
declined because he was too busy, here is an example of the difficulty of
involving future users. The
debate about whether quantitative or qualitative research methodologies are the
best is long running. Traditional
approaches tended to rely on statistics as being crucial for analysis. More recently research has shown that it is
crucial to involve users in systems development, their views and experiences
are needed in order to design a usable system.
As discussed throughout this project, a major reason why many IT
projects fail is due to poor user requirements gathering, it is essential to
involve users in the design process.
Both methodologies have their advantages, but certainly in this project
the qualitative approach has proved to be the most advantageous to the design
of the community. 6.2 Community Design
The
community design process highlighted the importance of involving users. Without
their input the community would not be able to satisfy their needs. The survey assessed their needs, while
observation and interviews analysed league administrator’s tasks. Once the user requirements had been assessed,
the relevant software was selected and sociability planned. Prototypes were designed and implemented, and
thorough usability testing conducted to refine the application. By consulting users throughout the
development process in an iterative manner many problems can be detected and
eliminated along the way, this can then save a lot of time and effort,
particularly at the later stages of development. 6.3 Usability Testing
Ideally
the number of users selected for usability testing would be much larger,
although we can say that there was a good age balance of users who took part in
usability testing. The samples of users
were aged 23, 24, 25, 38, 42 and 62, making the results a good representation
of the future community. Age can be an
important factor on the results, as different age groups generally possess
different Internet skills and experience. Whilst
conducting usability tests, users were timed performing the tasks, the aim was
originally to analyse the quantitative data in order to highlight usability
strengths and weaknesses. A decision was
made that this would provide little if any useful information on the usability
of the system because each user is very different to the next, their skills, experience,
and age can dramatically effect the time taken to complete a task. Timing the users with a stopwatch may have
had an effect on how users completed the tasks; this quantitative technique is
quite impersonal and will have placed an element of pressure on the users. Timing users encouraged them to perform tasks
as quickly as possible, and this certainly increased the number of mistakes
made, especially early on in the test when users were trying to get used to
both the test conditions and the system itself.
Therefore the times taken during the testing were disregarded and not
included in the analysis of the usability results. 6.4 Online Community Theory
At
present “most online community theory is borrowed from other disciplines, which
researchers adapt to make informed guesses about how it applies to online
communities. In the future, however, new
theories and methods relating specifically to the online world will become
essential to better inform software design, sociability and usability” (Preece,
2000, p.392). Preece highlights that
more theory that speaks directly to developers of online communities is
needed. Having researched and developed
an online community in this project we agree with Preece that more theory is
needed to guide developers to produce more usable and sociable software. The future of the ‘UK League Snooker
Community’ is not guaranteed to be successful, although it certainly looks
promising, but if more established theories on online community design had
existed that could have been used as guides then the community would be have
been designed more proficiently. This
situation is always going to be a problem when a new concept arrives, theory
needs time to take a foot hold, as more and more academics study the area, a
common ground on correct practices becomes established. Based
on our experience during this project, we would like to contribute towards
online community theory by offering advice to future developers on how to
produce effective and useful online communities. The contribution offered here is that
developers should try not just to produce an online community so that people
can communicate, but also to promote and develop an online community as a tool
wherever possible, this will then dramatically improve the chances of the
community’s success. During the project
it became clear that the community could save hours of work by providing a tool
for league administrators to administer their leagues online, rather than using
a spreadsheet, although further research is needed to prove this fully. If people discover that online communities
can be used as a tool to complete their work whilst providing a service to
other people, then online communities could expand extensively. 6.5
Further Research/Activities
If the
community is to expand, we believe that just a few leagues need to be
enlightened on the benefits of joining the community. Once a small number of leagues start using
the site on a seasonal basis this will hopefully sow the seeds of the newly
formed community. Any person in the UK
will be able to go to the site (
http://www.leaguesnooker.co.uk) and see
publicly the wealth of information available to leagues that have already
become members of the community, as no username or password restricts access to
league information. This will be
achieved primarily by word of mouth, but it will also be possible for people to
discover the league through search engines such as Google, which currently
lists the ‘UK League Snooker Community’ at the top of the search list, if these
words are typed into the search field.
Publicity for the community needs to be widespread, mail shots can be
sent to individual leagues, and the community can be publicised on the Internet
using various methods. After
a usability test with Colin Hales a committee member and participant in the
Stirchley snooker league in the West Midlands, Colin remarked that his league
was looking to employ a designer to build a website and purchase an existing
database for the Stirchley league, but having seen the community and what it
had to offer he asked if the Stirchley league could become a member of the
community. The Stafford snooker league
administrator and a committee member have also used the community, and would
like to begin using the community as both a tool and service to its members in
next years season. This is a real result because it displays that the community
is valued, hopefully the communities value will be recognised by more snooker
leagues throughout the UK. 6.5.1 League Committees and Administrators
Persuading the
league committees and administrators to use the website as a tool to record
league data is going to be the greatest obstacle that the community will face
if it is to be successful or not. There
are several reasons why:
·
A lack of skill and experience of using
the Internet ·
That they find that their current method
is adequate ·
No access to the Internet ·
The cost of using the Internet
·
Posting to existing UK snooker website
forums ·
Contacting league committee’s to present
the website in person ·
To offer training to league
administrators on how to use the site, both in person and over the phone ·
To keep improving the sites functionality
usability and sociability 6.5.2 Adaptation of the community
From
the research and development carried out over the past four months, it became
more and more plausible that the ‘UK League Snooker Community’ could quite
easily become the ‘UK League Sports Community’.
The database and application code are designed specifically to be
generic because the UK snooker leagues are so diverse in their methods of
scoring a league and its competitions.
Therefore, sports such as golf, bowls, football, table tennis, rugby,
cricket, pool and many more that all possess local leagues located throughout
the UK could be also be served by the community. The home page could be replaced by a list of
all the sports that the community serves, and then users could click on their
particular league sport that would direct them to the current home page, that
would still contain the UK map and a different banner to represent each
individual sport. 6.6 Summary
This project has
attempted to combat the problems that UK snooker leagues currently suffer from
by researching and developing an online community to provide detailed information
for any snooker league in the UK and by creating a central point where league
players can communicate on a national basis.
Firstly, a literature review was conducted to discover more about online
community development, the work of Professor Jenny Preece was identified as
being the most outstanding, she proposes a method – community-centred
development that was followed. The
community’s design was achieved through assessing the proposed community’s’
needs, analysing user tasks, selecting the relevant software, planning
sociability, designing implementing, and finally testing prototypes. Throughout the project, users were involved
in the design process. Without their input the community could not satisfy
their needs, and would ultimately fail. Has the problem
been solved? It seems that the project
has achieved its objectives, but to what extent is uncertain. Two leagues have
displayed their interest in joining the community, which is a real result
considering that the prototype community has only existed for a short period of
time. But the community needs a lot more
work putting into it before it becomes a successful thriving place for UK
snooker participants to visit. The
league committees and administrators need to be enlightened about the benefits
of the community for their league members and as a tool to administrate their
leagues, by no means an easy task. They
also need to be welcomed and nurtured once they do become members, as Preece
points out “Nurturing is important not only early on in the community’s life,
but throughout its existence. Again,
communities are dynamic, and change as people join and leave, so ongoing
support is necessary” (Preece, 2000, p.211).
As the founder of the community we will carry on improving the
community’s sociability and usability, ultimately refining the site to a state
that is accepted by users from all over the UK.
This should then lead to achieving the overall aim of this project -
Uniting the isolated physical communities into a single virtual community. If the community were successful, then it
would seem very plausible that it extends its offerings to the many other
leagues sports communities that currently exist throughout the UK and therefore
become the ‘UK Leagues Sports Community’. 7 References
Beyer,
H and Holtzblatt, K. (1998) Contextual Design – Defining Customer-Centred Systems. San Francisco: Morgan Kaufmann Publishers, Inc Dix,
A., Finlay, J., Abowd, G., Beale, R. (1993) Human-Computer Interaction. Prentice Hall. Faulkner,
X. (2000). Usability Engineering. London: Macmillan Press Greenbaum,
J and Kyng, M (1991). Design at Work. London: Lawrence Erlbaum Associates Hackos,
J. and Reddish, J. (1998) User and Task Analysis for Interface Design. John
Wiley and Sons, Inc. Hague,
P. (1993). Questionnaire Design.
London: Kogan Page Limited Hewitt,
T. (1986) ‘Iterative evaluation’ in Harrison M D and Monk AF (eds) People and Computers: Designing
for Usability, Proceedings of the Second
Conference of the BCS HCI Specialist Group, September 1986. Hix,
D. and Hartson, H.R. (1993). Developing User Interfaces: Ensuring Usability through Product and
Process. New York: John Wiley and Sons, Inc. Kim,
Amy Jo. (2000). Community building on the Web. Berkeley, CA : Peachpit
Press Kollock,
P. (1996) Design principles for online communities. Harvard Conference on the
Internet and Society http://www.sscnet.ucla.edu/soc/faculty/kollock/papers/design.htm,
Last Accessed 14/01/03 Lazar,
J., Hanst, E., Buchwalter, J., Preece, J.; Collecting
User Requirements in a Virtual Population: A Case Study, WebNet
Journal: Internet Technologies Applications and Issues, Vol. 2 No. 4, Oct. -
Dec. 2000 Lazar
J., Tsao, R., Preece, J. One foot in cyberspace, and the other on the ground – A case study of
analysis and design issues in a hybrid virtual and physical community. WebNet
Journal: Internet Technologies, Applications, and Issues, Vol. 1, No. 3, 1999.
Pages 49-57. Levine
Young, M. and Levine, J (2000). Poor Richard’s Building
Online Communities – Create a Web Community for your Business, Club,
Association, or Family.
Lakewood: Top Floor Publishing Lewis,
C., Hair, D., and Schoenberg, V. (1989).
Generalisation, consistency, and control. Proc. ACM CHI’89 Conf. (Austin, TX, 30 April
– 4 May), 1-5. Nielsen,
Jakob. (1993). Usability engineering.
San Diego : Morgan Kaufmann Oppenheim,
A.N. (1992). Questionnaire Design, Interviewing and
Attitude Measurement. London and New York: Pinter Publishers Preece,
J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. and Carey, (1994) T. Human-Computer Interaction. Wokingham, UK: Addison-Wesley. Preece,
J. (2000) Online Communities: Designing Usability, Supporting Sociability.
Chichester, UK: John Wiley and Sons. Preece,
J. (2001). ‘Online Communities: Usability, Sociability, Theory and Methods’ in
C. Earnshaw R., Guedj, R., Van Dam, A., Vince, J. (eds) in Frontiers of human-centred computing,
online communities and virtual environments. London
: Springer. Scheiderman,
B. (1998) Designing the User Interface – Strategies for effective human-computer interaction. Third
Edition Addison Wesley Longman, Inc. Schuler,
D. and Namioka, A. (1993). Participatory Design:
Principles and Practices. London: Lawrence Erlbaum Associates, Inc. Report
on the first joint European Commission/National Science Foundation Advanced
Research Workshop, 1-4 June 1999, Bonas,
France http://www.eimc.brad.ac.uk/news/8_2.htm,
Last Accessed 14/01/03 http://home-3.worldonline.nl/~sonali/snookerlinks/u02.htm,
Last Accessed 26/03/03 http://news.bbc.co.uk/1/hi/business/1500668.stm,
Last Accessed 03/04/03 http://badc.nerc.ac.uk/search/ukmo/ukmo_uk_counties_map.html,
Last Accessed 18/04/03 http://www.discusware.com/discus4/index.php,
Last Accessed 08/05/03 A Comparison of technologies for
database-driven websites for higher education Michael Schacht Hansen, Jens
Dørup, Lars Riisgaard Ribe and Kristoffer W. Larsen Section for Health Informatics,
University of Aarhus, Denmark http://www.intermed.dk/contentmanagement/datadriven.pdf,
Last Accessed 11/05/03 http://www.bbc.co.uk/lancashire/sport/cue_sports/leagues.shtml,
Last accessed 12/05/03 |
