ECMA TR 61-1992 USER INTERFACE TAXONOMY《用户界面分类法》.pdf

1、EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONUSER INTERFACE TAXONOMYECMA TR/61June 1992.EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONUSER INTERFACE TAXONOMYECMA TR/61June 1992.Brief HistoryECMA/TC35 was set-up in 1990 to develop an architectural reference model for the user system interface. The mainpur

2、pose was to use the developed model to identify the standards required for this interface and also to improve thecommunication on user interfaces in generally providing a common framework and terminology.Work started by examining the currently available user system interfaces and the relevant work a

3、lready in progress inother standardisation bodies. A number of meetings were dedicated to the consideration of user interfaces eithercommercially available or under development, and liaison was maintained with other standardisation bodies, inparticular with ISO/IEC JTC1/SC18 WG9 and is ISO/TC159/SC4

4、 WG5.In addition to the ECMA user interface reference model, this ECMA Technical Report contains a set of forms (seeannex A), permitting the classification of a user interface according to the ECMA taxonomy. This annex containsexamples of completed forms.The work of NIST was considered, and annex B

5、describes the relationship between the interface in this TechnicalReport and the one described in FIPS 158.Annex C describes a set of input, output and input/output devices.Work on this ECMA Technical Report was completed in February 1992.Adopted as an ECMA Technical Report by the ECMA General Assem

6、bly of June 1992.- i -Table of contents1Scope 12 References 13 Definitions 13.1 Dialogue 13.2 Dialogue control function 13.3 Dialogue technique 13.4 Presentation of information 13.5 Coding 13.6 Formatting 13.7 Input/Output device 13.8 Guidance function 13.9 Metaphor 24 Acronyms 25 User interface str

7、ucture 25.1 Integrated approach 25.2 Structure of components 35.2.1 Metaphor 35.2.2 Dialogue technique 45.2.3 Guidance function 45.2.4 Dialogue control function 55.2.5 Presentation of information 65.2.6 Input/Output devices 76 Engineering and ergonomic principles 86.1 Action/object order 86.2 Comple

8、xity of function set 86.3 Complexity of objects 86.4 WYSIWYG 86.5 Physical principles 86.6 Dialogue principles 96.7 Drivability 96.8 Look and Feel 96.9 Internationalisation 97 Applicability domains 98 Environmental constraints 109 UIRA realisation 10Annex A User interface classification methodology

9、13- ii -Annex B The NIST interface model 17Annex C Description of input and output devices 191ScopeUser interface design is an area where research and standardization are still in progress. Therefore, thistechnical report cannot be exhaustive.Most existing work on user interface models has focussed

10、on the technical aspects, with particular emphasison implementation issues. By contrast, this report attempts to concentrate on conceptual aspects. For thisreason, it is not always easy to relate the model described in this technical report to those proposed by others.This ECMA Technical Report desc

11、ribes user interface elements and concepts and their relationships anddependencies. It should support the description of existing user interfaces and the specification of future onesin terms of these elements and concepts and their structure.It is not the purpose of this ECMA Technical Report to giv

12、e value judgement on the choices for specific userinterfaces.This ECMA Technical Report should assist in improving communication on user interfaces in general byproviding a common framework and terminology. It might also assist:- the designer/implementor of user interfaces and of user interface mana

13、gement systems;- the vendor when describing user interfaces of software products;- the procurer/buyer when defining user interface requirements;- standardisation groups.2 ReferencesISO 9241 Ergonomic requirements for office work with visual display terminals (VDTs) - Multi-partStandardFIPS 158 The u

14、ser interface component of the application portability profile (NIST - 1991)3 DefinitionsFor the purpose of this ECMA Technical Report the following definitions apply.3.1 DialogueA two-way communication between a user and a system to achieve a particular goal.3.2 Dialogue control functionA function

15、supporting the user progressing through a dialogue.3.3 Dialogue techniqueA specific method to implement a dialogue.3.4 Presentation of informationThe coding and formatting methods used to support the user progressing through a dialogue.3.5 CodingThe use of a code which assigns meanings to a variety

16、of sensory signals to convey information betweensystem and user.3.6 FormattingThe arranging and structuring of coded information to assist the user in encoding input signals anddecoding output signals.3.7 Input/Output deviceA physical mediator between the user and the system.3.8 Guidance functionInf

