Moving both Tab/Tabs and Accordion to Layout sounds good 👍 Many systems classify Tabs as navigation, but that's theoretically incorrect. I guess the upcoming Stepper and Pagination components would then belong into Layout rather than Navigation too.

Just for visibility, Anne and I are also having a parallel conversation regarding Dialog here.

I'm having a hard time with most grouping in other Design Systems, particularly when the doc site doesn't feature a fuzzy search. It's nearly everywhere finding yourself in some other person's/group's definition that you need to invest time to learn and orient. There are too often differences (already starting at the component's names, see my favorite example tags, that is here represented as chips) and no real standards across the globe.

One vocal example in the current list would be SearchInput. I stopped skimming the groups and immediately went into “Inputs and Controls” to search for it. Just to have to search further to discover a separate “Search” group.
Also, to come from a general usability rule of thumb, don't group if there are only two members.

I'd put forward another proposal: Let's not group the components (as long as we're not providing search).

I'd put forward another proposal: Let's not group the components (as long as we're not providing search).

Fair enough. I find the functional grouping really strong and sensible, but at the same time I wouldn't like us to provide a classification that keeps raising concerns and feeling arbitrary to any degree. I would encourage us to keep exploring grouping options internally but, if you all concur, we could delay this decision until search is available (strongly agreeing with that point). Pinging @Sgs for visibility.

Change 831151 abandoned by Anne Tomasevich:

[design/codex@main] [WIP] Add component groups

Reason:

https://gerrit.wikimedia.org/r/831151

Sending to the backlog again until we turn to overhauling the doc site as an explicit focus.

Coming back to the conversations about this task, I agree on redesigning the Codex left menu to group some components. However, I propose the following organization:

• Actions: Button, ButtonGroup, ToggleButton, ToggleButtonGroup
• Containers: Accordion, Card, Module
• Info indicators: Badge, InfoChip
• Overlays: Dialog, Popup, Tooltip, Sheet
• Feedback: Message, ToastNotification
• Progress/Loading: ProgressIndicator, ProgressBar, Skeleton
• Input: Checkbox, ChipInput, Combobox, Field, FileInput, Label, Lookup, MultiselectLookup, Radio, Select, TextArea, TextInput, ToggleSwitch
• Media: Icon, Image, Thumbnail
• Navigation: Link, Tab, Tabs
• Search: SearchInput, TypeaheadSearch

Change #1100469 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] docs: Add component groups in the sidebar

https://gerrit.wikimedia.org/r/1100469

@bmartinezcalvo (we're not technically working on this as part of this sprint but I figured I'd get a head start)

I've pushed a patch with a proposal that merges your recent comment and the original groups that Sarai and I developed. I aimed to minimize the number of groups and avoid any groups with a single item (since we haven't built all of these components yet). It was also important to Sarai and I that we try to group things by purpose and not aesthetics, which is why we avoided things like "overlays" (we could have a "layout" section in the future that has things like module, sheet, container, divider, etc)

El T309109#10380079, @AnneT escribió:

@bmartinezcalvo (we're not technically working on this as part of this sprint but I figured I'd get a head start)

I've pushed a patch with a proposal that merges your recent comment and the original groups that Sarai and I developed. I aimed to minimize the number of groups and avoid any groups with a single item (since we haven't built all of these components yet). It was also important to Sarai and I that we try to group things by purpose and not aesthetics, which is why we avoided things like "overlays" (we could have a "layout" section in the future that has things like module, sheet, container, divider, etc)

Thank you for working on this @AnneT. After reviewing the patch, this is my feedback:

1. I would create a separate section for "Progress" to include there all the components related with that (ProgressBar, ProgressIndicator, Skeleton)
2. Since the Infochip provides different status feedback (notice, success, warning, error) I would move it under the "Feedback" section.
3. I'm not sure if Dialog should be part of "Feedback" since sometimes a Dialog is just informative or includes steps and actions (like a Process or an Onboarding Dialog). I wonder if Dialog should be moved to "Data & content display" instead.
4. I would separate "Inputs" and "Controls" into different sections. | patch ]], this is my feedback:

