Example 1: the temporary website
- Within this section:
- The overseas disaster scenario
There are a great many circumstances where Government needs to communicate with citizens on a highly topical matter. In many cases, the public is concerned with an issue that is gaining wide coverage in the media, and the Government needs an effective way of communicating and providing a mechanism for people to air their concerns. In the vast majority of cases the issues arise unexpectedly, so there is a need to respond quickly; communication and feedback channels must be established immediately and cost-effectively to provide a timely way to address public concerns.
In this environment, the Internet is a valuable tool. As well as being more focused than media statements and able to deliver more information more quickly, it offers the ability to act as a two-way information conduit; the public can direct comments, questions and concerns back to the Government using the same interface. In addition, the web is a cost-effective channel, with dramatically lower costs than public information campaigns through the traditional media.
So much for the good news. But how does the Government create a suitable site quickly whilst preserving the natural cost advantages of the Internet? Let's look at a hypothetical example.
The overseas disaster scenario
There has been a major earthquake in an overseas tourist region popular with New Zealanders. Damage and potential loss of life is heavy, there is a risk of secondary disease due to the widespread infrastructure failure, and the region is mostly cut off from immediate outside help due to the damage to airports and roads. The public are clamouring for information about the disaster and news of friends and relatives.
The decision is taken to create a website to act as a focal point for information delivery to the public, and as a way for people to inform the Government about New Zealanders in the disaster zone. The site needs to include:
-
Links to the latest media stories on the disaster, covering both local and international media outlets;
-
Formal announcements from government agencies, detailing the steps people should take in attempting to contact people who may be affected;
-
Lists of appropriate services delivered by different government agencies, particularly those that can provide immediate assistance for affected families;
-
A wizard-style interface to enable people to work through a set of questions or steps that will direct them to the correct agencies and services;
-
Mechanisms for people to contact the correct staff within agencies, and to post information they may have about people in the disaster area that may benefit others.
From the list of requirements it is clear that the following functionality will be needed:
-
Front-end web navigation components to enable users to find their way around the site easily;
-
An automatic news collection and display system, able to categorise and prioritise news stories from external sites;
-
A content management system;
-
Lists of appropriate services, agencies and contact details;
-
The ability to link the agencies and services into wizards through the content management system, in a way that requires minimal programming and maximum flexibility;
-
A message board that enables people to post messages to the site.
There are some other constraints, notably for the system to be highly reliable (to ensure people can gain access at all times of the day and night), the ability to handle high loads given the large possible audience, and the need for the site to be viewable over low-bandwidth links in overseas locations. And finally, the site must be fast to get operational and highly cost-effective, given that it will cease to exist once the crisis has passed.
Looking at the components available, there are many ways to meet the requirements from the available stock of components. These can be summarised as follows:
|
Requirement |
Available? |
Comments |
|
Web front-end |
No |
There are no standard Government components for creating consistent sites, as the autonomy of agencies has always taken precedence over standardisation. However an existing agency or EGU portal front-end could act as a starting point. |
|
Content Management |
Yes |
Available as a LEGO block from EGU. Would simply require new content managers to be allocated within the system. |
|
News Management |
Yes |
Available as a LEGO block from EGU. News collection and automatic categorization is available in the Autonomy search engine used to power the current portal. |
|
Services and Agencies |
Yes |
Available as a LEGO block from EGU. Details of all Government services, agencies and appropriate details are in the Metalogue metadata system, and are accessible programmatically. |
|
Wizard Creation |
Partly |
The components of services and agencies are available as noted above, along with the content management ability to create narratives to link them together. However experts from appropriate agencies would need to provide the knowledge to create the wizards. |
|
Message Board |
Yes |
Available as a LEGO block. Can be incorporated in the front end using standard programming techniques. |
|
Infrastructure |
Yes |
Available as a LEGO block. The Government portal already runs on high-availability servers with the ability to cope with high traffic volumes, so adding another website to the existing infrastructure would be reasonably straightforward. |
Using the component approach there is also the ability to add functionality such as e-mail subscription, allowing people to automatically receive e-mailed updates from the site.
As can be seen from this scenario, the component approach allows a suitable portal to be created quickly and cost-effectively. The officials involved can focus on outcomes - how to use the Internet as a two-way communication channel in the mix of available media - rather than on the process of programming sites and activating servers
[ Previous | Next ]

