On the Problem of Selecting Interaction Objects - CiteSeerX

in Proceedings of HCI'94 "People and Computers IX" The University of Glasgow, 23-26 August 1994), G. Cockton, S.W. Draper, G.R.S. Weir (Eds.), Cambridge University Press, 1994, pp. 163-178.

On the Problem of Selecting Interaction Objects François Bodart, Jean Vanderdonckt Institut d'Informatique, Facultés Universitaires Notre-Dame de la Paix, Rue Grandgagnage, 21, B-5000 Namur, Belgium. Tel : +32 (0)81-72.50.06/72.49.75 Fax : +32 (0)81-72.49.67 Telex : 59.222 FacNamB Email : {fbodart,jvanderdonckt}@info.fundp.ac.be This paper examines, gathers, and reviews global knowledge about selection rules for choosing interaction objects. This analysis allows to define: (i) the premisses of selection rules in terms of attributes from an object-oriented data model, (ii) the conclusions in terms of abstract interaction objects from an object-oriented model, and (iii) a generalized definition of selection rules. It finally endeavours to provide a more complete set of selection rules for elementary, composite, and specific data. Keywords: Interaction tools and techniques, Interaction Objects, Design Process, Model-Based Interface Tools, Selection, Object-Oriented Programming, User Interface Management Systems.

1. Introduction The problem of selecting interaction objects occurs when all the application data already defined by a designer should find a counterpart in the future user interface. The problem consists of selecting appropriate interaction objects (e.g. edit box, slider, dial, list box) according to a specification of application data, a user analysis, and a characterization of the physical environment . The purposes of this paper are: 1. to examine and condense already acquired results in the field of selection rules and tools for automating this activity (section 2); 2. to propose a generalized definition of a selection rule (section 3):
the premisses are expressed according to an object-oriented data model (subsection 3.1). This model includes attributes coming from application data, a user profile, and physical characteristics;
the conclusion is expressed according to an object-oriented model of abstract interaction objects (sub-section 3.2);
the generalized definition of a selection rule is therefore a logical combination of these premisses and conclusion (sub-section 3.3).

3. to provide a complete and detailed series of selection rules summarized in decision tables (section 4). This corpus of decision tables can be incorporated in a graphical user interface styleguide, can be used for teaching and referencing purposes, and can be a foundation for automatic tools. The conclusion highlights some limits of this work which should gain more common practice, improved formalisation, continuous extension, and user validation (section 5).

1. Related Work MacIDA (Petoud, 1993) generates windows according to an entity-relationship model. Its selection rules are fairly obvious: a window is selected for each entity, a simple edit box is selected for each attribute of an entity, a table is selected for each repetitive aggregate of attributes and a pushbutton is selected for each function. These selection rules are independent of the semantic data since they do not vary. There are also non explicit since they are code embedded, and therefore unmodifiable and invisible. Selectors (Johnson, 1992) seems to be a good example where selection rules are explicitly given in terms of application semantics. It correctly argued that "semantic considerations play a role in the categorization and choice of widgets (interaction objects): designers work at a higher level than arranging buttons, text fields, and relations between them." (Johnson, 1992). DON (Kim, 1990) introduced such selection rules after listing important factors for defining conditions:






the data constructor type (e.g. enumerated, subrange); a spatial relationship (i.e. horizontal, vertical, or circular); selectability informations (i.e. mutually exclusive, mutually compatible); editability information (i.e. writable or read-only); precision (i.e. high or low).

DON's selection rules are consequently semantic dependent and explicit, but still (apparently) unmodifiable and invisible to the eyes of the designer. IBIS (Seligmann, 1991) is an Intent Based Illustration System in the area of electronic engineering. It automatically generates front panels of electronic devices by using design rules mapping intent to stylistic choice and style rules mapping stylistic choices to visual effects. IBIS belongs to the same class. GENIUS (Janssen, 1993, Weisbecker, 1993) employs nine selection rules detailed in table 1 for generating a user interface for database-oriented interactive applications. UIDE (de Baar, 1992) goes a step further by expressing selection by production rules contained in decision tables. These tables are stored in a file which is editable by the designer. Selection rules become therefore modifiable. TRIDENT (Bodart, 1993, Vanderdonckt, 1993) graphically represents selection rules in a selection tree. With visible selection rules, designers are allowed to graphically see how the rules are processed, see why a particular interaction object has been chosen, and act if necessary. Selection rules can then be categorized along four dimensions: semantic dependence, explicitness, modifiability, and visibility. DON, UIDE, GENIUS, and TRIDENT illustrate that the current trend in automated user interface generation is more oriented to a knowledge-based approach to selection rules. In this approach, specific models are created of: the application domain, sometimes

