\documentstyle[12pt,tgrind,vi,bibcontents]{mitthesis}
\pagestyle{plain}

\begin{document}

%% remember to uncomment next line for final copy.


\pagenumbering{roman}
\input{frills}

%%%%\setcounter{chapter}{1}

%% tgrind -latex -lc filename.c >filename.c.tex
%% \tgrindfile{filename.c.tex}

\pagenumbering{arabic}

\section{Introduction}

LUCY is an Ann Landers type program that allows people in the MIT
community to ask questions on sensitive matters such as harassment
and discrimination.  Users can ask questions and also browse through a
selected list of public questions and answers.  The answers are
provided by a person or persons whom we designate as Lucy.  

The importance of LUCY is in that it fills an empty niche in the realm
of counseling.  While psychiatrists, social workers, advisors, and
friends all play their part in helping people to solve their problems,
there are some problems that are either too intimate, too
embarrassing, or too revealing for many people to talk about.  LUCY is
designed to fill this role.  In providing anonymity to the users, LUCY
gives them the freedom to seek out help regarding problems that they
had never dared to speak with anyone about.  

Also, LUCY is highly available.  Users can ask LUCY questions or
browse through the LUCY browser at any time of the day, and at their
convenience.  This is in contrast to the people mentioned above, who
have other time committments and schedules.  Plus, the fact that LUCY
is free to the MIT community adds to LUCY's availability.  

LUCY was originally written by Bruce Lewis during the month of
December, 1990, using a text-based interface.  It was released
informally to the user community, which complained that it was clumsy
and difficult to use.  As a result of this user feedback, it was
decided that the design and implementation of a graphical user
interface for LUCY was a necessary step in LUCY's development.  

This paper describes just such an extension to the LUCY system.
Specifically, it provides a graphical user interface to LUCY.  This
graphical user interface was built using Motif, X Windows, the Builder
Xcessory from ICS (Integrated Computer Solutions, Inc.), and the C
programming language.

The rest of this paper deals with the design, implementation, and
testing of the LUCY graphical interface.  Aspects of the graphical
interface that were designed included the browser, editor, help
system, and error handling system.  Also, special consideration had to
be given for the maintenance of privacy.  The underlying strategy for
the implementation involved an incremental approach to coding which
facilitated debugging.  For the testing, besides ensuring that the
program functioned correctly, we also needed ways to evaluate the
usefulness and quality of the resulting design and implementation.  

\section{Design}

The design of the LUCY graphical interface involved designing the
browser, editor, help system, error handling system, as well as
dealing with privacy considerations.  These design modules are
interrelated.  For example, the design of the browser and the editor
was influenced by attempts to preserve privacy.  And the design of the
browser was strongly influenced by the editor design, and vice versa.

\subsection{Browser}


A design goal for the browser was to maintain a simple interface.  The
browser needed to: display transactions, display the contents of a
transaction, allow transactions selects, and display transactions.

A split window approach in the style of Xmh seemed to be a feasible
design.  The top window displays a list of transactions, and the
bottom window displays the contents of the selected transactions.
When the user selects a transaction in the top window via a pointer,
the contents of the transaction are automatically displayed in the
bottom window.


When the user starts the LUCY program, we start out in browser mode.
The program displays the list of subject transactions in top window
and the contents of one subject transaction in the bottom window.
When the user selects a transaction by clicking on it with the mouse,
LUCY displays the contents of the transaction in the bottom window.
The user can use scrollbars to scan the list of subject headings.


An advantage of this design is that it is similar to Xmh,
which users in the MIT community would likely be familiar with.  The
similarity between mail abstraction and the meetings abstraction are
great enough that a user who is familiar with the mail abstraction
provided in Xmh will be able to use the LUCY interface without
problems.


Another way to implement the LUCY browser interface would have been to
create a new window every time the user selected a subject
transaction.  But creating too many windows would have cluttered the
display.  Also, the user has to either place each of new windows using
the mouse pointer, or the LUCY interface has to do so.

Still another way to implement the browser would have been to have two
physically separate windows, displaying the list of transactions in
one window and the contents of a transaction in another.  But then the
relationship between the transactions list and the contents of the
particular transaction is lost.  It is not clear to the user that the
two windows are tied to the same function.

When the browser displays a list of transactions from the public
browser, it should be able to display them in both forward and
backward chronology.  Forward chronology means that the subjects are
displayed in the order that they were added to the meeting.  Backward
chronology means that the subjects are displayed with the most recent
subject displayed first and the oldest subject displayed last, with
appropriate ordering in between.

Users who are new to the browser may want to read all of the subjects.
Forward chronological order is just as good as any for this purpose.
but users who have read most of the subjects in the browser will be
most interested in the subjects that have been recently added to the
browser---hence, the usefulness of backward chronological order.  

A possible extension to the browser involves keeping track of a list
of meetings in a special file containing a list of available meetings
and a corresponding filename for each meeting.  
Upon entering the browser, instead of displaying the available
subjects of the single existing meeting, we display the list of
meetings available.  Only when the user selects a meeting, do we
display the transactions available for the meeting.  Thus, the user
can selectively limit his or her browsing to the topics of interest
and ignore other topics.  

The advantage of this approach is that we can group questions
according to subjects and place them in separate meeting files.  For
example, we can have one file for harassment, and a different file
for relationships, and so on.  This way, the user can visit only the
subjects that he or she is interested in.  Also the user doesn't have to
page through a lot of unrelated questions to find useful ones.

\subsection{Editor}

The editor also uses a split screen.  The bottom screen contains the
editor and the top screen is unused.  In fact, the editor and the
browser use the same split screen.  The reason for this is that we do
not want it to be readily apparent whether the user is viewing the
browser or entering a question.  People will be able to tell the
difference if they look long enough, though.  


When the user selects `ask question' from the menu, LUCY enters the
editor mode.  After the user has typed in the question, the user needs
to select `send question' from the menu.  This pops up three dialog
windows, in sequence, to get relevant information, such as whether the
user wants a personal reply, and whether the user wants the question
posted in the public browser.  

It may seem cumbersome to require the user to select `send
question' after typing the question into the editor.  One reason for
this feature is that it wasn't clear that there was a simple way to
exit from the editor.  We don't want the user to have to type in
Control-D, for example, or type in a dot on a line by itself, because
it's awkward and not very intuitive.  If we provided a separate
pushbutton on the screen labelled `done', we would be making the
editor and browser look different from each other.

Also, at some point, we have to display dialog windows to gather
necessary information from the user.  But the longer we have the
dialog windows up, the more obvious it will be to a passer-by that the
user is asking a question.  Having the user select `send question'
from the menu to invoke the dialog windows, keeps the dialog windows
on the screen for a minimal length of time.  

A way to make the `send question' selection clearer to the user is to
display a prompt message to the user to select `send question' after
typing in the question.  This prompt message will be displayed when
the user first selects the `ask question' selection, and will
disappear the moment the user starts editing the question, in the
spirit of the Emacs notification messages.


\subsection{Help System}

Requirements for the help system was that it be highly available and
that it should provide help on whatever topics the user might need.  

The design of the help system is very similar to the design of the
browser.  The help window is a split screen, in which the top window
has a list of help topics, the bottom window displays the contents of
the selected help topic.  When the user selects a help topic in the
top window, the help system displays the relevant help message in the
bottom window.  

The similarity in design of the browser and the help system suggests
that knowing how to use one will help in using the other, since the
interface is essentially the same.  

Currently, the help system is implemented as a list of `windows', each
of which has a body of text associated with it.  This list is easily
editable using a text editor.  And hence it is easy to correct,
modify, and extend.  (See Appendix A for a sample help file.)

A future extension might use the meetings abstraction to provide help.
We would have a meeting containing transactions for each help topic.
This provides no particular advantages, except that the design becomes
a bit cleaner in that it relies on a smaller base of abstractions.

When the user selects `get help' from the menu, if a help window
doesn't exist, LUCY pops up an independent help window.  The user
selects the help topic in top window and the related text is displayed
in the bottom window.  Note that once the help window is on the
screen, it can always be accessed.  The user doesn't need to exit the
help window to return to the browser or editor, since they run
relatively independently of each other.

