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
