Page MenuHomePhabricator

Prototype solutions to avoid FOUC on section collapse
Closed, ResolvedPublic8 Story Points

Description

To move this along the developers of the team got together and brainstormed possible solutions. We are going to prototype all solutions. We will demo these prototypes to @Nirzar and @ovasileva on the Donald Trump article on a mobile device (emulated in Chrome).

The prototypes are:

Adding click handlers

Will be added to all headers to allow sections to be expanded (which will be removed when the toggle code loads)
Owner: @Jdlrobson
Link: https://gerrit.wikimedia.org/r/314210
Pros:

  • Solves the goal - Removes the flash of unstyled content with no impact on no JS or printed experience
  • Minimal bloat to HTML
  • Simple solution that is shippable in a sprint:
    • No input needed from design research given that we've shown the value of collapsing sections to users
    • Minor input needed from design team. The only decision necessary would be whether we need to show the collapse arrow icon in this intermediate state.
    • From technical side, we'd need to add/update some tests and ensure the inline script does not leak into API results. We may want to shift the code in the prototype from the MobileFormatter into the skin.
    • No changes in accessibility from normal - open sections still can happen with tab and enter key.

Cons:

  • Minor maintenance cost
    • Inline JavaScript is difficult to invalidate if we hit any issues, but given we are doing the same for lazy loading image we have set a precedent.
    • We will have to be careful to keep inline script in sync with the toggle code
  • Sections cannot be reopened until the page JavaScript has fully loaded. If the JS fails to load for any reason, due to a JS error, it will never be possible to close them but it will also not be clear that they need to be closed

Checkbox hack

Owner: @phuedx
Link: https://gerrit.wikimedia.org/r/#/c/315512/
Pros:

  • No FOUC
  • CSS-only
    • Can be progressively enhanced to include remembering whether a section was toggled
  • Trivially simple to style, minimising the hit to top-loaded styles.
  • Toggling JavaScript code can be removed or drastically simplified.
  • Supports all Grade A and C browsers.

Cons:

  • A dramatic DOM structure change – we'll need to move section headings inside of section containers.
  • The simplicity of the styles comes at the cost of additional complexity in constructing the page.
  • As the name implies, it's a hack…
  • Hard to make accessible
    • e.g. I couldn't get the label element to act as a button in Chrome (53.0.2785.143) so that sections could be opened with the keyboard.

Sections expanded by default with table of contents

Owner: @bmansurov
Link: https://gerrit.wikimedia.org/r/#/c/313874/
Pros:

  • ToC after lead section for all types of browsers: JS/non-JS, mobile/tablet.
  • Less tech debt as we won't be rendering MF version of ToC and as we'll be removing the section collapsing code
  • No FOUC.
  • Progressively enhanced ToC, viewable in an overlay for easy navigation without leaving the read position.
  • Allows easy searching on the page as there are no collapsed sections.
  • Consistent look and feel across form factors as opposed the current situation where ToC is visible on tablet-sized devices only.
  • Printing styles don't need special treatment as sections are expanded.
  • No need to worry if JS fails rendering collapsed sections useless as there is no collapsing at all.

Cons:

  • Non-JS users have to scroll to the top of the page to see the ToC.
  • On articles with many headings, the HTML size may get bigger a little bit. But, this increase may also be offset by the decrease in the modules we ship as we'd be removing mobile.toggle related code.

Details / section tags ( as suggested by @Yair_rand )

Owner: @Jdlrobson
Link: http://jdlrobson.com/tmp/Trump.html
Caveats: The prototype collapses all section headings / not just the highest level one (easily fixed but something to be aware of)

Pros:

  • Section collapsing becomes available for certain non-JavaScript users (any which have intentionally disabled JS) and grade C browsers (potentially UC Mini running extreme mode)
  • Limited styling needed
  • JavaScript code for toggling JavaScript can be removed (unless we want to support mobile options open by default)
  • Gracefully degrades
  • IE6 will render the content with the HTML5 shim.
  • This is mostly accessible - in Chrome for example you can expand with enter key. Older versions however may experience issues.
  • Section collapsing is instantly available and usable even on 2G connections as no JS is required.

