Hey everyone, Howie and I were chatting today about the users we're expecting on Apps. We suspect that the nature of the app will attract a different user base from Web and perhaps also Desktop, and that may mean we need to tailor the features that go into the app to that user base. We'd like some data to test that hypothesis Right now the tagging system just tags all edits are made on mobile, and there's no way to distinguish between apps and web. We'd like to change that. Splitting the tags would allow us to identify users that edit just on apps and figure out if they are actually different. All in all, there's potential for creating some really awesome data to analyse. My preferred solution is for us to have three tags for Mobile: Mobile Web, iOS App, and Android app. That way, we can generate usage statistics really easily for both iOS and Android independently of each other, and also compare those to each other. There is also the possibility of tagging all edits as mobile using the current tag, then additionally tagging edits as iOS and Android respectively. That makes the numbers between Web and Apps harder to compare, so I prefer the first option. Thoughts, guys? Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

For backwards compatibility reasons could all edits be tagged 'mobile edit' and could we append additional tags for app edits? e.g. mobile edit, mobile web edit mobile edit, mobile app edit On Wed, May 14, 2014 at 1:29 AM, Max Semenik <maxsem.wiki(a)gmail.com> wrote: the test apps potential Web, really compare, -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

I strongly advise against using edit summaries. If we want to be able to filter and aggregate on revtags, parsing edit summaries is a very inefficient way to store this information; it’s also abusing the purpose of a field that was not meant to store revision metadata (the fact that antivandal tools do so is because of the lack of alternatives, not because it’s a best practice). If we want to collect granular data about the edit interface or the client used to complete an edit, the only options on the table are (1) MediaWiki tags or (2) instrumentation via EventLogging. MediaWiki tags • unless you concatenate in a single tag all relevant metadata (uggh) , they will only capture some very high level property of the revision • they are public data, exposed in revision histories, recentchanges etc • they provide hook for functionality (useful if we think people will build gadgets) • there are community expectations on what tags are good for or not that we need to be aware of EventLogging instrumentation • it would allow to capture granular information about the edit in a structured way and without the limitations of MediaWiki tags • data collected via EventLogging is currently not published/replicated to labs. This is not because the information collected is private based on the terms of the privacy policy but because we haven’t worked yet on a solution to expose this data. • EL data cannot be read off from MediaWiki, so if the plan is to enable functionality in MediaWiki based on tags, this is not an option Of course a combination of the two is also possible. The relevant questions to ask are: • how much information needs to be captured in a tag? • is this data meant to be public? • are tags expected to provide hooks for functionality in MediaWiki or are they for analytics purposes only? Dario PS the same problems of what tags to use applies to account registrations, not just revisions On May 14, 2014, at 9:41 AM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote: Makes sense to me – the other option would be to automatically generate a string in the edit summary, like vandalfighting and semi-automated editing tools do. Tags can be a little finicky to work with when you're doing data processing & analysis, because they require joining with the revision table on revision IDs. If we're capturing the relevant info in the edit summary, that's stored in the revision table and thus requires one less extra join step :) On Tue, May 13, 2014 at 4:32 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l