UPA2007 Designing Interfaces Jenifer Tidwell
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

UPA2007 Designing Interfaces Jenifer Tidwell

on

  • 1,040 views

 

Statistics

Views

Total Views
1,040
Views on SlideShare
1,040
Embed Views
0

Actions

Likes
1
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

UPA2007 Designing Interfaces Jenifer Tidwell Presentation Transcript

  • 1. Designing “Designing Interfaces:” How Not to Write a Pattern Catalog Jenifer Tidwell UPA 2007 Wednesday, June 13
  • 2. Prologue: a little history
    • The year was 1997.
    • Read “Design Patterns” (Gang of Four) and “A Pattern Language” (Alexander).
  • 3. Developers designing UIs…
    • They knew the principles of good design.
    • They understood the importance of usability testing.
    • But they couldn’t get past rote copying.
    • “ Microsoft did it this way,
    • so we should do it this way too.”
  • 4. Could patterns help?
    • “These ideas work. Pick what you want from them, and ignore the rest.”
    • “And by the way, here’s why they work, if you’re curious.”
  • 5.
    • Hypertext
    • Video games
    • Consumer electronics
    • Spoken interfaces
    • Print design
    • Data visualization
    • Cartography
    • etc…
    Wanted to apply knowledge from other fields
  • 6.  
  • 7.  
  • 8. But was it useful?
    • Sort of.
  • 9. 1999-2002: no work done
    • I couldn’t solve certain problems
    • Come back to it with a fresh mind
    • Learn more about graphic design, industrial design, etc.
  • 10. Two jobs later…
  • 11. …and then…
  • 12.
    • Treat it as a fun theoretical exercise.
    How Not to Write a Pattern Catalog: (Design it to be used)
  • 13. 1. Design it to be used
  • 14. 1. Design it to be used
    • Prefer concrete to abstract
  • 15.  
  • 16. 1. Design it to be used
    • Prefer concrete to abstract
    • The format doesn’t have to be GOF, or Alexandrian, or …
  • 17.  
  • 18.
    • Examples
    • Context
    • Problem
    • Forces
    • Solution
    • Resulting Context
    • Diagram
    • Notes
  • 19.
    • Examples
    • Context
    • Problem
    • Forces
    • Solution
    • Resulting Context
    • Diagram
    • Notes
    • Primary Example
    • What
    • Use When
    • Why
    • How
    • Other Examples
  • 20.
    • But what about interoperability?…
  • 21. 1. Design it to be used
    • Prefer concrete to abstract
    • The format doesn’t have to be GOF, or Alexandrian, or …
    • The organization just needs to function; it doesn’t have to be perfect
  • 22.
    • But organization is important!
    • Help readers find patterns
    • Makes a statement about how the patterns should be used
    • It’s an information architecture problem.
  • 23.
    • So how should we categorize them?
    • By scale?
  • 24.
    • So how should we categorize them?
    • By scale?
    • By user task?
  • 25.
    • So how should we categorize them?
    • By scale?
    • By user task?
    • By problem statement?
  • 26.
    • What is the basic shape of the content?
    • What is the basic shape of the actions taken with the artifact?
    • How does the content or available actions unfold before the user?
    • How does the artifact generally use space and the user’s attention?
    • How is the content or action organized into working surfaces?
    • How can the user navigate through the artifact?
    • What specific actions should the user take?
    • etc…
  • 27.
    • So how should we categorize them?
    • By scale?
    • By user task?
    • By problem statement?
    • By design stage?
    • … This kind of worked.
  • 28.
    • What Users Do
    • Organizing the Content
    • Getting Around
    • Organizing the Page
    • Commands and Actions
    • Showing Complex Data
    • Getting Input from Users
    • Builders and Editors
    • Making It Look Good
  • 29. 1. Design it to be used
    • Prefer concrete to abstract
    • The format doesn’t have to be GOF, or Alexandrian, or …
    • The organization just needs to function; it doesn’t have to be perfect
    • Don’t sweat the “language” stuff
  • 30.
    • “ The language is a good one … when it is morphologically and functionally complete.
    • “ It is morphologically complete when the patterns together form a complete structure, filled out in all its detail, with no gaps.
    • “ And it is functionally complete when … the patterns, as a system, generate only those forces which they themselves resolve.”
  • 31.
    • Lowered standard: just make sure patterns link to each other.
    • Is-a
    • Leads-to
    • Alternative-to
    • Works-well-with
    • etc.
  • 32.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users)
  • 33. 2. Focus on your users
    • Solve the design problems they have
    • Not everyone’s
    • Use vocabulary they know
    • Use familiar examples
  • 34. 2. Focus on your users
    • “ Microsoft did it this way,
    • so we should do it this way too.”
  • 35.
    • Hypertext
    • Video games
    • Consumer electronics
    • Spoken interfaces
    • Print design
    • Data visualization
    • Cartography
    • etc…
  • 36.
    • Hypertext
    • Video games
    • Consumer electronics
    • Spoken interfaces
    • Print design
    • Data visualization
    • Cartography
    • etc…
    Only MathWorks software.
  • 37.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    • Try to capture all design knowledge as patterns.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users) (Other forms can be better)
  • 38. 3. Other forms can be better When you’ve got a hammer…
  • 39. 3. Other forms can be better
    • Suggestion, not command
    • Product, not process
    • Captures relationships among elements
    • Usable across platforms
    • Clearly improves the user experience
    My definition of “pattern:”
  • 40. 3. Other forms can be better
    • Principles
    • Heuristics
    • Style guides and standards
    • Components
    • Genres / idioms
  • 41. 3. Other forms can be better
    • Principles:
      • “ Make your interfaces easy to learn.”
      • “ Prevent errors.”
      • Bedrock design concepts
      • Commands, not suggestions
      • Very abstract, high-level
  • 42. 3. Other forms can be better
    • Heuristics:
      • “ Performance, cost, schedule: pick two.”
      • “ Expand the scope to simplify the problem.”
      • Strategies for solving problems
      • Commands, not suggestions
      • Process, not product
  • 43. 3. Other forms can be better
    • Style guides and standards:
      • “ If an item is too long to fit in the list box, insert an ellipsis in the middle and preserve the beginning and end of the item.”
      • Design parameters for a class of products
      • Commands, not suggestions
      • Often very specific
  • 44. 3. Other forms can be better
    • Components:
      • “ Here’s the code for a sortable table.”
      • “ Here’s a set of icons for use in drag-and-drop.”
      • Individual elements of a UI
      • Not relationships among them
      • Often very specific
  • 45. 3. Other forms can be better
    • Genres / idioms:
      • Form
      • Information graphic
      • Searchable online repository
      • Categories of UI types; “set the rules”
      • A context, not a pattern!
  • 46. 3. Other forms can be better
    • What about new innovations?
  • 47. 3. Other forms can be better
    • Another problem: patterns are verbose.
  • 48. http://www.visual-literacy.org/periodic_table/periodic_table.html
  • 49. 3. Other forms can be better
    • Tried to “patternize” genres/idioms
    • Tried to “patternize” information shapes
    • Attempted to create too many patterns for controls
    • Almost published “Inverted-L” as a pattern
    What had I done wrong?…
  • 50.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    • Try to capture all design knowledge as patterns.
    • Describe the obvious, without offering any genuine insight.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users) (Other forms can be better) (Think hard about use contexts)
  • 51. 4. Think hard about use contexts
    • Problem: You need X.
    • Solution: Use X.
    • (with apologies to Martijn)
    • You’re stuck in Obviousland!
  • 52.  
  • 53.  
  • 54. Diversion: pattern writing
    • How I write a pattern:
    • Notice a recurring design element.
    • Work up and down the abstraction ladder.
    • Understand why it works.
    • Figure out the context -- when it should or shouldn’t be used.
    • 5. Name it.
    This is what gets you out of Obviousland.
  • 55. Diversion: pattern writing
    • Pattern discovery in another domain…
  • 56. Step 1: find a recurring element
    • What’s common here?
    • Brown the meat in oil, on high heat
    • Remove it before it’s cooked
    • The rest of the dish involves liquid
    • Return the meat to the liquid, eventually
  • 57. Step 2: walk the abstraction ladder
    • Up, up, up:
    • Does it work with vegetables too?
    • Is the liquid required?
    • Would dry heat work, instead of frying?
    • But these seem to lose the “sense of
    • the pattern”
  • 58. Step 3: why does it work?
    • Research uncovers “Maillard reactions”…
    • Produce hundreds of flavor components
    • High heat (360+)
    • Requires both proteins and sugars
    • Deglazing often done too
  • 59. Step 4: figure out use context
    • …What, you want me to be a chef too?
  • 60. Step 4: figure out use context
    • We discovered that flavor depth is added
    • We ruled out vegetables and delicate oils
    • We decided that liquids define the pattern as much as the meat-browning does
    • Counterexamples?
  • 61. Step 5: name it
    • Any ideas?
  • 62.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    • Try to capture all design knowledge as patterns.
    • Describe the obvious, without offering any genuine insight.
    • Don’t bother with screenshots; they’re too hard.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users) (Other forms can be better) (Think hard about use contexts) (Visual examples are critical)
  • 63. 5. Visual examples are critical
    • They help you define the pattern
  • 64.  
  • 65.  
  • 66.  
  • 67. 5. Visual examples are critical
    • They help you define the pattern
    • Put your “evidence” out there
  • 68.  
  • 69.  
  • 70. 5. Visual examples are critical
    • They help you define the pattern
    • Put your “evidence” out there
    • Explain in pictures, not just words
  • 71.  
  • 72.  
  • 73. 5. Visual examples are critical
    • They help you define the pattern
    • Put your “evidence” out there
    • Explain in pictures, not just words
    • Inspiring in their own right
  • 74.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    • Try to capture all design knowledge as patterns.
    • Describe the obvious, without offering any genuine insight.
    • Don’t bother with screenshots; they’re too hard.
    • Just toss it out there with no followup.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users) (Other forms can be better) (Think hard about use contexts) (Visual examples are critical) (Find out how it’s really used)
  • 75. 6. Find out how it’s really used
    • Conducted a survey of DI readers to find out how they use patterns
    • (Not statistically significant)
  • 76. 6. Find out how it’s really used
    • 130 respondents
      • 20 were primarily developers
      • 50 were designers of some sort
      • A mix of managers, researchers, etc.
    • Majority have been in that role 2-8 years
    • But they do many different things…
  • 77.  
  • 78.  
  • 79. 6. Find out how it’s really used
    • Advice on specific design problems
    • Learn about UI design
    • Use examples as “sourcebook”
    • Terminology for describing design
    • Creative inspiration
    The book says:
  • 80.
    • “ How often do you or your team refer to the book for advice when you're designing interfaces?”
    • Total: 80%
    • Most common answer: “Once or twice during a project” (40%)
  • 81.
    • “ Has the book changed your mind about any design decisions?”
    • “Yes:” 50%
    • Sample answers: balanced palette, date choosers, data graphics, page organization
  • 82.
    • “ Identify chapters that taught you something you didn’t know before”
    • Total: 55%
    • Most common answer: Chapter 4, “Organizing the Page”
  • 83.
    • “ Identify chapters that taught you something you didn’t know before”
    What Users Do Organizing the Content Getting Around Organizing the Page Actions and Commands Showing Complex Data Getting Input from Users Builders and Editors Making it Look Good
  • 84.
    • “ Identify chapters that taught you something you didn’t know before”
    … but many respondents said “all” or “none.”
  • 85.
    • “ Have you used the book to help or encourage other people to learn about UI design?”
    • “Yes:” 70%
  • 86.
    • “ Have you or your team used the book to find or brainstorm new design ideas?”
    • “Yes:” 65%
  • 87.
    • “ Have you used the pattern names when talking about design?”
    • Total: 75%
    • “ Have you used the pattern names in design specs or other design documents?”
    • “Yes:” 35%
  • 88. 6. Find out how it’s really used
    • Advice on specific design problems
    • Learn about UI design
    • Use examples as “sourcebook”
    • Terminology for describing design
    • Creative inspiration
    … yes, patterns are used in all these ways!
  • 89. 6. Find out how it’s really used
    • 2/3 of workplaces “informally encourage use of UI patterns”
    • 1/3 formally use patterns “to enforce consistent design”
    Some other tidbits…
  • 90.  
  • 91.  
  • 92. 6. Find out how it’s really used
    • Few Hues, Many Values
    • Right/Left Alignment
    • Responsive Disclosure
    • Diagonal Balance
    • Deep Background
    Frequently-named patterns:
  • 93. 6. Find out how it’s really used
    • Responsive Disclosure (9 mentions)
    • Input Hints (6)
    • Wizard, Progress Indicator, Row Striping, Liquid Layout, Closable Panels (4-5)
    Pattern names used:
  • 94. 6. Find out how it’s really used
    • On changed design decisions…
      • “ considering an action panel to replace a convoluted menu system”
      • “ Simplifying color and making the page balance diagonally.”
      • “ Color Coding of pages was a new concept”
  • 95. 6. Find out how it’s really used
    • On changed design decisions…
      • “ I've moved away from linear wizards and toward 2-panel selectors, to give users more control over how they work with info or move through a process.”
      • “ It changed my mind about web page organization. I tend to think of them as inherently textual and organize them from left to right. I plan to spend more time considering the graphical nature of the data I'm presenting and thinking about grouping and layout.”
  • 96. 6. Find out how it’s really used
    • Good summation or reference for familiar ideas
    • Useful as a “memory jogger”
    • Different platforms: good
    • More patterns!
    • More AJAX!
    General comments…
  • 97. 6. Find out how it’s really used
    • General comments…
      • “ Synthesis, reinforcement, clarification: this is what the book was mostly useful for.”
      • “… it has boosted my design decisions and given me confidence to go ahead with the designs.”
      • “… many times I think of one way of doing things and after consulting with the book I have new ideas.”
  • 98. 6. Find out how it’s really used
    • Patterns are used in the ways we predicted
    Conclusions:
  • 99. 6. Find out how it’s really used
    • Patterns are used in the ways we predicted
    • They help both novice and skilled designers
    Conclusions:
  • 100. 6. Find out how it’s really used
    • Patterns are used in the ways we predicted
    • They help both novice and skilled designers
    • Many workplaces are aware of them and use them
    Conclusions:
  • 101. 6. Find out how it’s really used
    • Patterns are used in the ways we predicted
    • They help both novice and skilled designers
    • Many workplaces are aware of them and use them
    • Repository of design wisdom, more than a teaching tool (but both)
    Conclusions:
  • 102.
    • Treat it as a fun theoretical exercise.
    • Write it for all designers, everywhere.
    • Try to capture all design knowledge as patterns.
    • Describe the obvious, without offering any genuine insight.
    • Don’t bother with screenshots; they’re too hard.
    • Just toss it out there with no followup.
    How Not to Write a Pattern Catalog: (Design it to be used) (Focus on your users) (Other forms can be better) (Think hard about use contexts) (Visual examples are critical) (Find out how it’s really used)