A Global Web Enablement Framework For Small Charities and Voluntary Sector Organisations

A Global Web Enablement
Framework for Small Charities and

Voluntary Sector Organisations
Tom Robinson
Supervised by
Dr. Rachel J. McCrindle
School of Systems Engineering

The University of Reading, England
A dissertation submitted in partial fulfillment of the requirements of

The University of Reading for the degree of Master of Science in
Engineering and Information Sciences.
Abstract
With more people gaining access to the internet every day, the web enabling of core services
and business processes is becoming essential. There is a great deal of existing research
covering techniques and approaches to web enablement for commercial and public sector
organisations, but very little that is aimed specifically at small charities and voluntary sector
organisations. Numerous studies have shown that charities often lag behind commercial
organisations when it comes to their internet infrastructure and the extent of web enablement.
This dissertation investigates the needs and issues which charities face, in order to define a
number of key web enablement aims and objectives. Some problems are unique to the
charitable sector whilst others apply to all types of organisations.
As most web applications can be accessed from anywhere in the world, globalisation
is an inherent web development issue. A number of the most common issues associated with
globalisation are examined and current best practice solutions suggested.
The Foundations, Fundamentals, Features and Future (F4) Framework is the outcome
of the research into the situation, needs and issues faced by charitable organisations. It offers a
simple but detailed framework designed specially for web enablement projects within
charitable organisations. The framework is broken down into four key stages of web
enablement – foundations, fundamentals, features and future possibility. Through the four
layers, the framework covers key business drivers, internet access and security, error-handling
techniques through to global database access and undeveloped future technologies.
The framework was developed and refined through research and work undertaken with
GAP Activity Projects, a worldwide gap year charity. To demonstrate the implementation of
the framework, GAP is used as a case study. A number of web and related applications are
developed and evaluated including an online application system, mass mailing tools and an
extranet application. The case study demonstrates a number of novel techniques that have
been developed to solve some of the problems which were faced, including the use of XML as
a data storage method and a unique form validation technique.
Although the evaluation of the framework shows that it meets well the objectives it set
out to achieve, there are opportunities for improvement and future work. A number of future
expansions possibilities are examined including the use of mobile technology and content
management systems.
i
A Global Web Enablement Framework Tom Robinson
Table of Contents
Chapter 1. Introduction ......................................................................................................... 1

1.1. Chapter outline ............................................................................................................... 1
1.2. Area of work................................................................................................................... 1
1.2.1. Definition of web enablement............................................................................. 2
1.3. Charities and voluntary sector organisations ................................................................. 3
1.3.1. What is a charity? .............................................................................................. 3
1.3.2. Profitability vs. growth....................................................................................... 4
1.3.3. Trustees and volunteers...................................................................................... 4
1.3.4. Size variance in charities ................................................................................... 4
1.3.5. Financial contribution of charities .................................................................... 5
1.3.6. Why do charities need to be web enabled? ........................................................ 6
1.4. Case study ...................................................................................................................... 6
1.4.1. Knowledge Transfer Partnerships ..................................................................... 6
1.4.2. GAP Activity Projects......................................................................................... 7
1.5. Aims ............................................................................................................................... 8
1.6. Objectives....................................................................................................................... 8
1.7. Key web enablement drivers .......................................................................................... 9
1.7.1. Competitiveness.................................................................................................. 9
1.7.2. Cost cutting ........................................................................................................ 9
1.7.3. Communication with volunteers......................................................................... 9
1.7.4. Globalisation...................................................................................................... 9
1.8. Overview of the remaining chapters ............................................................................ 10
1.8.1. Chapter 2 – Literature review.......................................................................... 10
1.8.2. Chapter 3 – Problems to be solved .................................................................. 10
1.8.3. Chapter 4 – The F4 Pyramid Framework........................................................ 10
1.8.4. Chapter 5 – Case study – GAP Activity Projects ............................................. 10
1.8.5. Chapter 6 – Summary, evaluation & further work........................................... 11
1.9. Chapter conclusions ..................................................................................................... 11
Chapter 2. Literature review............................................................................................... 12

2.1. Chapter outline ............................................................................................................. 12
2.2. Previous research and studies....................................................................................... 12
2.2.1. Giving (in) to the Internet................................................................................. 12
2.2.2. Virtual Promise ................................................................................................ 13
2.2.3. Hall Aitken........................................................................................................ 14
2.2.4. Civic and community technology ..................................................................... 15
2.2.5. Developing the ICT capacity of the voluntary and community sector ............. 15
2.3. Existing models and frameworks ................................................................................. 16
2.3.1. The technology trap.......................................................................................... 16
ii
2.3.2. Application Service Providers (ASPs).............................................................. 17

2.4. Support organisations and websites ............................................................................. 19
2.4.1. Charity IT Resource Alliance (CITRA) ............................................................ 19
2.4.2. London Advice Service Alliance (LASA) Knowledgebase................................ 19
2.4.3. Making the Net Work........................................................................................ 20
2.4.4. IT 4 Communities ............................................................................................. 20
2.5. Globalisation ................................................................................................................ 20
2.5.1. Definitions ........................................................................................................ 21
2.5.2. Planning for multiple localised websites ......................................................... 21
2.5.3. Directing users to the appropriate site ............................................................ 22
2.5.4. Automatic redirection....................................................................................... 23
2.5.5. Language and cultural differences................................................................... 24
2.5.6. International characters and writing systems.................................................. 25
Chapter 3. Problems to be solved........................................................................................ 27

3.1. Chapter outline ............................................................................................................. 27
3.1.1. Similarities between business and charities..................................................... 27
3.2. Communication ............................................................................................................ 28
3.2.1. Email ................................................................................................................ 29
3.2.2. Moving from basic to advanced uses of email ................................................. 29
3.2.3. Sending bulk emails.......................................................................................... 30
3.3. Non-technical issues..................................................................................................... 31
3.3.1. Organisational culture ..................................................................................... 31
3.3.2. Fear of failure .................................................................................................. 31
3.4. Legislative compliance................................................................................................. 32
3.4.1. Data protection ................................................................................................ 32
3.4.2. Disability Discrimination Act........................................................................... 33
3.5. Globalisation ................................................................................................................ 34
3.5.1. Local infrastructure.......................................................................................... 34
3.5.2. Language.......................................................................................................... 34
3.5.3. Culture.............................................................................................................. 35
3.5.4. Design sensitivity.............................................................................................. 35
3.5.5. Legislation and currency.................................................................................. 36
3.6. Infrastructure ................................................................................................................ 36
3.6.1. Variance in technology, infrastructure and security overseas......................... 36
3.6.2. Designing for technical limitations .................................................................. 37
3.6.3. Weight............................................................................................................... 37
Chapter 4. The F4 Pyramid Framework............................................................................ 39
iii
4.1. Chapter outline ............................................................................................................. 39

4.2. The framework ............................................................................................................. 39
4.2.1. Development of the framework ........................................................................ 39
4.2.2. Framework model and framework infrastructure............................................ 39
4.2.3. The layers of the framework model .................................................................. 40
4.2.4. Why a pyramid? ............................................................................................... 41
4.2.5. Content of each layer ....................................................................................... 42
4.2.6. Implementing and using the framework ........................................................... 45
4.3. Foundations (F1) .......................................................................................................... 47
4.3.1. Introduction...................................................................................................... 47
4.3.2. Checklist ........................................................................................................... 47
4.4. Foundation: Internet access.......................................................................................... 49
4.4.1. Connectivity...................................................................................................... 49
4.4.2. Hosting ............................................................................................................. 49
4.5. Foundation: Email ........................................................................................................ 50
4.5.1. Spam ................................................................................................................. 51
4.6. Foundation: Security .................................................................................................... 51
4.6.1. Firewalls........................................................................................................... 52
4.6.2. Anti-virus.......................................................................................................... 52
4.7. Foundation: Software ................................................................................................... 53
4.7.1. Reduced price software .................................................................................... 53
4.8. Foundation: Data storage ............................................................................................. 53
4.8.1. Databases ......................................................................................................... 53
4.8.2. File storage and backup................................................................................... 54
4.9. Foundation: Programming platform............................................................................. 54
4.9.1. Programming environment choices ................................................................. 54
4.9.2. Java 2 Platform, Enterprise Edition (J2EE) .................................................... 55
4.9.3. Microsoft .NET Framework ............................................................................. 55
4.9.4. LAMP ............................................................................................................... 57
4.9.5. Using the Microsoft .NET Framework............................................................. 58
4.9.6. Recommended programming platform features............................................... 58
4.9.7. Object-oriented programming (OOP).............................................................. 58
4.9.8. XML & web service support............................................................................. 59
4.9.9. Intermediate code............................................................................................. 59
4.9.10. .NET managed code ......................................................................................... 60
4.10. Summary of foundations .............................................................................................. 61
4.11. Fundamentals (F2)........................................................................................................ 62
4.12. Fundamental: Industry guidelines and best practice .................................................... 62
4.12.1. Coding style and naming conventions.............................................................. 62
4.12.2. Standards compliance ...................................................................................... 62
4.12.3. Proprietary technology .................................................................................... 62
4.13. Fundamental: Code Library ......................................................................................... 63
4.13.1. Database access ............................................................................................... 63
iv
4.14. Fundamental: Error handling ....................................................................................... 63

4.14.1. Alerting the user ............................................................................................... 64
4.14.2. Alerting support staff........................................................................................ 64
4.15. Fundamental: Membership........................................................................................... 65
4.15.1. Registration ...................................................................................................... 66
4.15.2. Role based security........................................................................................... 66
4.16. Fundamental: Testing................................................................................................... 67
4.16.1. Browser testing................................................................................................. 67
4.16.2. User testing ...................................................................................................... 68
4.17. Fundamental: Documentation ...................................................................................... 68
4.17.1. Wikis ................................................................................................................. 68
4.17.2. Inline source code based documentation ......................................................... 69
4.18. Summary of fundamentals ........................................................................................... 70
4.19. Features (F3) ................................................................................................................ 70
4.19.1. Choosing modules and the order of development ............................................ 71
4.20. Feature: Online community.......................................................................................... 73
4.21. Feature: Sending multiple emails................................................................................. 73
4.21.1. Sending bulk emails.......................................................................................... 73
4.21.2. Centralised email functionality ........................................................................ 74
4.22. Feature: Online forms................................................................................................... 74
4.22.1. Layout and navigation...................................................................................... 75
4.22.2. Validation ......................................................................................................... 75
4.22.3. Server-side and client-side validation.............................................................. 75
4.22.4. Loose validation ............................................................................................... 76
4.22.5. Partially completed forms ................................................................................ 76
4.23. Feature: Extranet .......................................................................................................... 77
4.24. Feature: Global data access .......................................................................................... 77
4.24.1. Consolidating existing databases..................................................................... 77
4.24.2. Web enablement of databases .......................................................................... 77
4.25. Feature: Global file access ........................................................................................... 78
4.26. Summary of features .................................................................................................... 79
4.27. Future (F4).................................................................................................................... 79
4.28. Future: Mobile web enablement................................................................................... 80
4.29. Future: Mobile text messaging..................................................................................... 81
4.29.1. Economic viability............................................................................................ 82
4.30. Future: Content management ....................................................................................... 82
4.31. Summary of future ....................................................................................................... 82
Chapter 5. Case Study – GAP Activity Projects................................................................ 84

5.1. Chapter outline ............................................................................................................. 84
v
5.2. GAP Activity Projects.................................................................................................. 84

5.2.1. Who are GAP Activity Projects........................................................................ 84
5.2.2. Size ................................................................................................................... 85
5.2.3. What do GAP’s IT systems need to support? ................................................... 85
5.2.4. Offices worldwide............................................................................................. 85
5.3. The University of Reading ........................................................................................... 85
5.3.1. Student projects ................................................................................................ 86
5.3.2. Student coursework .......................................................................................... 86
5.4. Implementing the framework ....................................................................................... 87
5.5. Foundations (F1) .......................................................................................................... 88
5.5.1. Email ................................................................................................................ 88
5.5.2. Internet access.................................................................................................. 88
5.5.3. Security............................................................................................................. 88
5.5.4. Software............................................................................................................ 88
5.5.5. Data storage..................................................................................................... 89
5.5.6. Programming platform..................................................................................... 89
5.6. Fundamentals (F2)........................................................................................................ 89
5.7. Fundamental: Membership – myGAP.org ................................................................... 89
5.7.1. Login and authentication ................................................................................. 89
5.7.2. Registration form.............................................................................................. 89
5.8. Fundamental: Industry guidelines and best practice - GAP Website........................... 90
5.8.1. Removal of unnecessary scripting.................................................................... 90
5.9. Fundamental: Documentation ...................................................................................... 91
5.9.1. Wikis for documentation................................................................................... 91
5.9.2. Inline source code documentation.................................................................... 92
5.10. Features (F3) ................................................................................................................ 94
5.11. Feature: Sending multiple emails - GAP Mailer.......................................................... 94
5.12. Feature: Online community - GAP Community .......................................................... 97
5.12.1. Open source and free software......................................................................... 97
5.12.2. Implementation................................................................................................. 97
5.12.3. Integrating separate login and authentication systems.................................... 98
5.12.4. Results .............................................................................................................. 99
5.12.5. Photo galleries ................................................................................................. 99
5.12.6. Customisations ............................................................................................... 100
5.12.7. Overcoming Globalisaton issues.................................................................... 101
5.13. Feature: Online Forms – GAP Online Application System ....................................... 102
5.13.1. Flexible error checking .................................................................................. 102
5.13.2. Automatic saving without user action ............................................................ 103
5.13.3. References ...................................................................................................... 103
5.13.4. Online Application Viewer ............................................................................. 104
5.13.5. XML application forms................................................................................... 107
5.13.6. XPath for data extraction............................................................................... 109
5.13.7. XSLT for data display..................................................................................... 110
vi
5.14. Feature: Extranet – GAP Extranet.............................................................................. 112

5.15. Feature: Global data access – GAP Alumni Update System ..................................... 113
5.15.1. Alumni and the Business Partnership Scheme ............................................... 113
5.15.2. Issues with previous system............................................................................ 114
5.15.3. Key benefits of web enablement ..................................................................... 114
5.15.4. Method............................................................................................................ 114
5.15.5. Security........................................................................................................... 116
5.15.6. Storage format................................................................................................ 116
5.16. Feature: Global data access – GAP Management Information System ..................... 117
5.16.1. Web-based MIS .............................................................................................. 117
5.16.2. System convergence........................................................................................ 117
5.16.3. Legal aspects .................................................................................................. 118
5.17. Feature: Global data access – GAP Project Profiles .................................................. 118
5.18. Feature: Global file access – FTP server.................................................................... 119
5.19. Methods and tools resulting from the case study implementation ............................. 120
5.20. Chapter conclusions ................................................................................................... 121
Chapter 6. Evaluation, further work & summary .......................................................... 123

6.1. Chapter summary ....................................................................................................... 123
6.2. Summary & critique ................................................................................................... 123
6.2.1. Did it meet aims and objectives?.................................................................... 123
6.2.2. What makes the framework unique? .............................................................. 123
6.2.3. Is the framework suitable for a business environment?................................. 123
6.2.4. Benefits demonstrated by the case study ........................................................ 124
6.2.5. Scalability....................................................................................................... 124
6.2.6. Maintainability ............................................................................................... 125
6.2.7. Industry recognition ....................................................................................... 125
6.3. Challenges faced during implementation................................................................... 125
6.3.1. Email address validation................................................................................ 125
6.3.2. Online application system .............................................................................. 126
6.3.3. Automatic application form saving ................................................................ 126
6.3.4. Alumni update system..................................................................................... 126
6.3.5. GAP Mailer .................................................................................................... 127
6.3.6. User registration ............................................................................................ 128
6.4. Future work ................................................................................................................ 128
6.4.1. Globalisation.................................................................................................. 128
6.4.2. Mobile technology .......................................................................................... 129
6.4.3. Refinement and improvement of the model .................................................... 129
6.4.4. Specialisation of the model ............................................................................ 129
6.4.5. Team development.......................................................................................... 129
6.4.6. Exploration of methods and tools................................................................... 129
6.5. Chapter conclusions ................................................................................................... 130
vii
Table of Figures
Figure 1. Percentage of total income for Charities in different income brackets [4] ................. 5
Figure 2. The Technology Trap................................................................................................ 17
Figure 3. International gateway example ................................................................................. 22
Figure 4. Business and charity issues....................................................................................... 27
Figure 5. Data Protection Act 1998.......................................................................................... 32
Figure 6. The F4 Pyramid Framework ..................................................................................... 41
Figure 7. Direction of expansion and progress ........................................................................ 42
Figure 8. Foundations............................................................................................................... 43
Figure 9. Fundamentals ............................................................................................................ 43
Figure 10. Features................................................................................................................... 44
Figure 11. Future ...................................................................................................................... 44
Figure 12. Implementation flowchart....................................................................................... 46
Figure 13. Foundations checklist ............................................................................................. 48
Figure 14. Defence in depth ..................................................................................................... 52
Figure 15. Microsoft .NET Framework ................................................................................... 56
Figure 16. Intermediate code compilation................................................................................ 59
Figure 17. Summary of Foundations........................................................................................ 61
Figure 18. Example of wiki entry history comparison with MediaWiki ................................. 69
Figure 19. Summary of Fundamentals ..................................................................................... 70
Figure 20. Feature Planning Matrix ......................................................................................... 72
Figure 21. Example of an XML email template....................................................................... 74
Figure 22. Summary of Features .............................................................................................. 79
Figure 23. Web browsing on mobile and simple devices ........................................................ 80
Figure 24. Summary of Future ................................................................................................. 83
Figure 25. Mapping between F4 Framework and case study................................................... 87
Figure 26. Problems with proprietary code.............................................................................. 91
Figure 27. GAP's Documentation Wiki ................................................................................... 92
Figure 28. Example inline code documentation....................................................................... 93
Figure 29. Example output from NDoc.................................................................................... 94
Figure 30. GAP Mailer with addresses imported from Excel .................................................. 95
Figure 31. GAP Mailer showing message entry tab................................................................. 96
Figure 32. Using a web service to synchronise different systems ........................................... 99
Figure 33. Example of Community Server gallery image ..................................................... 100
Figure 34. Default Community Server Header ...................................................................... 101
Figure 35. Customised Community Server Header ............................................................... 101
Figure 36. Further visual customisations ............................................................................... 101
Figure 37. Error checking before application submission...................................................... 102
Figure 38. Reminder for applicant to check the page for potential errors ............................. 103
viii
Figure 39. Confirmation that the page validates .................................................................... 103

Figure 40. GAP Online Application Viewer.......................................................................... 105
Figure 41. Example of online application form in viewer ..................................................... 106
Figure 42. Application Form Stages ...................................................................................... 108
Figure 43. Uses for various sections of the application form................................................. 110
Figure 44. Using XSLT for processing online application forms .......................................... 111
Figure 45. GAP Extranet........................................................................................................ 113
Figure 46. FreeTextBox control in action .............................................................................. 119
Figure 47. Benefits for GAP .................................................................................................. 124
Figure 48. Save Now button on online application form ....................................................... 126
ix
Table of Tables
Table 1. Locale codes combing location and language............................................................ 24

Table 2. Examples of world writing systems ........................................................................... 25
Table 3. Basic and advanced email usage ................................................................................ 30
Table 4. Comparison of .NET and J2EE features .................................................................... 58
Table 5. Registration and linking scenarios ........................................................................... 115
Table 6. Account linking scenarios ........................................................................................ 116
Table 7. Methods and tools resulting from the case study implementation........................... 121
x
Chapter 1. Introduction
1.1. Chapter outline
This chapter will introduce the area of work that this dissertation covers and look at the
overall aims and objectives. This chapter will also include an outline of the dissertation
structure and a description of the contents of the remaining chapters. Each chapter in this
dissertation starts with a short introduction explaining the chapter contents and setting the
scene.
1.2. Area of work
This dissertation begins by looking at the reasons why charitable organisations can benefit
from the web enablement of current and future business processes.
While many businesses now use the Internet as a core part of their operations, charities
and smaller organisations can find it more difficult to find the time and resources to
successfully web enable their business processes. Most previous work on web enablement has
concentrated on commercial organisations where funding and resources are less scarce than in
the charitable sector. This dissertation will look at ways in which the web, related Internet
technologies and a suitable IT infrastructure can be of benefit to charities, community
organisations and even small businesses.
After looking at the background and identifying the key problems involved with web
enablement, the dissertation introduces a framework to achieve a structured approach to web
enablement. Following an exploration of the framework as a generic approach to web
enablement there is a case study demonstrating an actual implementation of the framework.
The defining features of a charitable organisation are examined and the management culture
and other issues explored, in order to justify the need for a structured web enablement
framework such as the one described in this dissertation. The framework has been designed
for organisations that have little or no in-house computing expertise, a limited budget and
short timescales. These types of organisation are most likely to need a framework to follow, to
enable them to get the most out of their investments in technology.
Page 1
A case study of the work carried out for an international educational charity is used to
illustrate and provide evidence of the effectiveness of the framework. The charity used for the
case study is GAP Activity Projects (GAP) Ltd1, a non-for-profit charity based in Reading but
with offices worldwide. GAP is the largest gap year organisation for 17-25 year olds in the
United Kingdom.
As the Internet allows almost instant communication to anywhere in the world, there is
additional material focusing on the web enablement of a charities global operations, hence the
title of the dissertation. The Internet is a key tool in allowing a charity to increase its reach to
a global audience but there are a number of complex challenges which must be overcome, in
order for a successful outcome.
The final stages of the dissertation deal with suggestions for further work, outline
some limitations of the framework and finally look at an evaluation of the project, framework
and the example implementation.
The reason for choosing to study web enablement for the charitable and voluntary
sector is that there is a lack of information about web enablement which is specific to the
unique needs and issues of such organisations. Although there is a large amount of research
which applies to the needs of commercial organisations, relatively little is specific to charities
or gives any mention to the unique challenges they may face. There are however a number of
detailed studies into use of the internet and web technology within charities, this is covered in
the literature review.
1.2.1. Definition of web enablement
In order to justify use of the term web enablement rather than e-enablement or Internet
enablement we need to look at what the web is and how it differs from the Internet. Chaffey et
al [1] highlight the key differences between the Internet and the World Wide Web in the
following way:
The Internet
The Internet, refers to the physical network that links computers across the globe. It
consists of the infrastructure of network servers and wide-area communication links
between them that are used to hold and transport vast amount of information on the
Internet.
1
http://www.gap.org.uk/
Page 2
World Wide Web

The World Wide Web is a medium for publishing information on the Internet. It is
accessed through web browsers, which display web pages and can now be used to run
business applications. Company information is stored on web servers, which are usually
referred to as web sites.
In the context of this dissertation, web enablement is defined as the process of

increasing an organisations ability to conduct work and offer services using globally
accessible web applications. The scope of this work also includes related Internet technologies
such as email and the File Transfer Protocol (FTP), so it could more accurately be described
as Internet enabling. The reason for using the term web enablement is that the focus will be
the World Wide Web rather than the many other Internet technologies which are available.
Internet technologies are important complimentary technologies to web enablement and will
be examined where appropriate.
1.3. Charities and voluntary sector organisations
are a number of important differences between the way commercial organisations and
charitable organisations operate. One of the major differences, implied by the fact that most
charities operate as not-for-profit organisations, is the decrease in the importance of
profitability on investments. Although in many cases this is an important difference between
the two types of organisation there are many other differences which can make a difference –
organisational culture, existing infrastructure, lack of an internal IT team and differences in
priority and purpose of the business.
1.3.1. What is a charity?
To be officially recognised as a charity, the organisation must be registered with the Charities
Commission1, a government funded organisation that regulates the charitable sector in
England and Wales. Scottish charities must register with the Office of the Scottish Charity
Regulator2. There are similar systems for regulation in the United States, Australia and
Canada. The Charities Act 1993 [2] is the most recent act detailing the definitions and
structure of UK charities. There are over 190,000 charities registered with the Charities
Commission, employing over 600,000 staff and 900,000 trustees [3].
1
http://www.charity-commission.gov.uk/
2
http://www.oscr.org.uk/
Page 3
1.3.2. Profitability vs. growth
Charities aim to grow and to fulfil a vision or purpose, such as the development of a cure for a
disease, rather than aiming for profit. This is a major contrast to commercial organisations
where profit for shareholders or company owners is usually the main goal.
1.3.3. Trustees and volunteers
Trustees are the people responsible for administration and control of a charity. Depending on
the type and size of the charity this may include the Executive or Management Committee,
Directors or in the case of a charitable trust – Trustees and Governors. Trustees come from a
range of social backgrounds and a variety of age ranges although they must be over 18 and
there are requirements which must be met regarding previous convictions and bankruptcy
status. Trustees are generally unpaid volunteers who take on responsibilities on behalf of the
charity.
Volunteers are an essential resource for many charities. Whilst staff working in the
head office are likely to be salaried, they are often supported by numerous volunteers who
work a variety of hours and participate in a wide range of activities. Many organisations such
as Riding for the Disabled1 have more volunteers than paid employees. Volunteers are a very
unique feature of charitable organisations and must always be taken into consideration when
changing business processes or developing new tools.
1.3.4. Size variance in charities
There are currently over 190,000 registered charities in England and Wales [3]. The majority,
approximately 57%, of these charities have a recorded income of £10,000 or less [4]. Small
charities represent nearly two-thirds of registered charities but make up less than 1% of the
total charity income. The Charity Commission’s 2005 Annual Report [3] states that the largest
500 charities are responsible for over 46% of the total charitable income. The size of charities
varies as much as the size of non-charitable organisations but many of the core characteristics
stay the same. The European Union [5] defines a small enterprise as an organisation with less
than 50 full-time employees and a turnover of less than 7 million Euros.
1
http://www.riding-for-disabled.org.uk/
Page 4
Charities vary in size enormously; the largest non-profit organisation in the United
States is the Bill and Melinda Gates Foundation1, which has an endowment of approximately
$27 billion. At the other end of the scale are small charities for local communities whose
turnover is negligible.
Many charities have wholly owned subsidiary organisations that operate as separate
legal entities and can make a profit, as long as the profit is donated to the parent organisation.
One of the largest charitable trusts in the UK, The Wellcome Trust2 has established a wholly
owned trading subsidiary, Wellcome Trust Trading Limited, to handle non-charitable trading
at the Wellcome Trust Conference Centre. GAP Activity Projects (GAP) Ltd. also has a
similar subsidiary called GAP Activity Projects (Enterprises) Ltd. The operation of a separate
legal entity removes some of the restrictions which a strictly charitable organisation must
comply with and allows a charity to fundraise by selling merchandise or renting facilities.
1.3.5. Financial contribution of charities
Non-profit organisations are growing rapidly in the UK and currently accounting for
approximately 8% of the gross domestic product (GDP). The non-financial benefits that
charities contribute to society are even greater and cannot easily be measured on a financial
scale. Charities are legally obliged to submit their accounts and annual returns to the Charities
Commission [3].
£1,001 - £10,000
£10,001 - £100,000
£0 - £1,000 £100,001 - £250,000

£250,000 - £1m
£1m - £10m
Figure 1. Percentage of total income for Charities in different income brackets [4]
(Source: Charity Commission)
1
http://www.gatesfoundation.org/
2
http://www.wellcome.ac.uk/
Page 5
The chart above illustrates the importance of small charities with regard to the total
charitable income. With 86% of total income for charities coming from organisations with an
income of less than £100,000 the importance of small charities is significant.
1.3.6. Why do charities need to be web enabled?
Web enablement can bring a number of benefits to small organisations, some of which would
be prohibitively expensive using traditional forms of communication. Publicity materials can
be sent around the world at a greatly reduced costs, and the organisation’s message can be
globally available to anyone with internet access. An organisation may also be able to make
gains in terms of the efficiency and speed of their operations. As the resources of small
charities are limited, it is important that they are able to make the most of these opportunities.
1.4. Case study
1.4.1. Knowledge Transfer Partnerships
Knowledge Transfer Partnerships (KTP)1 are a Department of Trade & Industry (DTI)2
sponsored scheme to encourage and support the transfer of knowledge between academic
institutions and companies. A committee comprising academic staff, staff at the company and
Knowledge Transfer Partnership support staff, manages each partnership. The partnership
involves the employment of one or more graduates who work at the company on a fixed term
contract, with the support of the knowledge base partner. The government sponsors the
scheme by contributing up to 60% of the total programme cost. Grants includes the graduate
salary, academic support and budgets for equipment, personal training & development and
travel & subsistence.
For all organisations, and especially charities who might not otherwise be able to
afford it, a KTP scheme can be of great benefit. It allows for the employment and support of a
new employee at a significantly reduced cost. GAP Activity Projects is currently working
with The University of Reading as part of a Knowledge Transfer Partnership. GAP chose to
embark on a KTP scheme for the web enablement of its key business processes and for
greater use of IT generally. This dissertation is a result of a combination of research and work
carried out with GAP.
1
http://www.ktponline.org.uk/
2
http://www.dti.gov.uk/
Page 6
1.4.2. GAP Activity Projects
GAP offers an interesting case study as it is a large and well-established organisation with a
number of interesting organisational features, making it possible to examine the impact of
web enablement in a number of areas.
GAP has a variety of offices and partnerships worldwide. The main office is based in
the United Kingdom and employs around 30 full-time staff. Other offices are smaller, with
GAP Australia having around eight full-time staff whilst other smaller offices have as few as
one person working full-time. GAP also works in partnership with YouLead1 in Canada who
perform similar functions to the other overseas offices but are not owned or directly
controlled by GAP.
Large numbers of volunteer staff, both in the United Kingdom and overseas, are an
essential part of GAP’s operations. There are well over a 100 volunteer staff actively working
for GAP and there are many opportunities to allow them to become more involved through
web enablement. The range of ages, IT skills, locations and access to infrastructure of GAP’s
volunteers brings a number of unique challenges and complexities.
Prior to the implementation of the work detailed in the case study, GAP only had one
full-time member of staff who dealt with IT matters. This support was limited to day-to-day
maintenance of the infrastructure, and all development work or creation of new systems was
outsourced to a consultant at a significant cost. The most significant product created by
external consultancy was GAP’s ‘Core’ database, which stores and manages the majority of
GAP’s operational data. This was completed shortly before the web enablement process
began.
The basic IT infrastructure required for the framework to be implemented was not as
good as it could have been to start with, however, GAP has had a broadband Internet
connection, fairly modern PCs for each member of staff, an internal network, a large website
and a comprehensive central database for some time.
1
http://www.youlead.org/
Page 7
1.5. Aims
The main aims of the research and this dissertation are to:
1. Demonstrate the importance of web enablement in the charitable sector.
2. Examine the current state of the art.
3. Develop a generic framework to support and guide web enablement of charitable sector
organisations.
4. Show how the framework can be applied.
5. Discuss the effectiveness of the framework and ideas for expansion and improvement.
1.6. Objectives
The wider aims are to be achieved by completing the following objectives:
1. Give background information regarding charities and voluntary sector organisations, web
enablement and globalisation.
2. Compare and contrast charitable and commercial organisations so that key differences can
be highlighted and business drivers identified.
3. Outline the problems which a charity may face when dealing with web enablement.
4. Look at existing research which is relevant to the subject area.
5. Highlight the key problems to be solved, both technical and non-technical.
6. Develop a framework which deals with all areas of web enablement, from the
infrastructure through to future possibilities.
7. Demonstrate an implementation of the framework by use of a case study.
8. Evaluate the framework using the lessons learnt from case study and make suggestions for
resolving any issues or limitations.
9. Offer suggestions for further work to expand the framework.
Page 8
1.7. Key web enablement drivers
All voluntary sector organisations have a number of key business drivers which must be taken
into account when developing a web enablement strategy.
1.7.1. Competitiveness
Charities often compete against commercial organisations in the market place. Smaller
organisations also compete against larger charities with bigger spending budgets. Although
not all charities are a competitive market, those that are need to be able to keep up with other
organisations in their market area. Web enablement is an area where larger and commercial
organisations tend to be ahead of smaller organisations that have more limited resources.
1.7.2. Cost cutting
Charities are always looking for ways of keeping costs down. Traditional methods of
communication and advertising are expensive to produce and physical items cannot reach a
worldwide audience. By using the web as a marketing and communication tool, costs can be
kept down and new markets can be reached. Rather than posting documents, charities can use
email and websites to distribute material to almost anywhere in the world at a very low cost
per transaction.
1.7.3. Communication with volunteers
Many charities rely on volunteers to perform key tasks. As voluntary staff, they are likely to
be part-time, often retired and may not work in the charity’s office or even in the same
country. The web can be a useful tool for communicating with voluntary staff and integrating
them into the core of the organisation.
1.7.4. Globalisation
Many charities are either globalising their operations or looking to do so. This brings a
completely new set of challenges which the organisation must face. Globalisation also brings
many opportunities for growth and the ability to spread an organisation’s message overseas.
By harnessing the power and abilities of the World Wide Web, a charity can expand its reach
at a very low cost, provided that the technical and cultural aspects are taken into account.
Page 9
1.8. Overview of the remaining chapters
1.8.1. Chapter 2 – Literature review
This chapter looks at the work of other researchers in the areas covered by this dissertation.
There is a look at previous research and studies which have been conducted within the
charitable sector. Coverage of existing frameworks is limited, as most past work has been
aimed at commercial organisations and not charities. Charities usually have very different
aims and objectives and the methods they use must allow for this. The ability of a web
application to be globally accessible is essential for many organisations, even small
organisations that do not have any staff or volunteers overseas. As the issues surrounding
globalisation have been around since the birth of the Internet, there is a great deal of existing
work in this area. This chapter also looks at some of the key technical issues and the solutions
which are appropriate for the type of web applications discussed elsewhere in this
dissertation.
1.8.2. Chapter 3 – Problems to be solved
This chapter looks at the web enablement challenges facing charities and voluntary sector
organisations. Some of these problems are unique to charities whereas others apply to any
small organisation, particularly those with little in-house computing expertise and limited
funds.
1.8.3. Chapter 4 – The F4 Pyramid Framework
This chapter outlines a generic framework for web development, designed primarily for
charitable organisations, but also suitable for many small businesses. The framework uses a
modular approach to web enablement and covers suitable approaches and techniques for web
enablement of a number of key business areas.
1.8.4. Chapter 5 – Case study – GAP Activity Projects
This chapter introduces GAP Activity Projects, the case study being used to demonstrate the
ideas developed in the framework. It then goes on to describe how the framework has been
used successfully in projects at GAP. GAP is a non-for-profit charity which helps organise
gap year placements for 17-25 year olds. The main office employs approximately 30 staff and
there are a number of regional offices around the world. As well as paid staff, GAP also has
Page 10
nearly 200 members of volunteer staff. The complexity, size and distribution of GAP as an
organisation makes it an interesting case study for the framework.
1.8.5. Chapter 6 – Summary, evaluation & further work
In this chapter, the framework as well as examples if its use and implementation will be
evaluated. The starting point for the evaluation is the challenges faced during implementation.
This leads to an evaluation of the effectiveness of the framework itself and a discussion of
ideas for further work, expansion and refinement.
1.9. Chapter conclusions
This chapter has introduced charities and voluntary sector organisations and has highlighted
some of the unique features that differentiate them from commercial businesses. With the
exception of communication with volunteers, charities have similar web enablement drivers to
many small businesses. The aims and objectives have been outlined and these are to be the
basis for the remaining chapters.
Page 11
Chapter 2. Literature review
This chapter looks at the work of other researchers in the areas covered by this dissertation.
There is a look at previous research and studies which have been conducted within the
charitable sector. Coverage of existing frameworks is limited, as most past work has been
aimed at commercial organisations and not charities. Charities usually have very different
aims and objectives and the methods they use must allow for this. The ability of a web
application to be globally accessible is essential for many organisations, even small
organisations that do not have any staff or volunteers overseas. As the issues surrounding
globalisation have been around since the birth of the Internet, there is a great deal of existing
work in this area. This chapter also looks at some of the key technical issues and the solutions
which are appropriate for the type of web applications discussed elsewhere in this
dissertation.
2.2. Previous research and studies
There have been a number of studies and reports on Internet and Information Communication
Technology (ICT) use within charities and voluntary sector organisations. The majority of
these studies are based on surveys. A selection of the most significant and appropriate studies
are detailed in this section.
2.2.1. Giving (in) to the Internet
The results of Goatman’s 2004 [6] e-communications survey revealed that larger charities
tended to be more positive about the potential impact of their website. They perceived the
costs and barriers to entry to be lower than smaller charities did. They were positive about the
potential of their website and the possibilities for extension and improvement. The majority of
those surveyed used email both internally and externally, however half of those wanted to be
able to use email more, particularly as a way of spreading information. Again, larger charities
with a bigger fundraising income were more positive than those in lower income brackets.
Across all sectors surveyed, there was a concern that email could become prone to
being caught by spam filters. Intranets and extranets were found to be in use by some
Page 12
organisations although they tended to be used as internal tools, rather than reaching out to
other stakeholders. Goatman concludes that there is a wide variety of engagement with web
and email technologies but that the majority of organisations see it as having a positive future
and are anticipating making improvements in the future.
2.2.2. Virtual Promise
The latest Virtual Promise report [7] contains the results of annual surveys of charities’ use of
the Internet between 2000 and 2004. Because Virtual Promise is an annual survey, the report
is useful in demonstrating trends in terms of the speed and direction of change. The ability to
compare results with previous years distinguishes it from one-off surveys, which give less
indication of trends.
The survey found that 78% of charities now have a budget dedicated to their website,
an increase from the previous year’s 65%. This demonstrates that more charities are realising
the importance of setting aside resources for web enablement. To back this finding up, it was
also found that the number of staff employed full-time in Internet-based roles had increased.
The majority of respondents had the following features as standard features of their websites –
information, links, news, downloadable files, an email enquiry services and job vacancies.
Whilst this shows good progress, it is still static content. Whilst static content is useful and
will always be necessary, a website can be improved by having dynamic content such as
events calendars that respond to the current date and news pages which are driven by an easily
updatable database back-end.
Worryingly only half of the responding organisations had websites that conformed to
the accessibility guidelines [8] of the W3C1. There is clearly a lot of work to be done in
ensuring accessibility to website content. 64% of charities were found to be using content
management systems; this is an encouragingly high percentage for a relatively new way of
managing website content.
1
http://www.w3.org/
Page 13
An extract from the conclusion of the report, which is applicable to the purpose of this
dissertation, is quoted below.
Charities have entered a second phase regarding the Internet, moving from asking
“should we have a website?” to “now that we have a website, how can we make it
better?”
2.2.3. Hall Aitken
In 2001 a comprehensive report titled E-enabling the Voluntary and Community Sectors was
prepared by Jeremy Wyatt [9] for Hall Aitken1 under commission from the Active
Communities Unit, the Department for Education and Skills and the Office of the E-Envoy.
The aims of the study were to assist with government policy development for ICT and related
matters within the voluntary and community sectors. The study comprised of a telephone
survey of 1,400 organisations as well as follow-up email surveys, focus groups, interviews,
desk research and informal discussion. Although the report is now around 4 years old it was
arguably the first large scale survey of ICT use in the sector.
The study found that organisations could improve the effectiveness of their services by
using the Internet as a delivery tool but found that the organisation needed to be suitably ICT
enabled in order to do so. Whilst most organisations were using basic ICT functions such as
word processing and email, only a few were found to be using more advanced functions such
as web based donations, online recruitment and acceptance of electronic payments.
There were concerning findings regarding the ICT infrastructure of many

organisations; the worst being that 60% of organisations with 25 to 49 employees had less
than nine computers between them. The number of organisations with an Internet connection
was found to be significantly lower at 78% compared to 94% of commerical businesses. In
general, the voluntary sector was found to be behind business in a number of key areas.
Businesses were significantly in the lead when it came to having a website, the speed of
Internet connections and the use of an intranet. This lack of infrastructure was found to affect
an organisation’s ability to take advantage of web technologies leaving the voluntary sector
behind when it comes to online promotion and online recruitment. The study followed up
1
http://www.hallaitken.co.uk/
Page 14
these findings with interviews which revealed that a lack of funds and limited knowledge
amongst some senior staff were the main causes of the lack of a suitable infrastructure.
2.2.4. Civic and community technology
Wilcox and Pearl [10] discuss what they term ‘civic and community’ use of the Internet. They
outline a number of uses for the Internet and web technology, particularly by government and
non-profits, and look at the success of projects in previous years, enabling them to identify the
common problems which emerge. They later cite Adrian Hancock of the Improvement and
Development Agency (IDEA) as stating that there are two key attributes which are needed for
successful use of technology – skills and finance. He warns that there is more to planning an
IT strategy than the initial phase and that there should be resources available to allow the
project to develop further, otherwise a project may not reach its full potential.
An interesting point made in the article is that even when a system is web enabled,
there may be some cases where the previous system needs to still be available. Even with the
large number of people who can access the Internet at home or work there may still be others
who are unable to, for one reason or another. So that these customers, donors or volunteers are
not ignored, they must be able to access services by alternative methods. If this is not
carefully considered when developing a web application, then it is likely to be problematic
later on. Even ‘online’ businesses like Amazon still have a postal address, fax and phone
number although it is not needed, advertised or made visible to most people.
According to the Wilcox and Pearl [10], one of the main lessons to be learnt from
previous projects is that there is a major skills shortage in the sector and therefore a
requirement for adequate and structured training for all staff, not just those that are developing
systems. In addition, many projects are not carefully planned or are unsuitable for the
organisation’s current internal state which can cause them to be less successful than they
could be or even to fail.
2.2.5. Developing the ICT capacity of the voluntary and community sector
The National Council for Voluntary Organisation’s (NVCO1) report [9] to the Active
Community Unit (ACU) of the Home Office contains the results of market research carried
out by independent consultants amongst the NCVO’s 2,500 members and 500 non-member
1
http://www.ncvo-vol.org.uk/
Page 15
organisations. They found that although 61% or organisations had Internet access, some
organisations were far more restricted. It was found that 14% of organisations only had a
single point of Internet access and 22% only had access for key staff. This demonstrates that
some organisations neglected or were unable to fund a network infrastructure to support their
Internet connection. Web enablement requires organisation wide internet access, not just
access for key staff or a single terminal.
An area neglected from many reports but covered by the NVCO is the need for risk
management. They state that whilst benefits of ICT can be very positive they can also bring
associated risks. There are a number of risks which any new way of working brings, but the
areas which are of particular concern in ICT projects are security, privacy, intellectual
property, transparency and compliance with legislation. These issues could be the reason why
some organisations are cautious about web enablement of their processes, and often with good
reason. A further conclusion, and one shared by other reports, is that there is a lack of
understanding and knowledge at management and trustee level of the relevance and benefit of
ICT and the Internet.
2.3. Existing models and frameworks
2.3.1. The technology trap
Wilcox and Grunwald [11] use the matrix in Figure 2 to explain what they call “The
Technology Trap”. They explain that in order for an organisation to make a change, such as
successful web enablement, there needs to be change in at least two dimensions of the matrix.
Page 16
Figure 2. The Technology Trap

(Source: D. Wilcox and T. Grunwald [11])
The goal is to move from “Old, Old” (1) ways of working to “New, New” (4) ways of
working. The two traps which may be fallen into, are to introduce new technology without the
organisational approach being changed (3) or changing the way the organisation works, but
not having the technological infrastructure to back it up (2).
2.3.2. Application Service Providers (ASPs)
Application Service Providers are businesses that offer services, generally via the Internet,
which customers can access remotely. The business model behind ASPs1 is to provide a
service which is complex or expensive to set up but which many organisations would find
useful. The service provider then sells access to this service for a small amount, but to a large
number of customers, and is therefore able to profit from the revenue generated and cover
their initial investment. There are many different ASPs available and they can range from
email providers to remote application providers to processor time on super computers.
For charities without the resources to have complex or expensive systems in-house, an
ASP can provide very useful services at a good price. ASP resources are usually paid for on a
1
It should be noted that the term Application Service Provider (ASP) is unrelated to the term Active Server Page
(e.g. ASP and ASP.NET) which is a development technology not a concept.
Page 17
pay-as-you-go basis. There is no need for a specialised infrastructure as most services are
accessible using the Hypertext Transfer Protocol (HTTP) as web pages, or Extensible Markup
Language (XML) web services.
When it comes to looking at the issues with ASPs, one of the main problems is that
there is limited scope for customisation of the service. For many customers, this is not a
problem but there may be times when the only way to get the required service is to develop
and manage it in-house. ASPs work best with services that can be used by a large number of
different organisations but which would be too expensive or difficult to be provided and
managed internally. Services that are bandwidth intensive are not always suitable for
provision as an ASP either, unless there is a suitably fast connection between the provider and
the consumer.
An example of an ASP, which fits the model very well, is a service for looking up
address details given a postcode. This is a good service for an ASP to provide as it is useful to
a large number of organisations, the bandwidth required for each transaction is low and it
would be very expensive for a small organisation to buy and manage its own postcode
database. By subscribing to an ASP such as this, a charity could dramatically reduce the time
it takes for a visitor to fill in a literature request form online. ASPs allow the organisation to
use a complex system to improve the user experience but with very little in-house expertise
other than the initial set up and linking to the ASP.
Whilst postcode lookup is a relatively basic service, there is no limit to the potential
complexity of an ASP. A more complex example is one of the many services which provide
online survey systems. These ASPs allow organisations to design and publish questionnaires
and then make the results accessible online. There is no need for the consumer organisation to
have its own website to take advantage of the system. To develop a similar system in-house
would require many resources and the total cost of ownership could be higher, especially for
smaller organisations. Larger organisations may prefer their surveys to be managed in-house
but for smaller charitable organisations, that may be a luxury which they cannot afford.
A useful guide produced by CompassPoint Nonprofit Services [12] contains a detailed

directory of ASPs which provide services either specifically for the charitable and non-profit
sector or for any type of organisation. Some examples include remote donor database
Page 18
packages, workgroup collaboration systems, event management, questionnaire providers,

payment providers and volunteer matching systems.
2.4. Support organisations and websites
There are a growing number of organisations that offer help and resources tailored for
charities and other voluntary sector organisations. Some offer commercial consultancy
services as well as free advice while others such as the Charity IT Resource Alliance
(CITRA)1 are founded by a group of collaborating organisations. There are too many
potentially useful organisations and websites to list them all but the selection below gives an
indication of the variety of help available and is a good starting point for a more in depth
investigation, based on an individual organisations needs.
2.4.1. Charity IT Resource Alliance (CITRA)
CITRA is a collaborative technology alliance formed by eight charity sector bodies – the
Institute of Fundraising2, Charity Consortium of IT Directors Group (CCitDG)3, Charity
Technology Trust (CTT)4, The Association of Charitable Foundations (ACF)5, Charity
Logistics6, smartchange7, and Community Network8. Its aims are to help improve access to
relevant and trusted IT information, people and resources and through the collaborative
alliance has a combined membership of over 40,000 individuals and organisations. The
CITRA website contains forums, white papers, polls, surveys, resources and event
information.
2.4.2. London Advice Service Alliance (LASA) Knowledgebase
LASA9 is a development and resource agency for advice and information providers. The aims
of the organisation are to make good advice available to all those who need it and to promote
the development of high quality information and advice services. Whilst the scope of their
1
http://www.citra.org.uk/
2
http://www.institute-of-fundraising.org.uk/
3
http://www.cfdg.org.uk/
4
http://www.ctt.org/
5
http://www.acf.org.uk/
6
http://www.charitylogistics.org/
7
http://www.smartchange.org/
8
http://www.community-network.org/
9
http://www.lasa.org.uk/
Page 19
work covers more than just IT, the Information Systems Knowledgebase gives good advice on
many subject areas including accessibility, buying equipment, databases, Internet and web
development, IT management, project management, software and troubleshooting.
2.4.3. Making the Net Work
Making the Net Work is a website which provides guidance for organisations, individuals and
communities who are looking to improve or set up their online presence. The Department of
Trade and Industry (DTI) funded the first project that the founders were set and later projects
have been funded by the Department for Education and Employment (DfEE)1. The site
contains a great deal of information and is especially suitable for charitable organisations
looking into web enablement as it has an extensive set of links to other useful online
resources.
2.4.4. IT 4 Communities
IT 4 Communities2 allows IT professionals to volunteer their services to community and

charitable organisations. It is supported by a partnership of organisations including the British
Computer Society (BCS)3, the Worshipful Company of Information Technologists (WCIT)4
and the industry publication, Computer Weekly5. The partnership aims to increase the number
of IT professionals volunteering in local communities and to make sure that the input they
provide is effective. For charities which cannot afford their own IT staff or the often high
costs of consultants, this, and other similar services, can be of great benefit.
2.5. Globalisation
The ability of a web application to be globally accessible is essential for many organisations,
even small organisations that do not have any staff or volunteers overseas. As the issues
surrounding globalisation have been around since the birth of the Internet, there is a great deal
of existing work in this area. This section looks at some of the key technical issues and the
1
http://www.dfes.gov.uk/ (formerly Department for Education & Employment)
2
http://www.it4communities.org.uk/
3
http://www.bcs.org/
4
http://www.wcit.org.uk/
5
www.computerweekly.co.uk/
Page 20
solutions which are appropriate for the type of web applications discussed elsewhere in this
dissertation.
2.5.1. Definitions
Internationalisation (i18n) is the process of design or modification of a software project so

that it can be later localised. With web projects, this is often done by separating the content
from the design so that localised variations can be made without major rewrites and
modifications of the design. The aim is to produce software that is free of any dependency on
language, culture, script, and coded character sets.
Localisation (l10n) is the process of converting a, preferably internationalised,

application so that it is suitable for another language, culture or location. This often includes
rewriting content and navigation into the target language, but sometimes involves more
complex changes such as handling special character encoding methods. If the original
application has not been internationalised first then the localisation may prove more difficult.
Localisable products separate data from code, correctly display the target language and
function properly after being localised.
Globalisation is often used to as an alternative description for internationalisation.

Globalised software is written to change the locale-specific information it uses to process data
and display information to the user based on the configured locale of the operating system, or
the personal preference of the user.
2.5.2. Planning for multiple localised websites
It is important to think about the long-term plans for the website structure, even if there are
currently no plans to have localised sites.
Country Coded Top Level Domains (ccTLDs) are the approach taken by Google and
many other companies. Each localised website is hosted at the root of its own dedicated
domain. This approach works well if the domain name is available for each of the required
localised regions. A limitation of this approach is that in some cases there may need to be
further subdivision for multiple languages. Google uses the ISO language code on the end of
the domain to resolve this complication. For example, the URL of Google Switzerland in
French is:
Page 21
http://www.google.ch/fr
Where it is not practical to obtain a ccTLD for each localised site, a common approach is to
obtain a generic Top-Level Domain (gTLD) such as ibm.com and then use sub domains for
each localised site. Wikipedia is a well-known example of this. The example below is for the
International English version of Wikipedia.
http://en.wikipedia.org/
Directory based is another common technique used by a number of sites. It is similar to the
sub domain approach, but the localised site is referenced as a directory, rather than a sub
domain, as used by IBM UK:
http://www.ibm.com/uk
2.5.3. Directing users to the appropriate site
Many sites use an international gateway page to direct users to the most suitable localised site.
The most difficult part of this is often that it needs to cater for visitors from many cultures and
languages so has to be as clear as possible, whilst also maintaining a corporate look and feel.
There are two routes which can be taken to reach a gateway page.
The first approach is direct access, so that the gateway page is held at the root of the
site. This means that when the main site URL is entered, e.g. ford.com then the first page to
appear will be the gateway page. The second option is to have a link to the gateway page
somewhere on the site’s front page. This works well where the localised sites have their own
domain names and visitors are less likely to come across the incorrect site for them. For
example, www.microsoft.co.uk goes straight to the Microsoft UK site, as it is presumed that
any visitors who have used that domain name will be visiting from the UK.
Figure 3. International gateway example

(Source: Wikipedia)
Page 22
2.5.4. Automatic redirection
To automatically redirect a user you must determine the location of the user and the language
they prefer to use. The Internet Protocol (IP) address of a visitor can be determined with each
request that a visitor makes. Geolocation software can use this information to determine the
geographical location of a visitor by comparing it with databases of the IP address ranges and
their location. Additionally the IP address can be matched against other similar IP addresses
where the physical location is known.
Unlike Internet servers, which are relatively static, home users with dialup connections
are often assigned different IP addresses and hostnames each time a new connection is
initiated. In this case the location can be hard to determine as it’s likely to change regularly,
depending on where the dialup user is. The naming conventions used by some ISPs includes
information which can be used to help determine location, for example:
Modem-226.ca.us.dal.net
With the example hostname above, geolocation software can take a good guess that
the user is connected with DALnet in California, USA and is on a dialup modem.
When a web browser makes a request for a page, the HTTP header can contain data
about the preferred language of the browsers user. This is normally based on the language
settings of the operating system, but it can be altered in the browsers settings. For example,
the header may contain:
Accept-Language: cy, en-gb;q=0.8, en;q=0.7
Which means the user would prefer to retrieve a Welsh (cy) version of the page but
will accept British English (en-gb) and other types of English if Welsh is unavailable. The
variable q gives each language a quality factor, i.e. weighting between 0 and 1, where any
value over 0 is acceptable. In this example, British English (en-gb) is given a higher
preference to International English (en).
Page 23
2.5.5. Language and cultural differences
The localisation of a web application requires more than just direct translation. There are
many differences in local culture which need to be reflected in a localised web application.
For example, in Germany it is seen to be unprofessional to use lowercase text for titles and
site logos whereas in other countries this is often done to give the site a more youthful image
or to show informality.
A technical problem, which is caused by the complexities of location, culture and

language, is representing all the possible combinations. If a web application is to be localised
for different languages, cultures and locations then there needs to be a way or representing
these. The approach taken in many applications is to combine the ISO1 language code and
ISO country code, in the hope that this will be enough to distinguish between different
cultures. These combinations are often referred to as the locale – a combination of language
and location.
Code Language (Location)
en-UK English (United Kingdom)
en-US English (United States)
fr-CA French (Canada)
Fr-FR French (France)

