@Sarai-WMDE please feel free to edit the task description or add anything else that you think is important here!

@AnneT @Sarai-WMDE should we add Thumbnail in this list? Although we already have it in Codex I'm not sure if it's a core component or not.

Apart from thumbnail I think a good candidate to be in the core component list would be the Image component (defining its sizes, aspect ratios and states). Do we plan to add Image as component?

@bmartinezcalvo good call! I think we may as well add Thumbnail since it already exists. I could see Image being useful (we had an Image component in structured data projects that also lazy-loaded the image once it came into the viewport), but we haven't discussed it as a team yet.

I think this list correctly reflects our known core components. Thank you, @AnneT!

I wonder what we should do about: 1. potential core components that we're not fully aligned on yet (e.g. Image – would be pro adding it to the list–, Accordion/Expand, Carousel, List, Pagination...) and 2. important patterns that will probably be developed as mixins (e.g. Divider, Label, Skeleton).

I'd personally add the latter to the list (with an indication of their actual nature). About the former (core component candidates), I would probably mention their existence, and link to the ticket where they are publicly listed: T277047 (I can update the table to reflect core/ core candidate components).

For potential components we're not aligned on, I would recommend leaving them off of the list of core components, which I see as components we are almost definitely going to build at some point. Really, the list might already be too long at this point :) Perhaps we can reference the design inventory table to indicate that we have a longer list of potential but not core components?

For important patters that we're likely to include, I think we should include them in the core list somehow since we have the same goal of informing consumers of Codex that these things will be available to them at some point—maybe as a separate list called core mixins or core patterns?

Perhaps we can reference the design inventory table to indicate that we have a longer list of potential but not core components?

Exactly! That's all I meant we should do.

Maybe as a separate list called core mixins or core patterns?

Sounds good! :)

I think an Image component is worth adding to the core list here.

We also may want to consider a Video component or multi-media component. Some prior art exists in MediaSearch for this.

These components could handle things like lazy-loading or loading indicators, fallbacks for broken links, responsive images, etc.

The epic T277047: Design inventory of Wikiverse (Codex design system, OOUI, MediaWiki widgets) UI components was updated to reflect the list of core and potentially core Codex components. For now, and until we reach some consensus, both Image and Media player components were documented as the latter.

I'm fine with adding those components in the core components list and also one more:

1. Image (single image component)
2. Image gallery (group of images). This could be specially useful for Wikimedia Commons)
3. Video player

Two questions from me for the design team (@Volker_E @bmartinezcalvo @Sarai-WMDE):

1. Is there anything I can link to for InfoChip?
2. What's the difference between Popup/Popover and Tooltip?

I would suggest that if a component is so important to the design system that it's a "core component", we (DST) should build it ourselves (or at least an initial version of it), rather than waiting for a team to need it and then have them work with us to build it. That suggests to me that we should trim this list a bit. I think we all agree that Button and Dialog are core components that it makes sense for DST to build, but what about DatePicker and FileInput for example? Or maybe we can split the list in tiers, and only commit to building components in the top tier ourselves?

In T313357#8176049, @AnneT wrote:

Two questions from me for the design team (@Volker_E @bmartinezcalvo @Sarai-WMDE):

1. Is there anything I can link to for InfoChip?

I had to read through all comments in T280681 to understand what's meant with “InfoChip”. A tag is exactly that widely used term for filtering and categorizing information. The separation here is interactive or just informative. Wonder if we need to provide both, I'd like to see them as one component. Altogether we should settle as team soon on one name and use it consistently, the tag/pill/chip bs – see also T280681#7720967 for weirdness in other design systems – is haunting me at night.

2. What's the difference between Popup/Popover and Tooltip?

Not sure if it is appropriate to separate them. A tooltip should not show interactive content, while a Popup could potentially contain such. The view logic should be the quite similar (with maybe show/hide and focusability differences).

TimeInput is currently missing here, or we rename DateInput to DateTimeInput to incorporate this functionality.

Dialogs come in so many different flavors, that I would rather see them split it up into sub-types similar to Buttons.
To compare with OOUI – message dialogs, simple dialogs, process dialogs.

@AnneT thank you for collecting all the core components list in the task. I've reviewed them and I'm commenting here some that are missing:

• Tag input: we have it in the OOUI Figma spec and in the OOUI demo
• Loader indicators (Spinners, Bouncing dots): should we include them as core components?

@bmartinezcalvo, in relation to your last comment:

Tag input: we have it in the OOUI Figma spec and in the OOUI demo

I think this would be ChipInput, based on the new terminology

Loader indicators (Spinners, Bouncing dots): should we include them as core components?

Those would be ProgressIndicator(s).

Regarding your questions, @AnneT :

1. Is there anything I can link to for InfoChip?

Not for now. I think there's only a generic task about adding the Chip component to Codex for now (T309249). We should create a specific task for InfoChip. If I'm not mistaken, this variant of Chip will be needed by Abstract Wikipedia.

2. What's the difference between Popup/Popover and Tooltip?

Popoup/Popovers (generally white boxes with pointers) can contain a greater amount of information and even media and actions. Tooltips (usually with a dark background) are smaller, generally only triggered on hover. They provide very short, clarifying information. I think the latter were defined recently in the context of Abstract Wikipedia. As noted in the original spreadsheet, these sound too much like the default browser tooltips, so we might need to clarify if we're talking about customizing those. Edit: This lack of definition might be a reason to document Tootltips as Potential core components instead?

Thanks, all! After reading through the comments, I'd like to make the following suggestions:

• We follow Roan's suggestion of thinking of core components as ones that would make sense for DST to build. That doesn't mean we have to build every one, but it's helpful to distinguish between components that have many use cases across projets and components with only one or two use cases/projects.
• We update DateInput to DateTimeInput as Volker suggested, but we consider removing it since it's pretty Wikidata-specific (it's also used on the structured data tab of filepages, but that's also Wikidata-specific)
• We consider removing any other components that seem more specific to a single project/use case. Diff would be another candidate for removal.

Also, based on conversation with Sarai, we may want to add Accordion (aka expand/collapse)

In T313357#8178725, @AnneT wrote:

• We consider removing InfoChip if it's specific to one project (if not, it can stay)

I wouldn't remove the InfoChip from the core components list since chips are being used in some projects and in each one of these design projects the chip is being designed differently since we don't have any guidelines defined for this component.

Function Page in AW	AW design project	Growth (also being discussed in T253706)

I would consider to include this component in the list since it's a component we need to define in depth.

@bmartinezcalvo sounds good, thanks for the info! I'll remove that suggestion.

The initial list of core components included in this ticket is based off of the design inventory of the Wikiverse performed by the product design team at WMF. We applied the following criteria to extract potential core components from said list:

1. Recurrent use in several of our projects (e.g. Message. This resulted in omissions such as that of 'Carousel'). In most cases, said components are already present in our existing UI libraries (OOUI, WVUI or WiKit) and require a migration.
2. Correspondence with HTML form and interactive elements (e.g. <button>, <dialog>, <input> with its different types, <select>, etc…)
3. Parity with popular, mature design systems. This is the least crucial or leading criterion, as we should always prioritize covering our particular use cases. Nevertheless, their existence in other libraries allowed justifying the introduction of certain detected components and patterns (e.g. skeleton loading) and can help us standardize some of our idiosyncratic elements. For reference, the following two resources provide an overview of common building block across external design systems: The component gallery, Open UI.

Based on this criteria (specially the first one), I would suggest a first update that removes ChipInput, Floating button and DatePicker (vs DateInput) from the list. Since the extension of their use case is unclear.

I think once we decide this, the list will be ready to be evaluated and adjusted with help from our collaborators. Hopefully, feedback will allow us to refine it in accordance to the first criterion.

In parallel to this, I believe that the DST should start defining how non-core components will be handled. These might be required, single-use Vue components that are project-specific (such as "Input with expander" in Wikidata/Wikibase). It'd be great to define an approach as to how these are related to our core components, a where will these be located.

Thanks for this helpful information, @Sarai-WMDE! I've also removed FloatingButton, ChipInput, and DatePicker from the list of core components based on your suggestion.

Reading the task description it seems (to me and maybe I’m reading wrong), the main characteristic of a component to be part of “core” is its certainty to be added to the library which is a derivative from how commonly it is used. The second characteristic would be that DST team will work on it or it will be prioritized in general.

From an outsider UI library consumer “core” resonates to “basic”, “blueprints”, “atoms” of a wider UI system which allow to build more complex components as opposite of when or who will implement the component. Mind that I'm not native-english speaker and this is just about nomenclature/naming.

I like better the "tiers" concept @Catrope suggested. Maybe scoring how atomic a component is (depends on other components or design tokens) and how critical to implement (other components depend on it, urgent, commonly used across MW software, product request) and based on the final score assign it to tier 1, 2..N. DST can focus on tier 1 then.

I like very much to see some sense of component groups/categories. I’d suggest to use a taxonomy focusing on “what” the component does (function, action, motion) rather on how it looks (shape). Some UI libraries that group components by function: Ant design, React Matrial UI (MUI), Chackra UI. For instance, messages (Message, ToastNotification) and progress groups would belong to the "Feedback" category whereas ValidationMessage belongs to the "Forms/Data Entry" category.

I really miss a Layout group/category with components like Grid, Container, Flex, Box, Stack, Wrap… which serves as a the scaffolding base components for higher level components enforcing some commons. For instance one could build a Card with a Box or more.

Maybe a Typography category for handling font commons, headings, etc. is worth considering (ie Chackra UI Text component ). Having Layout and Typography components using Codex design tokens could help to minimize the Don't rely on px unit based values problem.

tl;dr

suggestion: change naming of "core" to tiers (1,2...) based on component dependency tree and how critical it is.
suggestion: use functional category names and re-organize list
suggestion: create a Layout category for common scaffolding, composition and elements gutter
suggestion: create a Typography category for common text display
nit: Field and Label component seem strictly related to the category input & controls (Forms, data entry).
nit: Buttons could be under input & controls, they are a control afaiu

Hey @Sgs 👋🏻 I think your suggestions are really on point. I went ahead and tried to adjust our list using this spreadsheet to:

1. Drop the concept of "core" and instead categorize components by tiers (1, 2, 3). This is a first assessment (based on how atomic and essential the components are), and will need further polishing. Yours and DST's feedback here would be really welcome 🙏🏻

2. Use functional category names to group components: this is an excellent approach that brings a lot of order and meaning to the categorization. It prevents us from leaving any components ungrouped (see "Other core components").

3. Includes Label and Buttons under "Inputs & controls".

Regarding Typography and Layout (Grids): Our initial plan was to group such "foundational" elements under a global category that's separate from components. This category could be named something like "Global styles" or "Visual foundations". I think that separation makes a lot of sense when it comes to typographic styles and grids, but I do agree that documenting reusable "utils" such as box* under such "Layout" category makes a lot of sense. I included said category in the list. (But left Typography out in this first iteration).

*Box/frame only exists as a design concept for now. I'll need to align with the rest of the team to decide if we want to reuse and document such agnostic building blocks.

Thanks again for the great input!

Huge +1 to the functional group names, this is a major improvement toward our goal of using groups to make components easier to find and mentally map.

The atomic design tiers are helpful to us in terms of defining Codex's architecture, but I think the main goal of this task could still be served by naming the set of components we intend to prioritize because they have multiple use cases. Perhaps we can find a way to present the following information:

• For people who just want to know what components we intend to build, we provide a simple list of "core" components (or some other name that is more clear)
• For people with a deeper understanding of design system architecture who want more granular knowledge, we provide the tier data

I've updated the list in the task description to remove the component groupings, so this particular task can focus on the list of components and not the organization of that list. Further discussion specific to component groupings can happen in T309109.

Noting that we added ChipInput back in because FilterChips require a chip input, and because there are multiple use cases for it.

@DAbad is it possible for us to "finalize" this as we're preparing for the roadshow ("finalize" being in quotes because this isn't set in stone)? I'm imagining posting this list with a brief explanation of what it is on mediawiki.org, and linking to that list on the Codex docs site. What do you think? I'm happy to create a subpage of our team page on mediawiki.org and draft the explanation and transfer the table of components there.