Some naming issues for UIOptions

[Zenevich, Yura]

Hi everyone,

So based on the today's conversation we ended up narrowing down the possible names for options in the "out of the box" category to: |starter| and |basic|.

I will update my pull request asap. Please, if you have any preferences or concerns regarding the chosen names, reply to this thread.

Regards,

Yura

On 2013-06-04, at 10:36 AM, Justin Obara <obara.justin at gmail.com> wrote:

> I've given this some more thought today, and have the following suggestions.
> 
> fluid.uiOptions.defaultSettingsPanels -> fluid.uiOptions.settingsPanels
> fluid.uiEnhancer.defaultActions -> fluid.uiOptions.actions
> 
> These could be further subdivided as needed, (e.g. fluid.uiOptions.textSettingsPanels, fluid.uiEnhancer.textActions).
> 
> 
> I haven't yet come up with any suggestions for renaming fluid.uiOptions.defaultModel and fluid.uiOptions.defaultModel.outOfTheBox, but do have some questions about them.
> 
> 1) Do we really need fluid.uiOptions.defaultModel as a grade? It appears to only set an empty defaultModel as a member. If one was to override this, as illustrated by fluid.uiOptions.defaultModel.outOfTheBox, you'd have to basically rewrite all of the configuration anyways. The only difference is the gradeName "fluid.uiOptions.defaultModel" vs "fluid.littleComponent". 
> 
> 2) Why don't we use "fluid.uiOptions.defaultModel.outOfTheBox" as a grade of what is currently called fluid.uiOptions.defaultSetttingsPanels and fluid.uiEnhancer.defaultActions, instead of including it along side those?
> 
> Thanks
> Justin
> 
> On 2013-06-03, at 2:01 PM, Justin Obara <obara.justin at gmail.com> wrote:
> 
>> 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 <Antranig.Basman at colorado.edu> 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 - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>> 
>