% design2.tex is the same as design.tex except that 
% specs.tex file is included directly in the text for design2.tex.
% 
\documentstyle[doublespace]{article}

\pagestyle{headings}

\title{Design of a LUCY Interface}

\author{by UChin Kim \\
	Thesis Supervisor: Bruce R. Lewis \\
        \\
        \\   }

\date{}

\pagenumbering{roman}

\begin{abstract}

This paper discusses aspects of the design of a graphical interface
for the LUCY program.  Also included are a list of preliminary
specifications for most of the functions in the current LUCY program.


\end{abstract}

\maketitle

\pagebreak  % need this to separate the title from the table of contents

\tableofcontents

\listoffigures

\pagebreak

\begin{document}

\pagenumbering{arabic}
\setcounter{page}{1}

\begin{center}

{\Large Design of a LUCY Interface}

\end{center}

%%%%   HAVE TEXT HERE.   %%%%%%

\section{Design Considerations}

\subsection{Global Considerations}

\subsubsection{Interface}

The most obvious decomposition of LUCY is into two separate
interfaces.  One interface is the user interface, used for asking
questions, browsing through the public browser, etc.  The other
interface is for the answerers, which we will, for now, call the
reply interface.  

Advantages of this dichotomous breakdown of the LUCY interface
include: 1. We can limit access to the reply interface and hence
access to private material.  2. We can limit the user's access by
limiting the user interface.  3. The user's interface is not cluttered
with useless functions.  

I can think of no disadvantages to implementing two separate
interfaces.  It wouldn't necessarily be more work because there will
be much reuse of existing concepts and structures between the two
modules.  

\subsubsection{CLI Interface}

While menus are easier to use initially, some users will indubitably
prefer a command line interface, especially the person or persons
representing LUCY.  Ideally, the user should be able to interchange
mouse clicks with keyboard commands.  This is a nice feature to have,
but not a necessary one.  Time constraints will affect whether this
feature will be included.  


\subsubsection{Help Function}

Help should provide exactly the help information that the user needs.
This suggests that a browser type of interface might be useful.  The
user could browse through a hierarchy of help windows to locate the
specific help that he needs.  This is reminiscent of the Emacs Info
program, which allows the user to browse through on-line documentation
through a series of menu selections that specify what section of the
documentation the user is interested in.  The user can quickly find
out the information he needs to know.

\subsubsection{Error Trapping}

In an article on user interfaces printed a few years ago (I don't
remember where), the writer suggested that every error message should
be composed of three parts.  The first part tells the user what went
wrong.  The second part tells the user why it went wrong.  And the
third part gives the user suggestions on how to fix it or what to do
next.  

This is a very useful decomposition of an error message, because much
of the problem of error messages is that they are rarely oriented
toward the typical user who isn't interested in what a ``Segmentation
error'' is, but is interested in how to get his program working again.
Programmers tend to program error messages that assume a lot of
related and crucial knowledge on the part of the user, that the user
often doesn't have, and doesn't care to have.

\subsubsection{Menu Organization}

One basic strategy involves limiting the number of menus to about
seven available menu selections at any given time.  Having
significantly more than seven menu selections results in the user
spending much of his time scanning through the list of menus.  

Menu buttons should be easy to understand.  Otherwise, we defeat one
of the purposes of using menus.  The menus will be arranged in a
hierarchy.  Due to the resources feature of Motif, we can defer the
exact arrangement of the menus until runtime.  It should be relatively
straightforward to experiment with different menu layouts to find a
reasonably optimal layout.


\subsection{Specific Considerations}

\subsubsection{Browser}

Ideally, the public browser would be able to display questions
arranged according to topics and subtopics.  Users could then focus on
the questions they are interested in, instead of having to browse
sequentially through all the questions.  

However, if the number of question-answer pairs in the public browsery
never grows too large (less than 100 question-answer pairs), the
sequential method would be preferable in terms of simplicity of
implementation.

Also, multiple files could be set up so that each file contained
question-answer pairs corresponding to one topic.  Users could view
the files they were interested in.  If the number of question-answer
pairs under a given topic grew too big (greater than 200
question-answer pairs), the topic could be split up into two
sub-topics (e.g. questions under the topic SEX could be split up into
two sub-topics: CASUAL\_SEX and INTIMATE\_SEX) Sequential browsing
would be adequate for using this method.  What needs to be determined
is methods for splitting up topics into sub-topic as well as combining
topics.

For the hierarchical browser method, we could use one large file or
alternatively multiple files to keep track of the question-answer
pairs, plus topics and sub-topics.  A person using the reply interface
could categorize a question by choosing from the list of current
topics, or by specifying a new topic if appropriate.  Also, the user
could specify the topic for his question.  

