|
[ Home | Directory | About | Membership | Contacts | Search ] |
Prepared by: Susan Forbes, Murray Hemi, Greg Ford, Joan Ropiha for Te Kete Mö Te Taiao project.
Financial support for this project has been received from the Minister for the Environment's Sustainable Management Fund, which is administered by the Ministry for the Environment.
© The Crown (acting through the Minister for the Environment), 2001.*
This document describes the technical features that will make up the kaitiaki web site. The site will use the domain name http://www.kaitiaki.org.nz. The graphic design of the site is described here. Custom software will be built by ReddFish intergalactic to support the "kaitiaki on-line community" concept developed by the Kaitiaki Web Site Project Team. Site software will include:
| The web server software: | Apache web server1 |
| An e-mail list server: | Majordomo2 |
| Web based discussion groups: | mod_virgule3 |
| Text Search Engine: | ht/Dig.4 |
The web site will utilise custom applications including mod_virgule to enable the kaitiaki community to administer the site themselves and reduce the need for specialised administrators. The applications will help reduce the long-term costs of running the site.
The contract specifications required the following standards as a minimum:
This report identifies the key design principles of the web site and includes detailed specifications of the standards that will be applied to the web site. It is not intended to include detailed design of server applications.
The site will use a marae metaphor to provide clear roles for the community members. Visitors to the site will be able to join by entering their details into the "new members" form, including an introduction (or mihi) for their personal web page. The system will create an account on the site the visitor will be listed in the "new members" (manuhiri) list. Newcomers will initially be just viewers of the site (kaititiro) until the existing members welcome them on to the site. Existing members, seeing that there are people waiting on the manuhiri list will be able to acknowledge the newcomers, by accessing their personal web page and choosing the appropriate welcome. The system will track the process and use criteria known as "trust metrics" to determine appropriate roles for members, based on their level of acceptance within the community. Trust metrics are discussed in more detail below.
|
Example A visitor, "Moana Kaitiaki", arrives at the web site and decides to join. Moana clicks the accounts button and goes to the new members page. On the new members page, Moana enters an alias (Moana) her e-mail address, a brief körero about herself and her chosen password for the site. Her name is then added to the manuhiri list. An existing member sees Moanas name on the manuhiri list, clicks on her name and is taken to Moanas personal page. Recognising Moana as a close friend and active kaitiaki, the existing member selects the option to "Pöwhiritia Moana hei hunga käinga", welcoming Moana into the community as a tangata whenua (hunga käinga) member. As existing members welcome Moana onto the site, the system determines when Moana actually achieves tangata whenua status on the site. |
Te hunga käinga, the "home people" of the site will be able to add articles, and potentially have other roles on the site. Some of te hunga käinga will elected to te komiti whakahaere (or management committee) for the site, this is done by the same process of visiting the persons personal page as welcoming newcomers onto the site. Figure 1 shows the various roles for manuhiri, te hunga käinga and te komiti whakahaere and how these roles affect access to different pages on the web site.
Figure 1. Community access to web site
The marae metaphor will be carried over into the graphic design and navigation links on the site wherever practical. In this way kaitiaki who visit the site should quickly become accustomed to the way the kaitiaki on-line community operates.
The mechanism used to determine the group to which members belong is called "trust metrics". Trust metrics hare used on several successful on-line communities to help maintain quality discussion groups.5 Trust metrics will decide what can and cannot be done on the site. For example, only people with the highest trust level can modify the home page of a site.
Trust metrics have the potential to solve the problems of controlling access while preventing gate-keeping or "capture" of the web site by outsiders. They serve as a filter so that the most valued members of the community are given prominence, while less valued members have a chance to prove themselves before they are given the "lime light". In this way, the site can avoid spam (unsolicited advertising), abusive discussions and other bad behaviour that plagues some discussion group systems.
The proposed metric as used in the mod_virgule system is believed to be safe against take over by force of numbers, even if some of the existing community are misled into trusting the take over group.
Another advantage of trust metrics is that they provide an answer to the question of "who are kaitiaki?" or "who is Mäori?" Trust metrics let the community decide these issues collectively and organically, developing as the community develops.
For a detailed discussion of the trust metrics see the Advogato web site http://www.advogato.com/trust-metric.html .
The home page is the key to attracting new visitors to the web site. It needs to be attractive, interesting and invite the viewer on and into the rest of the site. The graphic design of this page, along with careful consideration of the download time for the page will determine its final look, but it will certainly combine environmental imagery, probably with a marae theme. The number and kind of links on the page will also depend on the graphic design chosen for the site as a whole. The choices made for this page will have an influence on the overall structure of the site.
A draft of the proposed site navigation structure is given in Figure 2. The actual site structure may vary a little from that shown. Please note that in the diagram, the home page is termed the "Welcome Page" as it leads quite directly to the main directory page of the site (which has many of the items you would expect for a home page).
The web site design will provide for the different preferences people may have for navigating the site and finding information. Links to recent articles contributed to the site will be on the home page, but it should also be possible to browse the articles by topic or to use the site search engine to find articles according to content or key words.
It is well known that human short term memory can contain only about 5-7 items. For this reason the documents will categorised into approximately 5 main topic areas. These main topic areas will form the basis for the "browse hierarchy". When new articles are posted to the site, the poster will be asked to select a topic area for their article.
Each page will also include a set of links to site tools such as the search page, user accounts and the mailing lists page.
Figure 2. Draft Site Navigation Structure
The look and feel of the web site will be kept consistent across the whole site by the use of standardised style sheets and background images. For example, changing the fonts in the main style sheet will change the font used when accessing any page without modification to the page itself. Similarly, the background image can be changed without modifying the pages. Pages will also be constructed out of components so that common items such as banners and navigation links can be applied consistently throughout the site.
To the reader, the site appears as a set of web pages, but most pages on the site will be built dynamically from several components by the web server. The page components will normally consist of:
A sample component layout is shown in Figure 3, the purposes of the components are given below.
Figure 3. Web Pages Composed Dynamically
The Banner is intended for carrying the site logo, or if a page has corporate sponsorship, it might be a banner advertisement linked to the corporate sponsors site.
The top navigation bar has a set of site navigation buttons linked to other sections of the site.
The content section contains the actual text of the document along with any graphics that make up the document. The content section itself may be built from components, for example for articles, the content may consist of the article itself along with all the comments on the article. Some pages may also be composed of lists of items, for example a directory or menu page.
Vertical panels serve several purposes; they can contain supplementary links, links to site tools, they help to reduce the width of text columns to improve readability. Depending on the visual design chosen for the page, the panels may appear on the left or right of the page.
Bottom navigation bars are useful on long pages, providing a handy set of navigation buttons when you reach the bottom of the page without needing to scroll back to the top. Used consistently throughout the web site, they let the reader know when they have reached the end of the page, which may not otherwise be apparent when viewing a page in the browser window. Bottom navigation bars will also contain copyright statements where required.
Web coding standards such as the version of HTML to be used are given in detail in Appendix I Technical Specifications.
The project requirements specified a major requirement was that the site should be viewable in as wide a range of browsers as possible. Browser scripting and framesets will be avoided.
The proposed approach is to use cascading style sheets to specify the fonts, background images and colour schemes used on the pages. Browsers that do not support cascading style sheets will display the pages with the current settings for the browser, which can be set by the user. This will enable the look and feel of the site to "degrade gracefully".
Authoring for the web can be quite difficult, as it is necessary to allow for different browsers, fonts, screen sizes and other variables. Many of the valuable contributions to the site will be from people with little or no experience producing web documents. For this reason several approaches will be used to add documents to the site:
The automatic conversion of RTF files to HTML will be done by an application specifically developed for this site. The application will attempt to detect headings and other document features and apply the sites style to these features. This will ensure that documents added to the site will have a consistent look and feel despite being created by different people.
It is assumed that only experienced web authors will upload pdf files, so the quality of these documents should be of a suitable standard, although the look will not necessarily be standardised.
Contributors to the site will be encouraged to select an appropriate copyright statement and/or licence agreement for their contributions.
A full text search engine will maintain a keyword index of the site. A search page will be available which allows for advanced searches such as search by author, title or topic. In addition to the search page, the navigation header or footer on most pages will include a quick keyword search field for quickly finding a particular document on the site.
Some pages may be excluded from the index, for example, for personal pages, only those contributed by "te hunga käinga" may be indexed.
Table 1 shows the proposed hardware and software requirements for the system. The requirements are not stringent as it is expected that a "low specification" Internet server will be adequate for the proposed site.
| Hardware | Software | |
| Essential | Server with permanent Internet connection |
Apache web server Majordomo list server Perl |
| Desirable |
ISDN Internet (128kb/s) connection or faster. Pentium 200 MHz or faster 500MB available disk space |
RedHat Linux 6.2*6 Apache Version 1.3* Perl Version 5.0* |
Table 1. Hardware and Software Requirements
The kaitiaki web site system will be designed to run on a single stand-alone server with a permanent Internet connection. There are no specific hardware requirements except that the server and Internet connection should be sufficiently fast to give reasonable response times.
The web server software will be Apache Version 1.3 or later. Some of the custom software modules being built for the site will be Apache "modules" so other web servers will not be compatible. As Apache is free and runs on a wide range of different computers and operating systems this requirement should introduce any difficulties in transferring the web site to other servers if and when it is necessary. The site will require the ability to add web server modules in order to install the main site application (mod_virgule)
The system software requirements are also minimal. The site will be designed and tested on a server running Red Hat Linux Version 6.2 or later, but operating system dependencies will be kept to a minimum. As Apache web server and Perl both run on several different operating systems, the site software may be portable to other systems.
The applications for the site will require lib-xml (the shared libraries for accessing xml files).
Quality technical and programmers documentation will be delivered with the site software. This documentation will be available with the source code for the site which will be available for download (under a GNU licence) on the site download page.
Web based (HTML) documentation will be provided on installing the site software, as well as a users guide for the site. The users guide will provide instructions for using the key elements of the site, including joining, logging on, adding articles, uploading documents and using the mailing lists.
Source code written for the site will be documented at the procedure level. Structured comments (Javadoc7 style) will be used so that HTML documentation can be generated directly from the source code. The documentation will enable interested parties to modify the applications if the kaitiaki community wishes to do so in the future.
The site will include source code for applications from various external sources including for example the "Perl"8 code for the mailing list server; the project team does not expect to document this code. The installation documents will however describe how to integrate the site with these applications.
A site overview will also be written that describes how to modify the site and change optional site settings and security policies. For example the overview will identify the files to modify in order to change the look of the site, these files would normally include background images, logos and style sheets.
The peer review team will be the asked to review and test the site, prior to "going live".
Usability testing will ensure that all pages can be viewed correctly on Apple Mac and PC, monitors of different quality, and via Netscape, MS Internet Explorer and Opera browsers; Page downloads should not exceed 25 seconds and the average time should be less than 5 seconds assuming a 56K modem.
Automated load testing will be used to test the performance, stability and scalability of the site. These tests will be undertaken:
There are four main components to the cost of hosting a web site:
Domain name registration costs are currently $53.00 per year for the annual licence fee and $12.00 per year to use Domainz9 as a secondary name server (recommended).
There should be no software licence costs for the kaitiaki web site because it is based on free software.
Site management and administration is usually on an hourly rate for time spent by technical staff responding to ad hoc requests such as changing user passwords or modifying and upgrading site software. Such assistance costs from about $75 to $150 per hour. The web site proposal automates as much of this kind of administration as possible to reduce the need and hence the cost which could otherwise be a major component of running costs. The number of hours required will probably vary widely, but one to two hours per month may be necessary.
Hosting fees cover the maintenance of the web server hardware, and the network traffic costs. They vary with the web service provider (hosting service), and with the features, disk space, and network traffic requirements. Hosting fees vary from around $20 per month for simple web sites on a shared server, to several thousand dollars for a high capacity dedicated server. Although the data storage and network traffic capacity required for the kaitiaki web site are not likely to be very large, the web server module proposed for the site (mod_virgule) cannot be used with most web hosting packages for shared servers, so a dedicated server will be required, or a special arrangement with the service provider.
An Internet service provider could be contracted to host the kaitiaki web site. The "Telehousing" option is presented below for comparison purposes, as it appears to be the most viable alternative amongst hosting services currently advertised on the Internet.
A server computer would be owned by the kaitiaki community (or a sponsor) and installed at a service provider who would provide a high speed Internet link. This service ranges from $120 per month (at http://www.world-net.co.nz/products_telehousing.html in Auckland) to around $300. This compares favourably with the monthly cost of purchasing a permanent Internet connection. A computer would be required, but this could be a cheap entry-level machine costing under $2,000. It may also be necessary to purchase hardware support services for the computer from time to time.
The site would be installed on a web server provided by a Internet Service provider, which may also serve other web sites. Pricing could be either a flat rate for hosting services and a per megabyte charge for network traffic ($0.25 to $0.30 /MB), or a flat rate for both. The monthly rate should be similar to the rates for Telehousing, but the total cost should be a little less as the provider will provide the server.
Stage I of the project included a literature review. Part of the literature review included an Internet search for pages of interest for kaitiaki. This search will form the basis for the links directory on the site. Because of the tendency of web sites to disappear, the project team developed the technique called "potted queries" for linking to external pages. Potted queries use an Internet Search engine (in this case http://www.altavista.com/) to find the selected page, and/or similar pages on the Internet. Instead of going directly to the page, the person seeking the page is taken to a page of search results listing similar pages. The desired page should be near the top of the list. In this way, we rely on Altavista to keep up-to-date links and reduce the maintenance required to keep links from the kaitiaki site to other sites up-to-date.
As far as possible, all site content will be stored in a single location. The suggested location is the directory /home/kaitiaki/. This location will contain the data store for the on-line community discussion (mod_virgule data), as well as the web directory and the mailing list data store.
Figure 4. Basic directory structure for /home/kaitiaki
Extensible Markup Language (XML) files are a standard (see: http://www.w3.org/) structured data file format, they are used as the data file format for mod_virgule and will be used wherever practical for data storage on the web site.
In general, the site will generate version 3.2 or 4.01 compatible HTML markup as specified by the W3C group (http://www.w3.org/TR/html4/).
Each HTML page will begin with HTML version information as follows.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
The colours, fonts and background images used in the documents will be defined in external style sheets. These will be specified in the header section of the HTML page as follows:
<LINK rel="stylesheet" type="text/css" href="/styles/style.css">
Many of the pages will be composed at "run-time" so they may use embedded style sheets based on a centralised store of style rules. For example:
<style type="text/css">
<!--
body {
background-color: #FFFFFF; background-image: url(/images/kaupapa.jpg); font-family: "Tahoma Mäori", "Arial Mäori", Horouta, sans-serif
} --> </style>
HTML character codes will be used for all non-ASCII characters (characters numbered 128 and higher). This includes characters like " the quotation symbol, © the copyright symbol and the macron characters shown in Table 2.
Meta tags will be used on all static web pages to provide the description and keywords for the pages.
<meta name="keywords" content="kaitiaki environment coastal taiapure">
<meta name="description" content="This page ....">
The "Robots" meta tag will be used to prevent indexing of some pages e.g.
<meta name="robots" content="noindex,nofollow">
The look and feel will be kept consistent across the whole web site by the use of standardised style sheets and background images. For example, changing the fonts in the main style sheet will change the font used when accessing any page without modification to the page itself. Similarly, the background image can be changed without modifying the pages.
Where possible, server components such as the web server and search engine will be installed in the default locations for the Linux distribution used. For example, RedHat packages (rpm files) will be used to install the software if they are available.
The project specifications require that the site must be viewable with images turned off. Alt tags will be used on images to assist in viewing the site when images are switched off.
Several image formats are in common use on the Internet: Jpeg, Gif, Png and Macromedia Flash. Flash and Png files are specifically aimed at Internet use, but unfortunately are not viewable in older browsers so they will not be used on the Kaitiaki web site. Jpeg and Gif files are supported in all graphics capable browsers and will be used where appropriate.
Jpeg files support millions of colours, so are ideal for photos. They also have a compression system that makes them highly efficient, but at the loss of some of the sharpness of the image.
Gif files support only 256 colours (maximum) and use a different compression system suitable for images with large blocks of the same colour. Unlike Jpeg images compressed Gif files suffer no loss of quality.
One problem is that many older computer displays allow only 16 or 256 colours; this can lead to serious loss of image quality. For this reason all Gif files used on the kaitiaki web site will use a "web safe palette". The web safe palette is a selection of 216 colours, which modern web browsers will use if the computer supports only 256 colours.
Image maps use a clickable image as a navigation tool. Most modern browsers support them, but "client-side" image maps will not be used on the kaitiaki web site as they do not work well when images are turned off. Where image maps are required the web site will use tiled images (one image will be sliced up and inserted into a table). Each tile will have an alt tag and may link to another page.
As the requirements specify that the site must support Macrons the following system will be used to ensure macrons are available.
1) The web pages will be formatted to use Macron fonts. (8 bit fonts, rather than Unicode fonts, as Unicode is not necessarily compatible with older computer operating systems).
2) Macron characters will be written using HTML codes to ensure that machines that use different character sets display the correct character (e.g. Macintosh and Windows PCs). The codes used are shown in Table 2.
| Lower case | HTML code | Upper Case | HTML Code |
|---|---|---|---|
| ä | ä | Ä | Ä |
| ë | ë | Ë | Ë |
| ï | ï | Ï | Ï |
| ö | ö | Ö | Ö |
| ü | ü | Ü | Ü |
Table 2. Macron Character Codes
3) Fonts will be specified only in the style sheets (css files), not in <font> tags.
4) For site visitors who do not have Macron fonts, there will be fonts available on the site for downloading. ReddFish will provide a selection of downloadable fonts that are suitable for use with the style sheets used on the site.
5) A list of macron fonts will be specified for each style so that commonly available macron fonts will be used in place of the specified font if it is not installed, but some other macron fonts are installed.
6) Users of older browsers that do not support style sheets can set their browser to use a macron font by default.
* © Copyright exists in this work in accordance with the Copyright Act 1994. However, the Crown authorises and grants a licence for the copying, adaptation and issuing of this work for any non-profit purpose. All applications for reproduction of this work for any other purpose should be made to the Ministry for the Environment.
2 http://www.greatcircle.com/majordomo/
3 http://www.levien.com/free/mod_virgule/
5 See for example http://www.advogato.com a site for "free software" programmers and the original site for the mod_virgule web module that will be a key component of the Kaitiaki web site.
6 * Minimum specifications: other versions may also be compatible.
7 Javadoc is a tool that parses the documentation comments in a set of (Java) source code files and produces a set of HTML pages describing the classes, methods, fields and other constructs used in the code.
8 Perl is an interpreted high-level programming language developed by Larry Wall
9 The New Zealand Internet Registry Ltd Domainz, is the New Zealand company responsible for the management of the National domain name Registry for .nz.