[EUI+] Move all Elastic Charts docs from the Components tab to the Data visualization
#8182
Conversation
…sualization` tab + remove unnecessary badge with charts version (handle that holistically if we're going to add it back in) + sidebar and copy tweaks
cee-chen
added
documentation
|
It's great that we're moving the components to the Data Visualization page, especially since it already existed. It's much cleaner and it improves discoverability 👍🏻 One thing I have a doubt about is, if the library is separate to EUI, why not make separate documentation altogether? Asking out of curiosity and to prompt a discussion, not to block this PR. |
Not sure what that historical context was honestly, you might have to ask the @elastic/elastic-charts team. I believe the impetus was originally that Elastic Charts didn't have its own documentation, so they threw it into EUI's way back when. But either way EUI+ is meant to document not just our components, but various aspects of design systems including best practices and patterns, so charts/data viz falls generally under that purview, especially when one of Kibana's main goals is data visualization. |
There was a problem hiding this comment.
But either way EUI+ is meant to document not just our components, but various aspects of design systems including best practices and patterns, so charts/data viz falls generally under that purview, especially when Kibana's main goals is data visualization.
True BUT best practices and UX patterns (along with components) still fall under the ownership of the EUI team. The moment we blur the lines of the ownership (like seemingly making charts a part of the EUI), we introduce ambiguity to the process. Now, if the charts become updated - who updates the docs? Us, the charts team? Who can answer questions about the charts? Us (the owners of the EUI docs) or the charts team?
It's not a big deal, just something to think about as team. Thanks for shedding a light on this and ofc no need to answer ☝🏻 I was just thinking out loud. I'll mention this again on some meeting of ours.
… visualization + fix version to be dynamic with package.json instead of incorrectly static
|
Those are amazing questions Weronika. I believe the impetus for EUI+ and moving to MDX was to make it easier for a lot more folks to contribute to documentation so it didn't necessarily all fall on us. That being said, I definitely agree that it living in our repo tends to make people expect us to maintain it. @tkajtoch and Jason/Kyriakos can probably speak to that more. |
|
I'll leave this PR up for another day for comments and then go ahead and merge it in. We can also continue to open up follow-up changes after it merges! |
|
Preview staging links for this PR:
|
💚 Build Succeeded
History
|
|
No one else commented, so I'm moving ahead with this PR. As mentioned above, we can always continue to make more updates in the future. |
|
Here's some additional context to this conversation. Our initial goal was to create a comprehensive resource for all design system-related topics at Elastic. We chose the term "EUI+" as an overarching umbrella label for all experience-related elements. Given the importance of visualizations in our product and their closer alignment with the color palette, it makes sense to consolidate our guidelines and patterns. However, I don't recall discussing whether this decision would affect the ownership expectations for charts library docs. @JasonStoltz / @tkajtoch, do you have any concerns about this? |
Summary
This PR moves our charts documentation that was previously in
Componentsto the top-levelData visualizationsection, and reorganizes several sections to make more sense with the new page guideline intros.It also opinionatedly renames the URL slug of
/data-viz/to/charts/(to match the team/repo name?), although I'm very open to feedback on that.QA
General checklist
N/A, docs only