Phase 1 - High-level OSDPL Discussion Questions & Answers

Owned by Allison Bloodworth
Last updated: Oct 30, 2008Version comment
11 min read

1. What is our goal/mission? (tick)

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 - including interface, interaction, and visual design) 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
  • will provide a taxonomy and design advice for the Fluid components

Note: we will obtain the URL uxdesignpatterns.org as well if possible.

Discussion

Nate Angell: +1 generally

Daphne Ogle: After a nights sleep, I'm wondering if we want to mention something at components. How about adding a bullet to the mission: "will serve as a taxonomy for the Fluid components" ? Or does that seem too restrictive? I think we'll have design patterns that don't map to components but our plan is to have 1 to many design patterns for each component we build. I'm curious what others think of this.

Jonathan Hung: +1 For the Mission statement and design goal audience.
Main content of it is good and it's fairly concise. Tightening of wording can be done later... I assume this will appear on the wiki once voting is complete?

2. Who is our audience? (tick)

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. Novice designers & designers who are new to the communities - for them the library will serve an instructional/educational as well as reference purpose; they will likely both want to peruse the library to learn best practices and 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.
  4. 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: Novice 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.

Discussion

Nate Angell: +1 generally, +1 on using uxdesignpatterns.org as well

Jonathan Hung: +1 Pattern authors as the 3rd audience.

(See notes from the 05-28-08 OSDPL group meeting for initial discussion of questions 3-9 below. If anyone would like to transfer the info to the "Discussion" sections below, feel free! (smile) )

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

As described in our Goals/Missions section above, there are many ways a design pattern library can help those using it. The OSDPL will be especially helpful as a tool to continue to improve the designs & user experience of the applications which are part of the Fluid community. It will be a collection of reusable design knowledge put together by people who have thought about a particular interaction in depth, and will help designers and developers create user experiences which are more consistent, both within and between the Fluid community applications.

The OSDPL will help the community integrate components with users and good, useful, accessible design in mind, as well as give us a language for talking about designs and components.  The context (e.g. the rest of the page, application, and/or workflow) components live in determine the exact design.  Some of the design decisions are configurations within the component itself.  Other design decisions happen outside of the component, but lead the user to the component (Add files button) or drop them out of it (display starting page with all new files in view and visually distinguished in some way). The patterns will also describe design rationale for the components.  This rationale is very important to designers as they think about configuration, contexts, which pattern in appropriate, etc.

The OSDPL can fill in as a 'virtual designer' in a community where often individual institutions do not have their own designers on staff. Developers often don't have access to design resources, and must do the design themselves. If a pattern library can provide guidance on the 'best' way to implement a particular component, then the developer can feel more confident that they're not going to implement poor designs.

The OSDPL will also serve an educational purpose. Developers often don't know much about design, but often end up having to do it anyway. If a pattern library can offer some explanation of why a design is the way it is, developers using the library can slowly build up a basic understanding that can help them to produce better designs when they're required to design something.

The OSDPL will help the community do good design in general by sharing knowledge & best practices.  There are other pattern libraries that do this same thing, but getting a comprehensive overview of all available design patterns requires going to several different places / libraries.  To avoid this problem, the OSDPL should include links to other appropriate patterns and design principles.  We don't need to recreate the great work others have done but let's make our library a "one stop shop" where we aggregate all the useful patterns and principles for the community.

Discussion

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

We should re-visit this question when we feel we understand our own goals well enough to answer it. If we do create a pattern library where anyone can contribute, it could become a place to aggregate patterns from all the different pattern libraries.

Discussion

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

 
By design, the community aspect of the OSDPL will be the defining feature that will differentiate it from other libraries. It will be focused on the needs of the Fluid communities, and of open source in general. The OSDPL will build upon existing pattern libraries through the contribution of multiple people from a diverse community. It will be different from other libraries because patterns will be dynamic, current, editable, and allow anyone to provide examples for their particular context. The OSDPL community will need to work together and put practices in place to make sure the patterns in the library won't stagnate and will remain relevant to the community.

The OSDPL patterns will be open source, include information about accessibility, and, where applicable, link to our (also open source) Fluid components. Currently Yahoo! is the only other pattern library that does these things. Our patterns also provide detailed integration advice for Fluid components, which is unique.

Our focus on a variety of different audiences (e.g. developers as well as designers) and recognition that those different audiences require different views on the patterns and perhaps even different workflows through the library is also unique, and a feature which we believe will make the library more valuable and easier to use.

Showing and describing the patterns in various communities/applications is also unique.  We recognize that there are many ways to solve the same problem, and that context matters, and will try to help pattern users think through all of this. Examples in the OSDPL of how patterns have been implemented in our communities can serve as a bit of a style guide for each community as well.

