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 Introduction. 6

1.1 Research Problem. 6

1.2 Project Background. 8

1.3 Aim. 8

1.4 Objectives. 8

1.5 Intellectual challenge. 9

1.6 Research Programme. 9

1.6.1 Methodology. 9

1.6.2 Determining the User Requirements - Interviews, questionnaires and observing. 10

1.6.3 Project Plan. 11

1.7 Deliverables. 11

1.8 Constraints. 11

1.9 Ethical issues. 12

1.10 Resources. 12

1.11 Summary. 12


2.1 Literature Review.. 13

2.1.1 Online Community Theory. 14

2.1.2 Usability. 15 Consistency. 16 User and Task Analysis 16 Usability Testing. 17 Usability Evaluation. 17

2.1.3 Sociability. 17 Purpose. 18 People. 18 Policy. 19 Sociability and Usability. 19

2.1.4 Software Development 20 Software Life Cycle. 20 Prototyping. 20 Software Options 21 Social Impact of Software Design. 22

2.1.5 Summary. 23

2.2 Research Methodology - Community-Centred Development. 23

2.2.1 User-centred design. 24

2.2.2 Contextual inquiry. 24

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

2.3 Summary. 27


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.4 Computing and Internet experience – Internet longevity and frequency of use, computing skill, possession of an email account and participation in online communities 40

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 Analysing user tasks. 49

3.4.1 League Administrators 49

3.4.2 League Participants 51

3.5 Summary. 51


4.1 Selecting Technology. 53

4.1.1 Message Boards 53

4.1.2 Web Site Design. 55 Languages 55 ASP (Active Server Pages) 56 PHP (Personal Home Page) 56 Perl (Practical Extraction and Report Language) 56 Coldfusion. 56 Language comparison. 57 Database Management System (DBMS) 58

4.2 Planning Sociability. 58

4.2.1 Purpose. 59

4.2.2 People. 59

4.2.3 Policy. 60

4.3 Summary. 61


5.1 Entity Relationship Modelling (See Figure 27) 62

5.2 Web Site Mapping. 65

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 Web Site Design. 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 Usability Testing. 74

5.8.1 Pilot Testing. 74

5.8.2 Usability Testing – Ethics 74

5.8.3 Usability Testing – Format 74

5.8.4 Usability Testing – Results 74

5.9 Summary. 74

6 conclusions and further research. 74

6.1 Research Methodology – Community-centred development. 74

6.2 Community Design. 74

6.3 Usability Testing. 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

6.6 Summary. 74

7 References. 74




Figure 1 – Project Plan. 11

Figure 2 - The three domains of Online Communities. 14

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). 21

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 33 – Home Page. 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 39 - Post a reply. 74

Figure 40 - League Administration Home Page. 74

Figure 41 - Add a League Fixture. 74

Figure 42 - Edit a Player. 74

Figure 43 – Delete a person. 74

Figure 44 – Season List. 74

Figure 45 – Community Administration. 74




Table 1 - The leagues that the survey respondents have played in…………………………     33

Table 2 - Semi quantitative comparison of features of four programming environments….        57




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



There are up to one thousand snooker leagues that exist in the UK , at present they are isolated, there is little or no communication that takes place between these leagues.  Often league participants do not know what is happening within their leagues, this being information such as league tables, fixtures, results, news and much more.  The typical source of information is the local newspaper that often displays vague information about a snooker league.  Therefore, to build an online community to serve UK snooker leagues would combat both these problems.  Before this can take place, online community development needs to be researched in order to discover the theories and methodologies behind their development with particular regard to assessing the needs of a geographically dispersed population.  Prototyping is an important stage of the process, in which users test and refine an application in an iterative manner of build and test.  The results from the project display that an online community for the UK snooker leagues would be highly valued by league participants because they could access detailed information concerning their league and begin to communicate with other league participants throughout the UK via an online Forum.  League administrators will also gain value from the community, as they can use it as a tool for storing, retrieving and manipulating their leagues information, while at the same time providing information to players within their league.  Due to this project, the future of the ‘ UK league snooker community’ looks promising.

1 Introduction