the application itself, the interaction objects belonging to the user interface components, and the user model. For our purposes, two models will be introduced: a data model and an abstract interaction object model. Then selecting interaction objects becomes a matter of writing mapping rules between application components and interaction objects components (Gray, 1992). These inspiration sources will now serve in defining widely applicable selection rules. Data type

Type

alphanumeric discrete or numeric

Range of Selection values type unlimited ]1,6]

Introduction Interaction object read write

simple multiple

>6 numeric

continuous ]1,60] > 60

simple multiple simple read write

edit box label list box with simple selection list box with multiple selection list box list box scale edit box label

Table 1. Decision table of selection rules in GENIUS An other source for identifying attributes for selection rules that could help is the knowledge about selection guidelines which can be found in many standards and styleguides. For instance, section 9.1 of Bellcore's styleguide (Root, 1993) is entitled "Matching Controls to user Tasks". It deals with controls for commands and operations, for "n of Many" choices, and for "1 of Many" choices. Mayhew (Mayhew, 1993) also recommends selection guidelines reported in table 2. Interaction object option buttons check boxes list boxes

Circumstances in dialog boxes,
4 choices, choose one, attributes in dialog boxes,
4 choices, choose many, attributes in dialog boxes, >4 choices or dynamically changing choices attributes/objects drop down list boxes in dialog boxes, in forms, when field has a reasonable number of fixed choices, attributes command buttons in dialog boxes, dialog control actions toolboxes in application windows, data attributes Table 2. Selection guidelines from Mayhew

3. A Generalized Definition of Selection Rules 3.1. A Data Model The data model consists of an object-oriented model (fig. 1) where application data can be divided into seven data types (i.e. hour, calendar, boolean, graphical, integer, real, and alphanumeric). These data types are considered to be the most frequent cases in businessoriented applications (Bodart, 1993) (e.g. office automation, administration, database applications). These data types are considered to be uncomplete when working with other dedicated applications (e.g. graphical editors, engineering laboratories). General Data DataLength DataName DescriptionLabel Domain IdentificationLabel Interaction Mandatory NumberPossibleValues NumberPrincipalValues NumberSecondaryValues NumberValuesChoose Selected_AIO DisplaySelected_AIO

AlphanumericData

GraphicalData

ExpandableDomain

BooleanData

CalendarData

RealData

Orientation

Preference ScreenDensity UserLevel

Precision

HourData

IntegerData

Preference ScreenDensity UserLevel

ContinuousDomain Orientation

Fig. 1. The object-oriented data model Each general data is composed of several attributes:





a data name: this is an identifyer (e.g. PersonSize); the data length: the number of characters, if relevant (e.g. 2); an identification label: this unique label identify the data to input/output and its nature (e.g. Size of the person :); a description label: this label specifies some constraints to be verified by the data in order to be valid, such as a unit measure, a valid domain or interval;

















the type of domain (as the limits in UIDE): whether the domain of the data is unknown, known, or mixed, that is a known domain with some unknown values the user can supply; the interaction (as introduction in GENIUS and content in UIDE): whether the data should be input, displayed or used in both dialog ways; the mandatory status: whether the data is required or not; the number of possible values (Npo for short) (as the range of values in GENIUS) : this number can be 1,2, or N if infinite (Vanderdonckt, 1993); the number of principal values (Npv for short): the number of values which are the most frequently used (Vanderdonckt, 1993); the number of secondary values (Nsv for short): the number of values which are the less frequently used such that the sum of principal values and secondary values is equal to the number of possible values (Npo=Npv+Nsv); the number of values to choose (as in (Mayhew, 1992), GENIUS and UIDE): this can be 1,2, or N if infinite. If this number is equal to 1, the data follows a simple choice method: after having chosen a data, the user can only select one value at a time to operate on that data. If the number is greater than 1, the data follows a multiple choice method: the user may wish to select two or more than two values simultaneously; the selected interaction object: a pointer to a suggested entry in the abstract interaction model (see below).

Different data types inherit the mentioned attributes either by specialization (for example, the AlphanumericData object add the ExpandableDomain slot) or redefinition (for example, the domain is known for the GraphicalData objects, Npo=Npv=2, Nsv=0, Nvc=1 for the BooleanData object). Specialization attributes include:








the domain expandability (Exp for short): whether the user can add own values; the precision (as in UIDE): whether the number of digits, decimals is important; the continuity of the domain (Cont for short): whether all values are spread in a continuous range of values (e.g. x >7, [1..10]); the data orientation (as in DON): whether the data are more conveniently represented horizontally, vertically, circularly or in an undefined way; the screen density: whether the amount of data by presentation unit is high, low; the user level: whether the user experience level is beginner, novice, intermediate, expert or master; the selection preference: whether the user has a preference (or physical skill) for typing in data rather than selecting it.

The three last attributes normally do not belong to the specification of application data, but they are provided apart. They are still inserted for hour and calendar data types because the semantic of these cases is better known than the other. Some attributes (e.g. the identification label, the mandatory characteristic) will not serve for selection. They are introduced here for specifying the data model and for final generation of user interface. 3.2. An Abstract Interaction Object Model

An Abstract Interaction Object (AIO) Model (Vanderdonckt, 1993) rather than a Concrete Interaction (CIO) Model is introduced to address three problems: 1. several presentations (or CIO) can be found for one particular AIO : for instance, a same check box can have a lot of different presentations (fig. 2); 2. different AIO can be used for input/display a same class of application data; 3. the AIO classification should be free of presentation considerations: behaviour considerations should be abstract across different platforms (Johnson, 1992).

Fig. 2. Different CIO for one AIO Defining an AIO consists of abstracting behaviours of CIO in order to be independent of a particular physical toolkit or library of interaction objects. Six sets of AIO have been identified: action objects, scrolling objects, static objects, control objects, dialog objects, and feedback objects (Vanderdonckt, 1993). These sets have been arranged in a hierarchical object-oriented model where each AIO is identified by a name, general and specific attributes (e.g. AT_AIO_Length), abstract events and primitives. This definition allows us to select interaction objects across a wide variety of computing platforms because the behaviour is considered in the abstract, rather than the different presentations. 3.3 A Generalized Definition of a Selection Rule The ordering of attributes in each selection rule has importance when writing decision tables. Attributes are sorted from the most general to the more particular in order to minimize rows in decision tables and to allow an iterative refinement of the ergonomic quality of AIO. The more right the attribute is placed, the more fine it is. A selection then has the general following form : IF Attribute1=Value1 AND Attribute2=Value2 AND  AND Attributen=Valuen Then AIO is [AIO_name]
i
1, . . . , nAttributei  Valuei  AIO  AIO _ Name where Attributei is any attribute of the data model, AIO_name is the name of any AIO in the AIO model.

4. A Corpus of Decision Tables A corpus of decision tables has been developed according to a hierarchy of types of selection rules (fig. 3). Selection rules fall into two categories: rules for input data and rules for displaying data. Same types of selection rules are found in both categories: rules for

input/displaying elementary data (7 supported data types), rules for taking into account the physical environment, rules for input/displaying specific kinds of data, group of data, and list of data (elementary and composite). Selection rules for window and dialog box are included in the "display" division. input

elementary data env iro nment co nsideratio n specific data g ro up o f data elementary data in a list list o f data

ho ur calendar bo o lean g raphical integ er real alphanumeric

display

elementary data specific data g ro up o f data list o f data env iro nment co nsideratio n co mpo site data

ho ur calendar bo o lean g raphical integ er real alphanumeric

selectio n o f w indo w selectio n o f dialo g bo x

Fig. 3. Hierarchy of selection rules Discussing all decision tables of selection rules would be impossible. We therefore refer to the technical report where all tables are explained (Vanderdonckt, 1993). We would rather focus on some decision tables and examples in order to illustrate the main ideas which prevailed the establishment of the tables. These ideas are expressed in the form of underlying principles for selection rules. In order to introduce, to define and to illustrate these principles, we propose to show decision tables for input an integer data (elementary).

4.1 Example of decision tables The label of each column represents an attribute taken away from the data model except for the last one which represents the selected AIO, taken from the AIO model. Nsv >0 =0

Exp Cont yes no

no

yes

Npo

Precision

[2,3] [4,7] [8,Tm] [Tm+1,2Tm] > 2Tm [1,10] low

high

Orientation AIO list box combination box radio-button with Npo items radio-button with Npo items + group box list box scrolling list box scrolling drop-down list box vertical scroll bar horizontal scale circular pie diagram undefined scale vertical vertical thermometer

horizontal circular undefined [11,Tm] > Tm

high low high low