Since anyone can contribute patterns to the OSDPL (perhaps subject to a still to be defined review process), it could (eventually) become the one place where all the patterns from many libraries are collected, assuming we can design an adequate searching and filtering mechanism and convince the other pattern authors to open source their patterns. This is a longer-term goal that we won't immediately pursue.

Discussion

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?

For the immediate future, UI design patterns should be the scope of the OSDPL. We could start with the category we think most appropriate, but design the library to allow for future expansion. Focus should be placed on nurturing a community that can help sustain and drive the direction, and inform the future scope of the OSDPL. If the community would like other kinds of patterns, then it should grow from that. Starting with a small scope will give the OSDPL focus it needs as it grows.

In the future, we may also want to consider having other related patterns that address behavioral issues (e.g. community building, collaborative work), as they could be very helpful to all the audiences we've targeted while they are doing interaction design work. 

It may be helpful to explore our programmer audience might find the library more helpful (e.g. more of a "one stop shop") if there were some programming patterns in the library as well. If we did add this type of pattern, it would probably be necessary to separate the search somehow so programming patterns didn't come up for people doing interaction design work and vice versa. Or perhaps programming design patterns don't reside in exactly the same space, but are provided another part of the library. Are there programming design patterns for "How to code a Fluid component" that we could use, for example?

In the future, we should also consider including design principles in the OSDPL. We should categorize as them as design principles (e.g. "safe exploration" or "satisficing") rather than patterns.  Understanding how and why users behave in certain ways is very important to good design, but not everything can live in a pattern.  Principles are sort of those overarching drivers in design.  Perhaps principles aren't of interest to all audiences but we believe all designers find them useful.  We should use existing principles wherever possible, and may want to ask Jenifer Tidwell if we can put the principles in her book on the OSDPL (since they aren't available on the web where we can point to them).

We don't think that we need to create a list of all possible patterns that the library could include now, but will track all pattern suggestions we receive here:

There may be some distinction between widget-oriented and content-oriented patterns, which may help us classify UI design patterns.

Discussion

7. Where can the group discuss these questions?

At meetings, on the mailing list, or on the wiki. People should use whatever method they are most comfortable with, and the lead for each set of questions will take responsibility for putting what's received via the mailing list on the wiki.

Discussion

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

This one hasn't gone out to the full group for discussion yet, but currently we are doing this via the fluid-talk mailing list, periodic pings to other (e.g. sakai-ux, jasig-ue) mailing lists, meeting dates on the Design Patterns page of the Fluid wiki and as articles at http://uidesignpatterns.org. Conference presentations on OSDPL are also occurring, but their point is more to build a community at a higher level rather than announce specific meetings. We should all also talk to people at conferences about the library and continue to advocate for patterns coming in.

Discussion

Email, conference presentations, wiki, etc. 

9. How can we foster a community to advise and assist with the creation of the pattern library?

We'd talked in Question #4 about waiting until we understood our own goals before reaching out to other communities. We should probably talk about how soon we'd want to consider each of the approaches below. Our outreach will probably be limited to some extent due to limited resources, but it is likely that interest will grow organically as people begin to integrate components and our library grows with useful patterns.

To build this community we can approach not only designers, but also developers in other areas who have done innovative work in UI and ask them to be part of our community, to share their work, their expertise, and their lessons learned. This means keeping abreast in open source community and OS projects to know where the interesting UI problem domains are being addressed.

We can also help folks realize and get excited about what the pattern library can do for them, through our participation in conferences and mailing lists (including those of other design pattern libraries), and then recruit contributors (some of whom might already be creating their own patterns).

In the future, we may want to consider contacting groups like usual list and organizational communities like IxDa, BayChi, IAI, etc., and higher-ed campus groups at other institutions (such as the Stanford UC group, which did discuss pattern libraries).

For people who come to the library, we should aim to keep the library open, and encourage people to give feedback, ask questions, answer questions, and collaborate. The threshold for entry should be low, ensuring that it is easy to join the community, contribute patterns, and make comments.

We can also consider including tools in the OSDPL that the community could use communicate, including threaded discussions, rankings, profiles, etc. We can also provide incentives for people to contribute and comment on patterns by leveraging user profiles and ratings (to recognize really helpful contributors or commentors), and get discussion and refinement of patterns going in the library itself.

As we are figuring out overall goals of the pattern library and then beginning to seed it initially with the first patterns (in the process of which we will be figuring out the best processes for creating, editing, finalizing and releasing patterns) it will also be helpful to have teleconference meetings. It may also be a good idea to have periodic teleconferences in the future to stay in touch with folks and ensure that people keep the library foremost in mind and continue to create and use patterns.

Discussion