\subsection{Error Handling System}

Ideally, an error handler should describe what went wrong, why it went
wrong, and what can be done about it (See Section 4).  The error
handling system will manifest itself in the form of error dialog
boxes.  It will display text messages relevant to the particular
source of error.  When an error occurs, the user is notified via an
error dialog box.  Instead of disappearing on its own, the error
dialog box will stay up until the user intentionally cancels it.  We
want to give the user every chance to see the message.

\subsection{Privacy Maintenance}

We need to maintain two kinds of privacy: screen privacy, and user
privacy.  With screen privacy, we don't want people walking by to
read a question that a user might be typing in, because there is a
good chance that the question is in regard to a highly sensitive
issue.  People who choose to ask questions of LUCY are choosing not to
pose these same questions to people in their support networks.  Why?
Because the questions may involve subjects such as abuse, harassment,
or discrimination.  Or the questions may reveal too much about the
person asking the question.    

A partial solution is to make the browser and the editor look the
same, so people in nearby workstations are less likely to pay
attention to someone running the LUCY program.  A passing observer
would have to look carefully to see that a person was entering a
question into LUCY instead of looking through the browser.  The fact
that the vast majority of workstations are in public clusters makes
screen privacy hard to obtain.  But it is very important for users to
be able to ask questions freely and openly in public clusters without
having to hide in a remote corner of the cluster.  

In terms of user privacy, ideally, we want LUCY to be able to respond
personally to the user without knowing the user's username.  This is
possible via the alt.personals server (See Appendix B).  A user can
send mail anonymously to the alt.personals server and still be able to
get a personal reply.  The alt.personals server is able to provide
anonymity by maintaining a database of users and creating aliases for
each user.  For example, if the user ukim sent a message via
alt.personals, the alt.personals server would strip the username from
the message and assign an alias username such as ak76, before
forwarding the message.

For now, we are not using the alt.personals server to provide
anonymity primarily because of time limitations.  For messages
requiring personal replies, we are requiring that the user include his
or her username.  But this brings up problems of authentication.  How
do we know that a user is not sending us someone else's username?

The importance of preserving user privacy is that we want the user to
feel free to ask the kinds of questions that they have always wanted
to ask but never dared to.  Also, people are more willing to talk
about revealing or highly charged topics if they know that they will
not be held accountable for their actions.  This may seem to be a
mandate for irresponsibility, but the need for having an open and
candid electronic forum overrides the issue of accountability.  


\section{Implementation}

The basic programming strategy was to build and debug the fundamental
structure of the program, and perform incremental coding and testing
to build a fully functional program.  

The Builder Xcessory (See \cite{builder}.)  was used to create a basic
interface for LUCY.  The interface code that the Builder created had
to be modified because of inherent limitations in the Builder program.
Also, callbacks (See \cite{young} for an explanation of callbacks.)
had to be written and inserted into the interface code. (See Appendix
C.3 for a listing of the callback routines that were added to the
interface.)  Finally, the LUCY interface was coalesced with the LUCY
meetings code that Bruce Lewis had written.

\subsection{Tools}

Regarding the choice of software tools, Motif was chosen over other
toolkits such as the Andrew toolkit, for several reasons.  The most
important reason was that the author was familiar with it.  Another
reason was that it had good, substantial documentation.  Many books
had been written about it, such as the one by Young \cite{young}.
And the {\em OSF/Motif Programmer's Reference} \cite{osf} explicitly
defined the functions in the Motif toolkit.  And the many examples
available in Young's book \cite{young} were important in understanding
how these functions were used.  

The choice of Motif dictated that the C language also be used.  Also,
in the course of designing the interface, a prototyping tool called
the Builder Xcessory was released by ICS (Integrated Computer
Solutions, Inc.).  Builder was specifically designed to prototype
Motif interfaces.  It was determined that its use would speed up the
initial coding of the interface, since it automatically generated
interface code.  


\subsection{Code}


The LUCY code is composed of five C files and some related include
files.  Three of C files were initially generated by the Builder and
later revised by the author (See Appendices C.2, C.3).  Two of the C
files were written solely by the author (See Appendices C.4, C.5).  A
description of the files follows.

The file main-c.c contains the top level function main() which is
responsible for creating the application shells and calling the
appropriate creation routines.  This file was modified to allow two of
the shells to be popped up arbitrarily by the callbacks.  

File creation-c.c contains the functions responsible for creating most
of the widgets.  Whenever changes needed to be made to the interface,
this file had to be modified by hand to incorporate those changes.
Also, most of the widgets that had originally been declared within the
functions in creation-c.c were made globally available.  This was
necessary, because many of the callback routines needed to access
these widgets.  

The third file callbacks-c.c, as generated by Builder, consisted of
the empty callback function declarations.  All of this
code was written by the author.  These callback functions handle 
user actions, where user actions can be selecting a menu item,
entering text, or selecting toggle options.  

The file viewbrowser.c contains code to abstract the meetings
interface into two routines, Get\_Subjects() and Get\_Transaction().
Get\_Subjects gets a list of subjects from the browser meeting, and
Get\_Transaction retrieves the contents of a subject.  These routines
rely on special library routines that Bruce Lewis (a programmer at
Athena) wrote to hide the details of the meetings interface from the
LUCY system.  

Finally, the file hes.c contains code to manipulate help screens.
Help text is kept in a text file in a simple format that allows
screens to be added, deleted or changed without having to perform any
compilations.  (See Appendix B for a listing of the sample help
file.)  

\subsection{Implementation Notes}


\subsubsection{Builder}

The Builder program allowed the LUCY interface to be created quickly,
but it had some severe limitations.  Changing the interface destroys
any code that may have been added by hand, thus discouraging the use
of the program for any serious work.  At one point, after having added
substantial code to the Builder-generated code, it was necessary to
change the interface in a substantial way.  After modifying the
interface, the author had to obtain listings of the two versions of
code, the first version containing the old interface and the
substantial code modifications, and the second version containing the
new interface with none of the previous code modifications.  These two
listings had to be merged by hand, because there was no program that
could perform the kind of special merging that these listings
required.  Also, the Builder, by default, specifies its widget
resources in the program code, instead of generating a special
application defaults file.  Although it is possible to change this
default for each individual resource, it becomes quickly impractical
to change this default for every resource involved.  The use of an
application defaults file allows users to customize Motif programs to
their own particular needs.  And it also allows programmers to modify
widget parameters without having to undergo a length compile process.
Even with these substantial drawbacks, using the Builder saved much
time in coding the interface.  


\subsubsection{HES}

The help editing system, hes.c, allows help screens to be modified
independently of the program involved.  HES parses the specified help
file to obtain help screens.  A help screen is composed of the name of
the screen and the text associated with that name.  In the sample help
file, the help screen names are enclosed within pipe characters (`$|$')
and the help screen text follows the help screen name.  In the sample
help file, test.help (See Appendix B), the help screen text for a
given help name continues until the next help screen name is
encountered or the special string `$|$EOF$|$' (End Of File) is
encountered.  

HES allows help screens to be loaded from a text file, and it also
provides functions to retrieve the contents of a particular help
screen.  LUCY uses HES to load help information.  Each help screen
corresponds to a help topic in LUCY's onscreen help.  If LUCY's help
file is modified in any way (i.e. help screens are added, deleted, or
changed.), these changes are reflected in the next invocation of the
LUCY program.  

A person who had edit access to the LUCY help file could update the
onscreen help documentation quickly and easily.  He or she would need
to know nothing about compiling programs since no re-compilation would
be involved.  As a result, maintaining and updating the LUCY help
messages becomes a trivial task. 


\subsubsection{Constraints}

When the viewbrowser (See Appendix C.4) reads in the subjects in the
browser meeting, there is an arbitrarily defined limit of 4096
subjects.  If there are more than 4096 subjects, viewbrowser will only
retrieve the first 4096.  Also, the contents of a transaction is
limited to 16384 characters in length (roughly 8 pages of double
spaced text).  This, again, was an arbitrarily defined limit.  
These limits made it possible to write the program without having to
deal with dynamic allocation.  

\section{Testing and Evaluation}


The use of incremental programming (See \cite{schildt} for a
discussing of incremental programming.)  allows code to be written
quickly and efficiently.  The basic idea behind this approach is to
always maintain a working base program from which to add on additional
sections of code.  At any point in the process, we add only a small
section of untested code to the working base.  If a bug is discovered
there is a high probability that it occurred in the section of the
code that was added most recently.  Hence, there is a localization of
errors, which allows for easier debugging, since discovering the
source of error is can otherwise be an arduous debugging task.  


No design process would be complete without a way to verify and
validate the integrity of the design.  Ideally, we want to test out
the interface on a sampling of users.  We could get their feedback on
what is clear and what is confusing.  Also, we could get suggestions
from them as to how it could be improved and then rewrite the
interface with these suggestions and comments in mind.


Although we eventually want to test the resulting design on a broad
sampling of users, this is sometimes not practical, because of time
constraints.  It would be useful to be able to evaluate a user
interface design more abstractly.  And to do this, we need to
determine what constitutes a good user interface.  


With regard to design, Norman \cite[page 188]{norman} writes that:

\begin{quote}

Design should:
	
\begin{itemize}

\item{Make it easy to determine what actions are possible at any
moment (make use of constraints).}

\item{Make things visible, including the conceptual model of the
system, the alternative actions, and the result of actions.}

\item{Make it easy to evaluate the current state of the system.}

\item{Follow natural mappings between intentions and the required
actions; between actions and the resulting effect; and between the
information that is visible and the interpretation of the system
state.}


\end{itemize}

\end{quote}

With regard to the LUCY GUI design, the menu system makes it obvious
what is possible (bullet 1).  Also, it would be good to gray out
undoable actions, making it apparent to the user that certain actions
are not possible.  When LUCY is in editor mode, we place a blinking
cursor in the edit region to show the user that we are in edit mode,
thus making use of a natural editing constraint.

Some features of the LUCY GUI are not obvious.  For instance, it's not
obvious that, in browser mode, the user should click on the browser
selection to view it.  It's also not obvious that Emacs commands are
provided in the text editor.  And for that matter, Emacs commands are
not very intuitive.  Fortunately, the arrow keys and delete key work
as expected, providing minimal functionality for non-Emacs users.


Most actions in the LUCY GUI provide automatic feedback (bullet 2).
The action `Send Question', pops up multiple dialog windows.  `Help'
pops up a help window if it does not currently exist.  Selecting a
transaction with the mouse displays the contents of the selected
transaction in the lower window of the LUCY GUI output.  And, of
course, text editing provides plenty of feedback to the user.  

The LUCY GUI has two states that look virtually identical.  This is in
conflict with Norman's suggestion to make distinct states look
different from each other (bullet 3).  The reason why the two major
modes, the browser and editor modes look virtually identical is
because we want privacy on the screen level.  This privacy was more
important than the guideline Norman stipulates regarding states---hence
the deviation.  

The use of status messages helps to promote the ease of use that
Norman advocates, while maintaining the similarity between editor and
browser states.  When the user switches from the browser to the
editor, we display a status message telling the user how to use the
editor.  The status message disappears when the user starts to edit.
Note that we do not need a status message for the switch from editor
to browser; we can simply display the contents of the most recently
selected transaction in the bottom output window.  

Norman also advocates making actions intuitive (bullet 4).  Users who
have used Emacs and/or Xmh will probably find the interface intuitive.
After all, much of intuition is based on experience.  The LUCY GUI
assumes that the user is familiar with menus and mice, as well as the
concept of e-mail.  There is a tradeoff between designing for a user
who knows little about the system and designing for a user who knows a
great deal.  It is easier to design for a user who knows much about
the system, because a lot of things that have to be carefully
explained to the novice user may be omitted in dealing with an expert
user.  In the case of the LUCY GUI, we are designing for the novice
user.

In regard to what constitutes a good interface, Norman \cite[page
200]{norman} writes that a good interface: ``[allows] the user to
recover from errors, to know what was done and what happened, and to
reverse any unwanted outcome.''

The LUCY GUI error handling system tries to let the user know what has
happened, why it happened, and how to fix or deal with the error.
This follows Norman \cite{norman} very closely.  One exception to
Norman guideline occurs because sometimes it may not be possible to
reverse an unwanted outcome.  For example, if a server is down,
preventing access to the LUCY public browser, it is usually not in the
user's power to bring it back up.

Norman \cite[page 200]{norman} suggestion that one should ``Design
explorable systems.'' is good because it encourages the user to try new
things more willingly.  When the user knows that his or her mistakes
are not fatal, they will be more willing to try different approaches
to obtain a desired result.  The comprehensive error handling in the
LUCY GUI encourages exploration by giving the user a semblance of
control over the system.

Joseph Dumas \cite[page 50]{dumas} lists, from highest to lowest
priority, a similar set of guidelines:

\begin{quote}

seven principles of interface design:

\begin{itemize}

\item{Put the user in control.}

\item{Address the user's level of skill and experience.}

\item{Be consistent.}

\item{Protect the user from the inner workings of the hardware and
software.}

\item{Provide online documentation.}

\item{Minimize the burden on the user's memory.}

\item{Follow the principles of good graphics design.}

\end{itemize}

\end{quote}

The last item in Dumas' guidelines is worthy of note because it
emphasizes aestheticism.  By ``good graphics design'', Dumas means to
make display, especially text, look aesthetically pleasing.  This is
an important consider.  Contrast a typewritten page with a
proportionally printed laser print out.  Proportionally printed text
is much easier to read, as well as being easier on the eyes.

\section{Analysis}

\subsection{Design Changes}

The implementation of the error system turned out to be simpler than
it was originally planned to be.  Originally, it was to use the HES
(help editing system, See Appendix C.5) to display error screens.
This turned out to be much more than was actually required for the
program, because there are not very many errors that can occur.  Also,
the notion of explaining what happened, why it happened, and what to
do about it is good, but is, again, more than was actually required
for LUCY.  

Originally, LUCY was designed to have two modes, a browser mode and an
ask question mode.  Due to the use of callbacks, it turned out to be
unnecessary to have modes.  LUCY can tell from the context of the
operation whether it is possible or not.  And only possible operations
are allowed.  For example, if the user tries to send a question, but
has not yet entered a question, LUCY displays an error message telling
the user what he or she has done wrong, as well as what to do next.

\subsection{Observations}

In the course of doing incremental programming and testing, due to the
use of informal testing, the SendQuestion feature had not been tested
for the previous ten edit, compile, and test cycles.  When it was
finally tested, it had the unfortunate tendency of terminating the
program with a `Segmentation Error'.  It was not immediately obvious
when this bug had been added to the code, since it could have been
added in any of the previous ten edits.  A program was needed to
simulate user actions and record the results of the actions in a
useful way, i.e. a test driver for Motif programs.  For a moderately
intricate interface, it is too tedious and error-prone to test each
menu item selection and step through all of the available options.

Eventually, the author was able to localize and fix this bug, but the
use of regression testing would have detected this bug when it had
first cropped up.  The use of fprintf statements that were sprinkled
throughout the code was a useful diagnostic in locating the source of
the bug.  Regular printf statements would not have helped in
localizing the bug, because UNIX buffers standard output.  A message
that had been printf'ed before the program crashed might never be seen
by the programmer because of this buffering.  Fortunately, UNIX does
not buffer standard error---hence, the use of fprintf's to localize
bugs.

Sometimes the best way to deal with errors is to work around them.  In
viewbrowser.c (See Appendix C.4), Get\_Transaction() calls the discuss
routine (See \cite{raeburn} and \cite{zanarotti}) dsc\_get\_trn() which
is supposed to retrieve the text of a transaction.  dsc\_get\_trn
requires the specification of a tfile (See \cite{raeburn}) which is a
special type of file.  The documentation available \cite{raeburn}
lacked examples that would have clarified both dsc\_get\_trn and tfiles.

The author was eventually able to use both dsc\_get\_trn and tfiles by
taking a circuitous route.  The process by which this occurs is as
follows.  The program associates a disk file with standard output.
Then it converts standard output into a tfile using the command
unix\_tfile().  The function dsc\_get\_trn() gets the contents of the
transaction and outputs it to standard output, which has been
re-routed to the disk file.  This disk file is closed and then opened
again.  We then read the contents of this disk file to get the text of
the transaction.  There is a command to directly read a tfile, called
tread, but the author could not understand it well enough to use it.  

\section{Conclusion}

\subsection{Constraints}

Some factors that influenced the design of the interface included:
time limitations, privacy considerations, and the existing design of
LUCY.

Because of time limitations, the scope of the problem was reduced from
providing a dual interface to providing the public interface.  The
public interface deals with users who ask questions and browse through
the answers, whereas the dual interface would also have included the
private interface.  This private interface would have provided a GUI
to the person or persons representing LUCY, and would have mediated
such tasks as: answering questions, posting questions and accompanying
answers in the public browser, editing questions, archiving questions,
and others.  While only a few people would interact with the private
interface, many people were expected to interact with the public
interface---hence, the selection of the public interface for design
and implementation.

Regarding privacy considerations, there were two different types of
privacy to consider (See \cite{lewis}).  When a user sends a question
to LUCY, the user may wish to remain anonymous, especially if the
question is in regard to a sensitive matter.  Yet the user might want
a private reply.  The problem is how to have LUCY respond to a user
without knowing the identity of the user.  The other type of privacy
to consider is that, since most workstations are in public clusters,
there is a high probability that people walking past terminals will
notice that a particular user is running the LUCY program.  This can
be potentially embarrassing for the user, especially if the user is in
the midst of asking a sensitive question.

In designing the graphical interface to LUCY, the existing design of
the LUCY program itself had to be considered.  In particular, the LUCY
system is built on top of a meetings structure, which constrained the
types of interactions that were possible.  Had LUCY been based upon a
different data structure, this would have constrained the types of
interactions in other ways.  

An example of a different data structure that might have been used is
the hierarchical tree structure (as in the UNIX directory structure).
While the meeting interface provides only two layers of hierarchy (the
meeting name is the top layer and the meeting's transactions form the
bottom layer), the hierarchical tree structure would have provided
many layers.  Hierarchical structures allows information to be
retrieved quickly and efficiently.  In order notation, a hierarchical
data structure allows information to be retrieved in $O(log \ n)$ time,
whereas the meetings structure allows information to be retrieved in
$O\,(n) time$, where n is the number of elements in the particular data
structure.  This is the difference between quickly flipping to the
appropriate subject topic in an encyclopedia versus starting from the
beginning of the encyclopedia and skimming page after page until
the right topic is found.

But there are advantages to using the meetings interface.  One
advantage is that it provides a solid software interface that has been
thoroughly debugged.  The similarity between the meetings interface
and mail allows easy translation between the two.  One can send a
transaction by mail or send mail via transactions.  Also, the meetings
interface allows for ambiguous topics better than the hierarchical
structure mentioned above.  Whereas, in a hierarchical tree, a
question may be filed under one of many nodes, there is no such
confusion in the meetings interface.  A question is either in the
specified meeting or it isn't.

\subsection{Future Improvements}

The following are a list of improvements and bugs to be fixed:

\begin{itemize}

\item{Provide an adequate help file.}

\item{The text window should stay the same size instead of resizing
dynamically as the text is being displayed.}

\item{When the user selects `Enter Question', have the text cursor
immediately appear on the screen.  Currently, the user has to click on
the mouse pointer.}

\item{Entering a question: text editor needs more emacs bindings---the
current ones are inadequate.}

\item{LUCY help window's iconified name should be changed from
popuphelp to lucyhelp.}


\end{itemize}





\appendix
\include{append}

\include{biblio}


\end{document}




\begin{figure}
\fbox{
\input{../xfig/schem1}
}
\end{figure}



Figure 2 should follow.

\begin{figure}
\include{../xfig/buildplan}
\end{figure}

\begin{figure}
\include{../xfig/block}
\end{figure}



The word meetings here is used in a special way, where there exists a
meetings server.  Clients can visit meetings and add transactions.
(reference the discuss papers here.)  A transaction is similar to an
e-mail message.  And a meeting is a collection of transactions having
a common theme.  
