Heads up that the badge should act as a count down when completing/declining suggestions, showing a slight animation like the one proposed in the design prototype.

El T420386#11777202, @Esanders escribió:

English will us "9+" instead of "+9" (Echo and Discussions tool have similar counters which use "99+"), but this be in the localised string so can change if necessary in other languages.

@Etonkovidova at the moment, navigation buttons just appear to navigate Edit Checks in the Pre-save moment.

El T420268#11774529, @EAkinloose escribió:

Experience:
Bulb goes grey to communicate that it's been disabled while suggestion side nav and citation popup remains

Since this is just a color token replacement in the disabled button's text, and given that it's related to Button's states, would it be possible to make this change also during this sprint #editing-30mar?

2. Surely close is not a progressive action? (Everywhere else we have a close button it is unflagged). I see it is next another button which is progressive but it would still feel odd to have it be progressive?

Following our recent discussions, we have aligned on the following proposal for how to approach the Design repository moving forward. You can find the full proposal and rationale in this doc.

We’ve decided to pause this work until we have evidence that newcomers are struggling with the current experience. This will be informed by the results of T404600.

What about just Replace to match the question above?

El T358359#11765211, @DTorsani-WMF escribió:

@bmartinezcalvo thanks for your thoughts. Does a Dialog actually change its order and alignment of buttons in RTL languages? I am not aware of us changing the layout based on reading direction.

@Esanders it looks good!

@DTorsani-WMF thank you for working on this. After reviewing the proposed updated, I would rather leave the Dialog buttons position as it is, aligned on the left in LTR to match the natural reading and decision flow. Users scan content from left to right, so placing actions on the right aligns with where their attention naturally ends.

El T414518#11763144, @Esanders escribió:

I've added the remaining issues (button colour, button size) to T386388, and updated the demo.

El T414518#11754652, @Esanders escribió:

@Esanders is the footer issue affecting both button position when it appears on top and at the bottom on desktop? If yes, we will need to solve this issue anyway for when the button would appear at the bottom (suggestions below)

It only appears at the bottom when there are suggestions below, which means there is more of the edit surface below the bottom of the viewport, which means the footer can't be visible. As such showing the button at the top side-steps this issue (as you can see in the patch demo).

El T414518#11753200, @Esanders escribió:

I can see this would be an issue on mobile in section editing. Fortunately on mobile we don't have the footer issue we have on desktop.

I agree that right alignment can feel slightly off in some cases. To maintain consistency, I would align this with the rest of the conversational elements. So if we move the buttons to the left in T358359, I would agree on applying this approach to this Toast as well.

El T413354#11747073, @ppelberg escribió:

@bmartinezcalvo: thank you for updating the task description to include the UX requirements you've helpfully specified for mobile.

Could you please do the same for desktop, per what @kostajh shared in T413354#11739268?

The original design is more aligned with other conversational components (e.g. Dialog, Popover) where the actions appear aligned on the right.

El T414518#11743210, @Esanders escribió:

In implementing I'm comparing this to the "Reply to reply" feature in DiscussionTools and there are some technical reasons for the implementation details used there:

1. In DT the "up" variant appears at the top of the page. This places it close to where there hidden component is, and also avoids the technical issue of what to do when the floating widget intersects with the footer at the bottom of the page.

@kostajh since the hCaptcha is an overlay on top of the Publish dialog, a semi-transparent overlay background-color-backdrop-light should be displayed behind the hCaptcha, as with other dialogs in the interface.

@Esanders the intention behind adding the rays was to better communicate the Suggestions ON state through a subtle animation. The goal was not decorative, but to reinforce the idea that something is active or “producing ideas,” beyond just a color state that changes.

El T415926#11733987, @ppelberg escribió:

Thank you for bringing all these findings together (T415926#11732770), @bmartinezcalvo! A resulting question for you below...

In T415926#11732770, @bmartinezcalvo wrote:
Next steps: Based on findings commented above, we will consider the following in T400903:

• Move Link to first-level, keeping Cite under “+”

Assuming we move forward with introducing the Suggestion Mode Toggle (💡) into the toolbar via T420419, how are you thinking we will create space for the 🔗 button to be visible within the toolbar (as opposed to being housed within the + menu)?

I’ve completed the usability testing conducted with 7 participants (3 newcomers, 4 experienced editors) and here are the main takeaways (more info in the slides with findings and insights):