Different Types of Patterns for Online-Booking Systems Claudia Teuber Software Engineering Group Institute of Computer Science University of Rostock [email protected] ABSTRACT

With the emergence of the pattern approach for software design researchers, software engineers and designers have started an intense discussion on patterns. This topic gained currency and is still evident in recent publications. Since then, debate has contained many conflicting theories, approaches, and ideas on the nature of patterns and their use in making the software development process more efficient. Keywords

HCI, Model Based User Interface Design, Patterns, User Interface Engineering INTRODUCTION

The idea of using patterns as design solutions to recurring problems in architecture was first introduced by Christopher Alexander in the 1970s as a “Three-part rule, which expresses, a relation between a certain context, a problem, and a solution.'' [1]

Peter Forbrig Software Engineering Group Institute of Computer Science University of Rostock [email protected] interaction have been introduced and are being published on the web [16]. The pattern language from Jenifer Tidwell [15] identifies and describes more than 50 patterns related to user interface design. A concept of using patterns in model-based design was presented in [13]. We will comment this approach based on the experiences in a project of managing berths in a marina. We will discuss our experiences and argue for a pattern based user interface design process. A PATTERN PROCESS

BASED

USER

INTERFACE

DESIGN

The approach of integrating the method of patterns on the one hand and the user interface design process on the other hand provides common solutions to recurring user interface design problems. Figure 1 displays the Requirements Analysis step and the User interface Design step of the software engineering life cycle.

Inspired by the ideas of Christopher Alexander patterns have been taken over to software design. The first book on design patterns was published by Gamma et al. [7], who picked up the original pattern idea and applied it to objectoriented software design. They specified a catalog of design patterns as solutions to recurring software development problems. Their attempt provided a common terminology for design aspects and supported the reuse of software development knowledge. Being both abstract and concrete made them the most applicable in the software community. The abstract aspect allows applications to vary contexts while the concrete aspect ensures the immediate implementation to practice [15]. The subject of HCI patterns has become a hot topic over the last few years. The various ideas on HCI patterns started to be structured at the HCI '97 workshop with the aim of ''exploring the utility of pattern languages for interaction design'' [2]. Still at the beginning of understanding the whole HCI pattern process, the workshop led to the classification of a constant structure between patterns. Further workshops helped to develop a sample format for HCI-patterns and to structure them [3]. Up to now, more and more pattern collections in the field of human-computer

Figure 1: A Pattern-Based user Interface Design Approach

Both steps are divided into sub-steps. The requirements analysis phase contains the User Analysis, Task Analysis and Business Object Analysis. These three sub-steps can be supported by patterns that provide solutions to common problems for these steps. The User Interface Design phase can be divided into three sub-steps, the conceptual design, the dialog view design and the visual design that can be supported by patterns. Its applicability is discussed in more detail in the following chapters with the example of the requirements analysis and user interface design for online booking applications

Figure 2: Task Model for Online Bookings REQUIREMENTS ANALYIS

The starting point for the development of any user interface is a thorough analysis of users, tasks, and objects. It provides the basis for later development steps in the software engineering life cycle. To avoid cost-intensive changes in the subsequent steps of the software development process, a thoughtful carried out analysis is the starting point of further design [18]. Therefore a structural analysis is essential for the development process. Task Analysis

Task Analysis defines the process of identifying the tasks users need to perform to reach a certain goal and build a strong awareness of them. Task analysis allows a detection of task goals, operations that need to be accomplished, and tasks' requirements and formulates them into a task model. Task analysis makes a strong contribution to user-centered design by involving the user perspective of task accomplishment into the design process [10]. “Let us assume Paul wants to go on a holiday trip together with his wife Anne. They have a sailing boat and would like to explore the Baltic Sea. To be on the save side they would like to book a berth for their first stay in Warnemünde, a very nice beach area in the northern part of Germany. It would be good to have a booking system available on the INTERNET said Anne”. Anne and Paul discussed for a while what kind of task support they would appreciate. Of course they would like to have support for making a reservation. It should be possible to modify and even cancel a reservation; they would like to have the chance to contact the managers of the marina and to have the chance to get help at any time during the booking process. Figure 2 presents a possible task model visualized using the notation of concurrent task trees [11]. The task model in Figure 2 explains what tasks and in which order Anne and Paul can accomplish to achieve the overall goal of booking a berth.

[(A >> B)=sequence, (A ||| B)=parallel, (A [] B)=choice]

