Dan and colleagues,
I appreciate the table of contents flyout in the Android app.
Would it also be possible to have sections collapsed by default, as happens on mobile web? See for example English Wikipedia's page WP:GAB for a long page that may be easier to navigate with sections collapsed by default.
Thanks,
Pine
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
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@gmail.com wrote:
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi Vibha,
Um.... If a customer is asking about a possible feature change then I would ask you to AGF, please. The change may be impossible to implement, there may be good reasons for the status quo, there may be reasonable differences of opinion, etc. In this case I am saying that I think there is a reason to collapse sections even with the TOC flyout, and I have offered an example of a page where this would be helpful. I would appreciate an explanation of how this would break the TOC structure.
Thank you (:
Pine On Oct 19, 2014 6:43 PM, "Vibha Bamba" vbamba@wikimedia.org wrote:
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@gmail.com wrote:
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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@gmail.com wrote:
Hi Vibha,
Um.... If a customer is asking about a possible feature change then I would ask you to AGF, please. The change may be impossible to implement, there may be good reasons for the status quo, there may be reasonable differences of opinion, etc. In this case I am saying that I think there is a reason to collapse sections even with the TOC flyout, and I have offered an example of a page where this would be helpful. I would appreciate an explanation of how this would break the TOC structure.
Thank you (:
Pine On Oct 19, 2014 6:43 PM, "Vibha Bamba" vbamba@wikimedia.org wrote:
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@gmail.com
wrote:
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Another good reason for not collapsing the sections in the content area is because of the Table of Contents flyout. Having collapsed sections in the content area will make the TOC flyout redundant. We wanted to address the need for collapsed sections by giving an easy access to TOC.
On Mon, Oct 20, 2014 at 9:19 AM, Vibha Bamba vbamba@wikimedia.org 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@gmail.com wrote:
Hi Vibha,
Um.... If a customer is asking about a possible feature change then I would ask you to AGF, please. The change may be impossible to implement, there may be good reasons for the status quo, there may be reasonable differences of opinion, etc. In this case I am saying that I think there is a reason to collapse sections even with the TOC flyout, and I have offered an example of a page where this would be helpful. I would appreciate an explanation of how this would break the TOC structure.
Thank you (:
Pine On Oct 19, 2014 6:43 PM, "Vibha Bamba" vbamba@wikimedia.org wrote:
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@gmail.com> wrote:
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi,
I have been playing with the app some more and I think I have found a simpler change that will solve the issue for me.
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?
I have other feature requests but this would be the most important right now. Other requests:
* Facilitate the viewing of page history within the app * Allow images to be disabled * Facilitate easy access to the Refdesk, Teahouse, and other help resources for both readers and editors
Thanks, Pine
Pine
*This is an Encyclopedia https://www.wikipedia.org/One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Mon, Oct 20, 2014 at 9:37 AM, Moiz Syed msyed@wikimedia.org wrote:
Another good reason for not collapsing the sections in the content area is because of the Table of Contents flyout. Having collapsed sections in the content area will make the TOC flyout redundant. We wanted to address the need for collapsed sections by giving an easy access to TOC.
On Mon, Oct 20, 2014 at 9:19 AM, Vibha Bamba vbamba@wikimedia.org 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@gmail.com wrote:
Hi Vibha,
Um.... If a customer is asking about a possible feature change then I would ask you to AGF, please. The change may be impossible to implement, there may be good reasons for the status quo, there may be reasonable differences of opinion, etc. In this case I am saying that I think there is a reason to collapse sections even with the TOC flyout, and I have offered an example of a page where this would be helpful. I would appreciate an explanation of how this would break the TOC structure.
Thank you (:
Pine On Oct 19, 2014 6:43 PM, "Vibha Bamba" vbamba@wikimedia.org wrote:
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@gmail.com> wrote:
Pine W, 19/10/2014 08:28:
Would it also be possible to have sections collapsed by default, as happens on mobile web?
Did you read the archives first? http://thread.gmane.org/gmane.org.wikimedia.mobile/1045 http://thread.gmane.org/gmane.org.wikimedia.mobile/507
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 20 October 2014 09:57, Pine W wiki.pine@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
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@wikimedia.org wrote:
On 20 October 2014 09:57, Pine W wiki.pine@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
To clarify, the "zooming" behavior I described is only on the iOS version of the app presently, but this feature could be added to the list of "new article styling and presentation possibilities" which would not be possible with collapsed section nav.
On Mon, Oct 20, 2014 at 4:37 PM, Monte Hurd mhurd@wikimedia.org wrote:
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@wikimedia.org wrote:
On 20 October 2014 09:57, Pine W wiki.pine@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
Thanks Monte and Dan,
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.
Pine
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Mon, Oct 20, 2014 at 4:37 PM, Monte Hurd mhurd@wikimedia.org wrote:
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@wikimedia.org wrote:
On 20 October 2014 09:57, Pine W wiki.pine@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
Responses in-line.
On Monday, October 20, 2014, Pine W wiki.pine@gmail.com 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.
That sounds good. :-)
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.
I think that's probably the best approach for you right now.
The apps represent a minuscule percentage of our reader base (~1%). In a market so heavily dominated by mobile apps, we expected it to be higher. My ultimate goal for the product is to get people contributing to Wikipedia on the app, but we need to fix the first step, the reader acquisition problem, before we consider the next. That means editor stuff like the watchlist, which would need to be implemented from the ground up in native code, is not a priority right now.
I should point out, however, that I am working on a watchlist feature for the Android app in my spare time. My first pass will hopefully be going in to the beta app soon. :-)
Thanks for your comments, and I appreciate that you are thinking about how end-users use the products.
And, thank you for taking the time to write to us about the app! We always appreciate the highly constructive feedback you give us. :-)
Dan