Tag Archives: patterns

SwissCHI event Mar 26, 09: “Interaction Design Patterns in the Real World”

On March 26, 09, the monthly SwissCHI event focused on "Interaction Design Patters in the real world". A panel of six experts plus an advocatus diaboli came together to exchange opinions and experiences on design patterns, but it quickly became clear that they weren't talking about the same thing at all: They were arguing on very different levels of abstraction, from controls to actual design patterns.

An initial definition of an interaction design pattern reads:

  • A proven solution to
  • A recurring problem
  • in a defined context

Participants in the discussion were:

  • Marcel Brunschwiler, UBS AG
  • Christian Hübscher, Zürcher Kantonalbank
  • Bernhard von Allmen, Roche Diagnostic
  • Thomas Kneubühl, MAS HCID
  • Stefan Schallenberger, eGovernment Kanton Aargau
  • Frank Leidermann, Swisscom AG
  • Daniel Felix had the role of the Advocatus Diaboli
  • Christian Hauri moderated the session

Marcel Brunschwiler, UBS AG, opened the session. UBS is using design patterns as "aid to self-aid" for better UI design (and to free up resources in the usability team for more challenging tasks). They don't really have interaction designers at UBS; instead Business Analysts are defining everything. There used to be a style guide that also defined how certain elements were to be applied.  UBS AG's pattern effort started with a big document. Later they switched to an HTML-based tool that featured a description of the pattern, its application, and related patterns. Future releases will incorporate best practice examples. The pattern library has already been in use for some time. Christian Hübscher, ZKB, seconded Marcel's description – at ZKB, too, Business Analysts describe the GUIs. They usually don't have any background in HCI. Currently, their pattern library is limited to one application. This app is based on an organically grown piece of standard software (which, by now, shows a huge degree of inconsistencies). They have been building up their pattern library within the context of a redesign project. They're using a Wiki. The Business Analysts aren't using it for their daily work yet, though. This shall be changed in the course of the introduction of a new spec process, in which specs will be linked to the library. They're also building the library into their prototyping tools. From the ZKB's point of view, the pattern library needs to be well-structured and needs to be available electronically.

Daniel Felix jumped in as the advocatus diaboli and pulled out a number of style guides, asking: What's new about this actually? He said all the pattern stuff has been there before, even linking all the elements can be found in earlier style guides. This at least triggered a longer discussion on the question whether controls and patterns are the same, which showed clearly that most of the audience wasn't quite sure about or familiar with the concept either. In the end, it was mentioned that the big difference is that a pattern library should always go from the problem to the solution, while a style guide usually starts with the solution and then describes where to apply them. Bernhard von Allem, Roche, told us of how they started out to define a style guide and later realized they had actually defined patterns, as they had started from the problems. For him, a spec contains information on colors, fonts etc., stuff that doesn't belong in a pattern definition. He pointed out that patterns were "management compatible" – they are easy to "sell" to management.

