It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

@Isarra, do you have any established ideas regarding this?

In T97968#1305425, @FreedomFighterSparrow wrote:

@Isarra, do you have any established ideas regarding this?

What's an established idea?

Truthfully? a too-fancy way of saying "*any* ideas you've already came up
with?".

I suppose what I'd really like to do is get interested folks to sit down
and discuss it. I don't know what would actually work in practice, for
mobilefrontent and other skins, for the various different extensions,
developers, interest groups...

But I don't really know how to do that. I'm not even sure I'd be the
right one to do that.

As is, my ideas are mostly just have resourceloader assemble different
files depending on screen types - developers label the files in the
modules or something as 'mobile' or 'desktop' or whatever? I dunno if
that would actually work, though.

Well, I'm willing. Any other takers here?

ResourceLoader already "'targets' => array( 'desktop', 'mobile' )", for the
use of MobileFrontend. So that piece of code can be ripped out of
MobileFrontend as-is, I guess.

I mostly tend to build extensions, as core is... shall we say, hard to
change? I was thinking of building an extension part-MobileDetect
<Extension:MobileDetect> and part-MobileFrontend - that is, take MF, rip
out everything to do with with transforming the article itself, and leave
the parts that have to do with detection and resourceloader - and then add
functionality to allow skins additional customization by using stuff like
"isMobile", "isAndroid", or whatever.

One of the main things we want to do, here, is get this stuff out of
extensions. MobileFrontend should be in core. Minerva, the skin it
happens to bundle, should simply be a skin primarily aimed at mobile
(though it works rather nicely on desktop, too, especially for some things).

We need to make it easier for all skins, somehow. That probably means
moving the MF stuff into core in some fashion, but it would also
probably mean some way to also specify a mobile skin instead of having a
skin scale to mobile? Just switch skins at that point, perhaps? Or not?

Because the way MF works currently, it's its own skin. It doesn't even
do the detecting whether it's mobile or desktop itself - that happens
before it ever loads, because how could the skin do that reliably, really?

Actually I'm not entirely sure how it works - I think it just expects
the front-end cache to forward the mobile stuff to it some other way.
Apparently wikimedia uses m.wikipedia subdomains and the like for that,
but that seems a bit hacky. Also doesn't scale well for smaller projects
and the like. Why should random third-party user N need to set up
varnish just to have a proper mobile experience when they only even have
one server in the first place?

Would a pure js solution work for the detection/flipping styles stuff?
It's bad for browsers, but would it maybe work for mobile? I have no idea.

Well, I, uh, added a thingy to the schedule so we can totally discuss this and maybe figure things out. Yes.

Cool. See you there :-)

I can come along and provide some insights from MobileFrontend

Yay!

$wgMFDefaultSkinClass = 'SkinVector';

So, is this a fair summary of our discussion?

1. Slightly improve the documentation to explain how to create responsive skins
2. Do mobile detection at the core level:
   1. see if the request already has a mobile header (e.g. X-DEVICE), which would probably happen if someone set up detection at the cache (varnish) level.
   2. (if not) Check for Apache Mobile Filter (AMF) and use that if it's installed
   3. (if n/a) Use a 3rd party library for user-agent detection (e.g. https://github.com/serbanghita/Mobile-Detect, which also has a Varnish version)
3. Have a configuration switch based on (1) to select a different mobile skin (a-la MobileFrontend's $wgMFDefaultSkinClass?)
4. Based on (1), load RL modules with according to targets (mobile/desktop), same as mobilefronted does
5. Have a function isMobile() for use by skins in PHP.

Aye, looks like. Some of this is a lot simpler than the rest - documentation is a long-standing issue, for instance, which is probably a large part of why I had to ask things in the first place - but I don't even know what's smaller.

There's also a lot of it done on some level either in or for MF, which is definitely a good start. As more progress is made there, it should help?

Aside from just cleaning up the ungodly mess that is the relevant chunk of bug 1, I think the main thing we can do from here is just submit patches and try to get things into core/whatever and make sure Jon/whoever actually sees...

@Fiona: MF will yet get its globally-relevant bits merged into core.

This may be a bit of a tangent, but how many chunks does MF logically have? Skin, wikipedia hacks, and some general mobile support and dealies? Or is it just the first two these days?

Somewhat related - you guys reminded me how annoying the skins system is.
I created a working prototype for a re-imagined and simplified sub-skin system that hopefully lowers the barrier to entry:
https://github.com/jdlrobson/SimpleSkins

It makes skin creation super easy for anyone who wants to build one.
Feel free to play around with it, make skins using it, fork it etc..

We should totally file bugs for each thing mentioned in T97968#1310011.

I've made an actionable bug T97968
Personally I think this is all that is needed to support core development.

I'm on the fence about having an isMobile function on the skin itself as I think we need to make skins that either do both (and are careful about the consequences) or decide to be a mobile only skin or desktop only skin.
I think once T97968 is completed we'll be able to work out all the rest

That should have been T100402, probably pasted the wrong one.

And yeah, that makes sense. Whoo!