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
