Appendix C: Log of Meetings

Minutes for Meetings

Group Meeting

11/10/1999 17:30 - 18:11 Present: jb, tc, tf, nh, ak, gkw

nh selected as group leader
ak selected as secretary

Agreed that it is important to investigate the two available hardware options:

Action: gw and tc to investigate and report back.
Action: jb, tf, nh, ak, gkw to investigate generally.
Action: ak to provide the group with a format for timesheets.
Action: nh to arrange a meeting with ih for Wednesday or Friday of next week.

Friday lunchtime agreed as generally available slot from future meetings.

Supervisor Meeting

13/10/1999 10:00 - 11:05 Present: jb, tc, tf, nh, ak, ih

General introduction by ih.

Notable points:

Clickable page numbers:
The ability clicking 3 digit numbers in pages is not the most fantastic thing in the world (whereas it is generally as far as most commercially available software goes).
With 'live links' it is important to give feedback to the user that an element is clickable. It would be good to use a standard way of doing this - notably turning the pointer to the familiar 'hand' as per a typical web browser. Short of this another method may be to invert the digits of the clickable number in the page.
Would be good to differentiate between a page number and other numbers. Obviously there will be occasions where determining this will not be possible, but excluding, e.g. telephone numbers should generally be possible.
The ability to save pages would be a boon.
Fetching pages in advance would represent a considerably better service than simply servicing requests on demand.
Leads to keeping pages in some sort of cache
Possible extension given caching would be the ability for a keyword search on the cache. (What heuristics can be applied for searching?)
Other potentially clickable elements would be web and e-mail addresses.
Should design for a large, scalable, fully-featured solution, and then build some subset of that.
Bookmarks
Statistics
- Could be applied to improve cache performance
- Could provide useful information to user (e.g. most popular or recently updated pages)
What is presented to the user on startup?
Will the system have the ability to create meta-pages, or even have a full teletext-editor?
Hardware:
Which adapter to use (internal/external)? Under what OS?
- Internal Haupage WinTV card
- Supported by video4linux - could use some code from that (properly credited), or write own driver.
- (Supplied) Windows driver supports DDE, but certain design decisions have been made by implementers (e.g. no fastext).
- Write own Windows driver
- OPT III/S External tuner/decoder
- Simply RS232 - ih provided scheme for addressing.
- Could use a modular architecture, since the abstracted teletext server need not care about the source of the pages, just that they are served appropriately. Thus could implement more than one of above options.
To consider:
- What version of Java?
- Applet or application?
James Freeman's individual project report worth reading, but must be aware that there is a danger that by looking at how others have implemented a similar system, it can limit your own thinking about the problem.

Action: Need to produce a core specification of generally quite 'doable', desirable functionality, and also consider various enhancements to possibly be implemented as extras.
Action: Provide CSG with list of requirements by appropriate time.

Group Meeting

15/10/1999 14:02 - 15:45 Present: tc, tf, jb, nh, ak

Hardware investigation:
- tc - required more technical documentation on the available cards
- Action: ak - item for ih meeting, tech specifications
- nh: Options are:
  - Internal card:
    - Cannot reasonably use under Windows without writing our own driver - not desirable.
    - Under linux, we could make a driver using code from the video4linux project
    - Action: tc to investigate video4linux in more detail to test viability. Also look at what would be necessary to credit v4l appropriately.
  - External adapter:
    - Over RS232, well defined. Should be relatively simple to write some serial handling code to interface to the external adapter.
  - Agreed: to put both options in spec and design in a modular fashion, to enable us to use either/both as desired.
jb has some useful documentation for later in the project
nh, Re: James Freeman's project:
- Fonts: Java's GraphicFont may well be too slow to use
- Double height and width characters will be fun to parse.
Discussed possible alternative to Java
- Talked about possible ways to make the results more widely viewable by:
  - A. Rendering the page to a 'large' gif on the server side
  - B. As above plus some HTML to still enable clickable elements using image maps.
  - C. Using many small gifs which would be downloaded just once, and then placing them using HTML
  - D. As C but using text for printable characters.
- A suffers from lacking any funky features that add value to the project
- B has potential, and may be a good way to achieve functionality for non-Java browsers.
- C has the problem that the number of characters gets very large (O(10,000)) when you consider all the different combinations of colour, etc. Any method of doing the colour client side will cause compatibility issues.
- D Suffers from not looking as intended in many locations
Coding environment:
- Will we use any kind of Integrated Development Environment, CVS, visual development tool for the front end, etc? Considerations include:
  - Need for importing code from text files written at home, or in various locations means CVS probably isn't viable.
  - Visual builder for front end may make life simpler, but depends on version of Java as to whether it is necessary (e.g. very simple to build good gui using Swing/JFC).
  - IDE may simplify process of integrating parts as project progresses.
Cache feasibility
- jb: The total bandwidth for the teletext stream is theoretically nearly 7 Mbit/s
- In practice the amount of useful data is considerably less than this.
Leads to question of what we store in the cache:
- We will very likely take the raw Teletext and create a sanitised form.
- Making that conversion is likely to require significant processing, and may well increase the size of the data.
- Thus it may make sense, for purposes of server and database workload and bandwidth in transmitting to store the smaller structure, and pass the workload of cleaning up and sanitising to the client, where it will be processing a relatively small number of pages, and only on demand.
Discussion of distibuted nature of project:
- Running a web server on the teletext server, if only to serve the applet will simplify the process of communication from applet to teletext server, since it will be allowed to talk to that machine without having to use a proxy
- The database and teletext server should be designed as logically separate, although for practical reasons we will in all likelihood run them all on one box.
- Should design for the potential to have a number of teletext servers, sharing the load, providing resiliance, better service, etc.
Action: Everyone to read James Freeman's project report.
Brainstormed list of potential features:
- Clickable page numbers
- Clickable URLs
- Clickable email addresses
- Saving pages locally
- Printing pages
- Bookmarking pages
- History (forward, back, etc.)
- Local caching
- Multiple page grabs (for offline browsing)
- Email notification (with authority to ensure you can't irritate another user)
- Send the page to a friend (by sending gif & html, or as plain text)
- Statistics
- Recently updated
- Most popular
- Server caching
- Refresh algorithm (could use statistics gathered)
- Generating Teletext from templates
- (Partial) list for CSG
- Group space
- Dedicated linux box (With root access, or close to it to install necessary software, or CSG to install appropriate software)
- Software (Apache, Oracle/Informix, JDK vTBD, more?)
- Plenty of disk space (TBD)
- WinTV Card & External Tuner
- Connection to aerial point
- Connection to internet (vital)

Group Meeting

18/10/1999 11:04 - 11:53 Present: jb, tc, tf, nh, ak, gkw

nh Need to work out draft specification for Wednesday for ih
Suggestion for basic specification:
Working with one hardware choice, but designed for more than one (modular architecture)
Including fastext
Click on any 3 digit number to move to that page
Server cache of all pages, updated by a simple algorithm, but identifying and storing all available subpages
Help system
Potential extensions to specification (ranked):
- 1. Intelligent clickable page numbers
- 1. Clickable URLs and email addresses
- 1. Improved algorithm for server caching (could use statistics gathered)
- 1. URL addressing directly particular pages
- 1. Send the page to a friend (by sending gif & html, or as plain text)
- 2. Bookmarking pages
- 2. History (forward, back, etc.)
- 2. User registration (either login or identified by cookie, giving persistence of preferences, bookmarks etc)
- 2. More fully featured version distributed as application rather than applet; e.g. saving pages locally as Teletext
- 3. Implementing on distributed systems; multiple servers, load balancing, etc.
- 3. Collection & reporting of statistics (e.g. recently updated, most popular, etc)
- 3. Multiple page grabs (for offline browsing)
- 3. Printing pages
- 3. Local caching for fastext
- 4. Local caching for previously viewed pages
- 4. Generating Teletext from templates
- 4. Implement alternative hardware option
- 5. Email notification (with authority to ensure you can't irritate another user)
Action: jb to help tc with video4linux investigation.
Action: nh/ak to obtain a WinTV card at earliest convenience.

Supervisor Meeting

20/10/1999 10:00-11:05 Present: ih, nh, ak

1. Proposed Specification

ih stated that he expects more in the basic specification, particularly from a MEng group of six people. noted that the keyword search facility was not on the extended list. nh assured that this was an oversight, rather than a deliberate omission.

There was discussion of:

Parsing: There is no 'right answer' to whether the workload is on the client or server side. Different situations might call for either. It would be desirable to have the ability to determine this on deployment (ih). e.g. have a switch which would shift more or less work to the client, depending on whether it was to run on a heavily loaded server, or where there was a dedicated box, respectively.
ih considered printing & saving to be more important than the ability to send the page to a friend.
ih: It must be multithreaded server-side, for performance reasons.
No-one has ever done the project with the option for an application, nor has anyone implemented printing & saving, nor has anyone achieved fastext using the WinTV card.
Which pages is it appropriate to send in a chunk? Just this page, all its subpages, n+1, n-1, fastext pages. It will likely be quicker to send a bunch together, since the overhead of the request/reply will be significant.

Action: Agreed to extend the basic specification to include intelligent handling of clickable page numbers, together with clickable emails and URLs. The group should also find another significant feature from extended list, to be included in the basic specification.

2. Proposed CSG Equipment list

ih questioned the need for such a heavyweight database as those suggested (Informix/Oracle). He said that previous groups have never used a database (storing cached pages using the local file system) and that to him something like MySQL should be up to the task.
ih confirmed that there should be no problem having a machine to which we have root access, addressing a concern from the previous group meeting.

3. Information on hardware

ih provided a WinTV card, and pointed us in the direction of the Hauppage website for the most up-to-date information and drivers.

4. Any Other Business

ih: What Paradigm to use?
- TV paradigm: make the system respond as similarly as possible to a standard TV set, thus those familiar with teletext will feel 'at home' e.g. typing 1... 2... 3... 4... would result in the system waiting until the 3, then starting to fetch page 123, then on pressing 4, would stop, and await a new page number 4xx.
- Web paradigm: take the view that this is an application for the web, and thus the behaviour should be more web-centric, using buttons, menus, etc.
Possibility of an intermediate approach, taking advantage of both approaches.
User Prefs: Storing preferences about users should allow us to give more choice to users, but ask them fewer questions each time. e.g. it may be desirable if there is an on-screen 'remote control' that it could sit docked to the left, to the right, or floating. There is no reason why a user should have to assert their preference every time if we 'know' them.
ak talked about how we might downgrade gracefully by putting a gif-based version of the system within the APPLET or OBJECT tag, to be displayed by browsers which cannot handle the applet. If the gif has an image-map associated with it, and we have in place a way of addressing a particular page by URL, then it could offer relatively rich functionality on very basic browsers. There should also be the opportunity for plain text display. ih suggested we may want to use some intelligence in terms of whether we try and display a page as graphic or text (a weather map is little use in plain text, yet stock prices are less useful as a graphic).

Group Meeting

22/10/1999 14:02 - 15:00 Present: jb, tc, tf, nh, ak, gkw

Issues from Supervisor Meeting
- We omitted keyword search from our feature list, agreed to add as rank 1.
- Features to move to core specification:
  - Server-side generation for Javaless clients
  - URL addressing directly to a channel/page combination
- Which paradigm?
  - Agreed that we should be seeking to extend the functionality past features one might find on a standard television set but to do so by offering the basic functionality using some sort of on-screen remote control, but then offer appropriate access to extended features (like keyword search) using the most appropriate means. Thus, a seasoned user of TV Teletext should find the simple easy to use, but the project will make best use of the available functionality.
- Database vs. files for storing cache
  - tc commented that it makes little sense to reinvent the wheel, and there are databases available which offer precisely the functions we need.
  - tc also commented that the particular choice of database previously listed was illustrative, rather than a firm selection.
  - Action: jb to investigate the available database options.
Subgroups:
- The group can be sensibly sub-divided into the client and server sides.
- jb, tc, ak will meet before the next meeting to discuss the server side.
- gkw, tf and nh will concentrate on the client side, looking at the UI, rendering and display and process communication respectively.
It was felt that the use of Java end-to-end would likely introduce too great a performance penalty. The key advantage would be that RMI could be used for the distributed communication.
The group was generally agreed on the use of sockets for communications.
Action: ak to look at the server-side generation of representative text or graphics.
Action: server group to investigate how best to store teletext in the cache.
Action: Agenda for Supervisor meeting to include discussion of fonts and page representation.
1-3 was agreed as a sensible time for future Friday meetings.

Group Meeting

26/10/1999 11:02 - 11:41 Present: jb, tc, tf, nh, ak, gkw

Action: nh to continue investigating sockets from Java Applet
tf: Fonts; does support more than four fonts, but there may be issues with what is available from a particular client. More investigation required, but sun.com was down when tf attempted this morning.
Server Group
- Believe we have a workable architecture (see diagram in first report) that will allow a good distributed nature to the project, with potentially many page grabbers, data stores and teletext servers.
- Should ask for 2 machines from CSG to enable a better demonstration of the features enabled by above.
The minutes of meetings will be on the web from next week.

Supervisor Meeting

27/10/1999 10:00-11:00 Present: ih, nh, ak

1. Specification

Approved amended specification.
MySQL
- Presented tc's comments (see previous group meeting).
- ih questioned what the pros and cons of the approach were, ak felt that it would improve performance and functionality, since queries could be built properly, etc.
nh expressed concern at the amount of time being spent on documentation. ih commented that it was a task that required organisation and delegation. While agreeing nh still felt that the overall load of documentation may be too great.
ih talked about the neccessity for estimating timescales, planning tasks and setting appropriate milestones; even if these are only very rough indeed, a first approximation can be very useful indeed.
Discussed the proposed architecture. ih said he felt it was workable (perhaps with some minor issues) and should be included in the first report.

2. CSG Requirements

Should include on CSG submission that the supervisor suggests 'one machine in the real-time lab and another in 20?'.
Break out WinTV as a separate point, and enumerate clearly that we have already taken possession of one card.

3. Looking like TV?

There is a precise teletext font, which is very similar (with a few differences) to a mode from the BBC computer.
ih's feeling is that it should look exactly as on a television, commenting that some might consider there to be an artistic element to the blocky characters, etc.
On the other hand, others have suggested that the information could be presented more pleasantly, taking advantage of the much higher resolution display, colours, etc.
There is scope for offering other viewing modes on top of the basic, fundamentally teletext 'look'.

4. Other Business

Group should discuss naming, etc.
ih suggested the possibility making the final group presentation a marketing pitch.

Group Meeting

29/10/1999 13:05-13:46 Present: nh, ak, jb, gkw, tc, tf

nh: Congratulations to ak for fulfilling ih's requirements in putting the minutes, etc. on the web.

Reports

Action: ak to send out simple HTML format for documentation.

nh: We need to start writing up our investigations, as this will be needed for the project report anyway. There are four reports to be done currently:

Explaining the choice for storing the server cache. Action: jb for Tuesday
Explaining the choices made in coming to the proposed architecture Action: tc/ak for Friday
Complete investigation into characters and the use of Java's GraphicFont Action: tf/nh for Friday
Detailing the User Interface design, e.g. what choices on remote control, what elsewhere. Action: gkw for Friday

Action: nh to look at capturing keypresses from the browser when the applet does not have focus.

Investigation of WinTV/video4linux

tc reported looking up documentation on VTX (which video4linux implements for teletext support). Assuming it can be made to work, it should offer significant new functionality to make everyone a 'happy bunny'.

Marketing

As brought up by ih at the last supervisor meeting, possibility of making the final presentation a marketing pitch.

Means we will need to identify the potential market, and come u pwith an appropriate name.

ak spoke for some time about how we could deliver to handheld devices using AvantGo, a WAP gateway or similar. Given the focussing of efforts of companies like Palm presently this could be shown as appealing to the enterprise market.

Short brainstorm resulted in some potential names: Netext, Jeletext, Ethertext, webText, iText, eText, Web Interface Teletext (WIT).

Action: all to come to next meeting bearing possible names.

Group Meeting

2/11/1999 11:17-11:57 Present: tf, gkw, nh, ak, jb, tc

nh: Timekeeping. it is important that we start meetings on time, since we are all very busy. The agreed start of meeting should not be seen as a five minute window.

Action: ak to send out details for documentation formatting in HTML.

Reports

jb has put on web.
ak/tc reported that this is on track to be ready for Friday as agreed.
tf reported that GraphicFont seems faster than previously reported (with graphs to show the speed). More research is to be done.
Started and on the way. gkw spoke about ideas for UI.

See previous minutes for a more rich description of each report.

video4linux

tc reported that after spending a considerable effort over the weekend the problem is being cracked. Also explained that there are two possible interfaces:

VBI - allows access to the stream of data. It was broadly agreed that (provided certain technical challenges can be overcome) this would provide the best possible service in terms of filling the cache with the most up-to-date information.
VTX - request based, asking for particular pages

Tom is now essentially waiting on CSG for access to resources to continue investigations further.

Action: nh to chase CSG for resources.

Miscellaneous

Action: ak to split the minutes by month and add a drafts section to the website.

tc reported that there is a very nice code -> HTML generator (LXR) which produces very nice hyperlinked web pages from source files, including references to where functions are used and more. tc believes it would be a very good way to make the source code for the project available and easily read.

ak raised issue of having the most complete version of the documentation on the web at the end of the project, with a reasonable, but less fully featured version to be printed out. Action: nh to put on the agenda for next Supervisor Meeting.

Action: nh to also put discussion of accessing the live stream, using VBI, rather than a request-based system on the agenda for next Supervisor Meeting.

Supervisor Meeting

3/11/1999 10:02-10:36 Present: ih, nh, ak

1. Progress Report

nh reported that we are making good progress.

On availability of resources, ih said we should be able to use the machine in the Real-Time lab immediately. Action: nh to talk to Geoff Bruce in CSG about access to Real-Time lab.

2. Final Report

Can we have the authoritative version of our report as a set of web pages? The short answer from ih is 'no' - a printed report is essential in terms of the moderation of marks, examiners meetings and so forth.

That said there should be nothing stopping us producing a web version of the report which is fully featured, which we might use in the demonstration of the project, the more technical forum, or even in the final presentation, although ih warned that this might impede the flow of the presentation.

3. Accessing Data Stream

ak talked of a possibility uncovered by tc that we may be able to access the data stream directly through the VBI interface in video4linux. This would offer considerable advantage in terms of filling the cache effectively, rather than using a request-response system.

Should this option be viable, it would involve a modification to the proposed architecture, which was discussed briefly.

There is, of course, the possibility that we will not be able to get it working in good time, and may need to have a fall-back position.

4. Other business

ak returned to the issue of off-air, in-vision teletext, noting that BBC 2, when broadcasting teletext pages late at night use a different (serif) font to the standard sans-serif one. ih commented that this may be because they are using a more advanced teletext specification with additional font support.

Action: ak to investigate what the BBC are up to.

Group Meeting

5/11/1999 13:05-13:50 Present: nh, tc, tf, gkw, ak. Apologies for absence: jb

Supervisor Meeting

nh explained the proceedings of the last supervisor meeting.

Reports

tf/nh: GraphicFont investigations look promiosing & continue. tf to write report for rendering scheme for next meeting.

ak/tc: The draft architecture report is in place. More work is needed to incorporate further changes to the architecture depending on progress with VBI.

gkw: Will produce a mock up of the UI over the next week.

Other Business

Working Title: ITX was agreed as a name for the project, which could potentially stand for many things (InfoTeXt, InternetTeXt...).

Group Meeting

9/11/1999 11:20 - 11:40 Present: nh, tc, tf, gkw, jb, ak.

Progress Reports

tc: video4linux is coming along Action: jb to assist tc with final stages
gkw: Swing interface coming together, will be linked in from Drafts soon.
jb: Action: jb to install MySQL on teign
ak: Tangible PHP generation prototype to come for Friday. Graphic buttons on the way (low priority).
tf/nh: tf discussed web/email recognition. gkw suggested pattern matching on 'shape' of address (xxx.yyy.zzz...), tc suggested looking up (locally) based on the top level domain.

Action: nh to supply gif to ak for teletext font.

Action: All to read through minutes so far & give corrections to content, grammar, style, etc.

Group Meeting

12/11/1999 16:03-16:55 Present: nh, tf, gkw, ak. Apologies for absence: tc

nh stated that the next report was due in less than a fortnight. It needs to state what we have done, our final design decisions, etc. We should be getting this written work together now, as it must be done at some point anyway.

Progress

nh showed the teletext font working in Java using a modified GraphicFont. Action: nh to have working in GraphicFont, using three fonts (for text, contiguous graphics and separated graphics). nh to pass font image to ak for Javaless version. After working, nh to rewrite the underlying GraphicFont code to work more effectively for our task.

tf discussed progress made with the parser. Action: tf (to send) by Monday a detailed description of the information he needs to the server group.

gkw has fixed assorted configuration problems with the WinTV card, he reported that we now have a sensible picture. There is still some interference, which may cause problems with teletext reception.

gkw reported that for the UI it is likely that we will drop Swing, as the DoC installation may cause problems with running it within lab. Action: gkw to give list of buttons for the toolbar to ak.

jb reported that the database is now up and running on teign. Some config still to be done.

ak reported on PHP progress. Has some PHP written for displaying teletext, but needs to put font in place before proceeding further. nh supplied the appropriate graphic.

Group Meeting

16/11/1999 11:19-11:50 Present: nh, tf, gkw, ak. Apologies for absence: tc

nh reminded the group that the basic report is due next week, and pointed out where we were on our proposed schedule.

gkw showed a version of the UI, written in Swing, with dockable toolbar and context-sensitive menus. Some work still to do to make work for DoC lab machines. Action: gkw to talk to CSG to discuss the peculiarities of Java within DoC.

tf has sent the interface he needs (in Java). The group must yet determine the lower level structure which the server group will deliver.

jb reported that there have been various problems with teign, now resolved, which have set back configuration of the database.

ak reported that the PHP code for Javaless functionality is coming along nicely. There have been some issues with getting the font into the appropriate internal format.

Supervisor Meeting

17/11/1999 10:04-10:50 Present: ih, nh, ak.

nh discussed the recent progress made:

on GraphicFont - ih commented that the rewritten underlying code could be packaged up as a reusable 'modulette'.
on UI - which was demonstrated after the meeting.
on the server-side - ih asked if the reception seemed to be up to par

Action: ak to get more documentation online, including agendas and potentially screendumps of progress.

ih responded positively to the idea of using an HTTP connection from client to web server which would run a proxy which would speak UDP to the ITX server. ih said this was the sort of thing that he wanted to see more of in the documentation. ak assured ih that this was in hand.

Group Meeting

18/11/1999 12:00-12:50 Present: nh, jb, tc, tf, gkw, ak.

Progress Reports

tc: The priority is getting sensible teletext out. Aiming for the end of the weekend. Action: tc to contact ih to arrange testing the siganl quality.
tf: Presented proposed structure. Action: server group to deliver whatever is most efficiently delivered, to be converted to Tom's format by the client group.Needs to have [page#, subpage#, data, fastext info]*n
gkw: JDK is up and running on teign. Action: gkw to discuss DoC's Swing installation.

Report 2: Project Design & Implementation

ak suggested that we all get our relevent parts written, to the agreed format^* by Tuesday's meeting, leaving a little time for discussion before ak integrates everything.
^*(Headings cascading down from <h2>; paragraphs enclosed in <p></p> pairs beneath that; any images to be in an images subdirectory).

To be written:
- ak: Introduction; Javaless functionality; personalisation.
- tc: Teletext decoding; interface to the database; scheme for updating database; proxy over http.
- jb: Choice of server-side caching mechanism (why a database?, why MySQL?); database schema (for both users and page caching) to the level of detail of table/column structures; describe the simple interface through the 'database server'.
- tf: Handling of teletext pages from nh's part (parsing -> image to screen); client-side caching; use of threads
- gkw: UI explanation with pretty pictures.
- nh: Communications; GraphicFont

Group Meeting

23/11/1999 17:30 - 18:11 Present: jb, tc, tf, nh, ak, gkw

ak: Thanked group for getting documentation to him, Report 2 went well. Apologies also for the new, more terse style of minutes; for reasons of practical expediency, implementation has become more important than lengthy minutes.

Group Meeting

25/11/1999 11:15 - 12:20 Present: jb, tc, tf, nh, ak, gkw

Server Group discussed their progress in working with the live VBI stream. There are some difficulties, and if efforts do not yield more results, the group may turn to using a piece of Open Source software to access the stream.

Group Meeting

30/11/1999 17:00 - 17:50 Present: jb, tc, tf, nh, ak, gkw

Server and client groups to meet immediately after meeting to clarify plans. ak discussed the needs of the client group with a full format for the server-side scripting to deliver data to be decided very shortly.

Due to present a demonstration to ih by the end of term, which will require much work.

Group Meeting

2/12/1999 12:10 - 12:20 Present: jb, tc, tf, nh, ak, gkw

In a short meeting to discuss progress and the plan of action it was suggested by ak that in future we should generally only hold smaller, less formal, ad-hoc, meetings. This will make progress more swift in the final stages of implementation, although it will increase the load on nh who will need to facilitate good communication. We should review progress at the start of the new term, after breaking for MEng tests and Christmas. All agreed.

Group Meeting

10/1/2000 14:30 - 16:30 Present: jb, tc, tf, nh, ak, gkw

All members explained where they were in the course of their implementation, with work still required in most areas, but the interfaces well drawn up.

Supervisor Meeting

12/1/2000 9:00 - 9:50 Present: ih, nh, ak

The group's progress over Christmas was described, we have a fuctioning parts of the system, but without all the connecting parts yet in place. Apologies were given for not demonstrating at the end of the previouis term, but progress over the holidays was good.

ih expressed his desire to see User Testing in the final report and asked what goals were laid down to ensure that the final deadline was met.