Page MenuHomePhabricator

Communicate that the page is protected
Closed, InvalidPublic

Assigned To
None
Authored By
Pginer-WMF
Jan 9 2019, 11:12 AM
Referenced Files
F28408956: image.png
Mar 18 2019, 11:00 AM
F28144481: Protected-page.png
Feb 7 2019, 12:56 PM
F28145710: Protected mobile.png
Feb 7 2019, 12:56 PM

Description

When presenting the ways to contribute for an externally-translated page (T212300), options to edit the original/local page are surfaced. However, these pages may be protected.

Protected pages prevent users from editing them if they lack the necessary user rights ( autoconfirmed users, extended confirmed users, or administrators, depending on the type of protection). This makes it hard to anticipate whether the user will be able to edit the page, or what to do to be able to (e.g. log-in may work if you have the needed rights). In this context, we want to keep the contribution points visible for users, but inform users when they reach their destination, to explain the unmet expectations (i.e., reaching the reading mode instead of the editing one).

Currently, protected pages are signaled with an icon and they have additional information about the protected state in their title attribute (which is shown as a tooltip when hovering on desktop).

When the user lands in the page that cannot be edited, we want to surface the protected message. The proposed solution is to:

  • On desktop, show a tooltip from the protected icon showing the description message more prominently for a few seconds.
  • On mobile, shown the "toast" notification that is currently shown when the user taps the protected pencil icon. The notification will be shown automatically after the page loads without the user taping the icon.
DesktopMobile
Protected-page.png (768×1 px, 548 KB)
Protected mobile.png (726×381 px, 251 KB)

Event Timeline

Pginer-WMF renamed this task from Communicate that the source page is protected to Communicate that the page is protected.Jan 9 2019, 11:12 AM
Pginer-WMF triaged this task as Medium priority.Feb 12 2019, 9:37 AM
Pginer-WMF removed a project: Design.

This task has two parts

  1. In an EG context detected, do an additional check to see if article is protected or not and abort any extra customization
  2. Instead of aborting, start a customization that just convey the protected status prominently.

I understand #1 and how it relate to EG,

Can you explain

  1. why you think #2 should be part of EG instead of general page display mechanism? Why you think that a page under google translate(example) need to convey this protected status while it is not conveyed in usual page renderings?
  2. Are we are assuming that the user has more intention to contribute in EG context than the general Wikipedia page reading context?

This task has two parts

  1. In an EG context detected, do an additional check to see if article is protected or not and abort any extra customization

No check was proposed in the EG context, because I think it is not possible to get relevant info out of it:

  • In an external translation service we don't know if you will be able to edit the page. Even if the page is protected, you can log-in and be able to edit it (depending on your rights), but from the EG context we don't have visibility on your user account.
  • The fact that the source article (that we show translated) is protected (or not), does not imply that the local article will be also protected (or not).
  1. Instead of aborting, start a customization that just convey the protected status prominently.

I understand #1 and how it relate to EG,

Can you explain

  1. why you think #2 should be part of EG instead of general page display mechanism? Why you think that a page under google translate(example) need to convey this protected status while it is not conveyed in usual page renderings?

It is about broken expectations. In EG we tell you "click here to edit" but when you land in the destination you are not in editing mode, and a clarification may help you to get re-oriented. It is not the same to access a page than access that page with the intention to edit (and not being able to do so).

  1. Are we are assuming that the user has more intention to contribute in EG context than the general Wikipedia page reading context?

No. I think that they would have the same or less (because of the complexity of the context). But those following a path to contribute will be surprised/disoriented to not being able to do so when landing to a protected article.

ok, So, what you meant is, "Showing this extra information about protected pages" when users come from an external context to edit a protected page.

When the user lands in the page that cannot be edited, we want to surface the protected message. The proposed solution is to:

But the screenshots are confusing. When a user comes to edit a protected page, this is what they will see. Why are you using the article reading mode as the landing page from external guidance?

image.png (339×829 px, 41 KB)

Users leading to a protected page with the intent to edit already have explicit indicators of the protected status (in view source mode) or the semi-protected one (in edit mode).