Hi @RHo — for the toolbar on mobile, is "AI suggestions" text part of the back button? In other words, should the press/active state be applied to the whole "[x] AI suggestions" block or just the [x]?

I'm not sure if there is another precedent with which we have to remain consistent, but the loading state of the mobile toolbar has the button and explanation text as distinct items.

@mewoph -- only the "X" is a button. The "AI suggestions" text is just text. It's the header saying what mode the user is in at that moment, so we wouldn't want tapping it to lead them elsewhere.

@MMiller_WMF Thanks, that's what I thought initially re:functionality, but the mockup seems to suggest otherwise since there is a box encompassing both. So when the user clicks on the [x] there would be a border around just the [x}? This interaction seems rather odd to me. Do we have examples elsewhere of an element with text and icon but only the icon is actionable so I can get a better sense of what this interaction looks like?

In T269638#6929442, @mewoph wrote:

@MMiller_WMF Thanks, that's what I thought initially re:functionality, but the mockup seems to suggest otherwise since there is a box encompassing both. So when the user clicks on the [x] there would be a border around just the [x}? This interaction seems rather odd to me. Do we have examples elsewhere of an element with text and icon but only the icon is actionable so I can get a better sense of what this interaction looks like?

Hi @mewoph - sure thing. This is meant to be like how the toolbar looks in the mobile wikitext (source) mode:

Thanks @RHo! The mock in Figma looks a bit different since there is a base90 background color just for the "[x] AI suggestions" so the item looks distinct from the rest of the toolbar suggesting to me that it's a single tool, whereas this toolbar has the same background base100 color throughout. Should we maintain the same background color here as well?

In T269638#6929561, @mewoph wrote:

Thanks @RHo! The mock in Figma looks a bit different since there is a base90 background color just for the "[x] AI suggestions" so the item looks distinct from the rest of the toolbar suggesting to me that it's a single tool, whereas this toolbar has the same background base100 color throughout. Should we maintain the same background color here as well?

Argh sorry it looks like I accidentally overrided the component colour in Figma, it should be base100 as well, per the standard toolbar. Have fixed it now on the spec.

Got it, thanks @RHo @MMiller_WMF!

Change 677384 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: update surface for AI suggestions mode

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

With this latest patch, all the changes for this task should be ready for testing with the exception of the following:

1. Instrumentation
2. T279492: Add a link: animate icon in recommended link annotation when acceptance changes
3. T279493: Add a link: clicking on robot icon on the annotation doesn't bring up link inspector

In T269638#6978589, @mewoph wrote:

With this latest patch, all the changes for this task should be ready for testing with the exception of the following:

1. Instrumentation
2. T279492: Add a link: animate icon in recommended link annotation when acceptance changes
3. T279493: Add a link: clicking on robot icon on the annotation doesn't bring up link inspector

The button toggling state is implemented in the patch for T269647: Add a link: rejection dialog, I'll see if I can find some time to fix that up. I'd wait for that before doing QA.

Change 677384 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: update surface for AI suggestions mode

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

For @RHo review - the items with

(1)

• Tapping on links in the article should do nothing (except the link suggestions).

The links (not the suggested links) can be right-clicked and opened in another tab/window. It seems to me perfectly fine. I added to signal that there are, in fact, some ways that users are still able to interact with a content.
Also, tapping on an article's templates, images and on the footer will bring up disabled template editor, media settings and page options window repectively.

Media Settings	Page options	Template editor

(2)

• Upon arrival, the user should see the article scrolled all the way to the top. Then it should immediately scroll down to put the first suggestion in the article in focus. The article should not be pre-scrolled to the first suggestion -- we want the user to get oriented to the top of the article and then for it to scroll down.

Please review the animated gif below - although all seem to be not jarring, the fact that the movement happens behind the introduction popup is kind of distracting.
Keep in mind that in real the scrolling happens much smoother than in the gifs.

with the intro (click to animate)	without the intro (click to animate)

(3) Margin and padding around the link element - please confirm that it's ok.

For @RHo review - some questions related but not exactly in the scope of specs for this task:
(1) A user when presented with AI editing mode might switch to Discussion or View history and then it's not possible to return to the AI editing mode.

Note: switching to Read and then click on Edit returns users to AI editing mode.

However, the help panel still display the info on how to add links between articles (and mentioning AI editing mode which is not-accessible now).

(2) The mockup for confirmed links (a user answered "Yes") shows the links as blue. Currently the confirmed links are still black.

mockup	betalabs

Thanks as always for the thorough review @Etonkovidova. This may be a case where for @mewoph and @kostajh to decide whether to open as new tasks for the following:

In T269638#6982335, @Etonkovidova wrote:

(1)

• Tapping on links in the article should do nothing (except the link suggestions).

The links (not the suggested links) can be right-clicked and opened in another tab/window. It seems to me perfectly fine. I added to signal that there are, in fact, some ways that users are still able to interact with a content.
Also, tapping on an article's templates, images and on the footer will bring up disabled template editor, media settings and page options window repectively.