Regarding using the browser, the user could specify first a topic and
then, if necessary, specify a sub-topic to narrow in on a range of
questions.  The hierarchical browser would require some way to keep
track of topics and sub-topics.  Possibly, we could have a special
file(s) to keep track of topics and sub-topics as well as their
related filenames.

\subsubsection{Editor}

The editor interface should be able to emulate any of several
different editors, such as: Emacs, vi, EZ.  In practicality, I will
probably incorporate an Emacs-like interface for the editor.
Appropriate help screen(s) will guide users not familiar with Emacs.

The editor should have two distinct sections: one section for
displaying and editing the question, and one section for displaying
and editing the answer.  Users would only be able to edit the
question.  Repliers would be able to edit both fields.

\subsubsection{Fields}

Some parts of LUCY require answers to a sequence of questions.
Default answers should be provided in a field environment, such that
the user has the option of accepting the default responses to all
questions or editing selected parts of the field.  This has the
significant advantage of keeping user responses to a minimum.  It can
be tedious for a user to answer a set of questions every time he wants
to ask a question.


\subsection{Other Considerations}

\subsubsection{User Anonymity}

One way to handle user anonymity would be to incorporate a dummy name
feature into LUCY\footnote{Michael Mermelstein '94 suggested this idea
to me.}.  If a user wants a personal response from LUCY, he can
specify a dummy name that he can later use to obtain LUCY's answer to
his question.  Metaphorically, the user is specifying a key by which
he can later access the answer to his question.  No other user can
access this answer without the key.  This allows LUCY to respond to
anonymous users who want personal relies.

When the user has retrieved the personal reply via his keyword, LUCY
would then be able to delete the question-answer pair from its private
queue.  

Possible problems with this include the following: the user might
forget his keyword, users might have trouble using the feature,
another user might be able to guess a user's keyword and thereby
obtain an illicit question-answer pair (and the genuine user would
never get his reply).  

