Page MenuHomePhabricator

[AMC] Minerva talk tabs give confusing experience when they are red links
Closed, ResolvedPublic

Description

Currently the color of links in MinervaTalkAtTop tab in AMC mode is black. On other skins links look different. Non-existent pages are marked as darkish red. This helps users to identify whether the associated page exists or not. Minerva should have the same design.

Screenshots

Where the associated page doesn't exist

In Timeless skin, the tab looks like this

Screenshot_20191027-134202.png (480×960 px, 41 KB)

In vector
Screenshot_20191027-134353.png (480×960 px, 40 KB)

Where the associated page exists

In Timeless skin

Screenshot_20191027-135414.png (480×960 px, 36 KB)

In Vector
Screenshot_20191027-135536.png (480×960 px, 60 KB)

Current design in Minerva

Screenshot_20191027-140003.png (480×960 px, 44 KB)

QA Results - Beta

ACStatusDetails
1T236608#7487913

QA Results - Prod

ACStatusDetails
1T236608#7487916

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

What is the problem statement here? I know these things are different, but what problems does that cause?

What is the problem statement here? I know these things are different, but what problems does that cause?

I mean a red link indicates that the page doesn't exist. In current MinervaTalkAtTop tab, non-existent pages are not colorized. How one is supposed to see if an associated page doesn't exist without visiting the page first? If we colorize the links in the tab, it would save us the trouble to going to the associated page.

If the tabs were not red links (and didn't throw you into the editor) would they still be problematic?

I've always been unsure about throwing people into the editor unless they explicitly ask to edit.

Jdlrobson renamed this task from [AMC] Colorize MinervaTalkAtTop tab to [AMC] Minerva talk tabs give confusing experience when they are red links.Oct 30 2019, 3:35 PM

If the tabs were not red links (and didn't throw you into the editor) would they still be problematic?

I've always been unsure about throwing people into the editor unless they explicitly ask to edit.

No, not really. They are not problematic but it's kinda annoying to get automatically directed to the editor. I just want something to detect non-existent talk pages.

So it sounds like the red link acts as an indicator to tell you 1) if there are any topics and 2) let you engage in the talk page.

Yes. It also helps to detect orphaned talk pages (where the associated main page doesn't exist).

Agree that it's confusing and undesirable that you can't tell if the page exists or not. It adds to the confusion of newcomers, or if we want to show the link to everyone, but it also makes it more difficult to navigate even if you've been around for a long time and know Wikipedia well.

(To add to the discussion above, it is problematic that you can't tell and then you're thrown directly into the editor if you're not used to Wikipedia so you don't get what's going on, but currently that's mainly just a problem on Swedish Wikipedia, which has requested testing having the talk page tab to be visible to everyone, even though there are still things to work out.)

Well all I know is if on desktop, redlinks now looked the same as non-redlinks, there would be an uproar.

Sure, but this is not desktop. The mobile site only added talk recently (2 years ago as part of the Advanced Mobile Contributions project). Previously the feature wasn't available. This is a confusing experience, but this work hasn't been prioritized. More strategic work is being focused on right now which may address this in future - particularly with how we build menus in skins consistently.

Locally adding to the Minerva skin css is an option:

.minerva__tab.new,
.minerva__tab.new:visited {
	color: #dd3333;
}
LGoto subscribed.

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.

stjn removed a project: Web-Team-Backlog.
stjn subscribed.

Still a thing. A usual UX expectation (at least) for advanced editors.

cjming triaged this task as Medium priority.Aug 20 2021, 10:07 PM
cjming added a project: Web-Team-Backlog.

Change 731293 had a related patch set uploaded (by Inductiveload; author: Inductiveload):

[mediawiki/skins/MinervaNeue@master] Make missing links in tabs red like all other skins

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

Change 731293 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Make missing links in tabs red like all other skins

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

Jdlrobson subscribed.

On beta cluster. Move to sign off if this looks good.

for articles that exist this looks good:

Screen Shot 2021-10-21 at 1.28.09 PM.png (1×778 px, 107 KB)

when the article does not yet exist, I'm not sure if both tabs should be red. what do people think (cc @RHo)? the first tab (Article) is in its selected state, so maybe the black would make more sense? in Vector the Article tab is black even when the article does not exist.

Vector for reference:

Screen Shot 2021-10-21 at 1.27.53 PM.png (540×2 px, 153 KB)

current patchalternative
Screen Shot 2021-10-21 at 1.33.28 PM.png (1×780 px, 165 KB)
Screen Shot 2021-10-21 at 1.33.52 PM.png (1×772 px, 164 KB)
In T236608#7448973, @alexhollender wrote:

for articles that exist this looks good:

Screen Shot 2021-10-21 at 1.28.09 PM.png (1×778 px, 107 KB)

when the article does not yet exist, I'm not sure if both tabs should be red. what do people think (cc @RHo)? the first tab (Article) is in its selected state, so maybe the black would make more sense? in Vector the Article tab is black even when the article does not exist.

Vector for reference:

Screen Shot 2021-10-21 at 1.27.53 PM.png (540×2 px, 153 KB)

current patchalternative
Screen Shot 2021-10-21 at 1.33.28 PM.png (1×780 px, 165 KB)
Screen Shot 2021-10-21 at 1.33.52 PM.png (1×772 px, 164 KB)

hi @alexhollender - fwiw I tried this on enwiki at first and did get redlinks on both article and discussion – then realised after checking a couple more wikis that on legacy Vector it is both red links:

enwiki
image.png (498×2 px, 91 KB)
cswiki
image.png (308×1 px, 51 KB)
on frwiki New Vector
image.png (412×2 px, 84 KB)
on frwiki switched to Legacy Vector
image.png (322×1 px, 51 KB)

Given this, and since the ticket is about adding making the content page a red link to more clearly signal when it doesn't exist, it probably makes sense to have article as red link as well. And as an aside, Minerva should probably have a more overt way to signal how to create the new page here. I know it is to tap the edit pencil icon, but it would be better if it matched the Vector action copy to "Create" rather than "Edit", and potentially the icon might be changed to something else that better conveys "create new":

Current Minerva with edit label showing as "edit"
image.png (644×1 px, 110 KB)
Potential update to icon and label
image.png (370×1 px, 48 KB)

thanks for digging deeper there @RHo. @Jdlrobson looks like this task is good to go to QA. It seems like we should file a separate task to handle keeping the Article tab red in new vector for pages that haven't been created.

legacy vectornew vector
Screen Shot 2021-10-22 at 10.44.54 AM.png (298×1 px, 116 KB)
Screen Shot 2021-10-22 at 10.44.44 AM.png (306×1 px, 81 KB)

In this particular case, design review = QA IMO.

apologies for the confusion here, based on @Jdlrobson's comment we've decided that the selected tab (whether Article or Talk) should not be red.

current patchwhat we want
Screen Shot 2021-10-21 at 1.33.28 PM.png (1×780 px, 165 KB)
Screen Shot 2021-10-21 at 1.33.52 PM.png (1×772 px, 164 KB)

Change 734353 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Selected links should not be red.

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

Jdlrobson added a subscriber: Jdrewniak.

Change 734353 merged by jenkins-bot:

[mediawiki/core@master] Selected links should not be red.

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Selected tab should not be red. See T236608#7454856

Screen Shot 2021-11-07 at 6.54.43 AM.png (1×971 px, 333 KB)

Edtadros subscribed.

Test Result - Prod

Status: ✅ PASS
Environment: frwiki
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Selected tab should not be red. See T236608#7454856

Screen Shot 2021-11-07 at 6.59.01 AM.png (1×972 px, 337 KB)