Media Settings	Page options	Template editor

This should be fixed as part of initial release imo as this is an important main requirement to not enable opening other cards, especially on Desktop where the add links card is no fixed as an overlay on the entire page. Equally, it should *not* be possible for all add link inspector cards to be closed:

Desktop	Mobile unexpected ability to close all link suggestion cards

(2)

• Upon arrival, the user should see the article scrolled all the way to the top. Then it should immediately scroll down to put the first suggestion in the article in focus. The article should not be pre-scrolled to the first suggestion -- we want the user to get oriented to the top of the article and then for it to scroll down.

Please review the animated gif below - although all seem to be not jarring, the fact that the movement happens behind the introduction popup is kind of distracting.
Keep in mind that in real the scrolling happens much smoother than in the gifs.

with the intro (click to animate)	without the intro (click to animate)

I agree it is a bit jarring when the editing toolbars and cards are loading on Desktop under the intro pop-up. @mewoph - is there a way to delay the intro pop-up animating on until after the editing toolbar and link inspector card loads?

(3) Margin and padding around the link element - please confirm that it's ok.

! In T269638#6982344, @Etonkovidova wrote:

[...] The mockup for confirmed links (a user answered "Yes") shows the links as blue. Currently the confirmed links are still black.

mockup	betalabs

I've filed new task for visual design fixes for the color and spacing of the link tag styling that includes the above two items here T279684

In T269638#6982344, @Etonkovidova wrote:

For @RHo review - some questions related but not exactly in the scope of specs for this task:
(1) A user when presented with AI editing mode might switch to Discussion or View history and then it's not possible to return to the AI editing mode.

Note: switching to Read and then click on Edit returns users to AI editing mode.

However, the help panel still display the info on how to add links between articles (and mentioning AI editing mode which is not-accessible now).

Should the Help panel for such cases to switch immediately to the normal Help panel?

cc @MMiller_WMF - We should create a new task to handle this case. My initial thinking is to have the same warning dialog as when the user tries to exit by navigating back. I agree that once they return, the help panel should no longer show this guidance if it is no longer available, but how hard is it to keep the task available on returning here? That would be my preference.

Regarding keeping the link inspector open at all times, I think this would be very complicated to achieve (if at all possible) without having a permanent context item (T267706). The link inspector is shown/closed based on focus changes on the editing surface and we don't have a lot of control over that as fas as I know.

I agree it is a bit jarring when the editing toolbars and cards are loading on Desktop under the intro pop-up. @mewoph - is there a way to delay the intro pop-up animating on until after the editing toolbar and link inspector card loads?

We could show the onboarding screens after VE loads. To confirm, the following requirement from T269490 will no longer apply, correct?

On desktop, onboarding will be in modals on top of the article they selected. We want those modals to load as soon as possible when they arrive on the article. Behind the modals, the user should see a greyed-out article.

The use case for switching tabs should be addressed by T278485: Inspector does not open after reloading the page on desktop. When the user navigates to View history or Discussion, there's a full page reload and there is an issue currently where the link inspector doesn't show up upon reload. Once T278485 is fixed, link inspector should show up when the user returns to Edit. If some of the recommendations were already accepted/rejected, upon navigating away, this default warning is shown. Would this be sufficient or do we need to further customize this?

In T269638#6984808, @mewoph wrote:

Regarding keeping the link inspector open at all times, I think this would be very complicated to achieve (if at all possible) without having a permanent context item (T267706). The link inspector is shown/closed based on focus changes on the editing surface and we don't have a lot of control over that as fas as I know.

Ah OK, thanks for explaining how T267706 fits in, I confess I'd not fully understood the implications of that task! @kostajh and @MMiller_WMF - would this be a case of [[ T267706#6923252 | a good UX reason that is solved]] by working on T267706 if not for initial release, then for v1 improvements soon after? I think it's quite important we keep the one link inspector card open at all times.

I agree it is a bit jarring when the editing toolbars and cards are loading on Desktop under the intro pop-up. @mewoph - is there a way to delay the intro pop-up animating on until after the editing toolbar and link inspector card loads?

We could show the onboarding screens after VE loads. To confirm, the following requirement from T269490 will no longer apply, correct?

On desktop, onboarding will be in modals on top of the article they selected. We want those modals to load as soon as possible when they arrive on the article. Behind the modals, the user should see a greyed-out article.

Yes. Unless it is somehow possible for the scrolling to the first link suggestion animation to happen only after the onboarding is closed?

The use case for switching tabs should be addressed by T278485: Inspector does not open after reloading the page on desktop. When the user navigates to View history or Discussion, there's a full page reload and there is an issue currently where the link inspector doesn't show up upon reload. Once T278485 is fixed, link inspector should show up when the user returns to Edit. If some of the recommendations were already accepted/rejected, upon navigating away, this default warning is shown. Would this be sufficient or do we need to further customize this?

Agree fixing T278485 should be sufficient.