Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

In this chapter, we again discussedthis concept from the perspective to generating a user interface using an extended pattern markup language, UIPML (User Interface Pattern Markup Language).

10.1 Capture and Reuse of HCI (Human–Computer Interaction) Patterns

As discussed in the previous chapters, patterns can be seen as a vehicle—a medium or an infrastructure—to bridge the gap between the two main activities: delivery and discovery. This representation is essentially about how to format the solution in a way that allows it to mature from its solution format into a pattern. In essence, a pattern is a solution alongside other information that supports it. The reason is that in order for a solution to be used by others, they have to be convinced that this is a good solution. Part of this comes by annotating pattern solution with expert analysis and comments, listing of some cases where the solution has been applied and the “success indicators,” and possibly some code examples. Bearing in mind that no two systems are exactly the same, and that every new software is a new adventure, patterns are typically annotated with important guidance on how to apply them in different contexts and situations. Some details are left out to allow the end user to rematerialize an abstract pattern back into a concrete solution that is adapted to the new design. Having decided on what to write, the sibling question would be how to best represent this information: through UML (Unified Modeling Language) diagrams, simple diagrams, images, text, source code, or a combination of all of them.

The success of pattern approach depends on all those three milestones. As we discuss the potential benefits of applying patterns in design reuse, we cannot claim that patterns are “silver bullets.” Due to the inherently creative nature of design activities, the direct reusability of designs represents only a small portion of the total effort (Yacoub and Ammar 1999). It requires a considerable amount of experience and work to modify existing designs for reuse. Many design ideas can only be reused when abstracted and encapsulated in suitable formats. Despite the creative nature of their work, software designers still need to follow some structured process to help control their design activities and keep them within the available resources. Partial automation of this process, combined with sound experience and good common sense can significantly facilitate the analysis and design phase of software development (Arutla 2000). Within this process, tools can help glue patterns together at higher design levels the same way we do with code idioms and programming language structures (Chambers et al. 2000). For example, the Smalltalk Refactoring Browser, a tool for working with patterns at the source code level, assists developers using patterns in three ways (Florijin et al. 1997):

From a pattern user perspective meaning any user interface (UI) designer, we can look at patterns in general as artifacts that have three main milestones, organized from a user perspective (Fig. 10.1).

Fig. 10.1
figure 1

Major milestones and users of patterns

Full size image

On the pattern user side, we can say that patterns are harvested and represented with the main goal of being delivered to other users who implement them as solutions. A delivery paradigm is essential in the pattern approach because it indicates that patterns arrived effectively to potential users; a knowledge dissemination view. This means that patterns should be represented in a way that software developers can learn, master, and apply easily and effectively in their context. This implementation highlights the main role of patterns, promoting effective reuse. If patterns were harvested and written down just for the sake of archiving them, then we have missed on the great benefits of patterns.

On the pattern author side, the discovery of a pattern is only the beginning. Harvesting is a carefully selected metaphor that indicates the hard work associated with patterns. By observing existing artifacts and problems that have been solved successfully, we can detect a repeated structure or behavior that is worth recording. By asserting its importance, we can write down the essential components and—if possible—analyze them. An expert can provide insight as to why this combination is good or why it works well and in what context. Finally, guidance on how to reuse this solution can be added to assist in modifying and reapplying the solution.

10.2 A Survey on Patterns Usages

This section reports the results of a survey on the popularity of patterns among mainstream developers in industrial settings. Our focus is on design patterns for interactive systems as identified early in the design community (Ling 1980; Rouse 1981). They include the design and implementation of UI for highly interactive software systems. The last few years have seen a growing number of new UI-related patterns. Numerous research projects and articles focus on how patterns “should” be generated and used (Alexander et al. 1977) and (Tidwell 1997). We focus on the other end of the journey, namely, how patterns are “actually” being used. The primary contribution of this survey is to investigate how patterns are perceived and applied in practical industrial settings by software developers. Our goal is to identify the current state of affairs and measure the effectiveness of existing pattern approaches and tools. Preliminary results of the survey showed that patterns are less popular among designers than commonly anticipated by research community, even after valuable theoretical analysis and rich pattern literature are produced. The results reflect the strong belief that patterns can indeed be helpful; however, it shows a major gap between this belief and the fact that only few pattern collections are popular, generally the older ones. New patterns are still less popular regardless of their quality. The survey also shows that the number of developers who are actually applying patterns in their work is much less than the number of developers who are just familiar with them.

