Hi Peter, that all makes sense! I think I’m left with 2 1/2 questions :-)
- Would it be useful to have a page with a table of extensions, presumably arranged alphabetically? (this is what the current page title implies and doesn’t provide). — If so, would it be useful to have this list also in the nav (I I think you said people wouldn’t often use it, but if it’s collapsable and easy to do, it might still be worth it). - If we can enhance the main camel component etc pages to link to at least the quarkus extension containing them (when present), do the current tables in camel-quarkus listing the supported components etc and linking to the extension page containing them provide significant value or are they confusing? Thanks! David Jencks > On Jun 1, 2020, at 1:50 AM, Peter Palaga <ppal...@redhat.com> wrote: > > Hi David, inline... > > On 01/06/2020 06:55, David Jencks wrote: >> I’ve been studying the camel-quarkus website wondering about generating the >> table of extensions and I have some questions…. >> The page is named “list of extensions” but that’s not what it actually is. >> It has tables of components, data formats, and languages, with links to the >> extension they are in. I find this confusing. > > You are right, it is confusing. > >> What are users likely to find most useful? Are they likely to think of the >> components, data formats, and languages they need and want to know what >> extensions are needed to run in camel-quarkus? Or are they going to search >> directly for extensions? Or both? > > I pondered on that too and here is the result: > > * The structure on the Camel Quarkus side does not matter in most cases > because the extensions are mostly 1:1 to their respective Camel bits. > > * The extension pages need to exist because they are required as a target for > the "extension guide" link from https://code.quarkus.io/ So the question is > whether we need both or extension pages only. > > * Some extension pages contain Camel Quarkus specific config options, > limitations and/or other info that is relevant to all included Camel > components, languages and data formats. It is important that users see that > Camel Quarkus specific info. Esp. googling for "camel quarkus > <camel-bit-name>" should bring a page listing that Camel Quarkus specific > info. I cannot see a way how to deliver that info (without too much > repetition) within a structure defined by Camel concepts. > > * Based on the above, I think we should not impose the Camel structure on > Camel Quarkus. I think Camel structure should be kept in its original and > natural location, i.e. in the Camel Components reference area. At the same > time, we should try to enhance the components, language and data format pages > there to contain info on which platforms (SB, Karaf, WildFly, Quarkus) the > given bit is supported. Something like > > | This [ component | language | data format ] is supported on > | * http://link.to/the-given-spring-boot-starter-page[Spring Boot] > | * http://link.to/the-given-karaf-bundle-page[Karaf] > | * http://link.to/the-given-camel-quarkus-extension-page[Quarkus] > | ... > | Please refer to the above links for the given platform's specific > | information. > >> If it’s the former, I think having separate index pages for the types of >> “thing” would be a good idea, to match the main camel website. Then there’s >> the question of what you get to when you select a “thing”. The extension >> pages don’t seem to me to be a very good match for clicking on a “thing” in >> an extension. I think it would make more sense to show a wrapper around >> most of the main camel “thing” page, the wrapper indicating something about >> the extension that provides the “thing”. Leaving out the information not >> useful for camel-quarks would be a good idea too… I think this includes the >> “main” camel maven coordinates. > > I find this option cumbersome, thus -1 for me. > >> As part of this question, is Spring Boot relevant to camel-quarkus? > > No > >> On the other hand, if users are more likely to be looking for extensions >> directly, then actually having a table of extensions would be a good idea. >> The list of extensions could also show up in the nav as a collapsible level >> 2 list. > > Users rarely use navigation, they rather come via Google. What matters is > whether the page they were brought to contains the information they look for. > >> Furthermore, would it be good to have links from the main camel “thing” >> pages to the quarkus extension providing them? > > Definely +1 > > What do others think? > > Thanks, > > -- Peter >
