I think that collapsed headers supports an "overview" scenario that is
really important.
In order to support the "Immersive reading" experience without breaking the
"overview" one we can experiment with the following:
1. Show sections collapsed initially.
2. If (and only) a section is expanded, when scrolling reaches the end of
the current section, next section starts to expands as you scroll.
3. If scroll is triggered from the sections itself, they do not expand.
I attached a quick sketch.
Pau
On Tuesday, September 17, 2013, Jon Robson <jrobson(a)wikimedia.org> wrote:
Thanks so much for all the discussion so far.
I'm not so sure about infinite scroll I need to think more about this. It
seems
wrong to me as there are always a finite amount of sections (so it's
never truly infinite or close to looking like infinite) and these sections
are already in the HTML so it seems wrong / unnecessary to hide them.
That said I think there are benefits to both
approaches of the existing
behaviour - one where they are all open (and can be
collapsed) and one
where they are all collapsed (and can be open)
I think a sticky preference would be best that uses a
combination of
localStorage and user preferences (the latter taking preference). I
think
such a setting could be surfaced as a simple toggle control at the bottom
of the footer (although I'm not sure what the icon would look like).
We could also imagine 'learning' a preference
based on behaviour by a
user (do they always open all the sections they come
across?)
Personally the current setup only makes sense to me if
the page loads
quicker due to not serving the html inside sections and loading the
content
of those sections only when the section is toggled open (ie. lazy loading
content of sections). In the current form we serve all the content and due
to this there is an inevitable flash of the section collapsing as the
JavaScript and entire page has loaded.
I'm not sure I agree with Steven's assessment
that this will make
navigating between sections difficult - behaviour gets reverted
- you close
the section to see the next section. This is akin to flicking through a
book and flicking to the next page (closing the section) if the heading at
the top of the page doesn't interest you. It just means you don't see all
the headings in one go which could be a good or bad thing.
Is there an A/B test we could do here? In situation A
we show all
sections open by default on say the Barack Obama article and in case B
show
all sections closed by default (note this is a simple line of JavaScript).
If we were to do this what would we be optimising for?
* Would it be how many sections are collapsed?
* What % of the article is read (could equate to how far down the article
a user
gets)?
I think this matter can be solved by collecting
data...
On Tue, Sep 17, 2013 at 10:29 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
Resending now that I'm on the design(a)lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
There's been some additional discussion on this, taking search engine and
Find
in Page optimization into account.
some Find
in Page-oriented stuff)
The smart search engine / Find in Page stuff is moderately complex, so I
think the
tappable options for section expansion are the place to start.
It seems to me that the following achieves TOC-like
information at a
glance while balancing page load performance, usability, user
choice, and
user choice measurement:
* Don't auto-expand articles by default
* Do have a JavaScript-injected "Expand Sections" / "Collapse
Sections"
feature at the top of articles with multiple sections
* Do have a user preference for Auto-Expand Sections
on Article Load.
* To gauge love/hate for features, have two preferences as follows
Show 'Expand/Collapse Sections' Option at Top of Articles
On / Off (default = On)
Auto-Expand Sections on Article Load
Note: this may slow page load time
On / Off (default = Off)
On Mon, Sep 16, 2013 at 4:20 PM, Jared Zimmerman <
jared.zimmerman(a)wikimedia.org> wrote:
I like the idea of expanding by default because it fixes my pet peev of
not being
able to do a find on page from my mobile browser without first
expanding all sections.
Jared Zimmerman \\ Director of User Experience \\ Wikimedia
Foundation
M : +1 415 609 4043 | : @JaredZimmerman
On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf <
psychoslave(a)culture-libre.org> wrote:
I didn't followed the thread, but if you try to consult the french
wiktionary with the mobile interface it's impossible: section title
--
Pau Giner
Interaction Designer
Wikimedia Foundation
