Hi, as a measure to standardise our URLs, I've introduced[1] a new
special page to change mobile site options, Special:MobileOptions.
Currently, it handles only beta features opt in/out. For exampple, to
enable beta features, you need to visit
[[Special:MobileOptions/BetaOptIn]] which is much clearer than the old
schema with urls like[2]. However, this change invalidates the old
URLs. The question is what shall we do with them:
* Create b/c redirects to special pages
* Use the opportunity to add beta links somewhere in UI
* Change the blog post to point to new opt-in URLs
* Do nothing, that post was too long ago
?
----
[1] https://gerrit.wikimedia.org/r/4587
[2] http://en.wikipedia.org/wiki/Somearticle?mobileaction=opt_in_cookie
--
Best regards,
Max Semenik ([[User:MaxSem]])
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&f…
[6] https://gerrit.wikimedia.org/r/#change,3894