We can't collapse sections on the app, that would be pointless and would completely break the structure of the TOC. ---- Vibha Bamba Senior Designer | WMF Design On Sun, Oct 19, 2014 at 2:26 AM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote:

Thank Pine, I believe its first critical to understand why a user needs this. We have to understand a user's need instead of responding to an interface request. There may be better ways of serving the same need. Typically one user group tends to think for themselves, but as a UX team, we need to serve the needs of users across the board. Kindly explain. Thanks Vibha ---- Vibha Bamba Senior Designer | WMF Design On Sun, Oct 19, 2014 at 7:55 PM, Pine W <wiki.pine(a)gmail.com> wrote: _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

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?

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 <dgarry(a)wikimedia.org> wrote:

We are writing a lot of text about things that, for me, are easier to demonstrate in person, so perhaps if we visit in person sometime we can discuss this in more detail.

I think I'll use Wikipedia on mobile web instead, as it is more in line with my interests as an editor, although I love the nearby feature in the Android app and the Android app is fast so I'll probably still use it on occasion.

Thanks for your comments, and I appreciate that you are thinking about how end-users use the products.