- How can patterns add value to the Fluid community?
- What do we mean by "design patterns"?
- What is the proper granularity for a design pattern?
- Who is our audience?
- Programmers, UX Designers, Jr. UX Designers
- Individual Fluid apps, all Fluid apps, other university websites & applications, all websites & applications
- What do our target users need?
- How many design patterns do we want to include?
- Should we seed our library from the Sakai Design Patterns Library?
- Do we want to include only patterns which relate to our components?
- Will Kuali Student require more general design patterns?
- What is our scope?
- How can we assist with the generation of the overall Fluid Component package?
- Patterns, style guide
, component code, component implementation instructions (design & technical)
- Patterns, style guide
- How do we want to present the information?
- Wiki, Content Management system
- How to classify the patterns/organize the information (hierarchy, tags, search, links to component code)?
- Should we use PLML (Pattern Language Mark-Up Language) to facilitate re-use of our library?
- How can we help our target users find what they need?
- Indexing, search, tags, dynamic generation of examples for each application
- How does the Fluid DP library relate to/borrow from other DP libraries? What value do we add?
- How can we ensure the Fluid DP library remains relevant/lives on?
- Who will be members of the group?
- When/how often should we meet?
- What are the first tasks we'd like to begin working on? Longer-term tasks/general project plan?
- What does the OSDPL have to offer that goes beyond what other pattern libraries offer?
Manage space
Manage content
Integrations