Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Re: [WikimediaMobile] HTML history interface / api use for MobileFrontend

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


arichards at wikimedia

Mar 29, 2012, 10:09 AM

Post #1 of 4 (185 views)
Permalink
Re: [WikimediaMobile] HTML history interface / api use for MobileFrontend

cross-posting to wikitech-l

On Thu, Mar 29, 2012 at 8:34 AM, Jon Robson <jrobson [at] wikimedia> 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.
> 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
> [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+China&format=jsonfm&sections=1a
> [6] https://gerrit.wikimedia.org/r/#change,3894
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>



--
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


tfinc at wikimedia

Apr 4, 2012, 1:19 PM

Post #2 of 4 (147 views)
Permalink
Re: [WikimediaMobile] HTML history interface / api use for MobileFrontend [In reply to]

>
> On Thu, Mar 29, 2012 at 8:34 AM, Jon Robson <jrobson [at] wikimedia> 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.
>> 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
>> [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
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jrobson at wikimedia

Apr 5, 2012, 10:34 AM

Post #3 of 4 (143 views)
Permalink
Re: [WikimediaMobile] HTML history interface / api use for MobileFrontend [In reply to]

> 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.

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


brion at pobox

Apr 5, 2012, 10:40 AM

Post #4 of 4 (146 views)
Permalink
Re: [WikimediaMobile] HTML history interface / api use for MobileFrontend [In reply to]

On Thu, Apr 5, 2012 at 10:34 AM, Jon Robson <jrobson [at] wikimedia> 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 mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.