Looking forward to chatting about this in the channel today, but I'll add my current thoughts here just in case.
I think I'm in agreement with not using the word "default" for the "outOThefBox" configuration. I was a bit leery about this as I helped implement it, and should have put more thought into it at the time. As with the rest of our naming, I think we need something descriptive about what exactly it is that a user could expect from it. What makes this set different from some set that other parties might create? For that matter would we ever consider creating multiple sets ourselves? For example, one that included only the legacy options and one that also included new settings like "content simplification"? I'm also not sold on fluid.uiOptions.defaultModel as a component/gradeName. When first reading that I would assume that it is itself the default model, but that is actually at fluid.uiOptions.defaultModel.defaultModel. The word "defaults" is already associated with a component's "default" configuration as specified in a call to fluid.defaults. If we call too many things "defaults" it will make things increasingly confused. I think we should try to refrain from using this word where possible. Thanks Justin On 2013-06-03, at 2:49 AM, Antranig Basman <[email protected]> wrote: > On 23/05/2013 13:17, Cheetham, Anastasia wrote: >> >> 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.) > > Thanks for these remarks, Anastasia. In answer to the last questions - we > don't have an alternative to have names for the separate grades as well as > the since grade which combine them for user convenience. If the separate > grades didn't have names, they couldn't exist :) "outOfTheBox" seems to be > our current de facto alternative to "default", and I think words like > "builtIn" are prejudicial by virtue of the previous argument suggesting > "privilege for the 1st parties" - clearly these grades are NOT actually > "built in" as we established. > > I'm not particularly excited about any of the words on offer, so calling on > the community for some fresh brainstorming! Perhaps we can have a chat in IRC > tomorrow - > > Cheers, > A > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