vertical horizontal circular undefined

horizontal thermometer dial horizontal thermometer spin button scale spin button scroll bar scale dial scale

Table 3. Selection rules for input an integer if domain is known and the choice is simple Table 3 depicts selection rules for choosing AIO if the domain is known and the choice is simple (i.e. Nvc=1). The first row can be read as: if the number of secondary values is strictly positive (Nsv>0), then the selected AIO is a list box (fig. 4a). The second row can be read as: if there are no secondary values (Nsv=0) and if the domain is expandable (Exp=yes), then the selected AIO is a combination box (fig. 4b,c). The third row means: if there are no secondary values (Nsv=0) and if the domain is unexpandable (Exp=no) and if the domain is not continuous (Cont=no) and if the number of possible values is between 2 and 3, then the selected AIO is a radio button with 2 or 3 items (fig. 4d). These rules can be stated roughly in the same way, therefore respecting the generalized definition mentioned above. Table 4 exhibits selection rules for input an integer if the domain is known and the choice is multiple (i.e. the user can input several values: Nvc>1). Tables 5 and 6 show selection rules if the domain of the data is unknown and mixed, respectively. Nsv =0

=0 >0

Exp Npo no [2,3] [4,7] [8,Tm] [Tm+1,2Tm] > 2Tm yes

AIO check boxes check boxes+group box list box Scrolling list box Scrolling drop-down list box Combination box List box

Table 4. Selection rules for input an integer if domain is known and the choice is multiple Domain unknown

AIO Profiled edit box

Table 5. Selection rule for input an integer if domain is unknown Npo [2,3] [4,7]

AIO radio button with Npo items + edit box radio button with Npo items + edit box + group box

[8,Tm] drop-down list box [Tm+1,2Tm] scrolling list box > 2Tm scrolling drop-down list box Table 6. Selection rule for input an integer if domain is mixed

Fig. 4 (a,b,c,d) Some examples of selection rules applications

4.2. Underlying principles 4.2.1. Principle of Appropriate Item Division The goal of this principle is to reduce information division by using appropriate AIO. Some particular AIO are more appropriate for a small, a middle or a large pool of items. For example, a radio button is more suited for a small number of mutually exclusive items. A simple list box is more convenient for an intermediate number of items. A scrolling list box (i.e. a list box with fast scrolling performed by double arrow buttons) is more appropriate for a large amount of items. A radio button is not suited for this situation because it leads to a large interaction object. To solve this problem, DON suggests a list box if the number of items is greater than a cutoff-constant=8 (Kim, 1993). GENIUS (Weisbecker, 1993) and Mayhew (Mayhew, 1993) prefer to limit it to ">6" (table 1) and to ">4" (table 2), respectively. We propose to select a radio button if the number of possible values (Npo) is bounded by 2 and 3 (table 3, row 3). A group box is then added if Npo is between 4 and 7 in order to clearly build a visual group (table 3, row 4). If the domain is expandable, an edit box is placed beneath the known values (fig. 5) (table 6, row 2). Beyond the limit of 8 items and more, a list box is recommended. The use of list box is also limited by Tullis' constant Tm=50 so that if the Npo exceeds this constant, a scrolling list will be preferred instead.

Fig. 5. A group box surrounding a radio button and an edit box

4.2.2. Principle of Adapted Precision and Orientation

The goal of this principle is to adapt AIO to the relative precision or orientation of data with which the user want to input/display it. For example, row 10 in table 3 states: if there are no secondary values (Nvs=0) and if the domain is not expandable (Exp=no) and the domain is continuous (Cont=yes) and the number of possible values is between 1 and 10 (Npo [1,10]) and if the precision is low (Precision=low) and if the orientation is circular (Orientation=circular), then the selected AIO is a pie diagram (fig. 6a).

Fig. 6. (a) pie diagram; (b) horizontal thermometer; (c) vertical thermometer; (d) scale If the orientation is left undefined by the designer, a scale would be selected (fig. 6d) (table 3, row 11). If the semantic of the data specifies high precision and a familiar horizontal representation (e.g. a duration, a period of time), a horizontal thermometer would be selected (fig. 6b) (table 3, row 12). If the familiar representation is vertical (e.g. a temperature, a potentiometer), a vertical thermometer would be selected (fig. 6c) (table 3, row 13).

