-
Notifications
You must be signed in to change notification settings - Fork 45
Introduction & Quickstart Page Styling #457
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
base: main
Are you sure you want to change the base?
Introduction & Quickstart Page Styling #457
Conversation
Caution Review failedFailed to post review comments. Configuration used: CodeRabbit UI ⛔ Files ignored due to path filters (7)
📒 Files selected for processing (27)
💤 Files with no reviewable changes (1)
🧰 Additional context used🧠 Learnings (4)📓 Common learnings
src/css/custom.css (3)
docs/overview/introduction.mdx (4)
docs/getting-started/quickstart.mdx (1)
🧬 Code Graph Analysis (1)src/components/PlatformCard/PlatformCard.tsx (1)
🪛 LanguageTooldocs/overview/introduction.mdx[style] ~131-~131: Consider removing “of” to be more concise (ALL_OF_THE) docs/getting-started/quickstart.mdx[style] ~136-~136: Consider using a different verb to strengthen your wording. (SHOW_INDICATE) 🪛 Biome (1.9.4)src/components/DarkCodeBlock/DarkCodeBlock.tsx[error] 125-125: Useless case clause. because the default clause is present: Unsafe fix: Remove the useless case. (lint/complexity/noUselessSwitchCase) [error] 126-126: Useless case clause. because the default clause is present: Unsafe fix: Remove the useless case. (lint/complexity/noUselessSwitchCase) [error] 127-127: Useless case clause. because the default clause is present: Unsafe fix: Remove the useless case. (lint/complexity/noUselessSwitchCase) [error] 135-135: Avoid passing content using the dangerouslySetInnerHTML prop. Setting content using code can expose users to cross-site scripting (XSS) attacks (lint/security/noDangerouslySetInnerHtml) 🔇 Additional comments (17)
WalkthroughThis update introduces several new React components and CSS modules to enhance documentation presentation, including custom-styled lists, info boxes, chat bubbles, code blocks, notes, and platform grids/cards. The Quickstart guide is rewritten using these components. The introduction page is refactored for improved structure, and syntax highlighting themes are unified. Custom CSS variables and responsive styles are added. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant DocsSite
participant ReactComponents
User->>DocsSite: Navigates to Quickstart or Introduction
DocsSite->>ReactComponents: Renders ListItems, InfoBox, ChatBubble, etc.
ReactComponents-->>User: Displays interactive, styled documentation
User->>DocsSite: Interacts (e.g., copies code, reads notes)
DocsSite->>ReactComponents: Handles UI feedback (e.g., "Copied!" state)
Poem
Impact AnalysisImproved Quickstart Tutorial with Enhanced Formatting and Interactivity📢 Medium 🔄 Impacts behavior The Quickstart guide for CodeRabbit has been replaced with a new, more interactive tutorial that uses custom components for clearer formatting, step-by-step instructions, and richer examples. Users will experience a more visually engaging and easier-to-follow onboarding process, including formatted lists, chat bubbles for example conversations, code blocks with syntax highlighting and copy functionality, and highlighted information boxes. Test the Quickstart guide end-to-end as a new user, verifying that all steps are clear and actionable. Check that all custom components display and function as intended across devices and themes, and that users can easily follow the integration and review workflows. 🔍 Related Files
Enhanced Introduction Page with Visual Components and Improved Layoutℹ️ Low 🔄 Impacts behavior The introduction page now uses custom React components for lists, platform grids, and info boxes, resulting in a more visually appealing and organized presentation of CodeRabbit's features, supported platforms, and informational content. Users will notice improved readability and a more modern look and feel. Verify the introduction page on different devices and themes, ensuring all lists, grids, and info boxes display correctly and are accessible. Confirm that navigation and links function as expected. 🔍 Related Files
Unified Syntax Highlighting Theme for Code Blocksℹ️ Low 🔄 Impacts behavior The syntax highlighting theme for code blocks in the documentation site has been changed to "nightOwl" for both light and dark modes, providing a consistent and modern appearance for code samples regardless of the selected theme. Check code blocks in various documentation pages under both light and dark themes to confirm correct syntax highlighting and visual consistency. 🔍 Related Files
Improved Documentation Styling and Mobile Layout Adjustmentsℹ️ Low 🔄 Impacts behavior Custom CSS variables and new styles have been introduced for documentation elements such as lists, notes, code blocks, and buttons, resulting in a more cohesive and visually appealing user experience. Mobile layout and spacing have also been improved for better readability on smaller screens. Test documentation pages on various devices and screen sizes, verifying that all styled elements render correctly and that mobile usability is improved. 🔍 Related Files
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Hi folks,
Thanks for this work. While I appreciate the design improvements already merged with #432 and the goals laid out with #438, I have some reservations about the changes proposed here.
The significant modifications to the pages' source—and the implied changes that they would require to all existing and future documentation—make me feel concerned about the trade-offs involved. I expect that we can find other paths to meeting the design goals of #438, ones that involve a much lighter touch to our source files.
Added source complexity
First and foremost, I see that this PR replaces some Markdown source files with MDX files, which allow React code to be added directly to the page source. While this does bring a lot of potential flexibility to the documentation source, it carries a significant cost in maintainability by weakening the separation between content and presentation.
Unnecessary change of source file types
The codebase already does support calling out to React-based components as needed, by way of the mdx-code-block
directive. That, I think, obviates the need to recast entire Markdown source files to MDX.
Increased developer friction and maintainability costs
Currently, writers need only know Markdown to improve or author product documentation. This change proposes to instead require that writers learn a Markdown/React/HTML hybrid, including components that are unique to this documentation set. This would add a lot of friction to future documentation maintenance, to say nothing of development.
We'd also have to separately document and maintain these new React components, indefinitely.
Decreased content/presentation separation
In particular, I question adding new React components for common documentation elements like lists, notes, and code blocks, all of which are already well-supported by basic Docusaurus-flavored Markdown, and all of which can be styled through CSS.
What does adding a new <ListItems>
component give us, which using ordinary CSS to style <ul>
elements can't do?
Added visual complexity
I'd like to know more about the motivation to place various types of content—such as lists and cross-references—inside of colored boxes, rather than allowing them to exist as body text.
This includes the proposal to turn lists of Git platforms into two-dimensional matrices, implying that the position of the elements in different rows and columns carries some sort of special meaning, even though there is only one dimension of data.
Research shows that readers tend to skip over "callout" boxes when they're mixed in with body text. These elements are best used sparingly, for either warning labels that are supported by adjacent body text, or for asides that contain interesting but skippable notes.
My concern is that by transforming a lot of naturally body-text elements into colored banners, you'd actually be making the page significantly harder to read and navigate.
Book versus brochure
I suspect that we might have different audiences in mind for this material? A lot of these design elements strike me as more appropriate to "pre-sale" product-marketing pages or blog posts, and not developer documentation.
The readers of these docs don't need their attention grabbed by stacks of info-boxes, or comforted by the presence of familiar brand logos. Instead, they're visiting these pages with the goal of completing a task, and in all likelihood have arrived here with focused intent. The less visual and cognitive friction we present these readers with, the better.
That is, the docs should look more like a book than a brochure.
My request
Here's what I'd like to see next for this PR:
-
Leave the pages as Markdown files.
-
Don't introduce React replacements for elements that Docusaurus Markdown already supports.
-
As much as possible, restyle elements with CSS alone. If you can't use CSS alone and really must introduce new react components, use
mdx-code-block
sections, exactly as these docs already do. -
Let body text be body text. Don't introduce boxes, banners or other breaks to the flow of reading. Authors can carefully insert flow-breaking elements when they need to, sparingly, through Docusaurus admonitions markup and other techniques.
🎨 Enhanced UI/UX: Quickstart & Introduction Page Styling
📋 Overview
This PR introduces styling improvements to the quick start and introduction pages, enhancing readability and visual appeal with new reusable components.
🔗 Related Issues
✨ Key Changes
🎨 Enhanced Quickstart Page Styling
📖 Improved Introduction Page Design
🧩 New Reusable Components
🎨 Visual Improvements
📱 Better User Experience
Screenshots