SXSW: Design Patterns: Defining and Sharing Web Interface Design Languages
[Notes from this panel with Luke Wrobeleski]
Luke Wrobeleski used to be at the NCSA and now is at Yahoo! working on design patterns.
So why talk about design patterns? One common problem is communication within design teams and with clients and developers and every other stakeholder.
Design patterns give you a shared language. When you see something that you don't recognize you don't see it the same way you do once it has a name, once the thing itself is wrapped in a concept.
As our world gets more interconnected, it becomes more important to parse meta-information. A pattern is essentially data about data. The notion of pattern recognition is becoming more and more important in this information firehouse age. Raven Progressive Matrixes, for example, are an intelligence test that measures pattern recognition. This is what designers are good at because we see the world through this lens.
See: designinginterface.com
See: welie.com/interfaces
See: Ebay pattern library
See: Yahoo! pattern library
So what are we talking about? They are a solution to problems in context. They are repeatable solutions to common problems. They work "positively" for specific problems in specific contexts.
When a person recognizes a set of stimuli they have a built-in process for handling that situation.
This is different than principles or guidelines, it is somewhere in between.
It is about a shared vocabulary, both visual and verbal, around actions and behaviors or general formatting. Some patterns are pretty broad. Drag-and-drop is a great example of this. If you treat the same way in many contexts users will better understand how to respond to the visual cues that indicate what actions are possible. Timing, feedback, etc. are caught up in the design pattern.
Looking at smaller scale elements like auto-complete, inline feedback, or hover detail present similar needs for consistency and patterns. The list goes on and on but looking at resources you can explore all that is out there.
Because design patterns are solutions to problems, there is a scope of design patterns. Some things apply at a very high level. These could include application archetypes. Down at the bottom of the scope is the component, or elements, that make up the application.
At Yahoo! they felt it was important to bound this at the top and at the bottom. SAP breaks this up differently and they take into account workflow and tasks. The danger of an expansive pattern framework is that it isn't very nimble. With the Yahoo! model you simple decide if you are making something big or small and go from there.
Grids is big scale, breadcrumbs are small scale.
The point here is to not over-think this issue. Pay attention to the context and work with that.
So what's in a design pattern, how are they documented?
- Name
- Problem
- Use when
- Solution
- Why
- How
- Examples
- Related Patterns
- Accessibility
- Code Samples
How are patterns used? They can be used as a style guide replacement for large web sites. They also help to share best practices between designers, with developers, and with clients.
At eBay they used to have a big style guide but the day it came out was the day it was obsolete. Style guides are both too general and too specific. Within a dynamic environment the action is where the problem is being solved, not how many pixels of padding is applied to a button.
[my thought: Design patterns are nimble and are set up to evolve within an organization. Their contextual nature allows an open conversation to take place around them.]
eBay moved from this to pattern library that embraced the idea of high and low level pattern structures geared toward offering solution to particular problems.
Oracle has a massive pattern description set but it is too rigid. You want something flexible enough that is can occupy that fuzzy middle.
So this is great for big firms but what about clients?
It hasn't been done very often but it is compelling because it focusses on solutions instead of rules. Sites take on a life of their own so giving the client a way to solve problems as they come up is more helpful than rules. It helps people do the right thing. Style guides focus on the what while design patterns give you the why.
There are inevitably things you will reuse, why not document and hone them?
Sharing these patterns is very important.
Be sure to focus on:
- User-Centered Goals
- Design Constraints
- Related Patterns
So what about an example? Top vs. Left vs. Right aligned field labels on forms.
Top aligned labels are good when the form is familiar. Left are easy to lay out visually but hard to scan. Eye tracking data is pretty interesting here because different choices have different costs.
Instead of whim, make the choice based on what the user is trying to do.
[he gave some great example that I couldn't get down]
0 TrackBacks
Listed below are links to blogs that reference this entry: SXSW: Design Patterns: Defining and Sharing Web Interface Design Languages.
TrackBack URL for this entry: http://www.samfelder.com/mt/mt-tb.cgi/278
Who is this guy?
Leave a comment