Idea: base an initial PoC proposal on the layout behavior of the child section navigator, maybe even including the border styling. Then show to design.

I've created a POC simple multi column component. I think the next step is to gather feedback from UX.
The component is visible here: https://docskit-pr-1316.commercetools.vercel.app/docs-smoke-test/components/multi-column-layout

Nice, thanks! I have no opinions about the border or box but I think given that the font size is body content (as opposed to the child section nav which has a smaller font) two columns would be better readable overall.
Would then be one column in the mobile viewport.

Hey, please do not go for this approach.
@gabriele-ct thank you for all the effort too build this.

• even though there is a long list, nowadays the user is not "afraid/tired" of scrolling
• a user scans to the content
• with the approach the contact is two crowded and heavy, there is no "break" for the eye
• a head map of user eye view is always strong on the left side and gets less to the right side
• with a long list we also add way more whitespace, is an ästhetic effect that gives the feeling of clean design but also saves the user from overloaded content.
  He can focus on what's important

Please keep the list as it is.
If there is a list that really takes 5 sec. to scroll then we need to log on a completely new approach.
for solving situations like this.

Hi @Shecki ,
thanks for your valuable input 👏 . I'll leave the draft PR open for now and we'll take a decision next week when @nkuehn is back 👍

I have no emotions on the topic, it was brought up by content authors and I just threw the idea of a column layout into discussion.

lets look for a different UI/UX solution

note from Nicola Molinari - saving it here for future reference:

_

I was looking at the Polaris docs today and noticed that they render the list of component props as one column (see first screenshot). I tried to apply that to our API data model docs, as we’re currently using 2 columns (see second screenshot as an example). As often times some of the fields or types have long names, it results in weird formatting of the names due to the 2 columns. With one column we might not have this issue in the first place and can better make use of the space. Anyway, just wanted to share that in case you might consider it as an improvement.

_

@zbalek thank you for tracking notes from slack in tickets so they don't get lost but I'm pretty sure this ticket is not the right place for the topic nicola brought up. The topic in the screenshots is about the specific layout of API specification components (which are autogenerated and have a very specific cotent structure) vs. this is about whether it's a good idea to allow authors to put arbitrary body content into a multi column layout..

closing the ticket as from the UX perspective I agree with the comment from @Shecki (Jun 17, 2022) as the list has not gotten longer since then and the arguments still apply to our current situation.