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

2.4 Adaptation Rules
How user interfaces adapt to the context of use can be described through rules that can be classified according to the types of effect that they can achieve.
Some adaptations consist of replacement rules: they indicate how to replace some elements according to the current platform. The elements to replace can be single user interface elements as shown in Figure 7. At the bottom we can see an application for accessing train timetables that on the desktop version supports the hour selection through a long drop-down menu while in the mobile version uses a radio button with a limited number of options since the possible hours are grouped.

Figure 2.7: Examples of replacement rules for single elements
Figure 8 shows how a replacement rule can be applied to a group of elements instead of single elements. In this case the grouping refers to query results concerning hotels for a given location. The desktop version (left) shows the results group in such a way as to provide additional information (such as comments from previous visitors), while the mobile version (right) shows details only on request, through elements that can be easily selected by touch.

Figure 2.8: Examples of replacement rule for a group of elements.
Another type of rule is splitting the user interface into two or more separate presentations. The new interfaces can be obtained in two ways: either by performing the creation of separate user interfaces or by dynamically showing and hiding the elements in order to achieve a similar effect. Figure 9 shows an example of page splitting. It refers to the well-known PacMan game: on the left is the single page presentation, on the right the version for small screens in which there are two presentations: one for playing the game and one for defining various settings.

Figure 2.9: Example of page splitting
In other cases adaptation needs removal rules. The purpose is removing content considered irrelevant for the target device. There can be various reasons for this: technological limitations or manufacturer choices (e.g. iPhones do not support Flash videos); objects removed because too expensive in terms of resources consumed in the new device; elements supporting tasks considered irrelevant for the target device. It is important to remember that removing elements can have an impact on script execution because they can refer to them, and if they are removed then the scripts may not work properly.
The most used adaptation rules are those aimed at changing some user interface properties. In this case the UI elements are the same but their presentations change in terms of: their attributes (e.g. colour, size, etc.): their position in the UI; space between them; overall user interface structure.
The adaptation rules can be expressed in the format: Event / Condition / Action. The event occurrence triggers the evaluation of the rule. Elementary events occur in the interactive application or in the context of use, or a composition of such events. The condition (optional) is a Boolean condition to be satisfied in order to execute the associated action(s); it can be related to something which happened before, or some state condition. The action indicates how the abstract/concrete/implementation description of the interactive application should change in order to perform the requested adaptation. It can change the user interface at different granularities: complete change of UI, change of some UI parts, change of UI elements, or change of attributes of specific UI elements. Here are some examples of adaptation rules:
Event (the user has selected the link to a printer description); condition (the user has selected more than three links to printer descriptions); action (show the five most sold printers)
Event (change of battery level); condition (if the battery level is below a given threshold); action (change screen brightness)
Event (user accesses application); condition (the user is elderly); action (increase font sizes 10%)
Event ((user is outdoors) and (it is lunch time)); condition (there are restaurants nearby); action (show list of nearby restaurants)
Event (application accessed); condition (the device is a mobile phone); action (show master and detail in different presentations)
If we want to consider applications in which accessibility is an important aspect we can have different examples of adaptation rules (Minon et al. 2013):
Event: the noise of the environment changes to a value over 25 decibels; Condition: the user has a mild hearing impairment; Action: all videos must display subtitles.
Event: the user accesses an application with many interaction elements; Condition: the user is blind; Action: an application table of content is created for easy access to each interaction element.
Event: the user interface is activated; Condition: the user is colour-blind; Action: change the foreground colour to black and the background colour to white in order to provide a high-contrast UI.
Event: the UI contains an element with a timeout; Condition: the user has a cognitive disability; Action: remove the timeout or increase the time limit considerably if necessary.
Event: the user interface is activated; Condition: the user has poor vision; Action: activate a screen magnifier.
Event: the user begins to move; Condition: the user has paraplegia and the UI is not rendered with the vocal modality; Action: the user interface is changed to the vocal modality
Event: the application contains many different interaction elements for performing different tasks at the same time; Condition: the user has problems in maintaining attention; Action: the UI is organized in such a way that only one task is supported at a time
Another important aspect to consider is that applications running on mobile devices have often to adapt to contextual events. Thus, there is an increasing interest in proposing environments that allow even people who are not programmers to define their context-dependent applications. Tasker (footnote 1) is an Android app that allows users to perform context-sensitive actions based on simple event-trigger rules. The user can create the context-sensitive rules in terms of tasks (sets of actions, which can be alerts or applications to activate, audio or display properties to change, ... ) executed according to contexts (that depend on aspects such as application, time, date, location, event, gesture, state) in user-defined profiles. Although Tasker is still limited in terms of types of application that can be developed, it is a start nonetheless and moreover demonstrates the utility of this type of contribution. Locale (footnote 2) is another Android app that allows users to create situations specifying conditions under which the user’s phone settings should change. An example of a rule that can be implemented with such tools is: after 4 pm if the battery level is less than 20% and WiFi is active then disable WiFi and decrease the screen luminosity.