Page MenuHomePhabricator

Add a link: rejection dialog
Closed, ResolvedPublic

Description

When the user selects "No" in the link inspector, they are shown the "rejection dialog", where they indicate why they rejected the suggestion.

  • Behavior
    • On both desktop and mobile, this is a modal that does not overlay the whole screen.
    • It contains a radio button set of choices; the user can only selection one.
    • It has a "Done" button on the bottom.
    • The user may select the "Done" button whether or not they choose a response. That button is the only way to dismiss the dialog.
    • When the user selects "Done" on mobile, this triggers an auto-advance to the next suggestion.
    • If the user makes a selection and selects "Done", then the link inspector changes. It gets an ellipses next to the "No" button, which the user can select to re-open the rejection dialog. When re-opened the dialog should show the response the user gave and allow them to change it.
    • If "No" has already been selected, and then the user clicks or taps on "No" again, toggles the button, but does not re-open the dialog.
    • Ellipsis button label: "Select reason this is not a good link"
  • Content
    • Header: "Why is this not a good link?" (bold)
    • Sub-header: "Your answers improve future suggestions."
    • Option 1: Almost everyone knows what it is
    • Option 2: Linking to wrong article (e.g. linking "moon" to "planet")
    • Option 3: Text should include more or fewer words (e.g., "palm tree" instead of "palm")
    • Option 4: Other
Mobile mockups as of 2021-01-12:
Desktop mockups as of 2021-01-12:

NOTE: Refer to Figma for up-to-date detailed redline mocks and specs:
Mobile: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=181%3A65
Desktop: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=112%3A0

Instrumentation

See T278117: Instrumentation: Rejection dialog for details.

Event Timeline

Change 654217 had a related patch set uploaded (by Kosta Harlan; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] AddLink: Add rejection dialog

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

Option 1: Everyday concept that does not need explanation (e.g. "sky")

I think this is a lot more context-dependent in practice. In an article about Abelian groups you might not want to link addition because the reader is no doubt familiar with it; in the article about subtraction you probably do. It's some hard-to-define combination of expected reader proficiency and how closely the two articles are related. I wonder if something like ''the average reader of this does not need an explanation of the concept'' would express that better.

Link should include more or fewer words (e.g. "palm tree" instead of "palm")

Maybe clearer with "text to be linked" instead of "link"? Just to make it clear this is not about the link target.

Option 1: Everyday concept that does not need explanation (e.g. "sky")

I think this is a lot more context-dependent in practice. In an article about Abelian groups you might not want to link addition because the reader is no doubt familiar with it; in the article about subtraction you probably do. It's some hard-to-define combination of expected reader proficiency and how closely the two articles are related. I wonder if something like ''the average reader of this does not need an explanation of the concept'' would express that better.

While I agree with that phrasing ''the average reader of this does not need an explanation of the concept'' takes into account the target audience (i.e. assumes that the target audience has a specific proficiency level), I noticed that Abelian group article has words Mathematics, addition, and a natural number linked to the respective articles.

Change 654217 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] AddLink: Add rejection dialog

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

@RHo quick clarification:

When the user selects "Done" on mobile, this triggers an auto-advance to the next suggestion.
If the user makes a selection and selects "Done", then the link inspector changes. It gets an ellipses next to the "No" button, which the user can select to re-open the rejection dialog. When re-opened the dialog should show the response the user gave and allow them to change it.

  1. Auto-advance should only happen on mobile, and not on desktop?
  2. If "No" has already been selected, and then the user clicks or taps on "No" again, does that a) toggle the button or b) re-open the dialog? (In other words is re-opening the dialog only done via the ellipses icon widget?)

@RHo quick clarification:

When the user selects "Done" on mobile, this triggers an auto-advance to the next suggestion.
If the user makes a selection and selects "Done", then the link inspector changes. It gets an ellipses next to the "No" button, which the user can select to re-open the rejection dialog. When re-opened the dialog should show the response the user gave and allow them to change it.

  1. Auto-advance should only happen on mobile, and not on desktop?