While pattern authors remained focused on discussing how patterns can be used, we did not find significant studies on how these patterns are actually perceived and applied in practice or how much they contributed to improving the quality and usability of interfaces. Some surveys and studies were done on interface design methods, on users (Colleen and Pitkow 1996; Pitkow and Colleen 1996) as well as interface usability, and how to improve it (Brinck and Hand 1999). Other surveys have focused on existing pattern collections in research community (Mahemoff and Lorraine 2001) and (Portland 2003). We also found empirical studies on how design patterns are perceived and promoted in the academia as a pedagogic tool (Porter and Calder 2004) and (Clancy and Linn 1999). However, we found only one survey made in 1996 on design patterns usage in practice (Beck et al. 1996). The need for more surveys is necessary to assess the large body of research that has been done on patterns since then, and to examine the different directions in which it is evolving.

The research-specific goal behind this survey was to identify the current state of affairs of patterns, and to measure how effective they are delivered and used in software industry. The study enables us to reveal the strengths and weaknesses of pattern practices and to measure the success or failure of current role of patterns in supporting the UI design process. This allows us to shed light on some grey areas in patterns and pattern tools and to have a better understanding of the needs of UI designers from a pragmatic point of view.

10.2.1 The Survey Structure and Population

The survey came in the form of a questionnaire divided in eight sections totaling 20 questions. The first three sections were devoted to get some information about responders and their work environment as well as sources of their professional knowledge. Section 4 and 5 were designed to evaluate their general perceptions and usage of guidelines and pattern. Section 6 and 7 enabled us to get more detailed information about the practices of using patterns and tools in UI design. The last section collected feedback about existing and future research trends and proposals. The survey was distributed during 6 months and sent as a broadcast to selected professional mailing lists as well as personalized emails. We focused on software professionals in industrial settings who are practically involved in the development of software systems and especially in user interfaces. We targeted large companies as well as medium size companies and consultants. The qualified number of replies was 121.

10.2.2 Analysis Method and Key Findings

The survey analysis is organized under three categories. First, we ran a frequency analysis on users’ profile as well as their work environment and knowledge sources. We also evaluated the popularity of pattern collections and tools. Next, we cross-tabulated some questions to report the opinions and practices of patterns among different respondents. All the data collection and statistical analysis were done using SPSS (www.spss.com). Finally, we collected all open-ended questions and analyzed them manually.

Figure 10.2 portrays the distribution of the respondents (Fig. 10.2). The majority of replies (41.3 %) came from developers with involvement in user interfaces. Out of all, 12.4 % respondents were dedicated UI developers, 19 % were system developers with no involvement in UI, and 5 % were web developers. While we only targeted industrial settings, we had 8.3 % professors and 13.2 % students in the replies, which reflect the fact that some people from the academia are indeed working in the industry as well.

Fig. 10.2
figure 2

The distribution of respondents

Full size image

10.2.2.1 Who Develops the User Interface? Who are the Users of Patterns?

The analysis of work environment and responsibilities delegated to development teams (Fig. 10.3) revealed that while a high percentage of respondents worked in UI-related teams (50 %), only a minority (16 %) worked exclusively in interface development teams. The rest (34 %) worked simultaneously in software and interface development. It is clear that the promoted idea of separate and dedicated teams for interface development and the underlying software development did not make its way completely in the industry. However, we did not correlate this to the size of the companies.

Fig. 10.3
figure 3

The responsibilities delegated to development teams

Full size image

When asked about some sources of professional knowledge, the Web was the most commonly used source (86 %), academic training was next (76 %), books (63 %), reuse of similar work (59 %), professional training (46 %), and working with mentors was the least popular at 27 %.

10.2.2.2 The Current Practices of Guidelines and Patterns

Though guidelines are generally considered an important support for designers, only 2.5 % take time to read them carefully and apply them. Out of them, 23 % browse them occasionally, and 66 % do not use them at all in their work. As for the popularity of patterns, 77 % were familiar with design patterns (Gamma 1995), and 40 % with some UI patterns. However, familiarity did not match the actual use of these patterns; only 15 % used UI patterns in industrial projects, showing that most developers know about UI patterns, but do not use them.

The number of popular UI pattern collections was also low. Only seven collections were known to the respondents. Despite the popularity of the Web as a source of professional knowledge, many new UI pattern collections on the Web were not known at all in the survey, regardless of their quality as known in the research community. This certainly requires further study.

10.2.2.3 The Status of Pattern Tools

We identified similar gap regarding existing tools for patterns. Despite the extensive research and rich publications of tool prototypes, only 10 % of respondents used tools. These were mostly general design (CASE) tools like Rational Rose, Eclipse, and Sun Java Studio, rather than specialized pattern tools. Only ten tools were reported in the survey, six of them were mentioned only once.

