You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Peter Palaga <pp...@redhat.com> on 2020/08/17 22:22:43 UTC
Re: [camel-quarkus website] Some questions about organization
I implemented some of the ideas discussed in this thread in
https://github.com/apache/camel-quarkus/pull/1534
In particular, the above PR lets the List of extensions page show an
alphabetically sorted list of extensions instead of using Camel concepts
(components, languages, ...)
The lists of supported components, languages, data formats, etc. are
still there but were moved to new dedicated pages. We can revisit the
question whether we need these pages once we have links from Camel
component pages to Camel Quarkus extension pages.
Thanks,
-- Peter
On 02/06/2020 15:07, Peter Palaga wrote:
> On 01/06/2020 19:22, David Jencks wrote:
>> 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).
>
> +1 from my side
>
>> — 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).
>
> +1
>
>> - 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?
>
> For reasons I mentioned earlier in this thread, my preference is to
> change the existing
> https://camel.apache.org/camel-quarkus/latest/list-of-camel-quarkus-extensions.html
> to contain a table of extensions (like you mentioned above) instead of
> the split into the Camel categories.
> But I am still open to hear reasons why we should do something else
> rather than this.
>
> Thanks,
>
> -- P
>
>> Thanks!
>> David Jencks
>>
>>> On Jun 1, 2020, at 1:50 AM, Peter Palaga <pp...@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
>>>
>>
>
Re: [camel-quarkus website] Some questions about organization
Posted by Peter Palaga <pp...@redhat.com>.
The changes are online now:
https://camel.apache.org/camel-quarkus/latest/reference/index.html -- P
On 18/08/2020 00:22, Peter Palaga wrote:
> I implemented some of the ideas discussed in this thread in
> https://github.com/apache/camel-quarkus/pull/1534
>
> In particular, the above PR lets the List of extensions page show an
> alphabetically sorted list of extensions instead of using Camel concepts
> (components, languages, ...)
>
> The lists of supported components, languages, data formats, etc. are
> still there but were moved to new dedicated pages. We can revisit the
> question whether we need these pages once we have links from Camel
> component pages to Camel Quarkus extension pages.
>
> Thanks,
>
> -- Peter
>
>
> On 02/06/2020 15:07, Peter Palaga wrote:
>> On 01/06/2020 19:22, David Jencks wrote:
>>> 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).
>>
>> +1 from my side
>>
>>> — 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).
>>
>> +1
>>
>>> - 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?
>>
>> For reasons I mentioned earlier in this thread, my preference is to
>> change the existing
>> https://camel.apache.org/camel-quarkus/latest/list-of-camel-quarkus-extensions.html
>> to contain a table of extensions (like you mentioned above) instead of
>> the split into the Camel categories.
>> But I am still open to hear reasons why we should do something else
>> rather than this.
>>
>> Thanks,
>>
>> -- P
>>
>>> Thanks!
>>> David Jencks
>>>
>>>> On Jun 1, 2020, at 1:50 AM, Peter Palaga <pp...@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
>>>>
>>>
>>
>