r103254 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:< r103253‎ | r103254 | r103255 >
Date:23:08, 15 November 2011
Author:brion
Status:deferred (Comments)
Tags:
Comment:
tweaks & more in readme
Modified paths:
  • /trunk/mockups/athena/README (modified) (history)
  • /trunk/mockups/athena/frame-inner.js (modified) (history)

Diff [purge]

Index: trunk/mockups/athena/README
——@@ -1 +1,35 @@
22 See https://www.mediawiki.org/wiki/Athena
 3+
 4+
 5+Implementation notes on this mockup:
 6+
 7+== Data source ==
 8+
 9+Pages are loaded in an <iframe> from http://en.wikipedia.org using ?useformat=mobile.
 10+They are currently loaded through a local .php proxy which hides the mobile-view header/footer and injects a script to modify behavior to cooperate with the parent frame.
 11+
 12+This frame embedding (using HTML5 postMessage) style, if integrated into the regular raw views, could make it easier for mockups and alternate UI tools to hook in without modification in future, without exposing direct XSS vectors between the two sides...
 13+
 14+
 15+
 16+== Screen size ==
 17+
 18+CSS media queries are used to check the screen. If 640px or wider, we enable the 'tablet' mode with wider buttons, more visible entries on the top bar.
 19+
 20+If smaller, we use the 'mobile' mode with more compact buttons, things folded etc.
 21+
 22+
 23+== Scrolling ==
 24+
 25+The embedding iframe is sized to match its content, so the outer document as a whole scrolls.
 26+
 27+Top & bottom toolbars float using position: fixed (warning: limited browser support!), with
 28+automatic switching to inline in the page layout when you reach the footer.
 29+
 30+
 31+== Known issues ==
 32+
 33+* position: fixed elements don't work on iOS 4.3 (ok on 5.0)
 34+* on iOS, bottom bar doesn't switch between position:fixed and inline in the footer during scrolling; event isn't called until scroll finishes
 35+* hash links like references and 'jump back a section' don't appear to be working
 36+
Index: trunk/mockups/athena/frame-inner.js
——@@ -38,12 +38,18 @@
3939 window.addEventListener('click', function(event) {
4040 var target = event.target;
4141 if (target.nodeName.toLowerCase() == 'a') {
42 - event.stopPropagation();
43 - event.preventDefault();
44 - messageParent({
45 - event: 'navigate',
46 - url: target.getAttribute('href')
47 - });
 42+ var href = target.getAttribute('href');
 43+ if (href.substr(0, 1) == '#') {
 44+ // Allow local #hashlinks
 45+ } else {
 46+ // Send any actual
 47+ event.stopPropagation();
 48+ event.preventDefault();
 49+ messageParent({
 50+ event: 'navigate',
 51+ url: href
 52+ });
 53+ }
4854 }
4955 }, true );
5056

Comments

#Comment by Yair rand (talk | contribs)   23:34, 15 November 2011

CSS media queries to distinguish between tablet and mobile? I thought the differences between the two displays would be large enough that they would require entirely separate HTML, JS, and CSS... But they're going to share the same stylesheet file?

#Comment by Brion VIBBER (talk | contribs)   00:06, 16 November 2011

The differences seem to be mostly in fairly small details: hide some things here, shove some things in a popup there, be more compact here, be less compact there. A lot of that is indeed trivial CSS. Some things will require different logic in the JS, but would be checking against the same sort of thing (and perhaps actually piggybacking on the CSS media query system to do it, for consistency).

The overall logic, behavior, widget sets, etc are mostly common; it makes a lot of sense to share an implementation. This also allows dynamically switching modes -- if you pull this up in a desktop browser, it simply *poof* switches over as you resize above or below 640px wide.

On an iPhone or iPad you'll generally not have a chance to resize live, but some web-app-ish systems (for instance Windows 8's Metro-style environment) do provide for splitting a large screen between two panes, and you may end up narrower or wider than you were before -- so this is a realistic scenaior for a mobile/tablet web site or HTML-based application.

#Comment by Yair rand (talk | contribs)   00:39, 16 November 2011

Much of the HTML loaded is not used on mobile (Gadget Gutter, geocoordinates/icons/tagline in L1 header, most of the top bar). Also, the tablet version would probably include jQuery, which would immediately make the javascript a zillion times too heavy even not including the standard site js and enormous Mediawiki library. However, if there are situations where it would be helpful if non-mobile users could make use of a compact interface, perhaps CSS media queries could be used for non-mobiles, allowing reformatting the page on resize, while giving a the minimal version (no unnecessary HTML, JS, or CSS) to browsers assumed to have slow loading times?

#Comment by Brion VIBBER (talk | contribs)   01:12, 16 November 2011

A few things:

  • jQuery doesn't actually make mobile browsers explode like they've been drizzled in C4. :)
  • You can scale the amount of stuff you load based on what you expect to use.
    • If you want to whine about loading unused HTML, you'll be HORRIFIED at our current http://en.m.wikipedia.org/ mobile interface, which loads up ENTIRE ARTICLES and then collapses ALL BUT THE FIRST SECTION, even if you never open up and read any of them! That's something we want to avoid more aggressively, and fixing that would easily overpower the "weight" of a few menu items (that are mostly still going to be there, but in a menu)
  • "phones" and "tablets" often have the same CPUs, RAM, and operating system as each other; if the HTML's too heavy for phones it's too heavy for tablets. If it's not too heavy for tablets, conversely it's not necessarily too heavy for phones.
  • Loading speeds (eg are you stuck on a high-latency 2g/3g/4g mobile network?) are entirely distinct from mobile/tablet/desktop interface form factors (size, availability of touchscreen vs keyboard & mouse input, expected multi & single-tasking behavior). A mobile phone or tablet may be on a highly-latent, flaky mobile network or it may be on wifi connected to a beautiful fiber connection. A laptop may be on that beautiful fiber connection, or it may be on a 3g dongle, MiFi, or tethered phone.
#Comment by Yair rand (talk | contribs)   02:45, 16 November 2011

Re unused HTML in the current mobile site: Yes, it's an enormous amount of unused HTML (almost half as much data as the jQuery scripts if it's a medium-large FA :) ), and it's something that really needs to be fixed. Would that be possible if the implementation is shared with tablets? Re loading speeds: I know pretty much nothing about this, but I gathered from the fact that the current mobile site is pretty stripped down in terms of data loaded that mobiles generally have much slower loading times... (Sorry if I'm being a nuisance challenging things I'm mostly clueless about.)

Status & tagging log