Page MenuHomePhabricator

Newcomer tasks: UX changes for ORES topics
Closed, ResolvedPublic

Assigned To
Authored By
MMiller_WMF
Feb 5 2020, 10:52 PM
Referenced Files
F31662402: image.png
Mar 4 2020, 6:15 PM
F31662385: image.png
Mar 4 2020, 6:15 PM
F31662406: image.png
Mar 4 2020, 6:15 PM
F31662404: image.png
Mar 4 2020, 6:15 PM
F31659922: image.png
Mar 3 2020, 3:35 PM
F31659289: image.png
Mar 3 2020, 12:53 PM
F31659410: image.png
Mar 3 2020, 12:53 PM
F31659302: image.png
Mar 3 2020, 12:53 PM

Description

The new ORES topic models have a more extensive ontology than what we originally implemented for the morelike version in T238610: Newcomer tasks: include topics in intro overlay and T238612: Newcomer tasks: topic filters.

In the morelike version we have 27 topics, and we show 12 by default, with the other 15 appearing when the user clicks "show more".

The way we will use the ORES ontology (as described in T244192: Newcomer tasks: ORES ontology mapping and score thresholds) will give us 39 topics, and we have broken them into four headers. Therefore, below are specifications on how we want to change the topic selection experience in both the topic overlay and the topic filter dialog.

Prototype

This interactive prototype shows how the topic filter should behave with the new topics:

Though the prototype only shows the topic filter, the same changes should be made to the topic overlay, shown when the user initiates the suggested edits module.

And if we want to see how this will look in our target languages, there are also the analogous prototypes below, which are controlled by this spreadsheet (which initially has Google Translate translations, but can be altered by our ambassadors if we wish):

Specifications

  • The topic pill buttons should be organized under four headers, in this order (regardless of language):
    • Culture
    • History and Society
    • Science, Technology, and Math
    • Geography
  • Under each header, the relevant topic pills should be shown alphabetized, according to alphabetization of the language.
  • We should implement the "select all" and "deselect all" links that are shown in the mockup. If there are no buttons selected under a header, the link should read "select all". If there are any selected, it should read "remove all". Note that this language is slightly different than what is shown in the mockup.
  • These additions will require the topic overlay and the topic filter dialog to be scrollable on both desktop and mobile.
  • The topic overlay and topic filter dialog mock should be the same fixed height as each other, and as the difficulty overlay. To display more content than fits, the contents should scroll within the dialog as can be seen in the Search widget and Continuous outlined booklet dialogs on the OOUI demo page.

Visual details

In T238610#5861323, @RHo listed visual design issues with the original topic overlay that contained morelike topics. That task has been resolved, and those outstanding issues are listed below, and should be addressed in the process to update the overlay and filters to contain the ORES models.

For Design review - the line spacing and font (?) for "We'll try to suggest..." subheading looks different from the mockup.

Yes, besides this item, there are other small visual design issues with the topic tags size and spacing.

1. Minor visual fixes to the topic ‘pills’
(i) Height of topic “pills” should be 36px (mobile and desktop)
(ii) More spacing around topic text is expected
(iii) When the topic is selected, there should be ore spacing between text and checkmark icon, and icon from RHS edge of pill

The above items can be fixed by changing a few properties on the following classes:

.wbmad-suggestion-wrapper .wbmad-suggestion {
padding: 8px 20px;  // changed from padding:2px 1.25em
border-radius: 20px;  // increase border-radius to account for taller pill)
}

.wbmad-suggestion-wrapper .wbmad-suggestion--confirmed .oo-ui-labelWidget {
  transform: translateX(-10px);  //decreases space between topic text and LHS edge of pill
}

.wbmad-suggestion-wrapper .wbmad-suggestion--confirmed .oo-ui-iconElement {
  right: 10px; // moves checkmark slightly further away from RHS edge of pill
}

Expected result:

image.png (178×1 px, 99 KB)

2. Desktop-specific items
(i) Dialog should not change height when “show more” is tapped
(ii) Add an extra 10px space between the topic intro text and the first row of topics
(iii) From T243365 - topic intro text should not wrap underneath the overlay illustration.

3. Mobile-specific items
It looks like the mobile version of the topic overlay was not covered in the review, and there are a few differences between expected vs actual.

image.png (936×1 px, 329 KB)

(i) Size of illustration is larger than expected
(ii) The illustration and topic header text should be vertically center-aligned
(iii) The intro/explanatory paragraph should be left aligned with the illustration and not wrap around the illustration.
(iv) The intro/explanatory paragraph text size is larger than expected.

Event Timeline

@RHo -- I'm putting this in your column for two reasons:

  • This is where you can add a link to the prototype of the overlay/dialog that has the topic header and buttons from the new ontology.
  • The original mockup has "select all" and "deselect all" buttons. Do you still think we should include those? We can if you think so, and I'll change the task description.

@RHo -- I'm putting this in your column for two reasons:

  • This is where you can add a link to the prototype of the overlay/dialog that has the topic header and buttons from the new ontology.

– Great, I'll work on this task instead of the T244192 one.

  • The original mockup has "select all" and "deselect all" buttons. Do you still think we should include those? We can if you think so, and I'll change the task description.

– Yes, we should still have the toggle select/select all topics under each header.

@RHo -- could you please also comment on how this overlay should work? Like should the messaging at the top scroll away? Or should it stay stationary as the user scrolls the topics below it? Also, right now, when the user clicks "show more", it changes the size of the overlay to accommodate. Should the overlay size not change once we have these ORES topics?

image.png (530×728 px, 61 KB)

What exactly should be shown before the user clicks Show more? Or does that feature go away entirely?

Under each header, the relevant topic pills should be shown alphabetized, according to alphabetization of the language.

If we want to be serious about that, we'll need to support sort keys in the configuration; alphabetic sorting typically cannot be fully automated.

What exactly should be shown before the user clicks Show more? Or does that feature go away entirely?

In this new version with about ~10-12 topics per header, that is no longer needed.

Under each header, the relevant topic pills should be shown alphabetized, according to alphabetization of the language.

If we want to be serious about that, we'll need to support sort keys in the configuration; alphabetic sorting typically cannot be fully automated.

TBH I am not as convinced alphabetical sorting is super-necessary based on the small number of topics per heading, but wonder if we could support other sorting criteria (popularity of topics selected, # articles in each topic, or even randomized order)

@Tgr -- if we don't implement alphabetical sorting, what will the sorting be governed by?

Currently we use the same order the topics are listed on the configuration page; we could always keep doing that. That gives the community full control (and can be used for sorting alphabetically) but is not very convenient to manipulate, copy to new wikis etc.

We can add a sortkey field, that is fairly trivial. It was mostly just a note to myself to not forget that. (Or we can omit it; possibly it will be never needed. I'm only familiar with lexicographic sorting in Hungarian, there you only need the sortkey for compund words where the word boundaries combine into a fake digraph; that's pretty rare. And maybe for foreign words, which probably won't show up in a topic list.)

Sorting by random is easy but seems very confusing behavior to me. (Or do you mean random but non-changing? That's still easy, we can hash the names or something like that.) Popularity / number of articles is more work, we'd have to store those somewhere and update periodically. IMO not worth the effort unless we really think that way of sorting will make a difference.

MMiller_WMF updated the task description. (Show Details)

Now that @RHo has created the interactive prototype that I've put in the task description, this is Ready for Development.

Change 574908 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] [WIP] ORES topics UI

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

The main part of this (the new UI for ORES topics) is now in code review. Next, I'm going to work on separating the topic preferences for morelike vs ORES, so that when we switch to ORES, everyone's topic selections will be blank and they'll see a blue dot (per a conversation with @MMiller_WMF). After that, I'll work on the design tweaks that the task description asked for.

Another caveat:

The topic pill buttons should be organized under four headers, in this order (regardless of language):

  • Culture
  • History and Society
  • Science, Technology, and Math
  • Geography

Because of how T246061: Newcomer tasks: Sort topics alphabetically was implemented, what happens instead is that the headers are sorted alphabetically, by (translated) header name. This means the order is not the same as what you asked for, and it will also be different in different languages depending on how they translated these names. If you still want to use the fixed order that you asked for, that would ideally be done in the backend. Right now, my frontend code just displays the topics and groups in the order they come from the backend, and doesn't attempt to reorder them.

Screenshot from 2020-02-27 17-08-55.png (777×498 px, 96 KB)

The section order is configurable at the bottom of MediaWiki:NewcomerTopicsOres.json - apparently I misremembered the order and happened to end with one that's also alphabetically sorted in English. I'll update it.

Change 574908 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] TopicSelectionWidget: UI changes for ORES topics

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

Change 575751 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Use different prefs for morelike vs ORES topic filters

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

Change 575752 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] TopicSelectionWidget: Do not resize dialogs when "show more" is clicked

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

