@gonyeahialam Do we know if the modal experience that is in the wireframes has been used by any other teams in the past? Or is it totally new?

Discussed in Slack: the modal is a modified version of the indexed dialog (tabbed navigation) on OOUI https://doc.wikimedia.org/oojs-ui/master/demos/?page=dialogs&theme=wikimediaui&direction=ltr&platform=desktop#MessageWidget-type-notice

This means that there's no pre-made signup/login dialog.

Note: I think it makes sense to test the login/sign-up method via Campaigns extension user flow for the second round of usability testing, @gonyeahialam & @CKMIE89. We can use the insights from comparing the modal flow (from first round) vs. the campaigns extension flow (from second round) combined with engineering input (after this investigation is completed) to decide what is appropriate for MVP.

This means that this ticket is still a valid engineering investigation, but I don't believe that usability tests should be blocked. Thanks!

Hi @Tgr , would you be able to lend some expertise around authentication (reaching out per https://www.mediawiki.org/wiki/Developers/Maintainers)?

As part of our project to build an on-wiki event registration tool we are exploring ways to meet this requirement: If logged-out user clicks "Register," a pop-up will appear that prompts them to login/create account.

Our UX Designer @gonyeahialam designed a modal for this using the indexed dialog (tabbed navigation) on OOUI.
Do you know whether using this pop-up/modal approach would be possible with our authentication code (I believe we're talking about AuthManager)?

I'll let @Daimona fill in any details that I missed. Let me know if a quick meeting would be helpful here.

If you are working with an external tool using OAuth login, you don't have any control over the registration flow - users will be sent to the normal login page (which links to the signup page) if they are not logged into Wikipedia, and after a successful authentication or account creation they will be redirected to the OAuth authorization dialog. (WikiEdu uses this and might be able to provide insights into usability aspects.)

If you are working with a MediaWiki extension, you can provide your own interface and rely on the action=clientlogin and action=createaccount APIs to integrate it with AuthManager, but it's trickier than it sounds and I would recommend against it - other extensions can (and do) make a wide range of changes to the login form, and your extension would either have to account for those or accept that various edge cases will be broken. The Wikimedia mobile apps have followed this route.

Alternatively, you could try to display the normal login page in a popup. (T71596: Provide JavaScript login widget) This would require core changes, or maybe a custom skin, to restyle the special page, but doesn't seem particularly complicated. You won't have much control over what fields the login form has, though, as other extenions can modify that. This is the approach taken by the mobile web page (MinervaNeue skin) - it doesn't use a popup but the page is customized to better fit to a smartphone screen.
(Note that showing the login and signup form in the same HTML page will probably be nontrivial - these pages are generated pretty deep in the framework.)

You can also just redirect the user to the login or signup form and use the returnto / returntoquery URL parameters to make sure the user returns after a successful account creation. That does not use a popup but from a user workflow POV isn't that different.

Hi @Tgr, thanks for the information! In short, we're currently planning to do that in a MW extension, and I had the same concern that you mentioned: I feared that making it work with custom login/signup fields (which are pretty common) could turn out to be very hard. My proposal was also to use returnto/returntoquery, as well as something which allows you to add some custom message to the special page (I know that GrowthExperiments does that, although I was looking for some prettier solution like a hook that allows extensions to properly inject HTML on the page).

In T300748#7692404, @Daimona wrote:

I know that GrowthExperiments does that, although I was looking for some prettier solution like a hook that allows extensions to properly inject HTML on the page

We needed to do that with a very short deadline; wanted to turn it into a hook eventually (or maybe expose the HTML content to AuthChangeFormFields) but haven't gotten around to it so far.

I think the trickiest part there will be figuring out what are the exact parts extension might want to manipulate (e.g. we switch the order of the benefit block and the form on mobile - by default it's below the form and users are unlikely to even see it.) Probably should have its own task.

In T300748#7694597, @Tgr wrote:

In T300748#7692404, @Daimona wrote:

I know that GrowthExperiments does that, although I was looking for some prettier solution like a hook that allows extensions to properly inject HTML on the page

We needed to do that with a very short deadline; wanted to turn it into a hook eventually (or maybe expose the HTML content to AuthChangeFormFields) but haven't gotten around to it so far.

Oh, but that's fine :) I was just saying that there cannot be two extensions both replacing the SpecialPage class, hence I wanted some stable solution that GE could also benefit from.

I think the trickiest part there will be figuring out what are the exact parts extension might want to manipulate (e.g. we switch the order of the benefit block and the form on mobile - by default it's below the form and users are unlikely to even see it.) Probably should have its own task.

Indeed... And I assume it would also reduce the customization capabilities -- you probably don't want to inject some complicated HTML in there when other extensions may add more stuff above or below yours. But yeah, it definitely deserves its own task -- I guess I'll create one as soon as the team will discuss this issue together.

Hello @cmelo & @JCarvalho: Can you take a look at the comments shared above and add any feedback? Then, we can move this ticket to product sign-off for me to review. Thank you in advance!