Stefan Schallenberger, eGovernment Kanton Aargau and MASHCID student, related that they had derived their patterns from requirements and paper prototypes. For him, it's important that a pattern library isn't just a collection of stuff, but needs to be accessible (they're using an HTML tool). He said patterns limit the solution space and help to achieve consistency. At Kanton Aargau, the project has been a success: they're planning on redesigning 80 internal apps. Thomas Kneubühl, Postfinance and also MASHCID student, told us about his project "Patternfinder", which looks at why patterns aren't used more heavily and how to make them more accessible. He found 1400 pattern descriptions in 40-50 libraries, which could imply a high level of redundancy. Interviews within their internal development department revealed that patterns were completely unknown. They were looking at involving the future users of the library more, e.g. by having them create their categorization scheme themselves, using tags etc.

Finally Frank Leidermann, Swisscom, spoke about the customer center application, and organically grown, very inconsistent app. They put together a pattern library that abstracted heavily from the actual UI and relies on, among other things, inheritance. It partially contains controls or styles, partially flow diagrams.

The subsequent discussion focused on the following points:

  • Patterns are very interesting for HCI experts, needs to be defined by HCI experts and made available; the target audience, though, isn't usually HCI experts. No-one needs to be afraid that a pattern library could turn everybody into an HCI expert (and render us out of work). It does allow HCI experts to focus on the really interesting issues, though
  • A pattern library should never be released without proper training, and their usage implies common sense. Engineers were looking for solutions to copy anyway
  • Patterns aren't the same as guidelines. There should be one solution per problem that a company should agree on
  • Pattern Languages are valid within a given domain and move within certain forces, e.g. what's feasible technically
  • Do patterns need to be updated? Should we collect older versions? Are patterns that need to be updated patterns at all? Aren't pattern technology-agnostic?

As for the future of design patterns ("what's going on with patterns in ten years' time?"), the panelists saw these options:

  • Patterns will be tied into design tools and IDEs
  • Pattern libraries and guidelines will live side-by-side
  • The hype will have died down
  • Those who understand them will use them; those who don't will ignore them

Using User Interface Patterns as a Design Framework

Design Frameworks in UI Design have come some way. Starting out as conventions amongst designers, then platform standards or standards across a number of platforms, to a written-down and agreed-upon set of guidelines, we have arrived at pattern libraries. Just recently Yahoo! released their UI pattern library to the public, allowing designers to profit from their research and development effort. Design Frameworks not only offer guidance as to how to design things so that a certain level of consistency is achieved. Their real power lies in structuring the way designers think about their domain and the tasks their users are doing: They can be used as tools for requirements engineering as well. But some hindrances need to be overcome.

What are Patterns?

The idea of patterns originated in architecture with Christopher Alexander's 1977 book "A Pattern Language". Alexander noticed that certain design problems kept occurring in different contexts but afforded a relatively small number of similar solutions. So he created the idea of patterns as the optimal solution to a given question in architecture. It could deal with a room, a building, a street, a town, or some transportation infrastructure. Alexander identified and described a set of design patterns and a "pattern language" that described the interrelationship between the patterns. Later, the idea was adopted in User Interface Design, and Martijn van Welie and Jenifer Tidwell started researching and publishing design pattern libraries for user interfaces for PCs; later these were expanded to cover different devices.

It is important to understand what patterns are not: patterns are not single interaction elements (or controls). They are not solutions to simple problems like "select one element from a list". They are parameter-sensitive sets of controls, interacting with each other on a given input and creating a certain output. Their aim is to support one specific design problem. Use Cases are one way of stating design problems. Basically, design patterns can be defined as optimal solutions to a given abstract use case, and a design pattern in context (i.e. with the right input and output parameters) represents the design solution to a specific use case.

Just as Christopher Alexander set up a number of patterns and defined a pattern language, a pattern-based design approach requires a basic set of patterns to choose from. Your pattern library is the toolbox you need to build your applications from. So, how do you create a pattern library?

Creating a Pattern Library

A pattern library needs to have a critical mass, to contain a certain number of patterns to work. It's useless to start with too small a number of patterns because you will end up trying to "squeeze" your applications, to fit your requirements to the patterns. That's not sensible. You should have patterns for all major places in your apps. E.g., in business applications, you'd need at least one list pattern and one framework / container pattern for actually viewing / editing business objects. Within the editing container pattern, you'd most certainly use different patterns for applying actions to the object. These patterns need to be there in different flavors to provide notifications (like success or failure messages).

Defining a pattern library is not really a democratic process. There needs to be a group in charge of the pattern library, and their task is to document patterns, evaluate requests for new patterns, and keep the number of patterns low. A high number of patterns not only increases design ambiguity and waters down the guiding power of patterns, but also increases maintenance effort. Therefore, all patterns should go through this central group to be approved.

The best way to arrive at a sufficient number of patterns is to take a close look at some exemplary applications. Abstract the use cases and activities undertaken in these apps from the actual design solutions. Out of the number of use cases, a limited number of recurring activities will emerge. Based on your industry, your users will mostly edit business objects, browse image libraries, request information on articles, or search huge databases of information. Within each of these domains, only a limited number of sufficiently different activities exist. For each of these core activities (i.e., for each of these design problems) an optimal design solution can be found. Try to identify the solution or solutions that are applicable to most or (if possible) all your use cases. Draft and iterate it until a somewhat stable solution emerges. This is your first pattern. Write it up on a Pattern Card, describing the design problem, the usage context, constraints, dos and don'ts. Then move on to the next pattern until you think you've covered most cases. Then go back into actual application design and re-design your apps, incorporating your newly-defined patterns

as you go. You will undoubtedly encounter numerous cases where your patterns don't fit as well as they should. Document these cases, but try to keep the number of patterns low for the first iteration. Once you're through with your apps, go back to the drawing board and re-evaluate your work from a certain distance. Think about the difficult cases – do they warrant new patterns, or can the existing patterns be extended to satisfy the newly discovered needs and requirements?

Once you've arrived at a stable number of patterns, you can go the next step: get the design patterns wrapped in code so that you end up with a number of components. Believe me, it's easier to start later, once the requirements and flavors of the patterns are clear and been through at least one iteration. Now it's time to profit from the work you've invested.

Harvesting the Crop

As soon as you've got design patterns and components – their equivalent in code –, you can benefit from your previous work: You'll realize how much patterns speed up the process of product definition and development. On the way, you'll notice that you've changed a number of job descriptions: UI design is changed from creating specific solutions to every problem anew to rather analyzing the use cases and identifying the most appropriate patterns for the problem at hand, including the right flavor of a given pattern and well as connecting the patterns in screen flows. Visual design will be freed from tactical day-to-day business to pursue more strategic design approaches. And development's tasks change from creating new solutions over and over again to configuring the existing patterns, wiring together the solutions, and create new and even better patterns. (Basically, given a Business Process Design Time suitable for end-users, business architects can be empowered to plug together basic applications from the patterns – as described in Dan Wood's 2003 books "Packaged Composite Applications" and "Enterprise Services Architecture".)