Change 575752 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] TopicSelectionWidget: Do not resize dialogs when "show more" is clicked

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

Change 575751 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Use different prefs for morelike vs ORES topic filters

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

@Catrope says that some of the design changes @Rita Ho asked for would cause our "pill" widgets to diverge from the ones in MachineVision. There's no technical issue with that necessarily, but we wonder if those changes shouldn't be made in both.

@RHo, do you have an opinion on this?

Also -- as of today, part of the design changes listed in the task description are merged, but the rest will be done next week.

@Catrope says that some of the design changes @Rita Ho asked for would cause our "pill" widgets to diverge from the ones in MachineVision. There's no technical issue with that necessarily, but we wonder if those changes shouldn't be made in both.

@RHo, do you have an opinion on this?

Thanks @MMiller_WMF and @Catrope , I agree that it would be ideal if the changes would be made in both. So looping in @AnneT and @mwilliams – I'd like to propose both teams update the pill/tag widget in the following ways:
(a) Taller height - particularly as the current height is smaller than ideal for tap targets on mobile devices. Proposal is for 36px height (same as buttons)
(b) More padding around text in selected tags - adding a tiny bit more breathing room between text and checkmark with the left and right edges of the pill.

Visual showing current v proposed on both UIs:

Current (Suggested edits topics group)
image.png (1×726 px, 111 KB)
Proposed
image.png (1×732 px, 110 KB)
Current (CAT example)
image.png (1×726 px, 607 KB)
Proposed
image.png (1×728 px, 604 KB)
Proposed with additional spacing tweak to margins around tags
image.png (1×724 px, 398 KB)

Note that I have kept the spacing around each pill different on CAT vs Suggested edits as per the implementation. I would also suggest reducing the space between tags on CAT.

@kostajh is going to manage fixing the padding/margins on mobile this week before the train hits production. See issues below:

image.png (648×367 px, 74 KB)

@RHo Makes sense to me! I'll update my mock ups and work with @AnneT to get that updated!

Change 576640 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Adjust topic UX

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

This looks good to me doing the design review on Chrome:

Desktop overlay
image.png (1×1 px, 275 KB)
Mobile overlay
image.png (1×728 px, 114 KB)
Desktop filter
image.png (1×1 px, 371 KB)
Mobile filter
image.png (1×732 px, 116 KB)

@Catrope @kostajh @Tgr -- @RHo brought up a good question around instrumentation. With the morelike version, we logged an event when the user clicked "show more". The ORES version doesn't have "show more" -- it has "select all" and "remove all". I just tried in beta, and I don't think we have events for those. If we don't, that's okay, but I'll file a separate task to add them later. Let me know!

Yeah, we don't have events for those.

Also the above the fold / rest differentiation when logging selected topic types doesn't make sense anymore and should be removed.

Change 576640 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Adjust topic UX

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

Change 577002 had a related patch set uploaded (by Gergő Tisza; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.35.0-wmf.22] Adjust topic UX

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

Change 577002 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.35.0-wmf.22] Adjust topic UX

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

Mentioned in SAL (#wikimedia-operations) [2020-03-05T00:45:39Z] <tgr@deploy1001> Synchronized php-1.35.0-wmf.22/extensions/GrowthExperiments/modules/homepage/: SWAT: [[gerrit:577002|Adjust topic UX (T244421)]] (duration: 01m 05s)

Checked in betalabs - all look identical to the screenshots @RHo added.

@MMiller_WMF - moving to PM review to let you know that the adjustments have been made and checked; the phab task can be markedas Resolved. I'll do additional checking after wmf.22 deployment.

MMiller_WMF closed this task as Resolved.EditedMar 6 2020, 8:50 PM

Great, thank you! I filed T247124: Newcomer tasks: additional EventLogging for ORES topics UX about the EventLogging changes.