O’zaro ta’sirli interfeysni loyihalashda hisobga olinishi kerak bo‘lgan operatorning asosiy xususiyatlari

2.5 Model-based UI Design in Multi-Device Contexts
Models are abstractions of real entities. We use models in our life more often than is generally acknowledged. For example, often in the morning we think about the main activities to carry out during the day, thus creating a model of the day.
In model-based approaches the basic idea is to use languages that describe the main aspects in conceptual terms in order to allow designers and developers to concentrate on the main semantic aspects and avoid having to learn a plethora of implementation languages. In this way it is also possible to link semantic information and implementation elements. We are referring here to the interaction semantics, which define the purpose of the user interface elements. This makes it possible to obtain device interoperability through many possible implementation languages because through implementation generators it is possible to derive various adapted implementations from logical descriptions. One further advantage of more semantic descriptions is that they facilitate support from assistive technology since the purpose of each element is more clearly defined.
The community working on model-based approaches has agreed in identifying a number of abstraction levels that can be considered when describing interactive applications, they are:
Tasks and domain objects: At this level the purpose is to describe the activities that should be performed in order to reach the users’ goals and the objects that need to be manipulated for this purpose. An example of concept at this level is “I want to select a work of art”. Notations that have been used to represent this type of description are ConcurTaskTrees (Paterno, 2000) or GOMS (John and Kieras, 1996).
Abstract Interactive Application: At this level the focus moves to the interactive part of an application and aims to provide its description in terms independent of the interaction modality used. An example of concept at this level is “Single selection object with high cardinality”. There is a need for an interaction object able to achieve this effect without specifying any detail that is modality-dependent; thus it is not indicated whether the object should be selected through a graphical interaction or a vocal command or a gesture.
Concrete Interactive Application: The description is modality dependent but independent of the implementation language. A concept example is “List Interaction object with X elements”. The assumption is that a graphical modality is used and a list element is required. However, such a list element can be obtained in various implementation languages.
Interactive Application Implementation: Here we have the actual implementation in some implementation language. Thus, for example the List object can be implemented in a toolkit for Java user interfaces (e.g. AWT) or HTML or other user interface libraries.
Figure 10 shows a small example of a multi-device user interface obtained through a model-based approach. In the top left part there is an abstract description consisting of a group of two elements, one for making a choice and one for providing a value in a range. Then, we can see three possible implementations for a mobile device, a desktop, and a domestic appliance. The choice is implemented through a radio button in the mobile device, two buttons in the desktop, and a switch in the physical appliance; while the value in range is obtained through a slider in the mobile device, a spin-box in the desktop device, and a lever in the appliance.

Figure 2.10: Example of model-based description of multi-device user interface
Currently there is a working group on model-based UI in W3C that is developing standards based on these concepts (see at http://www.w3.org/2011/mbui/). In addition, such concepts have proven to be useful for accessibility. Indeed, recently another group in W3C, the Independent User Interface (IndieUI) group, has been set up (http://www.w3.org/WAI/intro/indieui). It aims to make it easier for web applications to work in a wide range of contexts — different devices, different assistive technologies (AT), different user needs. Figure 11 shows an example of how an application can manage an event (Scroll Down) in a way independent of how it has been actually triggered from different technologies.

Figure 2.11: Example of abstract event
One issue with model-based approaches is that the development of the models sometimes has requirements that designers cannot address. To partially solve this problem reverse engineering approaches and tools have been developed. The basic idea is that such tools are able to analyse the user interface implementation and build the corresponding underlying model. An example is described in Bellucci et al. (2012) in which the tool presented is able to analyse Web pages, including the associated stylesheets, and build the corresponding logical description in such a way as to preserve the original scripts. One of the most engineered model-based languages is MARIA (Paterno et al., 2009), which includes: support for Data Model useful for specifying the format of input values, association of various data objects to the various interactors; an Event Model, which associates each interactor with a set of events that can be either property change events or activation events (e.g. access to a web service or a database); a Dialogue Model, which specifies the dynamic behaviour (what events can be triggered at a given time). The dialogue expressions are connected using CTT operators in order to define their temporal relationships; the ability to support user interfaces including complex and Ajax scripts able to continually update fields by invoking external functions, which can be implemented as Web services, without explicit user request; and dynamic set of user interface elements, which can be obtained through conditional connections between presentations or the possibility of changing only a UI part. It is notable that HTML 5 is evolving in the same direction by introducing a number of more semantic tags (such as navbar, article, etc.) which provide more explicit hints of the purpose of the associated elements. However, HTML 5 is mainly limited to graphical, form-based user interfaces. Thus, it is not able to address the increasing availability of various interaction modalities.
MARIA is also supported by an authoring environment, MARIAE (the MARIA Environment, publicly available at http://giove.isti.cnr.it/tools/MARIAE/home), which provides a graphical direct manipulation support to edit interactive applications at various abstraction levels and generate the corresponding implementation for various platforms, also using different interaction modalities. Figure 12 shows how the tool supports editing a logical description; on the left is the interactive tree representing the structure of the application, in the central area we have the graphical representation of the selected presentation with the possibility to drag-and-drop the relevant elements dynamically shown on the right.

Figure 2.12: The MARIAE Authoring Environment