Last modified: 2013-04-22 16:16:09 UTC
Created attachment 11537 [details] Landing page post-signup on mobile The E3 team is running an experiment post account creation, serving users a custom post-signup page with some suggested tasks. See: https://en.wikipedia.org/wiki/Special:GettingStarted This is also being served to mobile account creators; however, the CSS doesn't render on mobile (see attached screenshot), and the tasks aren't really suited to current mobile contribution workflows, anyway -- can we hide the task list/suggestions and just show the necessary CentralAuth SUL stuff for now?
I tested this four times in the iOS simulator, twice on iPad and twice on iPhone, and got different results each time. Sometimes I was redirected to the contents of Special:GettingStarted minus CSS, and other times I got the MediaWiki default. I'll attach screenshots of both, but regardless, serving any form of the desktop onboarding experience is probably a bad idea. Even with the correct presentation, asking mobile users to edit immediately at this stage is probably not the best notion.
Created attachment 11538 [details] iOS 6.0 simulator view with Special:GettingStarted
Created attachment 11539 [details] Same iOS simulator, two minutes later
Probably what is needed is a hook that extensions can hook into to disable them on mobile. This would require a change in whatever creates Special:GettingStarted as well. To render the CSS ResourceLoader is needed. There's a bug for that - bug 41340
Adding Matt and S. If the way to avoid serving this to MobileFrontEnd needs to be a change within Extension:GettingStarted, we'll add it to our backlog and change the component too. It would help us prioritize if it was clear what the timeline there was, if any, for moving account creation out of beta.
For the time being... adding a class 'nomobile' to any html element should remove it from the mobile view.
Steven, did you log out before retesting? That could potentially explain the issue (haven't checked the code). Is there a global variable that indicates whether it's mobile? The hook we're using is https://www.mediawiki.org/wiki/Manual:Hooks/BeforeWelcomeCreation , which does not have a parameter for this. We could use nomobile, but that's a hack. It would be better not to serve the HTML at all.
Is that content being served using the same hook that CentralAuth uses to display its stuff (hook UserLoginComplete, I believe)? If so, I can think of a way to hack around it - although I'm not sure it's any less pretty than adding nomobile class to the content container. To answer Matt's question, no there's no global variable that indicates this per se, but there is some MobileFrontend magic you can hook into to determine whether or not the mobile view should be getting displayed. Something like: if ( class_exists( 'MobileContext' ) ){ $context = MobileContext::singleton(); if ( $context->shouldDisplayMobileView() ) { //don't display content } } Someday this kind of functionality will be built into MW core, but until then, this is probably the easiest/cleanest thing to do.
Special:GettingStarted is supplying its own welcomecreation message <http://en.wikipedia.org/wiki/Special:AllMessages?prefix=gettingstarted-msg> in place of the default <http://en.wikipedia.org/wiki/Special:AllMessages?prefix=welcomecreation-msg>, but it seems the CSS and JS it supplies are not loaded on mobile. MobileFrontend should probably supply its own "Welcome to our world!" messaging, but I don't know what happens if two extensions both respond to the BeforeWelcomeCreation hook. So either way I think Special:GettingStarted needs to step aside using the code in comment #8. (In reply to comment #1) > I tested this four times in the iOS simulator, twice on iPad and twice on > iPhone, and got different results each time. I suspect sometimes you were logged in and thus creating a new account for someone else, since the message you see is from that case <http://en.wikipedia.org/wiki/Special:AllMessages?prefix=accountcreatedtext>. You're supposed to get a different presentation with a Reason field and a mandatory e-mail address in that situation, maybe there's a bug in the mobile version of account creation.
Arthur, no, we're not using that hook, we're using https://www.mediawiki.org/wiki/Manual:Hooks/BeforeWelcomeCreation . The other hooks run normally, which is part of why we chose this approach. As S said, that is specifically for changing the message displayed, which is exactly what we're doing. If both respond, the second hook registered will win. Is MobileFrontend using BeforeWelcomeCreation, or do they use the default message, or do they short-circuit somewhere? That context code isn't actually too bad, and we can use it now. The main small downside is that shouldDisplayMobileView doesn't seem to be cached (bug 43280). It may or may not be realistic to put in core, since multiple extensions are going to have different approaches to mobile.
I reassigned it to GettingStarted, since I agree with S that the fix is on our side.
> I suspect sometimes you were logged in and thus creating a new account for > someone else Yes, I think that must be it. I'll try and look in the logs on-wiki, since that is shown there.
https://gerrit.wikimedia.org/r/#/c/39715/
(In reply to comment #13) > https://gerrit.wikimedia.org/r/#/c/39715/ Merged by Ori on the 21st. Is this bug resolved fixed now?
Yes.
