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

2.2 User Interface/Task/Platform Relations
In this section we discuss a logical framework that allows designers to think about the various possible relations between the tasks to perform, the user interfaces, and the platforms available. By platform we mean groups of devices that share similar interaction resources, e.g. the desktop, the smartphone, the tablet. In particular, we have identified five possible relations:
Same task with the same user interface on different platforms
Same task with different user interface on different platforms
Same main task with different levels of subtasks on different platforms
Dependencies among different tasks performed on different platforms
Tasks meaningful only on some platform types (e.g. because they require very lengthy access or are related to a mobile position or to specific equipment such as a camera).
Because of the rapidly expanding variety of mobile technology there are indeed significant differences between different platforms. The consequence is that sometimes for the same task different user interfaces are more appropriate depending on the platform, and some specific tasks are only really appropriate for a specific platforms. For example, watching a football match does not make sense through a smartphone, even if this is technically possible, since the small screen is inappropriate for a ninety minute period and many details of the match could not be appreciated. On the other hand, this is a pleasant activity to carry out while comfortably sitting on a sofa with a large screen in front of you at an appropriate distance.
Figure 2 shows an example of the same task with different user interfaces on different platforms. The task is showing spatial information. On the left there is the version for a desktop device, which covers a wider spatial area and also provides an overview highlighting where the detail view is located. On the right, the version for the mobile device highlights the current position of the mobile user, showing a smaller area with touch control for changing the zoom level.


Figure 2.2 A-B: Example of same task with different user interfaces
Figure 3 shows a second example of the same main task with different user interfaces, , and some different subtasks. In this case the main task is to show the information regarding the flights of an airline. We can notice that both UIs support the possibility of searching flights and making reservations, but through different presentations and layouts; in the mobile version the interactive elements are larger to facilitate touch interaction; in the desktop version there is also the possibility of accessing additional information, e.g. regarding promotions.


Figure 2.3 A-B: Example of same task with different user interfaces
The next figure shows two examples of applications in which the mobile version supports some tasks that are meaningful only for that platform. At the top, an example search with the keyword ‘restaurant’: the mobile version shows a set of nearby restaurants on a map and in a list, in which each element has a button to initiate an immediate phone call to the corresponding restaurant. At the bottom on the right side we can see how the mobile version of Flickr makes it possible to show pictures that were taken near the current mobile position.

Figure 2.4 A-B-C-D: Example of tasks meaningful only on some platform
2.3 Authoring Multi-Device Interactive Applications
Authoring multi-device interactive applications requires changing the traditional ways to develop interactive applications. There are various ways to address this. The simplest way is to develop separately specific versions for each target platform. In this way the developers have full control over the specific aspects of each version. However, this means multiplying the effort of developing an interactive application by the number of target platforms. Thus, it implies more effort in development and maintenance. Indeed, if something has to be changed in the application then each version needs to be updated.
Another approach consists of developing one main version with fluid layout and subversions. This is what happens with responsive Web design, in which the authors implement liquid layouts and use media query support to identify different types of devices. For each type identified they provide stylesheets through which they can change the values of some attributes or show or hide some elements. This can be a relatively cheap way to address the problem, but it can limit the differences among versions that can be obtained in some cases, since stylesheets do not allow deep changes in the structure of the interactive applications.
Another approach is single authoring, in which one conceptual description of the interactive application is developed, from which various versions optimized for the various target platforms are obtained. One further solution is automatic reauthoring, in which the starting point is the implementation for a specific platform, and then derive implementations adapted for different platforms through appropriate transformations.
In the research community various solutions for this purpose have been proposed. An example is SUPPLE (Gajos, Weld, and Wobbrock, 2010). , which takes a functional specification of the interface, the device-specific constraints, a typical usage trace, and a cost function. The cost function is based on user preferences and expected speed of operation. SUPPLE’s optimization algorithm finds the user interface, which minimizes the cost function while also satisfying all device constraints.

Figure 2.5: The SUPPLE Environment (Gajos, Weld, and Wobbrock, 2010)
The SUPPLE authors then focused on how to exploit SUPPLE in order to support disabled users, for example, by automatically generating user interfaces for a user with impaired dexterity based on a model of her actual motor abilities. More generally, we can consider adaptation useful for both permanent and temporary disabilities. An example of temporary disability is when the user has to move fast and interact with a graphical mobile device. Thus, the user’s visual attention cannot be completely allocated to the interaction
One of the first approaches to authoring multi-device user interfaces is Damask (Lin and Landay, 2008), which supports authoring for three types of platforms: desktop, smartphone, and vocal. Damask is based on three aspects: sketches, layers, and patterns. Sketches are used to indicate easily what the user interface should look like. Layers indicate whether a user interface part should be allocated to all devices or only to one specific platform. Patterns are used to identify solutions to recurring problems in order to facilitate their reuse across different applications.

Figure 2.6: The Damask Authoring Environment (Lin and Landay, 2008)