Keywords

1 Introduction

Task models have a long history in the research of Human-Computer-Interaction (HCI) and several research groups are using and still developing them. There are notations that have an extended history of development and that are still in use. ConcurTaskTrees (CTT) [10] is one prominent example. However, there is no significant breakthrough in the daily use in industry. Some industrial use cases make the usage of task models necessary and task models are already used in some. The use-cases analyzed could not differ more; one use case aims to ease the communication between different disciplines while the other grounds the product-development on the task models. Our goal was to evaluate if there are special requirements for the use in daily practice that are not implemented by the existing scientific notations. We believe that the scientific use differs from the use in daily practice. Hence, these specific features and requirements may not be implemented.

This paper presents the results of a first pilot-study that evaluates the use of task models in practice. The study takes part in two different industrial settings with five participants that have different backgrounds and professions.

Section 2 gives a brief overview about task models and different notation. In Sect. 3 we describe our methods and the participants that participated. The results of the study are summarized in Sect. 4. Section 5 contains some aspects of the realization in useML. At the end, in Sect. 6 we present our conclusion and Sect. 7 gives an outlook on future work.

2 State of the Art

Task Models are a well-known concept in research; different notation or so-called languages were developed by many research groups. Task models have a long history that goes back to Hierarchical Task Analysis (HTA) that was defined in 1967 by Annett and Duncan [1]. HTA’s goal is to analyze the tasks of a worker and structure it hierarchically. Based on HTA [13], Goals, Operators, Methods and Selection Rules (GOMS) [5] was developed to estimate the effort that is necessary to earn the knowledge to perform a task sufficient. For this estimation, a detailed record of the tasks is needed and GOMS offers the possibility. It is not possible to include any temporal information in a GOMS-model. Groupware Task Analysis (GTA) is a method that supports the task-based development of groupware [14]. Groupware supports the work of groups or more users. It is possible with GTA to record and model the tasks in a hierarchical model. GTA has a graphical tool called EUTERPE for the creation of task models [15]. The Méthode Analytique de Description (MAD) is a semi-formal method to record user tasks based on interviews [12]. K-MADe is a tool to structure the tasks and create the model [3]. It has integrated temporal information that can structure the task model. Furthermore, it distinguishes between user- and system tasks. It is not possible to specify interactive tasks that are performed by a human and a system. The ConcurTaskTrees (CTT) is an engineered approach [10]. It supports the creation of hierarchical task models that can be structured with weighted temporal relations. CTT distinguishes between abstract-, interactive-, system- and user-tasks. CTTE is a graphical tool that supports the development with a graphical notation [9, 11]. CTTE enables the user to create a model graphically and analyze it with a simulation. CTTE has received an update that brings now a web-based solution, the tool is now called “Responsive CTT” [2]. Figure 1 shows a comparison between the two versions of the graphical notation that is implemented by the two tools. On the left the left is the syntax of CTTE depicted, the right model shows the icons of Responsive CTT. CTT has further usages, for example HAMSTERS is uses the concept and the notation of the integrated temporal relations [4]. HAMSTERS is an approach that identifies possible human errors and represents them [6].

Fig. 1.
figure 1

Graphical CTT syntax, left CTTE and right responsive CTT.

Full size image

The Useware Markup Language (useML) is a notation to model the user’s tasks within the human-centered development process [7]. UseML defines a “Usemodel” that is further structured in “Useobjects”, in CTT this would be represented by abstract tasks. The “Useobejcts” are structured in so-called “elementary Useobjects” that are actions that cannot be divided further. The aim of useML is to generate a User Interface by using different models, e.g. DISL and UIML, using transformation processes. Udit, is the graphical tool to develop the task model that allows also to simulate it [8]. As CTT, useML supports a graphical notation but implements it in a different way. To visualize the elements, useML uses colored boxes with text integrated as depicted in Fig. 2.

Fig. 2.
figure 2

Graphical notation of useML.

Full size image

3 Participants and Methods

We got access to two German companies that work in different areas. One located in telecommunication sector, is a large company that has a number of offices all over the world, from now on called “company A”. We could talk to three people from this company, one Interaction Designer, one Requirements Engineer and one User Experience Designer. The other company is a German medium sized company that delivers custom-fit solutions for many sectors, we call it “company B”. They develop both hard- and software for different products. The products differ from coffee-machines to medical devices. We were able to talk to one Software Developer and one User Interface Designer.

We used semi-structured interviews to get information about their work and the use of task models. To get suitable feedback, we conducted the same interview with each of the participants. After we found the initial requirements, we did two further iterations of unstructured interviews with the participants to evaluate the requirements. The evaluations were necessary because we interviewed people from two different organizations with different background and corporate philosophies.

