We've had ongoing problems with the auto-detecting mobile theme provided by MediaWiki's MobileFrontend extension. Because we serve cached pages to users who aren't logged in (and most users aren't logged in), desktop users end up seeing the mobile theme if that was the last version the wiki served, and vice versa.
We have a few options:
1. Scrap MobileExtension and serve everyone the desktop view.
- Pros: Simplest to implement.
- Cons: Reduced functionality for mobile devices.
- Rationale: Browsers on mobile devices are increasingly sophisticated and can handle desktop websites better than a few years ago.
2. Do the backend work to serve mobile pages from a unique subdomain and unique webserver config.
- Pros: Recommended by MediaWiki specifically to circumvent caching issues.
- Cons: Difficult to implement, may require significant downtime, requires coordinated work across several admins.
- Rationale: This is the best-practices fix for MediaWiki, even in newer versions, and probably the only way we can reliably cache PFW and serve a unique mobile skin at the same time.
3. Update to MW 1.23, the new MobileFrontend extension, and the new official mobile theme Minerva.
- Pros: It's MediaWiki's official and supported setup for mobile devices, and it includes a user-toggleable switch between mobile and desktop themes even when not logged in. Mobile CSS is easy to modify.
- Cons: It's not finished yet, with many incomplete or beta-quality features (notably editing). It's still susceptible to caching problems and represents a workaround more than a lasting fix. The skin would require extensive modification to match our style and implement common features. (Though to be fair, we haven't done that for WPtouch on 1.19.)
- Rationale: We need to update to 1.23 in May anyway, and this is the best-supported mobile option on 1.23.
I'd already started working on this as part of the preliminary testing for updating to 1.23 but haven't done much with it lately. It's doable, but Minerva is pretty rough, particularly for editing. It's not a plug-and-play replacement for WPtouch.
4. Use a responsive skin.
- Pros: Doesn't necessarily require 1.23. One skin serves many devices. Cache doesn't affect rendering. Opens up CSS options to reflow contents based on browser width, which can alleviate problems like TOCs and infoboxes crowding out content in narrow browser windows as well as mobile.
- Cons: Skin CSS is complex and more difficult to maintain or update. Older browsers will struggle. We're reliant on the skin's authors to update the skin code when/if MW changes. Skin must be rethemed to match our style. Some features may break without hacking into the skin.
- Rationale: This is arguably the most user-friendly option regardless of whether we modify caching, and it provides improved views not only for mobile users but also desktop users who resize their browsers.
I've already hacked together a mod of Refreshed, a responsive skin compatible with 1.19 and up. You can switch to it in your Appearance Preferences or view these samples: main page, Westcrown, Portal:Accessories, Poisons of Golarion.
Continued tweaking Refreshed, now with tabs and responsive menus. Still need to polish the tabs and menus.
For a bonus, see any creature page in the Refreshed skin, especially on a mobile device. Like a mobile skin, a responsive skin lets us target different styles for mobile users to avoid things like awkward text wraps around infoboxes.
Did a little more work with Refreshed to bring it closer to our existing skin, and switched all our infoboxes to use the infobox CSS class, which was in our stylesheets but for some reason not used; all the infoboxes has inline CSS. Regardless of the fix we implement, having all infoboxes on the same CSS class will help with styling to match.
I also took full-page screenshots at viewports of
- 320px (iPhone portrait; all nav in touch menu, inline images fill width)
- 480px (iPhone landscape; text wraps around inline images)
- 600px and 800px (tablet; add left sidebar, page actions and user menu in touch menu)
- 1024px and 1366px (laptop/desktop; right sidebar with user menu and search expanded)
The screenshot tool fouls up the left bar; it stays in place while scrolling, as do the top tabs in desktop viewports and the touch menu header in tablet and phone viewports.
Wow! Those all look great! It'd be nice to more clearly distinguish the search field as such, but overall, I really like it! I know that currently the slideshow images on the main page don't switch on mobile devices. Would the same be true using this new skin (I don't know what causes the problem, so it might be something entirely unrelated).
Thanks! The search field should have a magnifying glass in it, same as the QuickFind field in the editor. The slideshow works fine on my Nexus 4 and 7 in Chrome and Firefox Mobile.
Making this my default theme for the next few weeks to kick the tires with it.
I made some tweaks late last night that should help IE8. IE7 and earlier may be something of a lost cause for this skin, but running analytics on our logs it looks like about 1.2% of our pageviews are from IE8 and earlier—probably less since that includes my testing.
Still need to test on older Firefoxes. Good on Firefox all the way back to v3.4.
I also added a shadow to the tab/header bar to help separate it visually from the content, and did some very rudimentary performance testing in Firefox of Refreshed, the 1.2x-ready PFVector skin, and the default Vector skin. Surprisingly, Refreshed is on par with PFVector despite the extra CSS and image load. Both load about half a second faster and cache their scripts in the browser better than Vector, probably because both of them use the post-1.17 resource loader for everything and our version of Vector doesn't. My hack of Refreshed also seems to work pretty well on my local 1.23 test instance.
There's still some nits to pick, I'm sure my HTML and CSS are rusty and could improve, and I'd still like to find a way to get the user menu into the header and collapse the right sidebar entirely on the desktop viewports, but I'm low on free time for a couple weeks. Still, getting it up to a usable state wasn't as hard as I expected it'd be, and in the process a lot of the wiki should now be easier to style in any skin with some of the inline CSS moved to classes in Common.css.
Fixed some searchbox issues that were bugging me and restored search autocompletion on desktop. It temporarily breaks again if you resize the browser across viewports but comes back on a refresh. 1.22+ apparently fixes some of these issues.
More searchbox tweaks: Discrete "Go" and "Search" buttons are back. Distant, wavering voices of clients past wafted through my window and urged me to "make the logo bigger," so I did.