El T349016#10429379, @DTorsani-WMF escribió:

@CCiufo-WMF I wonder how this task can be refined or at least reviewed with the changes completed in T379299: docs: Implement simplification of component pages.

El T358857#10429335, @DTorsani-WMF escribió:

@bmartinezcalvo do we still want to provide these guidelines after the work in T379299: docs: Implement simplification of component pages and with the Toast component T303612 on the horizon?

El T366019#10429254, @DTorsani-WMF escribió:

@bmartinezcalvo do you mind reviewing this task to check what parts are still relevant after the docs simplification work of T379299?

With the simplification of component pages in T379299, I think this task no longer makes sense since the components pages now include info for any type of user in all sections. So declining this task.

That being said, we do want to consider where we should include the Figma link more globally and include the other resources which are currently found on the main page of the Codex docs site. > Some ideas are:

• Add the "Resources" section on the "Using Codex" page in the "About" section.
  • This wouldn't mean removing this section from the main page.
• Add the "Resources" section on the "Contributing" page in the "Overview" section.
  • One reason not to do this is because the necessary resource links are included throughout the contributing pages where appropriate.

El T322459#10429208, @DTorsani-WMF escribió:

During the docs simplification work in T379299, @AnneT and I discussed this again. The "Show code" action is actually a ToggleButton. We determined that the quiet ToggleButton would not work as well here since it is too subtle, so we decided to leave this as-is. Do @Volker_E and @bmartinezcalvo agree, and therefore can we close this task?

@lwatson thank you for working on this! I've been exploring some other design solutions for the "Return to top" and the "On this page". Let me know if it would be possible to make these changes:

@JSengupta-WMF since the Wikimedia Design Jam was completed on 12th and 13th December, I guess we can solve this task.

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

@Volker_E @CCiufo-WMF Moving the task to Needs Refinement so we can start with its implementation in the following sprints.

Ater some discussions with the team, these are the decisions for the Container implementation:

El T317792#10417333, @AnneT escribió:

@Volker_E in the design sync, we agreed that @bmartinezcalvo would open a task to document future improvements to the VitePress search UI

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:

@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.

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?

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

El T364377#10409827, @DTorsani-WMF escribió:

@bmartinezcalvo As a part of the docs simplification work, we went through this process. Therefore, this task can be resolved, right?

El T311209#10409822, @DTorsani-WMF escribió:

@bmartinezcalvo Since we recently updated these styles, this task is no longer relevant and can be resolved, right?

El T352465#10409801, @DTorsani-WMF escribió:

@bmartinezcalvo I believe we can close this task as the "With link" Card is documented in the Codex guidelines, right? https://doc.wikimedia.org/codex/latest/components/demos/card.html#with-link

Since we are removing all images from the components pages in T379299: docs: Implement simplification of component pages, I guess we can decline this task.

El T331623#10406396, @Dolphyb escribió:

@bmartinezcalvo My bad that i didn't finish this task during WMDJ but i would still like to finish to task if it's okay by you?

El T331623#10402376, @bmartinezcalvo escribió:

El T331623#10402134, @Dolphyb escribió:

[#wmdj]: @bmartinezcalvo i have updated the necessary changes in my own copy of figma codex . dont know if any more action is required from my own end to completed this task?

Hi @Dolphyb, thank you for working on this! As commented during the Codex Intro, we only include the components in the Codex library once they have been implemented in code, so we usually use Figma exploration files ]] to explore and decide before implementing the component, and then we include those updates in the Codex library once they have been implemented. So I recommend you to include your explorations in the Figma file linked in this task, so we can easily review it and discuss.

Regarding the new design of Inline Message, the idea with this task is to make the Inline Message less prominent since now the Bold style makes it so visible when used within forms. So you can explore possible solutions for that.

El T331623#10402134, @Dolphyb escribió:

[#wmdj]: @bmartinezcalvo i have updated the necessary changes in my own copy of figma codex . dont know if any more action is required from my own end to completed this task?

El T379299#10400964, @DTorsani-WMF escribió:

Another, probably more simple idea, was to bring the demo, configurable parts, and developer notes more physically close—essentially remove the margin between those elements, and sharpen the border-radius where they meet. Something like the image below.

El T379299#10397639, @DTorsani-WMF escribió:

If you all feel good about moving the developer notes below, I'm okay with that! I can see how we might need to add some more prominence then if we do that, but maybe the fact that they're bold and indented is enough? I'm afraid to add more borders and lines to the page. Some design feedback I got during design review was that there were already a lot of lines/dividers on the page. We reduced this by removing some unnecessary borders and lightening the color of the border around the example demos.

El T379299#10396677, @DTorsani-WMF escribió:

1. So far we are removing the References section, but moving important links from there directly to the text where they were referenced from.

I've reviewed the first patches and I've left some comments about those components pages. But adding here some generic feedback about these new summarized guidelines:

El T381215#10394287, @CCiufo-WMF escribió:

I believe this is by design -- we don't know every way messages could be used, so we leave it up to the user to add margins (or padding) when applicable. cc: @bmartinezcalvo @DTorsani-WMF

El T370214#10374025, @JScherer-WMF escribió:

Latest designs:

cc @bmartinezcalvo

El T373597#10390538, @OTichonova escribió:

The ticket has been updated with Spec sheet & Guidelines links

cc @bmartinezcalvo

El T342126#10381522, @Volker_E escribió:

The padding change results in this, which is design-wise problematic:

Thank you for working on this @Anne. Listing here some feedback collected from yesterdays DST design sync in case we want to apply this feedback in future versions of Image:

El T377493#10381733, @mwilliams escribió:

Thanks for your thoughts @Pginer-WMF. I definitely agree with the idea that bouncing dots might feel better suited for tasks where the user can anticipate an end result, especially in regards to messaging contexts. Guessing our constant exposure to the dots in text messaging has created this feeling that something is coming imminently.

It's also interesting that we used some similar examples but came to opposite conclusions, for example I preferred the spinner in the button loading use case because you could keep the text of the button.
We could also repurpose the spinner to not only be indeterminate but determinate which could make it more versatile.

I would propose a flexible approach to our next steps to keep this moving:

1. Continue with the creation of a progress indicator that is a Spinner. With that and the progress bar in Codex, we cover most use-cases. Since bouncing dots aren't currently a Codex component we aren't removing any functionality, it won't impact any past work that is using the bouncing dots.
2. Next up we work on implementing a skeleton / placeholder loading UI that will cover even more use cases.
3. With most use cases covered and generally more feedback and context, we consider whether we should add the bouncing dots as an additional option.

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)

@DTorsani-WMF this update makes sense to me. We could use the color-subtle when the icon is just decorative. And we could use a different icon color when:

• The icon is within a placeholder state (in this case it will use @color-placeholder to avoid the icon to be darker than the placeholder text)
• The icon is a status (notice, success, error, warning)
• The icon is part of an action/link

El T314514#10376294, @AnneT escribió:

@bmartinezcalvo I'd like to add an example to the Image demo page of an illustration that's different in RTL and LTR. Could you please export images that we can use for this, like the ones you used in the Figma spec?

As discussed and decided with the DST, this component will be finally named "Toast" to avoid longer and compound names. In case we reorganize the components list into groups in the components panel in Codex, this Toast will be grouped with the rest of the feedback components under a Notifications/Messages/Feedback section.