4 Results of the Study

The company B uses no task models at the time of the interview. The Software Engineer and User Interface Designer similarly mention that they have problems with the interdisciplinary communication. They already tried to solve this using other artifacts like further textual descriptions but did not succeed. They believe that task models could solve this issue or at least ease the communication. The two participants have no special training in the field of task modeling. In addition, the Software Engineer has no Usability-related knowledge. Both worked for the company for more than five years and are working in two different departments.

Right at the beginning of the two interviews it became clear that the requirements and expectations are different. The User Interface Designer emphasized that he does not want a tool that limits him in his creativity. He also expects a less detailed model than the Software Engineer. The User Interface Designer argues that the actions of the user are interesting and that he does not need a detailed model what happens in the “software’s background”. In his opinion a graphical notation with unambiguous names of tasks as identifiers is the best way to represent the model graphically. He argues that the model will have to iterate to improve its quality and validity. In contrast, the Software Engineer wants task models to be as detailed as possible. For his domain the details give each developer specifications how the software and its User Interface has to be implemented. This makes it easy for colleagues to understand the code since they have a reference that is common for all. As most important we found the need for iterative development in order to give the different discipline the possibility to get access for different levels of detail. We collaboratively worked out four levels of detail that give the users the possibility to choose which details they want to view.

  • First level of detail: This level of detail allows the user to create the initial structure of the model. It includes the modeling of abstract tasks; the more detailed actions of a user will not be included in this stage.

  • Second level of detail: In this level the users can enhance the model and add further detail, this includes the integration of the more detailed actions. On this level it will be necessary to enable a simulation of the task model. The simulation will give the opportunity to analyze the model and possibly find some problems.

  • Third level of detail: Within this level the user can assign attributes to all tasks. One example for such an attribute is the assignment to a user group. Other attributes are the assignment of tasks to a specific platform or device.

  • Fourth level of detail: The fourth and last level provides the assignment of functions to tasks. Especially Software Developers will be interested in this kind of information.

Both, the User Interface Designer and the Software Developer argue strongly for a graphical representation that is simple and easy to understand for the user. Especially the User Interface Designer mentions that his discipline is dominated by “visual people” and a graphical notation will support their mindset. We compared the icon-based representation (CTT) with a representation that uses boxes (useML). Both subjects feel more comfortable with the representation and syntax of useML.

We interviewed the participants of company A. Again, we interviewed the subjects with the same questions and got similar responses. The greatest difference is that in this company task models are already used in daily work. The used models are different to the in languages presented in Sect. 2. In this company they call task models “Task Flows” and they contain for example conditions that are adapted from flowcharts. However, they have the same purpose like task models, they record and structure the tasks that the users fulfil during their work with a system. Figure 3 shows a short extract of such a Task Flow. It has similarities with useML and the participants would not like to replace their notation with an icon-based notation like CTT. The Task Flow’s conditions can have many outgoing edges and only one can be executed.

Fig. 3.
figure 3

Example for a used Task Flow.

Full size image

The Task Flows are an integral artifact in each project and a fair amount of time is spent on their development. The time spent depends on the complexity of the task and the familiarity with the domain. The User Experience Designer came up with the example of “self-care apps” that is for her an easy topic and hence the creation of a task model will take less time than for a “large management system”. They use the Task Flows as a base for their future development, especially the navigation concept grounds on this artifact. They review the model at first within their department, using the “four-eye-principle”. This means that one person develops the Task Flow and another person will review it and gives feedback. Once they got a first draft, they give it to other departments like the Software Architects. They will also give feedback and the Task Flow evolves. These participants were confronted with the idea of iterative support for the task model development process. The first impression was positive and they believe that this modality will support their process. They told us that the four level of detail look well-considered but we should include the refinement of the task model in the first level of detail.

Figure 3 shows the importance of conditions in their work. The Interaction Designer explains that for her daily work a conditional branch is a central aspect. She thinks that if they use a scientific developed notation, it has to include conditions. To get a better understanding of her expectations, we showed her useML and asked her to comment on the implementation of conditions. She thinks that the existing possibilities are not satisfying. Especially that they are not depicted in some way in the model is criticized by her. She argues that conditions have to be displayed in the graphical model to understand the model and implement the next steps. The Requirements Engineer and User Experience Engineer agree on this. To visualize the condition in a model, two ways are suggested by the three subjects (see Fig. 4). The first version is a simple implementation that was the idea of the User Requirements Engineer. The second possibility is inspired by the flowcharts. This is a representation that Task 2 has a pre-condition and the user is able to view it on detail. The condition could be a delay or a state, for example machine turned on. If the condition could not be satisfied the task model could stop or a jump to another task is possible, depends on how it is implemented.

