Mailing List Archive: Wikipedia: Wikitech

Making MW aware of 'view types'

Index | Next | Previous | View Threaded

arichards at wikimedia

Jun 1, 2012, 4:03 PM

Post #1 of 5 (121 views)
Permalink

Making MW aware of 'view types'

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

--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

brion at pobox

Jun 2, 2012, 1:04 AM

Post #2 of 5 (106 views)
Permalink

Re: Making MW aware of 'view types' [In reply to]

On Sat, Jun 2, 2012 at 1:03 AM, Arthur Richards <arichards [at] wikimedia>wrote:

> *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
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Platonides at gmail

Jun 2, 2012, 5:06 AM

Post #3 of 5 (106 views)
Permalink

Re: Making MW aware of 'view types' [In reply to]

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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

brion at pobox

Jun 2, 2012, 5:21 AM

Post #4 of 5 (104 views)
Permalink

Re: Making MW aware of 'view types' [In reply to]

On Sat, Jun 2, 2012 at 2:06 PM, Platonides <Platonides [at] gmail> 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
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

arichards at wikimedia

Jun 4, 2012, 11:30 AM

Post #5 of 5 (107 views)
Permalink

Re: Making MW aware of 'view types' [In reply to]

On Sat, Jun 2, 2012 at 1:04 AM, Brion Vibber <brion [at] pobox> 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 [at] pobox> 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.

--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads