Agenda

Are there any urgent OSDPL issues which have not been addressed and need to be for the Fluid Infusion 0.4 release?
Discuss findings, recommendations, & whether there are any urgent fixes from the OSDPL Accessibility Review
Discuss OSDPL Pattern format - what audience are we trying to reach now?
Discuss experience editing Sakai Design Patterns & entering them into the OSDPL & any unmet needs or recommendations
Discuss experience migrating Fluid Design Patterns to the OSDPL & any unmet needs or recommendations

Attendees

Allison, Daphne, Eli, Erin, Jonathan

Meeting Notes

Though all the blocker issues have been resolved for the OSDPL release, the Fluid design patterns will likely need another review before saying they are "finalized" and there may be some more changes needed to the Pattern Data entry form based on today's discussion.
OSDPL Accessibility Review
- Erin and Jonathan walked the group through the OSDPL Accessibility Testing Results and Notes document
- Overall, there were no major glaring accessibility issues that we feel we need to create a disclaimer page on the OSDPL about
- There was a discussion of whether we have to be accessible as there were accessibility issues there. Eli said that Safari is notoriously inaccessible, and that we test for accessibility in Safari for Fluid components, but don't hold ourselves to being accessible there. We felt this probably applied to the OSDPL as well.
- uidesignpatterns.org -> we may want to direct to osdpl.fluidproject.org or osdpl.org so that folks aren't confused by the URL not matching the site name
- Though not mentioned specifically on the report, Jonathan did tab through the pattern data entry form and it seemed fine
- ACTION ITEM: Whole team to go through the OSDPL Accessibility Testing Results and Notes and add their comments about what design changes to make
- ACTION ITEM: After that, Allison & Jonathan to go through the report together and determine which items to enter JIRAs for
OSDPL Pattern format
- Discussion of "Why" vs. "Rationale"
  - To some extent, these could be synonyms. "Why" could be viewed as a deeper and more academic explanation of the reasons the pattern works (e.g. referring to design principles, studies).
  - Erin says "How" could explain how the design should work, and the "Rationale" should come after it saying why the decisions were made. For example, how would explain what the pager would look like, rationale would say why we went with the mid-range display instead of consecutive pages.
  - Daphne says "Rationale" could be overwhelming if it includes all our design decisions, and doesn't think that should be its function. She thinks the "Why/Rationale "section should include why the pattern is the way it is, why use this pattern, why we have this pattern, design principles, etc..
- Jon says developers need to understand design rationale as well so they know when they can and cannot skip recommendations the pattern. They can decide based on the rationale whether it makes sense for their context or whether they'd want to make a change. The highlight in inline edit is a good example of this.
  - Allison: help text can further describe what we want in each section as it's entered. We may want to update it based on our discussions. It may not be bad to have (somewhat) long help text in the pattern data entry form since user won't often be entering patterns.
  - ACTION ITEM: Allison to add a task to further flesh out rationale help text, and for everyone to review all help text
  - Decision: the format will stay as it is in the OSDPL right now, using "Why" instead of "Rationale" and keeping "Rationale" after instead of before "How"
  - In the future we may want to separate these two concepts for designers & developers, but this format will work as an interim step
- Some discussion of where links to related patterns should go since Tidwell mentions them in both the "Use When" (e.g. if there is an alternative pattern, she may say that's another option) and the "Why" sections. No hard decision made on that but we should mention them wherever it makes sense when you are describing the pattern.
- Discussion of where to put Fluid Component Integration Advice
  - In earlier discussions, we thought it would make sense to put all design advice in the "How" section, not the new "Component Integration Advice" section because we thought things about how the component should behave would be better in "How"
  - Eli was thinking about pointing to other Uploaders when he worked on his design pattern (to make the library less Fluid-centric), and he thought about listing them but realized that they do things slightly differently so that might detract from our recommended pattern/component. However, his impression in general was that having too much information in the patterns about Fluid components, especially without allowing the inclusion of information about other libraries' components, didn't jive well with the OSDPL Mission Statement of having a very open pattern library.
  - Decision: we feel that the OSDPL patterns and Fluid components should not be tied so closely together that it feels more like a "Fluid" pattern library than an "open source" pattern library. The "Fluid Component Integration Advice" should not reside in the patterns at all, and would be a better fit in the component tutorials. There can then also be a prominent link from the tutorial back to the design pattern for more info. Most of what we are currently calling component integration advice (e.g. see "Design Suggestions when implementing the Uploader" in the Upload pattern) can actually be generalized to become a part of the "How/Rationale" section of the design pattern, and we think that should remain in the pattern (without reference to what parts of this the Fluid component does or does not support). We will also keep links in the patterns to "Related Components" and allow folks to enter both Fluid and non-Fluid components there.
- All these decisions about pattern format are being made based on current knowledge of a developing process, and will be subject to change over time.
- Some discussion of the proper granularity of a pattern, e.g. for the Inline Edit Design Pattern, would having an explicit "Edit" link be different from clicking on the field to be edited itself to "open" it be completely different patterns, related patterns under the same parent, or the same pattern? We will keep this granularity issue in mind as we create patterns and create guidelines if it makes sense.
Entry of Sakai Patterns & Fluid patterns into the OSDPL
- Not much time at all for this discussion as the previous discussion items took most of the meeting
- Fluid pattern entry from wiki mostly complete, Sakai's are entered but the "Review for Generality" was barely started, and Allison has a couple pieces of Advice on this that she will publish
- We need to figure out what type of review process the patterns should go through before they are "finalized" on the OSDPL--should we review a pattern at the small group working meetings? We need to make sure to give people enough time to review. Do we need something like the Sakai pattern library has to say the patterns are "Complete & Endorsed," "Under Development," or "Incomplete?" Perhaps we don't even publish some of these categories.
- Jonathan created a skeleton page on the OSDPL on "How to create a good design pattern," but there isn't much there yet and it isn't published.
- ACTION ITEMS: Allison create wiki pages for general advice on entering a Fluid design pattern & page for advice on editing a Sakai pattern for generality in the OSDPL. We can work on them in the wiki then migrate them to the OSDPL.
- Potential next small group meeting topic: Close review of a Fluid pattern

Browser not supported