Anastasia, This looks great!
There's one thing I'm a bit confused about though: I see that the "UI Options API" is a child of "Fat Panel UI Options" in your instance. Is this hierarchy intentional, or just an artifact of the draftyness? In our designs, we suggested having the higher level family of components encapsulate the individual components (e.g., Inline Edit -> Simple Inline Edit). Cheers, James On Mon, Jul 4, 2011 at 2:15 PM, Cheetham, Anastasia <[email protected]>wrote: > > Jonathan and James (et al.), > > I've been working on how to use the component API design mock-ups > > http://wiki.fluidproject.org/display/fluid/Infusion+documentation+redesign+%28April+2011%29#Infusiondocumentationredesign%28April2011%29-API%3AComponent > > as the basis for documenting a component that is actually made up of > several "configurable subcomponents." > > My first stab at this is on the wiki, at > > http://wiki.fluidproject.org/display/fluid/Fat+Panel+UI+Options+API+%28in+development%29 > > Note that the bulk of the information is on the "uiOptions" subcomponent's > page, since that's where the bulk of the component is. We would ultimately > have a page for "Full with preview" and "Full without preview" which would > each link to the same "uiOptions" sub-page as well as to any particular > subcomponents. I haven't filled in most of the actual information – this is > mostly an exploration of the organization and navigation of the information: > the breakdown into separate pages, the links between them, etc. > > I'd love to have some feedback on this approach and any suggestions for > improvement. > > -- > Anastasia Cheetham Inclusive Design Research Centre > [email protected] Inclusive Design Institute > OCAD University > >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