17、ormation or capabilities that guide the users interaction with the system.- 2 -3.9 MetaphorAbstraction of familiar everyday objects or actions to be applied to user interface objects or actions byanalogy.NOTE 1:The usual definition of metaphor (see e.g. Collins dictionary) reads: “A figure of speech

18、 in which a wordor phrase is applied to an object or action that it does not literally denote in order to imply aresemblance.“4 AcronymsCAD Computer Aided DesignCASE Computer Aided Software EngineeringCSCW Computer Supported Cooperative WorkDTP Desktop PublishingI/O Input/OutputUIRA User Interface R

19、eference ArchitectureWYSIWYG What You See Is What You Get5 User interface structureClassification of user interfaces is made easier by the identification of commonalities, like engineering andergonomic principles.Another dimension of viewing user interfaces results from their domains of applicabilit

20、y. It divides into threecategories: the application area itself (e.g. office, control rooms), the user characteristics (e.g. expert, novice,casual), and the constraints (e.g. technology, economics).5.1 Integrated approachWith this approach the user views the interaction as one homogeneous integrated

21、 dialogue with the systemwhere the individual components are not exposed. However, from a system point of view, these individualcomponents are identifiable. Logically, six main components can be identified as shown in figure 1.PresentationofinformationApplicationApplicationDialoguetechniqueGuidancef

22、unctionI/O deviceMetaphorDialoguecontrolfunctionDIAL OGUEUSERFigure 1 - User interface overview- 3 -5.2 Structure of components5.2.1 MetaphorMetaphors are built for environments, objects and actions. Typical environmental metaphors that arecommonly found in current user interfaces include:- the desk

23、top metaphor;- the workbench metaphor;- the control panel metaphor.There are other existing or possible metaphors, for example various games are built on metaphors.Metaphors for objects and actions may be either specific to certain environments or may be generic, likecut and paste or drag and drop.

24、User interfaces may use one or more metaphors.Similarity between the metaphors and the user interface objects or actions improves acceptance andreduces the risk of misinterpretation.5.2.1.1 The desktop metaphorThe desktop metaphor represents objects and actions traditionally associated with a desk a

25、nd thesurrounding office environment.Typical metaphorical objects include:- folders, notebooks and documents;- filing cabinets;- calculators;- printers, fax machines, scanners;- in-baskets and out-baskets for mail;- a waste basket for disposing of unwanted documents;- alarm clocks and diaries;- card

26、 files.Actions associated with the desktop metaphor often involve “direct manipulation“ using a pointingdevice. These include:- filing;- printing;- mailing;- copying.5.2.1.2 The workbench metaphorThe workbench metaphor represents an environment which contains the tools and other work itemsorganised

27、to do work in a particular task area. Workbenches are usually specialised for the generationof particular products, such as:- software (CASE);- engineering drawings (CAD);- publications (DTP).5.2.1.3 The control panel metaphorThe control panel metaphor represents a physical panel containing an array

28、 of instruments forcontrolling a machine.Typical objects include dials and gauges (both analogue and digital), sliders, buttons and knobs.Typical application areas include:- process control;- patient monitoring;- simulation.- 4 -5.2.2 Dialogue technique5.2.2.1 MenusA set of options presented by the

29、dialogue system to the user. The user selects one or more optionsfrom the set and the system provides the desired response (or another menu in the case of ahierarchical choice structure). Menu options may be textual, symbolic or spoken.5.2.2.2 Languages- Natural languageThe technique by which users

30、communicate with the dialogue system in language originally usedfor human to human communication. The language itself is normally restricted with regard to thevocabulary and phrases allowed.- Command languageA specified set of user inputs which, when processed by the dialogue system, result in assoc

31、iateactions. Users enter (rather than select) complete or abbreviated command(s) and the dialoguesystem performs the activities specified by the command(s). Command utilized in a givenapplication are usually referred to as a command language. Command languages include bothnatural-like languages and

32、specialised languages.- Questions and answersA dialogue technique by which the user responds to questions asked by the dialogue system (e.g.system-initiated dialogue). Questions are typically asked one at a time and may vary depending onthe previous answer. In most applications of this dialogue tech

