User Interfaces for Design Systems

~ ~ The following section covers some of the work in Human-Computer Interaction and User Interface development that was the basis for this thesis. The first book to mention is [Shneiderman 1992]. This reference provides a comprehensive view of the issues that should be considered in designing a computer's user interface to be user friendly. It includes concerns about information overload and positioning of data. Shneiderman also expresses a need to simplify input methods, using a menu or mouse where possible. This book acts as a basis of knowledge about user interfaces that was used in making later decisions.
[Lemke & Fischer 1990], [Fischer et al 1989], and [Fischer et al 1990] all describe similar work on developing programs to critique designs. In [Lemke & Fischer 1990], the design being critiqued is that of a User Interface. This is interesting because of the program's encoded knowledge, but also because of the design of human-computer interaction for their system. Lemke &Fischer list some of the features they require of a distributed problem solving tool, used for designing this software. Among these are some ideas which help make the system more user friendly:

1. A Checklist keeps the user's attention focused.
2. A Palette of components limits the number of choices the user has to make, and makes interaction simpler.
3. Critics analyze the design as it progresses. These must provide useful, constructive criticisms, and not be too intrusive.
4. Specification Sheets guide the user and help to focus the critics so that criticisms can be understood by the user in terms of these specifications.
5. A Catalog of things for reuse or a potential case-based solver to simplify the solution.
6. A Code Generator to make the design usable.

Fischer et al [1989] discusses two systems, CRACK and VIEWPOINTS. CRACK has critics which analyze the design of a kitchen layout. These critics explain why certain decisions may be bad, and why others are good decisions. The text for the critics is all pre-written. VIEWPOINTS is a hypertext system which gives arguments and alternative viewpoints, and is attached to graphics views. However, VIEWPOINTS is not yet automated to find relevant information based on which critic is activated. The goal of Fischer et al is to tie the two systems together by using VIEWPOINTS as the explanation facility for CRACK.

In [Fischer et al 1990], several uses of critic systems are discussed, including supporting learning by offering criticism of solutions and/or methods of problem-solving; providing design environments which communicate with users in their domain language; and developing cooperative problem-solving systems which combine the talents of humans and computers to come up with the best solutions.

Fischer et al then discuss work on the JANUS system, a combination of the above two: CRACK and VIEWPOINTS. They list several steps in the critiquing process:

1. Goal Acquisition - the critic has to understand the goal of the problem. This understanding may be different from user's understanding.
2. Product Analysis - the system either develops its own solution and compares it to the user's, or it analyzes the user's solution against certain criteria.
3. Critiquing Strategies - the system designer has to decide how often to critique, how strongly, etc. These decisions can affect the user's reactions to the system.
4. Adaptation Capability - the user should be able to turn off certain critics, or the critics should adapt to the user's needs.
5. Explanation Capability - the system's ability to explain why one decision is wrong and another is correct using hypertext.
6. Advisory Capability - the system should be able to offer potential solutions, instead of just criticisms of the user's solution. This makes the system less frustrating to use, and can help the user greatly.

1. data management tools, which include visualization tools, editors, query tools, and documentation tools;
2. blackboard (BB) interface tools, which include translators from the BB to the local database, tools for displaying BB status, tools for displaying alert messages, and BB coordination tools;
3. communication tools, which include electronic mail and electronic conferencing;
4. application specific tools, which is a ``catch-all'' for anything else that might be thrown in for a particular application.

1. misconceptions accidents cognitive biases motivational biases;
2. missing concepts insufficient training knowledge decay promotion interdisciplinary breadth of the engineering domain

Silverman &Mezher discuss the use of critics in a Design Support Environment, which they define as a three-layered model of the design task and tools used: the knowledge based collaboration and synthesis layer, the visualization and analysis layer, and the information layer. The design process passes down these layers to generate the design, then passes back up through them to test the design. By generating an example critic, they were able to get some feedback as to how a critic could be properly used in a CAD system. The comments they received were that the critic should supply more before-task tutoring; the system should use graphics coloring to guide the users choices; praise information should be omitted; and there should be some prototype analogy module offered. Silverman &Mezher developed three distinct strategies for critiquing. Critics should follow one of these strategies:

1. Influencers try to avoid common errors and work before specific subtasks
2. Debiasers try to avoid biased information and provide the correct information
3. Directors guide the user toward good design choices.

They developed two principles based on their research. Principle 1 is ``The critic builder should draw from a library of active Influencer, Debiaser, and Director strategies.'' Principle 2 is ``To promote effective criticism, there must be a mutual, two-way exchange of ideas. The critic must be flexible and adaptive.'' These ideas were useful in developing agents which would interact with the user in the SNEAKERS system.
Another system, AskJef [Barber et al 1992] helps software engineers design interfaces by providing design examples, guidelines, errors, and stories. Much of the system is graphical, with examples showing what to avoid or to try. It uses text, graphics, animation, and voice to present the user with relevant information when presented with a specification of an interface design problem.