Developing a UI Pattern standard
Synopsis
This document is a discussion on the development of a UI Pattern standard for the Enterprise Pattern Exchange (EPE).
Table of Contents
Developing a UI Pattern standard
Synopsis
Table of Contents
Introduction
Audience
Why UI Patterns?
UI Patterns represent an opportunity for cooperation
The EPE
Why develop a UI Pattern standard?
Reducing confusion between alike patterns
Promote new patterns
A standard interface
Win win win
The anatomy of UI Pattern standard
A classification system
A documentation system
Analysis of some UI Pattern collections
Martin Welie - UI Patterns
Jennifer Tidwell - UI Design Patterns
Sari Laakso - User Interface Design Patterns
van Duyne, Landay and Hong - The Design of Sites
Yahoo – Design Pattern Library
Pattern markup language PLML
System proposal
System Rationale
Documentation system proposal
Part 1
Part 2
Part 3
Introduction
“large-scale deployment of patterns with explicit contextual representations have the potential to become a significant tool in both the software development process and the scientific understanding of usability for software applications”[1]
It is accepted that UI Patterns hold the potential to increase the efficiency of the software development process. This prospect has led to intense interest in UI Patterns by companies where software development is a core process – such as Oracle.
Audience
This document has been written primarily with contributing members of the EPE in mind. It is hoped that it will not be taken as a blueprint but rather as a discussion to spur decisions on the final shape of a UI Pattern standard to be implemented by the EPE.
Why UI Patterns?
“a pattern can be a useful vehicle to encapsulate the essence of a recurring problem, its analysis and solution”[2]
UI Patterns prepackage best practice guidelines and principles into ready to use components. They enable developers to conveniently solve common design problems. Their implementation also reduces the possibility of developers synthesizing what are often “slightly original” solutions to these common problems – increasing consistency and usability.
However for UI Patterns to be effective they need to be finely balanced between too fine grained and not fine grained enough.
“What chunk of knowledge—at what grain size—is appropriate to “qualify” as an independent pattern?”[3]
Too fine grained
Much of the value of a UI Patterns to developers is their less granular nature. Consideration needs to be given to provide patterns not so granular as to require developers to combine them to solve common design problems.
“Last year’s CHI patterns workshop demonstrated that even human factors specialists find it difficult to apply abstract patterns to specific design problems.”[4]
Not granula enough
UI Patterns that are too granular are also a problem. Two main issues occur with this type of pattern:
- They are commonly passed over by some developers who do not recognize the pattern as a solution to their problem
- They required extensive modification by developers
“What this requires, of course, is to strike the right balance between too technology-centric, short-lived patterns that essentially only describe what one particular (often graphical) user interface toolkit already implements, and “golden rules” that are always right, but never concrete and constructive enough to be of real value to the designer.”[5]
UI Patterns represent an opportunity for cooperation
The very nature of a UI Patterns requires that they be familiar to end-users. In many cases the less proprietary the UI Pattern the more effective it can be in solving a design problem. This characteristic makes UI Patterns an excellent opportunity for pattern writers to come together.
The EPE
The Enterprise Pattern Exchange (EPE) is an ambitious project, which aspires to become the major online UI Pattern resource for pattern writers and user alike.
Some of the features proposed include:
- The most comprehensive collection of patterns publicly available online to date (Oracle, Yahoo, eBay and Tidwell)
- Discussion threads for all patterns (including RSS feed generation)
- Pattern submit tool
- Search tools
- Role based access for patter writers, users and assessors
- Distributed pattern management tools
- Pattern usage statistics
The EPE was initially an internal Oracle project however more recently interest has been shown by other organizations and individuals to come together to publish a consolidated UI Pattern catalogue. It is expected this online catalogue would not be dissimilar to the now defunct but innovative MOUDIL project.
The development of this resource will present many challenges not least being the agreement on a standard to consolidate the patterns presented. Currently UI Patterns are classified and documented in various manners across publishers. Some substantial standardization efforts have occurred such as the development of PLML but to date not widely adopted. For the EPE to go ahead, the important question of this standard needs to be resolved.
This document looks to:
- Explain the rationale for a UI Pattern standard
- Provide a discussion on the makeup of a UI Pattern standard
- Provide an analysis of some of the current pattern collections
- Present a UI Pattern standard proposal
Why develop a UI Pattern standard?
“As these collections” have emerged, work has polarized and small groups have formed taking specific (and often divergent) stands.”[6]
The successful introduction of a single standard would not only be an enabler for the EPE project but is believed will further increase the value of patterns for software developers generally. It is suggested that a strong indicator of success of the EPE would be the general adoption of the standard implemented by the EPE.
Reducing confusion between alike patterns
“Putting patterns in a unified format will help discover these relationships, put related patterns closer together, and possibly remove the redundancies/inconsistencies.“[7]
Not surprisingly many of the same patterns exist across collections. A standard has the potential to help developers make sense of all these patterns and their different versions across collections.
Promote new patterns
“a strong structuring principle would be predictive; allowing researchers to identify
and seek out areas indicated by ‘holes’ in the content”[8]
The application of a standard classification system is likely to make the “holes” in the current crop of UI Patterns more apparent which in turn should result in the increased pace of development of new patterns to fill the spaces.
A standard interface
“It is then important to express patterns in a way that can be both human readable and machine processable” [9]
As the number of UI Patterns increases, tools to help developers find the most appropriate pattern to fit their need becomes more important. With a standard in place such tools will be compatible across collections.
Such a standard machine-readable interface also enables the tight integration of patterns within development tools to the extent where they can be automatically bound to entities within a data model. This holds the potential to find even further efficiencies for developers.
Win win win
A UI Pattern standard is likely to increase the potential to win for:
- Software companies by reducing the risks and costs associated with tightly integrating patterns into their development processes
- Developers through easier access to faster growing collections of more convenient (specialized) UI Patterns
- End users through the wider adoption of UI Patterns by developers resulting in more consistent and easier to use applications
The anatomy of UI Pattern standard
“A pattern can be seen as a bean of experience”[10]
It is possible to breakdown the makeup of a UI Pattern standard into two major areas of concern:
- classification
- documentation
A classification system
“private notes and sketches, gathered promiscuously, until the difficulty of selection and arrangement became so apparent that I began to classify them”[11]
As the quantity of objects in a collection increases so does the importance of the ability to classify them. In the case of UI Patterns the means of classification is not immediately obvious, however as more and more patterns are written, suggested as increasingly necessary.
To facilitate this discussion on the makeup of a UI Pattern classification system the following diagram and associated term are definitions are proposed:
Figure 1 - Classification terms diagram
a)System
A term used to describe the complete classification approach. It is possible that multiple classification “systems” could be supported by the EPE.
b)Type
A term used to describe each hierarchy level in a System.
c)Node
A term used to describe each entity within a Type.
d)Pattern
A term used to describe an individual UI Pattern within a Node.
Classification efficiency
A System implements tiers to enable users to find patterns. It is commonly recognized that the efficiency of hierarchy as a human interface is reduced if the entities grow out of proportion with each other resulting in either and overly deep or flat tree structure.
As such, to be effective a System needs to contain a balance of Types and Nodes in relation to the total number of Patterns it contains. It is suggested that the number of Types (hierarchy tiers) would be optimal when the number of nodes within any one Type was greater than three and less than twenty.
Types
On analysis of a number of pattern collections the following Types are proposed as likely candidates for inclusion in a System:
- Function
- Client
- Level
Function
The Function Type is the most obvious classification and is implemented by the majority of collections. As its name suggests, Nodes within the “Function” Type group by functional content.
Examples of Nodes of this Type:
- Welie – “Page Elements”
- Tidwell - “Showing Complex Data”
- Laakso – “Selecting and Manipulating Objects”
Client
“Are HCI/UI design patterns different for different targets (platform, operating system)?”[12]
The Client Type is used to group by platform target. This classification Type is implemented in the Welie collection.
Examples of Nodes of this Type (within the Welie collection):
- “Web Design Patterns”
- “GUI Design Patterns”
- “Mobile Design Patterns”
There is some debate as to whether binding a pattern to a specific client reduces the its timelessness. However I believe this Type is interesting as its inclusion is likely to open up “spaces/holes” for pattern writers to develop content useful to developers working with less popular/generic platforms.
Level
“the level of cities, then neighborhoods, houses until the level of windows” [13]
The Level Type groups by what could be described as granularity. To date no collections (this author has analyzed) have implemented this Type. Rather Level groupings have been relegated to Nodes within a Function Type.
For example:
- Welie - “Navigation” and “Basic Page Types”
- Tidwell – “Organizing the Content”
- The Design of Sites – “Creating a Navigation Framework” and “Design Effective Page Layouts”
Proposed examples of Nodes of this Type:
- Information architecture
- Screen architecture
- Site furniture
- Site principles
“the user may first be encouraged to consider content issues, followed by general structural and navigation elements, finishing with attention to detailed layout decisions”[14]
The is suggested this Level Type would add value to a System in the following ways:
- It is likely the EPE will be called to support greater than 500 Patterns. A third Type (hierarchy tier) would increase the efficiency of the System as the number of Patterns grows to and above 1000.
- Nodes with the Level Type can be used effectively to scope Patterns based on point in the development lifecycle.
- This Type will allow elegant support of multiple grains of Patterns within the same System.
A documentation system
“What information or knowledge necessarily must be included in the pattern?”[15]
The way UI Patterns are documented across collections found on the web is considerably varied. However on analysis of a number of pattern collections it is suggested that the documentation of Patterns can be broken down into three main areas of concern:
- Description
- Classification
- Verbal
- Visual
- Rationale
- When to use
- How it works
- Why it works
- Associations
- Related patterns
- Pattern examples
- Revision history
- Commentary
Analysis of some UI Pattern collections
The following is a high-level analysis a number of UI Pattern collections. Notes have been made in relation to each collections form in relation to standard anatomy as discussed in the previous section of this document.
Martin Welie - UI Patterns
Figure 2 - Welie classification map
Figure 3 - Welie documentation tree
Notes
- Patterns are classified by Client and Subject
- Subject classifications include a mix of content and functional types.
- Some of the Subjects such as “Navigation” and “Basic Page Types” could be regarded as Level classifications
- Patterns are documented with parts 1 to 3
- Rich in embedded images
Jennifer Tidwell - UI Design Patterns
Figure 4 - Tidwell classification map
Figure 5 - Tidwell documentation tree
Notes
- Patterns are classified by Subject type only
- Some of the Subjects such as “Organizing the Content” and “Getting Around” could be regarded as Level classifications
- Some of the patterns described are fine grained and could be regarded by some more as design guidelines or principles, for example: “Few Hues, Many Values” and “Prominent Cancel”
- Patterns are documented with parts 1 to 3
- Relatively rich in embedded images
Sari Laakso - User Interface Design Patterns
Figure 6 - Laakso classification tree
Figure 7 - Laakso documentation tree
Notes
- Patterns are classified by Subject type only
- Pattern documentation is light weight not including Part 2 type content
van Duyne, Landay and Hong - The Design of Sites
Figure 8 - Design of Sites classification map
Figure 9 - Design of Sites documentation tree
Notes
- Patterns are classified by Subject type only
- Subject classifications include a mix of content and functional types
- Many of the patterns described are fine grained and could be regarded by some more as design guidelines or principles, for example: “Above the Fold” and “Familiar Language”
- Some of the Subjects such as “Designing Effective Page Layouts” and “Creating a Naviation Framework” could be regarded as Level classifications
- Patterns are documented with parts 1 to 3
Yahoo – Design Pattern Library
Figure 10 - Yahoo classification map
Figure 11 - Yahoo documentation tree
Notes
- This collection provides no classification types
- Patterns look to be focused on “Rich” Client
- Patterns are documented with parts 1 to 3
- Features in part 3 of the documentation tree are advanced compared with other collections
Pattern markup language PLML
PLML pronounced “pelmel” is an XML based markup language developed by participants of the CHI2003 workshop - Perspectives on HCI patterns: concepts and tools. It represents probably the closest thing to a standard existing to today to document UI Patterns.
PLML was released in the form of a DTD for download. I have taken this and converted it into an XSD using XMLspy and generated some sample XML including:
- all elements and attributes both required and optional
- two iterations of repeating elements
The following is a high level analysis of the language.
Figure 12 – documentation tree
Notes
- Patterns are documented with parts 1 to 3
- Part 2 looks to be structured very differently from most of the collections previously reviewed
- The unique inclusion of a “management” tag
System proposal
Figure 13 – proposed classification System
System Rationale
It is suggested that a three Type System will be required for the EPE due to the large number of Pattern it will be required to support. This extra tier will help to not only keep the hierarchy in proportion but also provide “spaces/holes” for Pattern writers to focus their energies.
The Types have been ordered inversely proportional to the likely number of Nodes in each Type. It is suggested that the Client Type will have the fewest number of Nodes and as such would appear at the top of the hierarchy.
The proposed three Client Nodes are:
- Thin
Patterns relating to paged internet applications (PIAs) - Thick
Patterns relating to rich internet applications and desktop GUIs - Mobile
Patterns relating to small screen (handheld) devices
The middle hierarchy Type is Level with four proposed Nodes:
- Information Architecture
Patterns relating to navigational organization - Screen Architecture
Pattern relating to screen layout - Furniture
Course grained patterns relating to screen content - Principles
Fine grained patterns relating to screen content
The last and most Node populous Type is Function. No Nodes are proposed in this Type at this time.
Documentation system proposal
Like anything as detailed as a syntax standard it is likely to require considerably negotiation with all EPE parties present to finalize. At the same time it should be design to grow elegantly as new ideas and requirements come into being.
The design proposed is probably best described as a simplification of PLML. I have instigated nesting tags – “description”, “rational” and “related-content” to define the proposed three parts discussed previously (see- The anatomy of a UI Pattern standard). These nests help make the code more readable for humans and modular for machines.
Part 1
This section has been kept very similar to that of PLML. The “confidence” and “alias” tags have been removed and replaced with an “index” tag to embed the classification system. This approach should allow the increase index nodes through time if required while at the same time providing filter hooks for search tools.
Part 2
Considerable change has taken place in Part 2 where the more standard what, user-when, why approach taken by the sampled collections has been incorporated with the inclusion of an embedded “content” tag to make it more flexible to different weights of content.
Part 3
Once again very similar to PLML however I added a new “blog-link” tag.
[1] Capturing and Disseminating Usability Patterns with Semantic web technology - Scott Henninger, Mohamed Keshk, Ryan Kinworthy
[2] Tool-based Decision Support for Pattern Assisted Development - Sharon L. Greene, Paul M. Matchen, Lauretta Jones, John C. Thomas, Matt Callery
[3]Perspectives on HCI Patterns: Concepts and Tools - Sherman R. Alpert
[4] Capturing and Disseminating Usability Patterns with Semantic web technology - Scott Henninger, Mohamed Keshk, Ryan Kinworthy
[5]Patterns as a link between HCI and architecture - Jan Borchers
[6] Perspectives on HCI Patterns: Concepts and Tools - Sally Fincher, Janet Finlay, Sharon Greene, Lauretta Jones, Paul Matchen, John Thomas, Pedro J. Molina