% 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}