The Adaptable User Interface - Technion

COMFUTING PRACTICES 

Edgar H. Sibley 

Panei’ Editor 

A single adaptable user interface (AUl) which allows the user to switch 

between any number of different dialogue modes at any time-even in the 

middle of a command-can be useful to a variety of users who are neither 

beginners nor experts. It can also be used in applications where different 

dialogue modes are appropriate for the various parameters of a single 

command. An implemented user interface management system (cl// WS) 

suggests the practicality of AMs and their automatic generation. 

The Adaptable User Interface 

Eliezer Kantorowitz and Odecl Sudarsky 

THE AU1 CONCEP? 

Software systems interact with users in a large variety 

of ways (dialogue modes). These methods may be classi- 

fied as the menu-type and the command-language-type. 

In a menu-type-dialogue mode (MM), the user controls 

the system solely through the selection of options from 

a number of choices presented. It is assumed that only 

choices that make sense are presented to the user, and 

that it is, therefore, not possible to select options that 

are not permitted. In a command-language-type dialogue 

mode (CLM), the user controls the system by instruc- 

tions given in a certain command language. The user 

must know this language in order to use the system. In 

contr.ast with an MM, where the user is guided by 

menu.s and can only enter legal choices, the user of a 

CLM may enter erroneous instructions. A CLM should, 

therefore, be designed to detect improperly formulated 

instructions and to correctly recover from their effects. 

The advantages of an MM over a CLM are well 

known. Since the users do not have to learn any com- 

mand language, they may become productive with a 

new system after a very short time. A new user may 

explore the operations provided by a system simply by 

browsing through the menus. If such a system also pro- 

vides adequate help for every menu option, the user 

may operate the system without ever needing a man- 

ual. 

Menu systems may, however, be less satisfactory for 

frequent users who have to work through a large num- 

ber of menus to get their work done. Waiting for a 

menu to appear on the screen, finding the right menu 

entry, and making the selection can take time. Profi- 

cient users who do not need guidance tend to prefer 

a concise CLM where a few keystrokes, entered at 

full typing speed, achieve the same effect as a num- 

This research was supported by the Gutwirth Fellowship Fund and by the 

Nicholas M. and Gisela Deutch Fellowship in memory of their martyred par- 

ents and families. 

0 1989 ACM OOOI-0782/89/1100-1352 $1.50 

ber of relatively slow menu selections. Isaki and 

Schneidermann observed in [i’] that “Knowl.edgeable 

users often remark that they would prefer to type com- 

mands and believe that they can work more rapidly by 

just typing commands.” 

Realizing the different needs of beginners and ex- 

perts, many systems provide two distinct user inter- 

faces: a menu interface and a command-language inter- 

face. In these systems, the user has to select in advance 

(in the beginning of the session or before each com- 

mand) one of these two interfaces that is best suited to 

the task. If a user wants to change the dialogue mode, 

the current command must be completed fi:rst, and 

then the user must request that the system switch to 

the desired user interface. There are cases, .however, 

when it is useful to change the dialogue mode in the 

middle of a command. To demonstrate this, we will 

employ an example command for drawing a black box 

with the lower left corner at (0,O) and the upper right 

corner at (1,l): 

BOXBLACK(O,O) (1,l) 

The first case to be discussed is that of a user who is 

neither a beginner nor an expert but is somewhere 

between these two extremes. Such a user may realize 

that he or she has forgotten some command language 

element while in the middle of composing a command 

and may need the assistance of menus [3, 511. .Assume 

that the user has typed the word BOX of the example 

command and is uncertain about what colors are available. 

Shifting to an MM will facilitate color selection 

from a menu. A similar situation occurs when the user 

has made a mistake, e.g., entered a color that does not 

exist. After reading the error message, the user can 

switch to a menu of colors in order to select an available 

color. 

The need to assist users who cannot complete a command 

is realized in current systems, which enable commands 

to be programmed such that users are prompted 

for missing parameters. These systems, however, do not 

1352 Communications of the ACM November 1989 Volume 3.2 Number 11

give the users the freedom to employ at any time the 

dialogue mode that is most productive for their level of 

experience. The users’ freedom in changing dialogue 

modes solves another class of problems which we will 

discuss next. 

One of the criteria for deciding whether to use a CLM 

or an MM is the nature of the input data and the physi- 

cal properties of the I/O devices. In our example, the 

coordinates of the corners are known by their exact 

numerical values ((0,O) and (l,l)), and it is, therefore, 

appropriate to enter them by typing them at the key- 

board (a CLM). If a corner is only known by its position 

on the screen, however, it must be entered by moving 

the cursor with a mouse or another locating device. By 

our definition, this method for entering coordinates is 

an MM, where the points of the screen are the choices 

and the selection is made with the mouse. We observe 

that depending on the nature of the actual input data, 

the same command is sometimes entered in a CLM and, 

in other cases, in an MM. Sometimes it is required to 

employ two different dialogue modes within the same 

command. For instance, one of the corners of the box is 

known by its position on the screen (and must, there- 

fore, be entered by pointing at it) while the other cor- 

ner is known by the numerical values of its coordinates 

(and should be entered through the keyboard). 

It is sometimes useful to have more than one MM or 

more than one CLM. As an example, let us consider a 

system with two different CLMs for the same command 

language: a voice-input mode and a keyboard-input 

mode. Voice input is preferred when the user has to 

operate away from the terminal or is otherwise occu- 

pied. On the other hand, keyboard input may be 

quicker or less error prone in noisy environments. 

We propose an adaptable user interface (AUI), which 

will allow the user to switch dialogue modes in the 

middle of a command. An adaptable user interface is de- 

fined as an interface that: 

l supports a number of different dialogue modes. More 

than two modes may be provided; 

l allows the user to switch between dialogue modes at 

any time, i.e., even in the middle of a command; 

l makes the switch between dialogue modes smoothly 

and naturally; 

l makes it easy for the user to learn how to use the 

different dialogue modes, especially the CLMs, which 

usually require a longer training period. 

In order to enable simple and natural switching be- 

tween dialogue modes, a number of assumptions and 

requirements are proposed. The central assumption is 

that all the dialogue modes of an AU1 are different 

representations of a single underlying dialogue language. 

This common language is assumed to be constructed of 

a number of elementary syntactic components, to be 

called tokens. Every token is required to have a distinct 

representation in each of the dialogue modes. In an 

MM, a token is represented by a single menu selection, 

while the corresponding representation in a CLM is an 

Computing Practices 

atom of the command language. For example, in the 

GUIDE system, to be described later, CLM tokens are 

represented by character strings. Each token may be 

entered in any one of the available dialogue modes, 

independent of the modes employed for the other to- 

kens. Two subsequent tokens may thus be entered in 

two different modes. 

Beginners and casual users will employ the AU1 in an 

MM. As they become more familiar with the system, 

they will gradually learn the CLM instructions that 

they need. A user can exploit the CLM commands al- 

ready learned and employ an MM for all the other 

commands. Users will not have to learn CLM com- 

mands that are rarely used since they may be entered 

in an MM. 

Additionally, each token can be entered in the most 

suitable way. For example, in the BOX command, each 

of the two corners is given by a single token. One cor- 

ner of the box may be entered using a mouse while the 

opposite corner can be entered by typing its coordi- 

nates. The implementation of a user interface is usually 

a major effort. This is especially true for an AUI, in 

which several input devices must be monitored simul- 

taneously. It is, therefore, desirable to have a user in- 

terface management system (UIMS) [lo, 11, 15, 161 that 

automatically generates AUIs. Nonetheless, none of the 

existing UIMSs seem to allow the easy production of 

AUIs. Most systems can only generate single-dialogue- 

mode user interfaces. In systems that offer several 

modes, the end user is usually required to select a sin- 

gle dialogue mode at the beginning of the session. The 

Workspaces system [l] allows only partial adaptability 

(keyboard parameters must be entered first, followed by 

the parameters given by other input devices). The IOT 

[16], Switchboard [14], and Sassafras [6] systems may 

possibly be extended by the user interface designer 

with code that supports several dialogue modes; how- 

ever, writing such code is a difficult task that requires 

insight in parallel programming of I/O devices. 

THE GUIDE SYSTEM 

In order to test the practicality of AUIs and of their 

automatic generation by a UIMS, the GUIDE (Graphic 

User Interface Design Environment) system was imple- 

mented [13]. Further design goals of GUIDE were: 

l specification and modification of a user interface 

should be simple and require no programming skills. 

This will enable the system to be used by human 

factor experts who are not necessarily programmers. 

The ability to easily modify the user interface is im- 

portant since human behavior may not be precisely 

predicted, and some debugging may be required; 

l extending the user interface with new I/O devices 

and associated dialogue modes should be easy and 

require only minimal modification of the system. 

An application program developed with GUIDE has 

three main modules called the lexical, syntactic, and se- 

mantic components. The lexical component identifies 

November 1989 Volume 32 Number 11 Communications of the ACM 1353


the tolkens in the stream of input events. The syntactic 

component analyzes the stream of tokens it receives 

from the lexical component and invokes the semantic 

component when required. The semantic component is 

the collection of application routines written by the 

applic.ation programmers in some ordinary program- 

ming languages. 

The syntactic and lexical components constitute the 

user interface of the application program. GUIDE gener- 

ates this user interface from specifications given 

through interactive graphic design tools. The user inter- 

face specifications do not cause the generation of any 

code; rather, they are stored in a relational database 

and are later interpreted by a run-time environment. The 

code of this run-time environment is identical for all 

GUIDE-developed applications; only the database and 

the semantic component are different. A change in the 

user-interface specifications only requires a modifica- 

tion of the database. The effect of such a change can be 

seen immediately, since no compilation and linkage are 

requirsad. This facilitates rapid prototyping of user in- 

terfaces since the designer can try several alternative 

solutions within a short time. 

The Syntactic Component 

The syntactic component of the user interface employs 

a recursive transition network (RTN) as the definition of 

the dialogue language. An RTN interpreter executes 

this definition when it analyzes the stream of input 

tokens. RTNs were chosen for the syntax representation 

because they are as powerful as deterministic, 

context-free grammars yet easier to use than BNF represent,ation, 

especially for nonprogrammers [2, 4, 81. 

An overview and comparison of current methods for 

specification of the syntax of dialogue languages is 

found in [16]. tines. 

An RTN is constructed from a number of subnets. 

Each subnet is represented by a directed graph. The 

following kinds of states (nodes) and transitions l[edges) 

may appear in a subnet (see Figure 1): 

l initial state--the state in which the execution of sub- 

net begins; 

l return state-causes control to return to the calling 

subnet; 

l subnet call state-causes control to pass to another 

subnet (or, recursively, to the same subnet); 

l application call state-causes an application routine to 

be executed; 

l input state-causes control to wait for the reception of 

a token from the lexical component. A menu may be 

associated with this state; if required, this menu will 

be displayed automatically when this state is 

reached; 

l output state-causes the display of a message to the 

end user; 

l plain transition 

l return transition-appears after an application call 

state and is traversed if the routine has returned the 

return code associated with this transition; 

l option transition-appears after an input state and is 

traversed if the user has selected the menu option 

associated with this transition; 

l parameter transition-appears after an input slate and 

is traversed if the user has picked an object of the 

type associated with this transition. 

It is noted that a subnet may recursively call another 

subnet or itself. This enables the grammar of the dia- 

logue language to be defined in a modular way in much 

the same way as a program is constructed fro:m subrou- 

FIGURE 1. The Graphic Representation of RTN States and Transmissions 

1354 Conmwuications of the ~4CIvi November 1989 Volume 32 ,Yumber 11

Figure 2 shows an example of an RTN subnet called 

PickNode. The execution of this subnet by the RTN 

interpreter starts at the initial state S 1 and then imme- 

diately passes to the input state ~2. A menu called 

NodeMenu is associated with this state. The user has 

now to select one of the two options in this menu. If, for 

instance, the option named Del is selected, the option 

transition T2 will be traversed, and the application call 

state ~3 will be reached. The semantic procedure 

DNode associated with this state will be called by the 

RTN interpreter. Finally, the return state S5 will be 

encountered, and the execution of the subnet will ter- 

minate. 

GUIDE provides an interactive graphic editor called 

SYNEDIT. This editor allows the user interface designer 

to construct the RTN which defines the syntax of the 

dialogue language. A SYNEDIT screen is shown in Fig- 

ure 2. SYNEDIT checks the consistency and complete- 

ness of the RTN to make sure that it can be executed. 

The user interface for SYNEDIT itself was generated by 

GUIDE. 

The Lexical Component 

The lexical component of a GUIDE-generated user in- 

terface manages all the input and output of the pro- 

gram. The output consists of text messages, menus, 

icons, and links. A link is a line that connects two icons. 

Icons and links may be used to represent the different 

objects on which the application operates. They can, for 

instance, be employed to show the nodes and edges of 

the graphs that appear in some applications. 

GUIDE’s lexical component is called by the RTN in- 

terpreter (the syntactic component) when it encounters 

an input or output state. The lexical component cur- 

rently supports two dialogue modes. Every menu, icon, 

or link can, therefore, be selected in one of two ways: 

by pointing with a mouse (an MM) or by typing the 

option’s or object’s name (a CLM). Text typed at the 

keyboard appears in a special CLM text area at the 

bottom of the screen (see Figure 3 and the examples in 

Figures 2 and 7). If the user employs the mouse, the 

name of the selected menu option or object will be 

copied by GUIDE into the CLM area as if the user has 

typed them in. The CLM area will, therefore, in all 

klclfltl SUSNET PICKNODE IlILI+I-u~ 

53 

DNode 

4ddTrans 52 54 option 

4ddState Exit 

4ddTrans 53 S5 Plain 

MdTrans 

I 

S4 S5 Plain 

I 

FIGURE 2. An RTN Subnet being Edited by SNYEDIT 

k-l+lfltl Scroll bar I1 l~l-+l+l 

Graphic window area 

Text area 

FIGURE 3. Screen Layout for a Guide-Developed Application 


cases show the command language representation of 

the command being entered. This helps the user to 

learn the command language. Note again that each of 

the tokens in the command may be entered in a differ- 

ent dialogue mode. Furthermore, note that the user 

does not have to tell the system to switch between 

dialogue modes-but simply uses whichever device 

(mouse or keyboard) wanted. 

The different dialogue modes are managed solely by 

the lexical component. When the RTN interpreter re- 

ceives a token from the lexical component, it has no 

knowledge of the mode in which this token was en- 

tered. This makes the system relatively easy to adapt to 

future dialogue modes and input devices (e.g., a speech 

recognizer) since only the lexical component will have 

to be changed, while the syntactic and semantic com- 

ponents will remain unchanged. 

GUIDE includes a program called LEXEDIT that al- 

lows the user interface designer to define icons, links, 

menus, and messages. In the icon editor screen (see 

Figure 4) the icon is drawn using graphic primitives 

and text fields. The icon is shown twice: life-sized in 

the corner of the screen and enlarged in the main win- 

dow. In the link editor screen (see Figure 3, the de- 

signer can specify the attributes of the link: line style, 

arrowheads, and link shape. Text fields can be placed 

along the link. In the menu editor screen (see Figure 6), 

the menu’s graphic appearance is drawn. The name 

and the rectangular region occupied by each option in 

the menu can be defined. The designer has a choice of 

three menu styles: static, pop-up, and pull-down. This 

choice of facilities allows the implementation of many 

of the currently popular user interface styles. 

EXAMPLES OF GUIDE-DEVELOPED APPLICATIONS 

In order to test the applicability of GUIDE in various 

areas, user interfaces for three different applications 

were constructed. The applications are: 

l a directed graph editor, 

l a specification program for management information 

systems (MISS), and 

l the RTN editor of the GUIDE system. 

The directed graph editor is a small program. It was 



AddSam 

EM 

B 

FIGURE 4. LEXEDIT’s Icon Editor Screen 

FIGURE 5. LEXEDIT’s Link Editor Screen 

I 

&ENU EOfTOR: OPTIONS uenu: uyuenu 

f ,>Exit 

:,

item 

budget item 

S”PP 

supplier 

struct the subnets which constitute the RTN and to 

check the correctness of the RTN. Since SYNEDIT 

could not be used to enter the specifications of its own 

RTN, these data had to be entered manually into the 

specification database. The rest of the specifications for 

SYNEDIT were input with LEXEDIT. 

IMPLEMENTATION 

GUIDE was implemented on an IBM PC AT-compatible 

computer. Most of the software was written in the 

dBASE III PLUS database programming language and 

compiled with the Clipper compiler. The use of a rela- 

tional database to store user interface specifications al- 

lowed rapid and simple development of GUIDE. Since 

the dBASE language cannot be fully compiled, how- 

ever, the system is somewhat slow. A reimplementation 

of GUIDE in a compilable programming language is ex- 

pected to result in satisfactory performance. 

CONCLUSIONS 

It has been argued that it is sometimes useful to employ 

a number of different dialogue modes (such as typing 

text at the keyboard and pointing with a mouse) within 

the same command. This cannot be achieved in the 

current systems that provide different dialogue modes 

by applying an essentially separate user interface for 

each dialogue mode. In order to meet these needs, this 

article introduces the adaptable user interface (AUI) con- 

cept which integrates a number of dialogue modes into 

a single user interface. 

The freedom of the AU1 user to adapt dialogue modes 

to actual needs is useful at all levels of experience. A 

novice user starts by using menu modes (MMs) where 

guided by choices presented by the system and gradu- 

ally learns how to utilize the command language. An 

experienced user employs the faster command lan- 

guage modes (CLMs) but can switch to menus in the 

FIGURE 8. An ERD being Edited in the MIS Specification Program 

middle of a command if uncertain about how to finish 

it. An AU1 also enables the user to choose the dialogue 

mode that is most suitable for the nature of input data 

and the working environment. 

The implementation of the GUIDE system suggests 

that both AUIs and a UIMS which generates AUIs are 

practical on personal computers. It also shows that all 

dependencies on I/O devices and dialogue modes can 

be isolated in the lexical component of the user inter- 

face. This facilitates future additions of any number of 

new dialogue modes to the user interface of an already 

existing application. 

User interfaces for three different applications were 

implemented relatively quickly and conveniently using 

GUIDE. In these applications, switching between differ- 

ent dialogue modes appears natural and gives the user a 

new degree of freedom in exploiting the system. 

Acknowledgments. We thank David Reider for his 

kind help in system analysis and in the development of 

one of the examples. 

REFERENCES 

1. Enderle, C. The flexible configuration of interaction environments 

using GKS and Workspaces. In Proceedings of the Seeheim Workshop 

on UIMS. Springer-Verlag, New York. 1965. 

2. Green. M. Report on dialogue specification tools. In Proceedings of the 

Seeheim Workshop on UIMS. Springer-Verlag, New York. 1965. 

3. Grimes, J, D. A knowledge oriented view of user interfaces. In Pro- 

ceedings of the 12th Hawaii international Conference on System Sciences, 

Vol. I (Honolulu, Hawaii, Jan. 4-5.) ACM, New York, 1979, pp. 

158-163. 

4. Guest, S. P. The use of software tools for dialogue design. Inf. I. 

Man-Machine Studies 16, (Apr. 1962), 263-285. 

5. Heffler, M. J. A human-computer interface that provides access to a 

diverse user community. In Proceedings of the 14th Hawaii Intema- 

tionaf Conference on System Sciences (Honolulu, Hawaii, Jan. 8-9). 

ACM/IEEE, New York, 1981, pp. 601-610. 

6. Hill, R. D. Supporting concurrency, communication, and synchroni- 

zation in human-computer interaction-The Sassafras UlMS. ACM 

Trans. Graph. 5, 3 (July 1966), 179-210. 



7. Iseki, O., and Shneiderman. B. Applying direct manipulation con- [Information Systems]: User/Machine Systems-human fzclors; 

cepts: Direct Manipulation Disk Operating System (DMDOS). Sojtw. 1.3.6 [Computer Graphics]: Methodology and Techniques-interaction 

Eng. Notes 11, 2 (Apr. 1986), Z-26. techniques, languages 

8. Jac:ob, R. J. K. Using formal specifications in the design of a human- 

computer interface. Cownun. ACM 26, 4 (Apr. 19831, 259-264. 

9. Myers, B. A. User-interface tools: Introduction and survey. IEEE 

Sopw. (Jan. 1989), 15-23. 

lo. Ol:?eo, D. R., Jr., et al. ACM SIGGRAPH workshop OII software tools 

for user interface management. Comput. Graphics 21, 2 (Apr. 1987), 

71-174. 

31. Pfaff, G. E., Ed. User interface management. In Proceedings of the 

Ser,heim Workshop on UZMS. Springer-Verlag, New York, 1985. 

12. Reider, D., Kantorowitz, E., and Raz, Y. Specification of management 

information systems combining data modeling and structured analysis. 

In Proceedings of the 4th Israel Conference on Computer Systems and 

Sojtware Engineering (Tel Aviv, 

19B9, pp. 34-44. 

Israel, June 5-6.) IEEE-W New York. 

13. Sudarsky, 0. A user interface management system adaptable to various 

user experience levels. Thesis, Dept. of Computer Science, 

Technion-Israel Institute of Technology, Haifa, Israel, 1988. 

14. Tanner, P. P., et al. A multitasking switchboard approach to user 

interface management. In Proceedings of SZGGRAPH ‘86: 13th Annunf 

Conference on Computer Graphics and Interactive Techniques (Dallas, 

Tex., Aug. 18-22.) ACM/SIGGRAPH, New York. 1986, pp. 241-248. 

15. Thomas, J. J., and Hamlin, G. Graphical Input Interaction Technique 

(GIIT) workshop summary. Comput. Graphics 17, I (Jan. 1983), 5-30. 

16. van den Bos, J., Plasmeijer, M. J., and Hartel, P. H. Input-Output 

tools: A language facility for interactive and real-time systems. lEEE 

Trmts. Softw. Eng. SE-g, 3 (May 1983), 247-259. 

CR ‘Categories and Subject Descriptors: D.2.2 [Software Engineer- 

ing]: Tools and Techniques---user interfaces; D.2.6 [Software Engineer- 

ing]: Programming Environments-interactive; D.2.m [Software Engi- 

neering]: Miscellaneous-rrrpid prototyping; D.3.4 [Programming 

Languages]: Processors-interpreters, run-time environments; H.1.2 

General Terms: Human Factors, Languages 

Additional Key Words and Phrases: Dialogue languages, recursive 

transition networks. user interface management systems, user interfaces 

ABOUT THE AUTHORS: 

E. KANTOROWITZ is currently a professor at the Computer 

Science Department at Technion-Israel Institute of ‘Technology 

and an ACM member. His research interests are in adaptable 

user interfaces, fault tolerant distributed database systems, and 

he is involved in the design of an industrial database-oriented 

ship design system. Author’s Present Address: Computer Sci- 

ence Department, Technion-Israel Institute of Technology, 

Haifa 32000, Israel. KANTOR@TECHSEL.BITNET 

0. SUDARSKY recently completed his Master of !kience stud- 

ies and is an ACM member. His research interests are adapt- 

able user interface management systems. Author’s Present 

Address: 11 Mishmar HaYarden St., 18412 Afula, .lsrael. 

Permission to copy without fee all or part of this material is granted 

provided that the copies are not made or distributed for &ect commer- 

cial advantage, the ACM copyright notice and the title of the publication 

and its date appear, and notice is given that copying is by permission of 

the Association for Computing Machinery. To copy otherwise, or to 

republish, requires a fee and/or specific permission. 

Provides in-depth examination of the topics covered... 

acm Computing 

Surveys 

Editor-in-Chief Salvatore T. March 

LIniversity of Minnesota, Minneapolis, MN 

A 

uthoritative surveys and tutorials make 

ACM Computing Surtieys a required resource 

in computer science. Refer to 

Computing Surveys for updates, new 

perspectives on hardware and software, computer 

systems organization, computer science theory, 

artificial intelligence, applications, and a spectrum of 

peripheral topics. 

In the past, Computing Surveys has treated encryption 

and data security, the legal issues involved in 

privacy, fault-tolerant software, data management 

and organization, information systems, and manmachine 

interface software packages. 

What’s best is that the prose is lively and accessible 

while providing an in-depth examination of the topics 

covered. Published quarterly. ISSN: 0360-0300 

Included in STN’s Compuscience, AMS’s Mathsci.. Applied 

Science 6 Technology Index, Mathematical Reviews, Science 

Abstracts, Science Abstracts Index, British Maritiml? Technology 

Ltd.,Computer Literature Index (formerly Qtr. Bib/i. Camp. & Data 

Proc.), Computing Reviews, Compumath Citation Index (CMCI), 

Ergonomics Abstracts, Information Services for the f’h!ysics 6 

Engineering Communities, Index to Scientific Reviezus. 

Order No. 105000 - Vol. 22 (1990) 

Subscriptions: $85,00/year - Mbrs. $13.00 

Student Members: $8.00 

Single Issues: $20.00 - Mbrs. $10.00 

Back Volumes: $80.00 - Mbrs. $40.00 

Student Mbrs. $25/year 

PR 

63 

Circle #103 on Reader Service Card 

-- 

Please send all orders and inquiries to: 

P.O. Box 12115 

Church Street Station 

New York, N.Y. 10249 

1358 Communications of the ACM November 1989 Volume 32 Number 11 

-

The Adaptable User Interface - Technion

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?