10.2.2.4 The Mainstream Perception About Patterns

We also asked participants how they thought about patterns. The majority (59 %) saw them as an effective concept while 35 % were not sure. Only 5 % did not like the concept of patterns altogether.

Conversely, when asked about the effectiveness of patterns in practice today, only 29 % found them useful in their design whereas 44 % found them not useful. Nonetheless, developers showed that they still have faith on pattern; only 7 % were on the pessimist side about the future, saying that patterns will never be a real help to developers. Out of all developers, 36 % were optimistic and believed that patterns will help future developers while 56 % were not sure. This shows that patterns are underutilized in daily practices in the industry, but people still believe that they are a good concept. The difference between the high acceptability of patterns as an idea (59 %) and between finding them useful in design (29 %) may indicate that we need to support pattern reuse more actively. It points to the need to improve our techniques to facilitate pattern reuse among industrial developers.

The survey pointed at the problem of patterns underutilization in the industry, contrary to what is expected by most pattern authors. We conclude that besides discovering new patterns, we need to develop more techniques to improve existing pattern reuse and integration into the daily activities of mainstream programmers. We also need more pattern tool support to facilitate this reuse. The next sections summarize some of our research investigations to address these concerns.

10.3 An Extended Schema for Representing Patterns

The concept of a schema is used in many domains to present a high level, common view of different artifacts, or low-level details of them. In this section, we present a high-level schema of patterns based on our investigations in the thesis so far.

10.3.1 Why a Schema?

To conveniently handle the entirety of available patterns within a pattern system, it is helpful to define and separate different parts of each pattern according to the interest of the reader. A pattern classification schema that supports the development of software systems using patterns should have the following properties:

  • Simplicity: It should be simple and easy to understand, learn, and use. A complex schema would be hard to validate and will deter many users from using it.

  • Objectivity: Each classification criterion should reflect functional properties of patterns, for example the kinds of problems the patterns address, the related design phase, and the context of applicability rather than nonfunctional criteria such as pattern author or whether patterns belong to a pattern language or not.

  • Guidance: It should provide a “roadmap” that leads users to a set of potentially applicable patterns, rather than a rigid “drawer-like” schema that tries to support finding the one “correct” pattern.

  • Generality: Like programming languages, the schema should be independent of specific domain, platform, or technology.

  • Extensibility: The schema should be open to the integration of new patterns without the need for refactoring the existing classification.

10.3.2 A Schema for a Generalized Pattern Model

As highlighted in other chapters especially Chap. 2 and 7, the existing pattern language format that has been often used to document patterns looks as follows (Table 10.1).

Table 10.1 Pattern of design and the underlying representation of a design
Full size table

However, this narrative format (and its variations) has several limitations. It makes broad use of natural language-based prose and has little context. Hence, the patterns based on this format are strongly “document-oriented,” and can seem vague and open to interpretation. This limits their use in automated processing environments and interchange.

Furthermore, the notation is paper-printing oriented and does not provide any means of using the potential and benefits offered by the electronic medium of communication which in turns has several implications:

  • There is no standard way in which nontext objects related to pattern (say, solution or scenario of use) can be included.

  • There is no standard way in which instances of pattern expressed in the notation can be interchanged across a broad range of devices.

  • There is no explicit support for presenting patterns expressed in the traditional notation on Internet-based information systems, such as the Web. (The patterns could be written using some word processing package that can associate presentation and linking semantics, and the result can be converted to, for example, HTML. However, such process is not automatic and resulting documents are highly inefficient.).

  • There is no standard way to verify whether a pattern is compliant with the notation.

  • There is no standard way in which pattern solution implementations can be included.

  • There is no explicit support for Internationalization, in particular, for non-English language characters or other special symbols.

These limitations have motivated us to take an alternative approach to devise a pattern notation that can resolve these issues as well as to provide other features that can adequately represent patterns documentation. Representing and documenting patterns using an effective notation enable us to bypass above issues and provides various advantages.

One of our goals is to address the inconsistent properties, elements, and attributes of patterns while findings the commonalities among the variant pattern formats in order to generalize it into a simple, understandable, and flexible format in order to make it easier to document patterns and also to disseminate the essence of patterns to all of its users

Therefore, we use the Alexander’s Format as the fundamental basis of our proposed generalized format, but we also incorporated some of the issues from Gang of Four format in order to reduce the communication gap between patterns writers and software developers and overall to provide the object-oriented outlook of patterns.