4.2.3. Principle of Appropriate Interaction Style The goal of this principle is to be compatible with research done in the choice of appropriate interaction style for some kinds of data. For example, experimental studies proved this hypothesis: when task involved an elementary calendar input, fill-in field techniques were faster than direct manipulation, even for inexperienced users (Mayhew, 1993). When the same task involves the same data, but with difficult values, direct manipulation entry was experimented to be faster. In the same way, a dial seems to be more usable for input an integer if orientation is circular (fig. 7a) (table 3, row 14) rather than a rotator.

Fig. 7. (a) A dial; (b) A spin button

4.2.4. Principle of User Adaptability The goal of this principle is to select AIO with rich behaviour and improved user guidance and feedback if the user level of experience is low (e.g. a spin button rather than an edit box: fig. 7b). If the user level increases, AIO with fast behaviours and manipulations are adopted (e.g. a profiled edit box). By analogy, AIO with direct manipulation are preferred if the user prefers to pick up an item in a list rather than to type it in a field.

4.2.5. Principle of Screen Density Reduction The goal of this principle is to reduce the screen density as much as possible. The screen density can be evaluated by calculating if the number of visual groups would exceed the limit tolerated by the user level. If there are more visual groups, their surface on the screen should decrease for satisfying screen constraints and for avoiding human perception saturation. Some particular AIO can thus be degraded.

4.2.6. Principle of Environment Consideration The goal of this principle is to define selection rules for considering the physical environment as an extension of the two last principles. These replacement and reduction rules can replace an already selected AIO by another one if one desires to take the physical environment into account. These rules can be applied everywhere. For example, every list or combination box, scrolling or not, graphical or not, can be replaced with an equivalent drop-down list if the screen density is high or if the user prefers the selection method or if the user is unexperienced (fig. 8).

Fig. 8. A list box replaced with a drop-down list box

4.2.7. Principle of Specific Data Consideration The goal of this principle is to define selection rules for considering the specific data in particulier or extraordinary situations. Eighteen similar rules have been gathered, but they were not formalized according to the described data model since they introduce the specificity of many different contexts which are difficult to express in a model. For example, a scrolling cursor (fig. 9) can be suggested to input an integer in a continuous domain if the data should express the setting of an apparatus.

Fig. 9. Some scrolling cursors

4.2.8. Principle of Data Grouping The goal of this principle is to define selection rules for considering the input/display of data groups. It often occurs when semantically related data have to be grouped in an appropriate AIO whose definition support aggregation of data. For example, multiple group

boxes can be selected for surrounding all AIO selected for elementary data. Fig. 10 depicts a human-machine interface where group boxes group data on the person, data on the job, data on the skills/orientation.

Fig. 10. Data grouping

4.2.9. Principle of Data Listing The goal of this principle is to define selection rules for considering input/display of data lists. It often occurs when the user has to input multiple instances of a same aggregation of data.

Fig. 11. A repetitive dialog box for a list of data For example, a repetitive dialog box can be selected to input series of data whose type and definition are the same (fig.11). A normal table can be selected to input/display aggregates of data arranged in rows and columns on the condition that all data are elementary and can be expressed in simple edit boxes (fig. 12).

Fig. 12. A normal table for a list of data

5. Conclusion Despite extensive experience in the selection of AIO, this work still suffer from several intrinsic drawbacks:



















a great amount of selection rules (257 for input and 63 for display) have been defined and detailed to increase the precision and the appropriateness of selection rules. Nevertheless, this number remains too high so that the rules are not so easy to manipulate and to master as one might think; the ergonomic richness of the selected AIO really begins where data are very specific because one is able to predict that this particular AIO is the most appropriate in these given precise circumstances. Well then, the power of semantic formalization of the data model stops where selection rules for specific data begin. Therefore, the interest of these rules is not maximized. We believe that this limit is mostly responsible for different hindrances and that it is due to the limits of human perception of real world. If a human expert is able to suggest the best AIO depending on the specific circumstances, this expert can do that because s/he possesses a thorough command of the area which cannot be easily formalized. In other words, the time and effort to formalize this knowledge into selection rules would become too important regardless the benefits; the aim of our corpus of selection rules was mainly based on results, conventions and assumptions that have been gathered from experimental study mentioned in different references (Mayhew, 1992). The consistency between these selection rules is not always clear. A trade-off has been chosen when necessary; the selection rules have been expressed according to a strict production scheme: applying the set of selection rules therefore leads to one particular AIO. Sometimes alternative AIO should be considered equally. Fuzzy thinking should be added to express the likelihood of selecting a particular AIO rather than another one under particular circumstances; selection rules will ever remain incomplete since they are based on existing AIO. If new AIO are born, new selection rules have to be defined; selection rules heavily depends on user preferences, habits and preferences : selecting the most appropriate AIO according to experimental criteria sometimes does not lead to a smart result. Experimental criteria are formal, but psychological preferences are not. selection rules really need a final user validation even they are basically founded on proven theoretical and experimental results; selection rules only for business-oriented application have been studied. If they must be extended to other fields, recent research in the visualization of information according to the complex information types and structures should be considered.

