COMP 675 Winter 2000 Project
Project Overview
An important part of this course is the design project.
As a member of a design team of 5-7 students, you
will apply the methods and skills learned in class
(and hopefully elsewhere) to the design, prototypic
implementation, and evaluation of a realistic user
interface for an application. The project consists
of several parts, which will be graded separately.
Each team is supposed to produce joint deliverables,
which will be the basis for the grades of all team members.
The team members will also be asked for feedback on the
performance of the other team members. This subjective
feedback may be used to adjust individual scores.
Project Theme: User Interfaces for Knowledge Management
I expect the members of a team to suggest their own project topic,
based on the overall project theme.
If you have any doubts, you can talk to me about the selection of
the topic. As a general theme, I chose the combination of
a current topic in the fields of computer and information science:
Knowledge Management.
Knowledge Management
Many of the tasks performed by or with the help of computers
deal with the processing and organization of information,
often in the form of documents. In this document management field,
computers perform tasks that are precisely specified by the
user or a programmer (e.g. calculations in a spread sheet).
All the tasks related to the knowledge contained in the document
have to be performed by the user, with relatively little assistance
from the computer. A typical example is the use of a search engine
on the World Wide Web: A user types in some keywords, and the computer
finds documents that contain occurrences of the strings of characters
the user entered. The computer does not take into account the
meaning of the keywords: It won't find documents containing
keywords with similar meanings, or in different languages, or
documents in a format other than ASCII characters.
Offering computer users better support for knowledge-oriented
tasks is the goal of a trend referred to as knowledge management.
This is somewhat different from the knowledge representation and
knowledge processing issues addressed in the field of Artificial
Intelligence, where computers perform logical conclusions on the
basis of stored facts and rules. In knowledge management,
computers are used for a more shallow treatment of knowledge:
Instead of performing knowledge-based tasks directly, they
help users perform such tasks more easily, more efficiently, or
with better results. An example is the enhancement of keyword-based
search with similar terms: In addition to the term entered by the
user, the computer offers a selection of terms with similar meanings.
Such terms can be taken from a thesaurus, a dictionary, or
more complex repositories such as ontologies.
If you're interested in reading more about this topic,
here is a pointer to a
paper I wrote. This is work in
progress, and any feedback is most welcome.
Your choice of a project topic is not necessarily restricted
to the design of appliances or devices for knowledge management.
However, you must address the issues of
knowledge management in your project, especially in the
evaluation criteria and the testing and evaluation plan.
To do this, you should consider the following two questions:
- How can a user get to the relevant knowledge about
some topic, rather than being swamped with data
that seem only superficially related?
- How can your system help the user dealing with the
knowledge related to the task, in contrast to
simply delivering information?
A good example are search engines for the World Wide Web:
Searching for something on the basis of keywords is often
not very satisfactory, because the keyword alone is not
sufficient to separate usefull from useless knowledge.
Project Organization
The first part of the task will be to select an application,
and to establish user requirements to serve as the basis for the
later evaluation of the user interface.
Then a prototype of your selected application will be implemented.
Note that in many cases, due to time constraints, this
prototype will not be fully functional, but it should
have a "front end" that can be used for evaluation purposes.
In the last part, the prototype will be evaluated.
Since it is obviously difficult to evaluate your own product,
the evaluation will be performed by a
different team.
Finally, there will be a presentation on the project.
This presentation will focus on the last part, the evaluation,
and must include information on the initial user requirements,
design, and implementation performed by the original project
team. Both for the evaluation and the presentation it is
very important to provide the evaluators with good documentation.
This will be done with the help of design notes described next.
Design Notes
In your design notes, you should capture all relevant information
about your project, such as user requirements, reasons for
design choices, technical problems encountered, reasons for the
selection of development tools and environments, status reports, etc.
These design notes serve at least two important purposes:
First, they will be graded. Second, they will be used by the evaluation
team to perform the review of your project, and will contribute
substantially to the technical aspects of the final presentation
given by the evaluation team.
Organizational Aspects
In order to facilitate the exchange of information, especially
between the design/implementation and the evaluation teams,
the design notes must be kept as a Web-based document;
a template is available
to give you some guidance on the organization of your notes.
Templates
Please use the templates for the preparation of your project documentation.
Since all projects will be put together into a common Web page,
I suggest to follow the overall format as provided here.
If necessary, split up the template into separate pages,
or insert navigation aids.
Team Accounts
Group accounts will be established for each team,
so that you don't have to put your documents
on your personal Web pages. There will also be a
general class account through which all the individual
team documentations will be accessible.
A Web Page coordination group will coordinate these tasks, and
possibly develop an alternative Web framework for the documentation
of the projects.
The following paragraphs provide you with more details
on the different parts of the project. Included is information
on the time frame, and the contribution of the part to the
overall grade. For exact information on the time frame,
please consult the class schedule.
Project Summary
In the project summary, you are asked to answer some questions
about the application or system you will develop. This summary
covers important aspects of system development, and will help
you do consider these aspects systematically in the early
stages of development.
Project Part 1: Selection and Requirements
The first part of the project has two main objectives:
- Selection of the application.
- Elicitation of the user requirements.
Your team needs to identify an application you'll be working on,
and to clearly specify the task the system is supposed to solve.
In many cases, it will be useful to look at existing systems
for the selected or a similar application, and identify
features that are missing or can be improved.
In the ideal case, a summative evaluation should be performed
on a fully developed system that is used in a real-world
application by the actual users. Since this is practically
impossible in a classroom setting, you will have to "switch hats"
from your customary designer or programmer's perspective, and
look at the task to be performed from a user's point of view.
To establish the required functionality as well as usability aspects
is also known as requirements elicitation. For large systems,
these requirements are sometimes translated into a formal system
specification, which serves as blueprint for the actual implementation,
and as the basis for the evaluation and testing of the system.
Again, it is not practical here to perform a full requirements
elicitation or a formal specification, but you need to put
down the crucial functional features of your system together
with important usability aspects. Please note that especially
the usability aspects will be used by the evaluation team to
perform the assessment of your project. By providing concise
and clear definitions of these aspects, you will be able to
focus more on the technical aspects of the prototype implementation,
and it will be much easier for the evaluation team to derive
the evaluation criteria for the assessment of the system.
Please use this template
to prepare your documentation of the first part of the project.
Project Part 2: Prototype
The two important aspects for this part are:
- Implementation of the prototype.
- Preparation of a testing and evaluation plan.
After clarifying the requirements for your system,
you will implement a prototype of it. Depending
on your domain and application, you may either
use an existing application, and develop a new
front-end for it, or concentrate on the user interface
part of your system without actually implementing
the underlying functionality. In any case, the
prototype should be substantial enough for
users to play around with, and to get a feeling
for the interaction with the system.
For this part of the project, you will need to
concentrate on the technical aspects, relying
on the specifications and design notes from
the first part of the project. This is the kind
of work you're probably most familiar with;
nevertheless, you should not underestimate
the amount of time that is needed to build
the prototype.
In addition to the actual prototype of the system,
you will work on a a plan for the testing and
evaluation of the system. Again building on previous
work, you will describe a collection of usage
scenarios, ideally in combination with some
clearly defined benchmarks that allow a well-founded
evaluation of the system, and its comparison with
other, similar ones. You should show the overall
user interface to potential users as early as
possible, even if the prototype is not finished,
and get some feedback from them. This will help
you to incorporate changes early in the design
stages, when they are relatively cheap to implement.
Make sure to have a record of the user feedback,
either as video, audio tape, or interview notes.
The testing and evaluation plan will be based on
material learned in class. You can either read
the respective chapters in the text books early,
or make sure that much of the implementation work
is already done when we get to those chapters.
This way hopefully you'll be able to devote enough
time to the development of the testing and
evaluation plan. Keep in mind that this plan
will be the basis for the evaluation performed
by another team; even if you have a wonderful
prototype, a lousy testing and evaluation plan
is an excellent basis for an unsatisfactory
evaluation ;-)
In order to facilitate collaboration between teams,
all implementations and documents must be accessible
via the Internet, either as Web-based application,
or by making the executable downloadable.
Project Part 3: Evaluation
The evaluation team will perform the tests and evaluations
described in the previous part by the development team.
The overall evaluation will be presented to class in
a final presentation, and documented as Part 3 of the project.
The evaluation team also may suggest changes to the system itself,
and to the testing and evaluation plan. Remember that this
evaluation is done on the prototype of the system. Changes
are still relatively easy to incorporate into the final design,
and improvements for the testing and evaluation of the final
system will also be easy to incorporate. On the other hand,
this evaluation is restricted to a partial functionality,
in our case mainly the user interface, and does not cover
the full scope of the final system.
The evaluation will be done in parallel with the work on
the design and implementation of the prototype. Important
milestonse are of course the first and second part of the
documentation.
Project Presentations
Depending on time constraints, we may have short, initial or
intermediate presentations to introduce the project, and
show the progress made; this presentations will not be
graded separately, but may influence your team's mark
for the documentation.
The "official", final presentations for the project will be given as a joint
presentation by the development and the evaluation team.
The development team will present the task, purpose, design,
and implementation of the system, and the evaluation team
will report on the evaluation of the system. The overall presentation
must adhere to strict time limits, plus a short time for discussion.
Presentations that go over their time limit may be
interrupted, get a lower grade, or both.
If time and circumstances permit,
a quick demo of the main functionality of the system should
be integrated into the development team's part.
The discussion time can be used for questions and feedback from
the audience, or for the clarification of misunderstandings
or controversies between the development and the evaluation team.
A Few Notes on Teamwork
A substantial degree of your grade in this class depends on
the overall performance of your team. This can be good
(you do nothing, and still get a good grade) or bad
(you do all the work, but nobody else does anything, and
the overall result is not enough for a team). Ideally,
every team member should contribute a roughly equal share.
In reality, this is not the case because team members have
different backgrounds, experiences, work habits, cultures,
etc. Just like in a professional work environment, you
have to find a balance between looking after your own interest,
and contributing to the overall team effort.
If at any point you feel that there are serious problems
with your project team, feel free to talk to me, and we
can try to find a solution. I may also ask for additional
documentation to check the contributions of the
individual team members.
Towards the end of the term, I will ask for feedback on
the work within the teams, and if you feel that the
distribution of work has been reasonably fair.
In case there is a consistent and considerable inequity
in the distribution of work and responsibilities, I might
deviate from my usual policy of grading a team as a whole.
Franz Kurfess
Last modified: Mon Jan 17 12:34:15 EST 2000