We suggest a schema as shown in Fig. 10.4. This schema can be seen as relevant to the end-user experiences, the HCI/usability expert, and the software and UI engineers:

Fig. 10.4
figure 4

Pattern properties

Full size image
  1. 1.

    A pattern is a solution provided by an HCI/usability expert to a user problem, which can occur in different contexts of use.

  2. 2.

    The forces, the consequences of the problems as well as the rationale for the solution has to be detailed qualitatively.

  3. 3.

    Usability/HCI engineers have to ground the patterns in the HCI theory and principles. UI developers should also provide an implementation or strategies for implementing the patterns. Consequences should be linked to usability measures that provide a more objective way to assess the pattern’s applicability.

This abstract schema shows the major issues related to patterns from the perspective of different users. In this, each professional group is aware of their own concerns as well as the others’. Therefore, each group may be able to address the needs of other groups while contributing toward patterns and pattern languages. In this view, we are incorporating some concepts from different pattern collections in order to reduce the communication gap between pattern writers and software developers and to provide the object-oriented outlook of patterns.

This 3D abstraction highlights the major ingredients for documenting a pattern. Table 10.2 provides a summary of the key components that can be used in different pattern templates. This template could serve as a basis for future expansions to serve different needs.

Table 10.2 The proposed format of pattern documentation
Full size table

In Gaffar et al. (2003), we called for an approach to generalizing the format of patterns to facilitate the creation of a pattern database. As the idea was discussed and accepted, we implemented the first attempt of this task together with the major HCI pattern authors. The resulting format, the Pattern Language Markup Language (PLML) was created in the workshop to mark the first step toward a common pattern format (Fincher and Finlay 2003). Since then, we went much further into improving the presentation from a common but static presentation (The PLML is a static format) into a dynamic runtime module. We then upgraded PLML into the Generic Pattern Model (GPM) (Gaffar 2005) that offers the flexibility of changing its components as needed. GPM is then used in the tools that are discussed later in this chapter.

10.4 Modeling the Pattern Discovery and Dissemination Life Cycle

In the previous section, we proposed a schema and discussed its usefulness from delivery perspective. Here, we emphasize this idea and argue that a key factor to increasing the usability and usefulness of patterns is the adoption of a model for a complete pattern lifecycle. This would underwrite the activities that should be taken when identifying a pattern, documenting, delivering, applying, and maintaining it. Creating mechanisms to manage the overall pattern lifecycle has received little attention in the HCI patterns community so far. Our investigations and work as presented in the previous chapters provide a basis for better understanding of the process of discovery, representation delivery, and applications of HCI patterns.

Also as highlighted in the introduction of this chapter, the currently prevalent pattern approaches can be divided into two major activities only: pattern discovery and pattern reuse.

  • Pattern Discovery refers to the activity of writing patterns by domain experts.

  • Pattern Reuse refers to the activity of applying patterns in a useful design as recommended by pattern author.

We could not find significant work on guiding the user through the activity of finding suitable patterns for reuse. This can have negative impact on promoting pattern reuse (as shown in our empirical study (Gaffar 2004)). In this regard we introduce an intermediate logical layer between pattern discovery and reuse, namely, the dissemination process. Pattern Dissemination refers to guiding pattern users through the activities of locating all useful patterns, selecting some of them using different criteria and then applying them correctly in all phases of design and implementation process.

Based on the empirical study and the proposal of dissemination process, we can now redefine the lack of ineffective pattern reuse as a symptom and not a problem. The problem in this chapter is better identified as

  • The lack of a dissemination process

  • The lack of a common and programmable pattern representation to help in combining and reusing patterns and pattern tools in practical design environments. In the previous section, we explain how the generalized pattern model can solve this problem.

Having attributed the problem to the current narrative format for documenting patterns, we propose an approach to represent patterns as software components by identifying and rewriting their semantics as a model for designers as well as design tools. This model transforms text patterns into programmable objects with well-defined interfaces that reflect the knowledge underlying them. This makes them accessible in any object-oriented programming language as well as in XML for tool interoperability. We also provide a framework that supports a comprehensive dissemination process.

10.4.1 The Challenges of Dissemination

Dissemination refers to “the activities associated with delivering knowledge and experience from pattern authors to pattern users—or designers.” For efficient dissemination, we need to reduce the time spent by users in looking up patterns, and the ability to locate all patterns that can be useful according to some search criteria that a user can apply. So far, these activities have been left to the user. Pattern authors simply publish their patterns, generally in books or on the Internet and the dissemination process stops there. Some pattern authors recognized the problem and added links within their collections to other collections. This, however, adds to the confusion of the users as they see similarities between collections. They get distracted or lost in the available maze of patterns. In this context, we have defined the visibility problem that new patterns suffer as “new patterns become diluted in huge pattern offerings and hence get no significant chance of making their way to users.” This has been confirmed by the results of our empirical study. Consequently, many designers limit their pattern repository to few patterns that they already know and rarely look for new patterns.

