Patterns and Objects for User Interface Construction
Alecia Eleonora Acosta and Nancy
Zambrano, Central
University of Venezuela, Venezuela
|
 |
REFEREED
ARTICLE
PDF Version |
Abstract
Nowadays, computers play a very important role, that is to say, as
a communication tool between people. This introduces the interface
between human and machines as a key player, therefore the importance
of these interfaces. The existing software development processes recognize
this importance but do not establish precise guidelines for the construction
of the user interface as an activity within the system life cycle.
This article describes a method for constructing user interfaces based
upon interaction patterns. This method can be incorporated to an object-oriented
software development process which fulfills certain characteristics.
Interaction patterns describe interface design solutions favoring the
development of a user interface prototype.
1 INTRODUCTION
This paper presents a method for constructing user interfaces based
upon interaction patterns. This method is intended to reduce time spent
in developing user interface. This method can be introduced into an
object-oriented software development process that embodies the remaining
stages of software life cycle, which benefits the integration of the
areas of Software Engineering and Human-Computer Interaction.
The method
is engraved within the context of software development based upon prototyping
and supported by the reuse of components: interaction
patterns. An interaction pattern captures essential information relative
to a recurrent problem, shows a successful solution and describes the
context of this solution. A pattern is written to communicate the experience
and to allow designers to reuse it.
Among other things, these interaction
patterns are used to generalize a solution regarding interaction designs,
to record knowledge or experience
and to reuse it, and to facilitate communication among people involved
in software development, mainly from different areas (software engineer,
interface experts, problem domain expert, user, etc.). Section 2 of
this article deals with the essential aspects related to interaction
patterns. Section 3 describes the user interface prototype construction
method, where interactions patterns are used; and the third section
will explain the integration of this method within a software development
process.
2 GENERAL ASPECTS OF INTERACTION PATTERNS
Knowledge reuse is a
technique used by experts of any area; when solving a problem, they
make use of their own experience - as well as of others-
to verify whether they have successfully solved a similar problem and
then apply that solution with the required modifications (if any).
Generally
speaking, experienced designers almost never solve every new problem
since the beginning, they reuse solutions that have been
successfully applied before and that are part of their expertise. This
expert knowledge is translated into components that are going to be
used by others to solve similar problems. In the area of Software Engineering
a way of recording this knowledge is by using software design patterns
[Gamma97] and this practice allows designers to reduce development
costs and time. This same technique is applied to Human-Computer Interaction,
where the experience of interface design is recorded in interface design
patterns – or interaction patterns-which are reusable components
that describe a successful solution within a given context to a recurrent
problem regarding user interface design.
Figure 1. An interaction pattern, Author: Marjtin van Welie
URL: http://www.welie.com/patrones/searcharea.html [Welie03]
Software design
patterns and interaction patterns, even though they express solutions,
are two very different concepts. Interaction patterns
are closer, as far as objectives are concerned, to the original pattern
concept developed by Alexander in the field of architecture [Alexander77],
in the sense that they are oriented towards the creation of comfortable
environment for end users.
An interaction pattern works as a communication
tool between people working in a software development team (generally
a multidisciplinary
team made up by specialist in user interface design, software domain
specialists and users, etc.). Figure 1 shows a part of an interaction
pattern from Martijn van Welie’s collection, available in http://www.welie.com/patterns [Welie03]. Pattern Structure
In literature we can find several ways to write an
interaction pattern, all of them having basic components in common
even thought names
can change, for example [Mahemoff98], [Tidwell03], [Usability03].
Currently
there is no standard structure for writing an interaction pattern.
In this paper we propose a pattern structure using a metapattern,
this is to say, a pattern that allows describing patterns. Figure
2 represents
this metapattern.
Name, author
Classification and range. |
Name: states the central idea. Author: the name of the creator
of the pattern. Classification: states the pattern type. Range:
states the qualification of the pattern. |
| Problem |
Describes the problem to be solved from the user point of view. |
| Solution |
Describes, in a descriptive and graphic form, the solution of
the problem. |
| Context |
Presents the conditions under which this pattern is used. |
| Forces |
Points out the conflicts that could restrain the solution. |
| Usability |
Describes the impact of the use of the pattern from the usability
point of view. |
| Consequences |
Describes the result of applying the pattern. |
| Examples/Counterexamples |
Shows examples and counterexamples of the proposed solution. |
| Related Patterns |
Enumerates other patterns related to this pattern. |
Figure 2. Metapattern. Components of an interaction
pattern
This metapattern is aimed at defining a notation that can be
easily understood by the complete development team. It is not always
necessary
to describe each component for all patterns, with the exception of
obligatory ones as: name, problem, solution, context, and usability.
Figure
3 shows an interaction pattern from van Welie‘s collection
[Welie03], expressed using the metapattern of Figure 2.
| Name |
Simple Search |
| Author |
Martijn van Welie |
| Problem |
The users need to find an item or specific information. |
| Usability |
Action minimization |
| Context |
Any web site that already has primary navigation. User may want
to search for an item in a category. User might want to further
specify a query. |
| Forces |
By using this setup the whole search becomes a sentence that
reads like the search query. |
| Solution |
Offer a search
* The search interface
Offer search functionality consisting of a search label, a keyword field, a filter
if applicable and a "go" button. Pressing the return key has the same
function as selecting the "go" button. Also provide Search Tips and
examples in a seperate page. A link to that page is placed next to the search
functionality. The edit box for the search term is large enough to accomodate
3 typical user queries (typically around 20 characters). If the number of filters
is more than 2, use a combobox for filterselection, otherwise a radiobutton.
Search -- editbox -- for/in -- filter -- Go button
or just...
-- editbox -- Go button
* Presenting search results
The search results are presented on a new page with a clear label containing
at least "Searchresults" or similar. The search function is repeated
in the top-part of the page with the entered keywords, so that the users know
what the keywords were.
The number of "hits" is reported and the list of search results is
organized; sorted or rated with the best matches at the top. When there are more
than 10 results use a Paging mechanism. Each search result shows a link to the
item itself and a snibbet of text to explain the item. Preferably that would
a summary or abstract but can also be the first lines of text of the resulting
item. The structure of a "result" typically shows:
1. Page Title
2. Description
3. Categorization
4. URL, Size, Date
* Keyword matching
If more than one search term is used the search engine must handle them as follows:
if no special separators are used (not including the space), the search is interpreted
as an OR function, the results that match both terms are listed first. If special
separators are used the search engine must be able to handle more than one convention.
For example, sometimes the "AND/OR" separators are used but using a "+" or
a "-", include and exclude, must also be handled correctly. The engine
must also be able to handle spelling mistakes of at least one character. |
| Example |
From http://www.tucows.com
In this example from tucows, the designers actually were able
to make the search read like a sentence. Users can "download
sotware package X for Win2000"....
This example from Google shows how each result is presented |
| Related Patterns |
Consider the Paging or List Browser patterns for navigating through
a large set of results. However, users will not check more than
one or two pages of search results; instead they will edit the
search terms again. |
Figure 3. Simple Search Pattern expressed by the Metapattern
Taxonomy
of interaction patterns
Taxonomy permits classifying patterns as to
facilitate its creation and usage. Patterns can be classified based
on certain characteristics;
some authors have presented different classifications [Coram03] [Mahemoff98].
This
article defines the following interaction pattern types and their corresponding
symbols:
 Domain Patterns:
