WT:Wikipedia Signpost/Archive 10#Assistance from Evad37
{{aan}}
Consider CSS changes for better narrow viewport (e.g. mobile device in portrait mode) display
I know that we are missing really good tools for responsive design in article layout, but I think there are probably some tweaks that could be made to the Signpost's markup that would help make viewing on a small screen a nicer reading experience. I'm hopeful that RfC: Allow styling in templates will eventually provide easier solutions for CSS that includes @media
variations, but until then it may be worth giving up some of the precise layout control used for large viewport devices in favor of layout that degrades more gracefully for small viewports. --BDavis (WMF) (talk) 16:44, 22 December 2016 (UTC)
:{{pong|BDavis (WMF)}} I was the one that implemented the current design. I found it effectively impossible, given the limited CSS allowed on MediaWiki sites, to implement a design that scaled well both to very large and very small displays. The current design is optimized for ~11-15 inch displays, scales well to displays bigger than that, and scales poorly to smaller ones. Something had to give. I'm still not convinced anyone reads the Signpost in mobile at all. I've heard colloquially that a few do. Do you have better data on this? ResMar 03:28, 23 December 2016 (UTC)
::{{pong|Resident Mario}} I do not have data, but I would hypothesize that you are correct that the readership of The Signpost on devices the size of a typical phone is very low. This may be due in part to the fact that it is completely unreadable. On my iPhone the current main signpost page is rendered as 3 columns with the outer columns having a width of 2 characters and the middle column having a width of 7 characters. The article layout gives a width of 3 characters to the headlines and 12-15 characters to the article body. I think what is needed most is a flex box grid of some kind for the layout rather than the current inline styles. I'm very aware that the editing tools to make this easy are badly missing in MediaWiki in general. The only way to accomplish it that I know of personally is by getting css with @media
selectors added to the site css like was done for the .mw-tpl-portal-*
styles on Wikitech. Just fixing Common.css is also not enough due to the Mobile Frontend extension. It ignores Common.css and instead introduces Mobile.css which is bottom loaded and thus causes a FOUC before the mobile specific CSS is applied. --BDavis (WMF) (talk) 15:36, 23 December 2016 (UTC)
:::{{pong|BDavis (WMF)}} Polluting global stylesheets with local page specific CSS is exactly the sort of thing that the site as a whole needs to avoid, though. ResMar 22:24, 23 December 2016 (UTC)
::{{reply-to|Resident Mario}} Thank you for your design work. Would it be practical to have two different layouts created, one for small displays and one for tablet-and-larger ones? If not, would it be practical to generate something like a "book" or "single page" edition that is at least usable on small screens? I'm sure there would have to be compromises, such as eliminating or thumb-nailing large images (the user could click on them to view the files description page, and from there, the image, if he wanted to). davidwr/(talk)/(contribs) 17:49, 23 December 2016 (UTC)
:::{{pong|davidwr}} It doesn't appear to be possible to appease both types of displays in one page, but if you split Signpost stories into two separate pages, making one work for small displays would be trivial. That's not a bad idea, given the unlikelihood of more advanced CSS controls coming to Wikipedia. On that end however there's a separate problem: the Signpost is getting by right now doing publication using a not actively maintained bot script, and there's little prospect of the necessary bot changes being made unless a new script is written from scratch by a new maintainer. ResMar 22:24, 23 December 2016 (UTC)
Very glad to see this under discussion. I'm not too knowledgeable about CSS, but this is one of several interrelated issues that are high on my priority list to find a way to improve in 2017. One note, actually the current production model involves an almost entirely manual process that usually takes a couple hours and yields mistakes and oversights. The script is, as I understand it, far too broken to use (and my understanding is that the main culprit is the evolution of MediaWiki over time). We're also trying to figure out stuff like getting listed on Google News, improving SEO, updating the way attribution is handled in stories, making sure we have a good RSS feed, etc. The discussions are a bit scattered as yet, but I'm hoping to get more organized about it, and ideally to get some good help in a new production manager(s), as I believe our current production manager has too many RL obligations at the moment.
A data point -- it's true that few people are accessing the SP via mobile, but not an insignificant number. And it could well be that people have learned that mobile SP reading is annoying, and avoid it for that reason...in which case, a low number would not be a good reason to ignore the problem! Yesterday, [https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=desktop&agent=user&start=2016-12-22&end=2016-12-22&pages=Wikipedia:Wikipedia_Signpost/2016-12-22/Year_in_review|Wikipedia:Wikipedia_Signpost/2016-12-22/News_and_notes|Wikipedia:Wikipedia_Signpost/2016-12-22/In_the_media|Wikipedia:Wikipedia_Signpost 536 people accessed the main page via desktop, while 26 accessed it via mobile app or browser]. Our most widely read piece was Year In Review; 604 read it via Desktop, 37 via mobile. -Pete Forsyth (talk) 22:58, 23 December 2016 (UTC)
: Suggestion -- could the columns issue be partially addressed the same way as the {{tl|reflist}} template handles it? e.g.,
::Reflist uses a custom class which was inserted into the global CSS. The gist of this is that every single time a page on Wikipedia is loaded, one of the "bits and pieces" that has to get loaded is a set of reflist-specific instructions, even on pages which don't have any references whatsoever. For an ultra high-volume template like reflist
, this cost is negligible, but it would be very hard to justify carving a Signpost-specific clause in the globals (side note: the global is already full of junk that WMF personnel hacked in to get That One Specific Page working back in the bad old days). Besides, it wouldn't help, at least not the way the Signpost content is currently written.
::If the Signpost wishes to stay "on premises" on Wikipedia itself—and it does, and ought to—this issue is totally intractable. The Signpost is already facing serious structural issues that are far more serious than the question of mobile viewership. ResMar 23:38, 25 December 2016 (UTC)
::: Thanks {{u|Resident Mario}}; very helpful context. My question was slightly different; maybe the answer is a simple "no, that won't work," but let me clarify to be sure. (My understanding of how CSS works is admittedly hazy.) Is it possible to piggyback on the CSS class that's already used for {{tl|reflist}} -- that is, without introducing new CSS? -Pete Forsyth (talk) 00:46, 26 December 2016 (UTC)
::::Awfully derivative, but a clever idea...it might be possible. I'll try to experiment with it later. ResMar 01:07, 26 December 2016 (UTC)
:::::{{yo|Resident Mario}} Where can I learn more about the bot issues you all are facing? I might be able to help :) As for redesigning The Signpost, I agree with BDavis that the flexbox model is probably our best bet. It would be tricky, but I think it would be possible to get what we want without the use of media queries — MusikAnimal talk 01:52, 26 December 2016 (UTC)
::::::{{ping|MusikAnimal}} There was once a bot/script that automated this obscenely long process. :-) Having that again would save Pete a lot of time. Ed [talk] [majestic titan] 02:25, 26 December 2016 (UTC)
:::::::{{pong|MusikAnimal}} Re: bot code. The publishing bot was written by Jarry1250 in ~2013, when he was a highly active editor in charge of the Technology report. It's written in PHP using the Peachy framework, which I believe he had a hand in writing. The web interface is [http://tools.wmflabs.org/signpost/publish.php here]; the code for it is [https://github.com/Jarry1250/labs-signpost available on GitHub]. I would at this point say "Jarry has since moved on to other things", which I do believe was true at one time (hey, I'm technically retired, right? Sure!), but he seems quite to the contrary [https://en.wikipedia.org/wiki/Special:Contributions/Jarry1250 to be quite active]. So I suppose that with regards to fixing the bot, the next line of action ought to be this one: {{yo|Jarry1250}} ResMar 02:34, 26 December 2016 (UTC)
:::::::PS: {{re|The ed17}} Been a while since I've needed this one—{{edit conflict}} ;). ResMar 02:34, 26 December 2016 (UTC)
:::::::Re: flexbox. It's been a while since I've written heavy Wikipedia styling code, but I'm pretty sure style="display:flex"
isn't allowed, right? Tough place to build a flexbox out of...what do you think of this reflist trick? It's devious, which means it might work. ResMar 02:34, 26 December 2016 (UTC)
::::::::Hi Res! Yup, pretty active again (for now). Last I knew my interface still worked. I thought the point was that Wikipedia:Bots/Requests for approval/KharBot had replaced it, and maybe made some other changes at the same time? - Jarry1250 [Vacation needed] 20:09, 26 December 2016 (UTC)
:::::::::{{pong|Jarry1250}} Well this is awkward! {{yo|Kharkiv07}}, but it does appear that he hasn't edited in three months. Unfortunately the source code is not publicly available—the BRFA states "Source code available: No... willing to provide if issues arise". {{yo|Peteforsyth}}, have you contacted Kharkiv07 recently? Obviously the ideal would be for him to come back on and fix the bot up. If not, we really need for him to at least release the source code to the bot, so that others can patch it up (I'm very surprised that BRFA doesn't require stronger justification for not open sourcing your code!).
:::::::::Edit: actually, reading the BRFA again, is the problem that the bot is broken, or is it that the only user with access to it and the know-how to use is not around to run it? ResMar 20:37, 26 December 2016 (UTC)
{{outdent}}Yes, {{u|Resident Mario}}, I discussed these issues with {{u|Kharkiv07}} several months ago. Three significant pieces from our discussion:
- The bot is substantially broken, mainly due to updates to the MediaWiki software
- Recommended to rewrite the bot from scratch, but before doing that, best to have a thorough understanding of various possible changes to the Signpost.
- They are not likely to have the bandwidth to do that work themselves, but are probably available to advise.
I'll start a separate thread below to outline what those changes could/should be. -Pete Forsyth (talk) 22:51, 26 December 2016 (UTC)
:Thanks Peteforsyth. I'd be happy to make any changes to the main publishing scripts (i.e. both those changes that prompted Kharkiv's fork, plus any new ones). - Jarry1250 [Vacation needed] 23:08, 26 December 2016 (UTC)
I have fixed the three column layout, as well as another bug with the series sidebar messing up styling in some cases in articles.. Most of all however.. article layout is a mess... People seem to throw around div's like they are newlines and someone broke the entire idea behind the templates at some point. —TheDJ (talk • contribs) 12:20, 27 December 2016 (UTC)
:Whenever you have
Right some questions:
- There is a framing of 50px on the left and the right of the main content. This is the primary reason that much of the content is unreadable on mobile, since that is 1/4 of the screen already. So do we need it ?
::The framing acts as a gutter to the text content. It was meant to be a small optimization targeted at large displays, and I believe that it was the most controversial change in the format on the editorial board at the time that I introduced it. It's nonessential. ResMar 17:16, 27 December 2016 (UTC)
:::{{replyto|Resident Mario}} Right, I figured something like that. But it's completely different from the indentation of the header and the footer, is that also intentional ? —TheDJ (talk • contribs) 20:07, 27 December 2016 (UTC)
::::I think so. The gap was stylistic. Again, though, maybe not worth the overhead. ResMar 21:48, 27 December 2016 (UTC)
- Perhaps we can use viewport relative sizes for the margin/paddings ?
- There is a maximum width of 46em, but it is not clear to me if that intentionally excludes the sidebar or not.
::This intentionally excludes the sidebar. The page was designed around two columns of content in mind: the story text on the left, and visual/interactive supporting content on the right. If you haven't already, I suggest taking a look at Wikipedia:Wikipedia_Signpost/Newsroom/Style to see the design principles, or at the [https://www.bloomberg.com/graphics/2015-elon-musk-spacex/ original reference] I had in mind when I was working on this. ResMar 17:16, 27 December 2016 (UTC)
- All content of the sidebar is right aligned, meaning that on very wide pages, the sidebar is far removed from the content. I'm guessing that wasn't intentional ?
::I wasn't aware of alternative methods of achieving this. The idea was that on smaller screens (IPad, not IPhone) the content would mesh, which would preserve readability. ResMar 17:16, 27 December 2016 (UTC)
:::I might be able to do something that keeps the sidebar closer on large screens. —TheDJ (talk • contribs) 20:07, 27 December 2016 (UTC)
- Is it intentional that the content block is left aligned, or should it be center aligned ?
::I believe I experimented with center alignment, but it didn't work out so great. I don't recall why, but if you can make it work, sure, it can be used. ResMar 17:16, 27 December 2016 (UTC)
:::That would actually be a lot easier probably :) —TheDJ (talk • contribs) 20:07, 27 December 2016 (UTC)
- {{replyto|Resident Mario}} another question. There is a different indentation for the 'content' blocks and the 'in brief' blocks. Is that intentional ? —TheDJ (talk • contribs) 20:07, 27 December 2016 (UTC)
::I believe not. I'm not sure, but I think someone updated the top margin at some point. ResMar 21:48, 27 December 2016 (UTC)
I've also made a new preload template, that doesn't use raw divs and a new preload template to experiment with some more friendly mobile settings —TheDJ (talk • contribs) 14:16, 27 December 2016 (UTC)
- OK, I think i'll make forks of some of the templates and do the following:
- # Use viewport relative margins and make them a bit smaller, to avoid wasting too much space on mobile, without having to use media queries.
- # I'll make all blocks 'full width', and 'self contained' aka balanced, so that divs, won't span the entire page anymore. unbalanced divs (begin and end templates) are really annoying in combination with VE and parsoid
- # I'll define consistent indentation
- # I'll see if I can improve the sidebar a bit.
- That should help a lot. —TheDJ (talk • contribs) 20:07, 27 December 2016 (UTC)
:::Ok great, I'll leave you to it then! ResMar 21:48, 27 December 2016 (UTC)
:::: {{u|Resident Mario}} and {{u|TheDJ}}, delighted to see you forging ahead with this. It sounds like you both have a much better handle on how it does / should fit together than I do, so I'll just stay out of the way; but it would be good to check in once you're done, so I can get a sense of what changes you made, why, and how we can best honor them in our day-to-day practices. And I can use that as an opportunity to go through the excellent Style Guide linked above, and make sure it's fully up-to-date and concise. Please reach out if needed for any reason. -Pete Forsyth (talk) 22:11, 27 December 2016 (UTC)
::::: Hi Resident Mario and Peteforsyth, can I get your opinion on Wikipedia:Wikipedia Signpost/Templates/Story-preload/NAN3 and {{mobile|Wikipedia:Wikipedia Signpost/Templates/Story-preload/NAN3}}. It's not finished, but it should give a good idea about the general layout, and should work for both mobile and desktop. —TheDJ (talk • contribs) 15:47, 28 December 2016 (UTC)
:::::: Thank you {{u|TheDJ}}, they look good to me -- but, I don't have a very clear idea of what aspects I should be paying closest attention to, what represents a change, etc. They certainly look good on the surface. One detail, on the mobile version when viewed on my 4.5" Android screen, the "small" image is about the same size -- actually, I think a bit larger -- than the "large" image. I don't know that it's a problem, there may be no need to offer two different size options for small screens. But that's the only thing I notice.
:::::: Are you finished with the main Signpost page reformatting? Both the desktop and mobile versions do look quite a lot better on my mobile device now, thank you. Any further changes planned there? -Pete Forsyth (talk) 23:10, 28 December 2016 (UTC)
::::::: {{u|TheDJ}}, I hope you don't mind, I moved a couple pieces from the main page into templates -- getting a couple of raw DIV tags off the page (per your earlier suggestion), and getting rid of a stray DIV tag as well. Please take a look, and let me know if I've messed something up, or adjust as you see fit. Special:Diff/756880458/757133956 -Pete Forsyth (talk) 00:55, 29 December 2016 (UTC)
:::::::: One more question on this, {{u|TheDJ}} and {{u|Resident Mario}}: Might you be able to incorporate the "blurbs" (that is, the descriptive text about each section), and perhaps even cover image(s), into the Signpost archives? See this archive of Aug. 18 edition and the front page during the Aug. 18 edition -- the "blurb" text only ever lives on the main front page, and goes away when the next edition is published. This does not seem ideal to me. -Pete Forsyth (talk) 19:57, 29 December 2016 (UTC)
:::::::::This would require a change in publishing and bot procedures. The page in question is transcluded from Wikipedia:Wikipedia_Signpost/2016-08-18, which is generated at runtime by the bot (or by the publisher, if the manual procedure s followed) and is also used in other parts of the interface. Considering how rarely archive front pages are accessed directly, the additional complexity this would introduce isn't worthwhile. ResMar 17:14, 30 December 2016 (UTC)