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
