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 8 Next »

Agenda

  • Review one pattern on our own for the first half of the meeting tomorrow (Wed.)
  • Come together at 11:30 PDT/2:30 EDT with the goal of either:
    • saying the pattern is ready to go or
    • coming up with a list of what needs to be completed to do this.
  • If applicable, as we do our work we can update How to Create a Good Design Pattern
  • Protocol for deleting patterns from the Fluid wiki
  • Do we want to consider having symbols on pattern pages which indicate different levels of pattern "release" (e.g. Incomplete, Under Development, and Complete, endorsed)?

Attendees

Allison, Erin Jess, Jonathan, Paul

Meeting Notes

  • First half of meeting was spent individually reviewing the File Upload pattern
  • Second half:
    • Discussion of File Upload pattern
      • The description of how to select multiple files isn't complete. We need to add a description of how to drag a box around them with the mouse to select too.
      • Erin: should we add something here about helping with single file upload?
        • Allison: The pattern does specify some situations when it would be helpful for single files in "Use When," but it may be too much information to process in an Uploader when users simply need the functionality in the standard HTTP upload: Browse -> Choose File -> Upload. We found in user testing that users thought the Uploader had a lot of information to process.
        • Paul: I've also found it somewhat confusing in XP to see the OS File Browser on top of the Uploader when I first browse to a file (whose functionality doesn't work). It's hard to tell what it is and is cluttered.
        • Erin: This is a bug I've reported. The Uploader shouldn't be shown in that situation.
        • Conclusion: This pattern is probably more than necessary when users want to just upload a single file. We need another pattern for the simple HTTP file upload. This pattern should be named "Simple File Upload." This means the current (more complex) File Upload pattern needs a different name. Suggestions: Robust File Upload, Comprehensive File Upload, Multi-function File Upload, Full-Featured File Upload...we will need to think on this and decide on a name.
      • Erin: Do we need to add "This pattern in other collections?
        • Allison: I checked, and there is no other pattern like this out there.
      • Paul: A lot of our patterns are very declarative, and don't seem to reflect workflow.
        • Erin: We do want to describe the interaction between the application and the user, which is workflow.
        • Allison: We need to be careful about how much of the workflow we define in a pattern. Some of what we've done with the components reflect subjective design decisions based on our context, and we need to remember keep boundaries between the components and the design patterns to some extent. For instance, Tidwell is less apt to prescribe an entire interaction than Yahoo! might be. We can talk about the design decisions we made and explain the rationale behind them, but in some cases (e.g. for very specific interactions) may not want to say that it is the only way to do something (e.g. in File Upload, do we want to say it must include the ability to stop or cancel the upload after it's started?)
        • Paul: this pattern can be used
          • user needs to queue files
          • user needs to upload files from other places
        • Jonathan: the accessibility section should be revisited, as there have been changes to the way we interpret ARIA since he wrote this.
        • Post-meeting question from Allison: are we taking on bigger chunks of functionality in the File Upload pattern than is normally encoded in a pattern? Or are we missing smaller chunks of functionality that compose file upload?
    • Process questions
      • How often do we want to review patterns going forward to make sure things like Accessibility Info/ARIA aren't out of date? - something to keep in mind
      • How should we continue the process of releasing patterns?
        • Decisions:
          • For now (until we define the final process), have at least two people give the pattern a final review & edit, then have the original pattern author review the changes before sending it to the list.
          • As patterns are moved to the wiki, we will remove the content from that pattern's page on the wiki, but leave the page there with a pointer to the pattern on the OSDPL. This way, we can just look back in the revisions to see the old content, but it will be clear there is no current content for that pattern on the wiki.
      • What should we do at next week's meeting?
        • We may want to talk about governance (Jonathan's area), or we may want to review another pattern. Allison & Jonathan to send out an email by the end of the week about what we will do.
      • How should we release the File Upload pattern?
        • Allison & Erin will finish their edits, addressing issues above, Jonathan says Accessibility Info issues can be addressed after pattern 'release'
        • Pattern will be renamed
        • Eli and Daphne to review final pattern since they were the original authors
        • We will send it out to the list saying it is 'released' and asking for feedback
        • TBD: do we want to put any notation on the patterns to show that they are finalized or endorsed?
  • No labels