Issue
Article
Vol.30 No.4, October 1998
Article
Issue
Issue |
Article |
Vol.30 No.4, October 1998 |
Article |
Issue |
Developing user interfaces is no more a mere technical software development task; successful user interface design has to be interdisciplinary, taking into account other aspects, such as psychological, social, organisational, and cognitive aspects. It is generally accepted that the tasks, the user has to fulfil with a system to be developed should play an important role in its design. Knowing the user's tasks enables the designer to construct user interfaces reflecting the tasks' properties, including efficient usage patterns, easy-to-use interaction sequences, and powerful assistance features.
As a consequence, task modelling becomes a central part of the user interface design process. To accomplish this a systematic transition has to exist from task identification to user interface construction.
Currently the transition from task model to dialogue model is a challenging and relevant topic. The objective of the workshop was to bring together people with expertise in this domain in order to collect, structure and interrelate work dealing with this non-trivial transition. The purpose was to discuss practical design projects dealing with the transition from task model to dialogue model, research on theoretical, systematic approaches to the problem, and developments of tools and techniques supporting this transition.
The workshop participants, including the two organisers, formed a group of 18 people from Europe and the United States, with varying background, perspectives, and experience. A complete list of the participants is available on the workshop web site (URL at the end of the paper). Also the position papers submitted were (and are) available on the Web to be read by the participants before the conference.
The organisers started the workshop with a short introduction of themselves and a presentation of the workshop topics. Based on the position papers they proposed definitions of models used within the various approaches. The objective was to define a common language among the participants to be used within the workshop.
Afterward the participants were given the opportunity to present their relation to the workshop topics, such as research work done, mere interest, or practical experience and insights. In addition, they were asked to give a short overview of their approach to task based user interface design in terms of the given models and definitions.
One purpose of this workshop phase was to establish a group consensus of the problem under discussion; another purpose was to learn at least something about everybody's standpoint, discovering similarities or contradictions between the participants' experience.
After this phase the organisers presented a set of subtopics to be discussed -- from their own experience in the field enriched with topics extracted from the position papers. From this set the group selected two main points `Techniques, Methods, and Concepts in Practice' and `Models and their Properties' to be discussed in subgroups. At the end of the workshop the results of each subgroup were reported and discussed within the whole group. This was followed by a final discussion about the workshop results.
The participants used more or less different approaches and models in the field of task based user interface design. However, there are some common concepts: Within most of the presented approaches a task model of the current work situation is defined. This is described in terms of hierarchical structure of the tasks, temporal ordering, pre- and post-conditions, objects used within tasks (domain objects) etc. Based on this an envisioned task model is defined of how the users performs their tasks with the future system. This is formulated using the same concepts as in the first task model, in addition showing the division of labour between user and system. From this a model of the user interface is constructed, a constructive abstraction of the final implementation. All participants explicitly distinguish between the model of the dialogue and the model of the user interface objects. However, at the stage of task modelling domain objects are regarded to be a part of the task model.
In the presented approaches the transition from task to dialogue is carried out in two different `directions': In the first version, the objects of the user interface are defined, based on the task model and in the next step the appropriate dialogue model is developed. The second group takes the other `direction', i.e. based on the envisioned task situation the dialogue model and afterwards the necessary object model is developed. In these approaches in a first sub-step abstract dialogue views are defined showing all relevant information the user needs to perform a certain task. For each dialogue view the interactions taking place within are defined. Afterwards, the navigation dialogue describing the sequencing between different dialogue views are developed.
In contrast to all these approaches one participant reported the use of task based dialogue modelling to support evaluation tasks. Based on an existing user interface, mainly the objects presented to the user, the current task model is described. From this the model of the dialogue is derived to evaluate the existing interface.
Within this subgroup we wanted to learn something about how the transition from task to dialogue is performed in practice. After some group discussion we decided to do a practical design exercise, by choosing a small design task, doing it on the fly and observing how we did it. We split into three design teams, each consisting of one designer, one user, and one observer. Afterwards the group was reported to by the three observers, commented by all others.
The design-study was proposed by one of the participants: "The CHI 98-Wednesday-Conference-Planner". Its purpose is to provide substantial support to CHI 98 visitors to schedule their "CHI-day", e.g. the CHI 98-Wednesday. We performed the study by having the three users to be interviewed by "their" designers, while their observer was sitting at the side, taking notes, but not intervening. Apart from all of us really having fun in that exercise, we had several insights, which are listed below, some of which could be generalised, some of which were to some extent influenced by the artificial situation we created.
Two of the three designers were quickly starting to draw user interface designs and thus narrowing the user's thoughts to this level. This was due to the designers' practice, as they were doing it that way in their day-to-day routine. The interviews tended to revolve around the designer's problems that are more tangible and immediate. We need to understand better at the outset what is a task and what are the inherent problems in expressing a process for the user.
That way of suggesting design ideas led to the effect that some users could not express their ideas freely, as they were implicitly urged to think in terms of design items. So, silence on the designer's side was important, as then the user had the opportunity to think and to express other ideas.
In one case, the user was almost upset, as she did not get heard enough. So there is a constant tendency of controversy in this process, due to the different perspectives of user and designer.
We found that the user's ideas often directly led to a user interface item, which is probably more of an artefact of our study with the one-person-user- and design-"group".
There was a common understanding that a good design can only be done, when these steps were performed, and with appropriate time.
Almost all participants of our group found that there should be no formality involved when capturing the users' ideas, because of their diversity, which any formalism might be unable to cover. However, when writing them down afterwards, after some reflection, the designer should have a powerful formalism (and/or tool) to be able to express the semantics more precisely. This would turn out to be extremely helpful in checking the design and further development.
Some of the findings might be due to the fact that we started with an informal task analysis of the current situation and immediately turned this into a design. There was no time to think of an envisioned task model first. Still, it was a fascinating and worthwhile exercise.
In the second subgroup we concentrated on the use of formal models to support the transition from task to dialogue. The discussion was structured by a proposition of discussion points, some of which were covered: What are the goals when using formal models? What are the potential losses and gains? What are the requirements?
When applying formal methods to the transition from task to dialogue, the main goals are to supply an exact documentation, and to establish a common language between the different groups taking part in the process. Based on the formal model, a more exact evaluation can take place, which could be performed in very formal or more informal ways, allowing a more exact quantification of costs than otherwise possible. Formal modelling allows reasoning about the process and the underlying concepts itself, as a sort of meta-analysis of design. Also, when designs are expressed formally there is a chance of parts of them being reused in other projects, which is almost impossible otherwise. The design group will as well develop knowledge of the process structure in a much more explicit way, as formality forces precision on how to deal with the models as well. So group knowledge is developed how to make the transition from abstract concepts to concrete design.
The common language postulated above, however, might be hard to learn, as it is a formal language. So, the users and clients might not understand the formal model, and/or the designers could get lost in the formal "design" space, due to overwhelming complex formalisms, taking into account too much or irrelevant details. Also, the expressiveness of the formal language is a critical issue: on one hand the formalism should be easy to use, on the other hand it should be powerful enough to allow to express everything needed. Given that a formalism might be hard to use the problem of time and effort to be put into using it must be weighed against its potential gains. We found, however, that tools, supporting the formalism, and taking a lot of the detail work load off the users could counterbalance this possible disadvantage. Finally, we found that there might be a disagreement between disciplines about which formalisms to use, but were not really sure that this is a disadvantage all. Maybe this expresses only the fact that different disciplines need different formal models and tool support, which then should be designed to be in some sense compatible to each other.
On the positive side we found that using formal models successfully leads to a common understanding, to powerful organisational development as process knowledge gets explicit, and to a better maintainability of designs. Being formal allows the development of tools, supporting the formalism, which leads to consistent representations, possible from multiple perspectives, which is useful in the design process and for documentation.
Some disadvantages are advantages and vice versa at the same time. This holds true, for example, in the case of the `common understanding'. Even misunderstanding can be of great value if it leads to discussions and discovering errors in the models under development. As another example, using formal models in practice is often time consuming. However, it enables tool support which on the other hand helps to reduce coasts.
To effectively make use of formal models, tool support is of the essence. When available it lowers the cost of formal modelling, as many details are taken care of by the tool. Tools can help in the transition between models, in the establishment of relations between them; they can provide powerful navigation and visualisation techniques, to handle complex models; and they can support the process by enabling easy iteration (back up propagation of changes) and/or reverse engineering. Tool support should be flexible in terms of the notation, the representation provided and the degree of handling detail, as well as being able to combine formal and informal parts and transitions between them. Apart from that, it is mandatory that there is always a clear separation of a model's semantics and the notation used.
In the final discussion of the workshop, we focussed mainly on the tool support topic and its relation to formal models, which came up in both subgroups.
We found that the keys to the success of model-based systems in supporting the task to dialogue transition are the following:
Flexible and expressive formalisms that are able to capture most relevant aspects of an interface design
Tool support that "hides" those formalisms from the user or conveys them in a manner that is unobtrusive. It is a benefit of formal modelling or model-based approaches that they lead to a rather natural outgrowth of tools to support various stages of design.
Automation: Tool support that does not automate creative parts of interface design, automates or facilitates tedious or mechanical parts, and offers flexibility to users that allows them to make changes or to proceed in a number of different ways for each particular design. Formal models should not be equated with attempts to automatically generate a usable user interface.
Everybody at the workshop wanted tools. It was universally recognised that the software design process requires and supports multiple representations at all design stages, and that each representation requires and supports browsing, manipulation, and analysis tools. It appears that the best way to convey knowledge of how best to design artefacts is to do so implicitly, through the use of tools, and not explicitly, because that would require too much communication and learning. Applying theory in HCI implicitly means that analysts and designers do not even have to know what theory is being applied for them.
This overcomes a problem with formal systems that they are often too difficult to use for many analysts, who therefore turn back to the less demanding heuristic methods. If the formal tools can be automated, however, we should then see a breakthrough in the flow of cognitive psychology into HCI, since it showed us that there is potentially a lot of interest in such products, and that in the form of software tools they should be readily accepted.
There was a general agreement, that in the early phases of the development process formal models, and even semi-formal, models are often to restrictive. This holds true, for example, when documenting observations while analysing the user's tasks.
At the end of the workshop, we decided that now the work on this topic had "just begun", and that we will repeat that workshop at CHI 99. Please feel free to check the workshop web site to find more information (URL below, or via the CHI 98 Conference link).
We want to explicitly thank our workshop participants not only for the active performance during the event, but also for a large number of contributions before and afterwards, which we used in compiling this report.
Birgit Bomsdorf has a Master's degree in computer science and is currently working on her PhD thesis in the group of Professor Szwillus.
Gerd Szwillus is professor for Practical Computer Science at the University of Paderborn, Germany. He regularly gives HCI classes at the University of Paderborn and holds seminars and special lectures in this field.
Birgit Bomsdorf
Universität -- GH Paderborn
Fachbereich Mathematik/Informatik
Fürstenallee 11,
D-33095 Paderborn, Germany
email: kne@uni-paderborn.de
Tel: +49 5251 60-6623
Gerd Szwillus
Universität -- GH Paderborn
Fachbereich Mathematik/Informatik
Fürstenallee 11
D-33095 Paderborn, Germany
email: szwillus@uni-paderborn.de
Tel: +49 5251 60-6624
http://www.uni-paderborn.de/fachbereich/AG/szwillus/chi98ws/
Issue |
Article |
Vol.30 No.4, October 1998 |
Article |
Issue |