So, adopting a pattern-based design approach not only changes the processes of product definition, design, and development, but also the responsibilities within the development organization. Change Management should be involved in every step to avoid rising levels of frustrations in a great number of departments.

Once you start using your pattern library as a framework for requirements gathering it gets really interesting. As your pattern library contains the boiled-down interaction design approaches about your design problem domain, you can create standardized interview guidelines using the patterns to structure your interviewees' responses. For example, if your pattern library contains a pattern "list of business objects that I must work on" and one pattern "overall list of business objects with advanced filter mechanism", your interview could touch questions like:

  • Do you have a list of things you need to do – are there objects you get at certain times and need to work on, and once you're finished with them, they can disappear from the list? Which ones? The objects mentioned now should be part of the "list of business objects that I must work on" pattern.
  • Do you need to access objects regardless of whether they are new, in progress, or done? Which ones? What are the criteria you use to find the relevant object quickly? These objects would be part of the "overall list of business objects", and the "advanced filter mechanism" can be parametrized according to the answers, too.

With the right set of questions, you can cover all your patterns and understand how they need to be set up to meet the users' requirements. But don't forget to listen for any hints at things missing, ideas and concepts not covered, or elements rather "squeezed into" the design system your patterns represent. It is possible (and, at first, quite probable) that you will learn that your patterns don't quite fit, that a new flavor or even a new pattern is needed. A pattern library is a living structure that will evolve over time, and so will your design thinking.

So, you might ask, where will this lead us? Once we have a pattern library in place, once we've streamlined our UI design and application development approach, what next? Let's take a look into one possible future.

Vision: Towards a competition of components

Apple's Mac OS X Automator.

Imagine a computing world that has got rid of monolithic applications – on the desktop, on the servers, everywhere. For every purpose, the best possible component can be chosen and just plugged into a framework supporting and living open standards. "Application development" means: business experts define the processes, and business architects select the appropriate components and parameters, following an approach as described above. Using an application design time much like Apple's Automator, elements can be plugged together and auto-negotiate their interfaces and data exchanges.

Part of this is true already. SAP's NetWeaver platform is the first to use the term "applistructure", a Forrester Research-coined term for the convergence of "application" and "infrastructure". And SAP is not the only one on the market with a comparable offering for enterprise software. But on the desktop, much remains to be done. A concept for a basically document-centric approach to desktop computing was presented by Jef Raskin in his book "The Humane Interface", contrasting it to the current (well, 20+ years old) "application-centric" approach. Raskin asks: Why force people to buy an office suite that is poorly integrated when they could rather buy the components they need – a text editor, a chart drawing component, etc. (Well, Apple tried to introduce this approach as "OpenDoc" in System 7.5 to 8.1, unfortunately, rather halfheartedly, and then killed it.) It would be up to the OS manufacturers to provide the necessary infrastructure. And it would be up to a great number of small software companies (Independent Software Vendors) to compete for the best possible components available for a given user need. This would create a whole new momentum on the market, out of which everyone would benefit – well, maybe everyone except for the companies producing office suites right now. But then, why not prove they've got all the experience to create the best competitive components?

And the fascinating thing is: It's started to happen on the Web already. Basically, all the Web2.0 hype is about people composing their "information and application cockpits" tailored to their needs, based on an open infrastructure and publicly available components. And I guess that's just the beginning.