10.4.2 The 7C’s Lifecycle for Collection and Dissemination of Patterns

We define the 7C’s as “a structured process with the main objective to replace the huge cognitive load of manipulating HCI patterns by both authors and users.” The 7C’s process identifies both logical and physical aspects of the system. The logical aspects detail what actions and activities need to be done. The physical aspects complement the logical ones by specifying the roles associated with each action and activity, and details who is going to do what (Hoffer et al. 2002), (Whitten et al. 2001). As part of the pattern reuse problem is associated with missing roles in the dissemination activities (all left to the user), the 7C’s process addresses both how these activities need to be done, and who should be doing each of them. In short, the 7C’s process moves gradually from current unplanned discovery and use of patterns into building an automated pattern collection. The process comprises seven steps.

10.4.2.1 Combine—Place Different Pattern Languages in One Central Place

Despite the proliferation of research into HCI design patterns since the 1990s, there has been no successful attempt yet to unify these efforts or collections. Numerous works on patterns have been developed in the HCI community; however, they are scattered in many different places. A central repository of patterns will allow users to concentrate on knowledge retrieval rather than spending time on search for patterns.

10.4.2.2 Clear Out—Add on the Top the Different Formats, One Unifying Description

Ideally, different works on patterns deal with different problems. However, as we went through step 1, we were able to identify that some patterns are dealing with different sides of the same problem (correlated patterns), some patterns are offering different solutions to the same problem (peer patterns/competitors), and some are even presenting the same solution to the same problem (similar patterns), only in different collections with different presentation formats. Since a large number of patterns have different presentation formats, it is difficult to detect these redundancies or useful relations with other patterns until the user has spent some unnecessary time with several of them. Putting patterns in a unified format helps discover these relationships, put related patterns closer together, and possibly remove the redundancies and inconsistencies.

10.4.2.3 Certify—Define a Domain and Clear Terminology

This activity is necessarily human-driven. While it can be easy to find useful relationships among the patterns, the validation of good patterns is largely a matter of people assessing them against experiences and through use to decide if they were “really good patterns.” We use a process similar to that of Answer Garden (Ackerman and Thomas 1990) where new pattern proposals are routed to a distributed set of experts in different usability areas. These experts can then provide feedback to pattern writers, pointing them to similar patterns, and otherwise facilitating the process of creating a useful set of patterns.

10.4.2.4 Contribute—Receive Input from Pattern Community

New patterns emerge all the time in many areas of the scientific community, including HCI. It is very difficult to keep track of these emerging patterns. Typically, it would take years before an expert can come up with a thorough collection of patterns (Alexander et al. 1977); (Gamma et al. 1995), or have time to update an existing collection (Tidwell 1997); (Welie 2000). Having a central repository for patterns help unify pattern knowledge captured by different individuals in the future. Furthermore, putting such a repository to use in actual design situations will help to spot areas of design activities where there is a shortage of patterns so that they are made available to the community. The “central” concept refers to either a community wide web-based repository or a local repository within a smaller group of people. In both cases, a repository will help unify the effort of collecting and contributing to patterns.

10.4.2.5 Connect—Establishing Semantic Relationships Between Patterns

A significant part of knowledge associated with patterns lies in the relationships between them. After the Clear Out step removes redundancies, the Connect step is meant to build new connections between patterns. Finding and documenting these relationships will allow developers to easily use patterns as an integral part to develop applications instead of relying on their common sense and instinct to pick up patterns that seem to be suitable. A proven model for the pattern collection helps define ontology for the pattern research area with all proper relationships such as inference and equivalence between them.

10.4.2.6 Categorize—Mapping Patterns into the Assimilation Channels

Within the collection, we need to create pattern classifications or categories to make them more manageable. The first goal of categorization is to reduce the complexity of searching for, or understanding the relationship between patterns. For example, some patterns are just abstractions of other patterns. The second and more important goal is to build categories that can be mapped to different design approaches and methodologies, and then put patterns under their appropriate categories. This is the enabling technique to integrating patterns into different phases of several design approaches. As explained earlier, decoupling the dissemination and the assimilation processes allows same pattern to belong to different categories and be used in different assimilation processes.

10.4.2.7 Control—Machine Readable Format for Future Tools

