I have made a patch for a responsive version of MonoBook with mobile support. See: https://gerrit.wikimedia.org/r/c/421199/ or if you just want a live demo, https://wiki.zaori.org/wiki/Page_title?useskin=monobook - load it on a phone or make your browser window narrow or something and you can see what it looks like. This is a prototype nojs version; I intend to make an even sillier js layout with popovers and stuff as a followup patch.
A potential issue has already been raised with the icons: I don't really know how to make text strings actually, well, reliably fit on mobile devices, but a lack of support for no-image usage could also be a real problem in MonoBook. Feedback on that or whatever, as well as other testing and reviews, would be greatly appreciated.
There is also a rather more immediate problem at present. As you can see on the patch, jenkins has -1ed it for style problems. Unfortunately I have no idea what the style problems are because the output of that test is totally useless (https://phabricator.wikimedia.org/T190072) - can anyone tell me what the problem(s) are so I can fix them? And/or just resolve T190072? Please? It's starting to get a bit annoying, frankly, as it's been coming up across several of these patches.
-I
2018-04-02 6:13 GMT+03:00 Isarra Yos zhorishna@gmail.com:
I have made a patch for a responsive version of MonoBook with mobile support. See: https://gerrit.wikimedia.org/r/c/421199/ or if you just want a live demo, https://wiki.zaori.org/wiki/Page_title?useskin=monobook - load it on a phone or make your browser window narrow or something and you can see what it looks like. This is a prototype nojs version; I intend to make an even sillier js layout with popovers and stuff as a followup patch.
A potential issue has already been raised with the icons: I don't really know how to make text strings actually, well, reliably fit on mobile devices, but a lack of support for no-image usage could also be a real problem in MonoBook. Feedback on that or whatever, as well as other testing and reviews, would be greatly appreciated.
Well, it looks a bit dated, but in cute and geekish way. I love the way you took the menu out of the way without hiding it under a hamburger button, but what I would particularly like to see is how it handles navboxes. Traditionally, they have been hidden on the Wikipedia mobile site, prompting people to do all kinds of sick workarounds that kind of work, but not really. If anyone can come up with a decent solution to that it's probably you :)
Strainu
There is also a rather more immediate problem at present. As you can see on the patch, jenkins has -1ed it for style problems. Unfortunately I have no idea what the style problems are because the output of that test is totally useless (https://phabricator.wikimedia.org/T190072) - can anyone tell me what the problem(s) are so I can fix them? And/or just resolve T190072? Please? It's starting to get a bit annoying, frankly, as it's been coming up across several of these patches.
-I
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 3, 2018 at 6:52 PM, Strainu strainu10@gmail.com wrote:
but what I would particularly like to see is how it handles navboxes. Traditionally, they have been hidden on the Wikipedia mobile site, prompting people to do all kinds of sick workarounds that kind of work, but not really. If anyone can come up with a decent solution to that it's probably you :)
The solution is probably for the on-wiki editors to make navboxes responsive (e.g. using TemplateStyles[1]), rather than expecting the skin to deal with it.
[1]: https://www.mediawiki.org/wiki/Extension:TemplateStyles
2018-04-04 18:40 GMT+03:00 Brad Jorsch (Anomie) bjorsch@wikimedia.org:
On Tue, Apr 3, 2018 at 6:52 PM, Strainu strainu10@gmail.com wrote:
but what I would particularly like to see is how it handles navboxes. Traditionally, they have been hidden on the Wikipedia mobile site, prompting people to do all kinds of sick workarounds that kind of work, but not really. If anyone can come up with a decent solution to that it's probably you :)
The solution is probably for the on-wiki editors to make navboxes responsive (e.g. using TemplateStyles[1]), rather than expecting the skin to deal with it.
Skipping navboxes is a decision that was taken by the WMF team responsible for the mobile site (whatever it was called at the time) and can be solved cleanly only at the skin level, but I don't expect this to happen as long as it will break the mobile site.
Your proposal would be the ideal argument for reversing the current "solution", yes, but realistically, it's not going to happen throughout the hundreds of wikis that implemented navboxes.
Strainu
On Wed, Apr 4, 2018 at 3:18 PM, Strainu strainu10@gmail.com wrote:
Skipping navboxes is a decision that was taken by the WMF team responsible for the mobile site (whatever it was called at the time) and can be solved cleanly only at the skin level, but I don't expect this to happen as long as it will break the mobile site.
Your proposal would be the ideal argument for reversing the current "solution", yes, but realistically, it's not going to happen throughout the hundreds of wikis that implemented navboxes.
Here we're talking about Isarra's very interesting project to make the Monobook skin responsive, not whatever decisions WMF's mobile teams may have made in the past for their mobile-only skin. She is not obligated to follow their lead just because they led, and I'd recommend she doesn't in this case.
Note that's my personal recommendation and not any sort of official WMF position. I likely won't even be involved in the code review for her patch.
On 03/04/18 22:52, Strainu wrote:
Well, it looks a bit dated, but in cute and geekish way. I love the way you took the menu out of the way without hiding it under a hamburger button,
Well, admittedly, that approach was largely just so it would work at all without js. I was kind of planning on also having a more traditional popout thing for when js is enabled, but I haven't implemented that yet.
but what I would particularly like to see is how it handles navboxes. Traditionally, they have been hidden on the Wikipedia mobile site, prompting people to do all kinds of sick workarounds that kind of work, but not really. If anyone can come up with a decent solution to that it's probably you :)
As others rightly point out, the problem with navboxes is as much an onwiki/content problem as a skinning one - many of these did not need to be tables to begin with, but there was no reason not to, but there also wasn't really any better alternative. Now that we have things like templatestyles, options exist to convert them, but that's going to take considerable time and effort as well from actual content editors - but there are also a lot of tables in the wiki content that actually do need to be tables, too. This sort of data is hard to present and... well, frankly resolving that for tables in general should at least begin to approach navboxes as they are currently, as well?
So I see a few approaches here, beyond just convert the navboxes content-side, since, again, that doesn't solve all of it anyway (though we still should do that too):
* Hide such tables entirely (what MF apparently does?). They display poorly, and provide relatively little value as a result. I... don't like this logic, because if they weren't worth having they wouldn't be on the page in the first place, generally. This is the sort of call the editors should be making. * Collapse tables into a modal, as DJ says - have some sort of thumbnail and the like to indicate what it is in general, and then open it up into a full-screen viewer. Unfortunately requires js. (So fine for modern skins, but this is monobook!) * Just kind of... separate them from the rest of the content with contained scrolling (overflow: auto, I think?). Has potential to be very annoying, but at least it doesn't require js!
Given that that's all I've got, I'll just come out and say that a canned version of the second one in core would be incredibly useful across all skins, and... we can probably just manually add in the third as a nojs fallback? Except why not include that fallback regardless? Hmm.
Are there any other options here?
-I
wikitech-l@lists.wikimedia.org