1. I would create a separate section for "Progress" to include there all the components related to that (ProgressBar, ProgressIndicator, Skeleton)
2. Since the Infochip provides different status feedback (notice, success, warning, error) I would move it under the "Feedback" section.
3. I'm not sure if Dialog should be part of "Feedback" since sometimes a Dialog is just informative or includes steps and actions (like a Process or an Onboarding Dialog). I wonder if Dialog should be moved to "Data & content display" instead.
4. I would separate "Inputs" and "Controls" into different sections.

@bmartinezcalvo thanks for the feedback! I've done items 1-3. For inputs and controls, it's really hard to separate them - for instance, ToggleSwitch could be a control on a page, or an item in a form. It's technically an input, having a checkbox input under the hood, but it feels more like a control.

@AnneT after reviewing the patch one more time, I have some more feedback to share:

• I wonder if we could name the "Actions" section just "Buttons" and move the MenuButton there. I feel a bit confusing having just this MenuButton separated from the rest of buttons.
• I feel that the "Data & content display" section is not the best for Menu and MenuItem since they always display predefined options or actions. I wonder if they should be moved to their own "Menus" (or other name) section.

Copying @Volker_E's feedback from gerrit:

I would like to love the categories, but I get confused with some of them.
First and foremost, we should come up wit a different hierarchy styling, Having Components looking the same like the category groups underneath does not work in my opinion.
On confusing categories:

1. Having buttons in an overarching 'Actions' category, but then Links really far down together with Tabs is hard to wire up. Myself being a prayer for a stricter distinction of Links and > Buttons, would still like to see them close together.
2. 'Data & content display' – everything is a display, Would tend to remove 'display' here to stay in similar category max length across
3. 'Progress' – wouldn't it make more sense to put this into 'Feedback', even with ProgressIndicator on the horizon? I'm not fully convinced about 'Feedback' as term, but have no better idea atm

Generally I'm fine with 'Data & content', 'Feedback', 'Input & controls', 'Search'. I like 'Media'.

In T309109#10410263, @bmartinezcalvo wrote:

• I wonder if we could name the "Actions" section just "Buttons" and move the MenuButton there. I feel a bit confusing having just this MenuButton separated from the rest of buttons.

This makes sense to me and seems very clear; I'll make the update!

• I feel that the "Data & content display" section is not the best for Menu and MenuItem since they always display predefined options or actions. I wonder if they should be moved to their own "Menus" (or other name) section.

I'm hesitant about this because "Menus" sounds like it should either contain navigation menus, or all menu components. Also, most people won't be looking at the Menu or MenuItem page own their own - instead, they'll be looking at a menu component page and clicking through to the Menu or MenuItem page. These components, plus Tab, are really difficult to place in the groups/hierarchy. Right now, Menu and MenuItem seem most like data display components to me, so I'd recommend we leave them there until we think of something better.

Copying @Volker_E's feedback from gerrit:
First and foremost, we should come up wit a different hierarchy styling, Having Components looking the same like the category groups underneath does not work in my opinion.

@Volker_E do you think the group titles should be larger, have different text styles, etc.?

On confusing categories:

1. Having buttons in an overarching 'Actions' category, but then Links really far down together with Tabs is hard to wire up. Myself being a prayer for a stricter distinction of Links and > Buttons, would still like to see them close together.

Can you explain why you think buttons and links should be included in the same group? What should the group be?

2. 'Data & content display' – everything is a display, Would tend to remove 'display' here to stay in similar category max length across

That makes sense; I'll remove "display".

3. 'Progress' – wouldn't it make more sense to put this into 'Feedback', even with ProgressIndicator on the horizon? I'm not fully convinced about 'Feedback' as term, but have no better idea atm

I originally had it this way, but @bmartinezcalvo requested a separate Progress section, especially given that we'll eventually include Skeleton. Can you two please work out what we should do here so we can move forward?

Change #1105082 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [proof of concept] Nest and collapse component groups

https://gerrit.wikimedia.org/r/1105082

El T309109#10410723, @AnneT escribió:

3. 'Progress' – wouldn't it make more sense to put this into 'Feedback', even with ProgressIndicator on the horizon? I'm not fully convinced about 'Feedback' as term, but have no better idea atm

I originally had it this way, but @bmartinezcalvo requested a separate Progress section, especially given that we'll eventually include Skeleton. Can you two please work out what we should do here so we can move forward?

