As we're starting to migrate functionality provided by the MobileFrontend extension into Mediawiki core, we have to grapple with some existing limitations in Mediawiki. I'd like to propose a core change that I think will greatly increase MW's flexibility in rendering content for different 'view types'. By 'view type', I mean things like:
* The standard web browser view * A print view * A mobile view * Other device specific views, views for particularly slow connections, views with no graphics, etc.
We could use the idea of a 'view type' to allow us to do some cool stuff, for instance:
*Dynamic view-specific skin loading* MobileFrontend already displays content from a mobile-specific skin. We could make it possible for Mediawiki to dynamically determine the skin to load based off of the current view type, and provide a pattern for skin authors to follow for building view type-specific skins, for example: * Standard: <SkinName>.php * Print: <SkinName>Print.php * Mobile: <SkinName>Mobile.php We could also provide a hook for people to be able to define their own view types, as well as allow for configuration to define default skins for specific view types. We could then more easily build view types for specific devices, for instance. This would greatly lower the barrier of entry for someone who wants to write a mobile-specific skin, print-specific skin, etc, and would enrich the pool of available MW skins.
*View-specific functionality* Different view types will likely have different bits of functionality that they require, separate from the rest of MW, that may not make sense to exist in a Skin. We could allow different view types the opportunity to bootstrap view-specific functionality when appropriate. If we segment this functionality to only load for a specific view-type, we can prevent unnecessary components from loading if they are not appropriate for a specific view. I haven't yet really flushed this concept out, and am very open to suggestions on implementation. * * I started hacking a bit at a few core files to give a code example of how this might be implemented, at least for dynamically loading view-specific skins: http://pastie.org/4010775
I'd love to hear people's thoughts on this and integrate feedback as we move forward with migrating MobileFrontend into MW core. Fore more info on the MobileFrontend to core migration, see http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
On Sat, Jun 2, 2012 at 1:03 AM, Arthur Richards arichards@wikimedia.orgwrote:
*View-specific functionality* Different view types will likely have different bits of functionality that they require, separate from the rest of MW, that may not make sense to exist in a Skin. We could allow different view types the opportunity to bootstrap view-specific functionality when appropriate. If we segment this functionality to only load for a specific view-type, we can prevent unnecessary components from loading if they are not appropriate for a specific view. I haven't yet really flushed this concept out, and am very open to suggestions on implementation.
I think there's two main parts to this: chrome and content.
Chrome is usually skin-provided stuff like the menus, sidebars, etc -- and we rearrange that dramatically for mobile, hide it for print, etc. The existing skin system seems to be able to handle this as we're seeing with the migration of MobileFrontend to using skins. Yay!
Content would cover things like numbered [1] links being expanded in a list in print mode -- we accomplish this today by hiding the list of links via CSS in non-print views.
For example, references should really be similarly treated: on desktop/tablet and mobile views they should pop up inline when you click them, while for print we really do want the big lists of refs so they make it to output. Potentially we can also have smarts for dealing with video or animated content with "flat" alternate content for print -- such as separating an animated diagram into multiple diagrams in print version.
This sort of thing can be accomplished by pure CSS -- having standard classes that hide things on mobile or on print -- or slightly more complicatedly with more parser fun having output format knowledge or replacement chunks... I think I recommend using CSS to avoid complicating things. ;)
Potentially hidden items could also be stripped from view to avoid transferring extra data, though...
I started hacking a bit at a few core files to give a code example of how
this might be implemented, at least for dynamically loading view-specific skins: http://pastie.org/4010775
Probably the most important thing is having smart fallbacks; if there's a customized desktop skin, but no mobile or print version of it, then on print or mobile view we should fall back to the default mobile or print skin rather than getting stuck on the preferred desktop skin. This'd make it easy to customize the desktop view while still having things work sanely in other views -- and having standard naming makes it easy to then go ahead and customize the mobile view too.
-- brion
On 02/06/12 10:04, Brion Vibber wrote:
I think there's two main parts to this: chrome and content.
Chrome is usually skin-provided stuff like the menus, sidebars, etc -- and we rearrange that dramatically for mobile, hide it for print, etc. The existing skin system seems to be able to handle this as we're seeing with the migration of MobileFrontend to using skins. Yay!
Content would cover things like numbered [1] links being expanded in a list in print mode -- we accomplish this today by hiding the list of links via CSS in non-print views.
For example, references should really be similarly treated: on desktop/tablet and mobile views they should pop up inline when you click them, while for print we really do want the big lists of refs so they make it to output. Potentially we can also have smarts for dealing with video or animated content with "flat" alternate content for print -- such as separating an animated diagram into multiple diagrams in print version.
This sort of thing can be accomplished by pure CSS -- having standard classes that hide things on mobile or on print -- or slightly more complicatedly with more parser fun having output format knowledge or replacement chunks... I think I recommend using CSS to avoid complicating things. ;)
We *must* hide them only with CSS. Remember that if the user clicks print without going first to printable version, we shall show them all the references.
Printable version is just a way to show in screen something similar to what would be printed. It shouldn't be a View nor have an independent class file. Hey!, printable could even be entirely handled by the ResourceLoader.
On Sat, Jun 2, 2012 at 2:06 PM, Platonides Platonides@gmail.com wrote:
We *must* hide them only with CSS. Remember that if the user clicks print without going first to printable version, we shall show them all the references.
Printable version is just a way to show in screen something similar to what would be printed. It shouldn't be a View nor have an independent class file. Hey!, printable could even be entirely handled by the ResourceLoader.
I'm willing to sacrifice the print-directly-from-regular-view, to be honest.
I've always had the impression that most people don't realize that there is a print stylesheet -- we originally tried to remove the 'printable version' link since it was made redundant by CSS but got loads of complaints.
Our primary web pages should be optimized for online reading; among other things this probably means a future where we collapse extra sections by default, since we believe most readers only look at the beginning or a specific part of the page, rather than reading the entire thing start to bottom. Many detailed articles are simply absurdly large, making them slow to parse, slow to download, slow to render, etc. On mobile we collapse sections by default to make it render faster and easier to scroll through on a small touchscreen, but saving download time as well will be a factor that's important on slow networks.
(And slow networks aren't exclusive to mobile -- many countries have poor or very high-latency internet connectivity which makes loading a large page with many components potentially quite slow on the desktop.)
Internet users generally expect a separate printable view, and we can certainly consider in the future whether it's worth it to maintain the print stylesheet on what's nearly always an online-only view.
-- brion
On Sat, Jun 2, 2012 at 1:04 AM, Brion Vibber brion@pobox.com wrote:
This sort of thing can be accomplished by pure CSS -- having standard classes that hide things on mobile or on print -- or slightly more complicatedly with more parser fun having output format knowledge or replacement chunks... I think I recommend using CSS to avoid complicating things. ;)
Potentially hidden items could also be stripped from view to avoid transferring extra data, though...
Particularly in regards to mobile as well as slow connections, you've hit the nail on the head. While doing everything with CSS might be a more elegant approach, we need to be able to have much more control over what data gets sent to the device, and when. That said, I don't think what I am proposing is incongruous with doing it all with CSS. The skin system can handle either approach, and if the view system is implemented correctly with fallbacks/overridability/etc, an administrator should be able to finely tune behavior depending on needs.
Probably the most important thing is having smart fallbacks; if there's a customized desktop skin, but no mobile or print version of it, then on print or mobile view we should fall back to the default mobile or print skin rather than getting stuck on the preferred desktop skin.
This'd make
it easy to customize the desktop view while still having things work sanely in other views -- and having standard naming makes it easy to then go ahead and customize the mobile view too.
Yah, totally agreed.
On Sat, Jun 2, 2012 at 5:21 AM, Brion Vibber brion@pobox.com wrote:
Internet users generally expect a separate printable view, and we can certainly consider in the future whether it's worth it to maintain the print stylesheet on what's nearly always an online-only view.
I agree with this as well. For the time being, if people are OK with me moving forward on this, I can leave the print functionality as-is and start implementing the view system around it. Down the road, we can figure out the best approach to handling print display.
wikitech-l@lists.wikimedia.org