LAS NTICS COMO MATERIA EN LA ESCUELA DE

faces

Like all approaches in the related work, the XSS Framework is currently limited to macro scripts as well as to distributed applications where each learner is provided with a separate device. Con- sequently, the XSS Framework does not support shareable user interfaces, which can be valuable tools for collaboration. To overcome this limitation an extended XSS Framework is envisioned. The vision comprehends general ideas rather than an elaborated concept.

3.5.1

Scope of the XSS Framework

The XSS Framework analyzes collaboration scripts on amacro leveland generates parts of dis- tributed applications. Therefore, it currently neither supportsmicroscripts nor the development of applications running onshareableuser interfaces.

The limitation to macro scripts was already addressed at the end of section 3.3.2. IMS-LD doc- uments exported by MoCoLaDe define scripts on a macro level (task sequence, role distribution,

3.5 Towards an Integration of Shareable User Interfaces 55

group formations and the like) but there is no specification of the micro level. Therefore, the automation of the XSS Framework is restricted to the general structure of scripted collaborative learning applications (as illustrated in Figure 3.9). The framework only processes predefined lists of phases in each of which learners are asked to engage in predefined activities. Scaffolds on a micro level, which specify how each task should be accomplished (cf. section 2.1.3) and therefore provide the fundamental requirements for the user interface design, are not processed automatically. In Figure 3.9 this would correspond to the design of the content within the white boxes. Therefore, the user interface needs to be (1) designed by educators and user interface designers in a collaborative manner and (2) manually programmed. This limitation can not be overcome without a metalanguage for micro-scripts (cf. Hernández-Leo et al., 2006).

A second major limitation concerns the target devices. The components which are automatically generated by the XSS Framework consist of one client per participant, each of which runs on a personal device. Therefore, the framework supports the development of distributed applications such as the M.U.R.D.E.R. application where each learner has an own laptop. The personal device guides the learner through the phases in a wizard-like manner, which is a very strict form of guid- ance. However, in many situations shareable user interfaces such as interactive wall or tabletop displays can be beneficial - either in addition to or instead of the personal user interfaces. Several benefits of shareable user interfaces have been presented in section 2.3.2. Therefore, the follow- ing section presents a conceptual solution which allows to apply the framework’s functionality to different types of displays.

3.5.2

Vision of an Extension for Shareable User Interfaces

This section presents the vision of a framework, which supports the development of scripted learning applications on heterogeneous displays. In other words, the envisioned framework not only supports personal devices but also shareable devices such as interactive wall or tabletop displays. At first, it is explained how the concept of workspaces can be used for that purpose. Second, some issues are addressed, which the use of different display types as well as the concept of workspaces entail. In the end, there is an outlook on possible framework solutions which could resolve some of these issues.

The Concept of Workspaces

The framework’s functionality could be extended to shareable user interfaces using the concept of workspaces. Instead of providing each learner with a series of screens that are shown on a

personal display, the series of screens could be mapped to apersonal workspacethat is part of a

shared display. This is illustrated in Figure 3.18. The right part shows how multiple workspaces could be arranged on a shared interactive tabletop display. The personal workspaces (dashed rectangles) are located on the edges in direct proximity of their owners. In its simplest form the content of the personal workspace could be identical to the content that would be shown on a personal device (similar to Figure 3.10). The area in the center of the display can be used as

56 3 From Graphical Learning Designs to Scripted Learning Applications

16 MEDIA INFORMATICS

DEPARTMENT FOR COMPUTER SCIENCE

Shared user interface for learner in phase n

personal workspace role 1 person al worksp ace role 3 pe rson al w orksp ace rol e 2 pe rson al w orksp ace rol e 4 Shared workspace interaction between personal and shared workspaces personal workspace

Personal display Shared display

Currently: 1 personal workspace on 1 personal display (1:1) Vision: n personal workspaces on 1 shared display (n:1)

Figure 3.18: From personal workspaces on personal displays to multiple personal workspaces on shared displays.

of the existance of visual demarcations as proposed here (Scott et al., 2004). When no lines of demarcations are shown the personal workspace is defined solely by the proximity to a user and naturally merges with the shared workspace. However, using marked-off workspaces allows to define the content of a workspace (e.g. using a markup language) and flexibly allocate it to different kinds of displays. For instance, a learner’s graphical user interface (cf. Figure 3.10) can either be allocated to a laptop or to a marked-off area on a tabletop display. This choice of the display environment should be made by the user interface designer once the collaboration script is defined. It is the first step of the client user interface finalization.

Issues

The above mentioned concept entails several issues. Some of these issues are caused by the heterogeneity of displays. When workspaces are designed for different types of devices, the dis- play’s characteristics need to be taken into account. First, there are basic aspects such as size and resolution of a display. Second, single- and multi-user devices need to be distinguished. While the display’s orientation does not play a role for single-user displays, it makes a significant dif- ference whether shareable displays are vertically oriented (wall display) or horizontally oriented (tabletop display). In the latter case, the users might not have the same perspective (e.g. Figure 3.10). A third factor is the input technology. For instance, whether input is done with direct touch or with indirect pointing devices affects how users interact with the application. For instance, on interactive tabletop displays not all parts of the display are reachable by all users. This problem does not occur with mice or other pointing devices. Finally, there are different techniques for text input, which also affect the layout of workspaces. When no hardware keyboard is avail- able (e.g. on tabletop or tablet computers) text needs to be entered using on-screen keyboards or handwriting recognition, both of which can occupy large areas of a workspace.

3.5 Towards an Integration of Shareable User Interfaces 57

In addition to the heterogeneity of displays, placing multiple workspaces on a shareable user interface allows for other interaction techniques than wizard-style applications. While in the M.U.R.D.E.R. application the exchange of keywords is automatically initiated by the server be- tween phases, tabletop displays encourage users to move content between workspaces using simple gestures like drag-and-drop. Thanks to a number of different display-reaching tech- niques (Nacenta et al., 2005) such interactions between workspaces are also possible when the workspaces are located on different devices. For instance,Pick-and-Drop(Rekimoto, 1997) al- lows user to pick up digital objects with a pen, move the pen to another display and drop the object there. There are also techniques that work with pointing devices (e.g. Hyperdragging

by Rekimoto and Saitoh, 1999) and thus allow to send objects to displays that are not within arm’s reach. A framework for heterogeneous devices needs to consider such interactions be- tween workspaces. Defining the interactions between workspaces is just as important as defining the workspaces’ GUI components and the interactions within the workspace.

Solutions

The basic version of the envisioned framework could leave the consideration of the above- mentioned issues to the programmer. The framework could simply support the definition of workspace content and interactions and provide the means to allocate them to heterogeneous displays. In this case, the programmer would implement the user interface for a specific target display and the framework could still handle the supported mechanisms. For instance, the frame- work could distribute tasks both across several devices or across several workspaces within the same device.

The more advanced the framework, the more of the above-mentioned aspects could be handled by the framework instead of the programmer. At the end of this theoretical scale is a framework, which allows the user interface designer to define workspace content and interactions in an ab- stract manner. The workspaces would be automatically configured and would also automatically adapt to the display it is attached to. In this hypothetical scenario there would be no need for a programmer. User interface designers could use graphical tools to define workspace content and interactions, similar as educators use graphical tools to define the collaborations scripts.

One step in this direction could be a unified gesture language as proposed by Echtler et al. (2010). In addition, there is research on seamless interaction between heterogeneous devices in the area of Ubicomp (e.g. by Greenberg et al., 2011 and Gellersen et al., 2009). While these approaches provide partial solutions, there are still many open questions. For instance, how do different kinds of workspaces and display environments affect collaborative learning? What are suitable guidance mechanisms for different workspace and display configurations? These questions need to be addressed in order to define the requirements of an extended XSS Framework more com- prehensively.

58 3 From Graphical Learning Designs to Scripted Learning Applications