Download Human Computer Interaction Design Report

Design Specification
From our design framework it was quickly apparent that the vast majority of the
work was at the co-ordinators end, since we do not know how computer literate the
club member is. We decided that all the club member would want to do is select
whether or not they could attend the specified event, however we also thought that
the possibility of more complex member functions could be included through a
linked web interface, this will be covered in more detail later.
We outlined the co-ordinator’s main stages of user activity as defined below:
Goal
Co-ordinate and manage his club in a fast and efficient manner.
Sub-Goal
Send out information about events.
Edit database of members.
View replies to previously sent e- mails.
Tasks
Setup a meeting.
Send out e-mails.
Add new members.
Edit old member profiles.
This is the very basic user model that we will be working with. Our system should
allow the co-ordinator to perform these basic tasks intuitively and provide extra
functionality to facilitate his job without creating annoyance should he want to
perform the simple tasks quickly.
At this stage we felt that we had a good enough outline to try and decide which
design environment to use as different programming languages will provide a
different set of constraints on the design. Our options were fairly limited and it fell
to a choice between:
• A highly graphical interface such as Delphi which would require some
additional coding to create interaction between the system and the user
using e- mail and would be a fixed location hard drive based application.
• A more restrictive language such as HTML, PHP and MySQL which limit
your design in terms of the interfaces which can be produced, creating
custom I/O methods would be complex, but which is ideally suited to the
task with specific database and internet based data transfer functions built
in. This method also has the advantage of allowing the co-ordinator to use
the system from any work station, so long as a secure login was provided.
We felt that the second option was the best choice as the MySQL functions seemed
ideal suited to the task. Also using HTML it would be extremely easy to implement
a member’s website displaying information past and future meetings and who will
be attending the next meeting (special care would have to be taken not to breach
the data protection act).
Hierarchical Task Analysis
The very last stage of defining our design specification was to create a task
analysis for the user model defined on the previous page. This is represented on the
next page for the tasks of adding a meeting and adding a member. This is an
outline of the exact tasks our system must perform to