Fig. 4.
figure 4

Possible visualizations of conditions.

Full size image

The participants of the two companies reviewed the tools CTTE and Udit for possible enhancements of the user interfaces and interactions. The participants mentioned that none of the tools fit to their requirements. However, both of them have strengths and weaknesses. The two tools implement the graphical notation in a different way. While CTTE on the one hand implements small icons as representation, useML on the other hand represents the tasks with boxes and a color-code. Especially the technically trained subjects argue that the colored boxes are sufficient while especially the User Interface Designer argues that the colors confuse him: “I don’t understand why this box is black and the other is orange.”. Furthermore, he thinks that the direct manipulation needs to be introduced. Both tools do not support this interaction. The implementations force the user to choose one element in the model and then using a “right-click” and choose the fitting element or click in the upper part on the fitting element. This indirect interaction, he argues, will interrupt the creation process. The other participants feel also that a direct manipulation is way more intuitive and modern. All participants wish a clear split between the functionalities and their reduction since they believe that they will not use them all.

Fig. 5.
figure 5

Final mockup of the task model editor.

Full size image

During the review of the tools with the subjects it became clear that the current implementations do not fulfil the expectations they have. The indirect interaction and arrangement of the User Interface elements do not satisfy them. The human-centered redesign of a task model editor was conducted; the final mockup (developed with Balsamiq Mockup) is depicted in Fig. 5. We used the ribbons, as they are known from other products like Microsoft Office 2010. The subjects believe that the functionalities of the tool need to be separated. Hence, we used the ribbons above. One ribbon consists of the basic functionality for modeling, the other consist of filter and the last one will start the simulation. The central part is the area that will contain the task model, the elements are consistent depicted in the model and above in the ribbon which is important for the subjects. Depicted is one possible graphical representation that was suggested by the participants. In this mockup it is also possible to choose the “Level of detail” in the upper part. The tabs “Filter” and “Simulation” switch to other views and actions.

To implement the changes that are needed we used useML since the participants believe that this notation only needs some changes to fit the requirements they have. Also, the tool Udit needs to be adapted according to the mockup above.

5 Realization in UseML

UseML is a XML-dialect and defined in a XSD-schema. This schema defines the language and the rules that structure the task model (called “Usemodel”) implements but also include the logical definitions. To implement the first and most important improvement, the level of detail, a minor revision in the definition is needed. An attribute that saves the current level is introduced. According to it, the graphical editor will allow or forbid the manipulation according to the definition that is explained above.

To implement the conditions further changes are necessary. The subjects demand two types of conditions:

  • Logic condition: This condition will have two specifications, pre- and post-conditions. If a logic condition is used, the user could provide a string with the description of the condition.

  • Temporal condition: To include some waiting time or latency a temporal condition is included as well. Two main characteristics are mentioned by the participants: duration and instant of time. The duration could be for example the startup of a machine. The instant of time is a particular point that is fixed, for example a change of shifts.

A complex type “conditions” is included in the schema and extended by two attributes that define the described types. A tool that implements all the aspects that are evaluated during the first phase is in development.

6 Conclusion

There are special requirements for task models in industrial use that are not implemented in scientific approaches yet. The current scientific implementations of task models do not fit the requirements of the subjects, hence they defined their own notations. To overcome this gap, we proposed an iterative approach that allows the users to create their model in different levels of detail. This offers the user the possibility to show only the relevant information for their work. It includes four levels of detail that begin with the initial creation of a task model. As next step the task model will be enriched by further actions and can be simulated to find possible problems within the model. The third level of detail includes the assignment of user groups or platforms to tasks. This is of special interest if the task model includes tasks that only a special user group can perform. The fourth and last level enables the user to assign functions to the tasks. This is relevant for Software Developers to get a richer specification of the task model. As well, the participants emphasize the need of conditions and their graphical representation. This is a central matter for the subjects. One subject told us that for her work the conditions are important and a notation without conditions will not be useful.

7 Discussion and Outlook

The results show that the scientific developed notations and languages do not fit to every requirement that is needed for the daily industrial use. However, some already well known concepts are valid and required for the daily use. The most prominent example is the hierarchical structure itself and the graphical representation. But especially the new iterative support could be a step forward to use task models more in a daily practice. The conditions that are introduced have also an effect on the task models. Especially that they have to appear in the model is currently not implemented. However, this is an important aspect but can lead to a model that includes some aspects of flow charts.

As the tool is completed an evaluation will be conducted. The evaluation will include the future users. They will get tasks and will have to solve them using the tool. The feedback they give will be worked in next versions of the tool.