@Volker_E @AnneT the "Progress" section now seems odd since we only have one component included there for now (ProgressBar). But, keeping in mind that we will include soon a ProgressIndicator and Skeleton, I would keep this section separated from the "Feedback" one for the following reasons:

• I would keep the "Feedback" section for those components providing statuses (notice, success, error, warning)
• I would keep the "Progress" section for those components used for loading state (we could also name this section "Loading" for clarity)
• I would keep the sections in this new navigation with less number of components for better findability.

Change #1105413 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [proof of concept] Un-group some items

https://gerrit.wikimedia.org/r/1105413

My only stylistic feedback is the text style of the group heading is the same as a page, except the page is actually a page you can go to and group headings are elements you can expand and collapse, and the only visually difference is the arrow implying expanding/collapsing. Maybe we could style the group headings similarly to how "Components" is styled at the top (housing Overview and Types and constants). Then the only differentiator from that is the arrow, since these can be expanded/collapsed. So stylistically the group heading is more similar to a page heading in the sidebar, not to a page, which I think functionally makes more sense. It looks like this is the style that the original demo is/was.

@bmartinezcalvo @DTorsani-WMF @egardner @lwatson @Volker_E Here's the proof-of-concept that groups some items but not all. Please let me know what you think here in the task (not on the patch)!

Thanks for putting this together so quickly. I don't mind the singular pages among other groups, but something about all the groups being opened by default in this scenario feels odd to me. Like the singular pages get lost. I'm also not sure how my idea from the comment before looks in this scenario (see attached with the group headings being bold).

Thanks Anne! When there are some groups and some standalone components, it might be better to have the accordions closed initially. I prefer the proof of concept shown in Design Sync which had all the components in a group.

paging @Catrope, who in gerrit mentioned not liking having groups collapsed initially

I also feel like there's something about the latest demo that is difficult to scan. I've updated it to include bolded headings for collapsible group titles as @DTorsani-WMF suggested.

I also generally concur with @lwatson - thus far, I think it makes the most sense to have everything in a group. However, if we're able to get the visual hierarchy right for the mixture of grouped and ungrouped items, I might feel differently.

@AnneT yes, fixing the hierarchy would change my mind.

Closing the partially grouped components doesn't solve anything. The mix of group items and non-group items in the sidebar is confusing and hard to read.
For now, I lean towards putting every component in a group. We can always update the group names and grouping later. The option to do nothing here seems ruled out because our component list is long.

@AnneT thank you for working on this. After reviewing both versions, I agree with the comments above. I find this new version with just some items grouped to be visually crowded and more difficult to navigate. I think the previous proposal, where all components were visible in different groups, works much better for both findability and visual structure.

Thanks all - I've updated this demo to have:

• All items grouped
• All groups expanded by default
• Bold labels for the groups
• Fewer groups (removed "progress" and moved its items to "feedback")

I've presented both patch1 with no accordions and patch2 using accordions during the Design Review with some designers to collect more feedback, and this is what they shared:

• The version with no accordions (patch1) generally feels more intuitive for them. But they feel the scroll in this components list could be too long.
• The version with accordions (patch2) could be useful for managing longer lists and reducing scrolling, but some found it to be bulkier and less visually appealing. They commented about removing the left line for the nested components in the Accordion.
• They commented on different ways of grouping these components. So in case we can spend a bit more time on this, it would be great to conduct an exercise with designers or other team members to see which is the best organization for all of us.
• We are organizing these groups by alphabetic order, but would it be possible to organize them differently? e.g. including the Inputs/Forms under Buttons.

So my recommendation is to test both versions if possible and try to conduct a card-shorting exercise with more users to help us validating the most intuitive grouping, given that we have different organization approaches.

Regarding the proposal using accordion, I've been exploring how to make these groups within accordions more visually balanced:

• Include a bit more separation between each component's group
• Remove the left line from the expanded components in each group, and align them with the group's title
• Use @color-subtle bold for the group's titles, so they are differentiated from the "Components" title on top of this menu
• If we could include 2px more padding on each item in this left menu in Codex to visually separate them better it would be great

