« Cairngorm Community Documentation and eLearning Project | Main | RIA Jobs with Adobe Consulting and Adobe Product Teams »

September 12, 2006

Patterns in Technology and Design

One of the things that has most excited me about Rich Internet Applications in particular, has been the way in which it has created a space where great Design and great technology come together to create great solutions.  Some people are fortunate to have talent in both areas – I’ve always had to settle for an affinity to the compiler rather than the canvas.  Working within Adobe Consulting has been a great opportunity to blend a  passion for technology, and a passion for the way that technology can revolutionise business,  with a collective of people who have the same passion and beliefs that Design can do the same thing, creating user-experiences that are useful, usable and desirable.

Tom Peters , a reknowned and innovative management guru , defines Design as “the ‘soul’ of the new enterprise” in his highly recommended read, “Re-imagine!”.   If you’ve been evangelising about Rich Internet Applications, it’s hard not to have empathy with the following quote from Peters, “Design has become a professional obsession.  I simply believe that design – per se – is the principle reason for emotional attachment (or detachment) relative to a product or service or experience”.   I’ve recently done a number of customer visits and  presentations with Simon Smith, our worldwide practice leader in Adobe Consulting for User Experience,  who throws a great quote up in his presentations, also from Peters, that Design “..should be on the agenda of every meeting, in every department, throughout the Enterprise”.

Is design on your agenda ?  Within Adobe Consulting, whether someone is a Project Manager, a LiveCycle specialist, a Rich Internet Application specialist, a Mobile application developer or an Engagement Manager, they are immersed in the importance of Design.  Through Adobe Consulting University – an ongoing learning program for our consultants – Design is placed on everyone’s agenda, as being as critical to the success of a solution delivery as the technologies which underpin it.  The fusion of great design and great technology is an online experience that exhibits breathtaking utility.

Design Patterns

I’ve written and spoken at length within the RIA community, around the topic of design patterns.  However, the idea of capturing design ideas as a pattern is attributed to the American architect, Christopher Alexander.

Christopher Alexander, a professor-emiritus at the University of California, Berkeley, co-authored “A Pattern Language: Towns, Buildings, Construction”, a book which almost 30 years on is still reputed to be one of the best-selling books on architecture.  In the book, Alexander first coined the idea of a “pattern language” derived from traditional architecture, which documented over 250 patterns that adhered to best-practices and thinking, while still affording the architect the creative freedom to adapt them to a particular context or situation.  By way of example, the “Arcade Pattern” is described as follows – “"Arcades - covered walkways at the edge of buildings, which are partly inside, partly outside-play a vital role in the way that people interact with buildings”.    This is then followed by a description of the pattern,  cross-reference to smaller component patterns such as columns, and larger patterns within which an Arcade has context. 

This logic and structure of this book was the inspiration for the software engineering text, “Design Patterns”, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, known affectionately as the “Gang of Four” or “GoF”. 

In software engineering, a design pattern is considered as a general and repeatable solution to a commonly occuring problem in software design.  The Gang of Four thinking became widespread, leading to a number of works including the one which had some of the greatest influence on my own software architecture thinking, “Core J2EE Patterns” by Deepak Alur, John Crupi and Dan Malks.  Many of the Core J2EE Patterns were to provide the basis of the Cairngorm Microarchitecture, which we advocate within Adobe Consulting as a consideration for the underlying software architecture in an Enterprise RIA.

Design Patterns in Architecture and Software Engineering … so what about in User Experience Design ?

The idea that there are recurring challenges for which tried and tested solutions exist, solutions which document approaches to the problem resolution while still affording freedom in implementation, always seemed to make sense to me as being equally applicable to user-experience design.  It has always struck me the Accordion Form in Flex for instance, represents a User Experience pattern with forces of “the user must be presented with multiple pages of form data to complete, but like a real-world form it is expected that quick and random access to the form is required.  Furthermore, though the form is logically sectioned, the order of completion of these sections is not necessarily logical.  The Accordion Form offers a means of rendering the form section by section, with sections accessed in an order determined by the user, affording random-access and rapid-access without the need to step through pages”.  I’m sure someone could come up with a more general and eloquent expression of the pattern here, but the concept makes sense to me.

At the beginning of the year, I picked up Jenifer Tidwells book “Designing Interfaces” from O’Reilly.  In this book, Tidwell expresses interface and interaction design as a pattern language, in the same way as Alexander, the Gang of Four, or Alur et al before her.   The patterns are drawn from desktop applications, web sites, web applications and mobile devices.  In the same way that other pattern catalogues have tried to structure and group their patterns, Tidwell categorises patterns as “Content Organisation Patterns”, “Getting Around” patterns, “Commands and Actions”, “Showing Complex Data” and more.  The pattern catalogue is online at http:///www.designinginterfaces.com/ and I’d highly recommend browsing the site for some insight.

Pattern Fever

When I presented this idea to some of my user-experience colleagues, it was interesting to hear that while such efforts are valuable, they create a risk that the patterns  be seen as the essence of a good user-experience, rather than the understanding of where and how these patterns should be used, of the fine-line between prescription and free-will, of the responsibility to learn from experience and stand on the shoulders of giants while still having the courage for creativity steeped in a solid understanding of why some things work and why other things don’t.

 My balance in talent towards the compiler and away from the canvas is not going to go away because I create an online banking RIA that leverages the “Card Stack” pattern for my different accounts, in “Movable Panels”, with “Diagonal Balance”, “Multi-Level Undo” and “Smart Menus Item”. 

Frankenstein’s Monster, yes.  Frank Gehry’s Guggenheim ?  I don’t think so.

And that creates an interesting parallel track in the architecture, software and design pattern movements;  that similar criticism can be drawn irrespective of problem domain.

I recently posted an article to my blog, “Why I think you shouldn’t use Cairngorm”, that attempted to provide early warning signals to developers that they were perhaps getting a little too pattern happy too quickly, and blindly applying the patterns that Cairngorm provides, without understanding the contexts in which they do and don’t make sense.  In his essay, “Revenge of the Nerds”,  Paul Graham writes “This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough— often that I'm generating by hand the expansions of some macro that I need to write”.  Now unsurprisingly to many of you I’m sure, I don’t agree that a pattern is always a sign of trouble – however, whenever I am reviewing code, the over-sprinkling of Factories, AbstractFactories, Decorators and Observers can often be a bad code-smell, that whiffs of a developer who has abdicated responsibility to design, in the belief that the patterns have it all covered.  In Cairngorm, the View Helper as a catch-all for any logic that doesn’t go in a Command or Business Delegate became a classic bad-code smell for us.

Other than Christopher Alexander’s own projects, those that employed his patterns met with mixed response from other architects and critics, leading Alexander himself to believe that patterns themselves were not sufficient in their own right; in a subsequent text called “The Nature of Order”, Alexander talks about the need to understand the way in which an environment self-forms, something he called a “morphogenetic” understanding.  In essence, this is a recognition that blind application of patterns is not a recipe for success; but rather the patterns are tried and tested ingredients, many of which work consistently well with each other, but rarely create a delicacy unlesss under the guidance of an experienced chef who understands the broader context of what makes a good dish.

If I can return back to the concept of user-experience design patterns, we can recognise that neither is arming someone with a pocketful of User Experience patterns the recipe for an effective user-experience.   The “Multiple Document Interface”  is often misused, where there is a lack of information about the currently opened windows, and there is no relative context of what is on-screen in relation to the task that the user is undertaking.  To quote our User Experience practice, “when everything is equal, nothing is important”. 

If you instead consider something like the user-experience in Breeze – itself a Rich Internet Application that has had much user-driven design-thinking applied – you will have experienced how the fluidity of the user-experience is capitalised upon, with areas of the screen expanding in size and importance according to the current task of the current user.  When you are presenting, the presentation window will grow in prevalence, shrinking in importance at the end of a presentation as the application is moved into a chat mode, and the discussion panel increases in relevance and real-estate.   A naïve implementation may have made all of these windows overlapping, resizable, draggable, dockable, collapsible, minimisable and maximisable windows.  However, this underlying principle of “when everything is important, nothing is” provides a higher-level of understanding and meaning.  This understanding of the environment and the way in which citizens operate within the environment, brings the same nature of order to a user-experience as Alexander describes – whereas blind application of say the “MDI Pattern” or the “Tabbed Pane Pattern” would create a user-experience that while perhaps technically clever, or aesthetically pleasing, fails to match the needs of the people who must use it from day to day.

Summary

So whether we are planning towns and precints, whether we are architecting our software applications for scalability and maintainability, or whether we are designing great user-experiences, we can count on patterns, but none too much.  Striking a balance between established wisdom, insight into the context and environment of our solutions, and the right to apply our own creativity and ingenuity to innovatively solve problems, are important lessons from both a technical and a Design perspective, and the path to a successful solution, whether it be a building, a software architecture or a great user-experience.

I recently read “The Ten Faces of Innovation” by Tom Kelley of IDEO, who defines 10 personas we can all adopt when trying to heighten creativity and deliver truly innovative solutions and services to our clients.  One of these personas, “The Cross Pollinator” is described as someone who can  create something new or better through the unexpected juxtaposition of seemingly unrelated ideas or concepts, taking clever solutions in one context and then translating them successful to another.  The role of the cross-pollinator is best captured in the book by a quote by Alexander Graham Bell, the inventor of the telephone only a few miles from our Adobe Consulting Edinburgh office: “Leave the beaten track occasionally and dive into the woods.  Every time you do so, you will be certain to find something that you have never seen before”.

With Design on my agenda, I’m finding there a number of interesting parallels between good Design and good software architecture; I’m curious as to what innovation lies beyond, and am curious as to the parallels that you may also have found.

Posted by swebster at September 12, 2006 05:13 PM

Comments

Posted by: bokel at September 12, 2006 07:40 PM

Posted by: Scott Barnes at September 12, 2006 11:48 PM

Post a comment

Name:

Email Address:

URL:
Remember Me? YesNo

Security code:

Comments: