- 
                Notifications
    
You must be signed in to change notification settings  - Fork 270
 
DOC-4543 split client pages into subpages #853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 
           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.  | 
    
          
 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.  | 
    
| 
           I don't hate it. 🤣 Coupla suggestions: 
  | 
    
          
 Glad you don't hate it :-) 
  | 
    
          
 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?  | 
    
          
 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: ⌨️  | 
    
There was a problem hiding this 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.
| 
           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?  | 
    
There was a problem hiding this 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.
Co-authored-by: David Dougherty <[email protected]>
| 
           @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.  | 
    
DOC-4543
There are some opportunities here to restructure the Develop/Connect section in general. All feedback is welcome!