ideas for restructuring SDK/Clients page

[LordGhostX]

Background

Waku comprises various SDKs/Clients (nwaku, js-waku, etc.), and it is crucial for the documentation to include comprehensive guides for each of them.

Challenge

I'm currently exploring optimal approaches to organizing the SDK/Clients documentation to ensure it is well-structured, intuitive, and enhances the overall user experience.

Proposed Solutions

Idea 1

• Introduce a navbar labeled "SDKs" that leads to a dedicated page containing cards similar to the format found at https://xmtp.org/sdks-and-tools.
• Each card can be a link to the respective documentation for each SDK.
• Remove the Waku Implementations page from the "Getting Started" section.
• Consider adding a new "How can I try it out?" section to the What is Waku page.

Idea 2

• Introduce a navbar labeled "SDKs" that provides a direct link to the Waku Implementations page from the "Getting Started" section.
• Consider redesigning the layout to adopt a card-style format similar to what can be seen at https://xmtp.org/sdks-and-tools.

Idea 3

• Include each SDK in the navbar, similar to the setup at https://docs.walletconnect.com/2.0/.
• Each section in the navbar can contain embedded documentation specific to the corresponding SDK.

Notes

• Idea 1 can be expanded to include cards for showcasing Waku examples, allowing for further scalability.
• Idea 2 is the most straightforward and expedient to implement.
• Idea 3 isn't "future proof". If Waku develops with 10 SDKs/Clients, we'll need 10 navbar items, cluttering everything and requiring restructuring.

cc: @hackyguru @fryorcraken @danisharora099

[LordGhostX]

Here's a revised idea combining elements from ideas 1 and 2:

• Create a navbar labeled "SDKs" that's a dropdown menu with links to the SDK's documentation.
• Leave the "Waku Implementations" page as it is.

[fryorcraken]

Card design is definitely more "sexy" than current implementation page. However I would not spend too much time on styling at this point in time. Depends how we can get a good layout.

I agree "3" is not optimal because we have a good number of SDKs:

• js-waku (browser)
• ReactJS components (React Native coming too)
• Waku React Native
• Waku Rust Binding
• Go-Waku
• Waku NodeJS Binding
• nwaku as a node
• nwaku as a nim library
• Kotlin (go-waku c-bindings)
• Swift (go-waku c-bindings)
• Unity/C/C#/C++

I would:

• have a navbar that is a dropdown menu
• try to improve laying of "Waku Implementations"
• Replace "implementation" and "Client" wording with "SDK" (and node for nwaku as a node).