IMO the absolutely ideal situation would be for one skin to be responsive
enough to work for desktop *and* mobile. I don't know if that's really
possible, but let's not dismiss the idea solely on the basis of "we need
something separate because we think it's too slow to develop that way".

I'm not sure that "getMobileUrl" is a good way to go. What is it used for,
and could we generate the correct URL in the first place instead of having
to do a transformation?

I can't look at all the referenced code on my phone right now to give an
opinion on how much cleanup it might need.

@Anomie agreed but there is definitely a case for some wikis to want completely separate desktop and web experiences - the beauty of this solution is it would give that choice (wgDefaultMobileSkin would default to whatever skin is the desktop choice).

Plenty of reading material on this subject:
https://www.google.co.uk/search?q=mobile%20site%20or%20responsive%20site&rct=j#q=mobile+site+or+responsive+site

http://www.smashingmagazine.com/2012/08/22/separate-mobile-website-vs-responsive-website-presidential-smackdown-edition/ is a great overview.

As a result we should support both.

In terms of your question about getMobileUrl - yes definitely. Let's support that in core. Essentially all it does is use a different base url. e.g. http://en.m.wikipedia.org rather than http://en.wikipedia.org

Appreciate your thoughts and look forward to a more detailed assessment :)

For those unfamiliar with the history of this issue: an earlier version of DeviceDetection already was in core, but wasn't integrated with anything else there and after some time of being used as a library for MobileFrontend, was pulled back. What do we need to do to prevent this from happening again? What is a threshold when deciding which component should be in core? Are these components generic enough to be used by anything but MobileFrontend?

@MaxSem I think having support for alternative mobile site with alternative skin delegation will give it the integration it needs.

e.g.

if ( isMobileDevice ) {
  $skin = getSkinForMobile() 
  if ( $alternativeMobileDomain ) {
    redirectTo( $alternativeMobileDomain );
  }
} else {
  $skin = defaultDesktopSkin()
}

With regard to having the mobile site be a separate URL, this is a practice we should not be encouraging. It's one site. Why complicate that, of all things, when all that's changed is the device?

A separate version of the skin with different layout and stuff is one thing, and a use case well worth supporting from what I've seen so far, but a separate url comes with a lot of baggage:

• It's confusing to users. You've probably seen how often m.wikipedia urls wind up in emails and stuff when all the sender wanted to do was share a page, just because they happened to be on their phone at the time. But no matter what device someone is on, the content is important, so users should really get whatever format presents the content best for their device in either direction. (Unless they explicitly override it or something.)

• It's complicated to set up and maintain. Separate urls require separate setup and maintenance and such, and require sending users to one or the other generally before they even hit the wiki itself. Even in general they invite more things to potentially go wrong simply due to extra complication.

• It can be really expensive. There are two ways to change urls: subdomains and folder paths. Since folder paths necessarily make both versions longer, subdomains are often more desirable. Unfortunately with SSL, adding a new subdomain can mean you need a new/much more expensive certificate, which is kind of not good.

• Probably other stuff. I dunno.

Many websites have two separate sites and we should allow that choice.

We are currently doing this now but it doesn't mean we can change our mind in future but choice and flexibility in open source is always a no brainer.

I'm also not a fan of the m. subdomain (or any similar scheme), but whatever we put into core should probably continue supporting that.

So if we have it… I'm wondering why we do the redirect to mobile on the desktop site when accessing it using a mobile user-agent, but we do not do a redirect to the desktop site from mobile when accessing it using a desktop user agent? It seems to me that this would be reasonable, and would mostly alleviate the first issue Isarra listed. (The visitor could still use the links to manually set and remember desktop/mobile site.)

If we can't effectively make one responsive site for whatever reason, we'll probably be forced to have different URLs in some manner because I doubt there's a request header to sanely vary caches on.

It does have problems, though; T100413: "You are centrally logged in." toast on every page view on commons for example, and I remember issues with OAuth too.

• DeviceDetection.php moved from MobileFrontend to core

This code doesn't seem bad, beyond the fact that user agent sniffing generally sucks.

I personally don't care for the IDeviceDetector interface that looks likely to only ever have a single implementation since it only gets to see the User-Agent and Accept headers.

• MobileContext::shouldDisplayMobileView moved to ContextSource

Conceptually probably ok, although IMO the use of it should be limited as much as possible to avoid feature divergence.

I almost wonder whether we shouldn't rename "mobile view" to something less single-purpose, and possibly split it up into component parts (e.g. "reduced bandwidth" mode, "small display" mode) if there are multiple parts.

As for the actual implementation, it seems to have some stuff that's not really in scope for the method name. Specifically, the call to redirectMobileEnabledPages() and the EnterMobileMode hook seem entirely out of place there.

• MobileContext::getMobileUrl moved to ContextSource

I still hate the idea of this method, and reiterate that it would be much better if stuff would just automagically generate the correct URL in the first place.

• contents of MobileFrontend hook onBeforePageRedirect moved into core

Seems straightforward enough, it seems the point is to just apply getMobileUrl() when needed. Although I'm not clear on why you're varying on those two headers there and not more generally.

But see my comment just above about getMobileUrl() in general, this shouldn't be needed.

• When creating a skin instead of using $wgDefaultSkin, when in mobile mode it should be possible to load from $wgDefaultMobileSkin

Seems ok, if we're having to vary caches already.

In T100402#1318012, @Anomie wrote:

If we can't effectively make one responsive site for whatever reason, we'll probably be forced to have different URLs in some manner because I doubt there's a request header to sanely vary caches on.

