Different Types of Patterns for Online-Booking Systems

Claudia Teuber
Software Engineering Group
Institute of Computer Science
University of Rostock
Claudia-Teuber@web.de
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
Peter.Forbrig@informatik.uni-rostock.de
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 Warnemnde, 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

<<TaskPattern>>
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
<<Task Pattern>>
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 Warnemnde.
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

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 120131,
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