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 Mon, 14 Sep 2015 08:38:12 GMT
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

Mime
View raw message