This page covers the design topics for Worldwide Sprint 2

Our goal for this sprint is to flesh out details for the high and medium priority plugins here on the wiki to jumpstart the planning for upcoming releases.  Since most of these pages are brand new, the first step is to simply describe the functionality and common uses of the plugin by filling out the functional description in Section 1. The idea is to always start by explaining as simply as possible what we think each plugin should do and agree on that first before we start throwing designs and code into the mix. For a decent example of what this means, please take a look at the button page to get a sense of what the first rough pass should look like.

Once we have the description filled out, we can start working designs/wireframes (Section 2) and sample HTML markup and styles (Section 4). These will inform the technical specification phase (Section 3) which is where we actually nail down the specific options, methods, events and API for the plugin. Yes, the section order is a bit wacky, we know.

People can just jump in and start filling out Section 1 for each of the items below, but I've made notes for the specific things we should get done if time allows.

High priority - try to tackle these first on Friday

Position

• Fill out Section 1: 
  • List high level requirements, features, options, and defaults for  positioning -- lots of different facets to write down for review
  • Generate a rich list of possible positoning scenarios we want this to cover, ideally with wireframe illustration for each, will be used for specification and tests

Shadow

• Fill out Section 1: (the button page has a pretty good start for this section, so let's use this as a model for the others)
  • List high level requirements, features, options, and defaults for shadow
  • Generate list of shadow use case scenarios where this would be used, will be used for specification and tests
• Review CSS framework shadow attributes already in ThemeRoller to ensure these are complete and workable

Stack fix

• Fill out Section 1: 
  • List high level requirements, features, options, and defaults for shadow
  • Generate list of use case scenarios where this would be used, will be used for specification and tests

Modal

• Fill out Section 1: 
  • List high level requirements, features, options, and defaults for modal feature
  • Generate list of use case scenarios where this would be used, will be used for specification and tests

Autocomplete

• Update section 1 description with additional scenarios/features/options if needed
• Since this plugin is pretty far along, review current tech specs (Section 3) to make sure it covers normal use case scenarios. 
• Review proposed html markup and styles for autocomplete menu (Section 4), test on supported browsers

Medium priority - try to cover these on Friday afternoon and Saturday 

Datepicker (refactor)

• Since this is a re-factor, start by filling out a bulleted list of functional changes, new features and code changes in Section 1

Buttons

• Review and revise Section 1:
  • This section is in pretty good shape and should serve as a rough template for how we want to fill out the other plugin pages for a first pass at describing the functionality and use cases.
  • Review and refine the list of button types, make sure we're covering all typical situations
  • Generate a list of all the contexts where buttons may appear (toolbar, button bar at bottom of datepicker, dialog button bar, etc.) for testing
• Create sample html markup and styles for each button type, test on supported browsers

Toolbar

• Fill out Section 1:
  • Make sure we have a clear list of all the plugins/UI widgets that a toolbar may hold (any button type, input, dropdown, check/radios, etc.) for testing
  • Specify the core features of a toolbar: dividers to group, method to specify alignment for groups of buttons (float these left, these right) and which features may be out of scope but coudl be added via extensions (re-order groups, drag toolbar, way to add/remove/re-order toolbar items)
  • Consider whether you specify a toolbar "style" that determines how buttons within are displayed (with or without button bg/border by default, with or without label text, etc.) or whether we just handle this when we add each button in (no bg.border, show text label)
• Fill out Section 2: Design mockups or wireframes
• Fill out Section 4: Create sample html markup and styles toolbar variations, test on supported browsers

Grid

• Fill out Section 1:
  • Created a prioritized list of features that we would consider as essential for a "simple" grid -- we're focusing on a read-only grid here, not editable grid like Excel
  • List out common use cases for our grid, will be used for specification and tests
• Fill out Section 2: Design mockups or wireframes
• Research on how to get the scrolling table body work while still using a table (not divs) for accessibility reasons while maintaining performance for tables with thousands of rows

Tooltip

• Fill out Section 1:
  • Requirements description for tooltip
  • Use case scenarios where this would be used, will be used for specification and tests
• Fill out Section 2: Design mockups or wireframes
• Fill out Section 4: Create sample html markup and styles for tooltip variations, test on supported browsers