First of all they can ask for help, make a reservation for a berth, modify or cancel an existing reservation. For reserving a berth, the first step will be the initial request for a berth, followed by a choice for an available berth or the refinement of search options if no suitable berth is offered. They must register after selecting a berth. In theory, the registration could be either at the beginning of the reservation process or just before purchasing or booking. Paul knows from a lot of investigations, that the force for early registration might cause customers to quit the application due to privacy reasons or time constraints. To avoid loosing the customer before booking, sailors are asked for registration after the selection of a berth, which fits to their wishes, just before the actual reservation. The short login allows registered customers to quickly register with their e-mail address and password. First time customers need to fully register by providing personal details and type of payment information. The type of payment information guarantees the reservation. The subsequent reservation overview summarizes booking and customer information and needs to be confirmed or rejected by the customer. It is possible to modify or cancel a reservation until a specified period of time before the check-in date, without being charged. This is an essential customer requirement since sailing trips are subjected to wind and other factors that cannot be influenced by people, which makes trips difficult to plan ahead. For modification or cancellation of a reservation customers need to register with their e-mail address and password. The reservation will be displayed for modifying or removing. If a customer has more than one reservation he is prompted to select a reservation. Modifications or cancellations of reservations need to be confirmed. Paul abstracted the task model already in such a way that it fits to the general business process. It is a generalized version of the task model of Anne and Paul. Our experiences with different models allow us to extend this task model to an even more general task pattern.

Name: Online Booking Task Model Pattern Context: Customer would like to book a certain object online for a specific period of time.

Object, eMail, PWD Online Booking

Problem: What tasks need to be accomplished to reach the goal: an online-booked object? Forces: • Time and goal efficient process • Intuitive booking process • Provide system status information [6] Solution: • Different logins for first time users and already registered users • Possibility of refining the query without going back to the beginning • Visual or descriptive specification of available objects • Visualization of the current status of the booking process and the display of a confirmation immediately after completion Model: The task model shown in Figure 2 contains the identified tasks for booking a berth online. If the term berth is replaced by a general object, the task general model can be derived (visualized by Figure 3). Online Booking []

[]

Ask for Help >>

Choose an Object

>>

Register

>>

>>

[]

>>

Print Prompt for Confirmation Reservation

[]

>>

Contact

Cancel or Modify a Reservation >>

Login [Specify Modify or Reservation Cancel a Number] Reservation

[]

Initial Choose Registered First Time Accept or Customer Registration Request Refine Login Specify Specify Select Booking Object Object Data Data

[]

Make a Reservation

|||

Refine Give Give Options Personal InformaInforma- tion on tion Type of Payment

[]

Reject

Cancel

>>

Modify

>>

Request Confirm Modify Confirm Cancel- Cancel- Reser- Modifilation lation vation cations

Figure 3: CTT notation of pattern “Online Booking”

The model can also be described in an object-oriented way as already mentioned in [13]. Figure 4 portrays such a notation of the model. In Figure 4 it is assumed that there a pattern “Register” with parameters “Login” and “PWD” already exists. The pattern “Online Booking” has three parameters. The first parameter specifies the object, which can be booked. The second and third parameters are the email address of the customer, which is used as login value for the registration procedure, and the password. This simple procedure for generalizing a specific task model to a general pattern was possible because the model of Paul did not contain specific tasks related to the objects boat or berth. These specific tasks are assumed to be specified according to the object-oriented specification. In this way we support the idea already mentioned in [19] of a unified approach of modeling tasks, objects and users.

Login=eMail, PWD Register

Figure 4: UML notation of pattern “Online Booking”

Let us next come to the analysis of the user of a booking system. In case of Anne and Paul we have an experienced and an inexperienced user. In the next section we will have a closer look at this problem. User Analysis

The aim of user analysis is to gain knowledge about the users concerning their general and domain knowledge, how frequently they are expected to use the application, their specific characteristics and skills. Knowing the user is the fundamental requirement for user centered design [9]. It is possible to combine certain applications to groups according to their functionality and establish that these groups refer to similar groups of users. And keeping in mind that patterns are generic solutions to recurring problems ([7] [13]) they can support the user analysis by providing generic user profiles for general application groups. For online booking applications it is possible to discover two user profiles: The First Time Customer pattern and the Registered Customer pattern. While the first one characterizes first time customers who have not booked with the application before, the second one describes already registered customers according to their characteristics, knowledge and experience. In the following both patterns are introduced in more detail. Name: First Time Customer Pattern Context: • Customers use this online booking system for the first time and does not know which steps to go through • Are unsure and highly concerned about how their given data will be used • Are unwilling to provide sensitive data e.g. credit card information • Require information concerning the marina and its facilities, its position and available berths • Need to be informed about the booking status • Require the possibility modifying or canceling reservations Problem: How do you manage to guide the customers through the booking process? Forces: [6] • Offer assistance and sufficient support during the booking process