Another observation is that if we want to use this grouping with accordions, we should revisit the rest of the sections of the Codex site (Using Codex, Contributing, and Style Guide) to unify them with this new navigation approach.

@bmartinezcalvo That already feels much more balanced indeed. 👍🏼

I also like the design proposal from Bárbara.

Change #1105082 abandoned by Anne Tomasevich:

[design/codex@main] [proof of concept] Nest and collapse component groups

Reason:

changes incorporated into parent patch

https://gerrit.wikimedia.org/r/1105082

Change #1105413 abandoned by Anne Tomasevich:

[design/codex@main] [proof of concept] Un-group some items

Reason:

we hate this

https://gerrit.wikimedia.org/r/1105413

Thanks all, and especially @bmartinezcalvo for the feedback and design suggestions! I've implemented them in this patch (see demo), and reordered the groups as Bárbara suggested (they don't need to be in alphabetical order).

I'd like to finalize this initial version of the groups this week if possible. To that end, I'd appreciate feedback on the following:

1. Are there any further adjustments to the styles needed? I did my best to match Bárbara's design but may have missed something.
2. Do we agree on having all groups expanded by default? This seems to be the best compromise as it ensures components are not hidden but groups can be collapsed as needed.
3. Is anything absolutely wrong with the component groupings, or can we move forward with the current groups and make adjustments in the future if needed? I'd like to move away from making marginal improvements to the group, and just focus on anything that is completely incorrect or problematic.

I think this is fine to move forward.

In the future, I think we should explore trying to get all components into a group, and having all groups except whatever group the current page belongs in (if any) collapsed by default. Otherwise it feels very busy over there.

But all this can be incrementally adjusted from here IMO.

My understanding with the design proposal was that all items should be grouped. It also looks like the design proposal removes the vertical line and does not indent the items within a group. I'm also in favor of Eric's suggestion of collapsing groups by default.

Thanks to the newly implemented search I'm a bit less concerned about the groups being collapsed by default. It might be a better compromise right now and we should watch users' feedback closely if this is making their lives unnecessary more complex.

Thanks for working on the initial phase! I agree with #2 expanding the groups by default and in regards to #3 we can move forward and make improvements if needed.

Thank you for working on this @AnneT. Responding to your questions:

1. Regarding styles, in my proposal I suggested removing the left line from the expanded components in each group, and removing the indentation so they were aligned with the group's title. I also suggested adding a bit more padding between each sidebar item (from 4px to 6px) so they appear to be less visually condensed.
2. I agree with Eric on collapsing all groups by default.
3. I'm not sure about the "Layout" group, so I would suggest removing that group and create a "Tabs" one for Tab and Tabs. I would also group the Menu and MenuItem under a "Menus" group.

Hi all, I'm so sorry but I linked to the wrong demo in my previous comment. This is the most up-to-date demo - please take a look (especially @bmartinezcalvo since I've implemented your design comments there!)

Ah, thanks Anne! I thought maybe I was looking at something out of date. This looks good to me. In my experience, the first thing I want to do is close all the groups. I'm still in support of closing all of those by default. I'm okay with the categorization now, especially since we have search implemented.

@AnneT thank you, this looks good now. I also prefer to have all groups collapsed by default. Regarding the groups, we could move forward with this version for now and then test this later in case we can group them differently.

A future consideration is adding group dividers which are used in Vitepress. Sorry if this was already discussed.

Also, I found this comment explaining the reason to abandon the "un-group some items" patch hilarious

Reason:
we hate this

Thanks everyone for weighing in! It sounds like we're all on board with the design and the groups. I've updated my patch to collapse the groups by default since most people prefer that. We can always update these things in the future based on user feedback. I'll ask the engineers for final code review.

In T309109#10442493, @lwatson wrote:

Also, I found this comment explaining the reason to abandon the "un-group some items" patch hilarious

Reason:
we hate this

It's fun to be dramatic sometimes haha

Change #1100469 merged by jenkins-bot:

[design/codex@main] docs: Add component groups in the sidebar

https://gerrit.wikimedia.org/r/1100469

Change #1113883 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from 1.19.0 to 1.20.0

https://gerrit.wikimedia.org/r/1113883

Change #1113883 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from 1.19.0 to 1.20.0

https://gerrit.wikimedia.org/r/1113883