For our limited purposes, we can say that those selection rules have been shown sufficient most of the time. We do not get the impression that new rules would substancially improve

the usability of a selected AIO, except under particular circumstances. Maybe another formalization will be more appropriate.

Acknowledgments The auhors would like to thank the anonymous HCI'94 reviewers for their helpful comments and other members of the TRIDENT project: A.-M. Hennebert, J.-M. Leheureux and I. Provot for their collaboration. This work was partially supported by the FIRST research program, Ref. RASE/SCHL319/Conv. 1487 and by the "Informatique du Futur" project of SPPS under contract N°IT/IF/1. Any opinions, findings, conclusions or recommendations expressed in this paper are those of the authors, and do not necessarily reflect the view of the Belgian Government. Copyright 1994 TRIDENT Project.

References de Baar, D., Foley, J.D., Mullet, K.E. (May 1992), "Coupling Application Design and User Interface Design", Proc. of CHI'92, ACM Press, pp.259-266. Bodart, F., Pigneur, Y. (1989), "Conception Assistée des Systèmes d'Information", Masson, Paris. Bodart, F., Vanderdonckt, J. (1994), "Guide ergonomique de la présentation des applications hautement interactives", Presses Universitaires de Namur, Namur. Bodart, F., Hennebert, A.-M., Leheureux, J.-M., Provot, I., Sacré, B., Vanderdonckt, J. (Aug 1993), "Architecture Elements for Highly-Interactive Business-Oriented Applications", Proc. of EWHCI'93, ICSTI, pp. 151-173. Gray, M.H., de Baar, D., Foley, J.D., Mullet, K. (May 1992), "Coupling Application Design and User Interface Design", Proc. of CHI'92, ACM Press, pp. 657-658. Janssen, C., Weisbecker, A., Ziegler, J. (Apr 1993), "Generating User Interfaces from Data Models and Dialogue Net Specifications", Proc. of INTERCHI'93, ACM Press, pp. 418-423. Johnson, J. (May 1992), "Selectors: Going Beyond User-Interface Widgets", Proc. of CHI'92, ACM Press, pp. 273-279. Kim, W.C., Foley, J.D. (Oct 1990), "DON: User Interface Presentation Design Assistant", Proc. of UIST'90, ACM Press, pp. 10-20. Kim, W.C., Foley, J.D. (Apr 1993), "Providing High-level Control and Expert Assstance in the User Interface Presentation Design", Proc. of INTERCHI'93, ACM Press, pp. 430-437. Mayhew, D.J. (1992), "Principles and Guidelines in Software User Interface Design", Prentice-Hall. Mayhew, D.J. (Apr 1993), "Designing with Graphical User Interface Standards", INTERCHI'93 Tutorial #29, p. 68. Petoud, I., Pigneur, Y. (1990), "An automatic and Visual Approach for User Interface Design", in Engineering for Human-Computer Interaction, North Holland, pp. 403420. Root, R.W., White, E. (Mar 1993), "Graphical User Interface Design Guidelines for Bellcore Software Products", Document SR-STS-002614, Bellcore.

Seligmann, D.D., Feiner, S. (Aug 1991), "Automated Generation of Intent-Based 3D Illustrations", Proc. of SIGGRAPH'91, ACM Press, pp. 123-132. Vanderdonckt, J., Bodart, F. (Apr 1993), "Encapsulating Knowledge for Intelligent Automatic Interaction Objects Selection, Proc. of INTERCHI'93, ACM Press, pp. 424-429. Vanderdonckt, J. (Aug 1993), "A Corpus on Selection Rules for Choosing Interaction Objects", Technical Report 93/3, FUNDP Namur, Institute of Computer Science. Electronically available via anonymous FTP at arzach.fundp.ac.be [138.48.4.5] in /pub/papers/jvd/Selection.ps.Z. Weisbecker, A. (Mar 1993), "Integration von software-ergonomischem Wissen in die Systementwicklung", Proc. of Software Ergonomie '93, pp. 299-310.