In this paper we propose a new variant of dialog modeling suitable for the web modeling world. It is incorporated within our general web modeling approach which relies strongly on task-modeling as a basis exploited throughout the development
Interactive web sites, web modeling, task based design, user-centered design
Web sites are currently moving from static pages towards highly interactive web sites. As a result, developing web sites has to focus more and more on the design of user interactions. Existing web modeling approaches [2], however, are traditionally following a data centered approach. They focus on the dynamic generation of web pages from data bases, mapping entities to web pages and relations to navigation links. Recent enhancements incorporate interaction elements into the models, frequently by modeling operation calls as side effects of activating links (e.g. [1]). There is no explicit concept in web modeling to deal with the user’s actions to execute a task – user movement is modeled along the information structure underlying the web site. A sequence of web interactions is modeled as a sequence of pages through which the user has to navigate. Hence, each dialog state is represented by a single page and a dialog sequence is defined by means of links.
In HCI, on the other hand, there exists rich experience with the modeling of tasks and dialogs to address user interface (UI) design problems [4] - but the models developed within these schools are not directly applicable to the web modeling problem. However, to come up with a task-oriented, user-centered development process, interaction design and feedback specification must be integral and explicit parts of a modeling technique for interactive web sites, and not an add-on to an otherwise data-oriented methodology.
Currently, we are developing a web design modeling approach [3] with the objective to integrate benefits from HCI methods with the needs of web modeling. In the following, we will refer to it as WOLM (Web Object Life Cycle Model), as this denotes the kernel model of our approach.
The starting point of the WOLM modeling process is a classical task analysis resulting in a task model of the „business“ describing which tasks are performed and which objects are affected. Other than in HCI modeling, the emphasis of this task modeling step is on the task objects rather than on the task hierarchy. The task objects are the objects which are to be represented on the web site (we refer to them in this context as web objects). In addition to capturing the static structure of these objects, their dynamics are specified, i.e. the way in which task execution affects the web objects. Hence, as the WOLM contains clear behavioral semantics reflecting the web object modifications as triggered by the web site user, it reflects the user centered task model.
The web representation is described by an additional model, which is derived from the WOLM by the definition of an Abstract Web Site Structure (AWS). It defines the grouping of information elements onto pages and subparts of pages, and the navigation between these elements, including ordinary links as well as interaction elements on the web pages. The AWS description is abstract, as it does not specify any details about the graphical representation. By means of a declarative specification, we assign the task objects as defined in WOLM to the AWS. Hence, there is a direct coupling between semantically well-defined events (task completion) and the corresponding user interaction elements on the web site. Overall, aspects of the dialog are covered by components of both WOLM and AWS. The main concepts are described in the following sections.
An essential concept of WOLM is the explicit modeling of task objects’ life cycles in terms of states and state transitions. The different states represent “situations“ or “configurations“ a web object can be in. Transitions between them describe the changes a web object undergoes during its lifetime through execution of tasks. To define states and state transitions, a WOLM class specification contains a definition of the state set of the objects (state fields), and rules governing the transition between these states. The state transition triggered by an event is described by a method invocation defining the effects of the transition on the object’s attribute values. The method performance can request input parameters from the user of the WOLM. An example of this is given by the following excerpt of a controller object, being the manager of a login-logout-process:
Controller {
method
tryLogin(String acc, String pwd) {...}
field
(logPossible, logFailed, logPossible)
rule
logPossible –tryLogin-> logSucceeded
...
}
At run time, triggering the tryLogin event in the state logPossible of a Controller object will require the two input parameters (acc and pwd).
Within the AWS, concerning interaction elements, the user’s input possibilities are mapped onto appropriate components, linking the input event to WOLM state transitions and modification operations. Currently we distinguish two basic input elements, namely requesting the performance of an action and providing input data. The AWS example below describes a possible future web page LoginPage, which is linked to the WOLM through the parameter controller, an object reference to a Controller object of the WOLM. The page contains a form, which in turn contains the input fields Account and Password, and a push button named OK, which triggers the method tryLogin of the corresponding controller object. We show this example in an abstracted hierarchic representation with indentation denoting hierarchy levels. Technically, we store this as an XML file.
Page LoginPage (Controller controller)
if (controller inState logPossible)
Form LoginForm
TextInput Account
HiddenTextInput Passwd
Button OK
Action controller.tryLogin(Account, Passwd)
Link -> this
if (controller inState logSucceeded)
Field UserInfo
...
Another important link between WOLM and AWS is given by the fact that different states of objects can be bound to different AWS fragments representing an object. For this purpose the AWS contains condition clauses specifying which elements are shown depending on states defined in WOLM. Hence, the state transition of a WOLM object related to an AWS fragment, can lead to different presentations. The top part of the above AWS example shows the specification for the case of controller being in the state logPossible. Following the second conditional clause, a completely different representation is specified for the state logSucceeded. Hence, once the user has successfully logged in, the appearance changes to a view within which some user information is to be included.
This technique allows the designer to define views, which function similar to concepts as used within HCI. A view in HCI specifies groups of related task to match the mental model of the user. A page in AWS also groups related task; the modifications occurring within such a view are modeled by WOLM while the corresponding changing representation is described by the AWS.
The effect of an interaction element such as a button consists of a trigger of semantic changes and the display of a new page. In the co-operation between AWS and WOLM, this is modeled as follows: First, the activation of a “button” element can trigger a state transition of a WOLM object, referred to as an Action element (in the above example controller.tryLogin). Second, the Link element specified with the button describes whether the same or some other page is to be displayed, using the “new” values of the WOLM model for this purpose (in the example the same page should be re-presented, which is indicated by this). Hence, classical hyperlinks are modeled as well as the effect of interaction elements. In contrast to ”traditional“ dialog modeling, the aspects of the user interaction context and its effect are separated: The perceived context of an interaction is specified in the AWS, and the effect is specified in the WOLM kernel. This separation makes sense, however, because of the ambiguous character of hyperlinks in the web modeling case.
We are currently realizing a tool environment for our model-based approach. Most tools are currently under development, some ore done. Emphasis up to now has been on the design and specification of the WOLM and AWS models, and their representation as XML files. A preliminary version of an executable model has been developed and is working. It allows the simulation and testing of the model and is the basis of the runtime system of the web application. Concerning language definition and evaluation we are currently applying the concept to realistically sized web projects, such as an on-line auction and a grammar school site. Up to now, we have worked on verifying the general feasibility of the approach. There are things left open such as the support for different user roles co-operating on tasks, similar to the personalization concepts in current web modeling approaches. The tool environment has to be finalized including the dialog model proposed here.
Bongio, A., Ceri, S., Fraternali, P., Maurino, A.: Modelling Data Entry and Operations in WebML, Proceedings of WebDB 2000, Lectures Notes in Computer Science, Vol. 1997, Springer Verlag, 201-214.
Fraternali, P.: Tools and Approaches for Developing Data-Intensive Web Applications: A Survey. ACM Computing Surveys 31(3), 227-263, 1999
Szwillus, G., and Bomsdorf, B.: Models for Task-Object-Based Web Site Management, Proceedings of DSV-IS 2002 (Rostock, June 2002), 267-281.
Vanderdonckt, J., and Puerta A.: Computer-Aided Design of User Interfaces II, Proceedings of CADUI’99, Kluwer Academic Publishers.