describe aspects of the interface that are related to a specific
software domain (for example, Electronic
Commerce, Virtual
Courses, etc.). System Patterns:
capture aspects of user interface concerning a specific application,
for example usability attributes that must
be guaranteed,
purpose of the system, etc.  Task Patterns:
describe interface aspects referenced to the interaction with software
functionalities.  Complex Element
Patterns: state interaction styles between user and the interface
made up by interface elements.  Single Element
Patterns: describe atomic elements of user interface.-
 User Patterns:
describe user profiles relevant for the application.
Interaction
pattern organization
Isolated patterns are not very important. The
link between patterns is as important as the pattern itself, and its
organization is the
basis for defining collection of patterns. It is possible to have a
pattern with a higher level than other (for example, domain and simple
element patterns) and generate a hierarchy among them. Also, it is
possible to relate patterns from the same level. Last but not least,
it is possible to establish a multiple link structure where patterns
reference other patterns. The notion of a pattern implies the creation
and/or manipulation of pattern groups related among each others, describing
a design of a complex interactive system.
After determining a structure
to describe a pattern and defining interaction pattern taxonomy, it
is necessary to establish how these patterns will
be organized within a collection, as to facilitate its creation, reuse
and maintenance.
Patterns will be organized in a collection depending
on how they will be used on the practice; this means that the final
goal of any organization
of patterns is to support an iterative design process where links among
patterns would lead the designer towards the next logical step in the
process of user interface construction.
One of the workshop INTERACT99
results, presented on [Borchers99], is the usefulness of interface
pattern languages, having established
that the goal of pattern language is to share successful interaction
design solutions among professionals and to supply a common language
available to any one involved in the analysis, design, development,
evaluation and use of interactive systems. There are also other experiences
on the definition of pattern languages proposed by [Bayle97], [Casaday97],
[Erickson01] and [Coram03].
An interaction pattern language is a collection
of structured patterns which serves designers as guidelines for constructing
a user interface.
A pattern at one level can reference a great number of other patterns
located at a lower level in order to complete the solution. When a
pattern references other pattern it means that the first needs the
solution described by the second to complete the solution. The patterns
so connected provide an informal grammar for design: a pattern language
in a certain domain.
The next definition of a pattern language, using
the metapattern presented in Figure 2, is based on the definition provided
by [Borchers01]:
On advantages of using pattern languages
is that development team speaks the same language, which establishes
an organizational principle that
facilitates
the use of interaction patterns.
Figure 4 is an abstract and simplified example
of pattern language, made up from different related pattern types.
It can be observed a domain pattern
D
which references a system pattern S, the latter at the same time references
task patterns T1 and T2, and the representation of task T2 in the user
interface is a menu described through a complex element pattern called
Menu.
The user interface construction method that will be explained
in the next section is based upon the creation of an Interaction
Pattern Language,
which together
with an Interface Object Model, is the starting point for the construction
of a user interface prototype.
Figure 4. Example of interaction pattern language.
3 A USER INTERFACE
CONSTRUCTION METHOD
User interface construction method (UIC) proposed
here can be integrated to an object-oriented software development process.
Moreover, this
method is inscribed in the development models that incorporate prototyping
since the first stages of the software life cycle; in this case we
propose to construct a user interface prototype starting from interaction
patterns and interface objects. The patterns are produced while applying
the method or they are selected from a pattern repository.
The UIC method
states a process for constructing user interface based upon interaction
patterns and interface objects. The method is aimed
at developing a user interface prototype that can be evaluated by the
end user; in this way the prototype could evolve up to satisfy user
requirements.
As it can be seen, this paper is not intended to create
a new software development method, but any object-oriented process
based on functionalities
of the system, supported by different architectures, interactive and
incremental, can be extended by the incorporation of the UIC method.
In
order to construct the user interface prototype we started from known
models, models defined in UML (Unified Modeling Language) [Rumbaugh99].
They are:
- Use Case Model which allows identifying functionalities
of a system from the point of view of the user interaction sequences.
- Domain Object Model allows identifying objects pertaining
to the domain of the system and the relationships among them.
Here it must be emphasized
that the method only takes into consideration the aspects relative
to user interface construction, and as a consequence
it should be incorporated to a software development process which
takes into account the remaining stages of software life cycle.
Artifacts used during a user interface construction
Figure 5 shows a diagram of the artifacts used and created
during the user interface construction: Use Case Model, Domain Object
Model, User
Interface Model (UI) consisting of a Pattern Language and an
Object Interface Model, and a User Interface Prototype.
It is worth
reminding that a Use Case Model describes all user
interaction sequences with the system that are required to
carry out its functionalities,
and each Use Case represents one unit of interaction between
the user and the system [Sparks02] Therefore, a Use Case Model
shows
all possible
scenarios from user interaction and represents the behavior
of the system.
The Domain Object Model, as any other object oriented
process, is created by identifying the objects located within the
domain of the
problem,
its characteristics, (attributes and operations) and the
existing relationships among them. This model is based on Use Case
Model
allowing to integrate
these two visions of the system. 
Figure 5. Artifacts of UIC method. The User Interface Model can be built based on the two aforementioned
models. This model embraces all the aspects related to the interface,
that is to say, the representation of tasks that the user needs to
perform while using the software. This model is formed by an Interaction
Pattern Language and an Interface Model Object, described as follows:
- The Interaction Pattern Language is formed
by a domain pattern which describes the domain to which
the system that is being developed belongs
to. A system can belong to one or more domains. Then, a domain
pattern should reference a system pattern which describes
its purpose, as well
as usability aspects that must be taken into account for the user
interface design. This system pattern will reference
all resulting patterns from
use cases analysis.
- The Interface Object Model is formed by objects
which belong to the Domain Object Model and also are
going to be represented in the user
interface (not all domain objects must be represented in the interface).
Moreover, Interface Object Model can include new objects as a result
of interaction instruments associated to operations, defined as
such in the Domain Model (for example, in an editor cutting
operation is
generally represented by a scissor object). In both cases the result
is obtained by applying a process denominated reification, that
is to say, conversing elements from one model to another
model of lower
abstraction level.
User Interface Model is the basis for constructing
a User Interface Prototype. This is a high fidelity prototype which
is drawn from a
horizontal and evolutive prototyping, as to embrace the whole user
interface.
User Interface Construction Process
Once we have established
Use Case and Domain Object models (which are basically
a part of the analysis activity
of software development
process)
it is time to construct the User Interface Model and the User
Interface Prototype, incorporating prototyping since the
first stages of
an interactive software life cycle.
Figure 6 shows
an activity diagram reflecting user interface construction
process. Next we describe
the activities that take place during
this process. 
Figure 6. User interface construction process.
Constructing a User Interface Model implies constructing
an Interaction Pattern Language and an Interface Object
Model. It appears that these
two activities are carried out one after the other but in the practice
they can be carried out at the same time. The next part describes this
model construction in two steps:
The first step is the creation of an
Interaction Pattern Language from use cases analysis,
this allows detecting interaction points that the
user has with the software; each point (or points) is translated
into a pattern that associates to it the interaction problem
to be solved,
all this from the user point of view. These patterns can be completed
by referencing to other interaction patterns. At the end we will
have a set of related patterns that form the pattern language,
which describes
the user interface.
Once the interaction problem to be solved has
been determined (a problem caused by one or several points
of interaction), pattern
construction
consists in describing this problem as a component of the pattern
and finding the appropriate solution. This solution can come from
reusing
an existing pattern or, on the other hand, creating a new pattern.
If the solution is very complex, it should not be written in a
single pattern, we just describe the essential elements
and use other patterns
to complete the solution; this will be reflected in the component:
related patterns. In addition, another important factor to be underlined
is that the activity of user interface prototype construction will
depend on the way the solution is described. This means that if
the solution is written in a descriptive and graphic way,
the prototype
construction will be easer because it will go from a low fidelity
prototype to a high fidelity prototype.
Once the solution has been
described, it is necessary to establish the context in
which the proposed solution will be appropriated
and the forces that will have an impact on that solution. Moreover,
you
must associate a mnemothecnic identification to the pattern (name)
and an initial confidence (range) with a minimum value (in this
case is 0).
In the case of interaction patterns it is important
to describe the usability impact, which must reflect
the usability aspects
guaranteed
by the pattern application. Also, the system answer should
be described after the pattern is applied, which corresponds
to
the consequences,
and last, we will illustrate a proposed solution using examples
or counterexamples from existing software showing a good or
bad usage
of this pattern. Here is worth mentioning that the construction
order of each pattern component is not rigorous, moreover,
sometimes it
would not be necessary to describe some of the components,
except the compulsory
ones.
The second step corresponds to Interface
Object Model construction. In order to do so we take as
basis the
Domain Object Model
and we apply reification of domain objects establishing its
representation
on user
interface and creating new objects through reification of
operations; in order to do this, it is necessary to define
an interaction
instrument [Beaudouin00]. An interaction instrument is simply
a mediator between
user and interface object. The number of objects from Interface
Object
Model could be greater than those from the Domain Object
Model because objects in the Interface Object Model are
drawn from
reification of domain objects as well as from its operations.
Figure
7 shows an example of reification of a domain object
denominated document and two of its operations: cut and
properties.
The left
side of the figure shows the class Document with some of
its attributes and operations. The right side shows the
corresponding representation
on the user interface of the object document as well as
the interaction instruments associated to their operations.
It
is to be noted
that on the first case a simple interface object is generated
(cut)
and the second case corresponds to a complete window (see
viewProperties),
which is described on a task pattern that belongs to a
pattern language
which describes the user interface of this software.
Figure 7. An example of object and operations reification.
The starting point for User Interface Prototype Construction is a
User Interface Model analysis, that is, a Pattern Language and an Interface
Object Model analysis which can be carried out at the same time.
Pattern
Language analysis can present various cases depending on how the
solution is expressed on interaction patterns. These cases are:
- If
solutions are only expressed on a descriptive way, in order to
produce a prototype it is necessary to implement these solutions
taking
into consideration examples presented on patterns as well as
objects pertaining to Interface Object Model.
- If solutions contemplate
windows layout, which are accomplished by using some tools different
from those to be used to develop
the end product (for example, diagram drawn by hand on paper),
up to
this point we have a low fidelity interface prototype. So,
starting from
this prototype, a high fidelity prototype will be constructed
implementing solutions described on patterns and taking into account
the learning
obtained by the evaluation of low fidelity prototypes and
incorporating objects pertaining to Interface Object Model.
- If pattern solutions
are graphically expressed, by means of an interface design made
using the tools to be used for the development
of end product,
then we almost have ready a high fidelity prototype where
we have incorporated objects pertaining to the Interface Object
Model.
What
is left is to
integrate and implement navigation between screens and
the remaining details, so that this artifact could be executed and
could
evolve
up to become the end product.
Here it must be emphasized that
this work is aimed at constructing a high fidelity prototype, applying
a horizontal and evolutionary
prototyping, so that the prototype will evolve to become
a final product.
Once the prototype has been constructed, it is necessary
to continue developing the software following any object-oriented
process.
The next section will describe the insertion of UIC method
within a Unified
Process. 4 INCORPORATING THE METHOD TO AN OBJECT-ORIENTED
SOFTWARE DEVELOPMENT PROCESS
One of the manifestations of the lack
of integration between Software Engineering and Human-Computer Interaction
is
the absence of precise
guidelines for the creation of user interface in software
development processes. One result of this research is
the proposal of a
user interface construction method (UIC). It is also
worth mentioning
that there are
other results regarding this integration which constitute
investigation guidelines in Human-Computer Interaction,
however at this moment
there are no standards or proposal generally accepted
by the community. Some
of these results can be seen on the edition presented
by Mark Van Harmelen, Object Modeling and User Interface Design [Harmelen01].
As
stated before, UIC method can be incorporated to an object-oriented
software development process, which is
based upon functionalities,
supported by architectures, iterative and incremental.
When we say that it is based on functionalities, it
means that
the process
starts
by identifying the functionalities that the system
will provide. Supported by architecture means that it allows
constructing
several models which
express different perspectives of the system that is
being developed; particularly it is required to model
the functionalities
by means
of a Use Case diagram and modeling objects that make
up the software domain
by means of a Domain Object Model. On the other hand,
the development process should be iterative and also
feasible
to develop in
an incremental way as to become the final product.
Software
Development Unified Process fulfils the aforementioned characteristics
because, among other factors, it includes
the construction of a Use
Case Model and a Domain Object Model. Figure 8 shows
activities as well as the stages belonging to the
Unified Process
as they are presented
in [Jacobson99]; where the user interface construction
is incorporated just as another activity within the
software development process.
As it can be seen in
Figure 8, the greatest effort of user interface construction is invested
during
the phases
of
Inception and Elaboration;
this is because the prototype is built after defining
Use Case and Domain Object models.
Once the UIC
method has been integrated to the Unified Process, what it is left
is a software
development
process characterized
by the
precise and clearly incorporation of user interface
construction, using two
of the UML models and introducing the concept
of interaction pattern and interface object to a user
interface construction. One of the main advantages
of using interaction patterns is the fact that you can successfully
reuse solutions
to recurrent
problems
related
to user interface construction. In order to achieve
its effectiveness it is convenient to use tools
that facilitate
the handling
of reusable components. In this way it is possible
to storage patterns
in a
repository and to recover them to be used for
constructing a particular user
interface.
Figure 8. Unified Process and UI construction
5 CONCLUSION
This work shows interaction patterns as reusable components
which, among other things, capture knowledge. These patterns are simple,
adaptable
and recoverable components, and combined with interface objects constitute
the basis for defining a user interface construction method.
As far
as interaction patterns are concerned, we propose a simple and precise
structure to express these patterns which will help different
professional groups to understand them; groups who could take part
of the development of current user interfaces. Moreover, this work
defines a taxonomy definition and a pattern organization that supports
its creation and usage by interface design specialist as well as other
specialists.
The user interface construction method represents a new
step towards integration between Software Engineer and Human-Computer
Interaction,
establishing precise guidelines for user interface construction and
incorporating this activity within system life cycle systems.
The user
interface construction method has been experimentally validated at
the first semesters of Computer Science at the Central University
of Venezuela obtaining satisfactory results. In addition, it has been
successfully applied in geological modeling software development as
part of a master thesis [Reyes02]. These study cases allowed to simplify
and clean the method showing its applicability and effectiveness.
ACKNOWLEDGEMENTS
The author of this paper would like to thank the Council
of Scientific and Humanistic Development of the Central University
of Venezuela (CDCH)
for financing this research.
REFERENCES
[Alexander77] Alexander, Ch.; Ishikawa, S.; Silverstein,
M.; Jacobson, M.; Fiksdahl-King, I. and Angel, S. “A Pattern
Language: Towns, Buildings, Construction.”, Oxford University
Press, 1977.
[Bayle97] Bayle E, Bellamy R, Casaday G, Erickon T, Fincher
S, Grinter B, Gross B, Ledher D, Marmolin H, Moore B, Pott C, Skousen
G, Thomas
J. “Putting it all together: Toward a Pattern Language for Interaction
Design.” CHI97 WorkShop, 1997.
[Beaudouin00] Beaudouin-Lafon,
M. y Mackay, W. “Reification,
Polymorphism and Reuse: Three Principles for Designing Visual Interfaces”.
Proc. Advanced Visual Interfaces, AVI2000, Italy, May 2000.
[Borchers01]
Borchers, J. A Pattern Approach to Interaction Design. Wiley 2001.
[Borchers00]
Borchers, J. “Breaking the interdisciplinary Limits
of computer-human Interaction Design: A Pattern Approach.”, SIGCHI
vol 32 1, January 2000.
[Borchers99] Borchers, J.; Fincher, S.; Griffiths,
R.; Pemberton, L and Siemon, E. “Usability Pattern Language:
Creating a community.” Report
of workshop at INTERACT’99 (Edinburgh, Scotland, Agosto 30-31,
1999).
[Carroll02] Carroll, John. Human-Computer Interaction, the New
Millenium. Addison-Wesley. USA,2002.
[Casaday97] Casaday, G. “Notes
on a Pattern Lenguaje for Interactive Usability.” CHI’97
Electronic Publications: Late-Breaking/Short Talks URL: http://www.acm.org/sigchi/chi97/proceedign/short-talk/gca.html.
[Coram03]
Coram, T. Y Lee, J. “Experiences – A Pattern
Language for User Interface Design.”, Visited June 2003. URL:
http://www.maplefish.com/todd/papers/Experiences.html
[Erickson01] Erickson, T. “Lingua
Franca for Design: Sacred Places and Pattern Languages.” DIS
2001. URL: http://www.pliant.org/personal/Tom_Erickson/LinguaFranca_DIS2000.html
[Gamma97] Gamma, E.; Helm, R.; Johnson, R.
y Vlissides, J. Design Patterns. Element of Reusable Object-Oriented
Software. Addison-Wesley. USA,
1997.
[Jacobson99] Jacobson, I, Booch, G; Rumbaugt, J . The Unified
Software Development Process. Addison Wesley, 1999.
[Mahemoff98] Mahemoff,
M. Y Johnston, L. “Pattern Language for
Usability: An Investigation of Alternative Approaches.” Asia-Pacific
Conference on Human-Computer Interaction (APCHI’98) Proceedings,
25-31. Tanaka, 1998
[Nielsen93] Nielsen, J. Usability Engineering. Prentice-Hall.
USA, 1993
[Reyes02] Reyes, A., Acosta, E, y Zambrano, N. “Patrones
de Interacción:
su uso en la construcción de la Interfaz de una Aplicación
de Modelación de Medios Geológicos.” RT 2002-01.
Lecturas en Ciencias de la Computación, ISSN 1316-6239. Escuela
de Computación, U.C.V. Apartado 47002 Caracas, Venezuela 2002.
[Rumbaugh99]Rumbaugh
, James; Booch, Grady and Jacobson, Ivar. UML: Unified Modeling
Language. Version 1.3, June 1999. Rational Software
Corporation http://www.rational.com
[Sparks02] Sparks, G. “An
Introduction to UML. The Use Case Model. Enterprise Architect. UML
Case Tool by Sparx Systems”. January,
2002. http://www.sparxsystems.com.au
[Tidwell03] Tidwell, Jenifer. “Common
Ground”. Visited
June 2003. URL: http://www.mit.edu/~jtidwell/common_ground.html
[Usability03]
Usability Group University of Brighton. “The Brighton
Usability Pattern Collection”. Visited June 2003. URL: http://www.it.bton.ac.uk/cil/usability/patterns/
[Harmelen01]
Van Harmelen, M. Object Modeling and User Interface Design. Designing
Interactive Systems. Addison-Wesley. USA, 2001
[Welie00] Van Welie,
M. y Troetteberg, H. “Interaction Patterns
in User Interfaces”, 7th Pattern Lenguaje of Programs Conference,
August 2000, Illinois, USA, 2000. URL: http://www.welie.com/patterns
[Welie03]
Van Welie, Martijn. "Amsterdan Collection of Patterns". Visited June
2003. URL: http://www.welie.com
About the authors
|
 |
