Wouldn't a simple <meta name = "viewport" content = "width=device-width"> added to the header of each page
make all Mediawiki sites look better on mobile right away? It wouldn't affect non mobile browsers too.
Currently one must go to Manual:FAQ#How do I add meta tags? lengths or add extensions to do that. No simple LocalSetting.php way either.
Talk:Mobile support in MediaWiki core/Flow
Current skins aren't built to handle mobile device widths. Doing that would cover tabs in some skins and make sidebars cramp the content.
For viewport to work a skin has to be custom developed to be responsive.
Jidanni, why don't you look at some of the responsive skins? There are quite a few of those, for example:
- Foreground
- Naiad
- WebPlatform
- Apex
- I very much like the 3 following bootstrap-based skins:
You should definitely take a look at one of those, IMO.
OK I have installed MobileFrontend.
In case anyone is still looking, here is one solution:
$out->addHeadItem('viewport', '<meta name="viewport" content="width=device-width">');
From: Google Webmaster Tools Team <wmx-noreply@google.com> Subject: Fix mobile usability issues found on http://radioscanningtw.jidanni.org/ To: webmaster of http://radioscanningtw.jidanni.org/ Google systems have tested 231 pages from your site and found that 100% of them have critical mobile usability errors. The errors on these 231 pages severely affect how mobile users are able to experience your website. These pages will not be seen as mobile-friendly by Google Search, and will therefore be displayed and ranked appropriately for smartphone users. Fix this now: 1. Find problematic pages View a report of the non-mobile-friendly pages found on your site, and the issues discovered: https://www.google.com/webmasters/tools/mobile-usability?siteUrl=http://radioscanningtw.jidanni.org/ 2. Learn about mobile-friendly design There are a variety of techniques you can use to make your site mobile-friendly. Specifically, look for information about the issues brought up in Webmaster Tools: https://developers.google.com/web/fundamentals/ 3. Fix mobile usability issues on your site Fix the issues preventing your site from being mobile-friendly. Not sure how to proceed? * If your site is built with software like Wordpress or Joomla (also known as "Content Management System" or CMS), read the easy steps to make a CMS mobile-friendly: https://developers.google.com/webmasters/mobile-sites/website-software/ * Read more about building mobile-friendly websites on our Developer site: https://developers.google.com/webmasters/mobile-sites/get-started/ * Ask a question in our forum for more help - mention message type [WNC-451500]. https://support.google.com/webmasters/go/community
Therefore please make MediaWiki ready for mobile. Yes I tried the extensions and they weren't up to par.
What was your experience using MobileFrontend? Does using something like that or a responsive MediaWiki skin change your report?
What didn't work for you with what you tried? I'd love to know more about this report and think that a little more information would be helpful for everyone.
Thanks. I recall that at least last year whatever convenience MobileFrontend provided was offset by ... well I forgot the details, but I ended up getting rid of it. Also if it was so good then why isn't it standard (built-in) yet? Which leads to the question of why can't what WikiPedia is using for mobile just allow not hardwiring wikipedia.org and allow one to use it for any MediaWiki wiki. I bet it would work 99% OK. But alas, my idea was not accepted. Not for even trial purposes.
Anyway I'm just saying that Google proves that MediaWiki sites look terrible and thus get their rankings chopped too, and there's still no OFFICIAL solution that MediaWiki dares distribute because those solutions are not ready for prime time... (OK if they are then why aren't they built in yet?) and there is no heat on MediaWiki's neck because WikiMedia sites all have their own fix so MediaWiki wiki users are left out in the cold.
Also here's an idea for how you can test how my site would look with MobileFrontend etc. stuff installed, without "imperiling" my other users: Start putting MobileFrontend in trunk, so my svn updates would pick it up. However -- only have it kick in when a browser with User-Agent: "MediaWiki MobileFrontend etc. test team browser/0.1" was browsing! Then you could check every nook an cranny (and sidebar!), to see if mobile users would still get the most out of my site. Thanks!
I might finally even help out again in that case.
Anyway, take Google's word for it, you've got a BIG problem. Can't just stay back in year 2006...
Jidanni, MobileFontend isn't part of core because a good portion of the development community is trying to move away from shoving everything in core bloating it more and more and is even attempting to move various features out of core. Installing extensions for key features is nothing new, MediaWiki has been that way ever since ParserFunctions was created.
You tried MobileFrontend a whole year ago when and decided to rant now without bothering to consider that in that entire year MobileFrontend has been developed further?
MobileFrontend's old hardcoding issues should already be gone. It worked fine when I installed it on a staging wiki for a client project.
Also, wtf are you trolling about svn and trunk for. We ditched the outmoded subversion over 2 years ago. All MediaWiki's development is done using Git.
Oops I meant git. I'm not talking about MobileFrontend's hardcoding, I'm taking about WikiPedia's frontend hardcoding.
Could you be more specific about what you mean by frontend hardcoding. Talking in abstract and vague terms doesn't help others find the answer you need, developers understand what could be fixed, or help improve anything for anyone else.
So you're talking about the Wikipedia/etc... apps, not MobileFrontend or any part of core.
That doesn't sound like a good idea. Pointing the Wikipedia app to a wiki other than Wikipedia doesn't sound like a good idea.
And making a generic "MediaWiki" app to point to any wiki is also a bad idea.
- Configuring it to point to various wiki to view will be too advanced a task for most users.
- It won't fit in well with the app oriented setup of current mobile operating systems. Searching for a "MediaWiki" app or accessing multiple wikis from one app will not make sense to the average user.
It'll essentially become a glorified web browser that can't even browse the web and is too confusing for most users to use.
If you want an app for your wiki you're just going to have to fork the iOS/Android Wikipedia apps, modify them to point to your wiki and use your branding, then publish them to the app networks yourself.
The Android and iOS app ecosystems just aren't going to make it any easier than that. They're not designed for this.
Hurmf... radio apps can listen to many channels... so there should be a wiki app that can tune in to many wikis. --- or something else on the drawing board appwise for all mediawiki wikis. Indeed, I can see the app's name already: MediaWiki.
Wikis are not radios, the user experience does not translate. And the mass majority of users reading the many wiki around the internet don't even know what MediaWiki is.
OK I am now looking at http://en.m.wikipedia.org/wiki/Main_Page in a emulator. I see there's still now way to get to the sidebar. The sidebar is the main way to navigate my wiki.
That's because the sidebar is an antique method of handling navigation that doesn't work well on mobile.
If search isn't a good method of doing navigation on your site it's better to configure a custom main page for mobile which has an optimized site navigation.
OK, I have now installed MobileFrontend again and now all that is remaining is "Eliminate render-blocking JavaScript and CSS in above-the-fold content" which is good progress.
I had better set $wgMFNoindexPages=true; else my site's rankings won't see the benefit of me adding MobileFrontend?
It looks like the default is already true.
That setting looks like a workaround to an indexing issue. One that theoretically could be fixed by adding a mobile rel=alternative the way Google describes.
((I reported this as T91183))
I'd recommend you leave that setting out of your config. That way if MobileFrontend fixes the issue things will just start working and get even better for your site, instead of your config overriding the improvement and downgrading your indexing.
On making MediaWiki aware, how about WebRequest::isMobile()?
Mobile and desktop skins are unfortunately two completely different beasts in terms of body output needs. Some people would advocate a mobile-first approach where you develop things for mobile and them layer desktop improvements on top of that. But we've got too much desktop legacy for that.
I suggest this:
- We leave SkinVector, SkinMonoBook, etc... as-is.
- We add a SkinMobile introducing the standard mobile skin.
- SkinMobile very liberally introduces methods that can be hooked into to extend the skin with whatever types of branding a wiki may want on their mobile view
- We add a $wgMobileDefaultSkin or $wgDefaultMobileSkin which defaults to 'mobile'
- We introduce some sort of flag that marks a skin as mobile vs. desktop.
- For now it'll probably have to be a $wg variable like:
$wgSkinModes['mobile'] = array( 'desktop' => false, 'mobile' => true ); - ((I think I already have an idea how I can fit that into the config setup for my skin rewrite))
- For now it'll probably have to be a $wg variable like:
- Special:Preferences gets keyed into skin modes and we add a new preference:
- Our current 'skin' preference only lists skins that are desktop=>true
- We add a new 'mobileskin' preference which lists skins that are mobile=>true allowing users to choose different mobile skins.
There are no older topics