• Facilitate the use of the online booking module • Provide security and privacy • Support a design for all and error tolerance • Allow cost transparency Solution: • Outline the different steps in the booking process • Indicate: (1) what information is collected (2) the purpose of why the information is being collected and (3) how the collected data is used [5] • Provide secure data transfer • Provide information about the requested resource, additional information and information about the booking status • Offer the possibility of canceling reservations • Register customers and save their details to shorten the booking process the next time they visit the site

The first time customer pattern is applicable for unregistered customers who are about to book their resource online for the very first time. The registered customer pattern applies to customers that regularly book the resource on this site. “Anne and Peter find an already existing electronic shop “Marina Portorosso” for booking a berth in Warnemünde. As unregistered users they explore the opportunities and find an appropriate berth. They would like to make a reservation. Hence, they register and get the status of registered users.” It is generally a good strategy to offer information to potential customers and it is also a wise decision to offer more services for known (registered) customers. Name: Registered Customer Pattern Context: • Customers have already used the online booking system before and gained knowledge about the booking process • Customers have been informed how, why and what personal data is stored • Require information concerning: marina and its facilities and position and available berth • Need to be informed about the booking status • Require the possibility modifying or canceling reservations Problem: How do you manage to guide the customer through the booking process? Forces: [6] • Offer assistance and sufficient support during the booking process facilitate the use of the online booking module • (See first time customer pattern) Ease of use, privacy, security, design for all, error tolerance, system status information, booking confirmation, cost transparency

Solution: • Outline the different steps in the booking process • Provide information about the requested resource, additional information and information about the booking status • Customize the booking process for registered users by providing special information (e.g. discounts, special offers that only fit to the customer etc.) • Provide secure data transfer • Offer the possibility of canceling reservations • Provide a short login

The above user patterns are applicable independent from the type of online booking application as well. They can be adapted to online booking systems for hotel rooms, rental cars, berths and more. We already mentioned object models. The next paragraph will have a special focus on business objects. Business Object Analysis

The analysis of business objects is based on the objectoriented concept. Business-object analysis identifies and illustrates the application objects. It includes the determination of their attributes, methods, and relationships, and visualization of their dynamical behavior. Since the objects that are involved in business processes as well as their attributes, methods and relationships can be generalized and then be transferred to similar applications, patterns can be used to support the design process and reduce complexity. Figure 5 displays the generalized business object pattern for online booking systems. One or more customers are able to book one or more objects. The booking refers to an invoice and includes a price. The price is modeled as its own class since there can be different prices and price types that are billed and calculated differently. Customer ID Last Name First Name Address City Postal Code ...

Booking Object ID Available : Boolean

Price Price Code Booking Booking Number Date of Arrival Date of Departure Status : (Reservation|Booking|Cancelation)

belongs to 1

1

Invoice Status

Figure 5: Business-Object Model for Online Bookings

The business-object model of Figure 5 provides a pattern for booking online. It provides useful classes and attributes. (Methods are neglected in our example.) There is still a lack of expressiveness in UML diagrams. Let us have a closer look at the attributes “Date of Arrival” and “Date of

Departure”. Both attributes are not necessarily applicable for all kinds of bookings. However, they provide information for a lot of booking systems. It makes sense to provide “multiplicity” information for all elements in an object pattern. This allows to specify, whether certain elements are essential and always necessary (e.g. booking number), whether they are optional (e.g. Date of Arrival) or whether they can occur several times (e.g. Address). Concepts already known for UML can be used in the context of patterns to provide more detailed information. In this way the design patterns from [7] can be specified in a more precise way. We implemented this idea for patterns in Rational Rose. USER INTERFACE DESIGN

After the analysis phase the collected information is used as a basis for the user interface design, which is divided into three design steps - the conceptual design, the dialog design, and the visual design. The conceptual design of the application includes the determination of the overall architecture and can be developed from the analysis models and can be supported by conceptual patterns. The dialog design defines structure and dynamic behavior of each dialog. [16] Eventually the visual design of the application, as the last step in the user interface development process, defines the specific layout. The corresponding presentation patterns establish the concrete design and the corresponding representation of the application's elements.

