camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: "advanced" label for params?
Date Tue, 22 Sep 2015 13:35:27 GMT
On Tue, Sep 22, 2015 at 3:30 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
>> 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.
>

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 <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
>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: https://www.manning.com/books/ibsen2

Mime
View raw message