There is clearly a compelling case to be made for dynamic sections, and if there is enough willpower we can of course overcome the technical difficulties.
What is also clear is that this can not and should not be fought as a 'lone battle'; but that means getting this work prioritized relative to everything else in our backlog. A compelling case needs to be made to the product folks (who are responsible for prioritization), and we, as a team, need to sit down and architect a solution, likely with a representative from the operations and platform teams. This is complicated enough and has such big architectural implications that it's going to require buy-in and effort from quite a few people to get done.
If it seems like it's going to be a while before we can tackle this problem in earnest and with our full attention, it would be sensible to back out existing, buggy code.
On Fri, May 17, 2013 at 9:27 AM, Jon Robson jdlrobson@gmail.com wrote:
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=0ArbzKvV50qF6dEFzR0pCbUxfVy1ybGV...
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson http://jonrobson.me.uk @rakugojon
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l