Yes that's right, auto advance should only occur on mobile please.

  1. If "No" has already been selected, and then the user clicks or taps on "No" again, does that a) toggle the button or b) re-open the dialog? (In other words is re-opening the dialog only done via the ellipses icon widget?)

It should be (a), the No is toggled off (at which point the ellipsis icon also disappears, as the rejection selection is cleared).

Change 674306 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Rejection dialog implementation

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

Change 674349 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Rejection dialog: Add ellipsis button widget

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

@RHo quick clarification:

When the user selects "Done" on mobile, this triggers an auto-advance to the next suggestion.
If the user makes a selection and selects "Done", then the link inspector changes. It gets an ellipses next to the "No" button, which the user can select to re-open the rejection dialog. When re-opened the dialog should show the response the user gave and allow them to change it.

  1. Auto-advance should only happen on mobile, and not on desktop?

Yes that's right, auto advance should only occur on mobile please.

  1. If "No" has already been selected, and then the user clicks or taps on "No" again, does that a) toggle the button or b) re-open the dialog? (In other words is re-opening the dialog only done via the ellipses icon widget?)

It should be (a), the No is toggled off (at which point the ellipsis icon also disappears, as the rejection selection is cleared).

OK, thanks @RHo. One thing I'm confused about:

  1. On desktop, the user clicks "No" and fills in their reason
  2. User sees the "No" button has a blue background, and now sees the ellipsis button, which they can click to reopen the rejection dialog.

How does the user advance to the next suggestion? Clicking "Skip" seems counterintuitive since they've already pressed "No".

@RHo quick clarification:

When the user selects "Done" on mobile, this triggers an auto-advance to the next suggestion.
If the user makes a selection and selects "Done", then the link inspector changes. It gets an ellipses next to the "No" button, which the user can select to re-open the rejection dialog. When re-opened the dialog should show the response the user gave and allow them to change it.

  1. Auto-advance should only happen on mobile, and not on desktop?

Yes that's right, auto advance should only occur on mobile please.

  1. If "No" has already been selected, and then the user clicks or taps on "No" again, does that a) toggle the button or b) re-open the dialog? (In other words is re-opening the dialog only done via the ellipses icon widget?)

It should be (a), the No is toggled off (at which point the ellipsis icon also disappears, as the rejection selection is cleared).

OK, thanks @RHo. One thing I'm confused about:

  1. On desktop, the user clicks "No" and fills in their reason
  2. User sees the "No" button has a blue background, and now sees the ellipsis button, which they can click to reopen the rejection dialog.

How does the user advance to the next suggestion? Clicking "Skip" seems counterintuitive since they've already pressed "No".

They can tap on the next link on the editor surface itself as well as the skip with ">" icon... but I don't disagree that calling it "skip" could potentially be confusing when it is the same button as the next chevron icon.
Spitballing some potential solutions in order of preference:

  1. Also have auto-advance on Desktops as people in usability testing didn't have trouble with it. We decided this as a the that having auto-advance might be disorienting on desktop when they can likely see the other suggestions nearby.
  2. Change the label to be "Next". This may reduce the affordance that the user can skip without seeing the word skip on there, but maybe this nuance could get lost in translation anyway
  3. Remove the "Skip" label on desktop entirely, just have the forward chevron icon button.

Which do you think is the most ideal from eng-perspective?

They can tap on the next link on the editor surface itself as well as the skip with ">" icon... but I don't disagree that calling it "skip" could potentially be confusing when it is the same button as the next chevron icon.
Spitballing some potential solutions in order of preference:

  1. Also have auto-advance on Desktops as people in usability testing didn't have trouble with it.

Easy to implement if we want to do that. So: if the user visits a recommendation that they already skipped or provided accept/reject for, then they'd be able to toggle the buttons and in that case auto advancing would not occur. For example, I clicked "No" and autoadvanced to the next suggestion, then I went back to the previous one, "No" appears in blue and I click it to toggle its state, in that case auto advancing does not occur.

We decided this as a the that having auto-advance might be disorienting on desktop when they can likely see the other suggestions nearby.

FWIW, I've sometimes found it difficult to visually pick out where on the page the link recommendations, so ensuring the user knows they can use the backwards/forwards arrow and/or providing auto advancing seems important.

  1. Change the label to be "Next". This may reduce the affordance that the user can skip without seeing the word skip on there, but maybe this nuance could get lost in translation anyway

+1 from me.

  1. Remove the "Skip" label on desktop entirely, just have the forward chevron icon button.

Also +1, but I think having "Next" on there might be a bit more clear to the end user.

Which do you think is the most ideal from eng-perspective?

Anyway, from an engineering perspective all are about the same level of effort; but if we implement auto-advancing on desktop and want to have more fine grained control over viewport positioning and scrolling effects, that's probably going to have be something that waits for after the initial release.

Thanks @kostajh - taking all your comments into account, esp. the one at the end around fie-grained control over viewpoint positioning if we add auto-advance on desktop, let's go with the least disruptive one and change the label on the button to "Next". I'll update the copy doc and relevant task.

They can tap on the next link on the editor surface itself as well as the skip with ">" icon... but I don't disagree that calling it "skip" could potentially be confusing when it is the same button as the next chevron icon.
Spitballing some potential solutions in order of preference:

  1. Also have auto-advance on Desktops as people in usability testing didn't have trouble with it.

Easy to implement if we want to do that. So: if the user visits a recommendation that they already skipped or provided accept/reject for, then they'd be able to toggle the buttons and in that case auto advancing would not occur. For example, I clicked "No" and autoadvanced to the next suggestion, then I went back to the previous one, "No" appears in blue and I click it to toggle its state, in that case auto advancing does not occur.

We decided this as a the that having auto-advance might be disorienting on desktop when they can likely see the other suggestions nearby.

FWIW, I've sometimes found it difficult to visually pick out where on the page the link recommendations, so ensuring the user knows they can use the backwards/forwards arrow and/or providing auto advancing seems important.

  1. Change the label to be "Next". This may reduce the affordance that the user can skip without seeing the word skip on there, but maybe this nuance could get lost in translation anyway

+1 from me.

  1. Remove the "Skip" label on desktop entirely, just have the forward chevron icon button.

Also +1, but I think having "Next" on there might be a bit more clear to the end user.

Which do you think is the most ideal from eng-perspective?

Anyway, from an engineering perspective all are about the same level of effort; but if we implement auto-advancing on desktop and want to have more fine grained control over viewport positioning and scrolling effects, that's probably going to have be something that waits for after the initial release.

Change 675776 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Rejection dialog: Store reason in annotation

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

Change 675781 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Rejection dialog button toggling

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

Change 674349 abandoned by Kosta Harlan:
[mediawiki/extensions/GrowthExperiments@master] [WIP] Rejection dialog: Add ellipsis button widget

Reason:
See Ib89dea32b1846802421c43093f9d39db934d7497

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

Change 675781 abandoned by Kosta Harlan:
[mediawiki/extensions/GrowthExperiments@master] [WIP] Rejection dialog button toggling

Reason:
Squashed into I414308f1c828599ab1054f9ba91ddebde8337274

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

kostajh triaged this task as Medium priority.Wed, Apr 14, 12:52 PM

Change 675776 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Link: Implement rejection dialog

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

For Design review - all seem to be in place.

Just to clarify - without selecting any options and clicking "Done", what would be stored as an answer?

For Design review - all seem to be in place.

Just to clarify - without selecting any options and clicking "Done", what would be stored as an answer?

It should be null, but I think we'll probably end up storing it as an empty string both in the database and in event logging.

Thanks @Etonkovidova and @kostajh - I only had one minor tweak!
Can we reduce the space between the heading and explanation text?
Actual

(space btween heading and text is 1em)
vs
Expected Space between heading is 0.25em

Mobile
Desktop
-

I think this is basically changing the margin to the following
.mw-ge-recommendedLinkRejectionDialog .oo-ui-messageDialog-message { margin: 0.25em 0 1em; }

Change 681329 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] AddLink: Adjust margin on rejection dialog message

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

Change 681329 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] AddLink: Adjust margin on rejection dialog message

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

With the adjusted margin:

DesktopMobile

Superb, thanks!