dialogs as derived from the task model. The sequence of dialog views belonging to the 'make a reservation' menu item includes: the 'request', 'select', 'register', 'confirm', and 'print' dialog view. While the 'modify or cancel' menu item leads to a sequence containing the 'login', 'modify or cancel' and 'print' dialog view. The limited navigational view structure for the mobile device is presented in Figure 7. Name: User Interface Conceptual Design Pattern for Online Booking Applications Context: A customer wants to book a certain object or resource online. Problem: How to model the dialog structure of an online booking application? Forces: The underlying tasks and their relations need to be adequately modeled and the concept of each side needs to be specified. Solution: To obtain the conceptual model for the user interface structure for online bookings, the task analysis model has been used as a basis. 1. Determine the depth of the task tree up to which task related information is used 2. Transform task model into dialog structure 3. Determine the navigational structure Example: Deciding for the overall navigational view structure leads to the following dialog structure illustrated in Figure 6.

Conceptual Design

Conceptual design patterns as abstracted solutions for the application's architecture hold solutions for the dialog structure and site concept. They are derived from findings of the analysis phases (task, user and business object model) and include generic and reusable solutions for developers. The following user interface conceptual design pattern for online booking applications provides a general solution and shows how to transform the task model structure into a dialog structure containing dialog views and transitions. The notation is borrowed from our dialog graph notation [12] with sequential and concurrent transitions between views, which are the nodes of our graph. “Anne and Paul use a PC for their browsing. They discuss how the task model for booking a berth is related to the navigational structure. Paul recognizes that the task structure is used to a certain level only. Using his mobile device he recognized a slightly different behavior.” Paul was right, the tree structure of the task model was used to the level 2 only. This allows a simple transformation to a dialog model. The first level of the task tree provides the top-level navigation. It contains (see Figure 6) the tasks: Make a reservation, Modify or cancel reservation, Help, and Contact. The 'help' and 'contact' menu items directly lead to their corresponding dialog view since they do not have sub-level dialogs. The menu items 'make a reservation' and 'modify or cancel a reservation' lead to a sequence of

Figure 6: Conceptual Design - Overall Navigation

The model captures all hierarchical and temporal relations of the task model. If animated, the dialog structure would reflect the temporal dependencies. If 'make a reservation' for example has been selected, only the 'request berth' menu item with its corresponding content area would be active together with the other top-level menu items. The 'select berth' menu item of the same sub-menu would not be available until the 'next' button fires and initiates the transition to the 'select berth' dialog view. The 'next' and 'back' transitions are based on the sequential concept. The hierarchical menu is modeled and visualized according to

menus of desktop applications to illustrate the similarities in use. The menu is visible throughout the application just the sub-level menu items refer to different sub-dialogs.

Figure 7: Conceptual Design - Limited Navigation

The limited navigational view structure refers to the following dialog structure displayed in Figure 7. A main dialog offers the possibility to choose between 4 menu items. If one selects the first menu item 'make a reservation', the sub-dialog 'request a berth' – a complex dialog that consists of five sub-dialogs will be opened (illustrated in Figure 8). Customers who intend to book, would, after selecting the 'make a reservation' menu item, be prompted to insert their date of arrival. After confirming the next dialog of the sequence, the 'date of departure' dialog view would be displayed. Subsequent to the 'make a reservation' sequence, Figure 8: Dialog Structure displayed in Figure 8, the for Limited Navigation transition 'next' would be fired and lead to the 'select' dialog where the customer chooses e.g. a berth followed by the registration, confirmation and finally the reservation confirmation is displayed. Dialog View Design

The dialog view design includes the definition of the interface elements, their structure and behavior without specifying any aspects that are related to their actual layout. The user interface dialog design reflects all user interface components, their structure and the behavior of each dialog. The overall dialog structure follows a certain framework, the so-called floor plan that clusters user interface components to semantic units. Developing the application's floor plan means to derive the dialog structure and interface elements from the conceptual model and to apply a specific layout for the application that defines how the user interface elements are arranged within the interface. The following user interface dialog design pattern provides fundamental support for the dialog design for online booking applications.

