El T350801#10200795, @DTorsani-WMF escribió:

To be fair, when we disable the button, the label becomes inaccessible from a color contrast perspective. That being said, I'm not against finding a better solution that keeps the label.

What about using a slightly altered variation of an inline ProgressBar at the bottom of the button? Something like this? (You can imagine it animating across the bottom of the button with the subtle padding on the sides and bottom. It would be white instead of blue.)

Too much?

After exploring more how to solve the Lookup usability issues listed in this task, here are additional solutions:

El T350801#10199393, @AnneT escribió:

In T350801#10197581, @DTorsani-WMF wrote:

I agree with the proposal. I do think providing an animated indicator within the button while it is disabled and loading could be helpful. I think in this case, we would replace whatever is in the button with the loading indicator, be it text, icon + text, or icon only. The button would maintain its original width.

We could do this by overlaying the icon and a background on top of the existing label, which would be covered up - that would be necessary to maintain the width of the button (we couldn't just visually hide the label with CSS).

That said, it would obscure the label for sighted users, and I'm concerned about that for reasons described in this comment above. I'd recommend we place the loading icon alongside the label instead.

El T350801#10189149, @AnneT escribió:

I have a few proposals, and think we could brainstorm more design ideas as part of this task:

• Show an inline message indicating what's happening after the button is pressed and during the process.

El T305036#10191835, @DTorsani-WMF escribió:

I think you may have meant to tag @AAlhazwani-WMF instead of Anne. But yes, I agree with the proposal and your justification, Bárbara.

I guess we will resize the external link icon from 16px to 12px as part of this task. So adding this as Acceptance criteria.

El T371118#10191160, @Volker_E escribió:

The request for amendment makes sense to me 👍🏻
As a note, link outlines are currently featuring Blue600 #4b77d6 in both, light and dark mode.

If we change the border focus color, we'd also have to change the corresponding box-shadow color (and consider to change the link focus color as mentioned above).

This would be Blue400 #88a3e8 :

I'd suggest Blue500 #6b8edf instead, as it has a stronger contrast to the default white color for components (it pops more, clarifying focus better, for example when tabbing through the interface) and still satisfy the 99.9% majority of our dark mode background colors.

What if we start from the icon (monochrome) version to make these logos more recognizable? We can use solid colors without any gradients.

El T305036#10187187, @AAlhazwani-WMF escribió:

@bmartinezcalvo @DTorsani-WMF i wanted to share a few visual suggestions to the latest proposal. feel free to take those ideas into account or ignore them if it doesn't make sense.

headers
adding a spacer above the headers could visually unbalance the vertical rhythm. the bolden text might be enough to visually separate the headers from menu items. i was also wondering if setting the headers to color-base might drive too much attention, what about color-subtle?

current	proposal

El T322014#10181695, @CCiufo-WMF escribió:

We shouldn't have to change anything with the Link yet, that work is captured in T369869. For now we want to preserve the current, but just have a new icon.

I conducted a Miro exercise with the design team, as well as a series of individual interviews with DST team members to discuss about what Responsiveness means for us and how we can define the right scope for the next step on Responsiveness. After analyzing all interviews, I've created these Google slides with findings and the next steps on this.

I've updated both Figma spec and Guidelines (patch 1073431) including the grouping within Menu. Depending on whether menu groups have a clear title to include in the menu item set, they could be grouped in two different ways:

1. Using headers: A prominent bold @color-emphasized header can be added as a title to group a set of menu items. Each group with a header will be separated by @spacing-75 (12px) for clearer distinction.
2. Using dividers: In those cases where there is no clear title to include in the groups, a @border-color-muted divider can be used to separate them.
   

El T374636#10158034, @JScherer-WMF escribió:

Latest designs

Tweaks made based on @bmartinezcalvo 's feedback and others. Changed the default background colour to interactive-subtle to differentiate it from the article content and the open state background colour. Added the coloured warning and success icons to the infochip. Broke out "learn more" CTA onto its own line in the description.

El T374731#10157801, @CCiufo-WMF escribió:

While I agree that logos and icons are distinct things, the use case for these logos is as icons. I think we should keep things simple and treat them as icons. Having them be organized separately within icons like @AnneT makes sense since they do behave differently (like in color modes).

El T374731#10157109, @DTorsani-WMF escribió:

@bmartinezcalvo Should the word "icon" be in the name at all then? Could it just be "logos"?

El T374731#10154907, @AnneT escribió:

• I've called these "multicolor icons" in the code and docs, but Eric brought up the idea of explicitly limiting this icon set to logos - is that something we want to do? Are there other valid use cases for multicolor icons, or should we limit them to logos? cc @bmartinezcalvo @DTorsani-WMF @Volker_E

El T374731#10151025, @AnneT escribió:

hey @bmartinezcalvo, could you export the isotopes at 20x20 px? The files linked in the task are 48x48

El T374731#10145529, @CCiufo-WMF escribió:

@DTorsani-WMF @bmartinezcalvo @mwilliams curious to know if there's any controversy over this or if we can just move this task to the design stage.

Ok, in case we represent them as "ChipInput" and "ChipLookup", we could rephrase these component's descriptions to be clearer on how users create chips on each them. I propose the following rephrasing:

El T345291#10142587, @AnneT escribió:

Initial feedback would be welcome, especially around user interaction details (for example, when you delete a chip, the menu closes because the input has lost focus. Should that happen?)

El T345291#10142587, @AnneT escribió:

@bmartinezcalvo here's a work-in-progress demo of the ChipInput with Menu, which I've built into a new component called ChipLookup. We can workshop the name, or we may decide to put the new functionality into the existing Lookup component and refer to it as a multiselect variant of Lookup.

Hi @Dogu, some weeks ago we worked on some improvements for the Table's headings, where we intentionally included the sort icon next to the header's label. So the expected behavior should be the sort icon next to the heading's label, separated form it by 8px:

El T371998#10138177, @lwatson escribió:

In T371998#10138155, @gerritbot wrote:

Change #1072254 had a related patch set uploaded (by LWatson; author: LWatson):

[design/codex@main] docs: reorder MenuItem's config demo props

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

As requested @bmartinezcalvo, I reordered the props listed in the config demo. I did not rename any props.

After exploring different options to ensure the Thumbnail's background is visible in both light and dark modes when the Thumbnail image has a transparent background, we've decided that using the @background-color-base-fixed (white) is the best solution. Although pure white #FFF is not recommended for dark mode, this isn't a problem in this case since the white color will work as image's background, so users will perceive it as part of the image itself.

El T363515#10137699, @lwatson escribió:

@bmartinezcalvo Another option: Anne suggested the checked-error-focus state as a red-colored version of the checked-default-focus state. (Preview: https://1024536--wikimedia-codex.netlify.app/components/demos/radio.html#configurable)

El T363515#10135625, @AnneT escribió:

Hey @bmartinezcalvo, I was just chatting with @lwatson about the patch to add error styles to Radio and was wondering if we could revisit the design for the Radio in a checked-error-focus state. The design shows this:

However, that blue border on the outside is going to be really hard to achieve in the code. Am I remembering correctly that Radios really shouldn't be both checked and in an error state anyway? If so, I don't think we should spend too much more time trying to get the checked-error styles right.

@lwatson I've reviewed the new multi-selection prop included within the MenuItem and it looks god and works fine in the Menu with multi-select. I would just update the MenuItem configurable demo to be more intuitive, following the natural sequence of interacting with the MenuItem. So I suggest this order of the states: