Mobile-l September 2014

mobile-l@lists.wikimedia.org

35 participants
51 discussions

Pulling the Commons app
by Derk-Jan Hartman 28 Nov '14

28 Nov '14

I propose we remove the Wikimedia Commons app from the store. Clearly there is no time available to work on it, there is no one maintaining it or following up on the problems that have been reported since 2013. Yann is just brining it up on wikimedia-l and I think that it is bad to have an app out there that no on is taking care of. So we should pull it and whoever wants to continue with it can release it under a name of this own. DJ

11 24

Thinking about offline search within our native apps
by Tomasz Finc 01 Oct '14

01 Oct '14

As the zero team starts to think about pre-loaded content the question of how search will function within an off line environment has come up. While it'll be up to each individual community to think about the size of the pre-loaded we should think about these collections being longer than a user would want to scroll through given only our article title search. Thus i'm eager to get a discussion going abut how we would support the following users story "As a user who has a Wikipedia pre-loaded device with little or no internet connectivity, I would like to search by article text, so that I can find multiple articles that could be relevant to me" Given this, an article title search is not good enough. * What would we have to change about our underlying data storage architecture to do full text search? * How fast would it be? * Would it scale to 100's/100's/etc on articles ? * What would the user experience look like? ... * ... other bits i haven't thought about ? This is not at a resourced feature level discussion yet but I'd like to get some engineering thoughts on it before we get there. --tomasz

4 3

Fwd: [MediaWiki-Core] Library infrastructure project ideas
by Dan Garry 30 Sep '14

30 Sep '14

Bryan, one of the engineers in the MediaWiki Core Team, is starting to look at making MediaWiki have more of a library-based structure instead of being a gigantic monolith. In particular, he asked one question which is of relevance: "What functionality from MediaWiki do you miss when you write a standalone PHP app?". As this is about MediaWiki internals this may only be of limited relevance to the Mobile Apps Team since we consume MediaWiki content via the API, but I thought I'd forward it here anyway in case anyone has any questions or suggestions for Bryan. Dan ---------- Forwarded message ---------- From: Bryan Davis <bd808(a)wikimedia.org> Date: 29 September 2014 23:07 Subject: [MediaWiki-Core] Library infrastructure project ideas To: mw-core-l <mediawiki-core(a)lists.wikimedia.org> I've started an etherpad [0] with some ideas about what we could try to do for the Q2 Library infrastructure project. Since this morphs a bit every time two or more of us talk about it, I'd like to get some collective notes/input before we walk into the quarterly review to pitch the idea and let the group there tell us what we should be doing. I know that I want to finish the logging work. I think this can be used as a good example of how to consume external libraries in MediaWiki core as well as helping solve a real deficiency in our existing code base. My RFC on the topic is a good start but the processes and procedures outlined there need to be published in a more visible place on wiki and battle tested for deficiencies. I think I'd also like to see the Profiler work done as I've heard that many components in MediaWiki are basically only tied to logging and profiling. I'm totally willing to be persuaded that there is a better candidate for extracting into a library however. One question I'd like to ask is "what functionality from MediaWiki do you miss when you write a standalone PHP app?" Database? Caching? I18n bits and pieces? Is one of these more compelling for extracting and publishing than the profiler? I'd also like to hear ideas about how we should be documenting the extracted libraries. Should we have a different workflow for generating docs from code? Is publishing docs as wiki pages a good, bad or meh idea? If we don't document on wiki how can we encourage document contributions from casual users? If we do document on wiki how can we ensure that changes in the API are propagated to the documentation soon after merge? How important is localization for code documentation? In case you are wondering "who put Bryan in charge here?", the answer is RobLa. :) Following in the model of the HHVM project where Ori has been acting as project manager / product owner, RobLa has tapped me to take the lead on organizing the library infrastructure project if it gets green lighted. I'll need a lot of help since I still don't know as much about MediaWiki itself as our average 13 year old contributor, but I hope I can be of service with my experience in project and product management. [0]: https://etherpad.wikimedia.org/p/MWCoreLibraryInfrastructure Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855 _______________________________________________ MediaWiki-Core mailing list MediaWiki-Core(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-core -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

Individual Engagement Grant funding available
by Pine W 28 Sep '14

28 Sep '14

Forwarding from Siko Bouterse: Greetings! The Wikimedia Foundation Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. <https://meta.wikimedia.org/wiki/Grants:IEG> Your idea can improve Wikimedia projects by building a new tool or gadget, organizing a better process on your wiki, conducting research on an important issue, or providing other support for community-building. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to funding for a team to help you. The program has a flexible schedule and reporting structure, and Grantmaking staff are there to support you through all stages of the process. Do you have have a good idea, but you are worried that it isn’t developed enough for a grant? Put it into the IdeaLab, where volunteers and staff can give you advice and guidance on how to bring it to life. < https://meta.wikimedia.org/wiki/Grants:IdeaLab> Also, IEG will be hosting three Hangout Sessions for real-time discussions to help you make your proposal better - the first will happen on September 16th. < https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events> For inspiration, you can read more about past projects < https://blog.wikimedia.org/tag/individual-engagement-grants/> that received funding or review open proposals < https://meta.wikimedia.org/wiki/Grants:IEG#ieg-reviewing>. We are excited to see some of the new ways your grant ideas can support our community and make an impact on the future of Wikimedia projects. Submit your proposal in September! < https://meta.wikimedia.org/wiki/Grants:IEG#ieg-apply>

1 1

need for an app? (was: [Wikitech-l] Future platforms, devices, and consumers)
by svetlana 27 Sep '14

27 Sep '14

(Duplicating this mail, as I wasn't subscribed to mobile-l a minute ago.) On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: > [...] > The Wikipedia app is currently under good development and I think its doing > great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana

6 10

Quicker = more edits on mobile
by Jon Robson 27 Sep '14

27 Sep '14

Background: * A patch got merged Fri Aug 29 [A] that bucketed 50% of edits so they would reload the page after an edit (test A), and 50% of edits would re-render the page in JavaScript using an ajax loader (test B) * The patch went live on English Wikipedia on the 11th September. Method: * I looked at an arbitary 7 day period before the 11th September (27th August till 4th September) and I looked at an arbitary 7 day period after the A/B test went live (12th till 19th September) * I counted successful edits via the mobile interface on English Wikipedia, restricted to the stable mode of the site and to the source editor only (not VisualEditor interface). This would minimise variance between the interfaces that could happen across different projects/languages/experimental features. * I looked at the exact same 7 day periods but this time restricted them only to editors with less than 5 editors to restrict the data to new editors. * I counted edits across all projects and how they varied post A/B test Results: Table 1: For the 7 day period before the A/B test [1]. isTestA Successful edits 0 9883 1 11097 Table 2: For a 7 day period after the result went live [2]. isTestA Successful edits 0 8835 1 7011 Table 3: For the 7 day period before the A/B test where the editors at the time of completing an edit had less than 5 edits [3] isTestA Successful edits 0 4276 1 4449 Table 4: For the 7 day period after the A/B test where the editors at the time of completing an edit had more than 5 edits [4] isTestA Successful edits 0 3359 1 2707 A breakdown per project can be found here generated using this SQL query [5]: https://docs.google.com/spreadsheets/d/11RFrOd4CBVk2hXIHjbSz8SPyMH7GlARUkNb… Analysis: Pre-A/B test for all editors, 1214 more edits occurred in bucket A (5.7%). See Table 1. You'd expect these to be the same. This raises concerns that there might be a problem with the A/B bucketing. However if you look at table 3: Pre A/B test for editors with less than 5 edits, 173 more edits occurred in bucket A (1.9%). Post A/B test for all editors, 1824 more edits happened in bucket B according to table 2 (11.5%) Post A/B test for editors with an edit count of less than 5, 652 more edits happened in bucket B according to table 4 (10.7%) * Considering the shift of successful edits from occurring in bucket A to bucket B, it is possible that ajax loading a page is generally getting us more edits. It seems that looking at new editors (edit count less than 5) is a more accurate way to compare the two sets of data. * This could possible be because the page reloads quicker, and a user is more likely to see a mistake and do a follow up edit or to get a better experience from editing (finds it quicker and more pleasurable.) I'd suggest more investigation into this but this data is pretty fascinating. Please do tear apart my method/investigate further. Links____ [A] https://gerrit.wikimedia.org/r/#/c/155675/ [1] select event_isTestA, count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20140827000000 and timestamp < 20140904000000 and event_editor = 'SourceEditor' and wiki ='enwiki' and event_mobileMode = 'stable' group by event_isTestA [2] select event_isTestA, count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20140912000000 and timestamp < 20140919000000 and event_editor = 'SourceEditor' and wiki ='enwiki' and event_mobileMode = 'stable' group by event_isTestA [3] select event_isTestA, count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20140827000000 and timestamp < 20140904000000 and event_editor = 'SourceEditor' and wiki ='enwiki' and event_userEditCount < 5 and event_mobileMode = 'stable' group by event_isTestA [4] select event_isTestA, count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20140912000000 and timestamp < 20140919000000 and event_editor = 'SourceEditor' and wiki ='enwiki' and event_userEditCount < 5 and event_mobileMode = 'stable' group by event_isTestA [5] select event_isTestA, wiki, count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20140912000000 and timestamp < 20140919000000 and event_editor = 'SourceEditor' and event_mobileMode = 'stable' group by wiki, event_isTestA order by wiki,event_isTestA

3 4

Data: Anon editing in mobile web
by Jon Robson 26 Sep '14

26 Sep '14

Thanks to Florian Schmidt, we have anonymous editing available in the alpha mode of the mobile website. He asked me to take a look at the data and it seems as expected usage is low (since not many people use the alpha) but it does give us an idea of the sort of edits we might expect on mobile web (although the very act of getting to the alpha is a bit of a challenge so should be taken lightly. The current strategy is to review anonymous editing via the mobile app, although personally I think this is dangerous to use as the sole basis, as when downloading an app, I might assume that the app can somehow be associated with my phone and this might lead me to be on better behaviour :) Anyway you can find anonymous mobile web edits here [1]. At time of writing this gives us a sample of 10 edits [2] including 3 edits to the same article. The user that did 3 edits did constructive edits. The other 7 consisted of 4 constructive (or seemingly good faith edits and 3 vandalisms. [1] https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&… [2] https://en.wikipedia.org/w/index.php?title=Naqshbandi_Hussaini_Golden_Chain… https://en.wikipedia.org/w/index.php?title=St._Joseph_High_School_(Connecti… https://en.wikipedia.org/w/index.php?title=Dirt&curid=24494046&diff=6267029… https://en.wikipedia.org/w/index.php?title=Neath&curid=290509&diff=62653510… https://en.wikipedia.org/w/index.php?title=Straight_Line_Stitch&curid=31508… https://en.wikipedia.org/w/index.php?title=List_of_WordGirl_episodes&curid=… https://en.wikipedia.org/w/index.php?title=East_Point_Mall&curid=18055072&d… https://en.wikipedia.org/w/index.php?title=East_Point_Mall&curid=18055072&d… https://en.wikipedia.org/w/index.php?title=East_Point_Mall&curid=18055072&d… https://en.wikipedia.org/w/index.php?title=White_Fence&curid=31049320&diff=…

2 1

[Apps] Refactoring work on iOS
by Dan Garry 26 Sep '14

26 Sep '14

Hi everyone, *tl;dr: The Mobile Apps iOS Engineering Team is doing some refactoring of network operations and data storage in the iOS app. Track our progress using the red and purple filters on our Trello board <https://trello.com/b/zgT6XuU6/mobile-app-sprint-40-ios-insert-theme-9-15>.* The iOS team has been working on the "Update all for saved pages" story this sprint. The work is taking much longer than expected due to some antiquated code in the app that handles network operations and data storage. The code is fragile, which creates peculiar crashes that are difficult to diagnose, it's hard to maintain, and it's difficult to develop on. "Update all for offline reading" in particular involves one synchronous process (the downloading of the data) talking to another (the saving of the data) in the background while there are other tasks going on in the main thread, which is a difficult enough problem to deal with without also dealing with antiquated code. This problem needs to be dealt with. Rather than delaying dealing with it, we decided to tackle it head on. Our two high-level objectives for the refactor are: - Migrate from our custom network operation code to the AFNetworking library, a well-maintained open source networking library. - Migrate our data storage system from Core Data to using a flat file system. This translated into a list of 11 action items, which are recorded on on our Trello board <https://trello.com/b/zgT6XuU6/mobile-app-sprint-40-ios-insert-theme-9-15> using the purple (networking refactor) and red (storage refactor) filters. In terms of priorities, this refactoring effectively blocks the "Update all for offline reading" story. That said, a sprint represents a commitment to completing the stories in said sprint, so we are going to complete everything in our current sprint that is not dependent on the refactoring before we begin the refactoring itself. If you have any questions, please do ask! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

4 6

Feedback of iOS WIkipedia 4.0.3 by Josve05a
by Jonatan Svensson Glad 24 Sep '14

24 Sep '14

I'm using an Apple iPad mini (1st gen), on iOS 8.0 (12A365).When logging in, the button should say "log in", and not "done".There is a lot of "blank"/whitespace at the bottom of every page.Pressing "W" should make the "Black" a little transparent, and not compleatly black.Pressing the "share"-button makes the app crash.There is nothing in the about privacy policy or disclamers (like in the bottom of the website).Make it possible to drag the "W" and "lines" and not just the sides.When searching: if only a few results show, the rest of the space with no results, should not be white, but transparent.I'm unable to delete specific pages from the "Saved pages"-page.

4 3

[Mobile web] Results from guerrilla testing of WikiGrok version A
by Maryana Pinchuk 24 Sep '14

24 Sep '14

Abbey and Daisy did some live user testing of WikiGrok version A out at Yerba Buena yesterday – here's their full write-up: https://www.mediawiki.org/wiki/Guerrilla_Testing_Wikigrok_Version_A A few actionable/interesting takeaways: 1) This version (in-line) is definitely less obtrusive to the reader experience than the pop-up overlay of the initial WikiGrok prototype; people didn't react strongly to it and didn't seem to think it was anything unusual or surprising. I think this is a good sign – it means we're more likely to get answers from people who are carefully reading the article and notice the call to action, not random button-mashers ;) 2) The UX is very easy to use, virtually painless. Good designin', Moiz! The only potential issue is that the tap events are being triggered a bit inconsistently. You can see it for yourself if you play around with it on beta labs – sometimes it takes awhile for the buttons to register a tap, and if you're impatient and tap a few times, you might accidentally end up on the second screen tapping on "yes" before you've even had a chance to read the question. Might need to investigate ways to improve this (Juliusz's Microtap stuff?). 3) People thought this might be an alternative to editing or a new way to edit. A few who'd tried unsuccessfully to make an edit in the past even pointed out how much better/easier this is. Early days and small sample size, but it's cool to get a bit of validation of the hypothesis that we can engage a much wider audience with a feature like this, including people who would never otherwise contribute to Wikimedia projects :) -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l September 2014