To handle the case of a user forgetting his keyword (and thereby be
unable to access LUCY's reply), we could either have a provision that
keeps a limit on the maximum number of question-answer pairs in the
private queue, so that if the queue is already at maximum size, we
discard the oldest question-answer pair.  Or we could decide to
discard all question-answer pairs in the private queue that have been
in the private queue for longer than n days.  Possibly, instead of
discarding private question-answer pairs that have been unaccessed, we
could post them in the public browsery so that the user might be able
to get his reply after all.  Anonymity would be preserved in any case.

Users that are not familiar with the safetybox metaphor as used in
this approach might have initial difficulty with it.  Help windows
should provide necessary help in this respect.  

To guard against rogue users that try to guess keywords and thereby
access a question-answer pair that they don't own, we could set a
limit on the maximum number of failed guesses that LUCY will allow
before exiting to the system.  Of course the rogue user can always
restart the LUCY program again, but this wastes the rogue user's time
so that he may consider not worth the trouble.  In any case, the
likelihood of this happening is relatively small.  If this turns out
to be a problem, we can always program additional safeguards into the
program.

\subsubsection{Dialup Access}

For LUCY to work via dialup access, LUCY must use pure text (no
graphics).  The simplest way is to have two versions of LUCY, one
version to use X Windows, and the other version to use a
terminal-based approach.  This design will, of course, be the X
Windows version.  


\subsubsection{Forwarding}

When LUCY forwards a problem to an expert, she must arrange for a way
to get a reply back from the expert.  The question should be sent by
e-mail, since a given expert is more likely to be familiar with e-mail
than with LUCY.  The straightforward way to handle forwarding is to do
it manually, i.e. mark that a question has been forwarded, as well as
marking that a question has been successfully answered.  


\subsubsection{Motif}

My major reason for using the Motif is that I am familiar and
comfortable with it.  Motif provides the necessary tools I need to
build the LUCY interface.


\section{Implementation Strategy}

My basic implementation strategy is to implement the interfaces
separately from the LUCY program.  Then, after I get the interfaces
working, I can add parts of the existing LUCY code 
incrementally until it is complete.  

I will have to make sure initially that my design will allow me to
glue the functional parts of the LUCY code (as opposed to the
interface parts) with my interface.  This will involve examining the
existing source code to determine how the current interface and
functional parts are currently composed.  

In regard to implementing the interface separately, I will also have
to write appropriate stubs and drivers in conjunction with the
interface.  But this should be a simple matter.

The advantage of implementing the interface separately is that it will
allow me to ensure that whatever bugs arise will be due to my
interface code and not due to the functional code.  A remote danger is
that, after I write the interface, I may find it cumbersome to fit the
two sections (interface and functional) together.  But I should be
able to avert this problem by studying the existing design in detail.


%\subsection{subsection here}


%\begin{figure}
%\fbox{
%\input{../xfig/schem1}
%}
%\caption{Title of Caption Here}
%\end{figure}


\section{Preliminary Specifications}

\ \\
\ \\


% specifications file for LUCY


\begin{tabular}{||l|l||} \hline
Name     & Show                                        \\ \hline
Function & Displays question and information related \\
	 & to it. \\ \hline
Inputs   & A way to select the question \\ \hline
Notes    & Simple interface with limited input \\
	 & requirements.  Display procedure and editor\\
	 & seem to have an abstraction in common. \\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Archive                                     \\ \hline
Function & Archive a question or set of questions \\ \hline
Inputs   & Select a question or set of questions \\ \hline
Notes    & limited input requirements, Add cancel \\
	 & and help buttons. \\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Edit (Comment) \\ \hline
Function & Lucy can edit a QA pair so that it can \\
	 & be published.  Or add comments, or reply\\
	 & to a question.\\ \hline
Inputs   & Keychars, edit keys, end-of-input del. \\ \hline
Notes    & Emacs like functionality as a default.\\
	 & User should be able to specify either \\
	 & vi, Emacs, EZ, if possible.  \\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Browse  \\ \hline
Function & Allows user to browse through public \\
	 & QA pairs.  \\ \hline
Inputs   & Topic Selection and sub-topic selection.\\
	 & Question selection, DisplayQuestion button.\\ \hline
Notes    & Meaty command.  Will require considerable \\
	 & overhead and design considerations.   Possibly, \\
	 & add either a print feature or save feature.  \\
	 & Save would be better because user could later \\
	 & modify it to add LaTeX or Scribe formatting \\
	 & commands before printing.  Possibly, can use \\
	 & browser also for LUCY private browsing.  \\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & List \\ \hline
Function & Lists the questions in the queue and their \\
	 & statuses.\\ \hline
Inputs   & Some way to page through extensive question \\
	 & lists.  Or navigate hierarchical waters.\\ \hline
Notes    & Perhaps also add selection mechanism like \\
	 & UNIX `ls' does -- e.g. ls -t sorts entries \\
	 & by time of last modification. \\ \hline
\end{tabular}  

\ \\



\begin{tabular}{||l|l||} \hline
Name     & Reply \\ \hline
Function & Reply to a user.  \\ \hline
Inputs   & e-mail address input  \\
	 & end-of-input \\ \hline
Notes    & Buttons should include: Help, Save, Cancel \\
	 & which are pretty self-explanatory.\\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Ask \\ \hline
Function & Allows user to enter a question and send \\
	 & it to LUCY.  Also allows some misc. options.\\ \hline
Inputs   & Text of question, end-of-input \\
	 & misc: topic heading, personal reply query, \\
	 & publish boolean \\ \hline
Notes    & Miscellaneous Inputs are a pain to specify.\\
	 & Perhaps have defaults so user doesn't have to \\
	 & go through the rigamarole.  Use fields. \\ \hline
\end{tabular}  


\ \\


\begin{tabular}{||l|l||} \hline
Name     & Publish/Post \\ \hline
Function & Lucy can make a QA pair public \\ \hline
Inputs   & Select QA pair, Select topic or sub-topic \\ \hline
Notes    & Also a do-it button to effect the operation. \\ \hline
\end{tabular}  


\ \\

\begin{tabular}{||l|l||} \hline
Name     & Quit \\ \hline
Function & Performs necessary cleanup before shutting \\ 
	 & LUCY down. \\ \hline
Inputs   & quit button. \\ \hline
Notes    & Confirm quit if some things are in limbo.\\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Help \\ \hline
Function & Provides advice to the user on how to \\
	 & proceed.  Tells the user about the system.\\
	 & Provides useful information that user can \\
	 & quickly access.\\ \hline
Inputs   & Information filtering inputs -- vague.\\ \hline
Notes    & Browser might be a useful basis for the \\
	 & help.  Help should be an independent window \\
	 & so user can refer to it while using LUCY.\\ \hline
\end{tabular}  

\ \\

\begin{tabular}{||l|l||} \hline
Name     & Forward \\ \hline
Function & forward question to an expert.\\ \hline
Inputs   & A way to select the question.\\
	 & e-mail address of expert. \\ \hline
Notes    & Limited interface.  \\ \hline
\end{tabular}  

\ \\

% future expansion
% \begin{tabular}{||l|l||} \hline
% Name     
% Function 
% Inputs   
% Notes    
% \end{tabular}  








\end{document}
