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