Antranig, this is an interesting topic. Naming can be a tricky thing; thinking about the issues you raise has really got me pondering.
Here are some stream-of-conciousness thoughts: Some opinions, some musings, some questions… First, Antranig, some of the points in your email brought to mind the discussions started in the thread "Designing a new UIO API." In that thread, you pointed out that we don't want to somehow elevate the out-of-the-box set of panels and settings to any privileged status. You also said > We anticipate that in real life, almost ALL practical uses of UIO will be in > the scenarios labelled under the headings "adding settings" and "removing > settings". These points make a lot of sense to me. Combine them with the information in this email, and it seems that the natural, un-altered state of the components is: empty. I'm inclined to refer to the "natural, un-altered state of the components" as the "default" state. But if we use "default" in our naming of the empty components, how then do we refer to the set of out-of-the-box panels and settings? "outOfTheBox"? "builtIn"? "starter"? "basic"? Should we even be referring to them as a set at all? Correct me if I'm wrong, but I imagine there will be use-cases where integrators might want to use *some* of the out-of-the-box settings but not others. Perhaps there should be no single grade that adds all of them, but rather separate grades for each? (Personally, I think we *should* have a single grade that adds all the out-of-the-box settings in one go – and not require six separate grades – but I could probably be convinced otherwise by good arguments.) -- 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
