Skip to content

Conversation

@andy-stark-redis
Copy link
Contributor

@andy-stark-redis andy-stark-redis commented Nov 6, 2024

DOC-4543

There are some opportunities here to restructure the Develop/Connect section in general. All feedback is welcome!

@github-actions
Copy link
Contributor

github-actions bot commented Nov 6, 2024

Staging links:
https://redis.io/docs/staging/DOC-4543-split-client-pages/apis/
https://redis.io/docs/staging/DOC-4543-split-client-pages/commands/client-caching/
https://redis.io/docs/staging/DOC-4543-split-client-pages/commands/client-getredir/
https://redis.io/docs/staging/DOC-4543-split-client-pages/commands/client-tracking/
https://redis.io/docs/staging/DOC-4543-split-client-pages/commands/client-trackinginfo/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/client-side-caching
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/dotnet/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/dotnet/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/dotnet/queryjson
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/go/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/go/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/go/queryjson
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/jedis/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/jedis/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/jedis/produsage
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/lettuce/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/lettuce/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/lettuce/produsage
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/nodejs/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/nodejs/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/nodejs/produsage
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/om-clients/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/php/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/php/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/php/queryjson
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/pools-and-muxing
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/redis-py/
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/redis-py/connect
https://redis.io/docs/staging/DOC-4543-split-client-pages/develop/clients/redis-py/queryjson

@dwdougherty
Copy link
Collaborator

Hi @andy-stark-redis . I'm not wild about adding another click to get to connection information: Develop > Connect > Clients > C# > Connect (again) > ... . This kind of seems like a solution for a problem that doesn't exist.

@andy-stark-redis
Copy link
Contributor Author

Hi @andy-stark-redis . I'm not wild about adding another click to get to connection information: Develop > Connect > Clients > C# > Connect (again) > ... . This kind of seems like a solution for a problem that doesn't exist.

@dwdougherty Yeah, I completely agree. My plans for restructuring some of this content have been on hold for a while, but I think this would be a good opportunity to move the Clients section up a level (basically just remove the Connect level). I'll do the same with CLI, Insight, etc (are you OK if we have a folder called Tools for those?) Also, how do you feel about moving the Java and Python clients up a level? I'm thinking we could list the clients by name with the language in brackets (eg, "redis-py (Python)", "Jedis (Java)"). It would save a bit of "tunnelling" to get to the page you want.

@dwdougherty
Copy link
Collaborator

@dwdougherty Yeah, I completely agree. My plans for restructuring some of this content have been on hold for a while, but I think this would be a good opportunity to move the Clients section up a level (basically just remove the Connect level). I'll do the same with CLI, Insight, etc (are you OK if we have a folder called Tools for those?) Also, how do you feel about moving the Java and Python clients up a level? I'm thinking we could list the clients by name with the language in brackets (eg, "redis-py (Python)", "Jedis (Java)"). It would save a bit of "tunneling" to get to the page you want.

That sounds better. I'm okay with your Tools idea. I also think it would be better to relocate the Pooling/multiplexing and Client-side caching folders, as they're not clients per se. Are these topics that could live in embeds and then be linked into collapsible sections in each main client doc? Not sure. Need to give this a think or two.

@andy-stark-redis
Copy link
Contributor Author

That sounds better. I'm okay with your Tools idea. I also think it would be better to relocate the Pooling/multiplexing and Client-side caching folders, as they're not clients per se. Are these topics that could live in embeds and then be linked into collapsible sections in each main client doc? Not sure. Need to give this a think or two.

Another approach is to have TCEs for everything except the connection page (eg, we could do that with CSC, JSON search, etc, because the content is basically parallel across clients). The connection details could all live in the main client page, tbh - I was just seeing if breaking it out was worth trying.

@dwdougherty
Copy link
Collaborator

I don't hate it. 🤣 Coupla suggestions:

  1. Add "hideListLinks: true" to the primary index page. I don't think that list is necessary given the new structure, since all the but two of the referenced links are in the lists above.
  2. You will definitely need to add aliases to each moved page.
  3. It's kind of odd that we now have a Develop > Tools section and an entirely separate Libraries and tools section. Maybe we just have to live with that. 🤷🏻‍♂️

@andy-stark-redis
Copy link
Contributor Author

andy-stark-redis commented Nov 7, 2024

I don't hate it. 🤣 Coupla suggestions:

  1. Add "hideListLinks: true" to the primary index page. I don't think that list is necessary given the new structure, since all the but two of the referenced links are in the lists above.
  2. You will definitely need to add aliases to each moved page.
  3. It's kind of odd that we now have a Develop > Tools section and an entirely separate Libraries and tools section. Maybe we just have to live with that. 🤷🏻‍♂️

Glad you don't hate it :-)

  1. Done.
  2. Yeah, this is still quite experimental. I'll do the aliases and fix the broken links once we're happy with the basic plan.
  3. Agree. I've renamed Tools -> Client Tools, and then Clients -> Client APIs. Also, the little programmer emoji is from an idea Michelle had to indicate which pages had code examples. I don't know if this is the best approach or if it's really necessary (most of the pages have examples now) but I thought we should try it out.

@dwdougherty
Copy link
Collaborator

Glad you don't hate it :-)

  1. Done.
  2. Yeah, this is still quite experimental. I'll do the aliases and fix the broken links once we're happy with the basic plan.
  3. Agree. I've renamed Tools -> Client Tools, and then Clients -> Client APIs. Also, the little programmer emoji is from an idea Michelle had to indicate which pages had code examples. I don't know if this is the best approach or if it's really necessary (most of the pages have examples now) but I thought we should try it out.

I like this version (and I was kidding about the "don't hate" comment, just so that's clear), though I'm not sure about the emoji. Funny thing about that, there was an article in this month's Write the Docs newsletter about emoji use. The article mentioned that emoji use can cause accessibility issues, and that emoji, in general, can be interpreted differently in non-western cultures.

@andy-stark-redis
Copy link
Contributor Author

I like this version (and I was kidding about the "don't hate" comment, just so that's clear), though I'm not sure about the emoji. Funny thing about that, there was an article in this month's Write the Docs newsletter about emoji use. The article mentioned that emoji use can cause accessibility issues, and that emoji, in general, can be interpreted differently in non-western cultures.

Your "don't hate" comment didn't suck ;-) I just wondered if there's a short way to signal "code examples" neatly (I tried just adding "with code examples" to the link title, but I think it might be a bit intrusive). Maybe 💻 or something else more like an icon without a person in it?

@dwdougherty
Copy link
Collaborator

dwdougherty commented Nov 7, 2024

Your "don't hate" comment didn't suck ;-) 🤣 I just wondered if there's a short way to signal "code examples" neatly (I tried just adding "with code examples" to the link title, but I think it might be a bit intrusive). Maybe 💻 or something else more like an icon without a person in it?

Maybe. The team should weigh in.

Another thing to consider is how the emoji bit would work for command pages, the ones with code examples. Probably just an update to layouts/commands/list.html and a new front matter flag? UPDATE: it's just as easy as adding the emoji to the "title" front matter, except, it appears very tiny on the list page. I tried with this emoji: ⌨️

Copy link
Collaborator

@mich-elle-luna mich-elle-luna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, I think RedisVL in this structure looks like it is missing the connect and example pages, so that is something to think about. Also the two topics at the end of the list could possibly move so they aren't missed? But, these aren't blockers to the changes, IMO.

@andy-stark-redis
Copy link
Contributor Author

I think I've checked this quite thoroughly for broken links and other issues and I've added aliases to moved pages. Any thought or issues before I merge?

Copy link
Collaborator

@dwdougherty dwdougherty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one suggested fix and a question.

@andy-stark-redis
Copy link
Contributor Author

@dwdougherty Thanks for the review! Yeah, the rationale (-ish) for the ordering of clients is that they are basically in order of popularity with the exception of C#. This is probably one of the least popular clients but we are trying to get into Microsoft's good books, apparently, so Mirko is keen to promote it. We keep Python first because it is probably more popular than all the others combined, so people would expect to find it quickly.

@andy-stark-redis andy-stark-redis merged commit c6e2186 into main Nov 12, 2024
5 checks passed
@andy-stark-redis andy-stark-redis deleted the DOC-4543-split-client-pages branch November 12, 2024 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants