It's great Shahyar has got the TOC in a state where we can see jumping down working. Try it at http://flow-tests.wmflabs.org/wiki/Talk:Sandbox (please don't add or hide/delete topics to this, it's crafted specially to test TOC. You can experiment on Talk:Flow_QA or your own user_talk page.)
If you click on e.g. topic 73 it works strangely (try it and see). We think Flow is trying to load topic 73 but it's at the bottom of the page which triggers loading topics 11-20, and then the view jumps around as topics show up.
We knew this would be hard to get right. Danny and I explored some use cases.
1. You click on topic 73 and there's a gap above it. * TOC requests that topic and some topics around it (e.g. N-3 through N+7) * TOC disappears * Flow shows a Loading more animation at the bottom of the page and positions the view at it. * When the topics show up, Flow positions topic 73 just below the fixed header as usual.
While this is in progress, we need to disable the usual bottom of page Load more behavior -- don't try to load 11-20. There should only be one load going on at the very bottom of the page.
(Note ErikB doesn't think there's a performance win in asking for only topic 73 then making separate API requests for topics 69-72, etc. Nor is it easy to provide a variable response "Give me enough topics to fill four [PageUp] operations from topic 73")
When Flow adds topics 70-77 to the page I think we need a "gap indicator" at the top of them to indicate there is a gap but Flow isn't yet trying to load stuff to fill it. On a fast computer and connection the user might never see this.
2. You scroll up from topic 73 Because Flow has loaded some topics above 73, you can scroll up into content above, preserving the illusion of perfect scroll. As you get closer to the gap (topics 11-69), Flow tries to fill in the gap to preserve the illusion of a complete page. When scrolling up into a gap Flow should always load bottom-up, i.e. it requests topics 60-69. The dormant "gap indicator" turns into the active Loading more animation
The problem is, while this is going on the user can scroll around past the gap indicator/Loading more animation. Quiddity and I think that's fine and Flow should let the user freely move around in the browser window; Danny would like to stop the user scrolling past the gap -- "You wanted to scroll up to some topics above, Flow is loading them, sit tight."
3. You scroll away from a loading more gap.
In either 1 or 2, you can scroll away from the gap in at least one direction, or you can open the TOC and jump somewhere else altogether. When the API request returns the topics intended for the gap, Flow inserts them. Question: do we reposition the view? Yes for the click in the TOC, but unclear for scrolling around. I'm not sure what the default browser behavior is if you insert a bunch of content in the DOM above what the user is viewing.
4. You scroll back into the gap After loading topic 73 and scrolling up a bit, say you jump to top of page, then scroll back down towards topic 10. Flow is still filling the 11-69 gap with topics 60-69. Now you're scrolling down into the gap, you probably want the usual Load more behavior, so Flow should request topics 11-20. * Should there be two loading indicators in the gap? I think so, a gap may be being filled from the bottom and from the top at once.
Furthermore, you aren't near the bottom of the view because topics 70-77 are there, so if you're holding down the space bar or scrolling in order to force loading more topics, it won't work. You'll scroll right past the gap and into the topics lower down. I think this is OK, you're probably back on a quest to get to the "end" of the board.
5. Now you bring up the TOC and click topic 49 Like step 1 above so * TOC requests that topic and some topics around it (e.g. 46 through 56) * TOC disappears * Flow shows a Loading more animation ... where? The one gap is loading topics 60-69 from step 2 and 11-20 from step 4, now it's loading a third group!
I'm sure there are further use cases and challenges. Next step is probably for Matt, Shahyar, Pau, Danny, to explore this with other interested parties.
Some design approaches we aren't pursuing: * Detailed "68 missing topics", "load/loading 10 above" messages or controls -- Flow only shows the Loading more animation in the gap. * Flow knows the topic titles in the gaps from the TOC, but it doesn't show them -- Flow only shows the Loading more animation. * Flow doesn't communicate the size of the gap. unlike e.g. a PDF viewer it doesn't know how tall topics are. It just places a Loading more animation in the gap.
-- =S Page Features engineer
The described behaviour sounds good to me in general. I illustrated some details in a document https://docs.google.com/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit?usp=sharing (feel free to add comments if any clarification is needed). Some details to consider:
- When topics are loaded above the current viewport we don't want them to affect the viewport position (with respect the current topic the user is viewing). The default behaviour of browsers is to push content down generating a "jump" effect. This seems to be avoidable if the scroll is manipulated as new content is added to keep the relative position ( example http://kirbysayshi.com/2013/08/19/maintaining-scroll-position-knockoutjs-list.html ). - I think that the issue of moving beyond a gap can be addressed by deciding which side of the gap to fill based on the user position (more detail in the document linked above). With the current implementation I have been able to see how topics were created from the gap and keep appearing (we are not adjusting the viewport when adding new items, and those are always added to close the bottom part of the gap). - Preloading strategy and transitions can help to avoid gaps and communicate what is happening when those are unavoidable. Currently content just appears suddenly. A transition where the existing elements move and the new ones fade-in would help to communicate what happens to each piece of content https://medium.com/@pasql/transitional-interfaces-926eb80d64e3.
Pau
On Fri, Nov 21, 2014 at 9:57 PM, S Page spage@wikimedia.org wrote:
It's great Shahyar has got the TOC in a state where we can see jumping down working. Try it at http://flow-tests.wmflabs.org/wiki/Talk:Sandbox (please don't add or hide/delete topics to this, it's crafted specially to test TOC. You can experiment on Talk:Flow_QA or your own user_talk page.)
If you click on e.g. topic 73 it works strangely (try it and see). We think Flow is trying to load topic 73 but it's at the bottom of the page which triggers loading topics 11-20, and then the view jumps around as topics show up.
We knew this would be hard to get right. Danny and I explored some use cases.
- You click on topic 73 and there's a gap above it.
- TOC requests that topic and some topics around it (e.g. N-3 through N+7)
- TOC disappears
- Flow shows a Loading more animation at the bottom of the page and
positions the view at it.
- When the topics show up, Flow positions topic 73 just below the fixed
header as usual.
While this is in progress, we need to disable the usual bottom of page Load more behavior -- don't try to load 11-20. There should only be one load going on at the very bottom of the page.
(Note ErikB doesn't think there's a performance win in asking for only topic 73 then making separate API requests for topics 69-72, etc. Nor is it easy to provide a variable response "Give me enough topics to fill four [PageUp] operations from topic 73")
When Flow adds topics 70-77 to the page I think we need a "gap indicator" at the top of them to indicate there is a gap but Flow isn't yet trying to load stuff to fill it. On a fast computer and connection the user might never see this.
- You scroll up from topic 73
Because Flow has loaded some topics above 73, you can scroll up into content above, preserving the illusion of perfect scroll. As you get closer to the gap (topics 11-69), Flow tries to fill in the gap to preserve the illusion of a complete page. When scrolling up into a gap Flow should always load bottom-up, i.e. it requests topics 60-69. The dormant "gap indicator" turns into the active Loading more animation
The problem is, while this is going on the user can scroll around past the gap indicator/Loading more animation. Quiddity and I think that's fine and Flow should let the user freely move around in the browser window; Danny would like to stop the user scrolling past the gap -- "You wanted to scroll up to some topics above, Flow is loading them, sit tight."
- You scroll away from a loading more gap.
In either 1 or 2, you can scroll away from the gap in at least one direction, or you can open the TOC and jump somewhere else altogether. When the API request returns the topics intended for the gap, Flow inserts them. Question: do we reposition the view? Yes for the click in the TOC, but unclear for scrolling around. I'm not sure what the default browser behavior is if you insert a bunch of content in the DOM above what the user is viewing.
- You scroll back into the gap
After loading topic 73 and scrolling up a bit, say you jump to top of page, then scroll back down towards topic 10. Flow is still filling the 11-69 gap with topics 60-69. Now you're scrolling down into the gap, you probably want the usual Load more behavior, so Flow should request topics 11-20.
- Should there be two loading indicators in the gap? I think so, a gap may
be being filled from the bottom and from the top at once.
Furthermore, you aren't near the bottom of the view because topics 70-77 are there, so if you're holding down the space bar or scrolling in order to force loading more topics, it won't work. You'll scroll right past the gap and into the topics lower down. I think this is OK, you're probably back on a quest to get to the "end" of the board.
- Now you bring up the TOC and click topic 49
Like step 1 above so
- TOC requests that topic and some topics around it (e.g. 46 through 56)
- TOC disappears
- Flow shows a Loading more animation ...
where? The one gap is loading topics 60-69 from step 2 and 11-20 from step 4, now it's loading a third group!
I'm sure there are further use cases and challenges. Next step is probably for Matt, Shahyar, Pau, Danny, to explore this with other interested parties.
Some design approaches we aren't pursuing:
- Detailed "68 missing topics", "load/loading 10 above" messages or
controls -- Flow only shows the Loading more animation in the gap.
- Flow knows the topic titles in the gaps from the TOC, but it doesn't
show them -- Flow only shows the Loading more animation.
- Flow doesn't communicate the size of the gap. unlike e.g. a PDF viewer
it doesn't know how tall topics are. It just places a Loading more animation in the gap.
-- =S Page Features engineer
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Mon, Nov 24, 2014 at 8:29 AM, Pau Giner pginer@wikimedia.org wrote:
I illustrated some details in a document https://docs.google.com/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit?usp=sharing ...
Wau Pow , how do you make those animated GIFs :)
- I think that the issue of moving beyond a gap can be addressed by
deciding which side of the gap to fill based on the user position (more detail in the document linked above).
I think your "When the gap is in the top 66%/bottom 33% of the viewport"
works when the loading indicator in the gap is visible to the user. But we're trying to preload topics before the gap is visible.[*] I think your model still works if we extend the regions off-screen, thus: "When the gap in the range two topics above off-screen to the top 66% of the viewport then topics are loaded below the gap", then we trigger load above and "When the gap is in the range bottom 33% of the viewport to 4 topics below then topics are loaded above the gap"
With the addition of the TOC users can no longer collapse topics, so maybe Flow should switch to a window-oriented decision to load more instead of by number of topics, thus "When the gap is in the range 3 windows above current viewport to the top 66% of the viewport..." That way if the topic above or below the viewport has 142 posts, Flow won't bother requesting extra topics that the user is unlikely to scroll to.
As the user scrolls around the gap can be in one side and then in another. Should this trigger both loads or abort the first?
[*] Or maybe we aren't? Shahyar later replied "Any load-more buttons above the viewport should not get triggered until they have been scrolled into view." Doing so avoids requesting topics that might never be shown, but it's bad for the user illusion of scrolling around a complete board.
Between Shahyar, Pau and S, this is getting into good shape for Matt to work from. There are still a few questions that we need to figure out:
*#1. Making the Jump behavior work properly* In the current version on flow-tests, jumping from the top of the page to topic #47 doesn't work properly. The header gets stuck at #10, and then you see a lot of topics jumping around as they get loaded. You never end up at #47. :) We need to get this part working before we tackle filling in the gap.
*#2. What are we loading when the user jumps?* When the user jumps from the top to #47, are we loading #41-50, or #45-54, or something else?
Any option is fine, but we've mentioned several versions and I don't think there's a clear consensus on which one is correct.
*#3. Can we have two in-progress loads at the same time?*Pau's model https://docs.google.com/a/wikimedia.org/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit#slide=id.g43bf42657_055 for how to anchor the user view makes a lot of sense. The behavior when you get to the loading indicator and then stop is very clear.
But what happens when the user scrolls past the loading indicator? There's already one load currently in progress. Can you have two going on at the same time?
For example:
User opens the page. -- #1-10 are loaded.
User opens the ToC, and jumps to #47. -- #45-50 loads, user is positioned at #47.
User scrolls up and sees the loading indicator. -- #36-44 load begins processing as the user is scrolling up.
User scrolls past the loading indicator to topic #9. -- Does #36-44 finish loading, or is that cancelled?
User scrolls back down to the bottom of topic #10. -- Start another process to load #11-20? Can we have both #11-20 and #36-44 in progress at the same time?
This can continue getting more complex if the user then scrolls quickly to the bottom of the page (triggering the next infinite scroll) or uses the ToC to jump to #27, in the middle of a gap.
The question is: Do we allow two in-progress loads at the same time, or do we cancel one if the user behavior triggers a second?
On Mon, Nov 24, 2014 at 12:48 PM, S Page spage@wikimedia.org wrote:
On Mon, Nov 24, 2014 at 8:29 AM, Pau Giner pginer@wikimedia.org wrote:
I illustrated some details in a document https://docs.google.com/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit?usp=sharing ...
Wau Pow , how do you make those animated GIFs :)
- I think that the issue of moving beyond a gap can be addressed by
deciding which side of the gap to fill based on the user position (more detail in the document linked above).
I think your "When the gap is in the top 66%/bottom 33% of the viewport"
works when the loading indicator in the gap is visible to the user. But we're trying to preload topics before the gap is visible.[*] I think your model still works if we extend the regions off-screen, thus: "When the gap in the range two topics above off-screen to the top 66% of the viewport then topics are loaded below the gap", then we trigger load above and "When the gap is in the range bottom 33% of the viewport to 4 topics below then topics are loaded above the gap"
With the addition of the TOC users can no longer collapse topics, so maybe Flow should switch to a window-oriented decision to load more instead of by number of topics, thus "When the gap is in the range 3 windows above current viewport to the top 66% of the viewport..." That way if the topic above or below the viewport has 142 posts, Flow won't bother requesting extra topics that the user is unlikely to scroll to.
As the user scrolls around the gap can be in one side and then in another. Should this trigger both loads or abort the first?
[*] Or maybe we aren't? Shahyar later replied "Any load-more buttons above the viewport should not get triggered until they have been scrolled into view." Doing so avoids requesting topics that might never be shown, but it's bad for the user illusion of scrolling around a complete board.
-- =S Page Features engineer
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
I think your "When the gap is in the top 66%/bottom 33% of the viewport" works when the loading indicator in the gap is visible to the user. But we're trying to preload topics before the gap is visible.[*]
Yes, preloading the topics early enough before the gap is visible should be our main goal. However, we need to decide what to do for users which scroll fast or suffer from a slow connection. The 66-33% approach helps making it consistent with the regular infinite-loading behaviour. Just as if there is a gap at the end of the current list.
As the user scrolls around the gap can be in one side and then in another.
Should this trigger both loads or abort the first?
I'm not sure on what is more effective. The initial load has some time cost for no immediate benefit, but loaded topics will be there if the user scrolls later (which may save time later). I think the answer depends how much such delay is.
maybe Flow should switch to a window-oriented decision
That sounds good, loading based on number of topics is just an estimation to get enough loaded content above/below the current viewport. Using a strategy that actually takes into account the scrolling distance may have some benefits (being less affected by topic length), but may add some complexity. A technical evaluation may be needed to identify the pros and cons of each approach.
*#1. Making the Jump behavior work properly*
Yes. I'm experiencing the same: clicking on a topi from the ToC and not getting there.
*#3. Can we have two in-progress loads at the same time?*
We need to take into account that the critical point is when the gap is visible, and with the viewport adjustments as soon as new content is loaded the gap gets quickly out of the viewport. If the user is moving around a gap,we can decide to cancel requests or let them get completed and just trigger new ones (as mentioned above, I'm not sure hat is more effective in terms of time/benefit).
If the user gets jumping around different topics, that could generate many gaps. We can decide to close some gaps when there are few topics remaining in order to avoid too much fragmentation. That is, we can normally load 10 topics around the current one, but decide to load 5 more if that closes completely a gap.
Pau
On Tue, Nov 25, 2014 at 1:04 AM, Danny Horn dhorn@wikimedia.org wrote:
Between Shahyar, Pau and S, this is getting into good shape for Matt to work from. There are still a few questions that we need to figure out:
*#1. Making the Jump behavior work properly* In the current version on flow-tests, jumping from the top of the page to topic #47 doesn't work properly. The header gets stuck at #10, and then you see a lot of topics jumping around as they get loaded. You never end up at #47. :) We need to get this part working before we tackle filling in the gap.
*#2. What are we loading when the user jumps?* When the user jumps from the top to #47, are we loading #41-50, or #45-54, or something else?
Any option is fine, but we've mentioned several versions and I don't think there's a clear consensus on which one is correct.
*#3. Can we have two in-progress loads at the same time?*Pau's model https://docs.google.com/a/wikimedia.org/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit#slide=id.g43bf42657_055 for how to anchor the user view makes a lot of sense. The behavior when you get to the loading indicator and then stop is very clear.
But what happens when the user scrolls past the loading indicator? There's already one load currently in progress. Can you have two going on at the same time?
For example:
User opens the page. -- #1-10 are loaded. User opens the ToC, and jumps to #47. -- #45-50 loads, user is positioned at #47. User scrolls up and sees the loading indicator. -- #36-44 load begins processing as the user is scrolling up. User scrolls past the loading indicator to topic #9. -- Does #36-44 finish loading, or is that cancelled? User scrolls back down to the bottom of topic #10. -- Start another process to load #11-20? Can we have both #11-20and #36-44 in progress at the same time?
This can continue getting more complex if the user then scrolls quickly to the bottom of the page (triggering the next infinite scroll) or uses the ToC to jump to #27, in the middle of a gap.
The question is: Do we allow two in-progress loads at the same time, or do we cancel one if the user behavior triggers a second?
On Mon, Nov 24, 2014 at 12:48 PM, S Page spage@wikimedia.org wrote:
On Mon, Nov 24, 2014 at 8:29 AM, Pau Giner pginer@wikimedia.org wrote:
I illustrated some details in a document https://docs.google.com/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit?usp=sharing ...
Wau Pow , how do you make those animated GIFs :)
- I think that the issue of moving beyond a gap can be addressed by
deciding which side of the gap to fill based on the user position (more detail in the document linked above).
I think your "When the gap is in the top 66%/bottom 33% of the viewport"
works when the loading indicator in the gap is visible to the user. But we're trying to preload topics before the gap is visible.[*] I think your model still works if we extend the regions off-screen, thus: "When the gap in the range two topics above off-screen to the top 66% of the viewport then topics are loaded below the gap", then we trigger load above and "When the gap is in the range bottom 33% of the viewport to 4 topics below then topics are loaded above the gap"
With the addition of the TOC users can no longer collapse topics, so maybe Flow should switch to a window-oriented decision to load more instead of by number of topics, thus "When the gap is in the range 3 windows above current viewport to the top 66% of the viewport..." That way if the topic above or below the viewport has 142 posts, Flow won't bother requesting extra topics that the user is unlikely to scroll to.
As the user scrolls around the gap can be in one side and then in another. Should this trigger both loads or abort the first?
[*] Or maybe we aren't? Shahyar later replied "Any load-more buttons above the viewport should not get triggered until they have been scrolled into view." Doing so avoids requesting topics that might never be shown, but it's bad for the user illusion of scrolling around a complete board.
-- =S Page Features engineer
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Complicated! But we have a clear precedent https://en.wikipedia.org/wiki/Mind_the_gap for the gap indicator --
1. The solution is to implement "middle" topic loading, so you can load topic X and N topics around it, as opposed to the current options of "fwd" and "rev" which only load topics before and after a given X. That way, when the content is rendered, you can jump to "ID" and no content will need to be loaded before it, even if it's at the bottom, because the viewport will be filled up.
There's no performance win for asking ONLY topic X. It's done like this for testing purposes. There's a Trello card (L110) to fix this stuff.
2. Stopping the user's scrolling is not a good user experience. It's been discussed several times now. Beyond obvious UX issues, it's an accessibility nightmare. (On a related note, the ability to turn off infinite scrolling on a per-user basis should be implemented.)
3. It already does, kind of. Whatever topic is listed in the affixed nav bar, is where you will remain. However, this is iffy because: if you are actually reading X, but scroll up a tiny bit, between A and X is a hidden "load more", but because A is very slightly in view, it is now the "topic being read". This logic can be changed to "what is the topic in the middle of the viewport" instead of "what is the topic at the top of the viewport".
4. This can be solved by moving the load-more buttons INTO the individual topics, so that they are always affixed to the correct location. Otherwise, what the code does is: sees 1 2 3 [loadmore 4 5 6], does 1 2 3 -insert 10 11 12- [loadmore 4 5 6]. If that loadmore is in the container for topic 3, it won't move.
5. Sounds like a bug. jumpTo a topic should not trigger loadMore except for below-the-fold. Any load-more buttons above the viewport should not get triggered until they have been scrolled into view.
--Shahyar
On Fri, Nov 21, 2014 at 3:57 PM, S Page spage@wikimedia.org wrote:
It's great Shahyar has got the TOC in a state where we can see jumping down working. Try it at http://flow-tests.wmflabs.org/wiki/Talk:Sandbox (please don't add or hide/delete topics to this, it's crafted specially to test TOC. You can experiment on Talk:Flow_QA or your own user_talk page.)
If you click on e.g. topic 73 it works strangely (try it and see). We think Flow is trying to load topic 73 but it's at the bottom of the page which triggers loading topics 11-20, and then the view jumps around as topics show up.
We knew this would be hard to get right. Danny and I explored some use cases.
- You click on topic 73 and there's a gap above it.
- TOC requests that topic and some topics around it (e.g. N-3 through N+7)
- TOC disappears
- Flow shows a Loading more animation at the bottom of the page and
positions the view at it.
- When the topics show up, Flow positions topic 73 just below the fixed
header as usual.
While this is in progress, we need to disable the usual bottom of page Load more behavior -- don't try to load 11-20. There should only be one load going on at the very bottom of the page.
(Note ErikB doesn't think there's a performance win in asking for only topic 73 then making separate API requests for topics 69-72, etc. Nor is it easy to provide a variable response "Give me enough topics to fill four [PageUp] operations from topic 73")
When Flow adds topics 70-77 to the page I think we need a "gap indicator" at the top of them to indicate there is a gap but Flow isn't yet trying to load stuff to fill it. On a fast computer and connection the user might never see this.
- You scroll up from topic 73
Because Flow has loaded some topics above 73, you can scroll up into content above, preserving the illusion of perfect scroll. As you get closer to the gap (topics 11-69), Flow tries to fill in the gap to preserve the illusion of a complete page. When scrolling up into a gap Flow should always load bottom-up, i.e. it requests topics 60-69. The dormant "gap indicator" turns into the active Loading more animation
The problem is, while this is going on the user can scroll around past the gap indicator/Loading more animation. Quiddity and I think that's fine and Flow should let the user freely move around in the browser window; Danny would like to stop the user scrolling past the gap -- "You wanted to scroll up to some topics above, Flow is loading them, sit tight."
- You scroll away from a loading more gap.
In either 1 or 2, you can scroll away from the gap in at least one direction, or you can open the TOC and jump somewhere else altogether. When the API request returns the topics intended for the gap, Flow inserts them. Question: do we reposition the view? Yes for the click in the TOC, but unclear for scrolling around. I'm not sure what the default browser behavior is if you insert a bunch of content in the DOM above what the user is viewing.
- You scroll back into the gap
After loading topic 73 and scrolling up a bit, say you jump to top of page, then scroll back down towards topic 10. Flow is still filling the 11-69 gap with topics 60-69. Now you're scrolling down into the gap, you probably want the usual Load more behavior, so Flow should request topics 11-20.
- Should there be two loading indicators in the gap? I think so, a gap may
be being filled from the bottom and from the top at once.
Furthermore, you aren't near the bottom of the view because topics 70-77 are there, so if you're holding down the space bar or scrolling in order to force loading more topics, it won't work. You'll scroll right past the gap and into the topics lower down. I think this is OK, you're probably back on a quest to get to the "end" of the board.
- Now you bring up the TOC and click topic 49
Like step 1 above so
- TOC requests that topic and some topics around it (e.g. 46 through 56)
- TOC disappears
- Flow shows a Loading more animation ...
where? The one gap is loading topics 60-69 from step 2 and 11-20 from step 4, now it's loading a third group!
I'm sure there are further use cases and challenges. Next step is probably for Matt, Shahyar, Pau, Danny, to explore this with other interested parties.
Some design approaches we aren't pursuing:
- Detailed "68 missing topics", "load/loading 10 above" messages or
controls -- Flow only shows the Loading more animation in the gap.
- Flow knows the topic titles in the gaps from the TOC, but it doesn't
show them -- Flow only shows the Loading more animation.
- Flow doesn't communicate the size of the gap. unlike e.g. a PDF viewer
it doesn't know how tall topics are. It just places a Loading more animation in the gap.
-- =S Page Features engineer
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee