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 <claus.ib...@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.ib...@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 <claus.ib...@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 <jans...@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 >>>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>>> Talend Community Coder - http://coders.talend.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Jon >>>>>> --------------- >>>>>> Red Hat, Inc. >>>>>> Email: jans...@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 >>>> dk...@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 > dk...@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
