INDIVIDUAL COUNCIL WEBSITES

LOGONS Project INDIVIDUAL COUNCIL WEBSITES System Management for Business Managers and Best Practice Guidelines for IT Officers

ACKNOWLEDGEMENTS This document is an output from the TAS 2000/151 Common Usage Project funded from the March 2000 round of the Networking the Nation program. Wise Lord & Ferguson advice to advantage Wise Lord & Ferguson were the prime contractor for this project and components from their focus group work are included in this document. The majority of this document has een produced and written y Prologic who were sucontractors to Wise Lord & Ferguson. The strategic consultancies for the LOGONS Projects are under the guidance of Trinitas who have provided strategic oversight of this project.

Tale of Contents 1. INTRODUCTION...5 1.1 DOING THE BUSINESS OF GOVERNMENT...5 1.2 SO WHY A WEB SITE?...6 2. BACKGROUND...7 2.1 LOGONS...7 2.2 MARKET RESEARCH...7 2.3 THIS DOCUMENT...7 3. OVERVIEW OF BUILDING WEB SITES...8 3.1 MANAGEMENT...8 3.2 DIFFERENCES BETWEEN SITES AND OTHER SYSTEMS...9 4. SCOPING...10 4.1 OVERVIEW...10 4.2 DELIVERABLES...10 4.3 MANAGEMENT...10 4.4 PROCESS...11 4.4.1 Document Project Constraints...11 4.4.2 Identify Site Goals...11 4.4.3 Identify User Groups...12 4.4.4 Identify Users Needs and priorities...13 4.4.5 Identify Services (transactional and informational)...14 4.4.6 Choose Services to implement...15 4.4.7 Planning for later Phases...17 5. SITE DESIGN...18 5.1 OVERVIEW...18 5.2 DELIVERABLES...18 5.3 MANAGEMENT...18 5.4 PROCESS...18 5.5 OVERALL ARCHITECTURE DESIGN...19 5.6 MANAGEMENT DESIGN PROCESS...19 5.6.1 Define informational (content) management strategy...19 5.6.2 Define Transactional Service processing and ackend integration...21 5.7 USER INTERFACE DESIGN PROCESS...21 5.7.1 Define site naming and randing...22 5.7.2 Define Service grouping and Site structure...23 5.7.3 Design Navigation and discovery facilities...24 5.7.4 Test Structure and Navigation with Users...25 5.7.5 Visual Design...26 5.7.6 Test Visual Design with Users...27 5.7.7 Develop Prototype...27 5.7.8 Test Prototype with Users...27 6. SITE IMPLEMENTATION...28 6.1 OVERVIEW...28 6.2 DELIVERABLES...28 6.3 MANAGEMENT...29 6.4 PROCESS...29 6.4.1 Identify Hosting Approach...30 6.4.2 Develop or Customise Content Management System...31 6.4.3 Implement Content Management System...31 6.4.4 Develop or Customise Transaction System(s) and Interface(s)...32 6.4.5 Implement Transaction System(s) and Interface(s)...32 6.4.6 Develop and Test Presentation System...34 6.4.7 Integrate Presentation System with Content and Transaction Systems...35 6.4.8 Alpha Test Site with Users...35 6.4.9 Test Site technically...35 6.4.10 Beta Test Site with Users...35 Page 3

6.4.11 Launch Site...35 7. SITE MAINTENANCE...35 7.1 OVERVIEW...35 7.2 DELIVERABLES...35 7.3 MANAGEMENT...36 7.4 PROCESS...36 7.4.1 Maintain Site Currency...36 7.4.2 Review Site Performance...36 7.4.3 Enhance Site...37 7.4.4 Re-Market Site...37 8. CONCLUSION...37 9. REVISION HISTORY...38 10. DISTRIBUTION CONTROL...38 APPENDIX A: DEFINITIONS...39 APPENDIX B: SERVICE AREAS...40 MOST WANTED...40 :...40 MOST LIKELY TO BE USED...41 APPENDIX C: SUBJECT INDEX HEADINGS:...42 APPENDIX D: USABLE SITE DESIGN PRINCIPLES...44 SPEED...44 RELIABILITY...44 LOWEST COMMON DENOMINATOR...44 ACCESSIBILITY...45 NAVIGATION...45 Non modal...45 Where am I, Where can I go and How did I get here?...45 Searchers and rowsers...45 Page 4

1. INTRODUCTION 1.1 Doing the usiness of government The demand for government services continues to increase. But governments cannot cope with this new demand using traditional structures and usiness processes. They are too expensive, don t deliver the holistic approaches required to cope with complex issues, and leave the customers of government the people and usinesses it is there to serve frustrated and angry. It is just too difficult to respond to modern issues with old methods. We have entered a period that requires us to look again at how we do the usiness of government to rememer afresh that the role of government in a lieral western democracy is to make things etter. To do this we need to approach the usiness of government in a way that: works effectively given disparate and often unlimited demand, and finite resources is light handed in its touch on social and economic issues looks over the horizon to anticipate structural change and mitigate economic dislocation intervenes where the externalities are high and the private sector is unlikely to invest in a socially optimal way. Traditional approaches can no longer deliver what is required. We are at the very eginning of this new wave of modernising government and the way ahead is not always clear. But several key elements stand out. The first is the need to separate the front-end experience of government from its ack end systems and structures. We force citizens, customers, usiness and third party service delivery partners to navigate their way through government. We force them to cope with complex organisational structures, to know the oundaries etween areas of responsiility, and to learn the technical usiness processes we use for our own purposes. Government is too complex for this approach to work any longer. It imposes too great an opportunity cost on the community. This is not to say that government shouldn t organise itself internally and conduct its own usiness processes in the most efficient way. Rather, the new way of doing government requires us to draw a clear distinction etween what happens in the engine room and what the customer or partner experiences. The second key element is the need to join up its of government to meet complex challenges or provide new services at a low marginal cost. Complex issues require holistic approaches, agility and the aility to recomine existing resources to produce services that appear and act as if they have een uniquely created to fill the specific need. This must operate within organisations, etween Councils and across tiers of government ut it does not mean aandoning functional usiness units or organisations. Organisational silos exist ecause they are an efficient and effective way to deal with much of the usiness of government (and usiness and other areas of activity which require differentiation on the asis of expertise, geographic location or other reasons). But they are no longer sufficient to meet the needs of the community. Rapid structural change in the economy is essential if Australia is to maintain and improve its position relative to competing nations ut it rings with it economic dislocation. Economic, technological and social change can remove social infrastructure and weaken social faric. Government can only act to make things etter if it is ale to act outside of the constraints of its day-to-day structures. We need new governance models, new approaches to managing information and services, and new infrastructure if we are to respond in a truly joined up way. The third element is the need for shared services across government to make the necessary technical, information and managerial infrastructure affordale and to manage the technical, capital and knowledge risk associated with it. We need to separate logical (usiness process) custodianship from Page 5