Actually, we already have everything technically needed (including the headers to vary on) for moving the mobile site to the same domain, excpet for WP zero woes: it is far easier for carriers to zero-rate traffic when there's a mobile IP distinct from desktop. They could still sniff the host from unencrypted HTTP traffic, however we're pushing for HTTPS these days.

I personally don't care for the IDeviceDetector interface that looks likely to only ever have a single implementation since it only gets to see the User-Agent and Accept headers.

An interface made more sense earlier, when DeviceDetection had detected more things besides mobile/desktop/tablet.

• MobileContext::shouldDisplayMobileView moved to ContextSource

Conceptually probably ok, although IMO the use of it should be limited as much as possible to avoid feature divergence.

I almost wonder whether we shouldn't rename "mobile view" to something less single-purpose, and possibly split it up into component parts (e.g. "reduced bandwidth" mode, "small display" mode) if there are multiple parts.

An issue here is that MobieFrontend programming requires remembering and understanding a few concepts like when to use getMobileUrl() etc - when exposed to general MW developers' population, the result might be more bugs.

• MobileContext::getMobileUrl moved to ContextSource

I still hate the idea of this method, and reiterate that it would be much better if stuff would just automagically generate the correct URL in the first place.

Improvement suggestions are welcome.

I would definitely favor killing the m domain. It's confusing and causes lots of bugs and headaches.

@MaxSem: What is the header to vary on?

@dr0ptp4kt Is there any chance that Wikipedia Zero could eventually migrate to a non-domain specific system? Would that be a deal-breaker for carriers?

In T100402#1336294, @kaldari wrote:

@MaxSem: What is the header to vary on?

X-CS.

@kaldari, @MaxSem : I've added @DFoy, @Yurik, and @jhobs to the card.

From what I understand, zero-rating by and large wouldn't be negatively impacted because most operators now use destination IP address-based zero-rating. But code would have to be introduced to ensure that Wikipedia Zero banners actually show, external link taps are intercepted to warn users of potential charges, etc.

In T100402#1336312, @MaxSem wrote:

In T100402#1336294, @kaldari wrote:

@MaxSem: What is the header to vary on?

X-CS.

Is that sent by anything besides our mobile apps? I'm not seeing it being sent from my phone with Firefox or Chrome, for example.

In T100402#1337482, @Anomie wrote:

In T100402#1336312, @MaxSem wrote:

In T100402#1336294, @kaldari wrote:

@MaxSem: What is the header to vary on?

X-CS.

Is that sent by anything besides our mobile apps? I'm not seeing it being sent from my phone with Firefox or Chrome, for example.

X-CS tagging is done at the Varnish edge:

https://git.wikimedia.org/blob/operations%2Fpuppet.git/a48158687618962b27eebe9633d69127e47b8537/templates%2Fvarnish%2Fmobile-frontend.inc.vcl.erb

https://git.wikimedia.org/blob/operations%2Fpuppet.git/a48158687618962b27eebe9633d69127e47b8537/templates%2Fvarnish%2Fzero.inc.vcl.erb

In T100402#1337553, @dr0ptp4kt wrote:

In T100402#1337482, @Anomie wrote:

In T100402#1336312, @MaxSem wrote:

In T100402#1336294, @kaldari wrote:

@MaxSem: What is the header to vary on?

X-CS.

Is that sent by anything besides our mobile apps? I'm not seeing it being sent from my phone with Firefox or Chrome, for example.

X-CS tagging is done at the Varnish edge:

https://git.wikimedia.org/blob/operations%2Fpuppet.git/a48158687618962b27eebe9633d69127e47b8537/templates%2Fvarnish%2Fmobile-frontend.inc.vcl.erb

https://git.wikimedia.org/blob/operations%2Fpuppet.git/a48158687618962b27eebe9633d69127e47b8537/templates%2Fvarnish%2Fzero.inc.vcl.erb

So it's not actually useful for varying caches in the general mobile-website case, only if someone is using varnish with our vcl rules.

If we implement this, we also need to make sure desktop users are redirected from the mobile to the desktop site.

Simply noting that if we were to do this, it would be ideal for device detection to be based on CSS selectors. Google and others use CSS selectors, provided as the media attribute of a <link rel="alternate"> tag, to decide whether to direct users to the desktop or mobile version of a site when they're served from different URLs.

This won't work for HTTP caching.

Having a separate mobile site is also bad when someone from a mobile device shares a link to a desktop user.

I resolved the issue at varnish level, detecting mobile device at varnish and redirecting the user appending the ?mobileaction=toggle_view_mobile parameter to the URL, without switching domains. Then, with JavaScript, I change the displayed URL removing that parameter. Users can now share a consistent URL between different devices and everyone gets the right skin, while Varnish can cache both URLs, and both get purged with a single PURGE request :) (actually, I have a more complicated rule to handle also the mobile cookies and strip them for caching)

Regardless of the issue of removing the .m. subdomain, would anyone object to us doing the first step of this task: "DeviceDetection.php moved from MobileFrontend to core". It used to be in core and that's really where it belongs. All skins (especially non-WMF skins) should have easy access to this data regardless of whether they are running MobileFrontend or not. Also the WikiEditor extension needs this data for proper eventlogging (T249944).

We seem to have something of a chicken and egg problem. Our features aren't responsive because all the mobile stuff is walled off into MobileFrontend, and the reason we have it all walled off into MobileFrontend is because nothing else uses it. We know that this is the future though, so let's move some of this utility code into core and leave it there.