User-Centered Modeling of Interactive Web Sites

Birgit Bomsdorf
Universität Hagen
Universitätsstraße 1
D-58084 Hagen
+49 2331 789 2962
Gerd Szwillus
Universität Paderborn
Fürstenallee 11
D-33102 Paderborn
+49 5251 60-6624


In this paper we propose a new variant of dialog modeling suitable for the web mod­el­ing 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], how­ev­er, 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 inter­ac­tion el­e­ments 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 under­lying the web site. A sequence of web in­ter­actions is modeled as a sequence of pages through which the user has to nav­i­gate. Hence, each dialog state is represented by a single page and a dialog sequence is de­fined by means of links.

In HCI, on the other hand, there exists rich ex­pe­ri­ence with the modeling of tasks and dialogs to address user in­ter­face (UI) design problems [4] - but the mod­els de­vel­oped within these schools are not directly ap­pli­ca­ble to the web modeling problem. However, to come up with a task-oriented, user-centered development process, inter­action design and feed­back specification must be integral and ex­plic­it 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 ap­proach [3] with the objective to integrate benefits from HCI methods with the needs of web modeling. In the fol­lowing, 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 re­sulting 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 mod­el, 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 spec­i­fy 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 cou­pling between semantically well-defined events (task completion) and the corresponding user interaction el­e­ments on the web site. Overall, aspects of the dialog are cov­ered by components of both WOLM and AWS. The main concepts are described in the following sections.

2.1 Task-Related States and State Transitions

An essential concept of WOLM is the explicit modeling of task objects’ life cycles in terms of states and state tran­si­tions. The different states represent “situations“ or “con­fig­u­rations“ 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 def­i­ni­tion 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 {
        tryLogin(String acc, String pwd) {...}
        (logPossible, logFailed, logPossible)
        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).

2.2 Web-Object Based Presentation

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 oper­a­tions. Currently we distinguish two basic input elements, namely requesting the per­for­mance 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 el­e­ments are shown depending on states defined in WOLM. Hence, the state transition of a WOLM object re­lat­ed to an AWS fragment, can lead to different pre­sen­ta­tions. The top part of the above AWS example shows the spec­i­fi­cation 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 suc­cessfully 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.

2.3 Separation of User Interaction and Link Information

The effect of an interaction element such as a button con­sists of a trig­ger 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 ex­am­ple controller.tryLogin). Second, the Link element specified with the button des­cribes whether the same or some other page is to be dis­played, using the “new” values of the WOLM model for this purpose (in the example the same page should be re-pre­sented, which is indicated by this). Hence, classical hy­per­links 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 spec­i­fied 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 mod­el-based approach. Most tools are currently under develop­ment, some ore done. Emphasis up to now has been on the design and specification of the WOLM and AWS mod­els, and their representation as XML files. A pre­liminary 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 cur­rently 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 personal­ization concepts in current web modeling approaches. The tool environment has to be finalized including the dialog model proposed here.


  1. 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.

  2.  Fraternali, P.: Tools and Approaches for Developing Data-Intensive Web Applications: A Survey. ACM Computing Surveys 31(3), 227-263, 1999

  3. Szwillus, G., and Bomsdorf, B.: Models for Task-Object-Based Web Site Management, Proceedings of DSV-IS 2002 (Rostock, June 2002), 267-281.

  4. Vanderdonckt, J., and Puerta A.: Computer-Aided Design of User Interfaces II, Proceedings of CADUI’99, Kluwer Academic Publishers.