Defining pattern models that accurately represent pattern semantics through their interfaces and rewriting patterns according to these models enhances the process of automating UI design using different assimilation processes. The ultimate goal of the 7C’s process is to allow user to interact with the machine as a viable partner that can read and understand patterns, and then process them in an intelligent way. Having machine-readable patterns is the last step in the process of pattern dissemination and the first step toward assimilating them.

10.4.3 Qualities of Design Patterns

The idea behind the 7C’s lifecycle is not to collect all patterns, but only good one. There are several factors that can define the quality of patterns. They are what make the pattern usable and easy to apply.

10.4.3.1 Formality

There have been several efforts (Gamma 1995; Appleton 2000) that provide strategies and suggest guidelines for patterns documentation. However, one of the limitations of these guidelines is that they make broad use of natural language for description, and hence are less formal and vague. Frequently asked questions (FAQs) also help answer user questions but they are usually focused on a single topic, often specific to a technology, and rarely provide reasoning for their answers. Patterns are more formal in their approach and exist at a higher level of abstraction than the strategies or guidelines. Patterns offer various advantages over guidelines and are anticipated to play an essential role in information technology. Still, patterns do not attempt to necessarily replace the FAQs, strategies, or guidelines in every manner. Rather, they should be considered as a key complement to overall initiative of a business application realization.

10.4.3.2 Practicality

Patterns provide practical “ready-to-go” solutions. A pattern describes “good” practical solutions to a common problem within a certain context, by describing the invariant aspects of all those solutions. Given a problem, patterns include a compact, focused, complete, and straightforward way of describing a solution. Since they provide the consequences of applying that solution, the user can decide and act upon in a timely manner if the solution is applicable to his/her situation.

10.4.3.3 Experience

Patterns form an “expert” system in practice. Patterns, when well-defined and coordinated, are more than a mere static disjoint “collections” of recipes. Patterns are tried-and-tested ways to deal with problems that recur. It is expected that those who have experience in a particular field of knowledge will have internalized certain solutions to these problems. As a result, they recognize a problem to be solved and know which solution need to apply in the particular situation. A pattern describes this internalized expert knowledge and states the problem, context, and solution, so that others with less experience can benefit from this knowledge. In this sense, patterns themselves can be considered as a “smart FAQ” or an “expert system” that encapsulates the knowledge and experience of the author. This enables them to be used as a knowledge base.

10.4.3.4 Reusability

A pattern presents a higher-level view of the same problem inflicting often multiple industries and provides a solution for it. It can also connect to other patterns in existence (in the same or other catalogs) for whole or in part of its solution (inheritance). Patterns thus encourage reuse.

10.4.3.5 Abstract, Modular Framework

Complex problems are often composed of several steps that need to be dealt with independently and then combined to arrive at a solution. Patterns represent these steps at a high level via “intelligent” distribution and allocation of responsibilities. They provide a framework that works in unison to fulfill a given task.

10.4.3.6 Community

Patterns help a broad community. Patterns communicate solutions to a community of architects, designers, and engineers, who make use of them at different levels and for different purposes. The goal of the pattern community is to build a reusable body of knowledge to support design and development in general.

10.5 Tools Support for Pattern Reuse and Dissemination

Beside the pattern lifecycle and representation, one of the key elements that explains the misuse of patterns also is the lack of tool support, which makes it difficult to capture, disseminate, and apply patterns effectively and efficiently. Tools need to be developed with three major objectives in mind. First, tools are needed to support UI designers and software engineers involved in UI development. Second, as a research forum for understanding how patterns are really discovered, validated, used, and perceived, tools are also required. Third, automation tools are needed to support the usage of patterns as prototyping artifacts and building blocks.

The following are some of the required features that should be provided a tool supporting the pattern approach:

  • Tools have to be designed to accept proposed or potential patterns in many different formats or notations. Therefore patterns in versatile formats can be submitted for reviewing.

  • A common editorial board for reviewing and validating patterns is also required. Before publishing, collecting and contributing, patterns must be accessed and acknowledged by the editorial committee. We are inviting the HCI patterns practitioners and researchers to set up and join this committee.

  • A pattern ontology editor to capture our understanding of pattern concepts and to put them into relation with each other (Taxonomy) will be an important step toward a systematic usage of patterns as well as the emergence of a pattern-assisted design tool.

  • Tools are needed to allow us to attach semantic information to the patterns. Based on this information and our ontology, patterns will be placed in relationships, grouped, categorized, and displayed.

  • A pattern navigator can also provide different ways to navigate through patterns or to locate a specific pattern. The pattern catalogue can be browsed by pattern groups or searched by keywords. Moreover, a pattern wizard will find particular patterns by questioning the user.

  • A pattern viewer will help in providing different views of the pattern, adjusted to the preferences of the specific pattern user’s need.

  • In what follow, we presented two different types of tools. First, the use of online databases accessible as a vehicle to document and share patterns on the Internet. Second, we introduced an integrated pattern environment that supports the dissemination process as well as the pattern-assisted design and automated code generation.

10.5.1 An Online Database for Patterns Documentation and Sharing

Too often, good patterns are hidden in Web pages that become severely underused in the daily activities of interface designers. This is because, the web page approach alone fails to provide the means to access appropriate patterns as needed and does little on the way of reusing them as an integral part of the development processes. Even if pattern authors are actively discovering and writing new patterns, it is difficult for users to keep pace with changes in the HCI community at large just by searching the Internet. Designers and developers often work under tight constraints and limited resources. Eventually, if software developers have to manually read, analyze, and understand every pattern in details to select the ones they need, the pattern system becomes unmanageable, even when it included useful patterns.

A better approach is to put patterns in a central database and make it accessible online through the Web or other Intranet facilities. A database of patterns can become a valuable resource that software developers and project managers depend on for efficient information retrieval and reuse (Fig. 10.5).

Fig. 10.5
figure 5

The online database approach for capturing and disseminating patterns

Full size image

Compared to Web pages and document-based approach for capturing and delivering patterns, an online database has some advantages:

  • Scalability: A separate database can store and manage larger data volume than files attached to a specific application.

  • Facilitate efficient updates: Unlike flat text files, a database categorize its contents into tables or objects which helps improve the lookup and editing of contents.

  • Connectivity: Several applications can connect to the same database, reducing the need for extra copies of data files and multiple updates (see integrity).

  • Promote interaction with other software: A database can provide application-independent information that can be called and used by several software tools and applications.

  • Reliability: A database usually has advanced capability to enforce reliability against mishaps like programmer errors and power outages.

  • Integrity: If properly designed, database can ensure integrity by having a single copy of each data object, so changes can be centralized to one place. This can greatly reduce redundancy and inconsistency.

10.5.2 Pattern-Based Assisted Dissemination and Design Environment

The central aspect of automating pattern-oriented design is its dependence on a predefined process. An established design process instigates quality design by allowing designers to follow structured methods in their activities. In our approach, we established the need for both dissemination and assimilation processes. We implement the dissemination process completely decoupled from any specific assimilation process. This allows it to offer patterns that can be integrated simultaneously in several assimilation processes. “Free patterns” that do not belong to any process are hard to integrate in design. Similarly, “proprietary patterns” that are specifically tailored to manually fit one design process using one specific example defeat the main purpose of pattern generality and abstraction. We see that a pattern can be integrated in several assimilation processes by properly encapsulating its knowledge and presenting its behavior through a well-defined interface.

Furthermore, there is usually more than one way to implement a specific pattern in different software systems. Furthermore, given the wide variety of user interface styles and development platforms, each pattern implementation can exist in various formats. For example, the Web Convenient Toolbar pattern that provides direct access to frequently used pages such as What’s New, Search, Contact Us, Home Page, and Site Map, can be implemented differently for a Web browser, and a Personal Digital Assistant (PDA). For a Web browser, it can be implemented as a toolbar using embedded scripts or a Java applet in HTML. For a PDA, this pattern is better implemented as a combo box using the Wireless Markup Language (WML). It becomes more convenient due to the PDA-related limitations like screen area, bandwidth, memory, and processor speed.

10.5.2.1 Usability Pattern-Assisted Design Environment (UPADE) Architecture

UPADE provides a unified interface to support the development of UI designs and improve software production. It is a prototype written in Java that aims to support HCI pattern writers and UI developers. By leveraging the portability and flexibility of Java, UPADE enables developers to easily and effectively describe, search, exchange, and extend their own patterns as well as those created by others. UPADE offers features to combine patterns while supporting their integration at high design level and automate their composition.

As a tool for automating the development of UI designs, UPADE embodies several functionalities. It helps both pattern writers and developers to use existing relationship between patterns to define new patterns or create a design by combining existing patterns. Moreover, in order to facilitate pattern combinations, the tool supports different hierarchical, traceable design levels. In our case study associated with UPADE, three levels are possible: pattern level, design level, and code level. At the pattern level, developer can see description of patterns, search a specific pattern, create a new pattern, and save it into the database. At the design level, developers can combine patterns, support the integration of patterns at different design stages, replace one pattern occurrence by another, and validate the selected pattern compositions. Finally at code level, developers can see the structure of the design in terms of classes, methods, associations, and inheritance relationships in a particular programming language. Additionally, UPADE provides a mechanism to check and control how patterns are created or modified. By using the database information, UPADE automatically examines the patterns and offers a related feedback to the designer.

10.5.2.2 Key Features Offered to Both Pattern Authors and Users

The main UI includes the following components (Fig. 10.6):

Fig. 10.6
figure 6

Navigating and selecting patterns

Full size image

  • “Browse” provides a description of existing patterns, some illustrated diagrams, and several practical examples. In this mode, UPADE produces and delivers patterns information. The information is presented using the incorporated format showing related design processes, pattern category, name, description, and examples. Categories are presented as a browse tree for navigation as shown in Fig. 10.5. By default, UPADE allows browsing patterns with their associated process name. However, software developers can switch to browse by category.

  • “Search” improves efficiency of using UPADE by accelerating the searching of patterns. The search window presented to developer offers two kinds of searches. Users can have a simple search for patterns by keywords. They can also select from several advanced search criteria in the ‘Criteria Combo Box’ and apply it.

  • “Edit” helps developers create their own patterns or modify existing ones. Since patterns are reusable components, a well-developed pattern should be saved for reuse in other designs (Florijin et al. 1997). UPADE allow developers to create new patterns and associate new implementation rules, or constraints with them. The use of constraints allows developer to decide how certain patterns can be combined with each other in the design mode.

  • “Design” develops structured steps to combine patterns, support integrating them at several phases of design, and validate their composition. As shown before, besides describing a solution, a pattern also describes several possibilities of how it can relate to other patterns and how it can be composed of other patterns. In this way, the generic nature of patterns is preserved. The creativity of design is also preserved by allowing designers the freedom to mix different patterns together. The process of freely mixing patterns together can be hard to validate in a complex network of patterns. Relationship constraints guide users into avoiding “invalid” or “less preferable” combinations and warn about unforeseen consequences. By offering validation of pattern relationships, UPADE helps designers in selecting more appropriate combinations during their design.

In “Design” mode, UPADE can support combination and organization of existing patterns from more general to more specific details. For example, the software developer can embed “Page Managers” patterns into “Information Architectural” patterns, and both “Navigation Support” patterns and “Information Containers” patterns into “Information Architectural” patterns. Moreover, the designer has the freedom to organize “Navigation Support” patterns and “Information Containers” patterns inside the layout; they can move, combine, or delete them altogether. These activities aim to explore how to organize and combine existing patterns to customize and format the new ones. “Design” editor provides a mechanism to check the validity of combined patterns using the set of constraints associated with them. It examines the compatibility of certain patterns and gives the related instruction to the designer.

Once the “Design” tab is selected (Fig. 10.7), UPADE can help start a new pattern-oriented design as follows:

Fig. 10.7
figure 7

Combining patterns in a new design

Full size image

  • Pattern developers need to browse the tree in the “Browse Tree Pane” to view available patterns.

  • Then they can select a pattern and drag and drop it into the “Drawing Pane” area.

  • They repeat these two steps until all desired patterns are collected into the drawing area.

  • Next, by selecting “Link Mode” button, developers are guided to connect each pattern to others by choosing from different relationship types that are available in the combo box of the control menu. While developers can choose the way they want to connect patterns to generate their own design, and the type of relationships, UPADE will check the validity of all connections selected by users and allow only valid ones. Users can override this mechanism, but they are provided with the consequences of their selections to help them make informed decisions. At the end, the developer can save the new pattern composition map into XML format for use by other XML-compatible tools.

UPADE is designed to be customized and extended, with the realization in mind that some designers have achieved a local set of patterns and conventions for style and structure, and only need a tool to assist them in creating new design more quickly that honors those conventions.

10.6 Key Contributions

Despite the wide acceptance of HCI design patterns within HCI and software engineering community, the current process of pattern reuse is a simple process of publishing numerous patterns using different media, and leaving it up to the users to do their best in figuring out how to trace and use them.

We suggested an addition to this concept to help define and standardize the process of pattern dissemination and assimilation. This process leads to an effective reuse of the knowledge contents within patterns. We proposed and developed UPADAE, first as an online digital library to share patterns, and then an environment to patterns-assisted design approach. In both categories, we prototyped several options at the database level (persistent layer), the processing level (tools), and the UI for both pattern writers and users.

The generalized pattern model and the associated notation to represent pattern have been discussed to facilitate interaction between patterns authors and users, and to pave the road for code generation from patterns descriptions.