1.1 Research Problem


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 (, 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  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.          


1.2 Project Background


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.   


1.3 Aim


The aim of the project is to solve the problem of the lack of information available to snooker league participants throughout the UK, and through extensive research attempt to unite the many isolated UK snooker leagues by developing a successful online community.


1.4 Objectives


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.


1.5 Intellectual challenge


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.


1.6 Research Programme


1.6.1 Methodology


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          


1.6.2 Determining the User Requirements - Interviews, questionnaires and observing


User requirements can be gathered locally in Stafford, Staffordshire through paper surveys, and nationally via an online survey.  Snooker league administrators will be observed, interviewed, and questioned to establish the processes they undertake to record data within their particular leagues, and also to ask their opinions on what content they would like to see in an online community.  League participants will also be given questionnaires, which will assist in discovering what information and functions they would like to access via an online community.  The questionnaires will be conducted mainly via an online survey, as the user population is distributed throughout the UK .


1.6.3 Project Plan


Figure 1 – Project Plan


1.7 Deliverables


-          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.


1.8 Constraints 


There is no single directory of UK snooker leagues, it may prove difficult contacting the majority of UK snooker leagues, thus the amount and diversity of users that are contacted may be limited.


1.9 Ethical issues


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 UK snooker league participants will be regarded as confidential and not divulged to any third parties.  Anonymity will be preserved at all times and any findings will be used in conjunction with the research only.  We promise to adhere to an ethical code of conduct during the project.


1.10 Resources


  • Adobe Photoshop
  • Browsers
  • Fasthosts Web hosting company
  • Interviews
  • Journal articles, Text Books, World Wide Web and Newspapers
  • Macromedia Dreamweaver MX and Macromedia Fireworks 4
  • Microsoft Access 2000, Internet Information Services 5.0, Word 2000 and Visio 2002
  • Surveys
  • Users


1.11 Summary


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.


2.1 Literature Review


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.


2.1.1 Online Community Theory

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), (, 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.

2.1.2 Usability


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. User and Task Analysis


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 UK snooker league participants, it is also to learn about users by observing them in action.  There is no substitute for watching a person go about their tasks to learn what they are really doing in order to incorporate these tasks into a system that will be designed for them to use.  What people say and actually do can be totally different things.  “In fact, experience has shown that users themselves do not know how to articulate what they do, especially if they are very familiar with the tasks they perform” (Hackos and Reddish, 1998 p. 7).  Based on this evidence it is important to ensure that further research is used to investigate how to conduct user and task analysis properly based on the work of several leading authors in the field of HCI, in order to establish the tasks that UK snooker league participants and administrators conduct, particular focus will be placed on the administrator’s tasks. Usability Testing


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 Evaluation


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. 


2.1.3 Sociability


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. Purpose


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. People


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. Policy


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. Sociability and Usability


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).


2.1.4 Software Development


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. Software Life Cycle


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


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) Software Options


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://, eCircles ( or Yahoo Clubs (” (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). Social Impact of Software Design


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. 




2.1.5 Summary


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” (, Last Accessed 14/01/03).



2.2 Research Methodology - Community-Centred Development


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. 


2.2.1 User-centred design


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.


2.2.2 Contextual inquiry


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.


2.2.3 Participatory design


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

2.2.4 Assessing community needs and analysing user tasks


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)


2.2.5 Selecting technology and planning sociability


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).


2.2.6 Designing, implementing, and testing prototypes


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.


2.2.7 Refining and tuning sociability and usability


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.





2.2.8 Welcoming and nurturing the community 


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). 


2.3 Summary


“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.






















The aim of this chapter is to assess the needs of the UK league snooker community by using a range of techniques that specifically deal with communities that are spread over a wide geographical area.  Community needs are assessed by surveys and interviews, whilst user tasks are analysed through ethnographic observation to improve our knowledge of the UK league snooker communities.


3.1 Requirements gathering


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. 


3.2 Survey design and distribution


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.


  1. The domain was registered, and the company ‘Fasthosts’ was used to host the domain with a Microsoft Access database behind the site.  An ASP form at the domain above was built so that UK snooker league participants could fill in the questionnaire online.  Participants from leagues all over the UK were contacted via a useful website which lists a number of UK snooker league web sites. The sites generally display email addresses, this then allowed us to contact several league participants.
  2. Notices were posted on a couple of existing snooker league website forums pointing people to the website so that the questionnaire could be completed.
  3. Questionnaires were emailed directly to league participants and administrators in an Excel spreadsheet format.
  4. Several Stafford snooker league secretaries were telephoned, asked if they would fill in the questionnaire, and then posted a paper questionnaire directly to their homes (See Appendix B). 


3.3 Analysis of the survey results


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:

  1. Demographics – Age, Gender, Location
  2. Current league information sources and availability
  3. Internet – Access, Location, Frequency, Browser, Pc or Mac
  4. Computing and Internet experience – Internet longevity and frequency of use, Computing skill, Possession of an email account, and Participation in online communities
  5. Willingness to participate in developing the community
  6. Community features suggestions
  7. Willingness to participate in the community once it is developed


3.3.1 Demographics – Age, Gender, Location, Years of league snooker experience


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


3.3.2 Current league information sources and availability


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


3.3.3 Internet – access, location, frequency, browser, PC or MAC


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






3.3.4 Computing and Internet experience – Internet longevity and frequency of use, Computing skill, Possession of an email account, and Participation in online communities


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


3.3.5 Willingness to participate in developing the community


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


3.3.6 Community features suggestions


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


3.3.7 Willingness to participate in the community once it is developed


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


3.4 Analysing user tasks


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. 


3.4.1 League Administrators


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.


3.4.2 League Participants


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.


3.5 Summary


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.


























4.1 Selecting Technology


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.


4.1.1 Message Boards


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:// 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:


*  Intuitive user interface that works with any browser
*  User interface fully customisable with downloadable "skins"
*  Formatting, HTML validation, and in-line image upload
*  Search capability (by date and/or keyword)
*  E-mail notification of new posts in "subscribed" areas
*  User interface available in English and 15 other languages


The product offers a number of features for moderators and the administrator:


*   Comprehensive browser-based administration tool set
*  Unlimited thread depth, allowing organization of material within topics
*  Configure public or private posting for each discussion topic
*  User account management tools

*   Complete interface customisation using templates/skins
*  On-line skin gallery to try out and download new skins
*  Easy installation onto nearly any Unix or Windows server
*  Fast, reliable performance of board operations




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).


4.1.2 Web Site Design


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. Languages


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” ( , 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 (Active Server Pages)


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. PHP (Personal Home Page)


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. Perl (Practical Extraction and Report Language)


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


“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” ( , last accessed 11/05/03).    Many developers choose Coldfusion because they believe that website programming is faster with this language. Language comparison


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: ( , 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. Database Management System (DBMS)


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. 


4.2 Planning Sociability


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. 





4.2.1 Purpose


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 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.


4.2.2 People


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.


4.2.3 Policy    


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.


4.3 Summary


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.


5.1 Entity Relationship Modelling (See Figure 27)


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 , 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 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

Six users performed the usability tests that were aged between 23 and 62, the users had to complete forty tasks that covered the role of the league administrator and league participant (see appendix F). Firstly, they were asked to log into the administration area, and complete a number of tasks, such as ‘Add a Club’, ‘Edit a Team’ and ‘Delete a Player’.  Once they had inputted a number of details into the database they were then asked to assume the role of the league participant who seeks information from the league that they had just been creating details for.  This was useful because the user could then see what they had produced when they were acting out the role of the league administrator, thus they gave some interesting feedback on the application.  They were also asked to post a reply and create a new thread in the discussion forum.


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 ( 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:

  1. League administrators may be unwilling to change their method of administering their league; this could be due to:

·         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


  1. League committees being unaware that the community exists
  2. League committees and administrators lack of understanding of how the tool could improve their method of recording information
  3. League committees believing that few league participants would access the website.
  4. To combat such obstacles the aim is to promote the community by:

·         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, 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, Last Accessed 14/01/03, Last Accessed 26/03/03, Last Accessed 03/04/03, Last Accessed 18/04/03, 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, Last Accessed 11/05/03, Last accessed 12/05/03