33、nique, answers can be qualitative(yes/no) or quantitative (a number).5.2.2.3 Direct manipulation- Object basedA form of dialogue in which the user directly acts upon the objects to be manipulated by pointingat them, moving and/or changing their physical characteristics (or values) via the use of an

34、inputdevice. In its purest form, a direct manipulation dialogue allows users to perform all availableinteraction operation by acting on displayed objects in ways analogous to manipulating physicalentities. Such objects are typically concrete, often graphical, representations of abstract softwarestru

35、ctures or capabilities, displayed within a simulated two or three-dimensional environment.- Control panel basedThis dialogue technique is defined by the closed loop consisting of machines and human operatorscontrolling the machines using control actuators, which are represented by objects that are u

36、sed toperform an action.The specifics of this dialogue technique are:- variety of types of control actuators;- input in digital or analogue form in normally fixed sequences;- strong time constraints (real time);- complexity of system control.5.2.2.4 Form fillingA dialogue technique that requires the

37、 user to fill in, complete or modify fields (typically labelled) ona form displayed by the system. This dialogue technique allows multiple user inputs in a singletransaction and provides contextual information concerning the nature of the required inputs.5.2.3 Guidance functionThis Technical Report

38、only considers guidance functions which are explicitly provided to the user onrequest or automatically by the dialogue system.Implicit user guidance which is integrated into the user-computer interaction is not considered here,because it does not represent an user interface structural aspect.- 5 -Gu

39、idance functions can be divided into:- guidance in non-error situations and error prevention;- guidance in error situations and error management.The guidance function is intended to promote efficient use of the dialogue system (quick and accurateuse of full capabilities), minimise the memory load on

40、 the user, decrease the time required to learn howto use the dialogue system, provide support for users of different skill levels and help the user to escapefrom error situations.5.2.3.1 Guidance in non-error situations and error preventionGuidance in non-error situations helps the user to access th

41、e functionality that the dialogue systemwas defined to provide. In addition it minimises the probability of user errors.Typically it includes:- Comprehension and task-oriented feedback is any unsolicited information given to the user insupport of efficient task completion. This feedback could be in

42、the form of conceptual overviews.Where the feedback can be directly related to the task context, it may include feedback on how thetask may be completed, on the dialogue system state, and on valid user input for the current taskstate. It also contains dialogue system messages enhancing the perceptio

43、n of user control.- On-line help explains at the users request “what“ can be done, and “where“, “when“ and “how“ itcan be done. This help may be specific to the current dialogue situation or may provide moregeneral guidance. Options include:. instructions for executing a command or accessing and usi

44、ng given dialogue system capabilities;. explanations of concepts associated with a task or interface component;. explanations of a special syntax.- Navigation is that type of guidance which supports the user in finding the most efficient dialoguepath to complete the task.Prompts provide guidance whe

45、re particular sequences of actions are required by the dialoguesystem.Cues provide guidance where no particular action is necessary but which aid users in navigation,e.g. indication of current mode.- Warnings are any information given to the user regarding possibly undesirable consequences ofexecuti

46、ng certain actions, e.g. the action is not reversible or may cause an unstable state to bereached.5.2.3.2 Guidance in error situations and error managementIn case of error situations, an error handling process may be offered to the user explaining the errorand supporting correction of it.These error

47、 handling processes may provide:- system information enabling the user to judge whether an error has occurred;- information about those portions of system actions which have been already executedsuccessfully;- for unintended system actions in progress, a mean to allow the user to end these actions t

48、o theusers satisfaction;- for error management, a mean to allow the user to decide on termination or continuation of thedialogue.5.2.4 Dialogue control function5.2.4.1 System environmentThe environment within which the dialogue system operates often provides general control functions.These include:-

49、 6 - WindowingThe division of a display area to provide one or more graphical contexts.The windowing system will normally support concepts such as input focus and providemechanisms to allow the user to arrange the windows as desired.- I/O equivalenceTo support the different requirements and preferences of users, the dialogue system may supportdifferent user interactions as equivalent. Such equivalences are used to provide accelerators or tosupport disabled users, for example keyboard equivalents for mouse actions, flashing versusbeeping.- Global storage facilitiesTo support the int