Forgetting bugs and performance implications (which are arguably
solveable) please read this for background on the why:
http://www.mediawiki.org/wiki/MobileFrontend/Dynamic_Sections
Please consult this data that reinforces a better user experience:
https://docs.google.com/spreadsheet/ccc?key=0ArbzKvV50qF6dEFzR0pCbUxfVy1ybG…
Turning this code off would cause less coding headaches but would fail
to solve the problems that it strived to complete namely and
significantly:
* Allowing older devices to read any large MediaWiki page (we have no
real data about which phones cannot access Wikipedia so it's difficult
to assess this as a problem)
* Older phones with older browsers would continue to load images that
are hidden.
* Optimisation loading of lead section (which I guess is now less
important that Google Quick View has arrived)
That said I think code that has been sitting around for __12 months__
without much progress is a bad thing (especially when the problems it
solves and the problems that need to be solved are clearly defined).
I have never been able to understand the problems to why bug [1]
appears to be "impossible" (despite looking so simple) and as a
frontend developer am not best suited to solve it. So if this truly is
as hard a problem as history is leading me to believe and will never
get fixed or no one wants to fix it I'd reluctantly lean towards
removing the code simply from the perspective of code hygiene.
This is not the best reason but I'm pretty tired of fighting a lone battle .
[1]
https://bugzilla.wikimedia.org/show_bug.cgi?id=42746
On Thu, May 16, 2013 at 10:36 AM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
Recently, more bugs with dynamic sections resurfaced.
Here is the
current situation:
* We mangle HTML in beta and alpha, removing all sections but 0 and
relying on JS to provide the rest.
* The former approach does not work with non-JS user-agents and when
JS is disabled or simply didn't get loaded (we're on mobile after
all).
* Pure-HTML fallback with links to separate sections doesn't sound
promising due to performance concerns.
** Because there's no sane way to purge the cached sections.
** And because we'll have to either spend more CPU time on every
mobile section view than on whole desktop view OR cache aggressively
and compete with parser cache, thus reducing overall cluster
performance anyway.
This is very broken and because there's no chance that it will be
moved into core in its present state it fails the beta inclusion
criteria (for final testing of features that will soon be exposed to
everyone).
Therefore, I propose to do away with it and if we still want dynamic
section views in the foreseeable future, use plan B that I proposed
before:
* Leave HTML as it is.
* Load subsequent pages dynamically.
** While the first page load may seem much heavier than just section 0
+ section headings, due to the amount of JS we serve, the
percentage of bandwidth saved by stripping sections is reasonably
low except for a few really huge pages.
** Subsequent page views work as before.
** All fallbacks work magically.
** Implementation is straightforward and requires much less work to
make it production-quality.
** No performance bells ringing.
--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Jon Robson
http://jonrobson.me.uk
@rakugojon