physical (hard assets) custodianship. We need to recognise that sharing does not mean a loss of autonomy ut a gain in depth of capaility. The final element is likely to e the most profound in its effect on doing the usiness of government. It involves a fundamental shift in centricity in who sits at the centre of the fundamental decisions aout defining need and assemling the services that are required to meet the events associated with that need. We are still locked in a government centric model. We decide on the services that will e availale, and that is a legitimate role for government. But we then assemle and present those services in a way that reflects how we operate rather than how our customer views the events they are facing in their life or usiness. We force people to think like governments, not like people. They don t like it and, increasingly, it doesn t work. This is not to say that there hasn t een change and reform. Government service delivery has improved dramatically as delivery channels and systems have adopted an eyes from the queue approach. However, at their core, they remain centred on the government process not on the customer. We need to change this to move through a centricity of need (where services are assemled and presented as if they have een uniquely designed to meet a life or usiness event experienced y an average person or usiness) to true customer centricity. Here the customer is ale to assemle a package of services that meets the unique circumstances of their life or usiness event. 1.2 So why a we site? The new ways of doing the usiness of government outlined aove, and more that have yet to emerge are only practical and affordale if they are supported y online technology networked information and communications technology. By itself, online technology doesn t modernise government. It cannot provide the fundamental changes in thinking, in usiness processes and in managerial systems that are required. But it does provide the platform for reform a way to separate the front end experience from the ack end structure and processes of government, to join up government and recomine services at low marginal cost, to share infrastructure, and to support true customer centricity. It is primarily and centrally a usiness platform central to the operation of Councils, not a peripheral technical issue. That is why this guide is aimed at usiness managers as well as technical experts. But the technology can t provide that platform if it isn t in place, if usiness managers are not familiar with its strengths and limitations, and if early enefits are not taken quickly to uild support for the new approaches. By itself, a Council we site is little more than a piece of technical wizardry, something you have ecause you feel you are compelled to have one. Expensive or cheap, high tech or simple, it will fail ecause it will have no usiness goals. Comined with an understanding of how it can e used to modernise government, it suddenly ecomes a powerful lever for change and a demonstration of what can e achieved. Because it sits at the interface etween the customer and government, it can deliver modernisation enefits even though the ack end systems may e old and in need of repair. It allows us to apply modern thinking while managing the investment and risk associated with changing usiness processes and systems. Having a pulic we site is not the same as using online technology to modernise government ut it is an essential and early step. This guide is designed to help usiness managers and technical experts to design Council we sites in a way that helps them capture the maximum enefit from their investment. It recognises that there are est practice ways of approaching the task and reflects very recent market research among a wide cross-section of the usiness, community and individual customers of Tasmanian Councils. Of equal importance, it anticipates the Local Government Entry Point currently eing developed y the LOGONS Project. The Entry Point will e intelligent and add significant value to the online service delivery capaility of all Tasmanian Councils. It will directly address the theme of using Page 6

online technology to modernise government. Councils with well designed, usiness driven we sites will e ale to take maximum advantage of the Entry Point, avoiding the need for expensive reinvestment. Building a we site that helps modernise the usiness of government is a non-trivial task ut it is an important and worthwhile investment in making things etter. 2. Background 2.1 LOGONS Section needs to e moved to later on. The LOGONS strategy has een developed y the Local Government Association of Tasmania (LGAT) on ehalf of and in consultation with Tasmanian Councils. The project is steered y a committee of senior Local Government officers and has een designed to approach the issue of online service delivery on a whole of government/sector asis. The strategy highlighted the enefits for local government from a whole of government approach such as economies of scale and sustainaility. The Strategy focuses on the following: identifying customer needs in order that online services can e delivered in a way that reflects how people think aout local government services; maximising the interface etween the levels of government; the need for shared systems and infrastructure to minimise cost and maximise the speed y which councils will e ale to ring services online; and the access and take-up y the community of online services (demand activities). 2.2 Market Research A research project has een undertaken to identify the themes and events that are most applicale to people in their online interaction with councils. This will estalish the framework that will form the asis of the rollout of future electronic services across the state. The purpose of the research project was to ensure that information is delivered to users in a way which est meets their particular needs and creates compelling reasons for usinesses and individuals to participate in online dealings with local government. The expected outcomes of the project are to: identify the themes that est reflect how the people and communities identify, prioritise and express what they need to do with Councils; identify the events that people face in their life and usiness that involve or could involve Local Government services; and identify the individual services that people want to undertake together in service packages. 2.3 This Document This document uilds on the results of the Market Research and provides a set of guidelines to Councils implementing their own we sites. This is a separate deliverale to the Online Portal. Page 7

3. Overview of Building We Sites Organisations that intend to implement a we site need to do so in a managed way in order to ensure the est result. There are three key questions to e asked: What should e included in the site? (Site scope) How should the functions and information e presented? (Site design) How do we go aout implementing the site? (Implementation process) A key aspect of Internet sites that is often misunderstood is that every site is actually a system. That is from the users point of view there are functions that they can perform against it and information that it provides to them. This is true even of sites which are only a few pages linked together. Thus the creation or enhancement of an Internet site needs to e treated like any other system project and include a well-defined plan, level of design of the expected result and testing to ensure that the result meets the needs. 3.1 Management As with all system projects, management is a key aspect. This includes: Planning Assignment of roles, which includes: o Owner/Sponsorship o Oversight o Project Management o Quality Control o Project Team Status Reporting Risk Management Review and quality control approach Issue and Change Management Deliverale Management Resource management and involvement of various groups: o Councillors o Staff o Pulic/Users Page 8

3.2 Differences etween Sites and other Systems The fact that a site has a pulic face has a numer of implications: Pulic sites are unale to require their users to e trained. This means that the site must e intuitive or at least usale without external assistance. A related issue is the need to provide a help/support desk for users (and staff who cannot say read the manual ) If there is something wrong with a site then people will find out aout it. Not only that ut the prolem has a much greater chance to ecome widely known (e.g. via the media) than for an internal system. Thus Quality Assurance and especially testing is critical. The site will often e holding information on users. This comined with the horror stories aout sold or stolen information means that managing privacy is critical. The Internet has many lack hats that will e quite happy to either damage your site or steal from you or your users. The need for comprehensive and ongoing security is unarguale. The information on a site should never e out of date. The users have grown to expect that the latest information is always availale from the we site and dislike seeing announcements aout upcoming events that have already happened. These issues need to e handled, thus adding or emphasising steps in the implementation process. Page 9

4. Scoping 4.1 Overview The Scoping phase is the period during which the features required of the site are decided. This sets the scene for the following phases and ensures that the efforts applied are focused on the Sites Goals and the needs of the Users. The phase will egin once Council decides that it wants to introduce or enhance its Internet presence. This decision should also define a numer of Project Constraints as a whole, such as: Budget Deadlines (e.g. xyz functions to e availale y Septemer 200X ) Resources (e.g. only staff to e used or outsourcing possile) In addition there may e specific constraints on the Scoping phase itself. Additional information on this stage is availale through the Tasmanian State Governments - Government Internet Pulishing Standards (GIPS), see: http://www.go.tas.gov.au/infoman/gips/planingyourwe4.htm 4.2 Deliverales The key deliverales from this phase will e: Site Scoping document (may also e called Site Requirements) which documents the: o Project Constraints o Site Goals o User Groups o Users Needs and priorities o Potential Services o Chosen Services including a cost enefit analysis if required A plan for later phases: 4.3 Management The general management issues apply to this phase, however there are a few aspects that are of greater importance. The identification of the Business Owner or Sponsor is critical at this stage and the commitment of that person to the whole of the project is also important. In addition the creation of a Reference group amongst usiness managers is critical to the success of the implementation. This group will form the core of staff resources who can provide information on the various Services and how they are currently supported within Council. They will also e ale to identify where the introduction of an Internet ased delivery of a particular Service will impact on the existing infrastructure. In addition Council IT staff must e involved (especially if the project is to e partially or wholly outsourced) as they are the keepers of the existing system infrastructure, which will often e an important aspect in identifying which Services will e provided from the list of those possile those that should. It may well e that some Services that will not e offered on the site initially may e implemented over time as technology, internal Council systems and pulic demand for a Service changes. Page 10

4.4 Process Identifying the site scope involves the following steps: Document Project Constraints Identify Site Goals Identify User Groups Identify Users Needs and priorities Identify Services (transactional and informational) Choose Services to implement Document results of aove Planning later phases Each of these steps is explained elow: 4.4.1 Document Project Constraints This is the documenting of the Project Constraints as discussed aove in the Overview. 4.4.2 Identify Site Goals The first and most important item is to agree on what the Council is trying to achieve y implementing or enhancing a site. Common goals are: Estalish a presence however minimal, often as a asis for further development; Provide users with information so that they do not need to contact Council directly; Provide users a mechanism to complete transactions, oth financial and otherwise; Provide users the opportunity to e involved in decision making through various virtual community mechanisms (such as online discussions, votes, feedack etc); The specific goals decided upon will drive the rest of the process. They should e agreed upon and documented at the start of the project. Page 11

