On 20 October 2014 09:57, Pine W <wiki.p...@gmail.com> 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 Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