Cons:

  • Complex change in MobileFormatter - we'd need to wrap all sections and headings in a container
  • IE6 without JS will not render any content due to the way it handles new HTML5 elements.
  • Section collapsing will disappear for certain browsers that support JS. most notably Internet Explorer/Edge based phones.
    • another way at looking at this is we exert pressure on IE to adopt this standard. We are a big website. We have a chance to make the web better.
  • Some people may not like the markup
  • Will be hard to expand sections on tablet mode without resorting to JS. We'll likely to have the same problem that we are trying to solve but with tablets instead.

The owners of each should be prepared for the meeting to be able to list pros and cons of each approach.

Event Timeline

Jdlrobson created this task.Oct 4 2016, 6:05 PM

Here is a prototype of expanded sections: https://gerrit.wikimedia.org/r/#/c/313874/

Jdlrobson renamed this task from Prototype solutions to Prototype solutions to avoid FOUC on section collapse.Oct 4 2016, 6:30 PM
Jdlrobson updated the task description. (Show Details)
bmansurov updated the task description. (Show Details)Oct 4 2016, 6:55 PM

Change 314210 had a related patch set uploaded (by Jdlrobson):
Collapse sections by default

https://gerrit.wikimedia.org/r/314210

Jdlrobson updated the task description. (Show Details)Oct 5 2016, 12:44 AM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)Oct 5 2016, 12:49 AM
Jdlrobson updated the task description. (Show Details)Oct 5 2016, 12:52 AM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)Oct 5 2016, 12:55 AM
Jdlrobson updated the task description. (Show Details)Oct 5 2016, 12:59 AM
ovasileva set the point value for this task to 8.
ovasileva moved this task from Incoming to 2016-17 Q2 on the Readers-Web-Backlog board.
Jdlrobson updated the task description. (Show Details)Oct 6 2016, 11:46 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Yair_rand.
ori awarded a token.Oct 11 2016, 4:23 PM
phuedx claimed this task.Oct 12 2016, 1:14 PM

@Jdlrobson: Could you clarify the browser requirements for Details & Summary elements prototype? CIU reports that these elements aren't supported by IE, Edge, Opera Mini, and older versions of Firefox.

Change 315512 had a related patch set uploaded (by Phuedx):
[WIP] Use "checkbox hack" for section toggling

https://gerrit.wikimedia.org/r/315512

phuedx updated the task description. (Show Details)Oct 12 2016, 3:02 PM

When shall we meet?

TheDJ added a subscriber: TheDJ.Oct 12 2016, 3:06 PM

Please also evaluate for accessibility !

Jdlrobson updated the task description. (Show Details)Oct 12 2016, 6:00 PM

good reminder @TheDJ :)
@phuedx I was having difficulty getting availability but I set something up for next Tuesday. You should have permission to edit the calendar invite to bring it forward... I believe you were one of the more difficult people to schedule.

Jdlrobson updated the task description. (Show Details)Oct 12 2016, 6:00 PM

Greatest command ever:

mwvagrant import-dump Trump.xml

Annoyingly scribunto is needed:
http://reading-web-staging.wmflabs.org/wiki/Donald_Trump

I've tried to enable it but I get "==> default: The container hasn't been created yet." whenever I try to run

mwvagrant provision

@phuedx could you take a look?

Jdlrobson updated the task description. (Show Details)Oct 12 2016, 7:25 PM

@phuedx I was having difficulty getting availability but I set something up for next Tuesday. You should have permission to edit the calendar invite to bring it forward... I believe you were one of the more difficult people to schedule.

Next Tuesday (18th October) is good for me. Or this Friday (14th) is good for me.

phuedx added a comment.EditedOct 13 2016, 10:28 AM

I've moved this to Needs Analysis as we'll be discussing the proposed solutions on Tuesday, 18th October. The prototypes are exactly that, prototypes, which won't be reviewed as other changes would be /cc @MBinder_WMF

phuedx removed phuedx as the assignee of this task.Oct 13 2016, 10:29 AM

Greatest command ever:

mwvagrant import-dump Trump.xml

Annoyingly scribunto is needed:
http://reading-web-staging.wmflabs.org/wiki/Donald_Trump
I've tried to enable it but I get "==> default: The container hasn't been created yet." whenever I try to run

mwvagrant provision

@phuedx could you take a look?

Firstly, use vagrant as it's more natural (vagrant is aliased to /usr/local/bin/mwvagrant).

