Dan,

Thanks for the responses.

* Glad to hear about the use of the active editor statistic for measuring success.

* The Signpost front page turns into long strings of vertical text when I look at it on mobile. Try viewing https://en.m.wikipedia.org/wiki/Wikipedia:Signpost on a display with a width of 400 pixels.

* Understood about the hamburger icons, though I think it's a little much to have two of them.

* Thanks for the info about onboarding.

* Understood about VE.

Pine

On Tue, Jul 29, 2014 at 5:54 PM, Dan Garry dgarry@wikimedia.org wrote:

Hey Pine.

Firstly, preamble. The goals of the Mobile Apps team are around increasing the quality and quantity of content available on Wikipedia. In order to quantitatively measure our success, we use the active editors metric, which is "number of registered users that have made 5+ edits". This is for practical reasons, as active editors is an organisation-wide and is useful a quantitative measure in spite of its weakness. Our goal is to increase the number of active editors!

So, responses in-line!

On 28 July 2014 14:40, Pine W wiki.pine@gmail.com wrote:

...

• Full text search functionality

We're thinking about getting a minimal form of this in like we have in Mobile Web. But it'll require a bit more thought before we can get started as we have to weight it against our other goals that more directly increase active editors.

That said, some of our Android engineers are working on full-page search functionality in their 20% time. For context, "20% time" is a thing that we stick to loosely that says that engineers are free to work on whatever interests them for 20% of their time, because sometimes really awesome things come out of really random ideas.

• Compatibility with Signpost front page template

...

I'm unsure what you mean by this. Can you explain?

• Support interwiki linking such as to Meta

...

I'm unsure what you mean by this too. I know what interwiki links are, but you can easily add them using wikitext editing and then access them using the button in the overflow menu.

• Condense the options panels from the left and right hamburger icons to a

...

single icon

This request is actually contrary to our style guidelines on these two menus. For the most part, application-level settings are contained in the hamburger menu and page-level settings are contained in the overflow menu. The exception is the font and theme selector, with the rationale that you need to test it on the page that you're on before you finalise the settings.

• More emphasis on encouraging people to edit

...

This is really important to us. Right now we're working on a special screen to help people that tap edit for the first time. And later we plan to add information to the onboarding screen to encourage people to edit. We need to be deliberate about this though, so that we're sure that we don't annoy our substantial reader base.

• VisualEditor fuctionality

...

For purely practical reasons this is not going to be done any time soon. For reasons I'll admit I don't fully understand yet, this is really *really* complex and could well represent over a year's worth of work for several full-time engineers. :-(

Thank you very much for your feedback. :-)

Dan

-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

Hi Bernd,

As a user, I would prefer to have all Wikimedia sites accessible within the app. Is that on the dev roadmap?

You are correct about the Signpost spaghetti, my apologies.

Is it possible to locate all 3 menu buttons on the right side of the search bar? The current setup is a bit awkward, though I realize that in constrained space with multiple languages there is only so much you can do and my proposal might cause other issues like cramped icons. A user survey might produce some good design feedback.

Pine