On 2011-07-07, at 11:26 AM, James William Yoon wrote: > 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).
James, thanks for the review. Good question about the hierarchy, and thanks for reminding me about that discussion. I'm not quite sure how we should handle this one: We will, in fact, be *discouraging* people from using the plain UI Options, and encouraging use of one of the three flavours. Essentially, we only want users to be looking at the UI Options docs in the context of it being a subcomponent of one of the flavours. I'm not sure how to structure the hierarchy of the docs to support that. Any ideas? -- 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://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