I had to destroy and re-create the machine backing our staging server as it got into a weird state. I've imported the Trump.xml dump but the Donald Trump page looks weird.

Sigh, Scribunto makes importing a complete nightmare :-( I think it's expecting a wikibase identifier somewhere and since wikibase isn't setup it explodes (I see this all the time locally)

So instead I messed around with:
https://en.wikipedia.org/w/api.php?action=parse&format=json&page=Donald+Trump&prop=wikitext
I then pushed the result through ?action=expandtemplates&format=json&title=Donald+Trump&text=

ending up with http://reading-web-staging.wmflabs.org/w/index.php?title=Donald_Trump2&mobileaction=toggle_view_mobile

So let's test on the above article.

Prototype showcase meeting notes: https://etherpad.wikimedia.org/p/banana-phrototypes

Proto 1 - inline JS handlers in the HTML

Pros:

Works while JS is loading
HTML only has no collapsing, sections are expanded
Event handlers removed when the actual JS loads

Cons:

Only opening to not add too much code
Duplicate JS solution in RLQueue and Skin modules

Proto 2 - Checkbox & CSS

Pros:

No JS solution
Just some CSS to add and some markup per section
Enables removing of JS toggling code
Browser support seems pretty good

    (CSS ~ or + selector. Some problems with very old IEs)

Cons:

Begs for restructuring of sections HTML to make it more solid
Making accessible seams unusually hard.

    e.g. I couldn't get the label to be focussable and interactable (!?) with a keyboard.

Breaks linking to sections with hash fragments, if all 

Why?

Nevermind, you can fix this with CSS!

Proto 3 - Core TOC, no section toggling

Pros:

Adds TOC & button to open TOC
No section collapsing so no problem
Accessibility is fine (links + hashes)

Cons:

With no JS and you go down, you need to go up to see sections

Proto 4- Details & summary tags

Pros:

Browser standard tags
Accessible by default
Future proof

Cons:

Needs changing the HTML
Browser support is poor (even modern IE won't support it)

My opinion is we should answer this question first:

Do we plan to remove section collapsing with something like the apps TOC with core's TOC?

  • Yes.
    • Then stall this effort, wait for Proto 3 - Core TOC, no section toggling to be implemented.
  • No
    • We need to consider between protos 1, 2, 4

I personally like and find section collapsing very useful so I wouldn't remove it even if we add a TOC on mobile, so I don't think Proto 4 is a good fix for the issue unless we clearly decide to remove section collapsing.

My preference is between Proto 1 - Adding click handlers and Proto 2 - Checkbox hack, preferring Proto 2 because it keeps a single collapsing implementation, while Proto 1 adds one, but I don't see many issues if we go with Proto 1 instead.

Proto 4 looks good, but has poor browser support and I'm not sure how we would do some additional features we have now like saving toggled sections to storage and restoring them on page load.

Jdlrobson moved this task from Code Review to Ready for Signoff on the Reading-Web-Sprint-83-Y? board.

My takeaways:
Proto 3 is great, but I think having a table of contents and section collapsing are two very different features. Like @Jhernandez I find section collapsing an extremely useful feature. I think we should pursue this but we shouldn't pursue it on the basis of solving the FOUC.

Proto 1 is the least risk and given its simplicity we could line it up and fix it in the next sprint.

I do like both 2+4 because of the value they add to our grade C experience. I think we should continue this discussion from the point of view "Make section collapsing available to Grade C+X browsers".

So in summary. My proposal is we run with #1 asap but we continue #3 and a merged #2+#4 in other Phabricator tasks with different motives.

I think Proto #1 solves the problem at hand, we should go with it and decide on whether we need the ToC later. I chose the Proto #1 rather than #2, as its main drawback is that it's not accessible. #4 is too radical and doesn't offer anything more to #1.

exactly what @bmansurov said..... the toc is different issue and it should go through our product process as any other feature.

All Protos solves the problem

1 is least risk
2 is tricky and will break screen readers, also IE support is pretty poor (some sites say even IE7/EI8 has some problems it, sadly I don't have IE8 to check that)
3 TOC is a totally new feature, would be nice to focus on it as a separate feature
4 looks the best if it comes to semantics

What if we connect 1 and 4 ? I mean lets go with proper HTML5, add details and summary tags and then additionally if browser doesn't support that lets do JS to add open/closed classs to toggle visibility ? With that approach we will have correct HTML, full screen-readers support and fallback for old devices.

Okay I've setup T148591 for 2+4. @bmansurov there's a question for you there :)
@bmansurov and @Nirzar can you capture table of contents in another card?

@ovasileva @phuedx @jhobs - just need some input from you but it seems like we might want to fold solution #1 into T126825 and schedule that for next sprint.

What if we connect 1 and 4 ? I mean lets go with proper HTML5, add details and summary tags and then additionally if browser doesn't support that lets do JS to add open/closed classs to toggle visibility ? With that approach we will have correct HTML, full screen-readers support and fallback for old devices.

We could definitely do this. It's a little more risky as we are changing the HTML structure and working with a slightly newer html tag, but we could do that as a follow up on #1 relatively easily. Should we discuss that in T148591 ?

@bmansurov There is already a toc ticket on design incoming column. i will repurpose that for toc discussion, does that sound good?

Yes, sounds good.

Hi all, sorry I'm late to the party. Here's some thoughts:

  1. Works for everything we wanted and is a straightforward fix. My vote goes here.
  2. It's a good solution for grade C browsers, which should be a focus. I agree on doing some research in T148591: Evaluate providing section collapsing to older browsers where we do not run JS
  3. I personally like the TOC style. I would nominate this vs. 1 for design testing and potentially implement in the future.
  4. See 2

So, seems like our next steps are:

phuedx updated the task description. (Show Details)Oct 19 2016, 9:51 AM

Can somebody help me understand why the accessibility story is different in 1 and 2? I don't know much about a11y and I'd like to learn.

jhobs added a comment.EditedOct 19 2016, 2:46 PM

My opinions lie with what most have said so far: I prefer the ToC style personally. I understand that it would be the largest of the 4 changes and thus using option 1 as a short-term fix is not a bad solution. I do have some questions, however.

Proto 3 - Core TOC, no section toggling

Cons:

With no JS and you go down, you need to go up to see sections

Why is this the case? Can we not make a ToC that uses simple links and would thus be able to have a no-js version? We have a no-js version of the hamburger menu; I don't see a reason we couldn't make one for the ToC and progressively enhance. I'm also curious if we've considered keeping section collapsing with a ToC. Seems the perfect candidate for an A/B test during implementation to see if people 1) use section collapsing with a ToC and 2) discover the ToC if section collapsing exists.

