Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

  • 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 (question) , component code, component implementation instructions (design & technical)
  • 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?
  • How should a targeted project implement a pattern in a way that future versions, enhancements and fixes can be pulled through to the targeted project in a maintainable and SCC-ed way?
    • Are Fluid's pattern's merely examples and documentation?
    • OS projects all have different and inconsistent methods of managing code that is sent from the server to the client (template or theme layers) that make this very difficult to generalize and abstract.
  • What does the OSDPL have to offer that goes beyond what other pattern libraries offer?
  • No labels