Hi Pine,
Thanks for the feedback on the collapsed vs expanded section navigation
issue! :)
Here's some background about why we went with expanded sections for the
apps:
Somewhat counterintuitively, it was largely because of the example you
gave: really large articles.
This may seem odd. How could keeping the sections expanded make navigating
large articles easier*?
It turns out, with collapsed sections navigation, if you are reading a long
section, you have to scroll repeatedly if you are partway through reading
that section and decide it does not contain what you are looking for, or
you want to read another section. The number of these useless "extra
scrolls" depends on how long the section is, how far you've read through
it, whether the next section you wish to read is above or below the section
you were reading, and how many sections there are in the article.
So "extra scrolls" are no good. But if an article is read from top to
bottom, the reader is not really not doing any "extra scrolls". They're
scrolling as they read and simply tapping the next collapsed section title
to read it.
So what's counterintuitive about collapsed section navigation and large
articles? It's this: the longer the article is, the less likely the user is
going to read it in-order or in its entirety, and in these cases, the
number of "extra scrolls" increases with collapsed section navigation.
This is why we give the user single-tap access to the article table of
contents. With this approach, if they read from top to bottom, nothing has
changed from a swipe count perspective, but we save the user a tap for each
section they read. When the top navigation is scrolled off-screen, as you
had mentioned, we also give the user single-swipe access to the table of
contents. Additionally, when the table of contents appears, it gives you a
"birds-eye" view of the section you had been reading and also
simultaneously scrolls the zoomed out article as you scroll the table of
contents to help you quickly find other parts of the article, whether text,
images or tables, which interest you.
We do need to make it more obvious to users that a single swipe will reveal
the table of contents at any time. We have designs for a little intro for
this which is already implemented on the Android app, and will soon be on
the iOS app as well.
Additionally, not collapsing the sections opens up new article styling and
presentation possibilities which would be confusing from a UX perspective
if sections had to be manually and individually expanded or collapsed.
("in-article search" for example, but there are many more, including
inconsistencies with larger screen tablet presentations)
Did this help make the decision to go with expanded sections make more
sense? Let me know, and thanks again for the feedback!
-Monte
*(For me "easier" came down to how many touch gestures I had to do to find
what I was looking for. So, one tap or swipe gesture was easier than 4 or
6.)
On Mon, Oct 20, 2014 at 4:22 PM, Dan Garry <[email protected]> wrote:
> On 20 October 2014 09:57, Pine W <[email protected]> wrote:
>>
>> When I am scrolling down a page such as WP:GAB, the navbar at the top of
>> the page disappears, which takes the TOC icon away with it. I was finding
>> it easy to get lost in a mass of text when scrolling down the page; hence
>> my request for collapsed sections. However when I scroll up the navbar
>> reappears. Can you make the navbar remain visible at all times?
>>
>
> Our app is a reader app like Kindle, but it's also a web browser app like
> Chrome. This navbar hiding is a common design pattern on both these kinds
> of apps, as it removes the clutter and lets the user focus on long form
> reading. Given that the ToC can be summoned by swiping left even if the nav
> bar is hidden, and that the user is informed of this in the form of an
> onboarding screen the first time they go to a page with a ToC, making the
> nav bar persistent would do nothing other than damage our long-form reading
> experience.
>
> * Facilitate the viewing of page history within the app
>>
>
> What is the user story for this? "As a reader, I want to view the page
> history, so that..."?
>
>
>> * Allow images to be disabled
>>
>
> This is something we're talking about at the minute. There are a lot of
> people out there, particularly on the Android app but also on iOS, that are
> on connections that have highly restricted bandwidth. Giving those users a
> text only mode would be great.
>
> The real question is, where does the option go? It's an application-level
> setting so it should go in the More menu, but I am very *very* reluctant
> to go down the road of adding tons of preferences to the app and turning it
> into something like the preferences page we have on the desktop site.
>
> We're continuing to think about this.
>
>
>> * Facilitate easy access to the Refdesk, Teahouse, and other help
>> resources for both readers and editors
>>
>
> Many of these pages (like the Reference Desk) look really bad on the
> mobile app, and others (like the Teahouse) are demonstrably broken. For
> example, the current setup of the Teahouse triggers the browser bounce
> behaviour (i.e. often, clicking on links will take you to mobile web) so
> we'd need to fix these pages and workflows up before directing users to
> them. And, suddenly, this quick fix is a lot of work! I do not want to open
> the team up to getting sucked into a black hole of work.
>
> Hopefully this explains our thinking.
>
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>
> _______________________________________________
> Mobile-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l
