Open Source Design Pattern Library group meeting - 05-28-08

Owned by Allison Bloodworth
Last updated: Aug 18, 2008 by Jonathan HungVersion comment
10 min read

Agenda

  1. Finalize Last Week's Discussion questions (See Phase 1 - High-level OSDPL Discussion Questions & Answers for a summary of responses to the mailing list)
Mission Statement

A design pattern is a "proven solution to a complex problem in a specified context." The primary goal of the Open Source Design Pattern Library will be to promote a set of collaboratively-created user experience (UX) design patterns as a way to design usable, high-quality, inclusive user interfaces in specific contexts. It will:

  • be the first truly open place for collaborating on UX design patterns. (It will be creative commons licensed, and not in any way proprietary or managed by heavy top-down moderation that precludes outside contribution, reuse and modification.)
  • be the place for advice on open source UX design
  • have a practical focus: as a common source of UX design inspiration and a place to learn about best practices for both designers and developers, as well as serving as a focus of discussion for their collaborative efforts
  • foster collaboration across disciplines, experience levels, and expertise
  • help communities design consistent interactions, both within and across projects, where it makes sense to do so
  • help create a shared language/vocabulary for communities to discuss UX design
    (Sidenote: what do folks think about potentially grabbing the URL "uxdesignpatterns.org" to point to our library as well as "uidesignpatterns.org"?)
Design Goals - Audiences

The OSDPL is a setting down of a portion of the body of knowledge that expresses the principles of good design. As such, it should serve as a reference work, as well as a repository for study. The library will be targeted towards a diverse set of audiences, including:

  1. Junior designers & designers who are new to the communities - they will likely both want to peruse the library to learn best practices as well as look for specific design solutions to problems.
  2. Developers who need to design the UIs they build - will most likely be looking for specific design solutions to problems, want more concrete solutions, and even code samples, pattern comparisons, demos, or components related to the pattern.
  3. Experienced designers - will probably browse the pattern library for inspiration, or to come up with innovative solutions to complicated problems.
    Pattern Authors, which may fall into any of the 3 categories above.

We will design the library for three primary audiences, meaning each of them will have their own interface (in this case, their own form of the pattern):

  1. Pattern Users: Junior Designers (who may want fairly deep explanations of patterns)
  2. Pattern Users: Developers (who may want more succinct patterns and code examples)
  3. Pattern Authors

We expect there will be some secondary audiences as well (meaning design will not be focused on them, but their needs should be covered in the interface which addresses the primary audiences' needs, perhaps with just a few additional enhancements):

  • Experienced Designers (should be covered by Junior Designers' interface)

As mentioned above, although Pattern Authors may fall into either the designer or developer category, they will have a completely separate interface to add and edit patterns (which others who are simply users of the library will never see). We believe designers and developers will have slightly different needs as users of the patterns. This could be as simple as presenting the full version of the pattern to designers and a more "stripped-down" version to developers. We believe designers will want to understand why a pattern is the right pattern, who else has used it, what other design considerations they need to think about when using the pattern, etc. They will want interaction consistency with some flexibility for innovation and different contexts. Developers may just want to "cut to the chase," "just tell me how to solve this interaction problem" or "tell me how to implement this solution, don't give me a bunch of different options;" in other words, they may prefer a much more prescriptive style. Developers will likely also want to have code examples or actual code to use. Additionally, the 2 disciplines' search strategies may also be quite different from one another. We'd like to confirm all of these assumptions in the future by doing user interviews/research.

  1. Discuss new high-level questions (are we missing any?)
    1. What is our goal/mission? (tick)
    2. Who is our audience? (tick)
    3. How can patterns add value to the Fluid Community?
    4. How can we contribute to the larger design pattern community?
    5. How will this pattern library add value to the existing pattern libraries? How is it different?
    6. What do we mean by "design patterns"/what is the scope of our work? Should we concentrate only on interaction design patterns, or include other human computer interaction or programming or architecture patterns as well? What types of patterns are within the scope of the OSDPL?
    7. Where can the group discuss these questions?
    8. How do we get the word out about where and when and how we're discussing this?
    9. How can we foster a community to advise and assist with the creation of the pattern library?
  2. Future meetings
    1. Note-taking
    2. Next meeting date
  3. Sign up for work on the OSDPL
    1. Tweak styling of OSPL site and check cross browser behaviour
    2. Check OSDPL modules for updates
    3. Modify pattern data entry form to allow entry of multiple examples
    4. Create & document database back-up process for OSDPL
    5. Remove "in" from OSDPL pages that aren't in a category

Attendees:

Allison Bloodworth, Daphne Ogle, Erin Yu, Jonathan Hung, Jess Mitchell (note-taker), Paul Zablosky, Rachel Hollowgrass

Meeting Notes

wordsmithing the goal and mission – do we feel good about it as it stands?

1. What is our goal/mission?

Daphne's suggested additional bullet: will serve as a taxonomy for the Fluid components

  • is taxonomy too restrictive? is it meaningful? does it sound like it's understandable to our audience?
  • changed to: will provide a taxonomy and design advice for the Fluid components
  • mission statement was originally worded as UI design patterns – A.B. changed to UX design patterns – a little more open if we want to include other things.
    • rachel – UI is just a button
    • Paul – much more embracing of all we're talking about
    • Jonathan – what about the audience – will developers understand UX patterns? They may not understand that they are meant for them. UI is clearer.
    • Jess – may have associations with UX and UI – know the audience first
    • Jonathan – keep UI bit – developers get that right away – our ulterior motive is the UX stuff rubbing off on them as they experience the library.
    • Paul – need to have focused UI content approachable to developers plus a general appreciation of UX. Tricky.
    • Rachel – they should be asking for bigger things – if they come here for UI they've come to the wrong place?
    • Daphne – yes and no, some of our components are UI mostly
    • allison – make sure target audience understands what we mean (e.g. UX vs. UI). I think the mission is for us mostly. Changing the wording from UI to UX will change our scope a little bit. Peter Rwwley suggested adding some cooperative work patterns...might not include that if it's just UI.
    • daphne – UX if we leave it at that can we have a parenthetical phrase that says the depth of what we're thinking.
      Who is the audience of the mission statement? Where is it going to be? Do we want to add this to the front page of the OSDPL?
    • Daphne: ux to us means:
      interface design, interaction design, visual design
  • rachel – mission statements are good for 'about' pages
  • Allison: goal statement is finalized - will send it out to the list.

2. Who is our audience?

  • three primary audiences, one additional secondary
  • Daphne – is this just for our use or do we share this? As it stands it could be a little confusing to people.
  • Allison: all Discussion Questions and Answers are on the wiki, and available for everyone to see...we probably won't put them on the OSDPL site
  • Daphne: we would want to tell them it will be useful to all of the audiences we've targeted (even secondary audiences--they may not understand what we mean by that)
    *Rachel: Kuali may not use the components; but will very likely use the pattern library.
  • Allison: answers are for our own working group...we can decide to wordsmith it and make it available on the site if we need it.
  • daphne – this might come out in the info. architecture part of this. We can decide how to accommodate those audiences when we discuss practically how to info. architect the library.
  • paul – junior – does it mean low-level or novice?
  • daphne and allison – we mean novice but will change that terminology.
  • rachel – serves both a resource purpose as a gateway to components but also an instructional purpose to educate.
  • allison: I'll add that. So we are settled on Audience, I'll send it out to the lists.
  • jess – good on audiences for now, but these can of course evolve.

High-level questions

  • allison – let's move to the high-level questions
  • if these questions are easier we can finalize questions in 2 weeks and/or continue discussion on the list
  • jonathan – more traffic on the list the better – good idea.
  • jess – let's just scoot through questions and then bring to the list if they require more chatter.

3. How can patterns add value to the Fluid Community?

  • daphne – #3 is easier – so let's talk about that.
  • rachel – why have another pattern library? what is it and what's in it for me?
  • allison – how can this add value to the community – trying to explain how we are helping the Fluid community – one easy answer – patterns help with implementing usable, accessible, Fluid components.
  • paul – the OSDPL is needed for the fluid community – it's a great mechanism for people to contribute to the community.
  • jonathan – can forsee how the OSDPL can become a testing ground for future components and modules for Fluid or beyond. Patterns can be refined by having this feedback loop between designers and developers – how the patterns worked for the developers.
  • paul – conduit for a connection with other communities.
  • let's move this to the list – got some great info

4. How can we contribute to the larger design pattern community?

  • allison --love to get the yahoo-pattern-authors folks involved in this list to generate interest among them to getting patterns into this library, but wondering if it's too early to pull in other groups?
  • rachel – opportunity for new interfaces – mobile, etc. having patterns available for different platforms. brings up the important platform question.
  • allison – is a question for fluid too
  • daphne – though this is an important question to talk about but it might be too early. too early to pull them in...
  • allison / jess – hold off on pulling them in until we have the high-level questions ourselves.
  • jess – let's come back and revisit this question, discuss in the future instead of right away. It will help us to understand our own goals before tackling this question.

5. How will this pattern library add value to the existing pattern libraries? How is it different?

  • allison: we allow collaboration and contribution...don't know of any other pattern libraries like that. patterns are created by communities.
    • berkeley drupal user group may want to contribute – he has UI issues on backend. was talking about drupal "patterns" bringing together drupal components – is that something that we'd have in our library or is that beyond what we're thinking about?
  • daphne: that kind of pattern could be applicable to some of our apps (sakai and uportal) portlets, interoperability, etc.
    need to think about this moving forward. if it's useful to the community then putting it in there may be good.
  • rachel – design pattern useful across – specific implementation is where this sort of thing might lead.
  • daphne – implementation is different – that might be a place for our design pattern library to be different.
  • allison – becomes a challenge for organizing the stuff so people can find what they need if the library contains may different types of patterns...could have groups of patterns--the library supports this now.
  • daphne – Would be better to add a FAQ than just a page with the mission statement, as questions like this keep coming up.
  • allison – maybe we should create a FAQ which is an edited form (so it's digestible for our audiences) of our answers to the high level questions.
  • discuss this question further on the list

6. What do we mean by "design patterns"/what is the scope of our work? Should we concentrate only on interaction design patterns, or include other human computer interaction or programming or architecture patterns as well? What types of patterns are within the scope of the OSDPL?

  • Allison – no lack of suggestions for the diff. patterns.
  • daphne – way finding or cherry picking – navigate – example of HCI pattern
  • allison – in the front of Jenifer Tidwell's book (Designing Interfaces) there is a set of patterns which are not Interaction design patterns, more user bahaviour patterns.
  • rachel – that sounds like a step before getting to designs
  • allison – might be different steps represented in our patterns
  • daphne – usable systems, to teach – we do want these things. Tidwell calls them "what users do" patterns.
  • rachel – how to use this library
  • allison – another page in the library could give an orientation to the different patterns in the library and where they may be used in the design process
  • jess – this lends itself to a diagram
  • daphne – different interfaces for different audiences – they come in at different places in a process.
  • rachel – lends to function structure – a whole bunch of links on a page. an Inform. architecture pattern.
    cherry picking sounds like infor architecture – not a functional structure – but it is a design.
  • jess – this might be beyond scope and while it is a pattern, it might be more info architecture.
  • allison – browse the other pattern libraries to see examples - there are definitely information architecture patterns out there
  • daphne – I don't think cherry picking is an information architecture pattern. take a look at beginning of tidwell's book for some more examples – I think they are more user behaviour patterns.
  • jess – sounds like this is an open question we should continue to discuss

7. Where can the group discuss these questions?

  • Allison: these meetings, fluid-talk, wiki (I've been taking responses on the mailing list and adding to the wiki, which is working fine for now)
  • Daphne: check in to make sure it's not too overwehlming – ask for help if it is.

8. How do we get the word out about where and when and how we're discussing this?

  • Allison – fluid-talk, ja-sig, sakai, is there a Kuali list?
  • rachel – not right now
  • any other lists we need to be invovled in?

9. how do we foster a community?

discuss on list?

10. Briefly discussed suggested tasks for folks to work on which will be necessary to address no matter what information architecture we design.

Action item: Discuss questions 3, 5, 6, 9 on list.