Can somebody help me understand why the accessibility story is different in 1 and 2? I don't know much about a11y and I'd like to learn.

In #1 you can navigate to, expand, and collapse sections with your keyboard for example. In #2 you cannot as far as I can tell.

My opinions lie with what most have said so far: I prefer the ToC style personally. I understand that it would be the largest of the 4 changes and thus using option 1 as a short-term fix is not a bad solution. I do have some questions, however.

Proto 3 - Core TOC, no section toggling

Cons:

With no JS and you go down, you need to go up to see sections

Why is this the case? Can we not make a ToC that uses simple links and would thus be able to have a no-js version? We have a no-js version of the hamburger menu; I don't see a reason we couldn't make one for the ToC and progressively enhance. I'm also curious if we've considered keeping section collapsing with a ToC. Seems the perfect candidate for an A/B test during implementation to see if people 1) use section collapsing with a ToC and 2) discover the ToC if section collapsing exists.

The TOC is already being progressively enhanced. Maybe you misunderstood what was being said. I'll try to explain too: Imagine you're on a long article page and you've scrolled down the last section. Now if you want to see the table of contents you have to scroll back up when JS is not available. That's what was meant in that comment. As for the A/B test, I think design is working on it.

bmansurov closed this task as Resolved.Oct 19 2016, 6:23 PM
bmansurov claimed this task.

Looks like we've agreed to go with the option #1.

Change 315512 abandoned by Phuedx:
[WIP] Use "checkbox hack" for section toggling

https://gerrit.wikimedia.org/r/315512

Change 314210 abandoned by Jdlrobson:
POC: Collapse sections by default

Reason:
Even though this is the solution we're going to go with it would be wise to start from scratch with tests when working on this.

https://gerrit.wikimedia.org/r/314210

Change 319067 had a related patch set uploaded (by Jdlrobson):
Collapse sections by default

https://gerrit.wikimedia.org/r/319067