\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.