The design of User Interfaces involves a process of gathering tasks (i.e. they are used as building blocks in order to describe the goal pursuit by the software application). Task hierarchies are abstract representations. Therefore, they are translated into more physical structures. The arrangement of these structures is not a trivial process in most of the cases. Applications are distributed over a certain number of containment structures due to temporal, spatial and cognitive load limitations. Instead of reducing these constraints to mere boundaries is possible to extract relevant information that could guide our designing process. For instance, if the container generation is aware of platform requirements in early stages of development, then it could prevent the rupture of related task groups (or the gathering or unrelated ones). In this paper we tackle these problems taking into account the semantic information coming from a neutral description of the UI, applying a set of rules based on heuristic knowledge of the relationship between operators and the introduction of a metric for weighting abstract containment structures.

The design of a UI in the Web domain implies the division of the application into Web pages. Each one covers some tasks of the application. However, the page metaphor is moving to the Single Page Application approach (SPA) [17]. In this kind of web applications, the behavior and content of a single web page is changed though dynamic modifications of the Document Object Model (DOM) that represents the web page. That is, SPAs need to deal with container structures which are dynamically transiting from visible/focused to invisible/unfocused status. For instance, there are many item-grouping libraries in the GUI world (e.g. Java layout managers). These libraries follow a general schema that we depicted in fig. 1: First, we have a frontier-component that serves as a foundation canvas for the application. Second, an undefined number of containment elements following an initial order of presentation. They are ordered but they can be presented to the user in a rotation of states from visible/available to invisible/non available.

The rest of this paper is organized as follows: Section 2 discuss the state of the art in the creation of containers. Section 3 introduces some theory in Task models and model driven engineering domains. Then Section 4 covers the description of our method. And finally section 5 presents conclusions and future work.

The difficulties that arise when you design containers include: First, how to solve the problem of distribution the UI over the available physical space since the size of the view is finite and as a consequence (in the non trivial UIs) we have to divide the UI in multiple views, this issue is treated in [1,4,8]. Also this perspective tries to solve the container problem in terms of available space (i.e., geometrical constraints [15,21] or more general restrictions [12]); the nature of the problem is NP-complex [8]. Second, how to determinate the acceptable frontier points that should be respected to create a coherent hierarchy of views. This process requires more knowledge (over the simple layout structure that is treated as proposed in [9,10,14] but with limitations in the recovery of information over the physical restrictions) to avoid grouping unrelated elements or breaking groups. The place to get this information in the following papers is a meta-description of the UI that is built in terms of a set of tasks: a task model. In [3,5,13,20] is created a hierarchy of widgets to define in a device independent way the UI and use a bottom-up algorithm that is based in the condition of "splittable" or not of the nodes (The nodes of the tree can be labeled as splittable or un-splittable) and from there looking for the highest ancestor of the node and the resultant sub tree is marked as a page. Nevertheless, the process does not include temporal information from the task model and the division point is defined in a fixed way. In [18] the idea of using the task model is explored but in this case the temporal operators are key elements to provide information of how divide and create the containers. The task model is traversed in a Breadth-first search and through a set or principles proposes the way of reducing the UI from the less constrained platform to display it in devices with fewer capabilities in a process called "graceful degradation". In order to create the containers in [19] again the starting point is the task model and the relationship between tasks is extracted from the information enclosed in the domain model besides the identification of tasks related to fulfill user goal and supplementary tasks. In [13] temporal operators are used to propose a presentation where tasks that should be enabled at the same time are grouped in two sets: first and body. Here, the relevance of the so called first action is over-valuated while in the proposed algorithm the weighting metrics are based on more parameters (specifically, task types and operators besides the inclusion of the knowledge of the allowed deepness of hierarchies in a specific technology). The last container generation method is part of [20] which does not worry for space constraint because is oriented to discover and use the relationship between tasks and subtasks to create device-independent UIs. Also, there is work developed in this area focusing the problem as an optimization task [2,6,7] in our proposal we are using some heuristics based in the notion of strong repercussion of the temporal operators that are used, this is also present in [13,20]. This paper proposes as solution in the next section: a model-based approach in order to create a feasible mapping between the finite layers and the task decomposition [13,18,19].

