On Thu, Mar 29, 2012 at 8:34 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
I've been experimenting with the api that Max
Semenik has been working
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
. 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
the API tested.
The resulting prototype  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.
1) It enables sub section expansion for which the existing design
doesn't really seem to work. Also it means pages like History of China
 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
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
4) Some sections just contain sub sections. So if I click a section
with heading 'Section 1' that only contains 'Section 1.1' and
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 , load History of China via the link 'Chinese history
texts' and click 'Prehistory' (observe 'loading content'). I guess
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  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.