Page MenuHomePhabricator

Step 1: Error messages: user is logged out but can continue editing as IP or log in (on save)
Closed, ResolvedPublic13 Estimated Story Points

Description

Problem:
A user might be logged out after the Bridge was loaded. We want to give them the option to save their edit anyway under an IP.

Screenshots/mockups:

Desktop

IPwarning_save.png (976×1 px, 46 KB)

Mobile

IPwarning_save_mobile.png (1×750 px, 57 KB)

button spanning two lines (very unlikely with new button width but keeping it in here just in case)

twoLineButton.png (488×500 px, 26 KB)

Notice banner on log-in page (after the user clicks "Log in (opens in a new tab)")
banner is going to be as wide as the text input fields on the page
desktop (this is the correct copy):

notice on login page.png (670×351 px, 30 KB)

mobile (just a screenshot to show the different widths):
image.png (771×726 px, 53 KB)

Please find final design specs in this Figma artboard.

BDD
GIVEN a Bridge edit
AND the user gets logged out after the Bridge has been loaded
WHEN Trying to save the edit
THEN the user is presented with an error screen
AND is given the option to save their edit anonymously

GIVEN an IP save error
WHEN the user clicks "Save without logging in"
THEN the edit is saved

GIVEN an IP save error
WHEN the user clicks "log in"
THEN the log-in page is opened in a new tab with a notice banner
AND the Bridge returns to the state before save was clicked

GIVEN an IP save error
WHEN the user clicks "go back"
THEN the Bridge returns to the state before save was clicked

Acceptance criteria:

  • error message is shown when assertuser fails
  • if user selects save without logging in, the second save is performed without assertuser
  • go back button is only shown on desktop and styled as a link
  • back arrow is shown on mobile to get back to previous screen
  • save vs. publish should be used on the button according to usePublish configuration of the wiki

Notes:

  • This is only supposed to happen if the first assertuser ended up saying that the user was actually logged out as opposed to having logged in under a different account.
  • The desktop version shows a "Go back" link that takes users back to the editor. In the mobile version, that go back action has to be performed by using the back navigation button in the header
  • Notification about contributing on another project is shown before this screen is shown.
  • Desktop to mobile button transition behaviour - Button width is always 100%. 24px horizontal margins are applied to the buttons div on desktop (above 499px break point) and removed on mobile (from 499px on). Vertical spacing between buttons increased from 8 to 16 px on mobile.
  • the notice banner is responsive to the width of the input fields of the log-in interface
  • If the user logges in under a different user name than they were previously logged in with, then they will end up in the generic error screen

Event Timeline

darthmon_wmde renamed this task from Error messages: logged out but continue editing as IP - on save. solvable. log in (5.1) to Step 1 :Error messages: logged out but continue editing as IP - on save. solvable. log in (5.1).Mar 18 2020, 4:27 PM
darthmon_wmde renamed this task from Step 1 :Error messages: logged out but continue editing as IP - on save. solvable. log in (5.1) to Step 1: Error messages: logged out but continue editing as IP - on save. solvable. log in (5.1).
Charlie_WMDE updated the task description. (Show Details)
Sarai-WMDE renamed this task from Step 1: Error messages: logged out but continue editing as IP - on save. solvable. log in (5.1) to Step 1: Error messages: user is logged out but can continue editing as IP or log in (on save).Mar 19 2020, 2:12 PM
Sarai-WMDE updated the task description. (Show Details)
Sarai-WMDE updated the task description. (Show Details)

Some suggested copy changes to the mocks related to this story too. Changes must be agreed upon:

Warning_generic_3actions_A.png (488×500 px, 19 KB)

What changed:

  • Rephrased the sentence "You can save your changes as an anonymous user", by a less inaccurate "You can save your changes without logging in"
  • The button copy changed from "Save without logging in" to "Save as IP user", to be more communicative of the compromise that users will be making.

Note: These copy changes also impact story T244360

Please share your thoughts!

I think in MediaWiki, “user” is often used as a shorthand for “registered user”, so I feel like “IP user” might be confusing… I don’t have any better suggestion, though.