Name: UID Pattern for Online Booking Applications Context: A customer wants to book a certain object or resource online. Problem: How to model the user interface dialog views for online booking applications? Forces: The user interface components and their structure on the dialog have to support the accomplishment of tasks and meet structural layout principles. Solution: The development of the dialog design requires three steps: 1. Define the user interface elements of the dialog view 2. Establish the dialog view structure to derive a floor plan 3. Characterize the dynamic behavior of the user interface elements Example 1: Online bookings via web browser To derive the user interface elements of the dialog view the conceptual model can be used as basis, which defines the navigational structure. For our example this would include top-level and second-level navigation and a content area. The dialog view contains three components: first the top-level menu, second, the sub-level menu and third, a corresponding content area. The top-level menu items hold references to the second-level menu, e.g. the 'reservation' points to the corresponding second-level menu containing 5 sub items: 'Request', 'Select', 'Register', 'Confirm', and 'Print'. Two of the top-level menu items do not refer to a second-level menu they directly point to their corresponding content area, e.g. the 'Contact' menu item refers to the 'Contact' content area. All other content areas are referenced by their corresponding second-level menu items. The next step would be to assign a layout to the dialog view. For online bookings the grid layout pattern [17] provides the best support, since it divides the site into various sections that can be used depending on applications requirements. Applying the grid layout pattern to the online booking example leads to the floor plan of the corresponding dialog view structure. The floor plan can be of a different level of abstraction. The more detailed it gets the more information is needed. This could be best realized by getting the users involved. They could, e.g. via drag and drop, define more user interface elements and their positions on the dialog view to get the floor plan more and more specific. Figure 9 displays such a specific floor plan for the 'Request' menu item of the 'Reserve a Berth' menu. Example 2: Online bookings via mobile phone Due to limited navigational space and interaction facilities the user interface dialog view structure for mobiles will be much simpler than for browsers. Taking the navigational structure from the conceptual design step as a basis, the dialog view will either contain menu items or requests input

or displays information. For selecting a menu item or confirming an input the interface furthermore requires a 'select'/'confirm' button.

Figure 9: Dialog View Design - Floor Plan For online bookings via mobile phone a simple vertical flow layout will be most applicable since information or user interface elements are organized in vertical sequence to support vertical navigation. The corresponding floor plan is omitted here. Used Patterns: Grid Layout Tiled Working Surfaces [15]

Pattern

Problem: How to design the visual appearance of the user interface for an online booking application? Solution: The visual design of the dialog requires the following decisions on [9]: • Use of controls (check boxes, buttons etc.) • Location and format of standard display components (navigation controls etc.) • Use of Color, Fonts and Styles • Input device interactions and keyboard shortcuts • Type, location, format, and wording of messages for online instructions Example: Figure 11 and Figure 12 display the results of the last design step: An online booking interface. Depending on the open design questions the interface can be derived in interaction with the user. If style guides are used that predefine fonts, colors and structure, the visual design step can be automated easily. If no style guide is predefined the interface is derived from the dialog floor plan that determines the overall structure, in interaction with the user that needs to specify open parameters.

[17]

Visual Design

In the paragraph above we have focused on user interface elements and their structure on dialogs. The next step would be to determine the visual appearance of the interface components and the overall dialog. How detailed the application's visual design style guide is specified depends on the size and the complexity of the application. A complete visual design specification where developers can directly code from may support the efficiency of complex software applications, while less complex applications can be developed more quickly with detailed floor plan and general design guides [9]. Visual design patterns reflect solutions for specific recurring graphical UI design problems. Since they refer to a lower lever of abstraction and are close to implementation, they support specific decisions concerning the look and feel of the application. [12] Patterns at this stage of the design process deal with questions such as: [16] Color, Contrast, Proportion, Font Styles, Layout, and Images etc. Patterns in this stage of the design process can assume what usability evaluations have discovered and provide general solutions, but they still need to be adapted to the specific application, with its specific style guides to be included. The user interface design pattern for online booking applications allows an adoption of the module to different designs. The following user interface components and parameters need to be instantiated and specified. Name: User Interface Visual Design Pattern for Online Booking Applications

Figure 11: Online Berth Booking Interface for Browsers Having applied the visual design pattern for online bookings to mobile applications leads to the following possible solution, shown in Figure 12, for online berth bookings. After selecting the 'make a reservation' menu item customers will go directly to the displayed 'Request' dialog view, where they can scroll through the list of items they need to fill in to take their reservation further By selecting the button Figure 12: Visual 'Select' they will either Design for Mobiles jump into the next sub menu or input dialog view.

SUMMARY AND CONCLUSION

