The Object-Action (or visa-versa) model and its applications
From Computing and Software Wiki
Contents |
Background
Object Action Interface or Action Object Interface is changing the way people interact with systems. As more and more systems switch from text mode command based languages to Graphical User Interface (GUI) the problem now lies with visually representing and displaying of user's tasks objects and actions. Before GUI was implemented in systems and users had to remember a set of commands and if they ever had to use a command which was not used frequently they would have to refer to another user of the manual pages.
Object Action Interface is basically an extension to the Graphical User Interface, it also relates to Direct Manipulation User Interface. DMUI can help create better Human Computer Interfaces and can also increase the usability of the product
There are two basic interaction models for any given system.
Object Action Interface
In this model the user will select the object first and then select the action which will be performed on the object.
Example: In Windows, if you want to copy a file you will first select a file (Object) and then right click and select copy (Action).
Action Object Interface
In this model the user will select an action and then select the object the action will be performed on.
Example: In command prompt, if you want to copy a file you will input copy <Source File> <Destination File>. 'Copy' which is the action comes before the object '<Source File>'
Scope
There has always been distinction between those two models in several domains starting long ao by compiler designers who always wanted to distinguish between syntax, which is different tokens parsed from a source code file, and the semantics, which are the actual operations invoked by that text. Different areas use the syntactic-semantic model of human behaviour, such as programming, database manipulation facilities and direct manipulation (Shneiderman, 1980, 1981)
Example
The difference between the two models can be seen when comparing a command based system (UNIX) to a GUI environment (Windows). The task to copy or move a file from one directory in UNIX is different than in Windows. In UNIX the action of copying is specified first and then object. In Windows the object is first selected then the action of copying is applied.
The Object Action Model is also used in a real life environment. If you want to move a file from one folder to another you will first select the file and then move it. You cannot choose the action of moving and then select the file.
Principles
Syntactic Knowledge
Definition: Syntactic Knowledge means the prior knowledge the user is needed and must be memorized before he is able to use the certain system efficiently.
Example: A user can use programming language efficiently if and only if he knows a good deal of commands and syntax specific to this language.
Syntactic Knowledge will have the following drawbacks:
Drawback1:
Description: If the system is complex, a novice user is difficult to trace the system and the user will be confused because the system can not provide the hierarchical or modular structure.
Example: A user is trying to use a mail system which has several modes of terminations: ENTER to terminate a paragraph, CTRL-D to terminate a letter, CTRL-C to cancel a letter, CTRL-Q to quit the system and so on
-> A novice user might be confused by different modes of operations
Drawback2:
Description: A considerable memory load is required from the user. Since the memory load of a human is limited, it is hard to retain over time unless the knowledge is applied frequently.
Example: commands for "CMD"
copy: copy the file to another location
cls: clear the screen
color: modify the background color
del: delete the file
...
->the command can be thousands or millions, the user can not memorize all commands very quickly
Drawback3:
Description: The knowledge could be independent in different system; it is hard to apply the previous system knowledge to the new one.
Example: in windows, ctrl + c is set to copy the file and ctrl + v is set to paste the file; but in Mac OS, command + c and command + v are used to copy and paste the file respectively.
OAI Model
Background:
In the design of cognitive psychology applied in HCI (Human Computer Interfaces) studies, it can not be separated from the patterns of use. This is because when using a particular CHI (Computer Human Interface) and having difficulties, the user asks for help from different resources, resulting in psychical and social environments must be used under computer and information technologies, this awareness can be defined as situated action and distributed cognition.
->OAI model tries to combine both situated action and distributed cognition approaches and this is called Object-Action Interface Model
The figure above shows the designer mapping from real world universe and intention to the interface of metaphors and plans.
For example: consider a user who needs to write a business letter using word processing software on a computer
High level task action - concept of writing a letter
High level task - letter production
High level task object - the letter
Interface object - the letter will be stored as electronic document
Interface action - know the details of using commands: "new", "save", and etc
Low level task object - using spelling characters to form words / sentences
Low level interface object - know where the keys are from the keyboard or how to use the mouse
Task hierarchies of objects and actions
Tasks are composed of objects and actions at high and low levels. Not all users will find these hierarchies to be perfect, but since they are comprehensible, a great deal of usefulness is provided.
User
Dividing complex tasks into sub-tasks and solving the sub-tasks independently has been shown to be a successful way to solve larger complex problems. Most real world objects and entities involve the use of this property of creating sub-tasks to create a plan of smaller action steps. People learn tasks actions and objects within their lifetime and realize that the process is simplified greatly, when managing different smaller levels within a hierarchy. Issues of implementation are not considered as much when executing tasks using this method.
Designer
Three steps are suggested by Ben Shneiderman, the creator of the 8 golden rules of interface design, for designers to correctly build a task hierarchy.
1. Know about the users and their tasks (Interviewing users, reading workbooks and taking training sessions) 2. Generate hierarchies of tasks and objects to model the users' tasks 3. Design interface objects and actions that metaphorically map to the real world universe
Interface hierarchies of objects and actions
This hierarchy is similar to task hierarchy, since it also contains hierarchies of objects and tasks at different levels.
Interface Objects
Users that interact with a computer system are exposed to high level concepts relevant to that system. These high level concepts include, but are not limited to: files, menus, buttons, pop-up boxes etc.. They acquire exposure to the properties of the objects and how manipulation of its properties can shape the use of the object. Through this experience, they achieve a basic understanding of how to perform actions and accomplish the tasks.
Interface Actions
These are also hierarchies of lower level actions which can be performed on objects relevant to the domain of computers as set out in the interface objects hierarchy. There are three levels of decomposition within the hierarchy. A high level plan might be to create a text file, which could involve mid-level actions such as creating a file, inserting text into that file and saving that file. The mid level action of saving the file can be decomposed into lower level actions like creating a backup copy and setting the access control rights of that file. More lower level actions might include naming the file, the location the file is stored, and dealing with errors such as space shortage and so on.
User
Users can learn interface objects and actions in several different ways such as demonstrations, sessions or trail and error sessions. Once these objects and actions depict a logical structure that the user can relate to other tasks objects and actions, the user is more likely to remember and implement this knowledge in the future.
Designer
Designers use the OAI model to understand the complexity of the processes that the user has to perform in order to successfully use an interface to perform a certain task. Designers model the interface actions and objects based on familiar examples and then adjust and fine tune these models to fit the task and the user.
Limitations and Challenges
Metaphor Interpretation
Each user's way of performing a task may vary. Defining steps completely with metaphors creates risk in the varying interpretations of metaphors amongst different users. Designers of object-action models must consider the wide range of interpretations that are possible when deciding on metaphors for an object. If there is a serious difference between the designer's interpretation and the user's interpretation of the metaphor used, the meaning of the model will be lost. In this case, all the work done to create the model will be lost and the user will be unable to perform the desired task with the interface.
Batching and Pipelining
Users of UNIX and other command line based systems may find that their usual actions of processing large amounts of similar data in one step more difficult in a OAI system. Using a model that focuses on the hierarchy of steps on one object causes this difficulty. Users of a OAI interface are encouraged to perform a series of actions on one object or one action on a series of objects. This somewhat rigid and unforgiving style used by the model can be limiting to some users. It becomes difficult to perform a specified set of actions to a specified set of objects. In command line interfaces, performing some set of actions on some set of actions is easily performed with pipe lining.
Adapting to Change
Users usually experience some difficulty in performing previously mastered tasks on a new interface system. Performing a task on a system becomes highly dependent on the user interface for most users. Changing the interface used in a task without changing any part of the task performed may cause some stress and difficulty. Users must relearn how to perform this task on the new interface as if it is a commonly performed task on another system. This relearning effort and time must be considered whenever an interface system involving metaphors, such as OAI interfaces, are being added, deleted, or changed.
References
- Amir Khella, Object Action Interface Model