I’m also worried about the “Log in (Opens in a new tab)” button label – I’m afraid that some translations of it will be long enough that they don’t fit into the button anymore.

In the story writing the question came up: "how can we, upon sending the user to the login page in a new tab, communicate to them to close the tab and return to bridge after login?".

Option 1: to show a message to the user on the login page (above the username & password fields), we could use the warning parameter, e.g.
https://en.wikipedia.org/w/index.php?title=Special:UserLogin&warning=mobile-frontend-watchlist-purpose (message keys which are applicable can be manipulated via the LoginFormValidErrorMessages hook)

I did not find a built-in way to show a message on the default login success page (LoginSignupSpecialPage::showSuccessPage()) short of using the UserLoginComplete hook to (conditionally?) manipulate $injected_html - which feels rather iffy.

Option 2: to show a message after successful login is to create a dedicated page for this purpose and use it as the returnto parameter of the login, e.g.
https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Special:BridgeWaitingForYou

Option 1 is rather simple to implement but is not ideally placed in the user journey. Option 2 appears in the right moment and offers more possibilities, but comes at the price of maintaining the weird landing page.

Hello! Thank you for bringing up these points.

I think in MediaWiki, “user” is often used as a shorthand for “registered user”, so I feel like “IP user” might be confusing… I don’t have any better suggestion, though.

we changed it back to the old copy

I’m also worried about the “Log in (Opens in a new tab)” button label – I’m afraid that some translations of it will be long enough that they don’t fit into the button anymore.

i have added a mock to the ticket and figma board of how it'll look when the button spans two lines.
quick question regarding this: would it be possible to separate the two copy parts somehow? part 1: log in part 2: (opens in a new tab)
in such a way that when the line break happens, the break would preferably happen between the two parts, instead of before the first word that is too long for the first line. Do you know what i mean?

Splitting the message into two parts would be possible, and I think it would be acceptable as well, though it goes a little bit in the direction of a “lego message”. I’m not sure how much influence we have over the line breaking, though – unless we completely disable line breaks in the “opens in a new tab” part?

In the story writing the question came up: "how can we, upon sending the user to the login page in a new tab, communicate to them to close the tab and return to bridge after login?".

Story writing note: we’ll go with option 1 for now.

Option 1: to show a message to the user on the login page (above the username & password fields), we could use the warning parameter, e.g.
https://en.wikipedia.org/w/index.php?title=Special:UserLogin&warning=mobile-frontend-watchlist-purpose (message keys which are applicable can be manipulated via the LoginFormValidErrorMessages hook)

I'm confused about the role of Go Back/Keep editing button(or link).
The task says:

GIVEN an IP save error
WHEN the user clicks "go back"
THEN the Bridge returns to the state before save was clicked

The AC says:

go back button is only shown on desktop and styled as a link
back arrow is shown on mobile to get back to previous screen

The Notes say:

The desktop version shows a "Go back" link that takes users back to the editor. In the mobile version, that go back action has to be performed by using the back navigation button in the header

The Figma designs suggest it's called "Keep editing".

Q1: Does Product and/or Design refer to the desktop "Go back"/"Keep editing" as a link or as a button?
Q2: Does that button/link go back to bridge's previous screen or does it close bridge and go back to the Visual Editor?
cc @Lydia_Pintscher @Charlie_WMDE @SaraiSan

Sorry about the confusion! We renamed the link text to say "Keep editing" but forgot to change it in the ticket :(

A1: I guess we referred to it as whatever. But have no agreed that it should be a quiet button
A2: it goes back to the bridge's previous screen

sorry about that again

Change 596167 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] ErrorSavingAssertUser: consistently space buttons

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

Change 596184 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/Wikibase@master] bridge: Make proceed button use save or publish text

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

Change 596167 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] ErrorSavingAssertUser: consistently space buttons

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

Change 596184 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: Make proceed button use save or publish text

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

Charlie_WMDE claimed this task.
Charlie_WMDE moved this task from Verification to Done on the Wikidata-Bridge-Sprint-20 board.

awesome \o/