4.4.3 Identify User Groups Another key issue is to identify the main groups of people who may use the site, as they often have different needs. This is usually done through a consultation and market research process. As LGAT has already performed market research as part of LOGONS, this may only need to e confirmed. 4.4.3.1 LOGONS Recommendations The LOGONS Market Research project looked at two main ways to categorise users of Council sites. These are: Relationship Community Type The identified Relationship groups are: Residents/Ratepayers Businesses Tourists & intending residents This grouping was found to e quite significant in that the needs and attitudes of the groups were quite distinct (see the next section). The identified Community Types are: Uran Regional/Rural This grouping was also found to e significant (that is having different needs), however the differences etween the relationship groups had a greater impact. In addition, most Councils are predominantly Uran or Regional/Rural and thus this grouping is less important for a Council s own site. Page 12

4.4.4 Identify Users Needs and priorities Once the User Groups have een identified the next step is to identify what the needs and priorities are and how they differ across the User Groups. Again this is usually done through a consultation and market research process. As noted aove the LOGONS Market Research effort has already identified many aspects of this for Councils. 4.4.4.1 LOGONS Recommendations The main User Groups needs differed as follows: Relationship group differences: Residents require information more than transactions; Residents are more interested in the visual attractiveness of a site; Businesses are more focused on transactions; Businesses are more interested in function than form and require consistency among council sites; and Tourists & intending residents are interested in information aout the local area Community Type differences: Uran o Residents in uran regions with a higher need for information aout rights and responsiilities Regional/Rural o More focus on community information o More interest in local government usiness agendas, meetings, issues o More focus on meeting tourism needs through local government o People in some geographically small regional areas are more likely to utilise face to face means in their dealings with councils Page 13

4.4.5 Identify Services (transactional and informational) Once the User Group needs are identified, the identification of specific Services and Service Groups (or Packs) that are required. This stage is normally accomplished y a comination of internal data collection (e.g. statistics on Services used currently) and consultation with users. 4.4.5.1 LOGONS Recommendations Prior to the Market Research, LOGONS surveyed a numer of Tasmanian Councils and produced a list of potential services and Service Packs. The ase list is included as Appendix C. This was then used to cross check the results coming from the Market Research. The Market Research captured oth the most used and most wanted services and areas. The complete prioritised lists are provided in appendix B. The main information and transaction requests of oth usinesses and local residents have een analysed and can e grouped into six service areas: - 1) On-line permits, payments, licences and applications providing oth information aout the processes and the aility to apply on-line for food and dog licenses, permits for pulic events and alcohol, ooking of local facilities, planning and uilding approvals and ojections and the aility to pay parking fines and rates. 2) Regulations, y laws and responsiilities - aility to rowse and search regulations and y laws and determine government responsiilities y suject area. There should e links etween regulations and requests for action in the form of email contacts or online forms. 3) Property rates, planning, uilding & zoning - aility to access property information y property identifier numer in relation to planning approvals, rates and zoning information. Also aility to apply for uilding & planning approvals and pay rates. 4) Council services information and requests for action in relation to ruish removal, pluming and sewerage, animal services, health services and the environment. There should e links etween council services, regulations and y laws. 5) Community events, services and organisations local services, amenities, events, usinesses 6) Your local council: Business and information latest news, agendas, minutes, tenders, vision statements, future issues, voting on local issues, jo vacancies) Contact your council - consultation and feedack tools (complaints, emergency action requests, requests for information, suggestions, feedack with timely responses) Council contact directory - details of council staff and councillors (email, phone, position, key responsiility, picture) Suscrie to electronic newsletters - to receive notification of site updates and changes y local area. Page 14

4.4.6 Choose Services to implement Once the services have een identified and classified, there needs to e a process to determine which Services and Service Packs are to e implemented and in what order. This should e driven from the goals originally agreed and also ased on a Cost Benefit analysis. Final decisions may e hard to make at this stage, as, without design, costings may e of low accuracy or even not availale. The key differentiators etween various services are: Informational versus Transactional Depending on the nature of the information provision (especially volatility), Informational services are often cheaper to implement. In addition multiple Informational Services can often e provided with the one set of infrastructure (e.g. a Content Management system). Transactional Services often need specific software to e purchased or developed and as such are often more expensive. Maintenance and Resourcing requirements Informational Services often require significant ongoing maintenance, which imposes a Resourcing requirement on the Council. However, there may already e a need to keep the information up to date (e.g. a community calendar) and the extra effort to support the Site may not e extensive. Transactional Services need for maintenance and resourcing should e minimal, especially where they are linked to an existing ackend system. An item to note is that if users are identified (and authenticated) then this may have a significant maintenance factor. However, assuming that each Transactional Service requiring authentication can use the same set of user information (such as a directory) then the maintenance cost is only incurred once regardless of how many Transactional Services are implemented. Existing Systems and Infrastructure The decision to make a service availale through the Internet often depends on what automation already exists to support it. If the Council already has an internal system for managing a contact directory, it may e relatively easy to make the same information availale through the we site. The opposite is also true, if the Council currently tracks Dog Licences through a paper ased system internally, this makes the provision of we-ased interface more difficult. Availaility of Third Party Services In general the use of an existing facility (uy) is less expensive (and usually more controlled in cost) in the long run than the creation of new facilities (uild). In the Internet realm there is a general move to supplying functions through a Service Provider (often readged to reflect the sites own randing), rather than implementing them on each and every site. This option should e carefully investigated especially in light of the LOGONS Local Government Entry Point (LGEP) project. Possile sources of these facilities are: o LOGONS LGEP, once implemented, will have common functions which are specifically designed to assist Tasmanian Councils; o Other Government Facilities. For example the State Government has a numer of useful sites including: The LIST which provides geographical and property search facilities; Service Tasmania Online site provides cross Government level searching o Commercial Service Providers (often known as ASPs (Application Service Providers). These will provide generic facilities such as: Payment processing Memership Management Community and Communication facilities (such as discussion groups, mailing list management and chat rooms) Content Management The aove factors should e weighed up, and then a shortlist of expected services should e finalised. Page 15

4.4.6.1 LOGONS Recommendations While the LOGONS LGEP is still under development at the time of pulishing this document, it is suggested that Councils leverage as much as possile off the Services that will e provided via the LGEP. This is particularly important for meeting the needs of Business Users and those who need to deal with multiple Councils, as the LGEP will provide a standardised interface for the Services. The diagram elow shows how a service could e provided using a standard function of the LGEP and re-adging it. Council Site Dog Rego UI Dog Registration Processing Dog Registration Backend LOGONS LGEP Dog Rego UI Dog Registration Processing In this example the LGEP provides a standard Dog Registration Processing facility along with a User Interface (UI) (that is a set of pages which a users accesses to otain the Service). This Service is designed as a functional lock that can e used to uild other sites. In this case the particular Council site has provided its own UI ( re-adging the Service), while using the LGEP function to handle processing. In addition the possiilities exist for groups of similar Councils to ecome Service Providers (or to sponsor one) for Services that are not provided y LOGONS and are unlikely to e (such as regional specific Services). This has already een done (though more ackend focussed) y Burnie Council, which is acting as a Service Provider for smaller local Councils. There also is the possiility of developing a Service or Service Pack in this way and then selling it to LGAT to ecome part of the Portal. In respect to the provision of Informational Services, as noted aove, it is often an all or nothing approach. Once the decision to implement at least one Informational Service is made, the infrastructure (Content Management System) can often e leveraged to provide many Informational Services with little extra system expense. Note that this does not imply that they are zero cost as often the cost of creating and maintaining the relevant Content is significant. Page 16

4.4.7 Planning for later Phases This step is to take the outputs of the Scoping and identify how the design and implementation phases will proceed. The key questions here are: In house versus outsourcing Revised constraints (e.g. increased or decreased Budgets, changed deadlines) Page 17

5. Site Design 5.1 Overview Once the asic Scoping has een undertaken the next step is to produce a design. This will define: How the information and transactions are managed and integrated with existing systems; How the site looks and ehaves from a user perspective. 5.2 Deliverales The result of this phase will e: Overall Site Architecture and Technology Approach Functional Requirements for Content Management Design Specification for Content Management (Optional) Functional and Interface Requirements for Transactions Design Specification for Transactions (Optional) User Interface Design, including style manual Prototype of the User Interface 5.3 Management This phase needs the normal management practises for a system project phase. This phase or at least the User Interface Design is often outsourced. Therefore this would e wrapped into a Request for Quote/Tender and then managed as for any outsourced IT project. 5.4 Process The Design Process will entail the following steps: Overall Architecture Design Management Design o Define informational (content) management strategy o Define Transactional Service processing and ackend interfacing User Interface Design o Define Service groupings, Site structure and Navigation o Test Structure and Navigation with Users o Visual Design o Test Visual Design with Users o Develop Prototype o Test Prototype with Users Page 18

5.5 Overall Architecture Design There is a need to define the overall architecture of the Site. This is asically documenting the approach to e taken to each of the various major components and how these will integrate. The diagram elow shows the major components of a Site and how they relate: Presentation Content Management Backend Systems USER Internet Front End Transactions Firewall The Presentation components of the site are those that the users see and interact with. These are designed with aims of eing oth usale and attractive. As much as possile these should e separated from the actual processing facilities. The Content Management components are those that provide the storage and management of the informational items that are availale to users, such as papers, articles, newsletters, laws and rules, guidelines, etc. These components may e linked to ackend systems (such as internal document management systems) or standalone. The Front End Transaction components are those that implement the asic processing of transactions availale through the site. These may involve a comination of own data storage and interfacing to ackend transaction systems. As discussed under Choose Services to implement, there may e a comination of outsourced, purchased and uilt components and this step should identify how each of the major components will e implemented. The document produced in this step provides the framework for the rest of the design approach. This document should e updated when design of components changes the architecture. 5.6 Management Design Process 5.6.1 Define informational (content) management strategy A key issue with any site is how to ensure that information provided y the site is up to date. This is known as Content Management and the project needs to define a strategy to ensure this. The main options for a Content Management strategy are: Use an external service to update information, usually reformatting the information as provided y Council Employ specialist staff to produce, format and pulish content Implement a system which allows Council staff to update the information, approve its release and then pulish to the site The decision is ased on the following factors: Upfront versus ongoing costs Page 19

Control issues Speed of update Volatility of the information Resource commitments For simple sites with low volatility, it is often reasonale to use an external service provider (such as a We Design company) to create the site Content from information provided y Council. Once a site reaches a reasonale size and/or the volatility of the Content is greater than weekly, then a system is recommended. The Functions that a Content Management System needs are: Aility for Content producers to create Rich Text items (i.e. formatted, with pictures and links etc). In addition the user will often need to define a name of the item and a description. It is also often useful to e ale to attach extra items to a Content item (such as a PDF version of an Article) Aility for Content producers (and others) to categorise each Content item. This includes oth flat (such as item type) and hierarchical (such as relationship) categories, which will e used for locating the Content item within the site. The categories should also e ale to e flagged as visile or not to users and search engines. (Note that these categories along with the name and description are what is known as Metadata (see appendix A)). Workflow to manage the pulishing of produced Content. This will include one or more reviews/approvals of the Content, possile rejection and resumission and final pulishing to the live site. Comments and other feedack should e possile for reviewer/approvers. Controlled access to Content items. This ties into the workflow so that the item cannot change while eing reviewed. Version management so that changes do not result in the loss of previous information. This is particularly important given the rules aout pulic sector record keeping. Templating mechanism so that the Content is kept distinct from the presentation of the site (which is handled under the User Interface Design Process) Need to integrate into existing Council systems, such as document management, communication systems such as email and user management systems such as Corporate Directories. Note that these requirements still hold regardless of the facilities or even the use of a Content Management System. They will need to e done manually if not automated. The diagram elow is an example of the workflow that may e used with a Content Management System. Creator Editor Pulisher Create Sumit Review Pulish Notify Notify Notify Retire New Sumitted Approved Pulished Retired Re-Sumitted Revise Rejected Notify Most commercially availale Content Management Systems availale today are in fact Content Management and Presentation Systems, in that they provide at least some level of display of the Content. This can make it harder to integrate them with other aspects of the site (such as Transactional functions). Page 20

5.6.2 Define Transactional Service processing and ackend integration If any Transactional Services are to e implemented in a particular phase, the ackend processing needs to e specified and how this interfaces to the we site. This is the normal system specification process and can e treated as a su project using standard system project procedures. The major difference is that it should not specify the details of how the User Interface is presented to the user, rather define the actual information that is required and will e provided. As with any new function how this will e implemented when it is required to integrate with existing facilities, there exist options in terms of: Buying a system that performs the requisite transactions and integrating it into the ack-end. This may take the form of an add-on to or new version of the existing ackend system or may e from a different supplier; Replacing the existing ackend with a new system that also provides the Internet functionality; or Building specific Internet functionality and integrating it into the existing ackend. If the vendor of the ackend is not providing Internet functionality then the interface etween them should e ased on Industry standards as far as possile. The current preferred mechanism for this is ased on XML (extensile Markup Language see appendix A), though this is the information definition mechanism. The actual details of the interface are defined in terms of an XML schema and managed y one or more industry consortia. 5.7 User Interface Design Process The following are some issues that need to e kept in mind when designing the User Interface for Internet sites. In addition to its pulic nature, the technology of today s we also imposes some constraints on applications: You will generally never e sure exactly what is installed and working on a users PC; and since they are remote it is hard to force them to change their environment. The technology is ased on a page at a time model and as such there is little interaction etween the user and the system etween pages. Thus the system has to e ale to work on a click y click asis. Most users still have slow connections (90%+ in Australia) and thus are often waiting for the page to load. This has oth usaility and reliaility impacts. In addition the failure rates for page loads are often in the order of doule figures (i.e. 10%+), which implies that the site has to handle the possiility that the pages are not rendered fully or at all. The user is not under any control as far as what actions they can take. Thus the application cannot assume the order that they will do things (i.e. non modal). Page 21

The way that people use the We also impacts on how sites are designed. Research has shown: Scanners not readers User do not read a we page rather they scan it looking for highlighted items and other things that catch their eye. (Don t Make Me Think, chapter 2, author: Steve Krug, pulisher: Circle.com, reference: http://www.circle.com/krugook/index.html); First rather than Best Choice Users will take the first reasonale choice rather than consider and try to make the est choice when navigating a site (Don't Make Me Think, chapter 2, see aove for details); Muddling Through Users will only read the instructions as a last resort, preferring to try something and then deal with the result. They also will only other thinking aout a task if they feel it is important (this is why most people can t change the time on their VCR) (Don t Make Me Think, chapter 2, see aove for details); Searchers and rowsers Research (http://www.useit.com/alertox/9707.html) has shown that more than half of all users will search efore navigating and that 30% more will navigate through a few pages then search if they have not found what they need. Thus the search engine for the site needs to e well integrated and also users need to get to their target in only a few clicks if navigating. These issues require that the design of a site is focused more on usaility than other systems. There is an overview of Usale Site Design Principles in appendix D. Additional information is availale from the Tasmanian State Government GIPS site at: http://www.go.tas.gov.au/infoman/gips/uildingyourwe4.htm The process of User Interface Design is as follows: Define site naming and randing Define Service grouping and Site structure Test Structure with Users Visual Design Test Visual Design with Users Develop Prototype Test Prototype with Users Document Presentation These steps are descried elow: 5.7.1 Define site naming and randing An important issue when creating a new site on the We is what will the sites name e and how will it e randed (e.g. logos, colours etc). 5.7.1.1 Domain Naming An aspect of deciding on the name is to otain the required Domain Name. This is less of an issue for Council sites than for commercial ones. This is ecause the Domain Name for most Tasmanian Council sites is in the XXXX.tas.gov.au format and this name is otained through the Telecommunications Management Division of the Department of Premier and Cainet of the State Government. 5.7.1.2 Metadata Another aspect of randing is to ensure that the site Metadata is well defined. Metadata is the general name for information aout the site, such as description, ownership, currency (i.e. date last updated) and categories or keywords. This information is used y search engines, portals and other facilities that users utilise to locate sites. Page 22

The Tasmanian State Government GIPS has a detailed explanation of Metadata and the type of information required (see http://www.go.tas.gov.au/infoman/gips/uildingyourwe4.htm#retrieval and http://www.go.tas.gov.au/infoman/gips/metadataintroduction.htm) 5.7.2 Define Service grouping and Site structure Once the set of services is known then a process of identifying groupings needs to e done. This will identify those services that should e grouped together and which others should e linked to or referenced. A Site Designer or Information Architect, applying the known usaility principles to the results of the User Consultation previously carried out, will do this. 5.7.2.1 Structural Principals Research has shown that structuring a site so that it matches the users needs, can e up to 10 times more effective than structuring a site ased on the organisations internal structures. Thus the Services should e grouped and the sites asic structure defined around the way the users expect the Services to e grouped. An additional aspect is that users often think of a particular Service eing relevant under different categories and thus the structure should allow for the same Service to e availale through different paths 5.7.2.1.1 Terminology The terminology that the site uses to descrie Services and Groupings is important as it is a key part of the user eing ale to find what they need and interact correctly. Therefore grouping services which the user sees as related is acceptale, ut if the name they are given is not what the majority expect then they will have troule finding it. 5.7.2.2 Personalisation One way to allow for differences etween users when defining structure is to allow for Personalisation, this is where the site knows or learns aout the users preferences and displays options ased on those preferences. 5.7.2.3 Advertising Many sites include advertising as a way to help defray the costs of providing the site. This is less common on Pulic Sector sites and in general often annoys users. A decision needs to e made aout whether advertising should e allowed, how much and where on the site. Page 23

5.7.2.4 LOGONS Recommendations 5.7.2.4.1 Structural Principles The six key service areas previously noted (section 3.4.5.1) are recommended as the most appropriate structure for the site. 5.7.2.4.2 Terminology Residents often do not know Council terminology, ut use more general terms to descrie the Services they expected. Businesses, particularly those who deal with multiple councils, need consistency. They would prefer that all council sites utilise the same language, headings and navigation tools. The six key service areas that were previously identified (section 3.4.5.1) need to e descried using the language of users; the following are examples of possile section headings: 1. On-line permits, payments, licences and applications a. Paying rates, licences, fees and fines. Permits and applications 2. Regulations, y laws and responsiilities a. Searching legislation and regulations 3. Property rates, planning, uilding & zoning a. Building, Planning and zoning services 4. Council services a. Council services (Health, Parking, Garage, pets and animals etc) 5. Community events, services and organisations a. Local events and information 6. Your local council a. Contact council (feedack, requests, complaints). Your local council (agendas, minutes, usiness, contacts) 5.7.2.4.3 Personalisation Resident groups in particular were wary aout the collection and/or retention of personal information unless it is optional to provide this information. 5.7.2.4.4 Advertising There were two areas where advertising was seen (y the users) as worthwhile on a Council site, these were: The sections on local events and organisations for residents and areas devoted to descriing the local area to tourists; and The sections used predominantly y usinesses such as those related to property and licensing. The size and prominence of the advertising is an issue, and in particular no moving images should e included. 5.7.3 Design Navigation and discovery facilities A critical issue is the aility of users to find and use the various Services provided on the site. These are descried as the Navigation and Discovery facilities. People with different levels of experience and different needs navigate y different means. The site should offer multiple means of navigation. (See Navigation section under APPENDIX D: Usale Site Design Principles). The main types of Navigation and Discovery facilities are: Page 24

Search Search includes full-text or keyword searching of the sites content. This provides a way for the user to find an item y its content, rather than how it is named and located in the site. Menus Menus include in-page and drop down or pull out popups. These are a way to provide a set of likely next locations a user may want. They may show one or more levels in a hierarchy. Category Drilldowns Category drilldowns are a way for the user to choose from values in a category, and then e offered options in other categories ( drilling down ), until they locate specific documents. From the users point of view they are just like a set of menus, however, they are usually more dynamic than menus. For example, see the Service Tasmania site (http://www.service.tas.gov.au ). Choosing Education from the For Information category list gives a page (http://www.service.tas.gov.au/nav/topic.asp?topic=education) which has some direct links and also a list of categories which can e used to drilldown. Cross Referencing Cross Referencing is the provision of links from a page to related information. This may e in the form of a direct link or it may e via a category, thus returning a list of other items. Sitemaps Sitemaps show all the key sections of the site, usually in a tree format (similar to Windows Explorer for a PC hard disk). Breadcrum trail (also known as active reference) Breadcrum trails are a mechanism to show where the user is in the site and to allow easy navigation to higher levels in the site. For example if the user is at the Dog Registration Application page, under the Dog Registration section of the Permits and Applications area of the site, then the Breadcrum trail will e something like: Permits and Applications >> Dog Registration >> Application Form It is particularly important that these facilities are consistent and accessile across the site. 5.7.3.1 LOGONS Recommendations The LOGONS project includes the identification of Common Navigation and Discovery facilities. As such it is recommended that Councils design their sites so that the Navigation and Discovery facilities are as independent of the Content and its structuring as possile, so that it is relatively easy to take advantage of the Common facilities when they ecome availale. Examples of this are: Drop down or pull out menus on sites should e defined as a common element which is easily separale from the rest of a page; Search engine should e launched y opening a standard URL and any enhanced or advanced search should e launched only through a common page; Category drilldowns should e done in a way that the links uild up a search string and that the options displayed are consistent; Cross Referencing should e done such that page location, and title can change without the need for re-linking. 5.7.4 Test Structure and Navigation with Users It is important that the initially designed structure e tested with users. This is particularly important as users often say they want certain items, while when presented with a set they choose differently. Usaility testing is a specialist area, however, significant results can e achieved y just displaying the suggested structure and asking for user comment. Page 25

5.7.5 Visual Design The visual design of a site are those aspects which affect how it looks to the user, including: Page Layouts That is where individual items are located on each page Styles (e.g. Colours, fonts and other visual elements) Graphics An aspect of Visual Design is that the numer of variations of the page layout should e kept to a minimum. 5.7.5.1 LOGONS Recommendations 5.7.5.1.1 General Page Layout Most sites follow a standard page layout, which includes: Header Footer Optional left hand ar Optional right hand ar For the Header the following is the most common approach: Logo in top left of page, which also has a link to Home Site Title in middle or slightly to the left of center Optionally dropdown menus Optionally search ox (at far right) Breadcrum trail Page Title Optionally the page tale of contents For the Footer, the following is the most common approach: Common links (such as home, search, sitemap) Disclaimer (see elow) Page identification and currency information and link to feedack Links to parent or related sites For the left hand ar, the common elements are: Common links, not included in the Header or Footer Optionally search ox (if not in the Header). Some sites make it the first item in the ar while others make it the last. Links relevant to the current page, such as: o Family, i.e. parent, silings, children of the current page in the site hierarchy o Key cross references to other pages within the site and outside of it o Page tale of contents if not in the Header Optionally advertisements The right hand ar is used less often than the left and its likely elements are similar to the left. If oth exist these components are often shared etween the ars. Disclaimers provide a mechanism for the Council to e covered legally in respect to the use of the site. The Tasmanian Government sites use a common disclaimer (see http://www.tased.edu.au/wegov/codi.htm). 5.7.5.1.2 Home page design The following recommendations have come from the Market Research: Items (in addition to sujects headings in the six key areas) that were designed y users for a local government home page included: A suscrie to newsletters field An index of community links Page 26

A ox containing latest updates A search field to search the site As well as having a front page index that groups services under the six index headings, a drop down menu or a fast links index could include some or all of the following popular index headings. (These headings were derived y asking focus group participants to design their own home page using the headings that they thought were most appropriate.) Fast links Pets and animals Health Garage Roads Emergency Services Council Tenders 5.7.5.1.3 Use of Styles and Style Sheets Sites should use a minimum numer of styles and these should e defined using style sheets. In particular the numer of fonts and colours should e kept to a minimum and the cominations chosen so they don t cause prolems for those with disailities such as colour lindness. 5.7.5.1.4 Graphics The site should only contain small graphics that are relevant and descriptive and quick to download. This in general means that they should e less than 20K in size. 5.7.6 Test Visual Design with Users Again it is important that the visual design e tested with users. This can e done with a small group of potential users. They are shown a picture of how key pages will look and asked for feedack. 5.7.7 Develop Prototype At the stage that the design is mostly defined it is often worthwhile to construct a Prototype of the site to confirm the design. This is usually done using asic page creation tools in order to e quick and low cost. The prototype should include the Home page, most of the page types and enough specific pages that the users can see how the navigation would work. 5.7.8 Test Prototype with Users Usaility testing with Users should e undertaken. This involves a numer of users from each of the key user groups. Each user is individually given the prototype and an expected scenario of use and they attempt to use the prototype as though it were the full site. Their experiences and reactions are recorded and these are used to identify any usaility prolems with the site design. Page 27

6. Site Implementation 6.1 Overview Once the site has een designed it is then a matter of implementation. This will produce a working site which once tested can e launched. A key aspect which needs to e defined during this phase is how and where the sites various components will e hosted. 6.2 Deliverales This phase will produce: Hosting arrangements, including: o Contracts and Service Level Agreements Content Management system, including: o Initial site Content o Training of Content producers (usually staff) o Training of administrators o Documentation on System o Integration with presentation and documentation on such o Purchase Contracts, including Intellectual Property agreements o Maintenance Contracts Transactional function system(s), each including: o Initial data o Training of users and administrators o Documentation o Integration with presentation and ackends and documentation on such o Purchase Contracts, including Intellectual Property agreements o Maintenance Contracts Site Presentation: o Home page o Navigational mechanisms (including search) o Pages presenting Content from Content Management System o Pages presenting interface to Transactions o Templates, style manuals, purchased elements such as images and fonts o Results of Accessiility and Compatiility Tests o Purchase Contracts, including Intellectual Property agreements o Maintenance Contracts Page 28

6.3 Management This phase needs the normal management practises for a system project phase and in particular this phase is often outsourced. This would e wrapped into a Request for Quote/Tender and then managed as for any outsourced IT project. It may also e roken into separate pieces depending on size, say one for each of: Content Management System Transaction function system(s) Site Presentation For each piece that is managed separately there needs to e contractual arrangements in place. These should cover not just the initial deliverales, time and cost, ut also the following aspects need to e addressed: Maintenance and Support As with any system there will e a need for maintenance and support. The response times for prolems should e short, as any down time on a pulic site will e noticed and possily commented upon. Intellectual Property As with most systems, anything custom uilt should have its Intellectual Property status clearly defined. This is particularly so with the presentation aspects of a site, as many graphics designers see themselves as artists and prefer to hold the IP for their designs. This can e a prolem as it could prevent other suppliers eing used for maintenance. Limits of responsiility If the site includes components sourced from a numer of suppliers (including in-house), then their needs to e a clearly defined area of responsiility for each supplier so that prolem diagnosis does not degenerate to finger pointing. An approach may e to appoint a Prime Contractor who must solve the prolem, regardless of its source, ut this also has its pitfalls and is generally a short term approach during implementation. 6.4 Process The Implementation Process will entail the following steps: Identify Hosting approach Develop or Customise Content Management System Implement Content Management System Develop or Customise Transaction System(s) and Interface(s) Implement Transaction System(s) and Interface(s) Develop Presentation System Integrate Presentation System with Content and Transaction Systems Alpha Test Site with Users Test Site technically Beta Test Site with Users Launch Site These are descried elow: Page 29

6.4.1 Identify Hosting Approach The Council needs to decide where each component of the site will reside. The options are: In house This necessitates significant expenditure and ongoing maintenance of infrastructure (including servers, security and networking). However, it also simplifies the how to get the data ack prolem descried elow. Out Sourced This reduces the infrastructure cost and management, and is easier to account for on an ongoing asis (e.g. costs are reasonaly predictale). However, it makes the Council dependant on the Service Provider and also introduces the prolem descried elow. With all approaches there is a need to interface the Front End or Internet related components of the system with existing or new ackend components at the Council. There are a numer of aspects to this prolem: Security The front end facilities are exposed to the Internet and thus have to deal with potential security reaches. Standard security practice is to isolate these systems from the critical ackend systems. The thinking is along the following lines: If the front end is hacked and the users can t pay their rates over the Internet this is less of a prolem than if the main rates system is compromised and the Council loses track of who owes what. Efficiency Complex interfacing may drastically reduce the speed of a transaction. This would render the facility of low value to the users for the reasons descried under User Interface Design Process aove. Consistency If the systems are not directly connected in real time then issues of consistency are raised. For example if one person from a household pays the rates over the counter and then another goes to the we site to pay, it may accept the duplicate payment. For most Council systems this type of issue is low impact. The cases where this is a significant prolem are those where users transactions affect each other, such as a ooking system. The resolution of this issue is ased on an analysis of the interaction of the front and ackend system. If they can e run with atch updating etween them, then outsourced hosting is not a prolem. If there is a need for real time interaction then outsourcing ecomes more prolematic and the efficiency and security issues need to e resolved. Page 30

6.4.2 Develop or Customise Content Management System Unless the Council already has a Content Management System (CMS) in place, there will e a need to purchase or have uilt such a system. It is very unlikely that this will e uilt in house, as there are many off the shelf or previously uilt examples that can e leveraged. It may however e possile to implement a system in house which is mostly manual, if cost is a major constraint. Unless these are developed or customised in-house, the involvement of significant Council resources will e mostly at the end of the process. There will of course, e a need for Contract Management during the development stages, which should involve representatives of oth Council IT staff and Business Management. 6.4.2.1 System and Integration Testing Assuming that the Content Management System has een created, one of the key tasks for the Council in this phase is to ensure that the system is tested y the developers/suppliers and in particular tested against the environment in which it will e hosted. 6.4.2.2 Delivery of documentation Council will also need to e reviewing and signing off documentation. 6.4.2.3 Acceptance Test Planning Council will need to e planning for the training of staff on the use of the CMS and for performing Acceptance Testing on it. 6.4.3 Implement Content Management System 6.4.3.1 Setup Content Management Environment This stage will ensure that the entire infrastructure is in place for using the Content Management System. This may include installing software on users PCs and configuring access and users on servers. Page 31

6.4.3.2 Produce initial Content The Content that will e availale on the day of the Launch will need to e created. This may go on in parallel with the other tasks in this phase, up until Launch. This is usually the responsiility of Council, at least to provide the initial information on which the Content is ased. The information on a We page needs to e structured carefully to ensure its usefulness to users, it may e that an Expert We writer is employed to polish the information to form the initial Content. 6.4.3.2.1 Recommendations for Content Production Site users usually scan rather than read the content should e structured to ease this. The following are some suggestions: Use Headings and short sections of text Use ullet points for lists Place key content so that it appears on the first screen and does not require scrolling to find Break larger documents up into smaller chunks and link them together. Page total size should e under 30K if possile. Use standard and few fonts Use consistent styles across content 6.4.3.3 Train Content Management System Users User will e trained in how to create, review, approve and pulish Content. This will usually e the responsiility of the supplier, ut it may e done through a Train the Trainer approach, wherey the supplier trains key staff at Council and then they train other staff as needed. 6.4.3.4 Acceptance Test Content Management System Council should perform a set of tests to ensure that the Content Management System works correctly. This should test the system against those functions specified for it and also that it is efficient and reliale. 6.4.4 Develop or Customise Transaction System(s) and Interface(s) As previously mentioned these systems and interfaces may e developed in a numer of ways. Unless these are developed or customised in-house, the involvement of significant Council resources will e mostly at the end of the process. There will of course, e a need for Contract Management during the development stages, which should involve representatives of oth Council IT staff and Business Management. 6.4.4.1 System and Integration Testing Assuming that the Transaction System(s) have een created, one of the key tasks for the Council in this phase is to ensure that the system(s) are tested y the developers/suppliers and in particular tested against the environment in which they will e hosted. 6.4.4.2 Delivery of documentation Council will also need to e reviewing and signing off documentation. 6.4.4.3 Acceptance Test Planning Council will need to e planning for the Training of staff on the use of the system(s) and for Acceptance Testing them. 6.4.5 Implement Transaction System(s) and Interface(s) 6.4.5.1 Setup Production Environment This is usually a comined task etween the suppliers of the systems and the hosting organisation (which may or may not e Council). This step will ensure that the final technical environment (servers, networking, third party software (such as RDBMS) etc) is in place and ready for Acceptance testing. Page 32

6.4.5.2 Migrate or create initial data It is often the case that Transaction Systems need initial data. This may need to e created or it may e migrated from existing (usually ackend) systems. The responsiility for this may e with the system supplier or could e with Council or a comination. Page 33

6.4.5.3 Train Transaction System(s) internal Users Most systems will have aspects that are used y internal users; these may e solely management features or may include some transaction handling (such as authorisation of transactions efore processing). For any such functions there is a need to train the internal users. This will usually e the responsiility of the supplier, ut it may e done through a Train the Trainer approach, wherey the supplier trains key staff at Council and then they train other staff as needed. 6.4.5.4 Acceptance Test Transaction System(s) internal and interface aspects As noted aove many systems will have internal as well as external functions and these along with the interfaces to the ackend systems should e tested at this time. 6.4.6 Develop and Test Presentation System 6.4.6.1 Develop visual and navigational design elements This step is where the actual visual aspects of the site are developed. These will often e enhanced from those produced for the prototype and will usually e done y expert graphic designers and we developers. In addition this step may involve the purchase of third party images or other visual items such as fonts. Council s involvement will generally e in the role of reviewing the results and approving. 6.4.6.2 Create Presentation Environment There needs to e an environment setup to support the site Presentation. This can include we and application servers and possily some networking facilities as well. This will depend on the approach taken for hosting. 6.4.6.3 Accessiility Testing The presentation system should e tested for Accessiility. This ensures that the widest spectrum of the pulic (especially those with disailities are supported) (see appendix D for more information aout Accessiility). This may also include testing the Content against various measures such as readaility and vocaulary required. The developer of the presentation should do this, and the results of the testing supplied to the Council. 6.4.6.4 Compatiility Testing As descried in Appendix D, most rowsers support slightly different sets of features. Testing should e done on the most common rowsers to ensure that users can operate the site. The developer of the presentation should do this, and the results of the testing supplied to the Council. Page 34

6.4.7 Integrate Presentation System with Content and Transaction Systems Once the Presentation, Content Management and Transaction systems have een developed and tested individually, they need to e integrated and then the site tested as a whole. 6.4.7.1 Integration Testing This will involve performing example interactions (either location of information or processing transactions) with the site and ensuring that the results are correct. This should e done as a comined effort y the suppliers of each system, to a set of scenarios as defined y Council. The results of these tests should e provided. 6.4.7.2 Acceptance Test Content Management System external facilities Council should then perform a numer of tests on the Content Management System to ensure that it provides the Content to the Presentation system correctly. 6.4.7.3 Acceptance Test Transaction System(s) external facilities Council should then perform a numer of tests on the Transaction System(s) to ensure that it provides the Content to the Presentation system correctly. 6.4.8 Alpha Test Site with Users Once the site is completely integrated and working, a select group of Users should e located and asked to review the site. This is to ensure that no major prolems exist with usaility. 6.4.9 Test Site technically 6.4.9.1 Performance Testing The site should e tested to ensure that it supports the required volumes and response times. This should e done using similar equipment to that of real users (e.g. home PCs and modem internet connections). 6.4.9.2 Reliaility Testing The site should e tested for oth staility and fault tolerance. Staility is the aility to run for an extended period, which should e at least a few days. Fault Tolerance is ensuring that the site either does not fail when components fail (if redundancy has een implemented) or fails gracefully. 6.4.10 Beta Test Site with Users A final test should e done with select Users to ensure the site is ready. 6.4.11 Launch Site The Launch is when the site is marketed and then officially availale to the Users. The marketing of the site should use multiple means, e.g.. a rochure with rates, letterox drops or local television and radio. The enefits of using the Internet to conduct usiness with Council need to e sold (savings in time and money, increased knowledge aout local events, issues and planning). 7. Site Maintenance 7.1 Overview This phase is after the site has een launched and is live. The concentration is on ensuring that the site is performing well, is up to date and is meeting users needs. 7.2 Deliverales The deliverales during this phase are dependant on what happens, ut may include: Page 35

Site Satisfaction Reports Site Usaility Test Reports Site Performance Reporting Site Change Requests Site Change Projects documentation 7.3 Management The management approach during this phase is partly one of contract management (of the hosting, support and maintenance contracts) and partly one of facility management. This means that the site should e treated as an asset and its performance and state managed. One option is to contract for regular reviews of the sites performance and utility, or this may e done in house. Any changes that are made to the site system (as opposed to the information) should e managed as for a change project with any system and many of the aspects descried in previous phases may apply. Content changes should e managed through the Content Management process defined in the Design phase. 7.4 Process 7.4.1 Maintain Site Currency Maintaining the site currency is mostly aout ensuring the site Content is up to date. This is primarily a procedural issue, wherey changes to information held internally should trigger changes to the site content and site content items should e regularly reviewed for currency. All changes to Content should e done through the processes defined for the Content Management system. 7.4.2 Review Site Performance 7.4.2.1 Measure satisfaction Regular measurements of user satisfaction with the site provide an indication of which aspects may need enhancing. This can e done through usual methods of surveys, questionnaires etc. 7.4.2.2 Measure usaility At particular times it is useful to measure the usaility of the site. The likely times are: After the site or a significant change to the site has een launched When changes to the site are planned When the satisfaction results indicate a potential prolem This testing is done as for during the Design Phase and may e outsourced. Page 36

7.4.2.3 Measure Technical Performance The site has a numer of technical measures that should e monitored. These include: Response times Volumes Error rates User session information (period, paths taken, etc) This information should e compiled and used to identify prolems or potential prolems with the site. This may require extra software that provides the measurements or may e provided as part of the service y the hosting organisation. 7.4.3 Enhance Site 7.4.3.1 Specify site changes Any changes required need to e clearly specified. The process is a cut down version of the process used during the original Scoping Phase. 7.4.3.2 Design site changes As aove all changes should go through a design process as in the original Design Phase. In particular changes should have their impact on the User Interface evaluated. 7.4.3.3 Implement and test site changes As aove all changes should go through a test and implementation process as in the original Implementation Phase. 7.4.4 Re-Market Site The site should e re-marketed at the following times: Whenever changes are made When site performance measuring indicates that users are not aware of particular functions When site performance measuring indicates that usage rates are lower than expected Rather than expecting people to come to the wesite, it is important that designers uild in the capacity to take the wesite to the users. Users should e ale to suscrie to site update emails that will notify them periodically of changes to information in their areas of interest. 8. CONCLUSION The process of creating or enhancing a we site should e treated like any other system project with all the normal project management practices applied. This document has provided an overview on the process and some suggested approaches to various aspects. It should e used (along with other sources such as the Tasmanian Government Information Processing Standards (TGIPS)) to guide a Council through its move to providing services through the Internet and as a checking mechanism against plans and proposals for the various phases. Page 37

9. REVISION HISTORY Version Date Reason Version Upgrade 0.A 5 Octoer 2001 Draft for review - 0.B 8 Octoer 2001 Revised Draft for Review Replace 0.C 11 Octoer 2001 Revised Draft for Review Replace 0.D 17 Octoer 2001 Revised Draft for Review Replace 0.E 22 Octoer 2001 Revised Draft for Review Replace 0.F 23 Octoer 2001 Revised Draft for Review Replace 10. DISTRIBUTION CONTROL Copy Role Organisation Recipient 1 LOGONS Project Manager LGAT Andrew Koerin 2 LOGONS Consultants Trinitas Steven Haines 3 WLF Lead Consultant LGAT Anne Kerr 4 Prologic Consultant Prologic Sean Turner Page 38

APPENDIX A: DEFINITIONS An Internet or We Site is a set of information and functionality accessile y a user over the Internet and presented through a Browser. The site is a logical grouping though it is usually related to one Domain Name and associated URLs URL Locations on the internet are addressed y the use of URLs (Uniform Resource Locators) (e.g. http://logons.lgat.tas.gov.au/localgovtentrypoint.htm). These consist of a numer of parts, the most important eing the Domain Name (e.g. lgat.tas.gov.au) and the Page path (e.g. LocalGovtEntryPoint.htm). Domain Name The Domain name generally identifies the organisation that runs the site. A single organisation may have multiple sites (e.g. www.lgat.tas.gov.au and logons.lgat.tas.gov.au) which are distinguished y the server name (which is added to the front of the domain name). Page path The Page path is the address of a specific page within a site. It appears in the URL after the domain information. Browser The program a user has installed on their PC which presents we pages (examples are Microsoft Internet Explorer and Netscape Navigator). There are a numer of different suppliers each of which has produced a numer of versions. Each different version supports a different set of functions. An issue for creating we pages is to ensure that the maximum numer of users can see and interact with the page in a consistent way. FAQ Frequently Asked Questions are a common feature on we sites. They are asically a help mechanism. XML XML is a standard for defining data, so it is easy for oth humans and systems to read and manipulate. Most recent systems are using XML for interfacing and data interchange functions. Scenario A made up case of an expected use of the site, which is used as the asis for a Usaility Test session. Page 39

APPENDIX B: SERVICE AREAS The Market Research has identified Service Areas ased on two criteria: Those which the users most want Those which were most likely to e used Most Wanted : The following tale, illustrates the key service areas identified y the three usiness focus groups and the six resident focus groups. (They are shown in order of frequency with which they occurred across the groups). Business Regional Uran paying rates fees & charges/paying ills complaints, action, advice/contacting council property/building, planning & zoning community events, promotions, activities/your local council regulations Bylaws & responsiilities council services/community services(tips, sewerage, emergency, road closures, childcare, lirary, etc) council directory local or community events, usinesses, organisations, services & amenities council usiness/information- minutes, agendas, vision statement, strategic plan, upcoming issues, positions vacant, work programs ruish removal dogs, pets & animals tourism/local area information council tenders & Grants health & environment landcare, parks & reserves permits & applications search facility/site map needing help & action parking links to other sites engineering selling to council family & children services suscrie to newsletters & updates frequently asked questions family history Vote ox on local issues Page 40

Most Likely to e Used The following tale shows those service area headings and specific services that were voted y participants as those that they would e most likely to actually access if they were availale online. They are shown in the order of the frequency with which they were nominated across the groups Service Area Headings Business Regional Uran Building/planning approvals & ojections Local events, news and services Council contacts COUNCIL records (minutes, agendas) Council services rates, fines and licences searching Regulations Complaints/comments/feedack Health and food advice and licensing land zoning usage needing help/action parks & reserves tourist information Permits for events Property information - rural council tenders Contacting purchasing officers (orders, payments) Online application Section 337 links to other council regions Location of stop taps Online voting parking council vision/forward planning information on family day care Family history gis information walks Page 41

APPENDIX C: Suject Index headings: Action Animals & pets Appeals Approvals & permits Building & Planning Business information Businesses & organisations By Laws Complaints & Comments Community information Contacts Council minutes & agendas Council responsiilities Council services Council works Councillors directory Education Emergency Services & contacts Environment Enquiries Essential services Events and opportunities Facilities Feedack Fees & charges Fines Food Licensing Funding Government links Grants Halls Health & Environment Health matters Help Information Insurance Land information Landcare Local news & events New uildings/ventures New resident s information Parks & Wildlife Payments Permits Pets Planning permits & enquiries Planning & Building Positions vacant Property Pulic liailities Rates Recycling Regulations Relocation kit Resolve complaints Roads Page 42

Ruish Search Services Sewerage Staff State events State government Tendering The local scene Tips Tourism Venues Water Whose who Works plan Your responsiilities Zoning Page 43

APPENDIX D: Usale Site Design Principles As noted Usaility of a site is a key design issue. Various aspects are descried elow: Speed Research (http://www.useit.com/papers/responsetime.html) has shown the following: 0.1 seconds is the maximum time etween actions for the system to appear to e reacting instantaneously 1.0 seconds is the maximum so that the users flow of thought is not interrupted though they will see the delays 10 seconds is the maximum delay for which you will keep the users attention. Longer than this the user will start another task Due to the nature of the we even the 10 second one is duious, however, regular we users have ecome used to the slowness and don t get annoyed until the page time exceeds 30 seconds. The principle is the same, get the user some info as quick as possile. This leads to two ovious approaches: Reduce the numer of pages as each costs communications time Reduce the size of each page as this extends the time to download Unfortunately these are often a trade off and need to e managed as such Reliaility Another issue in usaility is the reliaility of the we. Browsers download different parts of a page as separate communications, each of which could fail. This is why sometimes a page will show ut some images will e missing. Applications should not depend on all elements eing in place or should check efore processing. In addition this failure can occur at any time, including when responding to a user action. Thus the user may think they need to perform the action again. This leads to cases such as where you can accidentally order multiple copies of something y pressing the Buy utton more than once. Again the system should e detecting these situations and handling them. Lowest Common Denominator Site Designers need to avoid assuming that the user has specific technology. This implies that the application should only rely on technology which 90% or more of the users will have. The following site provides statistics on Browser usage: http://www.upsdell.com/browsernews/stat.htm In particular the following page provides suggestions on how to avoid rowser specific issues. http://www.upsdell.com/browsernews/stat_des.htm Page 44

Accessiility A particular aspect of this is the need to support those with disailities (e.g. lind persons using reading rowsers). This does not mean that sexy technology cannot e used on the site, ut rather that the site does not rely on that technology (i.e. there must e a fallack, usually text ased). The following site provides a full set of guidelines, checklists and tips on how to design a site to avoid accessiility prolems: http://www.w3.org/wai/resources/ In particular the following FAQ page provides an overview on how to ensure that a site is compliant: http://www.w3.org/1999/05/wcag-rec-fact Also useful is a testing facility which checks that a site is compliant to the rules. This can e found via the link elow: http://www.cast.org/oy/ Navigation Navigation is a critical issue in site usaility. Non modal The first aspect of Navigation is that it cannot e modal. You cannot assume that a user will follow any particular path or proceed through any particular page (if they can get there). Security controls modify this, ut even there it is possile for a user to BACK out of the secure area and then try to FORWARD in again potentially causing a prolem. In general it is est if the site makes no assumptions aout the path taken. Where am I, Where can I go and How did I get here? The key questions the user will ask when navigating are: Where am I?; Where can I go?; and How did I get here? A key issue for the application is to ensure that each of these have an ovious answer at any time. This includes clear page titles and readcrum trails, clear options and menus and reliale history. Searchers and rowsers Research (http://www.useit.com/alertox/9707.html) has shown that more than half of all users will search efore navigating and that 30% more will navigate through a few pages then search if they have not found what they need. Thus the search engine for the site needs to e well integrated and also users need to get to their target in only a few clicks if navigating. Page 45