> 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