Patterns as generic solutions to recurring problems provide fundamental support for the software development [7]. Applied to the topic of Human Computer Interaction they provide fundamental design support and further the development of user interfaces [13]. In this paper the pattern concept has been applied to the analysis and user interface design of online booking applications. Starting with a general overview of the evolution of patterns. We presented the pattern-oriented user interface design approach and applied theory to practice with the example of online booking applications.

4. CHI letters format. J. Borchers, A Pattern Approach to Interaction Design, John Wiley & Sons, 2001 5. L.F. Cranor and J. Reagle and M.S. Ackerman, Beyond Concern: Understanding Net Users' Attitudes About Online Privacy, 1999, http://www.research.att.com/projects/privacystudy/

6. B.J. Farquhar and G. Langmann, The Consumer Needs in Global Electronic Commerce, EM - Electronic Markets, 1998, 8, 2 7. E. Gamma and R. Helm and R. Johnson and J. Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 2002. 24th edition

We described the patterns along the scenario of Anne and Paul, but in fact the models and patterns are based on a thorough analysis [14]. The online booking pattern include analysis patterns that define users, tasks and business objects and user interface design patterns that specify the dialog structure, dialog design, and visual design. Finally the online berth booking application has been tested by an usability evaluation to find remaining usability problems to optimize the use of the integral online booking pattern. The heuristic evaluation was performed with domain und usability experts. The improvements of this evaluation are already included in this paper.

8. E. Gamma and R. Helm and R. Johnson and J. Vlissides, Design Patterns: Abstraction and Reuse of ObjectOriented Design, In ECOOP '93 Conference Proceedings, Springer-Verlag Lecture Notes in Computer Science, 1993, 406-431

Research in the field of patterns for the user interface development will remain an important key topic and requires further research to optimize the application of patterns.

11. F. Paternó, Model-Based Design and Evaluation of Interactive Applications, Springer, 2000

This paper constitutes a step forward on the way of integrating user interface design patterns in the software development process but still more research and progress is required. Especially the integration of different types of patterns has to be studied in more detail. We suggested some new notations for object patterns, which help to specify more precise patterns. Tool support for task and object patterns is already available. However, it is a question of further investigations to combine both approaches seamlessly. The same assumptions are valid for tool support for floor plans and detailed user interface specifications. REFERENCES

9. D.J. Mayhew, The Usability Engineering Lifecycle: a Practioner's Handbook for User Interface Design, Morgan Kaufmann Publishers, Inc., 1999 10. K.L. McGraw and K. Harbison, User-centered requirements: the scenario-based engineering process, Lawrence Erlbaum Associates, Publishers, 1997

12. D. Sinnig, H. Javahery, P. Forbrig, and A. Seffah. The complicity of model-based approaches and patterns for ui engineering. in Proceedings of BIR, pages 120–131, 2003 13. D. Sinnig, A. Gaffar, D. Reichart, P. Forbrig and A. Seffah, Patterns in Model-Based Engineering, Proc. CADUI 2004 14. C. Teuber, User Interface Design Patterns – Requirements Analysis, User Interface Design, and Usability Evaluation of the Online Boking Modue for hte Marina Software ”MarinaManager”, Master Thesis, University of Rostock, 2003 15. Tidwell, J. (1999). Common Ground: A Pattern Language for Human-Computer Interface Design http://www.mit.edu/~jtidwell/interaction_patterns.html

1. C. Alexander, The Timeless Way of Building, Oxford University Press, 1979

16. M. van Welie, Task-based User Interface Design, Vrije University, Netherlands, 2001

2. E. Bayle and R. Bellamy and G. Casaday and T. Erickson and S. Fincher and B. Grinter and B. Gross and D. Lehder and H. Marmolin and B. Moore and C. Potts and G. Skousen and J. Thomas, Putting It All Together: Towards a Pattern Language for Interaction Design, SIGCHI Bulletin, 1998, vol 30, 1, 17-23, January

17. M. van Welie, Welie's Patterns,

3. J. Borchers, A Patterns Approach to interaction design, In Designing Interactive Systems: processes, practices, methods, and techniques, 2000, 369-378

http://www.welie.com/patterns

18. S. Wilson and P. Johnson and C. Kelly and J. Cunningham and P. Markopoulos, Beyond hacking: a Model Based Approach to User Interface Design, Proceedings of HCI'93, 1993, 217-231 19. A. Dittmar, P. Forbrig, Higher-Order Task Models, Proc. DSV-IS 2003