Page MenuHomePhabricator

[SPIKE] When a user clicks view message for Commons notifications, investigate if it's possible to go directly to "Read as Wiki page" in webview
Open, MediumPublic

Description

Background
During user testing for Talk Pages, it was discovered that when a user clicks on their Commons talk page notifications they do not see their talk page message based on the default workflow, and they are bounced out of the app.

The Task
Send users to the "Read as Wiki page" link and keep the user in webview

Testing Instructions:

  • Check that it opens to the notification for new topics and replies

Reference:
Slide 14

Event Timeline

JTannerWMF triaged this task as Medium priority.Nov 15 2021, 3:59 PM
JTannerWMF created this task.
JTannerWMF updated the task description. (Show Details)
Dbrant renamed this task from When a user clicks view message for Commons notifications, take them to "Read as Wiki page" in webview to [SPIKE] When a user clicks view message for Commons notifications, investigate if it's possible to go directly to "Read as Wiki page" in webview.Nov 16 2021, 7:35 PM

@JTannerWMF @schoenbaechler

Currently when the user has a commons talk page message it takes them to their talk page, but not the exact section. Somethings like this:

now.png (2×1 px, 127 KB)

The talk page message in this case was for the second discussion [whose link is now purple(visited)]

However, the notification is actually giving us information to go to that discussion itself directly and open it like this:

then.png (2×1 px, 220 KB)

The reason it is currently failing to open the section is because of url encoding issue. We can update a quick fix to take the user to the discussion section directly as part of this spike, and if you want this to happen within the app, we can have a separate task to figure out all the cases where we can open a ChromeTab within the app, versus going out. You can test it out by building this apk: https://github.com/wikimedia/apps-android-wikipedia/pull/2994/checks
Please let me know your thoughts.

@schoenbaechler Moving this back to Doing.. the above solution is not optimal as we discussed in Engineering sync today :)

Hi @Jdlrobson

We are encountering a small issue when we open a mobile web page from the app.
When trying to access a talk page on commons, https://commons.m.wikimedia.org/wiki/User_talk:SHaran_(WMF)#File:Android_Espresso_Testing_Device_Configuration.png,
the top message/ welcome message is always hidden like so:

talk.png (2×1 px, 127 KB)

But when we click on "Read as wiki page" it becomes visible again.

When I inspected the page, I found that you are using a class in the body tag which is hiding the top message

<body skin-minerva--talk-simplified>

Would it be possible to either remove this and expose the top message or let us know a workaround. Also, we are opening this url in an external browser, so we cannot do any js injection..

You should talk to the editing team. The editing team are actively working on updating this page (T278588) and are currently its maintainers and the feature is frozen from our perspective until that happens. T291893 describes exactly your problem as far as I can see?

Would it be possible to either remove this and expose the top message or let us know a workaround. Also, we are opening this url in an external browser, so we cannot do any js injection..

I don't think we have any workaround here sadly. The "read as wiki" button is mostly aimed at power users. The content is hidden because it doesn't look great on a mobile phone. A lot of messages are also hidden erroneously due to T202919 and various anchors are not working. See T278590 for a list of all the bugs we are aware of.

One thing you could do if you need a short term fix is link to the desktop site with Minerva e.g. https://commons.wikimedia.org/wiki/User_talk:SHaran_(WMF)?useskin=minerva#File:Android_Espresso_Testing_Device_Configuration.png
(note the useskin property and lack of m. domain)

The Editing team shared in a sync that there work on mobile should address the Overlay that causes this problem, so I will move this to the backlog for now. We should revisit in Q4.