Table 1. Locale codes combing location and language
If the location is not relevant, then language code on its own can be used. This is often
the case with scientific or academic websites where slight regional variations do not matter, so
there is no need to assign a specific country code. The problem with this approach is when
there is a need to distinguish between two different cultures where the language and location
are the same; a further level of specification is required.
1
International Organization for Standardization (http://www.iso.org/)
Page 24
2.5.6. International characters and writing systems
There are many hundreds of languages which require special characters, accents and
completely different language structures and writing systems to English. Some examples of
this are show in Table 2. Although some languages share similarities, such as English and
French, both are derived from Latin, other languages are completely undecipherable without
being learnt from the ground up.
Type Language Example1
Phonetic English/Latin
(Alphabetic)
Characters represent vowels or consonants, left-to-
right.
Phonetic Arabic
(Alphabetic) (right-to-left)
Characters represent vowels or consonants, right-to-
left.
Phonetic Russian/Cyrillic
(Alphabetic)
Characters represent vowels or consonants, left-to-
right.
Phonetic Tagalog
(Syllabic) (Philippines) Characters represent combinations of consonants

and/or vowels, each called a syllabary.
Ideographic Chinese
Thousands of ideographs used to communicate

meaning, traditionally written top-to-bottom but
nowadays left-to-right is commonly used.
Table 2. Examples of world writing systems
1
“Design will save the world” and translations sourced from http://www.artlebedev.com/studio/slogan/
Page 25
Existing research and studies show that there is a clear need within the voluntary sector for
improved IT infrastructure and an increase in web enablement. The previous research and
studies carried out support this by highlighting the technology gap between commercial
organisations and charities. Although an existing web development framework for charities
could not be found, there are many support groups and communities which aim to help IT
development within the charitable sector. These can be valuable resources and worth
investigating at all stages of a web enablement programme. In terms of globalisation issues,
most of the solutions which are applied to businesses are equally applicable to charitable
organisations.
Page 26
Chapter 3. Problems to be solved
This chapter looks at the web enablement challenges facing charities and voluntary sector
organisations. Some of these problems are unique to charities whereas others apply to any
small organisation, particularly those with little in-house computing expertise and limited
funds.
3.1.1. Similarities between business and charities
Many of the issues and problems to be solved apply to both businesses and charities. There
are also issues which only apply to businesses or only apply to charities. The diagram below
illustrates this and shows that there is a large overlap between business and charity issues
when it comes to web enablement. These differences are explained and explored further in
this chapter. When researching and developing the framework, the primary target organisation
type was small charities but many aspects of the framework are also suited to commercial
organisations.
Figure 4. Business and charity issues
Page 27
Due to the way they are funded, charities and non-profits tend to be more financially
sensitive than businesses. They are often referred to as ‘mission-based’ because their aims are
to fulfill an aim or mission, rather than to make purely monetary gains. Selby [13] states that
it is important to recognise that commercial and non-commercial organisations have their
differences, even though they can also be considered similar in many respects.
3.2. Communication
Communication is the passing on of ideas and information. In business, it is essential to have

good clear channels of communication. Communication in an organisation where there are a
large number of people who need to be contacted and a small staff to handle communications
can be helped a great deal by a good web enablement strategy. Traditionally organisations
would communicate either face-to-face, over the telephone or by letter. This list of potential
communication medium was later expanded to include faxes and then email.
A charity will want to be able to communicate with a variety of people and the more it
can use email or other electronic systems to do this, the more it can cut postage and phone call
costs. There are five main groups of people which a charity will want to communicate with:
1. Internal staff including other offices and branches.
2. External staff, e.g. volunteers.
3. Existing customers and/or donors.
4. Potential customers and/or donors.
5. Suppliers and other business-to-business (B2B) communication.
All of these communication recipients can be contacted using email or other Internet-
based communication streams. Email should not necessarily be the only communication
method as there are many cases where contact that is more personal is needed or where a
recipient does not have access to email.
Page 28
3.2.1. Email
There are few modern organisations that do not have email access to some degree but research
has shown (see Chapter 2) that not all of them will be fully utilising email as a
communication method.
Email can be described as an active communication method, as messages are sent at a

given time and the content is often only valid for a certain time after the email has been sent.
An example of this would be an email asking team members to read a draft proposal before it
is sent to a higher-level manager. Whilst many organisations are able to reach a large passive
audience, email is one of the cheapest and simplest ways of actively communicating to a large
audience.
3.2.2. Moving from basic to advanced uses of email
The table below compares some of the basic and advanced use of email.
Basic tasks
Sending email
As one of the most basic tasks, sending a basic email includes the entry of a recipient,
subject and message body.
Receiving email
This is the process of accessing and reading new emails but to be effective it should
also include the ability to check for emails regularly and to have emails sent to
individuals rather than the organisation as a whole.
Using attachments
Attachments are a useful extension to standard text emails although care must be taken
to keep the size of attachments to a minimum and to ensure that attachments are not
potential security risks.
Sending multiple emails using CC or BCC fields

This is the most basic method of sending emails to multiple recipients. The main
disadvantage is that using the CC field reveals the recipient list to all recipients. Using
the BCC field keeps the list private but makes it more likely that the message may be
mistakenly marked as spam.
Page 29
Advanced tasks
Sending multiple personalised emails

This is where multiple emails are sent but with small customisations depending on the
recipient. It also reduces the chance of a message being mistakenly marked as spam as
each email is sent to a single recipient.
Sending HTML formatted emails and newsletters

Sending any email with HTML must be done with caution to ensure that all recipients
can view the contents. As long as HTML emails are properly prepared and used for
appropriate purposes they can be a useful communication tool.
Sending automated emails based on events

Automated emails sent by systems and applications can be useful for notifying the
recipient of an error or an action that must be taken due to an event.
Allowing automated subscriptions to mailing lists

Rather than having somebody manually adding and removing recipients from a mailing
list, it is very useful to have a tool which allows the users to do this without any action
from staff.
Receiving, parsing and recording email contents

It is possible to machine read the contents of an email and to take action based on the
content. Spam and virus filters read email contents to decide whether to block messages
or not. An email address set up to receive messages formatted in a certain way can be
set up to extract data and to store it in a database, perhaps then deleting the email if it’s
no longer needed.
Email redirection or filing based on contents

An automated system can be used to send enquiry emails to the appropriate person
depending on the keywords found in the email.
Table 3. Basic and advanced email usage
3.2.3. Sending bulk emails
The results of Goatman’s study [6] showed that there were concerns across all sizes and types
of organisation that external emails may be regarded as junk mail and blocked by spam filters.
Page 30
As email becomes more important to an e-enabled business, it is important to be able to send

large numbers of emails without them being blocked before they reach the recipients.
3.3. Non-technical issues
3.3.1. Organisational culture
If an organisation has staff that are inexperienced with modern technology, particularly
Internet and computing skills, then this can be a major issue in IT development. Wyatt [9]
discovered that middle aged and older people were often reluctant to use ICT. As well as a
lack of skills, some staff may be reluctant to change the way they do their job, particularly if
they have been used to completing their work successfully without the help of computer
technology. In this case they may see change either as a threat to the way they work or even
as a threat to their job. In [9] it was revealed that some people were not used to the culture of
information sharing and the passing of documents via electronic means.
Charities are generally not-for-profit organisations, which means that any returns are
fed back into the organisation rather than to shareholders and owners. Non-profits cannot
issue dividends or financially reward their directors to the same extent as commercial
organisations. This is complicated by the fact that even though the overall aim of a charity is
not to make a profit, they still need to make money the same way as a commercial
organisation in order to expand and grow. Charities are likely to find it harder to get funding
in the first place, as they do not have the investment opportunities that profit making
organisations have.
As in any small business, there is often a lack of formality in the way charitable
organisations operate. This is part of what makes many organisations work effectively, as
each member of staff is empowered to use their initiative and make their own decisions
without lengthy consultation with senior staff. This is something which must be thought about
when planning to web enable an organisation, as it could affect the way in which it is
received.
3.3.2. Fear of failure
Cravens [14] suggests that one of the barriers preventing organisations from becoming web
enabled is a fear of failure and a perceived waste of already scarce resources if a high-risk
Page 31
web project fails. There may be a tendency for an organisation to stick to what it knows but
this can leave it behind when it comes to taking advantage of web technology. Cravens [14]
even suggests that some people may see the use of new technology as a ‘fad’, perhaps this is
understandable given the speed at which technology and particularly the Internet has
developed.
3.4. Legislative compliance
3.4.1. Data protection
The Data Protection Act 1998 [15] applies to all UK businesses, including charities. The act
was created to protect the privacy of individuals and businesses by setting rules for the use
and storage of personal data. To comply with the act anyone processing personal information
must follow the eight principles of good information handling practice, which state that data
should be:
1. Fairly and lawfully processed
2. Processed for limited purposes
3. Adequate, relevant and not excessive
4. Accurate and up to date
5. Not kept longer than necessary
6. Processed in accordance with the individual’s rights
7. Secure
8. Not transferred to countries outside European Economic area unless country has
adequate protection for the individual
Figure 5. Data Protection Act 1998

(Source: Information Commissioner's Office1)
Large commercial organisations, who are likely to have more resources available to
manage data protection, may find it easier to comply with the eight principles than small
1
http://www.informationcommissioner.gov.uk/
Page 32
charities with less time to ensure legislative compliance. Whatever the size of the business the
rules are the same so it is important that the principles are kept in mind when developing new
systems and processes which deal with data. For organisations that have overseas operations
and where data needs to be transferred outside of the country of origin, the complication
increases. The country importing the data must have equivalent protection as stated in
principle 8.
3.4.2. Disability Discrimination Act
The Disability Discrimination Act 1995 [16] covers a number of topics but the most relevant
in the context of this dissertation is “Part III - The provision of goods, facilities and services”
which specifically mentions websites (Pages 7 – 71). Although the legislation clearly covers
websites, the part of the act regarding it is very general and does not mention any specific
standards that must be met. The act states that:
The Disability Discrimination Act makes it unlawful for a service provider to discriminate
against a disabled person by refusing to provide any service which it provides to
members of the public.
If the service is provided via a website then it must be made accessible to all. If a
website is not accessible then steps must be taken to improve the ability of visually or
otherwise impaired users to access and use the services the site provides.
Although the act does not specifically mention any requirements for accessibility of
websites there are widely recognised standards which can be used to check for website
accessibility. The most widely supported are the World Wide Web Consortium’s (W3C) Web
Content Accessibility Guidelines 1.0 (WCAG) [8] which define three levels of conformance
(A, Double-A and Triple-A). The three levels of conformance allow for the distinction
between basic accessibility guidelines being met, through to highly accessible websites, and a
lack of conformance shows a low level of accessibility. The guidelines offer both guidance
and a method of checking conformance against a set standard. Tools to check a website are
Page 33
available on the W3C website and commercial accessibility testing tools such as WatchFire’s
WebXM1 (formerly known as Bobby).
3.5. Globalisation
For the scope of this dissertation, an international charity is defined as one which has
volunteer or salaried staff working away from the country of origin for extended periods of
time. It also includes any charities which are reaching out to a global market place.
International charities face the additional challenges of long distance communication,
language barriers and variations in infrastructure.
3.5.1. Local infrastructure
Local infrastructure will affect the speed, reliability and ease of access to information.
Although many countries now have widespread broadband connections, others have very
limited access and slow, unreliable connections. Another problem is the age and ability of
computer hardware and software. Many technologies for information sharing depend on new
standards which are not always supported by older software.
3.5.2. Language
Information presented in a language that is not understood by the reader is likely to be either
indecipherable or at best, difficult to understand. Some languages share similarities, languages
based on Latin for example. Although language similarities can allow the target audience to
get a basic understanding of the information, it can easily be misinterpreted or only partially
understood. If the difference between the languages of the source and target are large then it is
very unlikely that it will be understood at all. The difference between English and Chinese is
vast and makes it very difficult to translate using guesswork and language similarities.
Cultural differences mean that it takes more than just straightforward translation to
make something suitable for use in another culture. A major factor in translation complexity is
the number of regional variations. The French spoken in Canada is different to the French
spoken in France so language that is suitable for one region may not be suitable for another.
Some countries have more than one official or commonly spoken language. The federal
Constitution of Switzerland stipulates that German, French, and Italian are Switzerland's
1
http://www.watchfire.com/products/webxm/
Page 34
official languages as well as Romansh for communicating with Romansh-speaking persons.

Additionally, English is increasingly being taught from an early age, often in preference to a
second official language. Each additional language that must be catered for adds to the time
needed to translate and manage a web application.
A further complication, which sometimes occurs, is when the translation of a name,

product or trademark has an unintentional meaning in other languages. This can occur even if
a web application has been localised because logos and brand names are often kept the same.
The Clairol “Mist Stick” (a curling iron) was sold in Germany under its English name which,
in German slang, reads as “Manure Stick”. These sorts of problems can also occur because of
bad translation – the Kentucky Fried Chicken slogan “finger-lickin’ good” was originally
translated to Chinese as “eat your fingers off”.
3.5.3. Culture
Culture is a difficult aspect of information sharing as, although languages can be translated, it
is more difficult to translate the overall content of the information so that it is suitable for
another culture. Information can either be translated directly, possibly causing problems if it
does not come across well to another culture, or it can be translated indirectly.
Indirect translation is often necessary for marketing information where the market and
culture varies greatly from country to country. Many web projects are designed without
giving a lot of attention to the expansion of the service to other languages and cultures,
causing problems when there is a later need to expand a product overseas. There are a huge
number of issues which need to be dealt with when globalising a web application. These
issues include but are not limited to language, culture, currency, legislation, infrastructure,
security and reliability. Dealing with each of these elements is a major challenge although
some are more difficult than others.
3.5.4. Design sensitivity
The perception of colour varies across the world. In Egypt, the colour white often represents
joy whereas in Japan it more commonly represents death [17]. These are generalisations and it
does not mean that a white colour scheme for a Japanese audience is necessarily bad but it is
worth considering this aspect of colour during the design. The problem with using a variety of
Page 35
colour schemes is that global branding can be affected and it adds an extra level of complexity
to any internationalisation attempts.
3.5.5. Legislation and currency
Legislation differs depending on physical location. In Canada, it is illegal for a job application
form to ask somebody’s religion or ethnicity whereas in the United Kingdom it is common,
even if only for statistical purposes. The biggest problem with legislation is that it is
constantly changing and therefore time consuming and complex to manage. Varying
exchange rates and different currencies often require a web application to dynamically change
the pricing for each country. The alternative is to have stabilised prices for different but this
can lead to problems if customers discover that a product is effectively cheaper to buy using a
different currency with a more favourable exchange rate.
3.6. Infrastructure
3.6.1. Variance in technology, infrastructure and security overseas
The quality and availability of access to the Internet varies overseas. In Africa Internet
penetration as a percentage of the total population is only 1.4% whereas in North America this
is much higher at 66.5% [18]. Much of this is due to the infrastructure and the perceived
importance of Internet access.
The world’s information infrastructure is developing rapidly, with more countries

becoming Internet enabled and a huge number of languages and cultures to deal with.
Allowing easy access to information in the relevant language and format is an important issue
and needs to be studied to encourage widespread use of any major web application.
One solution to this wide variance in access is to make web applications technically
and culturally neutral. The downside to this is that it can remove the personality of the web
application and make it seem too biased towards the dominant culture.
There is a large gap between the technological infrastructure in developed countries

and the infrastructure of developing countries. While broadband is popular in North America
it is very unusual to find it in poorer countries. The way in which the Internet is accessed also
varies. In richer countries users tend to use it at home or in the workplace, whereas elsewhere
Page 36
in the world it may only be possible to gain access at Internet cafés or libraries. When
developing web applications for global use, this is an important area to look at and could be
the difference between the product working or being unusable. If a site has been developed
for the US market, with lots of animation and images then it is not likely to succeed well in
countries with slower access speeds.
3.6.2. Designing for technical limitations
Although the growth of new technologies has been fast, not everyone is able to keep up with
the latest developments in hardware and software. This can restrict the technologies used,
especially if it needs to be deployed in poorer countries or organisations with older
technology such as schools and other charities. The infrastructure and age of resources is a
limiting factor and may mean that some of the advanced features available in modern web
browsers cannot be used until they are mature enough to have a wide and global penetration;
this can take many years.
3.6.3. Weight
Heavy use of multimedia for a UK audience is often suitable as a large proportion of the
population have access to broadband Internet connections. In poorer countries where the
infrastructure is often unreliable and slow, and the hardware and software a few years behind,
then the weight of a site must be decreased significantly. The weight of a site is the quantity
of information which must be downloaded from the web server to the user, for the page to be
displayed. It is usually measured in Kilobytes. Graphically intensive pages have a greater
weight than pages which just carry textual content. Yahoo!1 Is often used as an example of a
lightweight, yet content filled, site even where there’s the opportunity for it to exploit the high
bandwidth available to some of its visitors.
This chapter has investigated some of the key problems which charities looking to web enable
may face. Communication is a key business driver but must be carefully thought out to avoid
common pitfalls. Non-technical issues faced by the sector cannot always be solved
immediately but by understanding them it can help to make the web enablement process
1
http://www.yahoo.com/
Page 37
easier and less likely to fail. For smaller organisations, it can be hard to find time and
resources to ensure legislative compliance, however it is an important issue and all
organisations must do their best to follow laws such as the Data Protection Act and the
Disability Discrimination Act.
As shown by Figure 4, there is a large overlap between the issues faced by charities
and commercial organisations. Now that the issues have been explored more fully, it is useful
to refer back to Figure 4 to see which issues are unique and which issues apply to both
sectors.
Now that charities have been introduced, problems discussed and existing work
examined, the dissertation can move on to the development of a framework designed for
assisting charities and voluntary sector organisations to achieve their web enablement goals.
Page 38
Chapter 4. The F4 Pyramid Framework
This chapter outlines a generic framework for web development, designed primarily for
charitable organisations, but also suitable for many small businesses. The framework uses a
modular approach to web enablement and covers suitable approaches and techniques for web
enablement of a number of key business areas.
4.2. The framework
4.2.1. Development of the framework
The framework was developed and refined based on previous research and existing
information in the area of web enablement, as well as through the work carried out at GAP
Activity Projects. GAP is examined in more detail in the next chapter, where practical
examples of the framework are shown and put into an actual business context. Ideas for the
framework were based on previous experience as well as general reading about the current
state of the art (see Bibliography). By consulting with management staff, colleagues and
through contact with other charities, it was possible to develop a clear picture of the needs and
desires of charitable organisations and their unique needs. This led to the requirements of a
framework being collected, which were then applied to the design and implementation.
Within GAP there are a number of departments, including Marketing, Operations,
Development and Finance, all of whom were consulted during the research process and while
implementing the framework.
4.2.2. Framework model and framework infrastructure
Whilst this chapter primarily deals with modelling of the framework and its processes, the
case study, and the applications created as a result of the practical implementation of the
model, have resulted in an infrastructure of tools and methods to support the framework.
These tools and methods are investigated and explored in more detail in the next chapter but
at this stage it’s useful to be aware of the two separate but complimentary aspects of the
overall framework.
Page 39
4.2.3. The layers of the framework model
The many components which make up a web enabled organisation can be split into any
number of categories or layers. However, after looking at these components in terms of the
order in which they should be implemented, it was decided that they would fit best into four
distinct ordered layers.
The first layer of the framework model is the Foundation (F1) layer which consists of
the underlying IT infrastructure. The Fundamentals (F2) are components which require the
foundations to be in place and which are necessary to support the Features (F3) layer. All
layers rely heavily on the Foundations which includes hardware components as well as
suitable software. The Features layer contains features which build upon the Fundamentals
layer.
The top layer of the pyramid is the Future (F4) layer. A well-planned web enablement
project should leave room for future possibilities and new technologies which are not
available at the time of the initial implementation. Unlike some projects with a fixed tangible
deliverables, web enablement projects are usually ongoing concerns and it is important to
allow for the fact that there will be a constant need for change and refinement during the
lifecycle. For this reason, the top layer has been illustrated as clear, as it is a vision rather than
a tangible layer.
Page 40
Fea
tu res o d ules
M
&
Fun
d ame li b rary dule
e o
n tals Cod rship m
be
mem
Fou c t ure &
tru lity
nda
ti ons I n fras vailabi
IT et A
e rn
Int
Figure 6. The F4 Pyramid Framework
4.2.4. Why a pyramid?
A pyramid is used to represent the framework model for a number of reasons. By showing the
higher layers as smaller than the layers below, it demonstrates that the size of the underlying
layer has a direct affect on the size and scope of layer above. For example, if the IT
infrastructure can only cope with 25 concurrent database connections then the layers built on
top of those foundations will also be limited, unless the Foundations layer expands.
The pyramid model has no units of measurement and can therefore be scaled to fit any
size of web enablement project. Like a real Egyptian pyramid, the lower stages must be built
first in order to support later work built on top. The higher layers will only ever be able to
grow if the underlying layers allow them to do so. Figure 7 illustrates how layers of the
pyramid can be expanded to represent potential future expansion needs, but because of the
pyramid shape, the lower layers must always be expanded first. Progress through the pyramid
Page 41
stage is vertical from bottom to top. It is important to make sure the foundations are in place
for the implementation to be both scalable and supportable.
Figure 7. Direction of expansion and progress
The converging tip of the pyramid demonstrates that the possibilities for future
progress are going to be finite and limited by the lower layers. The wider and more supportive
the rest of the pyramid is, the further away the limiting tip becomes.
4.2.5. Content of each layer
The diagrams below show the order of progress and the suggested contents of each layer of
the pyramid.
Page 42
Foundations Foundations
Some of the key elements in this layer include:
Internet access • Internet access

Email
Security
Software
Data storage • Email
Programming platform
• Security
• Software
• Data storage
Figure 8. Foundations
• Programming platform
These primarily consist of the IT infrastructure and are likely to already exist in one
form or another in many organisations. This layer is important in highlighting the
need for a stable base layer before developing further tools and applications.
Foundations Fundamentals
Fundamentals
Some of the key elements in this layer include:
Industry
Internetguidelines
access • Industry guidelines
BestEmail
practices
Code library
Security
Error handling
Software
Membership
Data storage • Best practices
Testingplatform
Programming
Documentation
• Code library
• Error handling
• Membership
Figure 9. Fundamentals
• Testing
• Documentation
Fundamentals move away from the physical infrastructure and deal with processes,
data structure, documentation and the methodology used.
Page 43
Foundations Features
Fundamentals
Some examples of applications that can be
Features developed for this layer include:
Industry
Internetguidelines
access
BestEmail
practices
Code library
Security
Online
Error handling
Software
forms etc.
• Online communities
Membership
Data storage
Testingplatform
Programming
Documentation
• Sending multiple emails
• Online forms
• Extranet
Figure 10. Features • Global data access
• Global file access
In this layer the features developed for different organisations are likely to vary. The
examples given above are explored further later in this dissertation but there are
many more possibilities. This is the stage where the benefits of web enablement
become clear to all as the new developments will reach out beyond internal processes
and systems.
Foundations Future
Fundamentals
Some future technologies applicable to this
Features layer include:
Industry
Internetguidelines
access
BestEmail
practices
•
Code library
Security
Online
Error handling
Software
forms etc.
Mobile features
Membership
Data storage
Testingplatform
Programming
Documentation
• New technologies
• Expansion of current features
Figure 11. Future
The future cannot be predicted accurately, particularly in the fast-paced IT industry

which web enablement projects are a part of. It is important to look at what the future
may bring
Page 44
4.2.6. Implementing and using the framework
The flowchart in Figure 12 can be used as a high-level guide to implementing the framework.
It covers implementation from the start, all the way through the four stages of the framework.
As web enablement projects tend not to have a finish, there is no end state.
The diagram is split into IT Development and Software Development tasks. This
distinction is useful if an organisation is looking to employ a software developer but, to
reduce employment costs, does not want to begin employing them until they are needed or are
able to work effectively. For a software developer to be effective, the foundations must
already in place.
Page 45
The summaries referred to in Figure 12 are available in this chapter as well as the
Appendix.
Start
F1 Ensure suitable foundations are

Suitable foundations in place? No in place using Foundations
Checklist (see Appendix)
IT DEVELOPMENT
SOFTWARE DEVELOPMENT
Yes
Refer to Summary of Fundamentals

(see Appendix)
Maintenance & F2
documentation of Develop
code begins Fundamentals
Refer to Summary of Features

(see Appendix)
F3 Add new
Implement
Features
Features
F4
Explore Refer to Summary of Future
Future (see Appendix)
ideas
Figure 12. Implementation flowchart
Now that the overall methodology has been shown, the next stage is to explore each of
the four layers in turn, and investigate each in detail.
Page 46
4.3. Foundations (F1)
4.3.1. Introduction
The framework is dependant on an underlying IT infrastructure. The basic IT infrastructure,

which the framework depends on, consists of items such as a Local Area Network (LAN),
client PCs, servers, software and Internet access. The programming platform chosen must
meet suitable generic requirements such as object orientated programming features. The
Microsoft .NET Framework meets and exceeds the requirements for this layer of the
framework and was used to develop the tools and applications in the case study.
For the layers built on top to work effectively, there needs to be a solid and reliable
infrastructure underlying the systems and processes. This is analogous to the building of
foundations before building a house, the foundations have to be built or it is impossible to
build the rest of the structure. With software engineering projects, there can be a bit more
flexibility as it is possible to improve the foundations after, or at the same time as, the projects
which are built upon it. In an ideal world, the underlying infrastructure would be put in place
before software was developed on top of it but in reality, most software projects have to be
built upon on existing infrastructure. The exception is completely standalone projects, or
brand new organisations who can afford to invest in a suitable infrastructure from day one.
Because small charities are likely to have limited funding there’s a good chance that this will
be reflected in the quality of their existing computing infrastructure.
4.3.2. Checklist
The Foundations Checklist in Figure 13 can be used as a starting point for planning and
implementing the foundations. Initially it can be used for auditing purposes and then later
used to check progress in the implementation of foundations. Although a basic list, it is
designed for use by non-specialist staff that need a starting point and an indication of the work
which is required. The checklist requires a level of technical understanding but the reader only
needs to be know what an item on the list is and means, not how to implement it.
Page 47
Figure 13. Foundations checklist
Page 48
4.4. Foundation: Internet access
4.4.1. Connectivity
Before an organisation can e-enable itself, it needs a fast, reliable and preferably always-on
connection to the Internet. The report, E-enabling the Voluntary and Community Sectors [9],
showed that voluntary and community sector organisations were less likely to have an Internet
connection. Whilst 94% of businesses expected to have a connection by the end of 2001, only
78% of voluntary sector organisations expected to have the same level of access within the
same timeframe.
The speed and type of Internet connection required will depend on the number of users
in the organisation who will be using it to contact the outside world as well as the number of
users and other staff who will be using it to connect to information systems within the
organisation. Most connections only advertise the download speed and leave the upload speed
in the small print. If an organisation is planning to host a website itself then the upload speed
should be at least 512kb/sec. Synchronous connections such as Synchronous Digital
Subscriber Line (SDSL) are preferable to Asynchronous Digital Subscriber Line (ADSL) but
are generally more expensive. The contention ratio should also be kept low, preferably at least
1:20.
Any Internet connection that is business critical should have a suitable service level
agreement attached to it. This may drive the price of the service higher than an equivalent
consumer level contract but if the business depends on Internet access to operate then it can
save on support costs in the long term and provide a better service to customers.
4.4.2. Hosting
Hosting of websites can either be managed by internal staff or outsourced to consultants; it

can also be physically hosted externally or internally. Often a combination of these
approaches is useful. External hosting is better suited to websites which receive a lot of traffic
and which need to have an availability of close to 100%. Using externally managed hosting is
often good value for money because it is now such a large industry and therefore it is the
approach most organisations take. Externally managed hosting also relieves internal staff of
the burden of managing and supporting the servers. As with other external contracts, it is
Page 49
important that a service level agreement is signed to make sure that the hosting will be
suitable for its purpose.
For more advanced web applications, it may be desirable to have the server physically
hosted in a major data centre so that it has access to fast and reliable Internet connection but is
still managed by internal staff. This costs a lot more than shared managed hosting but it has
the major advantage of complete control over the server but without having to worry about
connectivity to the outside world. The major disadvantage is that if anything goes wrong then
the responsibility lies with the operator, not the network provider.
A cheaper alternative to the above approach is to host some web applications

internally. This can be a good approach to take when a site is being developed and changes
are constantly being made. At a later date, and if visits increase beyond the capacity of the
corporate Internet connection, then the server can be transferred to a data centre with the
required capacity.
4.5. Foundation: Email
Most organisations have already realised the benefits of widespread access to email. To be
truly web enabled then all staff, including volunteers should have regular and reliable access
to email. This level of pervasiveness enables applications to be developed which can use
email as a key part of their functionality. An example is enabling staff to receive email
notifications when a website visitor requests literature to be sent to them. The old approach
might be to list on the website the phone number of the relevant contact who would deal with
the request. A better approach would be an online form which the visitor can fill in and send
directly to the relevant staff member. As well as requiring the user to be less proactive in
contacting the organisation, it also makes the service available 24 hours a day.
An advantage of online forms over email is that it is easy to set up specific fields on
the form which can only contain certain values or that must be filled in for the form to be
submitted. This should reduce the chances of the requester having to be contacted again to
clarify exactly what they want or meant. Without a staff culture of regularly checking email,
this system would fail so it is important that this requirement is met before building projects
that rely on it.
Page 50
Whilst an organisation without a web presence can operate without email, it is rare to
find an organisation with a web presence that does not regularly use email. Some
organisations have made the complete transition from physical presence to online presence
and can only be contacted by email or through their websites. Amazon 1and eBay2 are well
known companies which operate entirely online, not even displaying a contact phone number
on their website.
4.5.1. Spam
A hazard of web enablement is the increased reliance on email over more traditional methods
of communication. Spam, phishing and viruses are issues which affect most email users to
some degree, but once they start affecting business critical systems the problem can worsen
significantly. Suitable spam filters should be set up to reduce the volume of unsolicited mail
reaching staff but without blocking genuine emails. A compromise is often the best solution
as it blocks most spam, but does not result in as many false positives.
4.6. Foundation: Security
Security is becoming increasingly important in recent years and many organisations are
placing it very high on their list of IT priorities, if not at the top. There is good reason for this
given the increased severity, intelligence and frequency of attacks on users and the systems
they use. Current best practice recommends that security should be both physical, policy
based and software based. This is based on the concept of defence in depth where a layered
approach reduces the attackers chance of success and increases the attackers risk of detection
as they penetrate or fail to penetrate each layer of the defence strategy.
1
http://www.amazon.com/
2
http://www.ebay.co.uk/
Page 51
Figure 14. Defence in depth

(Source: Microsoft)
4.6.1. Firewalls
Firewalls are the first line of physical defence on computer networks. They act as a gateway
between the organisation’s internal network and the outside world. Firewalls significantly
reduce the initial attack surface as they block access to all ports other than those which need
to have external connectivity. Two of most common firewall ports left open are port 80 for
HTTP and port 443 for SSL/HTTPS. These ports must be open to allow web traffic through
the firewall and into the web servers on the organisations network. The topic of secure
firewall setup and usage is beyond the scope of this dissertation but it is definitely something
which any organisation, and even home users should make sure they have in place as a bare
minimum.
4.6.2. Anti-virus
The impact of viruses, worms and Trojans can range from minor annoyances to complete
system failures or data loss. As with any size of organisation, a large loss of data can be a
disaster both financially and operationally. Smaller organisations and charities may find it
Page 52
particularly hard to recover. A firewall offers little protection if a virus arrives as an email
attachment, on removable media or is unintentionally downloaded from a website. In
accordance with the defence in depth model shown in Figure 14, there should be appropriate
anti-virus protection on the client and servers, even though they are already partially protected
by the preceding layers of security.
4.7. Foundation: Software
Software is needed for a number of areas of the foundation layer. There must be suitable
operating system software on the servers and workstations which comprise the organisation’s
network. The operating system software must be able to take advantage of Internet
connections, be able to support a range of server and client applications and be secure and
stable.
4.7.1. Reduced price software
Most software vendors offer software to charities and academic institutions at a reduced rate.
Where a normal small business might opt for cheaper alternative software, charities often
have the advantage of being able to buy more advanced products at a similar price to cheaper
alternatives. Thanks to the generosity of many software vendors towards the sector GAP
Activity Projects has been able to use some of the latest industry standard software packages
including Microsoft Windows1, Microsoft Office2, Macromedia Studio3, Adobe Photoshop4,
Adobe Illustrator5 and Microsoft Visual Studio6.
4.8. Foundation: Data storage
4.8.1. Databases
Databases can be used for a variety of tasks. They may be used for complex enterprise-wide
databases with hundreds of tables right down to simple single table logging applications. To
web enable an organisation there needs to be the infrastructure available to allow applications
1
http://www.microsoft.com/windows/
2
http://office.microsoft.com/
3
http://www.macromedia.com/software/studio/
4
http://www.adobe.com/products/photoshop/
5
http://www.adobe.com/products/illustrator/
6
http://msdn.microsoft.com/vstudio/
Page 53
to write to and read from databases. Although it is possible to run a website without a
database back-end, it is not possible to develop features such as dynamic news pages or
subscribable mailing lists.
4.8.2. File storage and backup
Organisations of any size, including sole proprietors, should ensure that any data and files
used by the business are kept securely and easily accessible. If possible, an organisation
should aim to store its data centrally on a physically secured server. It should also set up a
regular backup routine in the event of a hardware or software failure, fire or theft.
Most PCs are initially set up under the presumption that all data will be stored on the
local hard drive. Whilst this may be necessary in some cases, high bandwidth video editing
for example, the use of network storage devices should be encouraged and made as easy to
use as possible. A common setup is to give users access to a protected directory for their own
files and then to have one or more public or departmental file shares available for more
general use. Email is increasingly becoming used for the storage of critical information in the
form of file attachments and messages. It is essential that email is also backed up regularly.
As well as file storage being available, it should be fast enough for the user not to
notice that it is not stored locally. Capacity should be monitored so that it can be increased
before users begin to hit the limit and potentially lose data.
4.9. Foundation: Programming platform
4.9.1. Programming environment choices
In a small organisation with limited resources and time, it makes sense to limit the number of
core technologies and programming environments that are used. It is a major advantage and
cost saving to be able to re-use knowledge and code from one project and use it in others. The
requirements are listed below.
1. Ability to interact with legacy applications and code.
2. Ability to develop web, desktop and server applications.
3. Scalability and flexibility for future growth.
4. Extensibility if the required functionality isn’t available as standard.
Page 54
5. Reliable and tested technology, not experimental technology or betas.
At present, the two most prominent technologies which meet the criteria above are the
Microsoft .NET Framework and the Java 2 Platform, Enterprise Edition (J2EE). Another
architecture which is worth considering is the LAMP open source software collection,
comprising of Linux, Apache Web Server, MySQL database server and PHP/Python/Perl,
hence the acronym.
4.9.2. Java 2 Platform, Enterprise Edition (J2EE)
J2EE is a platform defined by a specification from Sun Microsystems, it uses the Java
language which was also developed by Sun. The core technologies which comprise J2EE are
Enterprise Java Beans, Servlets, Java Server Pages and a number of web services
technologies.
J2EE has a number of features which differentiate it from the Microsoft .NET
Framework, the most commonly cited being its ability to operate on multiple platforms from
different vendors. This ability to operate cross-platform is something which makes it
attractive to organisations which have a variety of existing hardware and operating systems, it
also reduces the reliance on one particular operating system vendor and hardware architecture.
4.9.3. Microsoft .NET Framework
The Microsoft .NET Framework shares many similarities with J2EE and has been on the
market for less time than Java. The most significant difference between the two platforms is
that the .NET Framework utilises a technology called the Common Language Runtime, which
allows .NET applications to be written in almost any high-level language. J2EE’s Virtual
Machine technology is similar but only the Java language can be used. Although the
Microsoft .NET Framework offers greater language flexibility it is more restricted in terms of
cross platform abilities. Microsoft understandably only fully supports its use on Microsoft
platforms and with the Microsoft developed languages of C#, Visual Basic and J# (based on
Java). Other languages which can be used include Perl, Python, COBOL, Eiffel, Pascal,
Fortran, SmallTalk, Java, RPG, Ada and APL. This gives a great deal of flexibility,
particularly if a charity already has a developer or consultant who works with a less
commonly used language and does not want the expense and inconvenience of retraining
them.
Page 55
Although Microsoft itself is not currently pushing cross-platform support there are a
number of projects looking to improve on this. The most well known is Mono1, supported by
Novell, which includes both developer tools and the infrastructure needed to run .NET client
and server applications on Linux.
The Microsoft .NET Framework makes a lot of sense if an organisation is already

using a lot of Microsoft technology as the integration between products is extensive and
planned to become even more so because of Microsoft’s Common Engineering Criteria2. The
common criteria must be met by all major new Windows server products and requires support
for the .NET Framework as well as other key Microsoft technologies. This is a positive step
towards reducing the complexity of integrating multiple systems.
Figure 15. Microsoft .NET Framework

(Source: Microsoft)
The diagram above (Figure 15) shows how the various components of the Microsoft
.NET Framework fit together. The languages which meet the Common Language
Specification [19] can be used to create both web applications and traditional Windows
applications. The core code for each task is the same, the only difference between
programming a web and a Windows application being the specific functionality and abilities
of the environment. The next layer is ADO.NET, which deals with connections to databases
1
http://www.mono-project.com/
2
http://www.microsoft.com/windowsserversystem/cer/allcriteria.mspx
Page 56
and other data sources, including XML. The code is compiled and run by the Common
Language Runtime, which interacts directly with the operating system. Visual Studio .NET is
Microsoft’s preferred tool for producing code and managing each of the layers of the
Framework but it’s possible to use other tools, including a simple text editor and the
command line compiler.
4.9.4. LAMP
The LAMP architecture is an unofficial acronym for a suite of commonly used open source
software packages which are frequently used to create integrated web application solutions.
The major difference between LAMP and J2EE/Microsoft .NET is that the originators of the
individual applications did not originally design their software to work together. The term
LAMP was popularised by Michael Kunze in an article for the German computing magazine
“c't” in 1998.
There are now a number of other collections of software using similar acronyms, this
is to be expected as the choices of technology change and new packages gain popularity over
others. For a long time MySQL was the most popular choice of database back-end among
PHP 4 developers but with the advent of PHP 5 and its integrated SQLite database engine, as
well as the increasing popularity of PostgreSQL, the choice of database platform is less clear-
cut.
There is no reason to expect development of open source alternatives to J2EE and

Microsoft .NET to cease to exist but it is likely that they will continue to operate as a number
of smaller components for a while to come. For this reason the highly integrated Microsoft
.NET Framework and J2EE platform may offer less confusion for small charities who prefer
the future direction of their platform to be controlled by a software vendor; Microsoft and Sun
Microsystems respectively. For a commercial organisation open source software can offer a
significant cost saving and the extra complication of managing multiple packages may not be
so much of a problem if there is a large enough team to support it. For charities, there are
currently significant discounts available for purchasing the software required by the Microsoft
.NET Framework. The core software components of J2EE are available to download free of
charge.
Page 57
4.9.5. Using the Microsoft .NET Framework
Both the Microsoft .NET Framework and J2EE share a common base functionality, which
makes them suitable for the requirements of the techniques used in the framework and case
study. For the rest of this dissertation the Microsoft .NET Framework will be the platform
which is used for examples. J2EE is just as suited to the task but as the case study, and
therefore the practical work supporting this dissertation, has been developed using Microsoft
.NET it is sensible to concentrate on showing examples using this platform for the remainder
of the dissertation. The table below lists the equivalent technologies for the two platforms:
Microsoft .NET Framework Java 2 Platform, Enterprise Edition

(J2EE)
C#, C++, J# and Visual Basic Java programming language

programming languages
.NET Framework Class Library Java core API
ASP.NET Java Server Pages (JSP)
IL Common Language Runtime Java Virtual Machine and CORBA IDL

and ORB
Windows Forms Java Swing
ADO.NET and SOAP-based Web JDBC, EJB, JMS and Java XML
Services Libraries (XML4J, JAXP)
Table 4. Comparison of .NET and J2EE features
4.9.6. Recommended programming platform features
There are a number of features which it is recommended the chosen programming platform
includes, or is capable of using. The features are explained in this section along with a
justification of why they are useful. It is still possible to implement the framework without
some of these features, but they should make development easier, faster and more reliable.
4.9.7. Object-oriented programming (OOP)
Object oriented programming practices have been used for the example implementation of the
framework. The ability to re-use code allows for easy expansion, scalability and flexibility.
Page 58
ASP.NET offers a unique development approach where everything in a web page, even down
to the basic level of a tag, can be treated as an object. This gives a powerful means of
accessing and controlling web applications with properties to set and retrieve information, and
respond to events occurring within the application.
4.9.8. XML & web service support
The .NET Framework has been developed with thorough XML support and allows easy
access to web services and other XML data. XML is also a commonly used tool for
international web projects as it has full Unicode support and is therefore suitable for storing
data in any language. With the rising popularity of web services it is sensible to choose a
development platform with built in XML support so that web services can be easily
integrated in future.
4.9.9. Intermediate code
Microsoft .NET and Java both use the concept of intermediate code which is compiled using a
JIT compiler (just-in-time). Java uses intermediate code, or byte code, to make applications
cross-platform. The byte code uses a lower level language than the high-level Java code but it
is still generic enough to be used on multiple platforms. Before the code is executed it is
compiled on the Java Virtual Machine (Java VM) which runs on the host computer. This
compiles the byte code ‘just-in-time’ and creates machine code which is then executed. The
.NET Framework is very similar but calls the CPU-independent instructions Microsoft
Intermediate Language (MSIL), as shown in Figure 16. The Common Language Runtime is
the equivalent of the Java VM although at present it is only generally available for use on the
Windows platform.
Figure 16. Intermediate code compilation

(Source: Microsoft)
Page 59
4.9.10. .NET managed code
Managed code is useful for reducing the chances of coding errors causing unexpected and
dangerous behaviour. Before the code is run, the MSIL is compiled into executable machine
code. The managed execution environment (CLR) can make guarantees about what the code
is going to do. It can insert traps and appropriate garbage collection hooks, exception
handling, type safety, array bounds and index checking. This stops a range of common
programming mistakes occurring and, as well as making code more reliable, it reduces the
chance of a security hole being opened. The slight speed decrease of running managed code is
made up for by the improved reliability and safety, especially with web applications where the
bottleneck is usually the user’s connection rather than the speed the server returns pages.
Page 60
4.10. Summary of foundations
The diagram below (Figure 17) is a summary and breakdown of the Foundations (F1) layer of
the framework. This can be used as a guide to the tasks involved and some of the key points
to be taken in.
Figure 17. Summary of Foundations
Page 61
4.11. Fundamentals (F2)
The Fundamental layer is a combination of software development, research and best practices
which must be applied and put in place before features are developed.
4.12. Fundamental: Industry guidelines and best practice
Before beginning development work it is important to be aware of, and to follow, best
practices in terms of the way code is written and technologies are used.
4.12.1. Coding style and naming conventions
It is useful to adopt a standard coding style and naming conventions. Rather than this
framework suggesting a proprietary coding style and set of naming conventions, it is
suggested that the recommended coding style of the language/platform vendor is used. This
information is usually made freely available on the vendor website or can be derived by
looking at sample code from trusted sources and Software Development Kits (SDKs).
4.12.2. Standards compliance
While creating a web application it is sensible to ensure compliance with the latest web
standards. Developing a web application using web standards is essential for compatibility,
maintainability and long-term success of a project. This simplifies and lowers the cost of
production and delivers sites which are accessible to more people and more types of Internet
devices. Following web standards will allow a web application to continue to function
correctly in the future as browsers evolve and new devices such as Internet TV and handheld
devices become more popular.
4.12.3. Proprietary technology
There are a large number of existing websites which make use of proprietary software on their
sites. This is something that should be avoided wherever possible to ensure that web
applications will work on a wide variety of computers in different countries. Because of the
previously high penetration of Microsoft’s Internet Explorer browser, many developers only
target and test their applications for one browser. This is a very bad idea as it may mean that a
website is unusable in any other browser and there is no guarantee that the targeted browser
Page 62
will still be the market leader a few years later [20]. Proprietary technologies such as
VBScript, ActiveX and other custom extensions that only work with Internet Explorer, should
be avoided and replaced with technology that is supported by all browsers. This may mean
that a web application cannot be as advanced as it could be, but it is more important that
everyone is able to use it without feeling frustrated. The only possible exception to this rule is
where the application is being developed for an intranet or extranet and the software
configuration of all users is known and can be controlled.
4.13. Fundamental: Code Library
In almost any modern programming language, there is the potential for reusing existing code.
This is a key aspect of the Object Oriented Programming (OOP) paradigm. It can decrease the
time it takes to develop new products and services if some of the code needed has already
been written and can be re-used. By developing an organisation-wide code library, it gives
new projects a head start, as there is already a foundation of code that can be used to perform
common tasks. The required components of a code library will vary depending on the
organisation, the projects being developed and any existing systems which must be interacted
with.
4.13.1. Database access
Rather than rewriting the database access code for each application it can be useful to have a
number of common methods for selecting, inserting, updating and deleting database records.
By putting this code into a library it also means that any changes in the data layer do not
require a rewrite of existing applications, only the library needs to be altered. Common
database access tasks such as lookups based on ID numbers and reference codes are also
sensible to include in a code library.
4.14. Fundamental: Error handling
Errors and exceptions should be dealt with appropriately. Showing the user the raw error
message is a security risk and will not be of any use to the majority of users. The most
friendly and secure approach is to display a friendly error message to the user whilst alerting
the development team of the error in as much detail as possible. Email is a sensible option for
alerting developers of a problem as there is unlimited space for error content and attachments
Page 63
as well as appearing as soon as the error occurs. Another more complex method of recording
error reports is to use a database. This allows multiple error reports containing the same
information to be grouped together and a frequency associated with the errors. The database
approach can be used as an extension to basic email alerts and for tracking purposes.
As well as a general error message for unexpected errors there should also be specific
error messages for expected errors, such as a temporary problem connecting to a database.
These errors, which may be expected from time to time, should reassure the user and ask them
to try again in a few minutes or whatever behaviour is appropriate.
It is a good idea to have a common method for alerting developers and administrators
when errors occur. A major difference between error handling in internal applications and
external web applications is that internal users will usually let support staff know when an
error occurs. Unfortunately, many web users may see an error without reporting it; they may
even give up what they are trying to do and not come back. Handling an error in any web
application consists of two key stages; alerting the user and alerting support staff.
4.14.1. Alerting the user
The user should be shown an appropriate error message. This should not contain anything
which could compromise security or confuse the user. There should be no system defined
error messages, codes or any other information which the user does not need to know. With a
web application, the easiest approach may be to redirect users to a friendly error page when an
error occurs. This could be specific to a particular error or generic if an unexpected error
occurs. The error page should explain that a problem has occurred, reassure the user and
encourage them to try again later. The message should assume that the error is able to be fixed
by support staff or is a temporary problem such as a database server going offline for
maintenance.
4.14.2. Alerting support staff
The second stage of handling an error, once the user has been taken care of, is to alert
administrators and developers to the problem. The recommended approach is to use email as a
freely available and cheap alerting method. The key advantage email has over any of the other
communication methods which predate it is that it is stored digitally and can be read and
created by computers. There are ways of machine reading faxes and recording human voices
Page 64
but as they are not natively digital formats they cannot be guaranteed to be accurately
recognised. Email error messages can be processed and sorted according to date, time,
application, user and many other variables. This can help to spot patterns and causes when a
bug is being tracked down.
Email error messages should be as detailed as possible so that the source of the
problem can be tracked down. Messages should contain all relevant error codes, system
messages and context details to make diagnostics as easy as possible. For web applications,
the following are likely to be of particular interest:
• The URL of the page causing the error.
• The contents of the query string (GET) and form fields (POST).
• The ID and contents of the current session.
• The contents of associated cookies.
• The user agent (browser) the visitor is using.
• The users host name (resolved from the IP address if possible).
• The users identity (if authenticated).
If using the Microsoft .NET Framework there are a couple of specific details which
may be useful in diagnosing a fault:
• The stack trace – for identifying the code which was executed prior to the error.
• The view state – which can be decoded to allow the state of form controls to be
identified.
4.15. Fundamental: Membership
In order to provide many of the features of a modern website it is essential to have a system
for allowing anonymous visitors to become authenticated members. Without a system like
this, it is difficult to provide online services which are tailored to a particular visitor’s needs
as there is no way to clearly identify who they are.
Page 65
4.15.1. Registration
Registration is something which most website users find irritating as it acts as a barrier to
parts of the site and requires them to take time from their visit goals to type details into a
form. Most registration forms require the user to choose an email address or username and a
password. Many web users will already have registrations for many other websites, all of
which may have different requirements for password complexity and username length. Due to
other people’s registrations users may be forced to use variations of their preferred username.
Security best practices recommend that users have different passwords for each site which, for
many users, is inconvenient and therefore ignored; this can lead to their other accounts being
made vulnerable if a user’s standard password is compromised.
To encourage users to register and discourage them from giving up prematurely, the
size and complexity of the registration form should be kept to a minimum. Questions and
fields should be logically grouped and in an expected order, i.e. forenames before surnames
and address details before post code.
The main hazard of unattended online forms is that the web application must be
responsible for checking the correctness of entries. Whilst it is relatively easy to check that a
required field has been filled in, or contains a valid date, there is no easy way to check for
spelling mistakes and typing errors in names, email addresses and passwords. As the two most
important fields in any registration form are often the email address (or username) and
password it is recommended that these are asked for twice. This duplication of data allows a
simple check to be performed which matches the two entries and alerts the user if there is a
mismatch.
4.15.2. Role based security
The most basic way of differentiating between users is to categorise them into anonymous
users and authenticated users. This is extremely limited, especially when members of the
public will be authenticating in the same way as members of staff. The solution to this is to
assign one or more roles to a user. This allows access to be granted to a user to they can
perform a restricted action. Before the page is loaded or an action takes place a simple check
is done to check the user has been assigned to the required role. Roles can be added and
removed from a users account as required. A simpler, and often used, approach is to assign
each user to a single group, e.g. Staff, Administrator or Member. Although assigning a user to
Page 66
a single group is simpler, it has the major disadvantage that a user can only belong to one
group at a time which decreases the system’s flexibility. For basic systems this can be
acceptable but when looking at using a single system for a number of tasks, some not yet
planned, then role based security is the only viable option.
4.16. Fundamental: Testing
Testing should be done throughout the development of each module as well as before the
module goes live. It is important that any problems in a module are discovered and resolved
as soon as possible, otherwise they can affect modules which are built on top of them,
potentially causing a complex chain of problems.
4.16.1. Browser testing
Web applications have the unique and often awkward feature that they may be used on a
range of browsers, operating systems and devices. Additionally they may be used with a range
of screen sizes, colour depths, font sizes and connection speeds. The use of web standards and
related best practices regarding design and coding of web applications is a good start but the
only way to find out how an application will look is to test it on a number of different devices,
operating systems and browsers. Because of the large number of combinations, it would be
too time consuming to test with all possible systems. A good compromise is to look at the
web server log files, preferably using a log file analyser or web statistics package, identify the
most popular combinations and then set up tests accordingly. Rather than having a separate
machine set up for each browser and operating system combination it’s possible to use virtual
machine software packages which emulate computer hardware in software and allow multiple
machines to run on one machine. Machine emulation software is available from VMWare1
and Microsoft among others. Another alternative is to use a service such as BrowserCam2
which, for a service fee, returns a number of screen grabs from different browsers and
operating systems. Whichever approach is used, browser testing is an important but often
overlooked part of the testing process.
1
http://www.vmware.com/
2
http://www.browsercam.com/
Page 67
4.16.2. User testing
If possible, an application should also be tested by users who are not directly involved with
the project. These testers may be staff from other areas of the organisation, volunteers or pilot
groups of actual users. User testing is sometimes the only way to discover a problem with a
system as it uncovers crucial user experience issues which can be missed when tested by
developers who know how the system is meant to work. Users will use a system how they
expect it to work, and this can reveal flaws in the application logic, user interface as well as
other unexpected problems which are hard to test.
4.17. Fundamental: Documentation
4.17.1. Wikis
A Wiki is a website which can be freely edited ‘online’ using only a standard browser. It
differs from a content management system in that editing and modification of content is
actively encouraged, rather than being hidden from the end user in the case of a traditional
content management system. One of the most famous Wikis is Wikipedia1, an online
encyclopaedia supported by the Wikimedia Foundation. Wikipedia has grown thanks to
contributions from thousands of members of the public who have contributed their knowledge
and the site is now one of the 100 most visited websites in the world. Part of this success is
due to its ability to cover multiple languages.
Although Wikipedia is a huge project with thousands of people using it every day, the
concept of a Wiki can be applied to many different scenarios. Although Wikis were originally
designed for open editing by anyone, it is also possible to restrict access to authorised users.
The advantage of a Wiki over traditional documentation is that it can be edited and kept up to
date without having to reissue and reprint large manuals and ensure that all staff have the
latest copies. The web accessibility of a Wiki is also useful as it is accessible from any PC
provided that the user is authorised to view or edit the information held on it.
A key benefit of using a wiki for documentation is that version changes are tracked
and changes can be reversed or rolled back to a previous version. As an example of
versioning, there may be occasions where there is a need to look at what the settings for a
system used to be. This can be easily checked by looking at previous versions of a wiki page
1
http://www.wikipedia.org/
Page 68
and seeing who made the change and what the change was, as shown in Figure 18. If content
is accidentally deleted but the mistake is only realised later, then the deleted content can still
be restored.
Figure 18. Example of wiki entry history comparison with MediaWiki
4.17.2. Inline source code based documentation
Documentation and comments inline with code is a very quick and easy way of documenting
a large and constantly changing project. There are documentation generators available for
both Java and the C# programming language which take specially formatted comments in
code and convert them to a more readable format, commonly HTML. These tools can very
quickly auto-generate a website containing documentation for all the classes, methods and
events in a project. The main advantage of this approach is that documentation is written at
the same time as code, or at least alongside it. This means that if functionality is removed or
Page 69
changed, then the auto-generated documentation can quickly be resynchronised without

having to open a separate documentation application such as a word processor.
4.18. Summary of fundamentals
The diagram below (Figure 19) is a summary and breakdown of the ideas discussed and
explored for the Fundamentals (F2) layer of the framework. This can be used as a guide to the
tasks involved and as a reminder of some of the key points.
Figure 19. Summary of Fundamentals
4.19. Features (F3)
The features of the framework are split into a number of modules. This approach is suited to
small organisations for a number of reasons. Taking a modular approach to web enablement
allows the work to be broken down into manageable work units. Each module can be treated
Page 70
as a separate project and should only rely on previously completed modules of the framework
foundations. By concentrating on one module at a time, it reduces the complexity of ensuring
that new systems are compatible with existing systems. Any existing modules should have
been documented and tested before new modules are developed. As charities cannot always
afford to make large investments for a single large project then modular development can
allow funding to be gained gradually, as confidence in the success of each web enabled
module grows.
4.19.1. Choosing modules and the order of development
The pro-forma in Figure 20 can be used to take ideas for features and structure them
according to importance and complexity. The initial ideas may come from a brainstorm
session but a system such as the one illustrated allows a list to be broken down into a
structured view of the modules that need to be developed.
Page 71
Later
Time needed
Soon
Figure 20. Feature Planning Matrix
Page 72
Once the desired features have been identified and placed in the appropriate section of
the grid it is easier to prioritise work depending on complexity and the time when a feature is
needed. Basic features which are needed soon are often good features to begin with as they
can be completed easily and are unlikely to cause problems or require outside assistance to
complete.
4.20. Feature: Online community
An increasingly popular way of attracting regular visits to a site is to make sure that it
contains fresh and regularly updated content. With limited resources, it can be hard for staff to
find the time to keep a website regularly updated with new content. As long as the site has a
big enough initial audience then forums and message boards are a proven way of providing
regularly updated content, by encouraging the users to contribute themselves. Forums can
increase the sense of community, which in turn leads to a valuable form of free marketing –
word of mouth. There are many pre-built systems available for community building but
before being chosen, it is important to make sure it is compatible with existing membership
and authentication systems.
4.21. Feature: Sending multiple emails
Email is an important tool for any size or type of organisation. Over half of the respondents to
Goatman’s survey [6] said they would like to be able to send more email and over 60% saw
fundraising as a legitimate use for email.
4.21.1. Sending bulk emails
Without a suitable system for sending bulk emails, the only alternative is often to send a
standard email using the “To”, “Cc” or “Bcc” fields to hold multiple addresses. As well as
exposing the email addresses of other recipients it’s also more likely to be flagged as spam
and also comes across as a lot less personal. Ideally, there needs to be a way of easily sending
large numbers of emails, to customise them for the user and for them to be sent as individual
messages. There are a number of applications and websites which can do this for an
organisation but for advanced customisation and control a custom application might need to
be written.
Page 73
4.21.2. Centralised email functionality
By creating a carefully designed set of classes and methods it’s easy to have a shared system
for creating and sending automated emails, such as those sent to confirm a user’s registration.
The key components are a class to represent instances of an email, a class containing static
methods to customize the email appropriately and a set of email templates such as the one
shown in Figure 21. XML is a good way of storing email templates as it can easily be read
and edited by hand and can contain HTML within CDATA blocks for advanced HTML
emails.
Figure 21. Example of an XML email template
4.22. Feature: Online forms
Online forms have a variety of uses, from an online job application form to a request for
literature.
Page 74
4.22.1. Layout and navigation
To prevent users from being overwhelmed by a complex form it is often a good idea to split it
into multiple, logically grouped, pages. If a multi-page form is implemented then it is also a
good idea to allow users to navigate around the pages as freely as possible. Many online
forms rely on a number of Next and Previous buttons to do this but a better user experience
can be gained by allowing navigation through the pages using a side navigation menu or
dropdown ‘jump’ list.
4.22.2. Validation
The care and attention which different users take when completing forms varies considerably.
Where possible the use of free text fields should be limited and dropdown selection lists or
tick boxes should be used instead. Unfortunately, this is not always possible and most forms
need to have at least one free text entry field. Free text entry means the user is able to enter
any text they like whether it is appropriate or not. Minor cases of commonly entered bad data
are incorrectly capitalised names or unnecessary punctuation. More severe cases of bad data
entry are invalid email addresses, invalid characters in a telephone number, wrongly
formatted postal codes and the correct data but in the wrong box. In order to keep the data
submitted through a form as clean and correct as possible it is important to validate all data
entered by the user.
4.22.3. Server-side and client-side validation
There are two stages when a form can be validated. The first to be triggered, and the most
user-friendly, is client-side validation using JavaScript or another suitable client-side
technology. This method performs validation before the form data is sent to the server for
processing and further validation. There are a number of good reasons for performing client-
side validation and one major disadvantage.
Validation on the user’s browser is more responsive as it does not require a round-trip
to the server and a reload of the page. It can also be used to dynamically alter the HTML of
the page so that incorrect form entries can be highlighted and help messages can be added in
the appropriate place to give the user information to fix the validation problem. The major
disadvantage of client-side scripting is that JavaScript may be turned off or may not be
compatible with the particular browser being used. For this reason, any client-side scripting
Page 75
must be replicated on the server. This combination of methods provides the best protection
from invalid data entries whilst offering the user a better experience if their browser settings
allow for it.
4.22.4. Loose validation
An approach developed as part of this framework is to aim for loose validation. This is
particularly suited to long and complex forms such as an online job application. The method
was developed for the Online Application System at GAP Activity Projects.
The problem with traditional approaches to validation is that for long and complex
forms it can be too restrictive. Each time a new validation check is added to a form, it
increases the strictness of the validation procedure. For forms with many data items, this may
stop the form from being completed and result in a confused user and an email or phone call
to the administrator asking for help. Unfortunately the larger the form, the more chance there
is of it needing validation before it can be submitted.
A solution to this is to keep existing validation methods, but not to restrict the form
from being submitted even if there are validation problems. The intention is to encourage as
many valid entries as possible but not to make the process so rigid that there is no way of
submitting a form which has failed some validation checks. This can be done by making the
form submission into a two-stage process. Rather than offering a submit button immediately
the first available option should be to check the form for errors, i.e. to force a validation
without submitting the form. This can then highlight any areas that need correcting. In the
event of the user being unable to get the form to validate there should still be the ability to
submit the form as it is. The button that submits the form can be hidden until the form has
been checked for errors, or after the user ticks a box to say that they understand the
consequences of the form not being fully validated.
4.22.5. Partially completed forms
Often it can be useful to save a partially completed form to come back to it later. Some forms
require validation of the data to be completed before the form can be saved. This is a bad idea
because an incomplete form is likely to contain errors and mistakes which might stop it from
validating. The only validation which should occur when saving partially completed form
instances is security checks to protect against SQL injection and cross-site scripting attacks.
Page 76
4.23. Feature: Extranet
An extranet can be thought of as an intranet which is accessible from anywhere in the world,
as long as the person accessing it can be authenticated and is authorised to do so. An extranet
allows an organisation to have a central information repository for all web users.
Organisations with an extranet often set it as the home page of their employee’s browsers so
that it is the first page to appear when they start a web session. An extranet can be anything
from a simple one-page website to a complex web application with online calendars, news
systems, message boards and downloads. As the entry requirements for an extranet are low, it
is a good idea for any organisation to implement one if they have the technical capabilities.
The more accustomed people become to using an extranet for accessing internal company
data, the more likely they are to keep using it while it expands with new features.
4.24. Feature: Global data access
Many organisations store data using file-based databases such as Microsoft Access. Whilst
this is suitable for a small organisation, which does not need to allow external or web access
to the data, it is not the best approach for successful web enablement.
4.24.1. Consolidating existing databases
Before looking at giving external access to existing databases, the first step should be to
attempt to consolidate existing databases into a single centralised database. This is sometimes
known as upsizing. Before upsizing existing databases there needs to be a suitable central
database management system in place. Microsoft SQL Server or Oracle are commonly used
database management systems with the robust features and enhanced functionality required
for web enablement of databases.
4.24.2. Web enablement of databases
Most modern web programming languages have the ability to extract data from common data
sources. The web enablement of a database may be required for many different purposes:
• Allowing volunteers and overseas staff to view and edit data.
• Letting people book places at an event.
• Recording the results of an online questionnaire.
Page 77
• Displaying data on a website to show current status or historical data.
The web enablement of a database can be very dangerous unless adequate security
measures are in place. One of the common flaws which allow malicious web users to access
data they should not have access to is known as SQL injection. This exploits a flaw in many
online forms and can potentially allow the user to view data they should not be able to access.
4.25. Feature: Global file access
Before the arrival of the Internet, the only way to transfer data from one site to another was to
physically transport it on disk, tape or optical media. The Internet, web and email allow
sharing of data to be performed between multiple sites in a much faster and easier way than
before. Even so, many organisations rely on email for the majority of their external data
transfers. This can be suitable for many purposes but it has a number of problems. Firstly,
there have to be two people involved with the transfer of data or a document – the sender and
the recipient. This can be acceptable when there is no rush or the recipient knows exactly
what they want, but it can often cause delays. This is a particular problem when offices in
different time zones need to share data. For an organisation with offices in the United
Kingdom and Australia, there is no overlap in standard working hours so it can take up to a
day for a request from one office to be fulfilled by the other.
The solution is to allow direct access to files, usually through the Internet using FTP
or via the web using HTTP. It is important to ensure that, before this is considered, there are
adequate security features in place to make sure that only authorised users can access files
belonging to the organisation. An organisation will usually have some files which are stored
for archive purposes and others which are used regularly. It is a good idea to restrict the
number of files that are available through the Internet to reduce the impact of a security
breach. Other options include setting up a synchronisation system to synchronise files
between two or more offices. This is complex to set up and may require a lot of bandwidth,
depending on the size of the transfers.
Page 78
4.26. Summary of features
Figure 22 is a summary and breakdown of the Features (F3) layer of the framework, based on
the previous section. This can be used as a guide to the opportunities available and some of
the key points to be taken in.
Figure 22. Summary of Features
4.27. Future (F4)
The final stage of the pyramid is for future technologies and expansions of the framework.
There should always be consideration for unexpected developments in web technology and
time should be spent investigating any new options which could be used to enhance the
Page 79
service an organisation offers. Once a future technology has been explored and is feasible
then it can be incorporated as a new or existing feature in the Features (F3) layer.
Not all future possibilities are unknown and many, such as the mobile web, are well
developed. A selection of technologies and concepts which should be investigated as future
expansions are detailed in this section.
4.28. Future: Mobile web enablement
Whilst the Internet is now being used to some extent by the vast majority of organisations,
mobile enablement, as a relatively new technology, is less commonplace. The growth of the
mobile phone market in the UK and overseas shows there is an increasing demand for web
applications to be available for mobile use. By the end of May 2001, Japan had over 40
million people accessing the Internet through their mobile phones [21], 71% of the total
number of web users [22]. In addition to mobile devices, there are now a number of consumer
devices which have been designed or adapted for Internet access, digital TV set top boxes
being a major example. Mobile devices tend to have small screens and a limited number of
input controls. TV based web browsers tend to be more basic and restricted than their PC
based equivalents and may be controlled by simple remote controls, rather than keyboards or
mice.
CNN on a mobile phone Yahoo! Japan on Web TV Amazon.com on a PDA
Figure 23. Web browsing on mobile and simple devices
Page 80
4.29. Future: Mobile text messaging
All major UK mobile network providers offer customers the ability to send and receive text
messages and it is rare to find a phone that cannot take advantage of the service. Although
text messaging (SMS) is more limited than email in terms of the size and complexity of a
message, it does have a number of advantages under certain circumstances.
In Western Europe, there are currently over 381.3 million mobile phone connections
[23] and as of December 2004 the number of phones in circulation in the UK exceeded the
UK population size [24]. Many owners of mobile phones do not have regular access to email
or even a computer so text messaging offers the ability to communicate with a much larger
potential audience. In 2004 over 26.2 billion text messages were sent [24] and there has been
a steady increase each year.
A popular new use for text messaging which is of particular interest to charities, is the
concept of making text donations. The donor simply texts a code word to the specified
number and a charge, usually one or two pounds, is made to their bill. The recipient charity
then receives the majority share of the total donation from the mobile operator. For larger
donations the donor can resend the message as many times as they want to. There are some
concerns that the mobile operators make a profit from the transactions but as all fundraising
tends to costs money this is a price which can be worth paying in order to reach out to a larger
market.
The National Blood Service uses targeted text messaging to remind donors of
upcoming appointments, sessions in their area and thank you messages after successfully
giving blood. The scheme was initially piloted with students [25] as they represented a user
group who had previously been difficult to keep track of when moving around.
There are a number of problems with text messaging which must be considered. Text
messaging from an organisation can be seen as invasive unless there is a good reason for the
message being sent. Unlike email, which is ‘pulled’ from the server and read when it suits the
recipient, text messages ‘push’ themselves onto the users phone. When the phone sounds an
alert to indicate the arrival of a new message there is no easy way of distinguishing between
an important message from friends or family and an automated message sent from an
organisation. If text messaging is being used as a marketing tool then it should be kept to a
minimum and only sent to those who have expressly consented to it.
Page 81
Many service providers and mobile phones also offer Multimedia Messaging (MMS),
which allows short videos and images to be sent in a similar way to text messages. There are
many possibilities for MMS technology and companies are only just beginning to make use of
the technology.
4.29.1. Economic viability
A number of respondents to the 2004 Virtual Promise survey [7] were concerned with what
they saw as the prohibitive costs of exploiting mobile technology, text messaging and digital
TV. This is likely to continue for the short-term while the technology is evolving and
maturing. Larger charities who can make a larger investment in their infrastructure have, and
are likely to continue to be able to, use this technology to their advantage.
4.30. Future: Content management
Content management is a popular way of allowing non-technical users to manage the content
of large websites. The basic principle is that the site layout is separate from the content. The
layout and site look could be designed by professional designers and coded by professional
developers and then the control of textual and basic graphical content is then empowered to
the staff. This produces consistent looking and powerful websites without burdening the
content creators with the coding of pages, or the management of files and links. Content
management systems tend to be used for larger web projects where the content needs to be
updated regularly without technical assistance. Content management systems require an
authentication system to define which users have access and editing abilities for which
content.
4.31. Summary of future
In Figure 24 some of the predicted future aspects of the framework are outlined, to act as a
reminder of the discussions earlier in this section.
Page 82
Figure 24. Summary of Future
In this chapter, the F4 Framework has been introduced, explained and detailed. The four
layers of the framework, Foundations, Fundamentals, Features and Future have been broken
down and explored. The framework model has been targeted specifically at charities but due
to the large overlap between business and charity issues, many aspects of the framework are
suitable for use in both sectors. For any type of organisation the framework should bring both
long term and short term benefits and cost savings. By being able to see tangible results at an
early stage of the process, the benefits of web enablement can be realised as soon as possible.
Now that the framework has been introduced, the next step is to give examples of how it can
and has been used in a real-world situation before moving onto an evaluation of its
effectiveness.
Page 83
Chapter 5. Case Study – GAP Activity Projects
This chapter introduces GAP Activity Projects, the case study being used to demonstrate the
ideas developed in the framework. It then goes on to describe how the framework has been
used successfully in projects at GAP. GAP is a non-for-profit charity which helps organise
gap year placements for 17-25 year olds. The main office employs approximately 30 staff and
there are a number of regional offices around the world. As well as paid staff, GAP also has
nearly 200 members of volunteer staff. The complexity, size and distribution of GAP as an
organisation makes it an interesting case study for the framework.
5.2. GAP Activity Projects
5.2.1. Who are GAP Activity Projects
GAP Activity Projects is the largest year out organisation for school-leavers in the UK. It is a
not-for-profit organisation, specialising in voluntary work placements overseas for 17-25 year
olds, in a transition year before going on to further education, training or employment. GAP
gives 17 to 25 year-olds the chance to live and work in a completely new environment with
the security of knowing that the placement they are going to has been checked by GAP staff.
In order to put the case study in progress it is useful to look at GAP’s vision and mission
statement:
“To be the leading provider of year-out experience for young volunteers worldwide.”
GAP’s Mission Statement is equally broad but with mention of the specific target audience of
young people.
“Our mission is to provide a distinctive and international volunteering experience, which is

inclusive to all young people. We will do this through a journey of discovery that fosters
independence, helps others and promotes global understanding.”
Page 84
The first key element of the mission statement, which affects the way GAP’s web enablement
strategy is developed, is to ensure that it is “inclusive to all young people.” This includes
making publicly accessible features easy to use, accessible to those with disabilities and in a
format which appeals to young people. The second key element is that it should be distinctive
(through use of innovative techniques) and international (to appeal to a worldwide audience).
5.2.2. Size
GAP currently arranges over 1,000 placements annually in 27 countries, for volunteers from
the UK and 750 placements in the UK for overseas volunteers. GAP has arranged almost
25,000 placements overseas since they started over 30 years ago. GAP is a small organisation
but with a wide reach.
5.2.3. What do GAP’s IT systems need to support?
GAP has over 250 volunteer staff around the world who work for expenses only, helping to
keep the costs to volunteers low, whilst enabling GAP to offer a wide choice of projects.
Volunteer staff work as project managers, interviewers, overseas representatives and in the
UK providing pastoral care to overseas volunteers. GAP estimates that the time given by
volunteer staff equates to the equivalent of 25 full time staff.
5.2.4. Offices worldwide
GAP has offices in Reading, England; Melbourne, Australia; Palmerston North, New
Zealand; Johannesburg, South Africa; and Vancouver, Canada. The UK office has 24 full-
time and two part-time staff, a large number of whom are returned GAP volunteers. The GAP
Australia office has five full-time members of staff with volunteer staff working in every state
and territory in the country. Both the South African and New Zealand office have one
member of staff and they are developing placements across their respective countries. GAP
Canada is managed and run by YouLead at the University of British Columbia and serves
Canada.
5.3. The University of Reading
GAP has useful links with the University of Reading and has plans for continuing these links,
beyond the scope and duration of the KTP programme that initiated the partnership.
Page 85
5.3.1. Student projects
Final year IT students at the University of Reading are required to complete a substantial
project in their final year. The projects are often suggestions made by academic and
administrative staff in the Schools of Systems Engineering. Projects based on actual needs are
preferred where possible and local businesses are often used as a source of projects.
GAP proposed two potential project briefs to The University of Reading and these
were offered to students looking for a project. Alistair Burnell, a Microsoft Student Partner
(MSP), chose to complete a project with GAP for his final year project. The project chosen
was the creation of a fundraising portal which sits alongside the myGAP website. The second
project, a brochure and literature request system will be offered to the next intake of students
later this year. Through the student projects, GAP has not only increased the strength of its
links to the University of Reading, but has also gained links with the Microsoft Academic
Team.
5.3.2. Student coursework
GAP currently uses a printed brochure as a major part of its marketing strategy. Because of
the size and weight of the brochure it costs a great deal to have printed, takes up a lot of
storage space and is costly to post. GAP was interested in looking at the viability of producing
a CD-ROM based brochure as an alternative to the traditional paper brochure. Normally this
would involve one or more commercial design agencies coming up with a prototype and
bidding for the contract. Using the links with the School of Systems Engineering at the
University, GAP was able to adapt the CD-ROM design brief so that it was suitable for an
MSc student group project. The outcome from this project was the production of prototypes
of a complete CD-ROM brochure, at no expense to GAP. The project provided the students
with real-life examples, making the requirements gathering and evaluation stages of the
project much more realistic than an artificial project.
Another successful project for both GAP and the University of Reading was a
coursework assignment for MSc students taking the Graphical User Interfaces module. The
task was to study and evaluate the websites of a number of gap year organisations including
GAP Activity Projects. As well as providing the MSc students with the opportunity to
evaluate a range of websites which they may not have previously come into contact with, the
results were passed on to the marketing team at GAP, acting as useful research material. The
Page 86
results of the study were interesting and have allowed GAP to make improvements based on
unbiased feedback and comparison from students in the target age ranges.
5.4. Implementing the framework
The main purpose of this case study is to demonstrate the framework being used and
implemented in a business critical situation. Now that GAP and the background for the case
study have been introduced we can look at how each layer of the framework was applied to
GAP and what features or changes were developed.
To give an overview, Figure 25 shows the F4 Framework with a mapping to each of

the key elements and modules that GAP developed and used.
F4
F3
F2
F1
Figure 25. Mapping between F4 Framework and case study
The case study uses the model and processes from the previous chapter and shows the
results of an actual implementation of the framework in a business critical real-life situation.
At the same time as demonstrating practical usage of the framework, the case study also
develops a number of tools and methods which are applicable to other similar organisations.
These are sometimes specific to GAP’s particular needs but many could easily be adapted and
used as the basis for web enablement in other organisations.
Page 87
5.5. Foundations (F1)
GAP already had most of the required foundations in place prior to using the framework but
the checklist and model was useful for ascertaining this. It is beyond the scope of this chapter
to cover the foundations at GAP in great depth but each core requirement is briefly described
below for the purpose of setting the scene.
5.5.1. Email
GAP staff have access to email on all networked PCs which they access using Microsoft
Outlook. A Microsoft Exchange server acts as a central store for all messages and is backed
up daily. Since upgrading to Exchange 2003 it is also now possible to access email externally
via Outlook Web Access which provides web access to emails from anywhere in the world.
5.5.2. Internet access
Internet access is provided through a wireless DSL (WDSL) connection which provides a
synchronous connection of up to 512 kbit/s upstream and downstream. Under normal use, this
can support up to 30 light web and email users. There is enough capacity for web applications
to be hosted in-house without any disruption to either local or remote users but it is expected
that as GAP expands its use of web technology, the connection may need to be upgraded.
5.5.3. Security
All GAP users have individual passwords, which are kept secret and must meet a certain level
of password complexity. A firewall blocks external access to internal servers, with the
exception of the web, FTP and mail server ports. The firewall also blocks external access to
dangerous websites. All desktop PCs, laptops and servers run Microsoft Windows and are
automatically patched with critical and security updates using Windows Server Update
Services, a central repository and management system. Finally, a McAfee anti-virus solution
is deployed on all computers and is centrally managed with McAfee ProtectionPilot. This
ensures that all computers are up to date, applies virus definition updates and allows
scheduled scans to be performed.
5.5.4. Software
GAP has bought the majority of its software at reduced charity rates. This has allowed it to
use industry standard software such as Microsoft Office, Adobe Photoshop and Macromedia
Page 88
Dreamweaver without paying full commercial rates. Using industry standard software is
useful when collaborating with suppliers and volunteer staff, as there are fewer compatibility
issues.
5.5.5. Data storage
GAP’s data is stored on three servers, organised by type – mail, databases and files. Data on
all servers is backed up nightly onto high-density tape using a rolling backup cycle. Backup
tapes are stored off-site in the event of a disaster. The hard drives on the servers are mirrored
which prevents most disk failure scenarios from causing data loss.
5.5.6. Programming platform
All of GAP’s applications for Windows and the web are written using the Microsoft .NET
Framework and Visual Studio 2003. The primary reason for choosing this platform was its
low cost due to charity pricing and its tight integration with the existing Microsoft
technologies already in use.
5.6. Fundamentals (F2)
As GAP had most of the foundations already in place, the fundamentals were where the
majority of initial work was carried out.
5.7. Fundamental: Membership – myGAP.org
5.7.1. Login and authentication
It was decided that the registration and authentication system would use email address instead
of a username. Many of myGAP’s users may not be regular visitors so it was decided that
asking them to remember a username could cause problems if it was forgotten between visits.
Email addresses have the advantage of being globally unique and, unless the user changes it
after first registering, they are easier to remember than a site-specific username.
5.7.2. Registration form
The registration form uses many of the techniques developed for the F4 Framework for online
forms. User entered data is checked by both client-side scripting and server-side scripting to
Page 89
ensure that the data is as accurate and complete as possible. The user’s email address and
password are asked for twice, to allow for a simple matching check to be performed. Rather
than asking for the email address the first time and then immediately asking for it again, the
second entry of these fields was put at the end of the registration form. The reason for doing
this is that some users are often tempted to simply copy and paste their previous entry to save
typing it in again. Unfortunately, this quick approach may mean that a typing mistake is
missed as the two entries match. By putting it at the end, the user is more likely to type it in
again rather than scrolling up to the top of the form and copying it from there.
5.8. Fundamental: Industry guidelines and best practice - GAP Website
Like many websites that were first developed a number of years ago, GAP’s website had a
number of issues in the areas of accessibility and standards compliance. In recent years the
importance of sticking to web standards and making sure websites are accessible to all users
has been highlighted but when GAP’s site was first developed many designers only worried
about whether it worked for unimpaired users using Microsoft Internet Explorer.
5.8.1. Removal of unnecessary scripting
The front page of the GAP site used proprietary VBScript and Internet Explorer specific
styling features to display a series of images which faded in and out. Although this looked
good, it only worked on some browsers, increased the size of the page dramatically and even
caused script errors on some incompatible browsers. Figure 26 shows the old site in two
different browsers and demonstrates that testing and developing for just one browser is not a
good idea.
Page 90
Internet Explorer 6.0 Firefox 1.06
Figure 26. Problems with proprietary code
The solution to this problem was to replace the fading images with a static image that
changed each time the page was visited. This allows a wide variety of images to be used on
the site and gives it a fresh appearance as visitors see something different each time.
Another area where the site used scripting but potentially alienated users was on the
side navigation menu. To provide a rollover effect some client-side scripting was used but it
had not been designed to fall back if the scripting engine was not available or was disabled.
This meant that unless Internet Explorer was used with scripting enabled, none of the links
could be visited. This also meant that search engine spiders could not get any deeper into the
site than the first page. The solution to this problem was to replace the script with standard
Hypertext Mark-up Language (HTML) hyperlinks and to use Cascading Style Sheets (CSS) to
provide the rollover effects. As well as stopping some users from visiting pages beyond the
home page, the previous method also restricted any search engine spiders from going beyond
the front page, reducing the exposure of the site to search engine databases.
5.9. Fundamental: Documentation
5.9.1. Wikis for documentation
GAP uses a Wiki to store documentation for its IT systems but only enables access to GAP
staff and only gives authorised staff editing rights.
Page 91
Figure 27. GAP's Documentation Wiki
5.9.2. Inline source code documentation
All of GAP’s recent development projects have been documented using the NDoc Code
Documentation Generator for .NET. NDoc is an open source project which uses a
combination of .NET’s reflection capabilities and the XML documentation files generated by
the C# compiler. Documentation is generated by the use of XML comments within the source
code, as shown in Figure 28. There are a wide range of tags for specifying different
documentation items and they can be used for documentation of classes, methods, events and
parameters. Some of the common XML tags used to contain documentation include
descriptions, parameters, return values, overloads, exceptions, cross-references and example
code.
Page 92
/// <summary>
/// Multiplies two numbers together.
/// </summary>
/// <param name="x">The first value</param>
/// <param name="y">The second value</param>
/// <returns>The value of x multiplied by y</returns>
public static int Multiply(int x, int y)
{
return x*y;
}
Figure 28. Example inline code documentation
The output can be generated in a number of formats, including HTML, which makes it
suitable for creating documentation for hosting on an intranet or extranet. The example in
Figure 29 shows a sample documentation output. All that is needed to create similar
documentation is correctly formatted documentation comments added inline with the code,
and the NDoc compiler which turns the source XML data into HTML.
Page 93
Figure 29. Example output from NDoc
5.10. Features (F3)
The bulk of this case study looks at how GAP has implemented features on top of the
previous two layers, Fundamentals and Foundations.
5.11. Feature: Sending multiple emails - GAP Mailer
Before GAP Mailer was developed, it was very difficult to send emails to large groups of
people without resorting to entering each recipient into the “To” “Cc” or “Bcc” field of the
email. This is a very bad way of sending multiple emails for a number of reasons. Unless the
“Bcc” field is used (blind carbon copy), then each recipient has access to the email addresses
and often names of each of the other recipients. Whilst this is acceptable for emails to internal
staff, who are willing for their details to be shared, it’s not good practice for promotional
mail-outs or event notifications. The second major problem is that emails like this are often
identified as possible unsolicited ‘spam’ email and may be blocked or filtered by the
recipient’s mail provider.
Page 94
The solution developed was to create a Windows application which could be used,
instead of Microsoft Outlook, to pull names from an Excel spreadsheet (Figure 30) and most
importantly, to send each recipient an individual copy of the email addressed only to them.
From the recipient’s point of view the emails appear to have been sent only to them, which
technically they have, reducing the chances of the message (Figure 31) being wrongly
identified as spam and removing any privacy concerns.
As an expansion of this basic functionality, it is also possible to customise each mail

further by adding more columns to the source document, the Microsoft Excel spreadsheet.
This is most commonly used to provide a personalised introduction to the email in the form of
“Dear Forename”. This adds the personal touch to each email and may improve the chances
of the email being read and actioned by the recipient. Further personalisation is made possible
by having an extra column of personalised information which can be placed anywhere in the
email using a placeholder. When the emails are sent the data in the third column replaces the
placeholder. This makes it easy to send, for example, emails to a group of potential volunteers
with their individual interview date and time as well as a personalised introduction.
Figure 30. GAP Mailer with addresses imported from Excel
Page 95
Figure 31. GAP Mailer showing message entry tab
After GAP Mailer had been used a number of times it was noticed that a large
percentage of emails bounced back as unrecognised or no longer active. The ability to contact
large numbers of recipients highlighted the need to keep email addresses up to date and to
make sure they were entered correctly. This was a good reminder of how important it is that
an organisation’s database is up to date and accurate so that email campaigns can be fully
effective. Unlike postal mail, which is often forwarded to the new address, incorrectly
addressed email usually bounces back with an unfriendly error message. As a small extension
of the GAP Mailer application, a small utility was created which searched the text of returned
emails and recorded the address which failed. This can then be cross-referenced against the
database to remove old records.
Page 96
5.12. Feature: Online community - GAP Community
5.12.1. Open source and free software
The software used by GAP’s community site on myGAP.org is a modified version of

Community Server by Telligent Systems Ltd1. Although not fully open source, the core
source code is published and community contributions are encouraged. This allowed the
software to be modified to fit in with the existing login and authentication system, which was
developed prior to the first release of Community Server. Open source software can be of
great use to the charitable sector. As well as being free to download, open source software is
fully customisable as long as there is sufficient expertise available to make the required
modifications.
5.12.2. Implementation
It was very important that if forums were implemented they would require people to login to
be able to post messages. This was so that any users who post can be tracked back easily and
warned or banned for inappropriate behaviour. To restrict forums in this way, a login system
was needed. Community Server uses its own login system, based on the early previews of the
ASP.NET 2.0 Membership functions. As myGAP already had a login system with many
registered users, there was a need to integrate the two systems so they would work together.
The approaches considered were:
• Replace the myGAP authentication system with the Community Server login system.
Although the Community Server system is more technically advanced it is also very
complex and would tie the whole of myGAP into a third party authentication system.
This could cause problems further down the line if the Community Server project ran
into difficulty and was no longer supportable. It could also limit any customisation of
the authentication system required by future projects built on myGAP.
• Replace the Community Server login system with the myGAP login system. This is
unfortunately extremely difficult to do, if not impossible, without a large rewrite of
major components of Community Server. Because the login systems are so different
and Community Server’s system is more complex and feature rich, the myGAP login
system was not suitable as a replacement.
1
http://www.telligent.com/
Page 97
• Use both login systems together with no integration. This is the simplest option but it
would have required users to register separately for the two different parts of the
website. The vast majority of users would find this confusing and irritating.
• Use both login systems but keep the Community Server login system behind the
scenes by creating a communication interface between the two different systems. This
was the chosen option as it allowed the minimum disruption to the two code bases but
gave all the functionality required for a seamless user experience.
5.12.3. Integrating separate login and authentication systems
Although the techniques described below were applied to myGAP (a bespoke system) and
Community Server (based on ASP.NET 2.0 Membership functions) the approach can be
easily adapted for limited synchronisation of many different systems and is not limited to
login systems.
The key to the integration was to create a web service which opened up a limited
interface to the required authentication and membership class methods of Community Server.
The only change made to the Community Server code-base was to add a new web service
(*.wsmx) file to the existing solution, as shown in Figure 32. This ensures that when
Community Server is upgraded and modified, there should be no complications other than a
few small modifications to the web service to reflect the functionality changes in the new
version.
The key tasks which needed to be possible were:
• Creating a new Community Server user when a new myGAP user is registered.
• Logging in a user automatically to Community Server once the user has been
successfully authenticated by the myGAP application.
• Synchronisation of usernames and passwords between the two databases.
• Automatic logoff if initiated from either application.
The diagram below shows the flow of information between the two applications. The myGAP
application makes requests to the web service layer which then performs the required action
and returns a response. For some tasks, the response is either a success or failure message, for
example to let myGAP know that the user has been created successfully. In other cases, the
response can contain data such as the role groups that a user is a member of.
Page 98
Figure 32. Using a web service to synchronise different systems
5.12.4. Results
The GAP Forums have proven extremely popular with over 3,052 users, 3,605 threads and
4,008 posts1 after just 6 months. As well as providing an incentive for regular visits from
users, they have also brought many of the advantages commonly obtained by adding forums
to a previously static site. Visitors are able to share their experiences and questions with their
peers in an open way without having to contact staff at GAP. Even for visitors who do not
have anything to contribute themselves, they can still read and search the previously posted
messages which can help answer many of the common questions. GAP staff have noticed a
marked reduction in the number of common questions they have to handle, giving them more
time to investigate more complex or urgent issues which people have.
5.12.5. Photo galleries
As well as providing forum facilities, Community Server provides a powerful system for
creating and organising photo galleries. This allows any member of staff to put photos from
1
As of 19th September 2005
Page 99
events online, as shown in Figure 33. Whilst the main website contains photos relevant to the
topic currently being viewed, a photo gallery as an entity in itself allows a much larger
number of photos to be displayed to those who are interested in seeing them without
cluttering the main website where photographs must be carefully selected. The photo gallery
is interactive and allows comments to be added, photographs to be rated and statistics to be
viewed. It is even possible to order prints of a favourite photograph. All this functionality is
made available by Community Server so there is no extra overhead for staff other than the
initial setup and creation of galleries.
Figure 33. Example of Community Server gallery image
5.12.6. Customisations
As well as the customisations made for the login and authentication system there were a
number of other changes which were made to the default Community Server application.
Because the full source code is made available, it is possible to get a very good level of
customisation. Small but critical visual differences made were in the appearance of the pages.
The GAP logo and taglines were used to replace the default graphics, the tabs for each section
Page 100
were modified and the colour scheme was changed to match the rest of the myGAP site. The
screenshots below demonstrate the changes side-by-side.
Figure 34. Default Community Server Header
Figure 35. Customised Community Server Header
Figure 36. Further visual customisations
5.12.7. Overcoming Globalisaton issues
The GAP Community can be accessed from anywhere in the world and anyone who takes the
time to register can post messages on the forums. At an early stage, GAP had to decide how to
deal with language use on the forums. It was important to set up any rules from the outset,
rather than being reactive to usage. The main concern was that non-native English speakers
would post messages in their local language, making it difficult for GAP staff to understand
and answer queries and potentially allowing unsuitable language and messages to be posted
without anybody realising. The only workable solution was to enforce English as the only
language which should be used on the forums. This has worked well, even though many
Page 101
visitors are from overseas and do not speak English as their native language. There have not
been any issues or complaints about the English language policy as most visitors are also able
to speak English in addition to their native language. Without this policy, it would be very
easy for a foreign swear word to be used unless it was recognizable to the moderators,
primarily English speaking staff working for GAP.
5.13. Feature: Online Forms – GAP Online Application System
5.13.1. Flexible error checking
The approach taken for input error checking was based on the loose validation concept
outlined in the framework. This means that the applicant will never find that they cannot
submit their form, even if there may be some mistakes in their application. Although this
sounds like a risky strategy, it has worked well. Due to the way the applicant is encouraged to
check for errors themselves there have only been a small number of cases where information
on the submitted form has been incorrect or missing. Compared to a paper application where
there is no validation at all, and handwriting can often be difficult to read, this is a great
improvement. Nobody has contacted GAP saying that they are unable to submit their
application because they cannot get past a rigid validation check.
Figure 37. Error checking before application submission
Page 102
Figure 37 is shown before users can submit their application. It shows which sections
of the form have passed the validation checks and allows users to see which parts of their
application they have or have not checked.
At the bottom of each page of the application form the user is encouraged to check
that page’s contents for validity. If the test passes then the last page of the application shows
this and the user is notified that all is well. If the checks fail, the invalid fields are highlighted
to allow the user to correct any mistakes before checking that section again.
Figure 38. Reminder for applicant to check the page for potential errors
Figure 39. Confirmation that the page validates
5.13.2. Automatic saving without user action
Because of the way ASP.NET handles post backs, it is possible to use any control to submit
the page (which comprises largely of a form). Normally form submission is limited to the
traditional post back methods of buttons or image buttons, unless client-side JavaScript is
written. ASP.NET deals with the creation of the client-side JavaScript automatically and
requires no extra code to be written by the developer. This was used for the online application
form to automatically save the applicants progress whenever a new page is visited. Normally
a multi-page form has a “Next” button at the bottom of the page which submits the data
entered so far and moves onto the next page. Using the navigation menu to submit the form
data allows the user to seamlessly move around the form without ever having to explicitly
save or submit each page of their application.
5.13.3. References
GAP requires all applications to include a reference from someone in a position of trust and
authority, who has known the candidate for at least two years. With the paper system this was
Page 103
on the last page of the application form itself and the applicant was required to pass this onto
their referee and then send the entire form to GAP once all sections had been completed. The
online application system still requires a reference, but it is done very differently. Once the
applicant has completed their application and made the payment, they are shown a screen
containing details on how to contact their referee. The preferred method is for them to enter
their referees name and email address, allowing an automated email to be sent to their referee.
When the referee receives this email, they are given detailed instructions on the
purpose of the reference, the importance of it and how to go about completing it. By visiting a
URL containing a unique code, the referee is presented with a form, similar to the paper
version, which allows them to fill in their reference online and then submit it instantly to
GAP. This improves the reliability and privacy of the information contained on the reference
as it is never seen by the candidate unless they request a copy. It also means that the applicant
does not have to hand over their application form to somebody else, something which could
take a while in some situations such as school holidays. Once the reference is complete, it
appears on the Online Application Viewer as a completed application. The applicant is sent an
email to inform them that the reference has been completed and their form is ready for
processing. The whole process is a lot faster than the paper method and reduces the time an
applicant has to wait before they can be considered for a placement.
5.13.4. Online Application Viewer
The Online Application Viewer (Figure 40) is effectively a replacement for an in-tray and
filing cabinet containing paper application forms. The interface is simple and initially consists
of a list of applications and a drop down list box, which allows the forms to be filtered
according to their status. The initial view shows completed applications, as this is the stage
where applications need to be checked by administrative staff. The stages of the application
process shown in the viewer are:
1. New/Incomplete – forms which have been started but haven’t yet been submitted.
2. Awaiting reference – when payment has been received and the form has been
submitted then the next stage of the process is for a reference to be obtained.
Page 104
3. Completed applications – these are ready to be reviewed and then entered into the
main database. At this stage the forms are usually printed or sent as an email to the
staff which arrange interviews and placements.
4. Entered into Core – an archive of applications which are in the main database, useful
for checking past applications and printing or emailing further copies if necessary.
Figure 40. GAP Online Application Viewer
As soon as an application is started it can be viewed ‘live’. This unique feature is possible
because the application is saved to disk automatically and regularly while the applicant is
filling it in. Being able to view the contents of an incomplete application can be very useful
for marketing staff who are able to see the progress of, and contact, potential applicants who
have not yet completed their form for one reason or another. When applications are awaiting
references it is possible to check the country which the applicant would like to visit before the
application is complete. This can particularly useful if placements in a region are becoming
Page 105
scarce as it gives prior warning and may allow the number of places available to be expanded
to meet demand.
Figure 41. Example of online application form in viewer
As shown in Figure 41, there are a number of additional options made available for individual
applications. The toolbar at the top allows applications to be copied to the main database once
they are complete, printed and emailed to a specified address. Sometimes references arrive by
post rather than using the online reference system. In these cases the Got reference? button
allows the application to progress to the next stage without requiring an electronic reference.
When an application has been inactive for a while, it is useful to be able to send the applicant
a reminder. The Send reminder button sends an appropriate message to the applicant
depending on the stage of the application process that they are in. In some cases, it may be
necessary to ‘delete’ an application. This option does not delete the application but marks it as
inactive and hides it from the viewer. The tool is more useful if it only contains live
Page 106
applications so it is useful to be able to remove the applications of people who have changed
their mind about applying or have also applied using the paper system instead.
5.13.5. XML application forms
Extensible Markup Language (XML) is a general purpose mark-up language developed by the
World Wide Web Consortium (W3C). Its syntax is very similar looking to HTML but unlike
HTML, it was designed to be used for more than one purpose. Unlike the early versions of
HTML, there are much tighter rules for writing valid and well-formed XML code. The strict
syntax makes XML harder to write than other text-based formats but it allows the contents to
be read and manipulated easily and accurately by machines as well as remaining human
readable. XML can be used for almost anything where structured content needs to be stored in
a text-based format.
XML documents were chosen for GAP’s online application system as the primary
method to store application forms, at all stages of the application process.
The other option considered was storage in a relational database but this would have
significantly increased the complexity of the data storage. Data stored in databases needs to be
strongly typed and often a maximum field length must be set. For an online application form
with a large number of fields and a variety of different data types, it is easier to store the data
in a weakly typed XML document. The XML application form is used at a number of stages
of the application process, as shown in Figure 42.
Page 107
Figure 42. Application Form Stages
The XML file is at the centre of the online application process from the start to finish
of the lifecycle. The first system to interact with the form is the ASP.NET online form which
the applicant completes and edits. Once this stage has been completed, the XML document
contains the majority of the application data. Until the applicant submits the form it’s possible
for them to come back to it and edit the content.
Page 108
Immediately after submitting the form data, the applicant makes a payment through
WorldPay and the data returned from this transaction is added to the application form so that
the transaction values are kept alongside the application.
The final stage of input comes from the applicant’s nominated referee who completes
a short form with a number of multiple-choice questions and an open text box for the
reference itself. Once this is submitted the data entered on the reference form is appended to
the XML document, thus completing the application form and making it ready for the next
stage of processing.
Prior to the web enablement of the application process, the application form, payment
and reference would usually come separately and would have to be collected and stapled
together before being processed and entered into the main database.
5.13.6. XPath for data extraction
One of the reasons for using a flexible and non-proprietary data format for the application
form are that no assumptions needed to be made about what the data will be used for once it
has been collected. GAP uses a Microsoft SQL Server database to store the key information
about new applicants but as XML is platform independent the data it contains can be used
with a variety of existing and future systems, as demonstrated by Figure 43. This flexibility
would be very useful if GAP ever changed its back-end database as the only code which
would need modifying is the layer which sits between the form and the database, the rest of
the system could remain unmodified.
Page 109
Application form
Personal details
Editable Medical information

School information Core
Applicant Placement preferences
Database
Reference
Referee
Payment Details
WorldPay
Hard copy HTML/Email

Figure 43. Uses for various sections of the application form
The data from the XML document can be easily extracted using the XPath document
query language. The .NET Framework provides classes for such queries in the
System.Xml.XPath namespace.
5.13.7. XSLT for data display
Although XML files are human-readable, their format is primarily designed for machine
reading and editing. Because GAP needs its application forms to be read by humans, a way
was needed of converting the XML file into a friendlier and more attractive format. XSL
Transformations (XSLT) provide a very powerful solution to this problem. The most useful
format for the application forms to be presented in is HTML, as this can be viewed and
printed on almost any modern computer as well as being emailable either as an attachment or
as part of an HTML email.
The process (Figure 44) requires three components:
• The original XML document which remains unchanged during the process
Page 110
• An XSL Stylesheet, which describes how to format the new document based on the
content and structure of the original XML file.
• An XSLT processor. The Microsoft .NET Framework provides this functionality in

the System.Xml.Xsl namespace.
Figure 44. Using XSLT for processing online application forms
Because the XSL Stylesheet is separate from the source XML document, it is possible
to use a variety of different style sheets depending on the desired outcome. For GAP’s
internal records, the stylesheet displays all the information entered by the applicant but if a
form is to be sent to an overseas host then some personal information and unnecessary details
can be hidden by using a different style sheet. A stylesheet can also convert an application
form from one XML schema to another, giving the flexibility to change the standard schema
but still keep older forms consistent with the new structure.
Page 111
5.14. Feature: Extranet – GAP Extranet
GAP used to lack a central starting point for staff Internet users. To encourage users to visit
GAP websites and internal tools without having to remember the web addresses it made sense
to have a single starting point that all users would see when opening their browser.
A survey of staff revealed that the majority had either Google or the BBC World News
website as their home page. Google was used as a starting point for web searches and the
BBC World News site was regularly checked by the Operations department in the event of
any natural disasters or other threats overseas. It was a good idea to carry out the survey as it
enabled the extranet home page to be developed as a useful resource and not something that
users would find an annoyance.
The extranet home page needed to contain a search tool, access to current news stories
and links to GAP websites and extranet resources. Links were easy to implement and the code
for querying the Google search engine is freely available from Google. A few small
modifications were made to allow users to search the World Wide Web, Google Images and
Google News by selecting the appropriate option from a dropdown list.
The news panel was more complex than the rest of the home page but thanks to the
BBC News headlines being freely available as an RSS feed it was possible to integrate both
the World and UK news into the extranet home page (Figure 45) without taking up too much
screen space.
Page 112
Figure 45. GAP Extranet
5.15. Feature: Global data access – GAP Alumni Update System
5.15.1. Alumni and the Business Partnership Scheme
All returned volunteers have the opportunity to join the GAP Alumni Club, which keeps them
informed of GAP events and allows them to keep in contact with other volunteers. Keeping an
up to date list of Alumni is important to GAP for many reasons. Some alumni volunteers are
recruited as part-time Promotions Officers who visit schools and colleges to give
presentations on gap years and GAP.
GAP operates a business partnership scheme with a number of large graduate

recruiters in the UK. The scheme has been running since 1989 and provides graduate
recruiters with the contact details, basic academic records and career aspirations of the
returned volunteers who opt-in to the scheme. This service provides an opportunity for alumni
to be contacted for summer vacation placements and job opportunities. GAP charges a small
fee for this service and provides records at the request of the recruiters. If the alumni records
are incorrect or out of date it reduces the value of the service so it is important that the
information can be quickly, regularly and easily updated.
Page 113
5.15.2. Issues with previous system
Prior to web enablement, the process of alumni updating was both expensive and labour
intensive. Each returned volunteer who GAP wanted to update their details would have to be
sent a letter and a form to fill in and return. This cost a lot in postage as well as the labour
costs involved with printing, packaging and sending the letters. To make things worse there
was also the added waste of letters sent to old addresses and the long delay between letters
being sent out and the form being returned. The information on the form then had to be
manually entered into the database, a time consuming process with the opportunity for
mistakes in the transfer.
5.15.3. Key benefits of web enablement
The alumni update system was in clear need of web enablement to cut costs and to provide a
better service to GAP, returned volunteers and business partners.
5.15.4. Method
The alumni update system was built as an extension to the existing myGAP member driven
website which gave the project a head start and a stable foundation to build on. Normally
when somebody registers on the myGAP site there is no way of knowing if they are already
on the main GAP database as the systems are not directly linked. Before somebody’s alumni
details, stored on the main database, can be updated there needs to be a way of associating the
myGAP login with the person’s record on the main database.
There are three possible situations which were looked at:
User group Registration and linking procedure
Unregistered user To link the myGAP account to the main database records, the user is
asked to provide their unique GAP Reference Number. This is listed
at the top of most letters sent from GAP, including the letter or email
asking them to update their details.
Registered user who If a user is already registered then changes to the registration process
has their GAP will have no effect. The solution to this was to offer the user the
Reference Number chance to enter their GAP Reference Number once they have logged
Page 114
in. As a security check the surname of the user is matched as well as

the reference number to prevent anybody accidentally or
intentionally falsely linking an account to an existing person.
Registered user This is the most complex situation as there is no simple way of
without a GAP associating the database records on each system.
Reference Number
Table 5. Registration and linking scenarios
Before the alumni update system could be used there needed to be a way of
associating accounts on myGAP with the person’s record on the main database. The table
below shows the methods that were used in each case.
Type Status Method
Registered and Not on main Do not allow linking

completed database yet
online Record of Already linked
application application on main
database
Paper Unknown Cannot do anything, probable if person cannot be

applicants found
Not assigned to a • Ask passport reference number (if not null)

placement • Ask interview date (if set)
• Else wait until the interview date is known
Requirements: 1 correct response
Assigned to, or • Ask passport reference number, if not null

away on, a • Ask country, if not null
placement
• Ask work type, if not null
Requirements: 2 correct responses
Page 115
Returned from • Ask passport reference number, if not null

placement or • Ask country, if not null
withdrawn early
• Ask work type, if not null
Requirements: 2 correct responses
All statuses where Allow the user to enter a message containing more
linking is details. This is then sent to GAP so that linking can
unsuccessful be performed manually.
Table 6. Account linking scenarios
Using a similar approach to the online application system, XML is used for the storage
of the completed forms.
5.15.5. Security
As the data being collected was of a personal nature (address, job details, career aspirations
and academic qualifications) it was important to make sure that the data was secure and could
only be accessed by the owner. Although the methods described above for linking the correct
account to the correct person were made as strict and secure as possible, there is still a chance
that a determined user would be able to identify themselves as someone else. Because of this
possibility, it was decided that the alumni update form would be blank, other than the name
and email address fields. This removes the risk of a malicious user being able to view the
personal details of somebody else. There is still the potential for somebody to be able to fill
the form in with incorrect information but this would only result in incorrect data being stored
on GAP’s database, it would not result in an external information breach. All changes made
by the alumni update system are logged on the main database, so any changes can be tracked.
5.15.6. Storage format
Again, XML was chosen as the data format for storing alumni update forms. The advantages
of this approach are the same as those gained by using XML as the format for the online
application form.
Page 116
5.16. Feature: Global data access – GAP Management Information System
Before this project, there was no Management Information System at GAP. For directors to
get the information they needed for decision making and planning, they had to perform
lookups and queries on various separate systems and put the figures together themselves.
5.16.1. Web-based MIS
The MIS is hosted within the GAP Extranet site, which makes it accessible to any user with
the appropriate permissions and password. This will later allow GAP to have one MIS for all
of its offices, picking up information from all locations and combining it for an overall picture
of the organisations performance based on key indicators.
5.16.2. System convergence
The MIS required convergence of a number of key systems:
• Core Database - as Core contains the majority of GAP’s everyday data and is easily
searchable, the important point for the MIS was to create useful summaries and allow
easy comparisons with previous dates.
• myGAP website.
• Brochure requests database.
• Online application system - the key indicators for this are the number of people at
various stages of the application process.
• External website statistics - The scope of integration with this existing system was
limited because there is no access to the raw data, only the summarised statistics
formatted as a HTML document. The HTML format was designed for presentation to
a human audience rather than for machine extraction of the data it contains.
Fortunately, an examination of the image and page filenames revealed that it was
possible to manipulate the URL to show data for the desired month. This allowed the
MIS to give users the ability compare results against previous months and previous
years.
• Internal website statistics - As there is easier access to the log files for the internally
hosted websites it was possible to setup the open source AWStats logfile analyser
which provides very detailed statistics.
Page 117
5.16.3. Legal aspects
As the site contains confidential performance related data, it was important to add a suitable
disclaimer to the first page of the MIS:
“Access to this site is limited to employees of GAP Activity Projects Ltd or temporary
members of staff engaged by or on behalf of GAP Activity Projects Ltd ("temporary
members of staff") only (in each case a "user"). Accordingly, if you are not an authorised
employee or temporary member of staff and you have not been issued with a username
and password by GAP Activity Projects Ltd, your access to this site is UNAUTHORISED
for the purposes of the Computer Misuse Act 1990 and you should exit it immediately. All
information contained on this site is strictly confidential to GAP Activity Projects Ltd.”
5.17. Feature: Global data access – GAP Project Profiles
In the domain of GAP a project is defined as a geographical area, usually a country but
sometimes a region of a country, i.e. Australia, South India or West Canada. These projects
are managed as separate entities and have different volunteer staff and in-country GAP
Representatives. The GAP Project Profiles system is needed for allowing global viewing and
editing of the data associated with each project. Prior to the web enablement of this system the
project profiles were stored as Microsoft Word documents, which were large and unwieldy.
Any changes to the documents had to be requested via email causing an administrative
overhead for the staff who had to do the editing work manually. The first part of the proposed
solution was to create a common layout for all project profiles with clearly defined sections
for each part of a project’s profile. The data is then stored in a database which allows
searching of content, access from other systems, regular backups and the ability to track
changes across versions.
One of the first difficulties to overcome in switching from a system using Microsoft
Word to a web based system, was the limited formatting available with standard HTML
forms. This was solved by using the freely available FreeTextBox control. This is an
ASP.NET server control written in C# for use in ASP.NET applications. The control is easy
to customise and works in both Internet Explorer and Gecko based browsers such as Firefox.
For the project profiles system the toolbar was customised to only show features which would
be used, reducing any potential confusion of users by having unnecessary features available.
Page 118
The control can be styled to match the style of Microsoft Office as shown in the screenshot
below which is using the built-in Microsoft Office 2003 style.
Before choosing this option for editing content it was important to ensure that it would
work for the vast majority of browsers and users as well as being simple to use. There are
other systems for entering rich text such as Bulletin Board Code (BBCode), primarily used on
message boards and forums, but they require the user to have some knowledge about the
syntax and the results of the code are only shown when the data is submitted. For the project
profile system to be able to reach to a wider audience it needed to be as simple to use as
possible.
Figure 46. FreeTextBox control in action
5.18. Feature: Global file access – FTP server
GAP’s head office in the UK stores much of its data on a network accessible shared hard
drive. This had worked well while the company was primarily based in the UK but since
expansion overseas, this approach was no longer suitable as there was no way of accessing the
information unless you were connected to the UK LAN. As well as the need for sharing
between offices, volunteer staff working from their homes also needed to get to some of the
data without having to request it by email.
Setting up a Virtual Private Network (VPN) is a popular method but is only suitable
for sharing to a limited number of offices as it requires a complex set up process and either
the installation of specialist hardware or software. For many of the volunteer staff, who may
need to access the information from a variety of locations, the File Transfer Protocol (FTP) is
Page 119
better suited to the task. Nearly all modern operating systems and therefore nearly all PCs
likely to be used by volunteer staff and overseas offices have the ability to connect to FTP
servers. There are many free FTP servers available which can be installed on existing servers.
In the case of GAP, the built-in Microsoft IIS FTP Server was used. At the time of writing
GAP is successfully using FTP to allow external access to files and VPN is being tested but is
not being used at the moment.
5.19. Methods and tools resulting from the case study implementation
As discussed earlier in the chapter, the case study supports the framework by demonstrating
that it can be used in a business situation and secondly, by leading to the creation of a number
of useful tools and methods. These methods and tools can be applied to many other
organisations, a summary of these methods and is shown below:
GAP Mailer This standalone application could easily be adapted for

use at any organisation which needed to flexibly send
bulk emails. There is even the possibility of packaging
the application up as a standalone product which could
be sold without modification.
Online Application System The infrastructure behind this application could be

General adapted to suit any multi-page, complex online form.
The main areas which would need to be changed are
the payment method and the number of pages and
fields the application form consisted of.
Online Application System The use of XML for saving the application form and
XML methods for manipulating the data within it for printing and
insertion into a database is a useful method and can be
applied to many situations, particularly those where it
is not possible to write data to a database straight
away. The use of XSLT to provide flexible visual
outputs is another key part of this storage method.
Page 120
Online Application System The concept of flexible error checking was developed
Flexible error checking for the Online Application System. This is a method
which, as far as the author is aware, is not being used
by any other web enabled service or application form.
It provides a good method for validating user input
whilst avoiding the possibility of a potential
volunteer/customer not being able to submit their
form.
Online Application System Giving referees the ability to submit references online
Online References is an important part of the overall application process.
The use of an XML application form allows reference
data to easily be added to the main form either at the
same time, or after the main application has been
submitted.
Alumni Update System The Alumni Update System solves a common problem
Registration which many organisations face. It demonstrates a

method for linking online profiles to a separate internal
legacy database system. The techniques used can be
adapted and used for many similar situations in other
organisations.
GAP Community This feature demonstrated that it is possible to

Integration integrate complex software into an existing web
application by using web services. By creating a basic
web service interface to the Community Server
software, it was possible to allow seamless integration
with GAP’s existing login system and to allow users to
have a single sign-on for all parts of the website.
Table 7. Methods and tools resulting from the case study implementation
The case study has shown how GAP Activity Projects used the framework to develop both
basic and advanced web enabled applications. GAP is still expanding on the applications that
have been developed and there are a number of new applications planned. The successful
Page 121
implementation and usage of the framework shows that the framework and the tools created
as a result of its implementation can be applied to a number of business critical systems.
Page 122
Chapter 6. Evaluation, further work & summary
6.1. Chapter summary
In this chapter, the framework as well as examples of its use and implementation will be
evaluated. The starting point for the evaluation is the challenges faced during implementation.
This leads to an evaluation of the effectiveness of the framework itself and a discussion of
ideas for further work, expansion and refinement.
6.2. Summary & critique
6.2.1. Did it meet aims and objectives?
Web enablement is a large and complex subject and it is outside the scope of this dissertation
to provide solutions to all aspects of the subject area. The framework offers a simple, yet
powerful, set of guidelines for web enablement and is suitable for many organisations, not just
small charities. Even so, this dissertation and the framework meet the aims and objectives set
out in Chapter 1. The framework is intended as a guideline and would need to be adapted for
different organisations, the framework pyramid model allows for this with no mention of
specific features, sizes or platforms that must be used. The key concept the framework is
ordered progress.
6.2.2. What makes the framework unique?
Unlike existing frameworks for web enablement, this framework has been developed from the
ground up for charitable organisations. It concentrates on the most important aspects of web
enablement and assumes that costs must be kept low. The framework does not make any
assumptions about existing infrastructure which must be in place, it is also possible to use the
framework model if web enablement work has already been started as the pyramid structure
still applies.
6.2.3. Is the framework suitable for a business environment?
As the case study has shown, GAP has successfully implemented the framework and is
continuing to develop new features and explore new technologies to expand it. That is not to
Page 123
say that there were not issues during the implementation but most of the issues were down to
unforeseen technical issues or user error and not a direct result of the framework model itself.
6.2.4. Benefits demonstrated by the case study
There were a number of benefits for GAP, a selection of these are shown in Figure 47
alongside the corresponding layers of the framework model. Even at the early stages of the
framework, there are benefits which become apparent.
F4
F3
F2
F1
Figure 47. Benefits for GAP
6.2.5. Scalability
The framework can be used by small or medium organisations without any need to redefine
the process or stages. For larger organisations the framework may also prove useful but is as
yet untested. As large organisations are more likely to have a good existing IT infrastructure
then the lower stages of the model may not be as relevant.
By using a scalable programming platform such as the .NET Framework there are
unlikely to be problems with scale. The .NET framework and its supporting applications of
SQL Server and Internet Information Services (IIS) are designed to be massively scalable and
were designed to be used with technologies such as load balancing and redundancy. The same
applied to organisations choosing J2EE and to a lesser extent, LAMP.
Page 124
6.2.6. Maintainability
By ensuring that security, data integrity and documentation are key aspects of the framework
the maintenance should be made simpler. A reliable and well-planned infrastructure and
foundations should require less maintenance than unstable foundations. Documentation and
adhering to best practices should ensure that maintenance work can be hassle free, even if the
original developers and management team have since left.
6.2.7. Industry recognition
The successful implementation of the framework by GAP Activity Projects was entered for
the Computing Awards 2005 in the Voluntary Sector Project of the Year1 category. The
project has been selected as one of the five short listed for the award in this category. The
awards are nationally recognised in the IT sector, being billed as the “Oscars of the IT
industry”. An article about the project is due to be published in Computing before the awards
ceremony on the 16th November 2005.
6.3. Challenges faced during implementation
6.3.1. Email address validation
Initially the myGAP authentication system required users to validate their email address
before logging in. After registration, the user was sent an email asking them to click on a URL
with an embedded activation code. This is a common technique used on many sites to get
round the problems of incorrectly typed or fake email addresses being used for registration.
Unfortunately, it confused many users who either had trouble activating their account, did not
get the email or ignored it and did not realise why they could not log in.
The solution to this was to loosen the requirements for logging in so that an
unvalidated user could log in, but they were not able to perform some functions until their
email address had been validated. A reminder is shown whenever a user with an unvalidated
email address logs in and the opportunity to have another validation email sent to their
address is given. This approach has been a lot more successful as it does not stop users who
misspell their email address from being able to view the forums or order a brochure but it
does stop users from applying unless they have valid email contact details. Email is often the
1
http://www.computingawards.net/shortlist.asp?id=0
Page 125
only means of contacting a user so it is essential that contact can be assured if they have an
application in progress.
6.3.2. Online application system
Due to the size of the application form and the number of questions asked, there were a few
cases where small typing mistakes in the code, such as misspelling the name of an XML
element, caused data either not to be saved when it should have been or for it not to be
displayed on the printout. Whilst this is easy to solve it can be hard to spot and depending on
the data affected, it took a while before anyone noticed. The greater the complexity of the
system, the harder it is to thoroughly test it. Some of the feedback received from applicants
who used the online application system is listed in Appendix A.
6.3.3. Automatic application form saving
As explained earlier in section 5.13.2. Automatic saving without user action, the application
system uses a novel method for saving multi-page form data which does not rely on the user
explicitly saving their progress. Whilst this worked well for users that understood the concept,
others became concerned that their data would be lost because there was no obvious way to
save it. Although the data is still saved automatically when the user navigates to a new page, a
button (Figure 48) was added to ease the concerns of some users who wanted to be in control
of when their data was saved. This was a valuable lesson in making sure that the user
interface suited the usage style of different users. Although one of the intentions of the
automated approach was to make things easier for the user it is perhaps too different to the
traditional approach which some users are used to.
Figure 48. Save Now button on online application form
6.3.4. Alumni update system
Initially a different approach to the one being used now was used when sending letters to
alumni who GAP wanted to update their details. Instead of sending the basic GAP reference
Page 126
number, their database identifier, a registration code was used. This was created by taking the
first three letters of the users surname and then running a hash on the identification number.
The reasoning behind this was to stop somebody guessing somebody else’s reference number
and therefore causing a security breach. Whilst this worked well for most people there were a
number of issues with it.
• Some users misread numerical zeros as the letter O and vice versa.
• If a user had not received the letter but wanted to register then a member of staff had
to be contacted and the appropriate code looked up.
• Codes had to be generated and users had to be pre-registered. This caused problems
when users tried registering, unaware of the pre-registration, and understandably
became confused that their email address had already been registered.
6.3.5. GAP Mailer
GAP Mailer was initially deployed as a remote application with the majority of code residing
on an internal web server. A small stub application was installed on users PCs which then
accessed the main application from the web server, updated the local cache and then ran the
application. In principle this was a good approach to application management as it meant that
any updates to the GAP Mailer application were automatically available to all users – the stub
application would always check for differences between the locally cached application and
the remote code. Due to limitations in GAP's network infrastructure this was initially the only
practical way of ensuring that all users were using the latest version of the application.
There were a number of problems with this approach, which meant it was later
abandoned. If the web server was unavailable, it meant that nobody could use the application
as the stub required the code on the server to be available in order to check for updates. There
were also a few occasions where changes in seemingly unrelated security settings on client
and server machines restricted access to remote applications. This configuration mismatch
usually resulted in error messages with little suggestion as to where the source of the problem
was. GAP Mailer uses a ‘legacy’ ActiveX control for the message body and this had to be
installed along with the stub application. As the control was not designed for .NET it was not
possible to update it automatically so there were a few cases of version mismatch between the
version of the control on the client and the version being used by the latest release of the
application.
Page 127
When GAP upgraded its network to an Active Directory structure, it gained a lot more
control over central application management so the previous approach to managing GAP
Mailer was abandoned in favour of automatic installation through Group Policy. This allows
an application to be assigned to a group of machines and automatically installed or uninstalled
on start-up. This now allows any future changes to GAP Mailer to be easily made regardless
of security settings, legacy control versions and web server availability.
6.3.6. User registration
Even with the thorough error checking on the registration form, some users still
managed to enter incorrect details. The myGAP registration form contains a number of
dropdown boxes; on some operating systems, the mouse scroll wheel changes the value of the
entry when a user is trying to use it to scroll down the page. This problem may explain why a
few registrants entered incorrect details such as their country of origin being incorrect. A
small number of registrants entered their surname and forenames in the incorrect boxes,
something that is hard for a computer to spot and, in some cases, difficult for a human to spot.
Some registrants entered incorrect email addresses, some of the mistakes included prefixing
the address with www. or adding @mygap.org or @gap.org.uk as a suffix. Fortunately, some
of the more common mistakes were easy to check for and the logic has been improved but as
with any online form, there are still opportunities for bad data to be entered into the system.
6.4. Future work
6.4.1. Globalisation
Although globalisation is a key issue with web enablement, the case study did not
demonstrate this aspect as much as it was hoped. Because of changes in GAP’s global
management strategy during the implementation of the framework, not all web enabled
systems needed to cater for a global audience were developed during the project lifetime. It
was decided that some of GAP’s overseas offices would manage their own web presence and
web processes rather aiming for a single point of access and management. Although this is
likely to happen eventually, it is still at the early stages of planning and is outside the
timescale of this dissertation.
Page 128
6.4.2. Mobile technology
There are many possibilities for exploring uses of mobile technology within the charitable
sector. As discussed earlier, many charities have already begun to use text messaging as a
marketing tool. With the emergence of third generation mobile technology (3G), there are
possibilities for transfer of multimedia to phones. This could be used for a number of
purposes, perhaps video updates on the work a charity is doing being sent to volunteers.
6.4.3. Refinement and improvement of the model
The framework model itself could be expanded to provide for a wider variety of projects, not
just web enablement. The pyramid is four-sided but only two of the sides are labelled, there
could be scope to add concepts to the remaining two sides to make the pyramid appear more
complete and the framework able to be applied to a number of situations.
6.4.4. Specialisation of the model
The model is generic by design but for some organisations with specialised needs, there is
scope for specialisation and variation of the model. Some organisations may have a small
head-office but many volunteers and satellite offices. These organisations might require a
different approach to web enablement, especially if management of the organisation is spread
over many sites and applications need to communicate with each other in a distributed
manner.
6.4.5. Team development
The framework does not explicitly explain how to use the framework when there is a team of
developers working on the implementation. Teams allow different projects to be worked on
concurrently and can significantly reduce the time it takes to complete a project. As the work
examined in the case study was all completed by a single developer, there are not currently
any examples of the effectiveness of the methods used when applied to a team.
6.4.6. Exploration of methods and tools
As discussed in 5.19, a number of methods and tools have been developed to support the
framework. Most of these are tied into the business processes of GAP Activity Projects but it
would be possible to take the core methods and tools and make them available for general use.
Page 129
The GAP Mailer application could easily be adapted to become a general-purpose

email application usable by many different types and sizes of organisation. Some of the
methods such as loose validation could be explored and defined as standalone methods
suitable for a number of similar projects.
In this concluding chapter, it has been shown that the framework is effective in meeting the
aims set out at the beginning of the dissertation. While there is still scope for improvement
and refinement of the framework it has been shown that it can be successfully applied to a
real-world organisation. The discussion of challenges faced during the implementation, and
their resulting solutions, will mean that other organisations can learn from the problems
encountered in the initial implementation. In terms of future work, there is plenty of scope for
incorporating new technologies into the framework. Mobile web technology is an emerging
area of growth and is therefore worth investigating further, as are the areas of content
management and further globalisation issues.
Page 130
References
[1] D. Chaffey, R. Mayer, K. Johnston, and F. Ellis-Chadwick, Internet Marketing: Strategy
Implementation and Practice, Pearson Education, Harlow, pp. 12, 2000
[2] Charities Act 1993 (c. 10);

http://www.opsi.gov.uk/acts/acts1993/ukpga_19930010_en_1.htm
[3] G. Peacock, “Charity Commission Annual Report 2005 - Report of the Charity
Commissioners for England and Wales for the year ending 31 March 2005,” March 2005;
http://www.charity-commission.gov.uk/Library/spr/pdfs/annrep2005pt1.pdf
[4] Charity Commission, “Income of Registered Main Charities In England & Wales,” March
2005; http://www.charity-commission.gov.uk/registeredcharities/factfigures.asp
[5] Commission Recommendation of 3 April 1996 concerning the definition of Small and
Medium-sized enterprises (SMEs), OJ L 107, p. 4., 30th April 1996
[6] A. Goatman, “Giving (in) to the Internet – Results of 2004 e-communications survey,”
Manchester Business School, 2004
[7] A. Spigelman and E. Evans, “Virtual Promise – From Rhetoric to Reality, A report on
charities’ use of the Internet between 2000-2004,” nfpSynergy, September 2004
[8] Web Content Accessibility Guidelines 1.0, World Wide Web Consortium (W3C);
http://www.w3.org/TR/WAI-WEBCONTENT/
[9] J. Wyatt, “E-enabling the voluntary and community sectors”, Hall Aitken, November
2001; www.e-envoy.gov.uk/assetRoot/04/00/08/28/04000828.pdf
[10] D. Wilcox and M. Pearl, “Civic and Community Technology”, The Journal of The
Communications Network, Vol. 1. Part 1, June 2002
[11] D. Wilcox and T. Grunwald, “Avoiding the technology trap”, Making The Net Work;
http://www.makingthenetwork.org/tools/matrix.htm
[12] M. Stein and J. Kenyon, The eNonprofit: A Guide to ASPs, Internet services, and online
software, CompassPoint Nonprofit Services, 2002; http://www.compasspoint.org/enonprofit
[13] C. C. Selby, “Better performance from ‘nonprofits’”, Harvard Business Review, 56(5),
pp. 92-98, 1978
[14] Cravens, J. (2002), “Barriers to being online”, Coyote Communications;

http://web.archive.org/web/20040205162500/http://coyotecom.com/online1.html
[15] Data Protection Act 1998; http://www.opsi.gov.uk/acts/acts1998/19980029.htm
[16] Disability Discrimination Act 1995; http://www.disability.gov.uk/dda/
Page 131
[17] P. Russo and S. Boor, “How fluent is your interface? Designing for international users”,
INTERCHI '93: 342-347, 1993
[18] Neilsen, NetRatings, 2005; http://www.nielsen-netratings.com/
[19] Microsoft Developer Network, “What is the Common Language Specification?”

Microsoft .NET Framework Developer's Guide, 2005; http://msdn.microsoft.com/library/
[20] OneStat.com, “Mozilla's browsers global usage share is 8.69 percent according to
OneStat.com”, Press Release, April 2005;
http://www.onestat.com/html/aboutus_pressbox37.html
[21] K. Miyata, J. Boase et al., “The Mobile-izing Japanese: Connecting to the Internet by PC
and Webphone in Yamanashi”, 2003;
http://www.chass.utoronto.ca/~wellman/publications/webphone/Webphone-PC-Norway-
FINAL.pdf
[22] Trintech Group, “Statistics for Mobile Commerce”, ePaynews.com, 2005;

http://www.epaynews.com/statistics/mcommstats.html
[23] C. C. G. Garofano, “Market Share: Mobile Connections, Western Europe, 2Q05”,

Gartner, August 2005
[24] Mobile Data Association, “Messaging Marches Ahead” April 2005; http://www.mda-
mobiledata.org/mda/documents/messagingmarchesaheadmarch05.pdf
[25] BBC News Online, “Give us UR blood,” September 2001;

http://news.bbc.co.uk/1/hi/health/1531142.stm
All web addresses referred to in this dissertation were verified on 18 September 2005.
Page 132
Bibliography
The books listed below were used as general reference material.
D. Watkins, M. Hammond and B. Abrams, Programming in the .NET Environment, Addison

Wesley, London, 2002
J. Yunker, Beyond Borders: Web Globalization Strategies, New Riders, London, 2002
D. Ince, Developing Distributed and E-commerce Applications, Addison Wesley, London,

2002
S. McConnell, Code Complete: A practical handbook of software construction, 2d. ed,

Microsoft Press, Redmond, 2004
C. Avgerou, Information Systems and Global Diversity, Oxford University Press, Oxford,
2002
D. Chaffey, R. Mayer, K. Johnston, and F. Ellis-Chadwick, Internet Marketing: Strategy

Implementation and Practice, Pearson Education, Harlow, 2000
S. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press,

Redmond,1996
J. Zeldman, Designing With Web Standards, New Riders, London, 2003
T. Connolly, C. Begg and A. Strachan, Database Systems: A Practical Approach to Design,

Implementation and Management, 2d. Ed., Addison-Wesley, Harlow, 1998
C. Sells, Windows Forms Programming in C#, Addison-Wesley, Harlow, 2004
M. Morrison, Teach Yourself XML in 24 Hours, 2d. Ed., Sams Publishing, Indianapolis, 2002
S. Mangano, XSLT Cookbook, O'Reilly, Cambridge, 2003
Page 133
Appendix A
Feedback
The following feedback was received from users of GAP’s online application system.
“Brilliant idea, very easy to fill out, section checking very useful. Perhaps timekeeping
would work better if reference was obtained before application form was filled out, to avoid
last minute being out of control of the applicant?”
“Very effective way of sending details, and it works better as there is more space
compared to the written form. It is also very well laid out with the links. Login and log out
buttons could be useful, as I wasn't sure whether the data had been saved online.”
“The online application system was straightforward to use and seems to allow for a
rapid succinct application to be submitted.”
“Form was nice and clear, and worked well (not like those ones where you spend
hours filling it in and then you lose everything).”
“It would really help if you included the reference request section in the main body of
the application. I couldn't do the payment until all was ready to go - we had carefully made
sure everything else was done. Only then to discover - at a weekend - that you needed a
reference with an email address. This delayed everything.”
“An excellent service. No problems. Only minor comment: You could have been more
prescriptive with the personal statement. I wasn't sure what to write, or the ideal length of the
statement.”
“A clear and easy-to-use application method. It's especially helpful to save

information on your form as you complete it.”
“I found the online application form one of the easiest I've ever filled in. It was really
well set out and simple and easy to understand and I got it filled in quickly.”
“Very efficient service. I knew exactly what I had to do. Excellent way of checking if
you made a mistake or missed something out!!! Really good!”
Page 134
Appendix B
This appendix contains large, blank diagrams which can be printed and used for reference.
Progress flow chart

Maintenance continues
throughout all stages
Future becomes Feature
Page 135
Foundations (F1) Checklist
Page 136
Summary of Foundations
Page 137
Summary of Fundamentals
Page 138
Summary of Features
Page 139
Summary of Future
Page 140
Feature Planning Matrix
Later
Time needed
Soon
Page 141

A Global Web Enablement Framework For Small Charities and Voluntary Sector Organisations

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Global Web Enablement Framework For Small Charities and Voluntary Sector Organisations

Uploaded by

Copyright:

Available Formats

A Global Web Enablement

Framework for Small Charities and

School of Systems Engineering

A dissertation submitted in partial fulfillment of the requirements of

Chapter 1. Introduction ......................................................................................................... 1

Chapter 2. Literature review............................................................................................... 12

2.3.2. Application Service Providers (ASPs).............................................................. 17

Chapter 3. Problems to be solved........................................................................................ 27

Chapter 4. The F4 Pyramid Framework............................................................................ 39

4.1. Chapter outline ............................................................................................................. 39

4.14. Fundamental: Error handling ....................................................................................... 63

Chapter 5. Case Study – GAP Activity Projects................................................................ 84

5.2. GAP Activity Projects.................................................................................................. 84

5.14. Feature: Extranet – GAP Extranet.............................................................................. 112

Chapter 6. Evaluation, further work & summary .......................................................... 123

Figure 39. Confirmation that the page validates .................................................................... 103

Table 1. Locale codes combing location and language............................................................ 24

1.1. Chapter outline

1.2. Area of work

1.2.1. Definition of web enablement

World Wide Web

In the context of this dissertation, web enablement is defined as the process of

1.3. Charities and voluntary sector organisations

1.3.1. What is a charity?

1.3.2. Profitability vs. growth

1.3.3. Trustees and volunteers

1.3.4. Size variance in charities

1.3.5. Financial contribution of charities

£0 - £1,000 £100,001 - £250,000

1.3.6. Why do charities need to be web enabled?

1.4. Case study

1.4.1. Knowledge Transfer Partnerships

1.4.2. GAP Activity Projects

1. Demonstrate the importance of web enablement in the charitable sector.

2. Examine the current state of the art.

4. Show how the framework can be applied.

The wider aims are to be achieved by completing the following objectives:

4. Look at existing research which is relevant to the subject area.

5. Highlight the key problems to be solved, both technical and non-technical.

7. Demonstrate an implementation of the framework by use of a case study.

9. Offer suggestions for further work to expand the framework.

1.7. Key web enablement drivers

1.7.2. Cost cutting

1.7.3. Communication with volunteers

1.8. Overview of the remaining chapters

1.8.1. Chapter 2 – Literature review

1.8.2. Chapter 3 – Problems to be solved

1.8.3. Chapter 4 – The F4 Pyramid Framework

1.8.4. Chapter 5 – Case study – GAP Activity Projects

1.8.5. Chapter 6 – Summary, evaluation & further work

1.9. Chapter conclusions

Chapter 2. Literature review

2.1. Chapter outline

2.2. Previous research and studies

2.2.1. Giving (in) to the Internet

2.2.2. Virtual Promise

2.2.3. Hall Aitken

There were concerning findings regarding the ICT infrastructure of many

2.2.4. Civic and community technology

2.3. Existing models and frameworks

2.3.1. The technology trap

Figure 2. The Technology Trap

2.3.2. Application Service Providers (ASPs)