CLIPS is being used as an integral module of a rapid prototyping system. The prototyping system consists of a display manager for object browsing, a graph program for displaying line and bar charts, and a communications server for routing messages between modules. A CLIPS simulation of a physical model provides dynamic control of the user's display. Currently, a project is well underway to prototype the Advanced Automation System (AAS) for the Federal Aviation Administration

Kosta, Charles P.

Krolak, Patrick

Miller, Ross

Vesty, Matt

English

NASA Technical Reports Server

j/_ -,_/ N96- 12929
Prototyping User Displays Using CLIPS
Charles P. Kosta
Ross Miller
Center for Productivity Enhancement
University of Lowell
Lowell, MA
Dr. Patrick Krolak
Matt Vesty
Transportation Systems Center
Cambridge, MA
534
https://ntrs.nasa.gov/search.jsp?R=19960002920 2020-06-16T05:31:44+00:00Z
Abstract
CLIPS isbeingusedasan integralmoduleofa RapidPrato-
typingSystem.The ProtolypingSystemconsistsofa display
managerforobjectbrowsing,a graphprogramfordisplaying
lineand barcharts,and a communicationsserverforrouting
messages between modules. A CLIPS simulation of physical
model provides dynamic control of the user's display. Current.
ly, a project i$ well underway to prototype the Advanced
Automation System (ASS) for the Federal aviation administra.
tion.
A prototype, as defined by The American Heritage
Dictionary, is an original type, form, or instance
that serves as a model on which later stages are
based or judged.
LEVELS OF FUNCTIONALITY
The prototyping of user interfaces has evolved into
four distinguishable levels. The first level is the
"'straw man" stage, when a basic screen design is
developed that approximates how the interface should
look. The purpose of this phase is to work out aes-
thetics issues only; it does not give any indication of
the usability of the display. Using C or another script
-like language, the second level prototypes static
responses using limited scenarios. At this phase the
objects can react to user input, but the responses do
not deviate from an internal script. The third level
incorporates a dynamic response from the system.
During this phase the dynamic system attempts to
mimic the real system as closely as possible in such
areas as responding to user events and simulating (or
generating) user scenarios. While using this level
prototyping users should not be able to tell that they
are using a prototype and not the real system. The
highest level of prototyping contains everything in the
previous three levels plus the ability to capture and
report on usage metrics.
The function of prototyping is to demonstrate
whether or not a model serves a useful purpose. At
the first level, we are trying to find out if the screens
are discernible; do they portray right meaning. The
second level asks whether or not the prototype can
respond in an intuitive manner. The third level utilizes
scenarios that in turn simulate events to which the
user must react. The highest level uses metrics to
modify the behavior of the running system. It is
important to note that the first three levels also have
metrics, but they are not integrated into the prototype;
they are external: surveys, video taped sessions, sub-
jective comments of the user community.
USER DISPLAYS
Typically, static mock-up displays are the first proto-
types created for most applications. They help deter-
mine spatial and size constraints for various data mod-
els. Dynamic displays are later generated to allow
users to interact with the prototype.
Today's prototypes not only deal with data
models, but with user models as well. For example,
icons must somehow depict a similar meaning for all
users. Supporting this trend is the rapidly increasing
role that windowing systems are playing in today's
computing environments. Specifically, the method in
which information is distributed into windows and
icons is important for users who are trying to under-
stand the state of an active system.
New techniques are being developed daily that
strive to go beyond the borders of windows of infor-
mation into what have been termed widgets. Widgets
are typically some graphical representation, in the
form of an icon or window, that provide movements
and actuators upon some object. An example of this
type would be a sliding bar widget. In a similar man-
ner to the sliding bars used on stereo equipment, the
user can select the slide bar with the mouse and move
it along the axis to set or adjust some scalar value.
Widget complexity is limited only by the creator's
imagination, and they can be as simple as a small
radio knob dial or as complicated as the entire front
panel of a virtual computer. In general, prototyping
systems are becoming increasingly object oriented
with data items taking on object properties. These
535
properties can be linked to widget functionality on the
display and when an object value changes the corre-
sponding widget can be updated.
This paper will attempt to explain one particu-
lar system that was designed to elicit user require-
ments through the use of prototyping user interactions.
The project is called User Requirements Prototyping
System (URPS). URPS is positioned at the prototyp-
ing interactions (third) level on functionality. This
does not mean that the two lower levels (static and
responsive) arc excluded -- they are also available.
What we have not included as yet is a method to
obtain metrics from the running prototype.
OBJECT RENDERING
Information can be represented (rendered) in different
manners. A temperature can be rendered as a number,
a picture of a mercury thermometer that has more pix-
els filled as the temperature increases, or as a square
block that changes from blue to red. Any one of these
methods may be appropriate in a given situation. Any
object can be rendered in some manner, although the
method is usually based on object functionality as far
as the user interface is concerned.
Pop-up windows are interesting in that they can rep-
resent a user model that goes beyond the "desktop"
into models that are based on a virtual technical assis-
tant working with the user's "desktop." In particular,
current pop-up windows are used for displaying a
message about the system that you must deal with
immediately (like a high priority memo on your desk-
top); displaying a menu that represents either local or
global choices about the window below it; and dis-
playing pop-up windows that act like post-up notes
from the system.
DYNAMICS
Allowing dynamic changes to happen on the display is
useful. Most user design prototypes find it necessary
to know if the user can use and interact with the data
that is presented. Current techniques make use of C
language (object-code linkability), Sl_cially designed
scripting languages, or message passing constructs to
facilitate dynamics. URPS takes a combined approach
in the form of an expert system shell call CLIPS (C
Language Integrated Production System). Event mes-
sages travel between objects via a FACT construct.
Programmability is available at both runtime via
CLIPS rules and link time via C code though CLIPS.
WInDOWInG
It is important to consider the user model as a guide to
object rendering. Current windowing systems allow
the designer to choose different techniques for win-
dow (or object) managerr_nt. The three main types are
tiled, overlapping, and pop-up windows. _led win-
dows are those that split up the screen into smaller
tiles -- no window ever covering up another -- and
is based upon the user's ability m deal strictly with
base spatial concepts. Overlapping windows allow for
the possibility of dam being covered up and are usual-
ly equipped with the ability to resize, move, and place
one window over another. In user models terms, over-
lapping windows represent the "deskiop" paradigm.
CURRENT SYSTEMS
There are many systems currently available for proto-
typing user displays. Two will be discussed briefly.
The first is a low cost solution available
through COSMIC called TAE+ (Transportable Appli-
cations Environment Plus). TAE was developed by
NASA Goddard as a tool for building consistent,
portable user interfaces in an interactive alphanumeric
terminal environment. TAE also supports rapid proto-
typing of user interface screens and interactions, and
allows the direct reuse of those screens in the final
applications. TAE+ now supports X Window and
MOTIF widgets.
536
VAPS (Virtual Application Prototyping Sys-
tem) is a much more elaborate, commercially avail-
able package that runs on silicon graphic worksta-
tions. The user can build prototypes by interactively
laying out the display
and then attaching scripts
to each object. The
scripts are C functions
that are modifiable by
the user. VAPS supports
a wide range of input
devices, and a designer
can first prototype a con-
trol panel using just
graphics and a mouse.
Later, a touch sensitive
screen can be added.
VAPS, a sophisticated
product that can proto-
type very realistic
sci'eens, is a product of
Virtual Prototypes.
DISPLAY MODELS
Rendering Models are
lo T
[
1
Objec_ Views
I
File Viewer
(Help File)
along with the speed of the system, can support inter-
esting pictorial effects. But one can always choose to
tackle the graphic modes (using or buying a package).
The biggest problem here is in choosing what level of
PCLIPS Disp_
Floor !
Log Winclows Floor Plans
Bar Charts
anti Graphs
Figure I. PCLIPS Display Model
basedon thedisplaydevicesavailable.These devices
range from very low capabilitydisplaysand veryhigh
leveldisplays.To examine a few of thesedifferences,
threeexamples willbc discussedhere:theANSI ter-
minal,theIBM PC and theX Windowing System.
Using inverted text and special symbols
whenever possible,the standardANSI terminalcan
provide many rcndenng possibilities,although tiled
windows seem to bc thefavoriteon thesesystems. It
is,however, possibleto write,or use,a package can
provideboth overlappingand pop-up styles.Pictorial-
ly,widgetstendtobc squareand numbers arc usually
depictedwithnumerals.Artisticallyspeakingitispos-
sibletohave iconsthatarcintuitive.
The next stepup from the ANSI terminalthe
IBM PC. The extended ANSI capabilitiesof thePC,
graphics to support. Bit image
graphics on the PC can pro-
vide a good medium for wid-
gets; however, screen manage-
ment is usually still up the
programmer.
Lastly, the X Window-
ing System (and other win-
dowing systems) provide win-
dow management features and
widget management as well.
A detailed explanation of the
X Windowing System can be
found in other places - it is
referenced here to show that
display models can vary great-
ly with device availability.
PROTOTYPInG THE ISSS
The original work in this area
was done to support the rapid
prototyping of the maintenance and control consoles
for the Federal Aviation Administration's 0::AA) new
air traffic control system, the" Advanced Automation
System (AAS). The purpose Of the project is to devel-
op a rapid prototyping system for a man-machine sub-
team to use in identifying user requirements in terms
of the graphical interface. This information could then
become the basis for a requirements document for the
user interface.
The user displays were separated into func-
tional groups where corresponding object structures
and icons were created to represent the various
objects. Functionally, the objects represented hard-
ware and software objects that were in some state of
usability. Widgets were built using the "traffic light"
concept. Green means the object is functioning fine;
537
yellow means there is a degradation of the object; and
red means that the object is dead. Blue is used to rep-
resent available but nonallocated resources.
CLIPS is being used as an event-based system.
CLIPS is well qualified for this role due in part to the 1
features of the production system model. It addition to
events, CLIPS facts are being used to recreate the dis-
play model in the form of a fact base (knowledge
base). These facts hold the object oriented system data
about the actual objects and all the corresponding wid-
get functionality. CLIPS rules function as receptacles
for events that occur both by the simulation system
and user's (display-based) events. See Figure 1.
PCLIPS is a parallel version of CLIPS that
allows multiple CLIPS experts to communicate via a
broadcasting function called remote assert (rassert).
By using this method any number of CLIPS experts
can be initiated. URPS presently has two: one that
serves as a simulation of the prototyped system and
another that maps simulation events to the user's
screen. A display manager controls usage of the user's
screen. Widgets communicate with the display manag-
er in order to gain access to the display space and to
update the dam. =>
EVENT-BflSED FUnCTIOnALITY
)
There are two major types of widgets: an icon class :
made up of bit-image graphics and the other, an icon- ;
which is surrounded by a colored box; both represent ;
the state of the objecL The box type is our GENERIC ;
class. For this demonstration we have only one icon
class; it is called TERMINAL.
{deffacts DisplayPanager "Base 0=jeer Classes lor Display ._aaqer"
; te'_:ate: taa_!con ¢wicqet-class> cwic_t-s:ate> ¢.ico_fi_.era_>l
: tea. late: (msp-_-. state <wia_t-:lass> <wta_t-s_ate> Oox-.coio:.)
{r.ap_a_._icon termina up "iX:i termir.al oX")
{=ap_ckr,icon t.ermiaal down "Ik:J_termina:_err')
(map__.,_icon terminal ue9raded "ik:i_ter_,tnaI_warn')
(_ap a_.,_:,con terminal s;ancLby "ik:i,te:_.._naI_standDy'}
{map_(_ 1con terminal spare "_k:l termlna'._spare')
Im.m_,_4m ,It'.ml'b _D_|P tt_ I"_'L'TII,It
(map c_ stare gener:: down RED)
(_p_c__staze generic spare WHITE)
lmap_Otn_sta=e generic standby BLbE}
Imap__._staze generlc degraoed YELLOW)
NOTE: The generic_display_update and icon_dis-
play_update use facts sent from CLIPS to the Display
Manager to control widgets, ask..for_something
receives events from the Display Manager.
(Ocfruleqener-z.display__:_te "C_,ch a:: Genera= Status Z.'a._._"
(status ?type ?object ?state)
(dm ob3ect ?ob3ec_ ?)
(map_d_,_state generic ?state ?signal)
(rasser dm turncolor ?ob3ect ?s_qnal)
)
(de,ruleicm_:isplay_upCa:e "C.aC:_ oaly ._.%_IINALS:atus Cba_es"
(status -"-" ?objec_ ?state)
(ckn_o_jec_ ?ob)ect icon)
(map_CT__con terml.-.a- ?s_aze ?_name)
(asset; am chg-icor. ?ob]e:z ?fnan_)
(Selec_ . .) facts are remotely asserted by the
Display Manager when the user does something These
are much like user events.
: Currently, the default action is to open up a
; mabv.t_w. If _he object SELECTed does not have a
; lubvie_, %lle_ it dOeS not have a **map_rim windcacs"
; fact eAt.her. Another rule wlth a lower salience
; catches loft User Events in case there is no sub
; Vl_.
(defrule ask :or some=._Ang =,_a_ch User Events"
?r I<- l_elect ?obj)
{(_n winOow ?c_ ?w ?h S?Window Stu._f)
{._ap-d_indow ?ob_ ?x ?y}
{_asRr_ _m oven-w_n_ ?o_i ?x ?v ?w ?h $?Windo_ S_uH
538
DISPLAY MODEL FUNCTIONALITY
Functionally, the display is separated into views.
These views consist of collections of such widgets as
object views, monitor logs, bar charts, and pop-up
menus. Object views are windows controlled via
remote asserts (rasserts) to the Display Manager
Screen control, and pop-up windows are also con-
trolled by Display Manager requests. Log windows,
bar charts, and the floor plan are separately running
programs that join the PCLIPS session upon start-up.
IMPLEMENTATION ISSUES
The Commodore Amiga was chosen as a platform for
the following reasons: Low cost, useful resolution
(640 X 400), choice of bitplanes, dynamically load-
able icons, commercially available image-based tools,
and multiprocessing capabilities. The fn'st challenge
was porting Clips 4.3 over to the Amiga -- no problem
--justa 5 week delay! The next challengewas in
designingthe actualdisplayfunctions.Following this
came the PCLIPS functionality;being able to allow
multiple CLIPS experts tojoin togetherto form a
PCLIPS Environment.This was accomplishedviathe
recodingof a PCLIPS serverwhich runs in theback-
ground.The servermanages incoming requeststojoin
a PCLIPS sessionand distributesremote assertstoall
currentlylistedCLIPS processes.Once wc had tools
working we were then able to attackthe problem of
rapidprototypingtheISSS.
ment of new user interfaces. Widget technology is
important for encapsulation of data and needs further
study. Object Oriented approaches were definitely the
way to go in our prototyping system. These approach-
es were used to determine the level of granularity for
the prototype and also to specify functionality of
object classes -- no one object was coded better or
worse than another in the same class. Image based
view facilitated the involvement of an-types who felt
they had much more feedom with paint programs than
when they were asked to layout displays based on
geometrical (graphical) shapes.
Additionally, an interactive configuration tool
was created to help in the layout of widgets within
views, allowing objects to be positioned over bit-
images (pictures). This is pan of a far more interest-
ing problem: whether to deal with image based objects
or grahpical based (lines, cubes, geometry . . .)
objects. One interesting group discussion led to the
idea of rendering graphical objects on top of bit image
backdrops.
concLusions
After weeks of designs and redesigns, we have found
widgets, object oriented programming and image
based icons to be important concepts in the develop-


Prototyping user displays using CLIPS

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server