You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Kulp <dk...@apache.org> on 2015/09/09 18:53:10 UTC
"advanced" label for params?
I’m working with the UI folks in Talend to enhance the tooling that we provide. Right now, we have various components with specific parameters exposed. This “kind of works”, but as new parameters are added in Camel we have to keep things up to date and such. We’re trying to switch to using the json stuff that is generated at build time (great stuff, BTW) so that all the parameters that are available is presented to the users. Currently, there are labels for “consumer” and “producer” and anything not labelled one of those is common between the two. That’s a great start. However, while testing with some users, we’ve run into a usability problem: some of the components have soooooo many parameters, many of which would rarely ever be used, that trying to find the useful stuff that they care about is harder than it should be. For example, take a look at the file component:
http://camel.apache.org/file2.html
There are 7 “common” options, but for the consumer, there are then an additional 51 options. It’s really too many to present in a single list and not have the user go “what?!?”.
Would there be any objections to adding an “advanced” label to options that are generally not normally used by say 90% of the use cases? I know that determining whether something is “advanced” or not can start heading down the path of bike shedding and the whole “what’s advanced for one user isn’t for another” and all that, but I think we need to have something to help out with this. Another thought was an additional “advanced=true” or “userlevel=1” or similar attribute to denote this, but the label functionality is already there and it seems to be perfect for this.
I did quick look to see how many options we have. I parsed/processed all the component json files (didn’t look at the models or data format) and there are over 10,000 options. It’s a huge task to go through each of them, but if we can agree on a path forward, we can start tackling some of the more used components and then see how that works. File, http, jetty, jms/sjms, etc… Longer term, this info could be used to provide more useful component pages for the docs, putting the more useful stuff at the top.
Thoughts? Objections? Other ideas?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: "advanced" label for params?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Sep 22, 2015 at 3:30 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Sep 22, 2015, at 3:15 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>> I got a bunch of more components to use more labels.
>>
>> However for login credentials I used "security". But I wonder if we
>> should use "login" for username/password etc so they "stand out" as
>> security can have a bunch of other options for TLS/chipers/and
>> whatnot.
>
> Would “Authentication” work better? For components that have other types authentication/login options (SSH for example) could group them all together.
>
Yeah that is a better name, and its also starting with A, so it may be
shown in a tab earlier than Login, if tabs are sorted A..Z etc.
> Dan
>
>
>
>
>>
>>
>>
>> On Mon, Sep 14, 2015 at 10:38 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Yeah maybe advanced is a term that is maybe used in other products. So
>>> I guess its after all an okay word.
>>>
>>> I logged a ticket about this
>>> https://issues.apache.org/jira/browse/CAMEL-9131
>>>
>>> On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>> Using the word advanced is imho not always the best word for uncommon
>>>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>>>> can be used.
>>>>
>>>> The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s gui for similar things. If you are on a Mac, go to your Settings app and open up the “Security & Privacy” settings. There is an “Advanced…” button. Likewise in the “Internet Accounts”. There were a few other places I saw this as well while poking around the various OS X applications preferences panels.
>>>>
>>>> Of course, this could be something Apple has localized to my US version of OSX. No idea. :-) No idea what MS does in Windows.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Yeah it was the idea to add more labels to the options. The idea is
>>>>> that you can append more labels separated by comma, eg
>>>>>
>>>>> "consumer,common,security"
>>>>> "consumer,common"
>>>>> "consumer,networking"
>>>>> "consumer,security"
>>>>>
>>>>> And if a component is only consumer or producer then that would be
>>>>> implied, and you do not need to have "consumer" or "producer".
>>>>>
>>>>> Though as we know naming is hard in IT so sometimes it can be a bit
>>>>> hard to find a good name and categorize all those options.
>>>>>
>>>>> And there is also some inherited options like synchronized /
>>>>> exchangePattern that most people do not use, but what label should
>>>>> they have?
>>>>>
>>>>> Using the word advanced is imho not always the best word for uncommon
>>>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>>>> can be used.
>>>>>
>>>>> If we get all that done eventually then all the components is
>>>>> documented out of the box and is also tooling friendly and using the
>>>>> same grouping of the options, as well documentation (its just the
>>>>> javadoc) eg all the stuff there is out of the box in the json file.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
>>>>>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>>>>>> often been overwhelmed myself at the list of options for some components
>>>>>> :-) I imagine it also clutters up UIs for the sake of showing options only
>>>>>> a small number of people may ever use.
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>>
>>>>>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>>>>>> provide. Right now, we have various components with specific parameters
>>>>>>> exposed. This “kind of works”, but as new parameters are added in Camel we
>>>>>>> have to keep things up to date and such. We’re trying to switch to using
>>>>>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>>>>>> all the parameters that are available is presented to the users.
>>>>>>> Currently, there are labels for “consumer” and “producer” and anything not
>>>>>>> labelled one of those is common between the two. That’s a great start.
>>>>>>> However, while testing with some users, we’ve run into a usability
>>>>>>> problem: some of the components have soooooo many parameters, many of
>>>>>>> which would rarely ever be used, that trying to find the useful stuff that
>>>>>>> they care about is harder than it should be. For example, take a look at
>>>>>>> the file component:
>>>>>>>
>>>>>>> http://camel.apache.org/file2.html
>>>>>>>
>>>>>>> There are 7 “common” options, but for the consumer, there are then an
>>>>>>> additional 51 options. It’s really too many to present in a single list
>>>>>>> and not have the user go “what?!?”.
>>>>>>>
>>>>>>>
>>>>>>> Would there be any objections to adding an “advanced” label to options
>>>>>>> that are generally not normally used by say 90% of the use cases? I know
>>>>>>> that determining whether something is “advanced” or not can start heading
>>>>>>> down the path of bike shedding and the whole “what’s advanced for one user
>>>>>>> isn’t for another” and all that, but I think we need to have something to
>>>>>>> help out with this. Another thought was an additional “advanced=true” or
>>>>>>> “userlevel=1” or similar attribute to denote this, but the label
>>>>>>> functionality is already there and it seems to be perfect for this.
>>>>>>>
>>>>>>> I did quick look to see how many options we have. I parsed/processed all
>>>>>>> the component json files (didn’t look at the models or data format) and
>>>>>>> there are over 10,000 options. It’s a huge task to go through each of
>>>>>>> them, but if we can agree on a path forward, we can start tackling some of
>>>>>>> the more used components and then see how that works. File, http, jetty,
>>>>>>> jms/sjms, etc… Longer term, this info could be used to provide more
>>>>>>> useful component pages for the docs, putting the more useful stuff at the
>>>>>>> top.
>>>>>>>
>>>>>>>
>>>>>>> Thoughts? Objections? Other ideas?
>>>>>>>
>>>>>>> --
>>>>>>> Daniel Kulp
>>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Jon
>>>>>> ---------------
>>>>>> Red Hat, Inc.
>>>>>> Email: janstey@redhat.com
>>>>>> Web: http://redhat.com
>>>>>> Twitter: jon_anstey
>>>>>> Blog: http://janstey.blogspot.com
>>>>>> Author of Camel in Action: http://manning.com/ibsen
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2nd edition:
>>>>> https://www.manning.com/books/camel-in-action-second-edition
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2nd edition:
>>> https://www.manning.com/books/camel-in-action-second-edition
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2nd edition: https://www.manning.com/books/ibsen2
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: https://www.manning.com/books/ibsen2
Re: "advanced" label for params?
Posted by Daniel Kulp <dk...@apache.org>.
> On Sep 22, 2015, at 3:15 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> I got a bunch of more components to use more labels.
>
> However for login credentials I used "security". But I wonder if we
> should use "login" for username/password etc so they "stand out" as
> security can have a bunch of other options for TLS/chipers/and
> whatnot.
Would “Authentication” work better? For components that have other types authentication/login options (SSH for example) could group them all together.
Dan
>
>
>
> On Mon, Sep 14, 2015 at 10:38 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Yeah maybe advanced is a term that is maybe used in other products. So
>> I guess its after all an okay word.
>>
>> I logged a ticket about this
>> https://issues.apache.org/jira/browse/CAMEL-9131
>>
>> On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>> Using the word advanced is imho not always the best word for uncommon
>>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>>> can be used.
>>>
>>> The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s gui for similar things. If you are on a Mac, go to your Settings app and open up the “Security & Privacy” settings. There is an “Advanced…” button. Likewise in the “Internet Accounts”. There were a few other places I saw this as well while poking around the various OS X applications preferences panels.
>>>
>>> Of course, this could be something Apple has localized to my US version of OSX. No idea. :-) No idea what MS does in Windows.
>>>
>>> Dan
>>>
>>>
>>>
>>>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> Yeah it was the idea to add more labels to the options. The idea is
>>>> that you can append more labels separated by comma, eg
>>>>
>>>> "consumer,common,security"
>>>> "consumer,common"
>>>> "consumer,networking"
>>>> "consumer,security"
>>>>
>>>> And if a component is only consumer or producer then that would be
>>>> implied, and you do not need to have "consumer" or "producer".
>>>>
>>>> Though as we know naming is hard in IT so sometimes it can be a bit
>>>> hard to find a good name and categorize all those options.
>>>>
>>>> And there is also some inherited options like synchronized /
>>>> exchangePattern that most people do not use, but what label should
>>>> they have?
>>>>
>>>> Using the word advanced is imho not always the best word for uncommon
>>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>>> can be used.
>>>>
>>>> If we get all that done eventually then all the components is
>>>> documented out of the box and is also tooling friendly and using the
>>>> same grouping of the options, as well documentation (its just the
>>>> javadoc) eg all the stuff there is out of the box in the json file.
>>>>
>>>>
>>>>
>>>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
>>>>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>>>>> often been overwhelmed myself at the list of options for some components
>>>>> :-) I imagine it also clutters up UIs for the sake of showing options only
>>>>> a small number of people may ever use.
>>>>>
>>>>> Cheers,
>>>>> Jon
>>>>>
>>>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>
>>>>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>>>>> provide. Right now, we have various components with specific parameters
>>>>>> exposed. This “kind of works”, but as new parameters are added in Camel we
>>>>>> have to keep things up to date and such. We’re trying to switch to using
>>>>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>>>>> all the parameters that are available is presented to the users.
>>>>>> Currently, there are labels for “consumer” and “producer” and anything not
>>>>>> labelled one of those is common between the two. That’s a great start.
>>>>>> However, while testing with some users, we’ve run into a usability
>>>>>> problem: some of the components have soooooo many parameters, many of
>>>>>> which would rarely ever be used, that trying to find the useful stuff that
>>>>>> they care about is harder than it should be. For example, take a look at
>>>>>> the file component:
>>>>>>
>>>>>> http://camel.apache.org/file2.html
>>>>>>
>>>>>> There are 7 “common” options, but for the consumer, there are then an
>>>>>> additional 51 options. It’s really too many to present in a single list
>>>>>> and not have the user go “what?!?”.
>>>>>>
>>>>>>
>>>>>> Would there be any objections to adding an “advanced” label to options
>>>>>> that are generally not normally used by say 90% of the use cases? I know
>>>>>> that determining whether something is “advanced” or not can start heading
>>>>>> down the path of bike shedding and the whole “what’s advanced for one user
>>>>>> isn’t for another” and all that, but I think we need to have something to
>>>>>> help out with this. Another thought was an additional “advanced=true” or
>>>>>> “userlevel=1” or similar attribute to denote this, but the label
>>>>>> functionality is already there and it seems to be perfect for this.
>>>>>>
>>>>>> I did quick look to see how many options we have. I parsed/processed all
>>>>>> the component json files (didn’t look at the models or data format) and
>>>>>> there are over 10,000 options. It’s a huge task to go through each of
>>>>>> them, but if we can agree on a path forward, we can start tackling some of
>>>>>> the more used components and then see how that works. File, http, jetty,
>>>>>> jms/sjms, etc… Longer term, this info could be used to provide more
>>>>>> useful component pages for the docs, putting the more useful stuff at the
>>>>>> top.
>>>>>>
>>>>>>
>>>>>> Thoughts? Objections? Other ideas?
>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Jon
>>>>> ---------------
>>>>> Red Hat, Inc.
>>>>> Email: janstey@redhat.com
>>>>> Web: http://redhat.com
>>>>> Twitter: jon_anstey
>>>>> Blog: http://janstey.blogspot.com
>>>>> Author of Camel in Action: http://manning.com/ibsen
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2nd edition:
>>>> https://www.manning.com/books/camel-in-action-second-edition
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2nd edition:
>> https://www.manning.com/books/camel-in-action-second-edition
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition: https://www.manning.com/books/ibsen2
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: "advanced" label for params?
Posted by Claus Ibsen <cl...@gmail.com>.
I got a bunch of more components to use more labels.
However for login credentials I used "security". But I wonder if we
should use "login" for username/password etc so they "stand out" as
security can have a bunch of other options for TLS/chipers/and
whatnot.
On Mon, Sep 14, 2015 at 10:38 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah maybe advanced is a term that is maybe used in other products. So
> I guess its after all an okay word.
>
> I logged a ticket about this
> https://issues.apache.org/jira/browse/CAMEL-9131
>
> On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>>> Using the word advanced is imho not always the best word for uncommon
>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>> can be used.
>>
>> The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s gui for similar things. If you are on a Mac, go to your Settings app and open up the “Security & Privacy” settings. There is an “Advanced…” button. Likewise in the “Internet Accounts”. There were a few other places I saw this as well while poking around the various OS X applications preferences panels.
>>
>> Of course, this could be something Apple has localized to my US version of OSX. No idea. :-) No idea what MS does in Windows.
>>
>> Dan
>>
>>
>>
>>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> Yeah it was the idea to add more labels to the options. The idea is
>>> that you can append more labels separated by comma, eg
>>>
>>> "consumer,common,security"
>>> "consumer,common"
>>> "consumer,networking"
>>> "consumer,security"
>>>
>>> And if a component is only consumer or producer then that would be
>>> implied, and you do not need to have "consumer" or "producer".
>>>
>>> Though as we know naming is hard in IT so sometimes it can be a bit
>>> hard to find a good name and categorize all those options.
>>>
>>> And there is also some inherited options like synchronized /
>>> exchangePattern that most people do not use, but what label should
>>> they have?
>>>
>>> Using the word advanced is imho not always the best word for uncommon
>>> options. Maybe some good english word for "uncommon / seldom / rare"
>>> can be used.
>>>
>>> If we get all that done eventually then all the components is
>>> documented out of the box and is also tooling friendly and using the
>>> same grouping of the options, as well documentation (its just the
>>> javadoc) eg all the stuff there is out of the box in the json file.
>>>
>>>
>>>
>>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
>>>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>>>> often been overwhelmed myself at the list of options for some components
>>>> :-) I imagine it also clutters up UIs for the sake of showing options only
>>>> a small number of people may ever use.
>>>>
>>>> Cheers,
>>>> Jon
>>>>
>>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>
>>>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>>>> provide. Right now, we have various components with specific parameters
>>>>> exposed. This “kind of works”, but as new parameters are added in Camel we
>>>>> have to keep things up to date and such. We’re trying to switch to using
>>>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>>>> all the parameters that are available is presented to the users.
>>>>> Currently, there are labels for “consumer” and “producer” and anything not
>>>>> labelled one of those is common between the two. That’s a great start.
>>>>> However, while testing with some users, we’ve run into a usability
>>>>> problem: some of the components have soooooo many parameters, many of
>>>>> which would rarely ever be used, that trying to find the useful stuff that
>>>>> they care about is harder than it should be. For example, take a look at
>>>>> the file component:
>>>>>
>>>>> http://camel.apache.org/file2.html
>>>>>
>>>>> There are 7 “common” options, but for the consumer, there are then an
>>>>> additional 51 options. It’s really too many to present in a single list
>>>>> and not have the user go “what?!?”.
>>>>>
>>>>>
>>>>> Would there be any objections to adding an “advanced” label to options
>>>>> that are generally not normally used by say 90% of the use cases? I know
>>>>> that determining whether something is “advanced” or not can start heading
>>>>> down the path of bike shedding and the whole “what’s advanced for one user
>>>>> isn’t for another” and all that, but I think we need to have something to
>>>>> help out with this. Another thought was an additional “advanced=true” or
>>>>> “userlevel=1” or similar attribute to denote this, but the label
>>>>> functionality is already there and it seems to be perfect for this.
>>>>>
>>>>> I did quick look to see how many options we have. I parsed/processed all
>>>>> the component json files (didn’t look at the models or data format) and
>>>>> there are over 10,000 options. It’s a huge task to go through each of
>>>>> them, but if we can agree on a path forward, we can start tackling some of
>>>>> the more used components and then see how that works. File, http, jetty,
>>>>> jms/sjms, etc… Longer term, this info could be used to provide more
>>>>> useful component pages for the docs, putting the more useful stuff at the
>>>>> top.
>>>>>
>>>>>
>>>>> Thoughts? Objections? Other ideas?
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Jon
>>>> ---------------
>>>> Red Hat, Inc.
>>>> Email: janstey@redhat.com
>>>> Web: http://redhat.com
>>>> Twitter: jon_anstey
>>>> Blog: http://janstey.blogspot.com
>>>> Author of Camel in Action: http://manning.com/ibsen
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2nd edition:
>>> https://www.manning.com/books/camel-in-action-second-edition
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition:
> https://www.manning.com/books/camel-in-action-second-edition
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: https://www.manning.com/books/ibsen2
Re: "advanced" label for params?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah maybe advanced is a term that is maybe used in other products. So
I guess its after all an okay word.
I logged a ticket about this
https://issues.apache.org/jira/browse/CAMEL-9131
On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>> Using the word advanced is imho not always the best word for uncommon
>> options. Maybe some good english word for "uncommon / seldom / rare"
>> can be used.
>
> The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s gui for similar things. If you are on a Mac, go to your Settings app and open up the “Security & Privacy” settings. There is an “Advanced…” button. Likewise in the “Internet Accounts”. There were a few other places I saw this as well while poking around the various OS X applications preferences panels.
>
> Of course, this could be something Apple has localized to my US version of OSX. No idea. :-) No idea what MS does in Windows.
>
> Dan
>
>
>
>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>> Hi
>>
>> Yeah it was the idea to add more labels to the options. The idea is
>> that you can append more labels separated by comma, eg
>>
>> "consumer,common,security"
>> "consumer,common"
>> "consumer,networking"
>> "consumer,security"
>>
>> And if a component is only consumer or producer then that would be
>> implied, and you do not need to have "consumer" or "producer".
>>
>> Though as we know naming is hard in IT so sometimes it can be a bit
>> hard to find a good name and categorize all those options.
>>
>> And there is also some inherited options like synchronized /
>> exchangePattern that most people do not use, but what label should
>> they have?
>>
>> Using the word advanced is imho not always the best word for uncommon
>> options. Maybe some good english word for "uncommon / seldom / rare"
>> can be used.
>>
>> If we get all that done eventually then all the components is
>> documented out of the box and is also tooling friendly and using the
>> same grouping of the options, as well documentation (its just the
>> javadoc) eg all the stuff there is out of the box in the json file.
>>
>>
>>
>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
>>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>>> often been overwhelmed myself at the list of options for some components
>>> :-) I imagine it also clutters up UIs for the sake of showing options only
>>> a small number of people may ever use.
>>>
>>> Cheers,
>>> Jon
>>>
>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>>> provide. Right now, we have various components with specific parameters
>>>> exposed. This “kind of works”, but as new parameters are added in Camel we
>>>> have to keep things up to date and such. We’re trying to switch to using
>>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>>> all the parameters that are available is presented to the users.
>>>> Currently, there are labels for “consumer” and “producer” and anything not
>>>> labelled one of those is common between the two. That’s a great start.
>>>> However, while testing with some users, we’ve run into a usability
>>>> problem: some of the components have soooooo many parameters, many of
>>>> which would rarely ever be used, that trying to find the useful stuff that
>>>> they care about is harder than it should be. For example, take a look at
>>>> the file component:
>>>>
>>>> http://camel.apache.org/file2.html
>>>>
>>>> There are 7 “common” options, but for the consumer, there are then an
>>>> additional 51 options. It’s really too many to present in a single list
>>>> and not have the user go “what?!?”.
>>>>
>>>>
>>>> Would there be any objections to adding an “advanced” label to options
>>>> that are generally not normally used by say 90% of the use cases? I know
>>>> that determining whether something is “advanced” or not can start heading
>>>> down the path of bike shedding and the whole “what’s advanced for one user
>>>> isn’t for another” and all that, but I think we need to have something to
>>>> help out with this. Another thought was an additional “advanced=true” or
>>>> “userlevel=1” or similar attribute to denote this, but the label
>>>> functionality is already there and it seems to be perfect for this.
>>>>
>>>> I did quick look to see how many options we have. I parsed/processed all
>>>> the component json files (didn’t look at the models or data format) and
>>>> there are over 10,000 options. It’s a huge task to go through each of
>>>> them, but if we can agree on a path forward, we can start tackling some of
>>>> the more used components and then see how that works. File, http, jetty,
>>>> jms/sjms, etc… Longer term, this info could be used to provide more
>>>> useful component pages for the docs, putting the more useful stuff at the
>>>> top.
>>>>
>>>>
>>>> Thoughts? Objections? Other ideas?
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Jon
>>> ---------------
>>> Red Hat, Inc.
>>> Email: janstey@redhat.com
>>> Web: http://redhat.com
>>> Twitter: jon_anstey
>>> Blog: http://janstey.blogspot.com
>>> Author of Camel in Action: http://manning.com/ibsen
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2nd edition:
>> https://www.manning.com/books/camel-in-action-second-edition
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition
Re: "advanced" label for params?
Posted by Daniel Kulp <dk...@apache.org>.
> Using the word advanced is imho not always the best word for uncommon
> options. Maybe some good english word for "uncommon / seldom / rare"
> can be used.
The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s gui for similar things. If you are on a Mac, go to your Settings app and open up the “Security & Privacy” settings. There is an “Advanced…” button. Likewise in the “Internet Accounts”. There were a few other places I saw this as well while poking around the various OS X applications preferences panels.
Of course, this could be something Apple has localized to my US version of OSX. No idea. :-) No idea what MS does in Windows.
Dan
> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> Yeah it was the idea to add more labels to the options. The idea is
> that you can append more labels separated by comma, eg
>
> "consumer,common,security"
> "consumer,common"
> "consumer,networking"
> "consumer,security"
>
> And if a component is only consumer or producer then that would be
> implied, and you do not need to have "consumer" or "producer".
>
> Though as we know naming is hard in IT so sometimes it can be a bit
> hard to find a good name and categorize all those options.
>
> And there is also some inherited options like synchronized /
> exchangePattern that most people do not use, but what label should
> they have?
>
> Using the word advanced is imho not always the best word for uncommon
> options. Maybe some good english word for "uncommon / seldom / rare"
> can be used.
>
> If we get all that done eventually then all the components is
> documented out of the box and is also tooling friendly and using the
> same grouping of the options, as well documentation (its just the
> javadoc) eg all the stuff there is out of the box in the json file.
>
>
>
> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>> often been overwhelmed myself at the list of options for some components
>> :-) I imagine it also clutters up UIs for the sake of showing options only
>> a small number of people may ever use.
>>
>> Cheers,
>> Jon
>>
>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>> provide. Right now, we have various components with specific parameters
>>> exposed. This “kind of works”, but as new parameters are added in Camel we
>>> have to keep things up to date and such. We’re trying to switch to using
>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>> all the parameters that are available is presented to the users.
>>> Currently, there are labels for “consumer” and “producer” and anything not
>>> labelled one of those is common between the two. That’s a great start.
>>> However, while testing with some users, we’ve run into a usability
>>> problem: some of the components have soooooo many parameters, many of
>>> which would rarely ever be used, that trying to find the useful stuff that
>>> they care about is harder than it should be. For example, take a look at
>>> the file component:
>>>
>>> http://camel.apache.org/file2.html
>>>
>>> There are 7 “common” options, but for the consumer, there are then an
>>> additional 51 options. It’s really too many to present in a single list
>>> and not have the user go “what?!?”.
>>>
>>>
>>> Would there be any objections to adding an “advanced” label to options
>>> that are generally not normally used by say 90% of the use cases? I know
>>> that determining whether something is “advanced” or not can start heading
>>> down the path of bike shedding and the whole “what’s advanced for one user
>>> isn’t for another” and all that, but I think we need to have something to
>>> help out with this. Another thought was an additional “advanced=true” or
>>> “userlevel=1” or similar attribute to denote this, but the label
>>> functionality is already there and it seems to be perfect for this.
>>>
>>> I did quick look to see how many options we have. I parsed/processed all
>>> the component json files (didn’t look at the models or data format) and
>>> there are over 10,000 options. It’s a huge task to go through each of
>>> them, but if we can agree on a path forward, we can start tackling some of
>>> the more used components and then see how that works. File, http, jetty,
>>> jms/sjms, etc… Longer term, this info could be used to provide more
>>> useful component pages for the docs, putting the more useful stuff at the
>>> top.
>>>
>>>
>>> Thoughts? Objections? Other ideas?
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Jon
>> ---------------
>> Red Hat, Inc.
>> Email: janstey@redhat.com
>> Web: http://redhat.com
>> Twitter: jon_anstey
>> Blog: http://janstey.blogspot.com
>> Author of Camel in Action: http://manning.com/ibsen
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition:
> https://www.manning.com/books/camel-in-action-second-edition
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: "advanced" label for params?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah it was the idea to add more labels to the options. The idea is
that you can append more labels separated by comma, eg
"consumer,common,security"
"consumer,common"
"consumer,networking"
"consumer,security"
And if a component is only consumer or producer then that would be
implied, and you do not need to have "consumer" or "producer".
Though as we know naming is hard in IT so sometimes it can be a bit
hard to find a good name and categorize all those options.
And there is also some inherited options like synchronized /
exchangePattern that most people do not use, but what label should
they have?
Using the word advanced is imho not always the best word for uncommon
options. Maybe some good english word for "uncommon / seldom / rare"
can be used.
If we get all that done eventually then all the components is
documented out of the box and is also tooling friendly and using the
same grouping of the options, as well documentation (its just the
javadoc) eg all the stuff there is out of the box in the json file.
On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <ja...@gmail.com> wrote:
> Yeah, I like the idea of an "advanced" label for non-common options. I've
> often been overwhelmed myself at the list of options for some components
> :-) I imagine it also clutters up UIs for the sake of showing options only
> a small number of people may ever use.
>
> Cheers,
> Jon
>
> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> I’m working with the UI folks in Talend to enhance the tooling that we
>> provide. Right now, we have various components with specific parameters
>> exposed. This “kind of works”, but as new parameters are added in Camel we
>> have to keep things up to date and such. We’re trying to switch to using
>> the json stuff that is generated at build time (great stuff, BTW) so that
>> all the parameters that are available is presented to the users.
>> Currently, there are labels for “consumer” and “producer” and anything not
>> labelled one of those is common between the two. That’s a great start.
>> However, while testing with some users, we’ve run into a usability
>> problem: some of the components have soooooo many parameters, many of
>> which would rarely ever be used, that trying to find the useful stuff that
>> they care about is harder than it should be. For example, take a look at
>> the file component:
>>
>> http://camel.apache.org/file2.html
>>
>> There are 7 “common” options, but for the consumer, there are then an
>> additional 51 options. It’s really too many to present in a single list
>> and not have the user go “what?!?”.
>>
>>
>> Would there be any objections to adding an “advanced” label to options
>> that are generally not normally used by say 90% of the use cases? I know
>> that determining whether something is “advanced” or not can start heading
>> down the path of bike shedding and the whole “what’s advanced for one user
>> isn’t for another” and all that, but I think we need to have something to
>> help out with this. Another thought was an additional “advanced=true” or
>> “userlevel=1” or similar attribute to denote this, but the label
>> functionality is already there and it seems to be perfect for this.
>>
>> I did quick look to see how many options we have. I parsed/processed all
>> the component json files (didn’t look at the models or data format) and
>> there are over 10,000 options. It’s a huge task to go through each of
>> them, but if we can agree on a path forward, we can start tackling some of
>> the more used components and then see how that works. File, http, jetty,
>> jms/sjms, etc… Longer term, this info could be used to provide more
>> useful component pages for the docs, putting the more useful stuff at the
>> top.
>>
>>
>> Thoughts? Objections? Other ideas?
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> Cheers,
> Jon
> ---------------
> Red Hat, Inc.
> Email: janstey@redhat.com
> Web: http://redhat.com
> Twitter: jon_anstey
> Blog: http://janstey.blogspot.com
> Author of Camel in Action: http://manning.com/ibsen
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition
Re: "advanced" label for params?
Posted by Jon Anstey <ja...@gmail.com>.
Yeah, I like the idea of an "advanced" label for non-common options. I've
often been overwhelmed myself at the list of options for some components
:-) I imagine it also clutters up UIs for the sake of showing options only
a small number of people may ever use.
Cheers,
Jon
On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote:
> I’m working with the UI folks in Talend to enhance the tooling that we
> provide. Right now, we have various components with specific parameters
> exposed. This “kind of works”, but as new parameters are added in Camel we
> have to keep things up to date and such. We’re trying to switch to using
> the json stuff that is generated at build time (great stuff, BTW) so that
> all the parameters that are available is presented to the users.
> Currently, there are labels for “consumer” and “producer” and anything not
> labelled one of those is common between the two. That’s a great start.
> However, while testing with some users, we’ve run into a usability
> problem: some of the components have soooooo many parameters, many of
> which would rarely ever be used, that trying to find the useful stuff that
> they care about is harder than it should be. For example, take a look at
> the file component:
>
> http://camel.apache.org/file2.html
>
> There are 7 “common” options, but for the consumer, there are then an
> additional 51 options. It’s really too many to present in a single list
> and not have the user go “what?!?”.
>
>
> Would there be any objections to adding an “advanced” label to options
> that are generally not normally used by say 90% of the use cases? I know
> that determining whether something is “advanced” or not can start heading
> down the path of bike shedding and the whole “what’s advanced for one user
> isn’t for another” and all that, but I think we need to have something to
> help out with this. Another thought was an additional “advanced=true” or
> “userlevel=1” or similar attribute to denote this, but the label
> functionality is already there and it seems to be perfect for this.
>
> I did quick look to see how many options we have. I parsed/processed all
> the component json files (didn’t look at the models or data format) and
> there are over 10,000 options. It’s a huge task to go through each of
> them, but if we can agree on a path forward, we can start tackling some of
> the more used components and then see how that works. File, http, jetty,
> jms/sjms, etc… Longer term, this info could be used to provide more
> useful component pages for the docs, putting the more useful stuff at the
> top.
>
>
> Thoughts? Objections? Other ideas?
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen