cross-posting to wikitech-l
On Thu, Mar 29, 2012 at 8:34 AM, Jon Robson jrobson@wikimedia.org wrote:
I've been experimenting with the api that Max Semenik has been working on and the html5 history interface [1] to add javascript to the MobileFrontend extension so that any searches, link to other articles and section expansions go via the api. It's something I'm very interested to do both from a usability and site performance perspective. The best example of what I'm trying to do can be seen on http://github.com . It's worth pointing out that this is not currently on the roadmap but it is something I'm very interested in us doing.
The resulting prototype [2] has a few quirks (and a few things I haven't paid attention to e.g. page titles do not change) but I think is interesting as it is noticeably faster (please bear in mind this is a slow server) and reduces the load on the server in that any page loads after the first load will go via the api. Note devices which do not support the history api or jQuery are not effected by this code.
It throws up some interesting challenges.
- It enables sub section expansion for which the existing design
doesn't really seem to work. Also it means pages like History of China [3] look different when viewed normally to when retrieved via the api (the normal version only has expansion on the top level sections) 2) Also the back button (at the moment) has no memory of which sections were opened/closed and instead goes back to the last loaded page. 3) The first page is still wastefully loaded. It would be good if we could load all sections dynamically on the first page whilst not give a crummy experience to non-javascript users. 4) Some sections just contain sub sections. So if I click a section with heading 'Section 1' that only contains 'Section 1.1' and 'Section 1.2' there is a brief flash whilst it tries to load any text for section 1 (Please load-> empty string). To see what I mean load the Japan page [4], load History of China via the link 'Chinese history texts' and click 'Prehistory' (observe 'loading content'). I guess it would be useful if the api let me know beforehand if a section was empty of any text so I didn't try to retrieve it. 5) The api returns the heading in the text. For example in [5] the line Prehistory includes the heading in the text. This is unnecessary as I can determine this from toclevel and line. In my code I'm currently scrubbing this out every time I load.
Feel free to have a play [6] locally as the mobile-geo server is very very slow and improve on it. Let me know if this interests anyone other than me :-)
~Jon
[1] http://www.w3.org/TR/html5/history.html#the-history-interface [2] http://mobile-geo.wmflabs.org/w/index.php/Millet [3] http://mobile-geo.wmflabs.org/w/index.php/History_of_China [4] http://mobile-geo.wmflabs.org/w/index.php/Japan [5] http://en.wikipedia.org/w/api.php?action=mobileview&page=History+of+Chin... [6] https://gerrit.wikimedia.org/r/#change,3894
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Mar 29, 2012 at 8:34 AM, Jon Robson jrobson@wikimedia.org wrote:
I've been experimenting with the api that Max Semenik has been working on and the html5 history interface [1] to add javascript to the MobileFrontend extension so that any searches, link to other articles and section expansions go via the api. It's something I'm very interested to do both from a usability and site performance perspective. The best example of what I'm trying to do can be seen on http://github.com . It's worth pointing out that this is not currently on the roadmap but it is something I'm very interested in us doing.
We've talked about this a number of times and it had been blocked getting the API tested.
The resulting prototype [2] has a few quirks (and a few things I
haven't paid attention to e.g. page titles do not change) but I think is interesting as it is noticeably faster (please bear in mind this is a slow server) and reduces the load on the server in that any page loads after the first load will go via the api. Note devices which do not support the history api or jQuery are not effected by this code.
It throws up some interesting challenges.
- It enables sub section expansion for which the existing design
doesn't really seem to work. Also it means pages like History of China [3] look different when viewed normally to when retrieved via the api (the normal version only has expansion on the top level sections) 2) Also the back button (at the moment) has no memory of which sections were opened/closed and instead goes back to the last loaded page. 3) The first page is still wastefully loaded. It would be good if we could load all sections dynamically on the first page whilst not give a crummy experience to non-javascript users. 4) Some sections just contain sub sections. So if I click a section with heading 'Section 1' that only contains 'Section 1.1' and 'Section 1.2' there is a brief flash whilst it tries to load any text for section 1 (Please load-> empty string). To see what I mean load the Japan page [4], load History of China via the link 'Chinese history texts' and click 'Prehistory' (observe 'loading content'). I guess it would be useful if the api let me know beforehand if a section was empty of any text so I didn't try to retrieve it. 5) The api returns the heading in the text. For example in [5] the line Prehistory includes the heading in the text. This is unnecessary as I can determine this from toclevel and line. In my code I'm currently scrubbing this out every time I load.
The best way to balance all the pros/cons is to load the chrome+first paragraph as fast as possible. *Then* load all subsequent sections asynchronously *while* the user is reading the first section. That way we have all the content by the time the user gets to each sub section. This resolved you having to wait for each section as you tap but allows the page to load as fast as possible.
--tomasz
The best way to balance all the pros/cons is to load the chrome+first paragraph as fast as possible. *Then* load all subsequent sections asynchronously *while* the user is reading the first section. That way we have all the content by the time the user gets to each sub section. This resolved you having to wait for each section as you tap but allows the page to load as fast as possible.
How would you say this would work for users with javascript disabled? I could imagine us having a separate url for a 'complete page' - e.g. a page like the ones we have now e.g. http://en.m.wikipedia.org/wiki/San_Francisco/complete and then having http://en.m.wikipedia.org/wiki/San_Francisco be the first paragraph with a link saying 'read more' pointing to the 'complete page'. This provides a path for non-javascript users. Then we enhance this to load the sections asynchronously as you've suggested.
On Thu, Apr 5, 2012 at 10:34 AM, Jon Robson jrobson@wikimedia.org wrote:
The best way to balance all the pros/cons is to load the chrome+first paragraph as fast as possible. *Then* load all subsequent sections asynchronously *while* the user is reading the first section. That way we have all the content by the time the user gets to each sub section. This resolved you having to wait for each section as you tap but allows the
page
to load as fast as possible.
How would you say this would work for users with javascript disabled? I could imagine us having a separate url for a 'complete page' - e.g. a page like the ones we have now e.g. http://en.m.wikipedia.org/wiki/San_Francisco/complete and then having http://en.m.wikipedia.org/wiki/San_Francisco be the first paragraph with a link saying 'read more' pointing to the 'complete page'. This provides a path for non-javascript users. Then we enhance this to load the sections asynchronously as you've suggested.
That sounds pretty sensible; basically either way you have to click through something to get at more content. With no JS it's "intro" -> "complete"; with JS you get to open each section individually.
-- brion
wikitech-l@lists.wikimedia.org