Our methodology is supported by a Model driven engineering approach (http://www.omg.org/). We are going to present its core elements: the CAMELEON framework [22], UsiXML [20] and the CTT task model [13].

The design of UIs using a model based approach that includes features as Multi-level abstraction and Modality independence [16] requires the use of a framework to deal with the complexity of the process. We are using the CAMELEON framework [22]. This framework divides the development process in four successive levels of abstraction: Task and concepts (T&D), Abstract User Interface (AUI), Concrete User Interface (CUI) and Final User Interface (FUI). The UI is represented in the User Interface Description Language, UsiXML (UsiXML which stands for User Interface eXtensible Markup Language). This language provides the representation of the UI in the four levels of the framework, in a design independent way and over multiple contexts e.g., Character, vocal and Graphical User Interfaces among others.

The Concur Task Tree model (CTT) is a well known technique in Computer-Human Interaction to model an application in an independent platform way. The task model of UsiXML is implemented through CTTs. The objective of this model is to explain the work that the user pursuits as a hierarchy of tasks where each task is decomposed until arriving to basic tasks. The description below is very brief and a more detail description could be found in [13]. The sibling tasks (denoted as T) are related to each other through the following binary and unary operators: Concurrent Operators: These operators imply that T1 and T2 are performed in any order, in a concurrent order:

The following section describes the proposed method to generate Web UI containers. Before going any further, we have to introduce some concepts: A level is a set of tasks recovered by an exploration of all nodes adjacent to the current task node in a breadth-first search. The root by definition is the first level. Also we have to define the concept of layer which is a set conformed by each containment element that belongs to the same parent container e.g. in the right side of Fig. 1 are shown a UI with four layers.

In order to clarify the explanation a case study is presented (see Fig. 2). A sub-tree will be updated after each step of the method.

The first step is the identification of levels (see Fig. 3). The case study includes eight levels (according to the given definition). Then sub-trees are created using as parameter the number of layers acceptable in the target platform. The procedure is as follows. The algorithm starts a bottom-up climbing of the tree searching the parent node at the nth layer. The starting point, called anchor node (see Fig. 3a) is the deepest and the most left positioned leaf node (in order to respect any possible sequence operator).

After that the procedure is repeated. The anchor node is relocated and the climbing restarts until it reaches the root node. The final product is a sub-tree called from now on: virtual container (VC). A formal description of the algorithm is presented in Fig. 5.

The definition of layers is done in terms of heuristic notions. Most of platforms do not impose a fixed nor static number of layers then we have to define an approximated value. For instance, in Fig. 4 the possible number of layers of four devices is presented as a guide to the designer. Next we present the result for the case of three layers in Fig. 6 (in this case the procedure delivers four containers).

The second step is the evaluation of the internal structure of each container. This in turn provides us with the required information to generate the hierarchy of inner containers. This process is based on the generation of abstract containers [20] and we have to remember that the root task since is an inner node is marked as container not as a work to do (for instance, get or retrieve a value). Now in order to reduce the complexity of the process we are going to mark each level as a set of inner nodes if any sibling is a branch parent (e.g. Fig. 7, sections 7a and 7b are inner nodes), otherwise they are marked as leaves (see Fig. 7c).

Then ( 1) is applied to each set of nodes (for instance Figs. 7a to 7c). Let I and L denote the sets of inner and leafs nodes, respectively. Let op denote the operator set formed by {C, F, and S} Where C is the set of all concurrent operators. F is the Selection operator and S is the set of sequential operators. Let T denote the analyzed task set. Finally, let n denote the amount of generated containers.

Without the presence of any restriction the number of configurations to generate is equivalent to the problem of location of elements in a set of boxes (see Bell numbers algorithm). For instance, the hypothetical VC from Fig. 8a with three concurrent tasks (A, B and C) has six possible containment configurations according to (1). This process is presented as a formal algorithm in Fig. 9. Now consider the VC (Fig. 6d) of the case study and in this situation is possible to deliver three configurations (see Figs. 10, 11 and 12). Another point of interest is the process of propagation of the control widgets e.g. the "close task" that is member of the first container (Fig. 6a). This task should be available in all the UI then it should be propagated. The process is straightforward: the task is integrated to each children container (see Fig. 10a). It is important to remember that inner nodes as ChangeBMDetails in Fig. 10b are removed but her name should be propagated in their children containers (e.g, container 10c could be named ChangeBMDetails.showBMParameters in order to preserve information of the task hierarchy).

After the generation of the container structures comes a weighting process, based on the values of table 1. Once again the process involves exploiting semantic information (now from task types and operators). Then we count all the exposed items of the container (leaf task and operators) using a breadth-first walk while the inner containers would be seen as black boxes and dismissed in order to apply (2).

It is worth noting that weight values are based on heuristics notions of the importance and complexity of the task types and operators and it is a pending task an evaluation of current values (as well as the layer weights). Now, it is presented in Fig. 13 Now, we have to present to the designer the most suitable configuration and for that we are going to use a classic metric, the weighted average. Then, the configurations with lower cost are presented to the user. The weights are related with the number of layers that previously we have defined as constraint of the VC containers. Finally, according to the result of table 2 we should suggest our user/designer the configuration C2 (Fig. 11). The process of transformation from task model to AUI is out of the scope of this paper since it is discussed in [3,20].

The method at this point could deliver three AUIs connected with navigation elements. For instance, the way of connected the UIs could be seen more clearly in the problem of the fragmentation of the sub tree depicted in Fig. 6e, there the task Update is a sub task of an upper tree besides it is the root node of other container. Then, the approach taken to resolve this situation is the introduction in the upper container of a navigation component pointing to the lower one. A fundamental consideration is the fact that the proposed method (for the moment) is not looking optimization. Instead of that it wants to provide the designer with plausible scenarios.

In this paper we have presented an alternative method for the semi-automatic generation of the hierarchy of containers that compose a UI. This method is based on the recovery of semantic information extracted from the tree structure and the operator types. The data is extracted from the topology of the tree and the operators interacting with the tasks. The result is a feasible UI well balanced over the layers also flexible enough to allow the developer select alternative configurations. This method could help in fast prototyping as well as in exploration of news containment dispositions. Additionally, this method is platform independent since we only deal with an abstract definition of the UI. Finally, we are going to explore the integration of the algorithm into an editor tool in order to make extensive tests.