1. Background

We have purchased a new Server (400MHz PentiumII), and are now looking to port www.Paneris.co.uk and some other minor sites onto it. Additionally we would like to extend the functionality and usability of the Paneris system with new technology available to us by hosting on Linux, and by using the Template technology developed by building iglu.com.

This document will deal with the Requirements for the PanerisII system, as this will also define the requirements for the new box.

2. Business Need

The Paneris community exists because www.paneris.co.uk exists. Recent projects, and some long standing issues mean that moving the site onto a server we can control will give us massive business benefit, including improved messaging, version control, and database integration.

Additionally there is a real business need to improve the interface, which, because it is different from most web sites is difficult to use for the novice user. The interface is intuitive, but it also needs to be instantly familiar, which is something we are missing.

3. Users and services

The Paneris site is going to be used by three groups of people:

1. Paneris Partners and Customers. These interact with different levels of indifference, largely because of difficulties understanding the size and complexity of the interface.
2. Casual Visitor. We don't fully understand how casual visitors use the site, but my feeling is that they simply run away.
3. Paneris Members. Depending on the level of use, Paneris members either love the site or are extremely antagonized by it ("the Paneris monster tried to eat me"). Paneris members tend to be technically competent, and so building an interface acceptable to them would be a great 1st step.

4. Constraints

The point of moving Paneris to a new box is to remove constraints, although obviously we are tying ourselves to Linux, and OSS in general.

All the pages on Paneris are pre-generated at present, making the system very quick. As we move over to template technology it is important that the system remains responsive.

5. Detailed Requirements

5.1 Interface Redesign

The interface is intuitive in it's own right, but it is sufficiently different from other web interfaces (by necessity) to be difficult for the novice (and moderately experienced) user to cope with well. The 'nodal' approach of the existing system is very valuable and means that the site transparently maps onto the file system. This allow straightforward access by Telnet, HTTP and FTP, which is useful.

The problem is that although most people understand a directory tree, they do not perceive of Paneris as such. If they simply considered Paneris to be an enhanced online file system, they would quickly grab the idea.

Suggestions:

1. we stop using the word 'node' and use instead the word 'directory', 'root' and other common terms for describing a file system
2. the interface is improved to look much like Windows Explorer (or the GUI to the FS on a more cool OS like BeOS or KDE?). Certainly the left hand window with the expanding file tree. By creating a familiar interface we will remove 90% of the acceptance problems new users currently have. Quote from WilliamC: "It took me ages to realize that the links on the left were actually directories".
   I feel that a 'web style' interface is going to give us many design headaches in the long term, and that we need to maintain the 'mapping of the FS' interface, but we do need to make it completely explicit that this is what we are doing.
3. an explicit path to the current directory is always displayed.
4. buttons are buttons (they roll-over, and are graphical).

5.2 Messaging

Messaging at the moment nearly works. A few refinements, and we have a brilliant and flexible system.

1. Each directory has it's own independent threaded message board (as now)
2. Users can subscribe and unsubscribe from boards
3. Users can change their email address which would have an instant effect on the entire system.
4. Boards generate email messages to subscribers
5. Users can send mail from a POP3 client to an individual board.
6. Subscribers to a board have the option of 'cascading' their subscription to child directories (on by default). This also impacts on new child nodes as they are created.
7. Users can spell-check messages before they are posted.
8. Messages to be stored in the database and to be searchable on a directory specific and a system level.

5.3 New Directory Creation

New directories can represent a variety of information. They may be related to projects, customers, people, systems, jokes or nothing in particular. At present we have a system of hierachical templates, which does not allow the user to decide what sort of directory they are creating. A more explicit approach would be to offer the user an option of creating a new directory based on one of the templates defined. I do not think that allowing the user to edit the html at this stage is beneficial, rather it is a 2 stage process - create the directory, the edit what is in it.

5.4 Bug Lists / ToDo Lists

Initially bugzilla was considered a solution. I would like to have a look at the PHP (www.php.net) bug system, which is simpler (and well up to our requirements). We need the following info to be recorded for each :

• timestamp created
• timestamp last amended
• status - Closed, Open, Analyzed, Suspended, Duplicate, Assigned
• who reported
• who fixed
• reference number
• title (short description)
• detailed description
• priority (not sure about this)

We need a search facility, and a stats report (check out PHP). We also need to be able to surpass reporting of closed bugs (by default), a link into the time recording system (FAR), and to be able to order the bug list by time / who etc.

ToDo lists will be created for each directory.

5.5 Version Control

The entire site will come under CVS. There must be a Web interface to this (as updating documents online is extremely important). The interface must be very simple (a user may never have used a Change Control system before, and is unlikely to understand what they are doing). It is important that CVS can be turned off as uploading 1000 new gif files for a site could be extremely onerous. How does CVS integrate with FTP?

5.6 Invoicing

The invoicing system nearly works, it needs updating to provide some sort of transaction mechanism (does postgress support this?). It has a couple of bugs. Which will be fixed when we use the new Datadictionary technology from iglu.

We need to ability to specify a VAT number for each partner and automatically add VAT to appropriate invoices.

TTJ is not the best person to write requirements for this has he originated the system.

5.7 Time Recording

The Time Recording System nearly works, and will be much improved by using the new Datadictionary Technology.

An automatic mechanism of allocating timesheets to invoices should be considered.

TTJ is not the best person to write requirements for this has he originated the system.

5.8 Legacy Data

Document Dated: Mon Nov 16 15:30:14 1998
Modify this document