WO1992005498A1 - Procede de conception d'interfaces utilisateurs pour programmes d'application - Google Patents

Procede de conception d'interfaces utilisateurs pour programmes d'application Download PDF

Info

Publication number
WO1992005498A1
WO1992005498A1 PCT/US1991/006757 US9106757W WO9205498A1 WO 1992005498 A1 WO1992005498 A1 WO 1992005498A1 US 9106757 W US9106757 W US 9106757W WO 9205498 A1 WO9205498 A1 WO 9205498A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
user interface
user
generic
specific
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US1991/006757
Other languages
English (en)
Inventor
Douglas A. Fults
Anthony M. Requist
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Geoworks
Original Assignee
Geoworks
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Geoworks filed Critical Geoworks
Publication of WO1992005498A1 publication Critical patent/WO1992005498A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present invention relates to a process for designing computer software and, more particularly, this invention relates to a process for designing user's interfaces for application programs.
  • An application is a tool which a] lows a person to use a computer to accomplish a task.
  • a word processor provides the user of a computer with a way to write, store, and print out letters.
  • a drawing program allows him to create charts, diagrams, and organizational charts.
  • the application is the interface between him and the computer hardware.
  • An operating system is a program which acts as an interface between applications and the computer hardware. It provides an environment in which a user may execute programs. Operating systems attempt to make the computer system easy and efficient to use. Operating systems in conjunction with the computer hardware are often called environments. 1
  • a user interface is a set of rules and conventions by which a computer system communicates with the person operating it.
  • operating systems such as UNIX or MS-DOS
  • Users were expected to use and remember complicated, forgettable commands such as "enscript -2Gr -Plw.”
  • Different applications all had different user interfaces--to print the current document, a user might have to press the function key F7 in a word processor and the keys Ctrl-Alt-P in a database program.
  • Computers were difficult to learn, difficult to use, and, worst of all, inconsistent. In the pursuit of the often-coined property known as "user friendliness, " much work was done in terms of improving user interfaces.
  • user friendliness Much work was done in terms of improving user interfaces.
  • GUIs graphical user interfaces
  • buttons, and wind ows accessed by a mouse.
  • GUIs graphical user interfaces
  • the graphical, intuitive nature of these interfaces solved many of the problems inherent in earlier operating systems.
  • GUIs typically provide a large tool kit of user interface gadgets such as windows, buttons, and menus.
  • Applications make use of these UI items to implement their interaction with the user. In order to avoid an out mess of inconsistent applications, companies develop rules and conventions for using the UI gadgets.
  • GUI allows the same applications to be accessed at various levels of functionality. These levels range from an appliance mode, where users are only required to push a few buttons, to a novice computer interface (such as Tandy' s Deskmate., to a full-fledged professional graphic user interface like Motif. Users, as their skills and needs grow, may simply switch interface levels to access more powerful features. So if users only want to quickly type a letter or envelope, they do not have to wade through a program designed to produce newsletters involving multiple columns of text running from page to page and graphics placed randomly throughout the document. They can merely run the word processor in appliance mode and painlessly type a simple letter without having to set a billion options and to pick their way through a hundred extra features (See Appendix B, "Style Guides" for how scalability relates to style guides).
  • FIG 1 illustrates the conventional application design process.
  • FIG. 2 illustrates the application design process according to the present invention.
  • Figure 3 illustrates a dialogue box
  • Figure 4 is a menu.
  • Figure 5 illustrates pixels on a screen.
  • Figure 6 illustrates a scroll bar.
  • Figure 7 illustrates a scrolling list.
  • Figure 8 illustrates a submenu.
  • Figure 9 illustrates hierarchy of objects in a tree data structure.
  • Figure 10 illustrates a window.
  • Figure 11 illustrates the salesman example.
  • Figure 12 illustrates a generic user interface objects.
  • Figure 13 illustrates a sample generic user interface tree.
  • Figure 14 illustrates the realization of the sample user interface tree.
  • Figure 15 illustrates a simple Mackintosh application.
  • Figure 16 illustrates a OS/2 sample application.
  • Figure 17 illustrates a conventional user interaction.
  • Figure 18 illustrates the user interaction according to the present invention.
  • Figure 19 illustrates a good layout for print dialogue box.
  • Figure 20 illustrates a poor layout for print dialogue box.
  • Figure 21 illustrates a computer software system incorporating elements in accordance with the present invention.
  • Figure 22 illustrates a prior art computer software system.
  • Figure 23 illustrates a document control object.
  • Figure 24 illustrates a NewWaveTM interpretation of the document control object of Figure 23.
  • Figure 25 illustrates an OpenLookTM interpretation of the document control object of Figure 23.
  • Figure 26 illustrates a MotifTM interpretation of the document control object of Figure 23.
  • Figure 27 illustrates a list object.
  • Figure 28 illustrates a NewWaveTM interpretation of the list object of Figure 27.
  • Figure 29 illustrates an OpenLookTM interpretation of the list object of Figure 27 ⁇
  • Figure 30 illustrates a MotifTM interpretation of the list object of Figure 27.
  • Figure 31 illustrates three possible gadget choices (Abbreviated Menu Button, Exclusive Settings and Scrolling List) with an example of a screen display and style guide interpretation rules for each.
  • Figure 32 illustrates two possible gadget choices for a hypothetical user interface (Graphical Radio Buttons and Scrolling List) with an example of a screen display and style guide interpretation rules for each.
  • Figure 33 illustrates a generic user interface object and an OpenLookTM user interface and a hypothetical user interface interpretation of the generic object.
  • Figure 34 illustrates a sample generic user interface specification.
  • Figure 35 illustrates an interpretation of the specification of Figure 34 under MotifTM or OpenLookTM.
  • Figure 36 illustrates an interpretation of the specification of Figure 34 under a hypothetical user interface style guide.
  • Figure 37 illustrates an interpretation of the specification of Figure 34 under a hypothetical user interface of the future in an advanced mode.
  • Figure 38 illustrates an interpretation of the specification of Figure 34 under a hypothetical user interface of a future in a novice mode.
  • Figure 39 illustrates an implementation of the principles of the invention using procedural programming rules.
  • Figure 40 illustrates an implementation of the principles of the invention using objects using pointers to methods.
  • Figure 41 illustrates an implementation of the principles of the invention using objects having class pointers to class structures.
  • Figure 42 illustrates a prior art user interaction with an application to produce an action in a computer system.
  • Figure 43 illustrates a user interaction with an application in accordance with the present invention to produce an action in a computer system.
  • Figure 44 illustrates prior art development and use of a specific user interface specification for a particular user interface.
  • Figure 45 illustrates development and use of a generic user interface specification for use with any of multiple specific user interface interpreters (MotifTM,
  • UI component representing an input/output need of an application (as opposed to a visual specification such as a scrolling list). Examples include document control, exclusive list selection, and viewing areas.
  • generic UI object library
  • generic user interface specification interface designed for a particular application based on objects from the generic UI object library, including the selection and organization of objects and hints
  • UI Interpreter generic to specific UI interpreter
  • New UI interpreters for new style guides can he written after the creation of an application executable, and the application's user interface will be presented in accordance with the new style guide. What this means is that new, improved user interfaces could add novel and wonderful capabilities far beyond that imagined by the original application designer, simply because functional as well as subjective information about the application's UI needs are stored with the application. Similarly, specific user interfaces intended for users with varying levels of proficiency may be defined, so the very same application executable can also be presented appropriately to both novice, average, and advanced users.
  • the generic UI object library overcomes these limitations. Input/output needs are abstracted to the highest level possible. Functional needs are identified and placed into distinct categories, called generic UI object classes. The subjective, descriptive thoughts and considerations previously existing solely in the mind of the UI designer are stored as characteristics, known as hints, of the application and its user interface.
  • Style guide requires "File” menu to have these menu items:
  • Style guide requires "File” menu to have these menu items:
  • a specific UI specification which provides a "File” menu with the items required for specific Ul B” would be an illegal interface for specific UI "A” since menu items are named differently and function differently.
  • This problem is solved by abstracting the fundamental need for "document control" within an application.
  • Most applications have a need to manage and manipulate documents, so the generic UI object library provides a single GenDocumentControlClass object.
  • This object if chosen for use in an application's interface, stores the abstract concept that the application performs operations on files and therefore needs the user interface to allow the user to manipulate files.
  • the generic UI to specific UI interpreter software for each of the above specific UIs processes the existence of a GenDocumentControlClass object by creating the appropriate file menu, as specified by the style guide.
  • a common interface requirement of an application is to let the user choose between a number of different options.
  • Some of the gadgets available in different specific UIs which may be used to accomplish this are: ⁇ a scrolling list of items, of which one is highlighted
  • buttons of which one may be selected (pushed in, like the buttons on a stereo receiver to choose between Tuner, Tape, CD, etc.)
  • ⁇ a pop-up list, whereby the current selection is shown. Clicking on it brings up a window which shows the rest of the possible selections. Dragging the mouse over the desired item and releasing selects it.
  • a hint is an embodiment of human/computer interface criteria for an application, stored digitally.
  • the following example illustrates how they are used.
  • the component is a list object, it is implemented as a scrolling list gadget (no other gadgets are available).
  • the single application executable can be run under many different specific user interfaces at many different levels of functionality. To the developer, it's a better product and time and resources saved. To the user, it's five (or more!) programs for the price of one.
  • GEOS offers many different types of hints.
  • functional hints as described above (size, importance, etc.)
  • task related hints For instance:
  • This feature would appeal to someone constructing a report ⁇ This feature would appeal to someone constructing a schedule
  • non-exclusive setting that shows a check mark in a square box when the setting is chosen
  • rectangle containing a group of controls (basically a "multiple-choice” control). Usually accessed as a pull down menu from the main menu area or as a pop up menu from any place on the screen [BOX, SEE PAGE 17] message
  • an object sends a message to another object to make it perform a particular action
  • images on the screen are composed of many individual pixels of certain colors
  • pane containing a list of text fields.
  • the list can be read-only or it can be editable
  • Object-Oriented programming is an approach to programming which is vastly different than traditional procedural programming.
  • Programming languages such as C and Pascal consist of functions and procedures which manipulate data.
  • the program code executes in a well- defined order, looping and branching when necessary.
  • Object-oriented programming groups data and procedures in a bundle known as an object. There is no predictable flow of execution.
  • Objects are self-contained units (data structures) which contain data (called instance data) and procedures (called methods) to modify their own data. Objects send and receive messages. For example, suppose a dog is an object. The commands you give him are messages. He learns those commands, and the responses he remembers are his methods. So, if you instruct the dog to "Sit,” you are sending him a "Sit" message. He receives the "Sit” message, initiates his "Sit” method, and subsequently sits on the ground. Messages
  • An object sends a message to another object to make it perform a particular action. This is also known as invoking another object's method.
  • This way of accomplishing tasks is a natural extension of how humans interact. For example, when a traveling salesman appears at your door, you say, "GO away," and he leaves. You give a command and expect the recipient to handle it. This is how users interact with their computers, and this is why object-oriented programming lends itself so well to a user-driven system.
  • a method is the program code in the object which responds to a particular message.
  • the salesman's "Go away” method was his knowledge that when someone says “Go away” he should turn around, walk away, and remove your name from his list of potential customers (his instance data).
  • Classes are groups of objects with identical types of data and methods. Objects in a class share common sets of data and knowledge of how to respond to certain messages. Each object is called an "instance" of a class. For instance, the salesman above might be an instance of the "Acme Encyclopedia Salesmen” class. He and other fellow instances of the "Acme” class all know how to respond to a "Go away" message because of training from their supervisor.
  • Classes are organized in a hierarchical structure. Classes inherit behavior from classes above it For example, the class "dog" might be defined as:
  • the class Dog has subclasses Pretty Dog and Ugly Dog. These subclasses may have subclasses of their own. Due to inheritance, if the class Dog contains a method "Sit,” then every subclass (Pretty Dog, Ugly Dog) also understands that method. So, if an instance of the class Poodle receives a "Sit" message, it doesn't need to have its own “Sit” method. It simply passes the message up to the class Pretty Dog which passes the message to the class Dog. Why Is Object-Oriented Programming Natural?
  • Objects are intrinsically related to classes. Think of a rolodex with printed sections for name, address, and phone numbers. Every time you fill one out, you create an object. The format of the rolodex card is the class. So then, whenever you fill out a rolodex card, you are creating an instance of the rolodex card class. The way that the format of the rolodex card is presented to an operating system is known as a data structure. Objects (and classes) are implemented as data structures. Data structures are tables of data including structural relationships. So a UI object, with its moniker, attributes, and hints would be a single data structure in the form of its class. 3 Dan Shufer, Hyper Talk Programming. GEOS APPLICATION DESIGN
  • Object oriented programming is not a new concept. Neither is the idea of using objects to represent user interface components. What is novel is the way of using objects as UI components such that GEOS can interpret what those components are intended to do. Then GEOS can create the actual, visual and behavioral application UI to be a good interpretation of any number of style guides.
  • GEOS changes the process of designing an application's user interface.
  • the user interface designer weighs the human/computer interaction design considerations against application input/output requirements and creates a generic user interface description (in the form of objects with attributes and hints).
  • the GEOS operating system uses its specific user interface software and automated style guide interpreter to read the generic description and produce on-screen representations adhering to any particular specific user interface style guide.
  • GEOS accomplishes this seemingly impossible task through a two step process. Firstly, the application developer defines his program's user interface using UI objects with special properties that allow him to express the user interface needs of his application. Secondly, GEOS reads the description, interpreting it, and produces a realization of the program user interface which visually and behaviorally conforms to the explicit and implicit guidelines of a particular style guide. Because this interpretation is done at runtime, the user may switch specific user interfaces (e.g. Motif to Openlook) at any time.
  • specific user interfaces e.g. Motif to Openlook
  • GEOS shortens and streamlines the application development process by removing the step in which the user interface is designed to fit a particular style guide.
  • GEOS provides what is essentially an auto style guide. All the details and nuances of each specific user interface are implemented by GEOS.
  • the application simply defines user interface using a generic model. This generic model decouples the application from its user interface.
  • the application developer specifies the application's user interface in terms of common semantic properties, rather than specifics of the particular user i srface gadgets. As a result, the system supports a scalable environment and several GUI specifications with the same application code.
  • the developer specifies the application's user interface in terms of abstract (generic) objects, common semantic properties, and guiding hints, rather than specific user interface gadgets. These generic objects are placed in a hierarchy to demonstrate their relative importance and interdependencies.
  • GEOS maps ea ⁇ h generio UI object to one or more specific UI objects, depending on which specific user interface is chosen. For example, an application's UI file might specify that a list of options be presented to the user. Depending on the attributes and "hints" of the generic object, this might be implemented as a sub-menu in OpenLook or as a dialog box in OSF/MotifTM. The conversion from generic to specific user interface is transparent to the application. GEOS can accommodate any number of specific user interface libraries.
  • style guides provide guidelines and specifications for application designers to follow when they design their program's user interface. Given a particular set of human-to-computer interaction needs, it defines which specific Ul components to use. Sometimes style guides are very specific: for example, OpenLook specifies that main controls are to be organized in a series of button menus and most style guides ask that menu items end in an ellipses defined if the user will be asked for more information before the operation is carried out.
  • This method of implementing the user interface provides benefits for developer and user alike.
  • the user can purchase one application--a word processor, for instance. Then, depending on his personal preference, he may run the program with a Motif, OpenLook, or NewWave user interface. If his son wants to type a quick letter, he can switch to a user interface designed for novices (Appliance mode in GEOS).
  • Generic UI classes are abstract types of user interface components. By thoroughly researching and analyzing existing and proposed GUIs, GeoWorks identified the base set of user interface components that were common. Abstracting these components--reducing them to their functional essence resulted in ten generic UI classes. For example, all specific Uis need a method of initiating an action hence the generic trigger class. A list of the major generic UI classes follows:
  • ⁇ GenPrimary provides the main window for an application, grouping and managing all of the controls and output areas for the application
  • ⁇ GenTrigger represents a pushbutton that initiates a certain action when triggered by the user ⁇ GenSummons, elicits responses from the user, typically several at a time
  • ⁇ Genlnteraction serves as a generic grouping object (group of controls, non-modal dialog box, menu, or sub-menu)
  • ⁇ GenRange allows the user to interactively set a value within a discrete range of values
  • ⁇ GenList groups multiple selection items (to set options, and so on)
  • ⁇ GenView provides an area of the screen on which a document may be shown
  • ⁇ GenDisplay displays and manages one or more secondary windows
  • GenTextEdit and GenTextDisplay provides text fields with differently formatted text, keyboard navigation, cut and paste, and other editing functionality
  • Generic UI objects are instances--specific incarnations--of generic UI classes. So when an application needs a particular UI component (a button, for instance) it chooses the appropriate generic class (GenTrigger) and asks GEOS to create an instance of that class. The application can then use the resulting generic UI object as part of its user interface. Each individual UI object has its own instance data whose scope is determined by the UI class. There are two kinds of instance data: attributes and hints.
  • a generic UI object that represents the functionality inherent in the type of component desired.
  • GEOS provides different types of generic UI objects which determine the general category of functionality wanted. Special properties of that object are set to convey more detailed as well as vague information about the human/computer interaction design considerations and application input/output requirements.
  • these generic UI objects are data structures with two different types of instance data--attributes and hints.
  • Attributes define the behavior and/or appearance of a UI object in a very specific manner: an attribute is either on or off, and there is a definite set of attributes associated with every UI object class. When an application sets an attribute, it can be sure that the specific UI component that GEOS selects exhibits the desired behavior.
  • setting the modal attribute for a dialog box ensures that the user must respond to it before continuing.
  • Setting the disabled attribute for a trigger dims the trigger's label (called a moniker) and doesn't allow the user to select it.
  • a moniker is a special attribute every UI object has. Each UI object may be given a moniker, or visual representation, though a moniker does need to be defined for every object. It could be the name of a button or the icon to be displayed when a window is minimized.
  • a UI object is not restricted to a single moniker: a list of monikers may be defined. Depending on the situation and context, GEOS uses one of the monikers. For example, an application may define different icons for CGA, EGA, and VGA monitors to optimize the its appearance. GEOS displays the proper one for a particular user's set up. Some UI objects may have several textual and pictorial monikers. GEOS chooses the appropriate moniker. Hints
  • Hints provide additional information about the UI object in question. An application's needs are not always absolute and may be interpreted differently (even ignored) by different specific UIs. Some visual and behavior aspects of UI objects should not be implemented as attributes because of this. In other words, there are some UI components or functionality which is not universal to all specific UIs. Those capabilities cannot be attributes, since not all specific UIs support them. Therefore, they become hints. When the developer assigns hints to a particular UI object, he cannot be certain that the hint will be implemented by any one specific UI. There are two types of hints: command and declarative.
  • Command hints are direct requests for a specific implementation of a UI component.
  • a developer would choose to use a command hint when he had a specific UI component style in mind.
  • an application may explicitly ask for a scrolling list (HINT_SCROLL_LIST) or check boxes (HINT_CHECKBOXES).
  • HINT_SCROLL_LIST scrolling list
  • HINT_CHECKBOXES check boxes
  • Not all specific UIs offer the capability to follow command hints. For instance, some specific UIs allow the user to use the keyboard to navigate menus and dialog boxes. To support this, certain UI objects would contain severa l HINT_NAVI GATI ON_l D and
  • HINT_NAVIGATION_NEXT_ID hints . Motif would make use of this . OpenLook would ignore it because the style guide doesn ' t allow such navigation. GEOS fulfills a particular command hint in any specific user interface that supports it.
  • Declarative hints are more vague; without referring specifically to a particular implementation, they give an indication of the functionality of the UI object in question.
  • a generic UI object containing a list of possible actions may have a HINT_MENUABLE, indicating that the developer envisions the list being presented in a menu.
  • GEOS implements the list of actions as a simple series of large, plainly visible buttons.
  • an option in that menu may have hints stating that it is advanced, infrequently used, and potentially dangerous. Then a novice specific UI would remove the trigger altogether.
  • declarative hints may or may not be implemented by a particular specific UI.
  • CVA does not allow submenus in the menu bar.
  • a Genlnteraction object with the hint HINT_MENUABLE that is inside of another Genlnteraction object with the hint HINT_MENUABLE would be implemented as a submenu in
  • This tree is a hierarchy of UI objects, to
  • tokenID "MANUFACTURER_ID_GW”
  • viewAttributes isol atedContents
  • backColorR BLACK /* background color */
  • Menultem2 GenTrigger ⁇
  • GEOS implements it in any particular specific user interface. It automatically sizes menus, fields, and boxes; it places buttons, scroll bars, and text--all the while adhering to the specific user interface style guide. Below is how this particular generic UI specification might be realized by GEOS for Motif.
  • Decorations are additional specific user interface components that the developer does not request, but that GEOS provides in order to maintain a good implementation of a particular style guide.
  • GEOS adds the buttons in the upper comers, a resizing border, and a "pin" option in the menu. These are all accoutrements which the style guide for GeoWorks' implementation of Motif states should exist and function in a certain manner. The developer doesn't need to worry about remembering them or asking for them, since they may be different for Open Look or New Wave. This is another example of how GEOS ensures a good interpretation of style guide without needing explicit direction from the programmer.
  • Libraries are modules of executable code which are dynamically loaded into memory when needed by one or more applications. Only one copy of a library module is loaded at a time and is shared by all executing applications.
  • Specific UI libraries are responsible for interpreting the generic UI description and implementing the actual application's user interface.
  • Macintosh applications make use of many resources, such as menus, fonts, dialog boxes, and icons, which are stored in resource files.
  • an icon resides in a resource file as a 32-by-32 bit image, and a font as a large bit image containing the characters of the font.
  • the resource consists of descriptive information (such as, for a menu, the menu title, the text of eacn command in the menu, whether the command is checked with a check mark, and so on).
  • the resources used by an application are created and changed separately from the application's code. This separation is the main advantage to having resource files. A change in the title of a menu, for example, won't require any recompilation of code, nor will translation to another language. 4
  • the programmer would first make use of graphical, interactive development tools on the Macintosh to define the menu and its contents. He would first create a new menu resource. Then he would add commands to the menu (New, Open, Save, Save As, and Quit). Finally, he sets the attributes of the menu and its choices (e.g. no checkmarks, separators between Save As and Quit, etc.). Below is a complete list of all the resources he would define:
  • Each menu resource also contains a "menu ID” that' s used to identify the menu when the user chooses a command from it; for all three menus, this ID is the same as the resource ID. 4This paragraph and subsequent descriptions and code fragments from "Inside Macintosh,” Vol. 1. Excerpts of code to initialize and display these resources would be as follows:
  • CONST applelD 128; ⁇ resource IDs/menu Ids for Apple, File menu ⁇
  • appleM 1; ⁇ index for each menu in myMenus (array of ⁇
  • windowID - 128 (resource ID for application's window ⁇
  • exitcommand 6; ⁇ skip a number because of separator ⁇
  • VAR mymenus ARRAY[1..menuCount] OF MenuHandle;
  • VAR i INTEGER
  • OS/2's style guide (CVA) and operating system are quite different than Apple's, so user interface designs need to be altered and code needs to be completely rewritten.
  • ClientWndProc // Window procedure for class OL, // Class style
  • WinQuerySysPointer HWND_DESKTOP, SPTR_APPICON, FALSE
  • the programmer formats dialog boxes in the
  • GeoWorks identified a problem.
  • Conventional applications generally handle their own user interaction. For example, if the user double clicks on any letter in a word, the application selects the entire word because that's what its style guide says to do. Notice that we have a parallel without earlier dilemma--different style guides have different ways of handling user input. How can an application be truly specific user interface independent if it has to worry about different types of user input? The GeoWorks answer is to abstract user interaction as well.
  • the application receives user input. For instance, the user double clicks while using a word processor under Motif. Then, the application determines the context of the user input. For instance, the user clicked on the second word in a word processing document. Next, the application passes this information, the actual input and the context, to the appropriate specific UI interpreter. Finally, the UI interpreter, given the context and the raw input, tells the application exactly what to do. For example, it tells the word processor to select the targeted word.
  • Style guides are documents intended to promote both visual and operational consistency across the set of applications running in a particular environment. To achieve this goal, design rules describe the user interface and design approach in detail. However, it is impossible to anticipate all situations. So that consistent extensions can be made, portions of the document attempt to explain the rationale behind the rules, and the intended "feel" of the applications in question. These design rules are provided in pursuit of integration and consistency. Application programmers are asked to commit themselves to following the design rules because of the importance of a cohesive, consistent set of applications. 6
  • Scrolling with Scrollbars This section describes information vou need to specify for your application when vou provide scrollbars for a scrollable text region....
  • Scrolling Objects of Unknown Size In some situations, it is impossible to determine the size of the object being viewed. For example, the result of a database
  • This dialog box design is good for several reasons. Firstly, it visually groups options into logical groups with sensible titles--Printer Options and Document Options. The setting of which printer is connected is not one which the user frequently changes. Therefore, the options related to this are not even accessed through this dialog box. Clicking Change Options... brings up a separate dialog box.
  • the Document Options have descriptive, obvious names--high, medium, and low print quality. Print and Cancel give an good indication of what the buttons will do. Additionally, the extra box around Print indicates a default action, good for experienced users as well as novices unsure of what to do next.
  • the scalable user interface can be thought of as just another style guide. It is simply a style guide designed with the user's computer proficiency very much in mind. For example, for novices, the style guide would state that the user should be able to plainly see all his options. Thus, hidden menus (pulldown or pop up) would not be allowed. Scrolling views are also undesirable because of their complexity. Visible methods of getting help need to be evident at all times.
  • an automated style guide can run an application with its normal style guide (such as Motif or Open look), or switch to one designed for novices. Conceptually and to the application developer, it's just the same as switching between two very similar "professional" specific user interfaces. To the user, it's like getting several programs for the price of one.
  • FIG. 21 there is shown a diagram illustrating the dynamic interaction of the constituent elements of the invention.
  • the elements of Figure 21 all are implemented in computer software.
  • the Application software interacts with the operating system software.
  • the operating system software includes the Generic User Interface Object Library and Controller (GUIOLC), multiple specific UI Interpreters (SUIIs) (only one shown), and multiple specific UI Toolbox and Controllers (SUITC) (only one shown), and their respective driver software modules (only one set of driver software modules shown).
  • GUILC Generic User Interface Object Library and Controller
  • SUIIs multiple specific UI Interpreters
  • SUITC multiple specific UI Toolbox and Controllers
  • GUI Generic UI Specification
  • SUITC SUITC
  • GUISs for the different Applications.
  • the GUIOLC and the SUII serve to map Input/Output (I/O) requirements of an Application to the SUITC under which the Application is to be presented to the user.
  • the GUIOLC provides a series of generic UI object classes (e.g., GenApplication, GenPrimary, GenTrigger, etc). These generic UI classes act as an interface between the Application and the portion of the operating system software that controls the representation of a specific user interface for the Application. For example, when the Application needs to represent a UI component used to initiate a certain user action, it specifies the GenTrigger generic user interface object. From the standpoint of the Application, the steps required to represent a component for initiating user interaction merely involves specifying the GenTrigger object.
  • the operating system software handles the details of actually selecting, arranging and otherwise managing the gadgets used to represent the component.
  • a selected SUII uses the specified object and instance data for that object to interpret the manner in which the specified object is to be represented.
  • the selected SUII selects gadgets from a corresponding SUITC and arranges the gadgets in accordance with attributes and hints in the instance data for the specified object.
  • Each Application can have a different GUIS associated with it.
  • GUIS GUIS
  • the different GUISs associated with the different Applications can result in different representations (visual or behavioral) for the same generic UI object. This is because different GUISs can have different instance data.
  • the Operating System Software rather than the application, indicates the specific UI under which the Application is run.
  • the system software determines which of the four is to be used by the Application (and which of the four SUIIs and SUITCs).
  • the application itself to indicate which of the four (or more) specific UIs is to be used by the Application.
  • Figures 23-26 illustrate how the same generic UI object and the GUIS for a particular Application can result in different visual representations when different specific UIs are designated.
  • a GenDocumentControl object and the instance data from an Application GUIS is shown.
  • Figure 24 shows a possible NewWave interpretation of the object of Figure 23.
  • Figure 25 shows a possible OpenLook interpretation of the object of Figure 23.
  • Figure 26 shows a possible Motiff interpretation of the object of Figure 23.
  • Figures 27-30 further represent how the same generic UI object and a GUIS for a particular Application can result in different visual representations when different specific UIs are designated.
  • Figures 28-30 respectively represent possible NewWave, OpenLook and Motiff interpretations of the object of Figure 27.
  • Figure 31 illustrates the operation of a representative SUII for a GenList object under an OpenLook User interface. Possible gadget choices available from the corresponding OpenLook SUITC are indicated in the left column. The representation and arrangement of the gadgets in accordance with this SUII is indicated in the center column. The decision method used to determine which gadget choice to make is indicated in the right column.
  • the representative interpreter selects which gadgets (left column) and their arrangement (center column) based upon predetermined criteria (right column).
  • the information used to test the criteria is found in the instance data of the GUIS for the designated GenList object.
  • one Application may specify certain instance data in its GUIS for the GenList object, and another Application might specify different instance data in its GUIS for the GenList object.
  • the operating system using the exemplary SUII of Figure 31, therefore, could represent a GenList object differently for the two Applications due to their different GUISs.
  • Figure 32 illustrates the operation of another exemplary SUII.
  • the interpreter of Figure 32 is hypothetical for a GenList object.
  • the left column represents possible gadgets from the hypothetical SUITC (not shown).
  • the center column represents their arrangements under this interpreter.
  • the right column illustrates the criteria used to select the gadgets.
  • FIGs 31 and 32 it should be appreciated that even the same generic UI object (e.g. GenList) using the same instance data from the same GUIS can result in a different UI representation when a different specific UI is selected.
  • the specific UI is OpenLook
  • Figure 32 the specific UI is a hypothetical UI.
  • Figure 33 shows a further representation of a generic user interface object (GenList) and its instance data and two possible interpretations of it, one under a hypothetical UI, and the other under an OpenLook UI.
  • GeneList generic user interface object
  • Figure 34 shows a representative hierarchy of generic UI objects and their respective instance data.
  • Figure 35 shows possible Motiff and OpenLook interpretations.
  • Figure 36 shows a possible hypothetical graphical UI interpretation.
  • Figures 37 and 38 respectively show possible hypothetical interpretations under advanced and novice modes.
  • Figure 43 provides a dynamic block diagram which represents interpretation of user interaction by an operating system in accordance with the present invention.
  • a user provides an input such as a double click mouse command on text.
  • the Application passes the user input command information (double click) and the context information (over text) to a specific UI interpreter.
  • the SUII interprets the input information and indicates its meaning to the Application.
  • Application then can request the operating system to perform a function consistent with the input (e.g., select a targeted word). It will be understood that different specific UIs can interpret the same input differently. Moreover, the different interpretations can depend not only upon the nature of the command but also upon the context in which the command is provided.
  • the SUII shields the
  • FIG 41 there is provided a dynamic block diagram which provides a generalized representation of the operation of an object oriented system.
  • the present invention is implemented as an object oriented system, although it could be implemented as a procedural system ( Figure 39).
  • each generic UI object represents a class.
  • the GUIS for an Application provides instance data for the generic UI object class members.
  • the multiple SUIIs include messages that point to methods for operating on the instance data.
  • the generic UI object points to the SUII for the first specific UI, and the messages and methods of that first SUII operate on the instance data of the generic UI object.
  • an Application is running under a second specific UI
  • the generic UI points to the SUII for the second specific UI, and the messages and methods of the second SUII operate on the instance data of the generic UI object.
  • an Application and an SUII can communicate through a generic UI object.
  • the Application may specify the generic UI object GenList and communicate the message, delete "tomato".
  • the GenList object running under the OpenLook specific UI, for example, sends the message to the OpenLook SUII.
  • the OpenLook SUII uses the message to identify a method that results in removal of the "tomato" moniker from the UI representation.
  • GUIOLD and the multiple SUIIs are separate modules.
  • the GUIOLC and the multiple SUIIs can be implemented as a single module without departing from the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Digital Computer Display Output (AREA)
  • Processing Or Creating Images (AREA)
  • Stored Programmes (AREA)
  • Document Processing Apparatus (AREA)

Abstract

Procédé de conception d'interfaces utilisateurs destinées à des applications, caractérisé en ce que les applications sont complètement indépendantes des changements se produisant dans des interfaces utilisateurs spécifiques. Le procédé permet la conception d'interfaces utilisateurs génériques et il stocke lesdites interfaces utilisateurs génériques dans des structures de données avec des indications et des objets génériques de sorte que l'interface accessoire finale ne soit pas limitée à l'application.
PCT/US1991/006757 1990-09-24 1991-09-24 Procede de conception d'interfaces utilisateurs pour programmes d'application Ceased WO1992005498A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US58686190A 1990-09-24 1990-09-24
US586,861 1990-09-24
US59568690A 1990-10-09 1990-10-09
US595,686 1990-10-09
US68110291A 1991-04-05 1991-04-05
US681,102 1991-04-05

Publications (1)

Publication Number Publication Date
WO1992005498A1 true WO1992005498A1 (fr) 1992-04-02

Family

ID=27416493

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1991/006757 Ceased WO1992005498A1 (fr) 1990-09-24 1991-09-24 Procede de conception d'interfaces utilisateurs pour programmes d'application

Country Status (4)

Country Link
JP (1) JP2794339B2 (fr)
AU (1) AU8752791A (fr)
IL (1) IL99550A0 (fr)
WO (1) WO1992005498A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0603095A3 (fr) * 1992-11-05 1995-03-29 Ibm Méthode et appareil pour gérer un environnement de fenêtres dans un système de programmation orientée objet.
EP1067449A3 (fr) * 1994-03-10 2001-03-21 Microsoft Corporation Dispositif et méthode de positionnement automatique d'un curseur sur une zone de contrôle
WO2010147433A3 (fr) * 2009-06-19 2011-03-31 Samsung Electronics Co., Ltd. Appareil et procédé d'envoi et de réception d'une interface utilisateur dans un système de communication
US8037406B1 (en) 2006-07-25 2011-10-11 Sprint Communications Company L.P. Dynamic screen generation and navigation engine
US8531480B2 (en) 1994-05-16 2013-09-10 Apple Inc. Data-driven layout engine

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010048448A1 (en) 2000-04-06 2001-12-06 Raiz Gregory L. Focus state themeing

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4692858A (en) * 1984-02-02 1987-09-08 Trillian Computer Corporation Visual interface between user and computer system
US4782463A (en) * 1985-09-12 1988-11-01 International Business Machines Corp. Method for generating display screens for a set of application programs by calling screen management subroutines
US4811240A (en) * 1986-12-22 1989-03-07 International Business Machines Corporation System for creating and controlling interactive graphic display screens
US4866638A (en) * 1988-03-04 1989-09-12 Eastman Kodak Company Process for producing human-computer interface prototypes
US5021976A (en) * 1988-11-14 1991-06-04 Microelectronics And Computer Technology Corporation Method and system for generating dynamic, interactive visual representations of information structures within a computer
US5041992A (en) * 1988-10-24 1991-08-20 University Of Pittsburgh Interactive method of developing software interfaces

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH021025A (ja) * 1988-06-09 1990-01-05 Fuji Xerox Co Ltd ユーザインタフェイスの排他的選択子作成方式
JPH021023A (ja) * 1988-06-09 1990-01-05 Fuji Xerox Co Ltd ユーザインタフェイス設計方式

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4692858A (en) * 1984-02-02 1987-09-08 Trillian Computer Corporation Visual interface between user and computer system
US4782463A (en) * 1985-09-12 1988-11-01 International Business Machines Corp. Method for generating display screens for a set of application programs by calling screen management subroutines
US4811240A (en) * 1986-12-22 1989-03-07 International Business Machines Corporation System for creating and controlling interactive graphic display screens
US4866638A (en) * 1988-03-04 1989-09-12 Eastman Kodak Company Process for producing human-computer interface prototypes
US5041992A (en) * 1988-10-24 1991-08-20 University Of Pittsburgh Interactive method of developing software interfaces
US5021976A (en) * 1988-11-14 1991-06-04 Microelectronics And Computer Technology Corporation Method and system for generating dynamic, interactive visual representations of information structures within a computer

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0603095A3 (fr) * 1992-11-05 1995-03-29 Ibm Méthode et appareil pour gérer un environnement de fenêtres dans un système de programmation orientée objet.
EP1067449A3 (fr) * 1994-03-10 2001-03-21 Microsoft Corporation Dispositif et méthode de positionnement automatique d'un curseur sur une zone de contrôle
US8531480B2 (en) 1994-05-16 2013-09-10 Apple Inc. Data-driven layout engine
US8037406B1 (en) 2006-07-25 2011-10-11 Sprint Communications Company L.P. Dynamic screen generation and navigation engine
WO2010147433A3 (fr) * 2009-06-19 2011-03-31 Samsung Electronics Co., Ltd. Appareil et procédé d'envoi et de réception d'une interface utilisateur dans un système de communication
US8892633B2 (en) 2009-06-19 2014-11-18 Samsung Electronics Co., Ltd Apparatus and method for transmitting and receiving a user interface in a communication system

Also Published As

Publication number Publication date
JPH05508726A (ja) 1993-12-02
JP2794339B2 (ja) 1998-09-03
IL99550A0 (en) 1992-08-18
AU8752791A (en) 1992-04-15

Similar Documents

Publication Publication Date Title
US5327529A (en) Process of designing user's interfaces for application programs
Myers User interface software tools
US6469714B2 (en) Infocenter user interface for applets and components
US6259445B1 (en) Computer-based documentation and instruction
De Baar et al. Coupling application design and user interface design
US6275227B1 (en) Computer system and method for controlling the same utilizing a user interface control integrated with multiple sets of instructional material therefor
Loy et al. Java swing
US6222537B1 (en) User interface controls for a computer system
Scarpino et al. SWT/JFace in Action: GUI Design with Eclipse 3.0
US6518979B1 (en) Automatically-maintained customizable user interfaces
Myers 51. Graphical User Interface Programming
JP2794339B2 (ja) アプリケーションプログラムのユーザインターフェースを設計するプロセス
Myers et al. Environment for rapidly creating interactive design tools
Tuck et al. Help by guided tasks: utilizing UIMS knowledge
Lawrence Compaq Visual Fortran: A guide to creating windows applications
Myers UIMSs, Toolkits, Interface Builders 1
Cole et al. Java Swing
Szczur et al. Transportable applications environment (TAE) plus experiences in “Object”-ively modernizing a user interface environment
Herczeg et al. A new approach to visual programming in user interface design
Mokhtar INTERACTIVE JAVA PROGRAMMING
Green et al. access to information: the human computer interface and GIS
Myers et al. Overview of the Amulet User Interface Toolkit
Jain Vsh: a Multiparadigm Framework for Graphical User Interfaces
Altenhofen et al. Adaptation and Use
Oldenburg OSF Motif: the user interface standard

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA JP KR NO SU

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IT LU NL SE

COP Corrected version of pamphlet

Free format text: PAGES 1-78,DESCRIPTION,REPLACED BY NEW PAGES 1-74;PAGE 79,CLAIMS,REPLACED BY NEW PAGE 75;PAGES 1-35,DRAWINGS,REPLACED BY NEW PAGES 1/34-34-34;DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase