Page MenuHomePhabricator

Add header to username suggestion list
Closed, ResolvedPublic

Description

This task is about updating the username suggestion list to make it clear to people that typing @ + character(s) within the Reply tool's visual mode will filter the username suggestion list.

Background

In the usability tests we ran (T246191) of Reply v2.0, several people reported: a) the tool's username lookup functionality to be highly valuable and b) said functionality not being obvious. [i][ii]

Implementation details

  1. In the Reply tool's visual mode, when someone types @ or clicks the "👤" icon within the toolbar, people will see the username suggestion list appear with the 👤Find user heading atop it
    • If other people have commented in the section, the username of the other comments' authors should be presented beneath the 👤Find user heading
      • ⚠️ Let's see how this looks once implemented. I wonder whether it may make more sense to not now the heading in this case.
    • If other people have NOT commented in the section, simply the 👤Find user heading should appear with no username beneath it
  2. When someone types a character after @, those characters should appear within the 👤Find user heading.
    • If there are registered username(s) that match the characters the user has typed, said username should be > presented beneath the 👤Find user heading.
    • If there are NOT registered username(s) that match the characters the user has typed, no results should be beneath the 👤Find user heading. This case will be addressed in this ticket: T258460

Tweaks

  • Within the username suggestion list, the text (read: the user's input) that appears after Find user: should be a lighter shade of gray than the Find user: text.
  • Make username suggestion list 50-100% wider

Done

  • Functionality should work in the ways described in the "Implementation details" section
  • All "Tweaks" are implemented

i. "I had to guess typing more of the intended name will eventually offer that name. This is the best functionality imo, but some hint that this functionality exists might be helpful." via @Demian: https://www.mediawiki.org/wiki/Topic:Vmtco3nu7vnfmobq
ii. "It wasn't immediately obvious to me that I could keep typing after the @ to filter the list. But once I discovered that, it was easy to use and felt responsive (though the latter can be hard to judge on a small test page)." via @Pelagic: https://www.mediawiki.org/w/index.php?title=Topic:Vju7lfcav875rt8r&topic_showPostId=vkpxssh1ty6lue6t#flow-post-vkpxssh1ty6lue6t

Event Timeline

We will revisit this task after we complete usability testing:

ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: Demian.

Add a header to the username suggestion list, similar to Phabricator's 👤Find user

That sounds good to me. Discord does that, Twitter not, but @-ing in twitter is seen in many tweets, so it's common knowledge IMO.
Phab adds "👤Find user" to the top of the list. Alternatively:

  • Add "More..." to the bottom of the list, only if there are unlisted users.

In any case clicking on these should not hide the list (users might click this item, expecting a user search dialog to show up).

One more hint would be to show more users. It seems to me the logic does not lists users, that will appear later when I type more characters. An example to demonstrate what I mean:

  1. I type @p -> the list shows only 2 users: PauTest, PPelberg-test
  2. @pp -> PPelberg-test
  3. @ppp -> Ppppowerup
  4. I delete that last character, @pp -> PPelberg-test, Ppppowerup

I'd expect Ppppowerup or another name with "pp" in it to show up for ˙@pp` and possibly @p initially too, not just after backspace-ing.
If the list would be full (eg. 8 or 10 users listed, more would be cluttered), then I'd expect typing more characters will find the user I'm looking for.
As the user list is only 1 or 2 long (in my test), I assume the tool has a very limited set of users to search from (seemingly those, who already commented).
This discourages me from further typing the name in anticipation that it will show up.

To summarize, I'd add this strategy too:

  • Always list 6/8/10 (to be decided) users matching the query. Prioritize the users by: who commented (later) and other activity metrics.

The metrics could be: whom I've interacted with, who was active most recently, etc. If there is such metric that can be cheaply calculated, otherwise this is not important.

One more hint would be to show more users. It seems to me the logic does not lists users, that will appear later when I type more characters. An example to demonstrate what I mean:

  1. I type @p -> the list shows only 2 users: PauTest, PPelberg-test
  2. @pp -> PPelberg-test
  3. @ppp -> Ppppowerup
  4. I delete that last character, @pp -> PPelberg-test, Ppppowerup

I'd expect Ppppowerup or another name with "pp" in it to show up for ˙@pp` and possibly @p initially too, not just after backspace-ing.

This sounds like a bug. Filed as T256974

Task description update

  • ADDED "Implementation details"

Per today's conversation with @Esanders and @iamjessklein, we are going to implement what is described in the "Implementation details" of the task description.

Change 610327 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Support headers in CompletionWidget

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

ppelberg renamed this task from Consider adding header to username suggestion list to Add header to username suggestion list.Jul 8 2020, 5:23 PM

Change 610328 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP Username suggestion header

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

@Esanders, looking good. A question RE the case where no account exists for the username the person is searching for [i]:

  • Is it possible for the suggestion list NOT to return any results in this case?

...I appreciate the tool currently does show "results" in the suggestion list regardless of whether the username the person searching for is registered or not. [ii]

With the above said, I wonder whether this behavior, coupled with the addition of the "Find user:" heading will lead people to expect (and I think, rightfully so) that the person they are searching for has an account considering they searched for them and a "result" showed up.

...I can imagine a case where someone is wanting to ping someone they talk to often [iii], so they type out their username quickly, select a result from the username suggestion list without inspecting their selection too closely, carry on with writing the rest of their comment, posting it only to wonder later why the person they were wanting to talk to hasn't responded.


i. This case is copied from the "Implementation details" section of the task description:

  1. When someone types a character after @, those characters should appear within the 👤Find user heading.
    • If there are NOT registered username(s) that match the characters the user has typed, no results should be beneath the 👤Find user heading

ii.

Search for a user that does not have an account registered and notice the unregistered username appears within the suggestion list
Screen Shot 2020-07-08 at 7.23.21 PM.png (588×498 px, 45 KB)
Confirm no account has been registered with the username that appeared within the suggestion list
Screen Shot 2020-07-08 at 7.23.40 PM.png (1×2 px, 318 KB)

iii.

Screen Shot 2020-07-08 at 7.32.59 PM.png (600×492 px, 53 KB)

@Esanders, looking good. A question RE the case where no account exists for the username the person is searching for [i]:

  • Is it possible for the suggestion list NOT to return any results in this case?

During today's meeting we discussed the following potential approaches
@ppelberg to add more details later
A: update the username suggestion list with some kind of visual indication that communicates to people said username does not exist; complication: possible that this update will happen after user makes selection

B: treat userlinks differently for links that do not have user accounts associated with them; said treatment would be displayed after someone makes a selection from the username suggestion list.

Case: username does not exist

We will consider how to make it clear to people when they've created – what looks like a ping – for an unregistered username in a separate ticket.

Resulting actions

  • I've created a ticket where the work mentioned above will happen in this ticket: T258460
    • Note: the approaches discussed in T252084#6309510 have been added to the description.
  • I've update the "Implementation details" of the task description so it reads as follows:
  1. When someone types a character after @, those characters should appear within the 👤Find user heading.
    • If there are registered username(s) that match the characters the user has typed, said username should be > presented beneath the 👤Find user heading.
    • If there are NOT registered username(s) that match the characters the user has typed, no results should be beneath the 👤Find user heading. This case will be addressed in this ticket: T258460

Next steps:


i. http://patchdemo.wmflabs.org/wikis/e6310e2d8fd7783a713fa9f9cdaa9853/w/index.php/Talk:Main_Page

Looking good @Esanders. A few tweaks and links to things to figure out in the future.

Tweaks:

  1. The default size of input feels small - can it be made a touch larger so that it's roughly a quarter of the size of the default full text box on desktop?
  2. Add in the 👤icons - that indicate whether the user exists or not.
  3. We can save some space by not duplicating the input in the title of the dropdown until an actual user appears

Screen Shot 2020-07-30 at 12.25.56 PM.png (356×486 px, 21 KB)

  1. The find user header - label - should disappear when you start typing

Other Issues

  1. I don't think that we should allow users to type in or talk to users who have no talk page. This is being discussed in: T258460
  2. In the scenario that a contributor wants to add a word that starts with @ - they should be able to escape the flow and not add a user. T259277

Implementation notes
The below are the notes from the conversation @Esanders, @iamjessklein and I had this morning. The "Tweaks" section of this task's description has been updated to include the "Actions" commented in-line below.

  1. The default size of input feels small - can it be made a touch larger so that it's roughly a quarter of the size of the default full text box on desktop?

Action

  • Make username suggestion list 50-100% wider
  1. Add in the 👤icons - that indicate whether the user exists or not.

This issue will be addressed in T258460

  1. We can save some space by not duplicating the input in the title of the dropdown until an actual user appears

Action

  • Within the username suggestion list, the text (read: the user's input) that appears after Find user: should be a lighter shade of gray than the Find user: text.
ppelberg moved this task from 👁Needs Engineering Input to 📐 Doing on the Editing Design board.
ppelberg moved this task from Doing to Code Review on the Editing-team (FY2021-22 Kanban Board) board.

(Yikes, sorry for the move from "Code Review" --> "Doing"...I was intending to move it to the "Doing" column on the Editing Design board.)

Change 610327 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Support headers in CompletionWidget

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

Change 619324 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (18920ed63)

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

Change 619324 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (18920ed63)

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

Change 610328 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Username suggestion header

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