Alecia Eleonora Acosta is teacher and
researcher at the Central University of Venezuela from 0ctober,
1988. She did a D.E.A d’Informatique at the Université Paris-Sud
XI, France, September 1992. Next, she obtained her Master in Computer
Sciences at the Central University of Venezuela in 1993. Currently
she is working on her PhD. in Computing Sciences and doing research
around user interface design, patterns, user interface design guidelines,
web design, interface agents. She can be reached at eacosta@strix.ciens.ucv.ve.
|
|
|
Nancy Zambrano Rivas is teacher and
researcher at the Central University of Venezuela from 0ctober,
1976. She obtained her Master in Computer Sciences at the Central
University of Venezuela in 1989. She obtained her PhD. in Computing
Sciences, Informatique at the Laboratoire de Recherche en Informatique
(LRI), Université Paris-Sud XI, 1995. She is researching
around Software Engineering (light methods, heavy methods, object-oriented
methods, Unified Process, software development methods based on
transformations) and Human-Computer Interaction (interaction patterns,
user interface construction methods). She can be reached at nzambran@strix.ciens.ucv.ve. |
Cite this article as follows: Alecia E. Acosta, Nancy Zambrano: “Patterns
and Objects for User Interface Construction”, in Journal
of Object Technology, vol. 3, no. 3, March-April 2004, pp. 75-90. http://www.jot.fm/issues/issue_2004_03/article1
|
