camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: "advanced" label for params?
Date Tue, 22 Sep 2015 13:30:18 GMT

> On Sep 22, 2015, at 3:15 AM, Claus Ibsen <claus.ibsen@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 <claus.ibsen@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 <dkulp@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 <claus.ibsen@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 <janstey@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 <dkulp@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


Mime
View raw message