Hey @Dbrant, in a meeting with @schoenbaechler and he said it is okay to use the interaction from Editing Team, he will also look into material design as a backup

@Dbrant @JTannerWMF some inspiration on how to adopt the username suggestion on Mobile from Twitter:

Thanks for sharing this @schoenbaechler , @Dbrant mentioned to me that the Editing team built their @ mention feature on VE , so we won't be able to do it entirely the same way. Something I mentioned was if we can brainstorm on perhaps an alternative. For example, either let people know when they hit reply to use wikitext conventions to ping someone, or put the brackets in their for them. I will be OOO first week in January but feel comfortable with whatever solution the two of you discuss as long as we are ensuring a user with no background in wikitext can confidently tag a user they are replying to in order to ensure they are aware they have gotten a reply to an existing thread.

A possible alternative is any time a user presses reply, we auto add @{User_talk:x} with the cursor in the x with the expectation that the user will add the user OR if we can grab the user name and insert it for them that would be ideal. Tagging @MattCleinman to follow along

Potential solution, in two parts:

First, to easily allow folks to add mentions when doing in line replies:

1. Anytime there is whitespace (space or newline) followed by an @ symbol, convert the at symbol to @{}, with the cursor in between the two curly brackets.
2. When sending data to the server, change anything in the format @{any text} to [[User talk:any text]] before sending it up to the server. User talk seems to redirect in all languages, as appropriate. (For instance in Arabic Wikipedia it redirects to some Arabic meaning "user talk".)

Second, to automatically tag the person they're replying to, if it's a nested reply (if it's a new topic, don't do any of this):

1. Use UserTalkAliasData to find what User Talk is called in the language Wikipedia we're in.
2. Find the final mention of that term in the text that is being replied to. It should be next to a colon.
3. Find the part after the colon. This should be the username. (I think this should generally work for RTL languages, but may not always work for LTR usernames in RTL languages and vice versa.)
4. Start the freeform text for the reply with @{Username} .

Concerns about these proposed solutions? Am I missing anything key that would prevent them from working?

The engineer that picks this up should explore some of the solutions listed here in close partnership with @schoenbaechler , I think this is one of those tasks where we won't knwo which route is easiest based on our tech limitations until we try

@Dbrant and I talked about designs for this today. There are still some things left to investigate per Dmitry’s comment, but there’s nothing more needed from a design perspective. @JTannerWMF @MattCleinman please check out the designs as well.

In a meeting with @schoenbaechler and we discussed making sure there is an accent color to indicate if a user name is active or not, which may also result in changing the color of the compose message. We also would like to remove the colon if it isn't after the first user name.

I'm making the pre-population a separate task T299182

This is great work @Dbrant — some feedback:

01) Please show the keyboard directly once users tap 'REPLY`. The view should also scroll to the last message, so the CC0 disclaimer is visible, the view doesn’t jump and convenience when searching for other users), like this:

Here’s a video of the current behavior of my device (keyboard stays disabled once reply is tapped):

https://www.dropbox.com/s/pf0dzx9khdrr3yl/screen-20220120-192631.mp4?dl=0

Please check out the designs for reference, you can see that the input field stays where it is:

If this is too difficult to achieve I suggest to always move the reply field to the top of the view and show disclaimer and suggestion dropdown below it (to avoid jumps when looking for other users)

02) Don’t show the CC0 disclaimer when the auto suggestion dropdown is visible:

Show it again once a username has been selected:

@schoenbaechler please try the latest run:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/1729171415

The keyboard should appear automatically. However, when showing the drop-down list of usernames, some amount of scrolling is not avoidable.

(p.s. you can now drop videos directly into Phab)

@Dbrant lets discuss this in our 1:1 today 👋

Notes from the call with @Dbrant 👇

• DB will look into the keyboard issue: it is currently not showing up after tapping 'REPLY' (it’s working in Suggested edits)
• Hide CC0 disclaimer when @mention dropdown is visible to save vertical screen estate
• DB will look into moving the input field further up (and below the latest message) to have more space below for the @mention dropdown, see comparison below

Implementation | vs | Design

CC @JTannerWMF

@Amire80 Question for you:
We're implementing @-mention functionality in Talk pages, which seems to be a nearly universal standard on various media platforms for pinging users. However, I have a feeling that the @ notation is specific to Western cultures, and specifically to LTR languages. Is the @ symbol used for pinging users on RTL wikis (hewiki, arwiki, etc), or is it a different symbol? Or are there different conventions entirely?

@schoenbaechler I've made some tweaks to improve showing/hiding the keyboard when replying:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/1745876752

@Dbrant

@schoenbaechler I've made some tweaks to improve showing/hiding the keyboard when replying:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/1745876752

Nice work, this is a great improvement, these two are DONE ✅

• DB will look into the keyboard issue: it is currently not showing up after tapping 'REPLY' (it’s working in Suggested edits)
• Hide CC0 disclaimer when @mention dropdown is visible to save vertical screen estate

What’s the status on this one? 👇

• DB will look into moving the input field further up (and below the latest message) to have more space below for the @mention dropdown, see comparison below

Implementation
Design

The key difference between the two is: less movement and better orientation for users.

One more thing: hide the overflow menu after tapping 'REPLY' or 'NEW TOPIC' in both user and article talk pages (it’s not needed in create mode):

Thanks!

@schoenbaechler Please see the latest build, in which I hide the overflow menu while replying:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/1751406991

However, moving the input field further up to match the height of the user list will not be possible at this time.
An additional quick note about this:

Most of the time the user will have no intention or reason for @-tagging another user, especially since we're pre-populating the field with the parent username. Therefore, for the majority of the time, this would just be unnecessary and inexplicable empty space.

Ok, just checked the latest built @Dbrant — looks good!

One last thing since we’re already working on this view — would it be possible to add the talk page subject to the app bar title on scroll?

It will provide additional value/context, especially if the thread is long! The app bar title should only be be truncated with an ellipsis.

@schoenbaechler Done ->
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/1752966345

perfect, thanks @Dbrant — moving it to code review!

Working well for me on 2.7.50393-r-2022-02-07