Mobile-l March 2015

mobile-l@lists.wikimedia.org

45 participants
58 discussions

[Apps] Improving Android release cadence
by Dan Garry 12 Mar '15

12 Mar '15

Hi everyone, There is a long time between production release on Android. The reason for this is because we have featured merged into master that are sound from an engineering standpoint, but aren't quite ready for release yet. These features often block production releases. As product owner, pushing out regular bug fix builds would make me very happy! But there is a requirement that we are able to not push out features that are merged but not ready for production yet. This can probably me managed by feature flags. Dan Duvall (on cc) from Release Engineering will consult to help Dmitry and Bernd figure out what their process should be for maximum effectiveness. Thanks! Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

7 12

Problem i met with wikimedia_android app
by cxyshine＠yeah.net 12 Mar '15

12 Mar '15

hi there: i really need help for my wikimedia_android app. it is not easy to study the project ,since i don't know where i can get the design documents about the android app . i have study wikimedia_android app for about a month(download from https://github.com/wikimedia/apps-android-wikipedia) ,i also build a mediaWiki (download from https://www.mediawiki.org/wiki/Download) on my wampserver (i didn't install any extentions on mediaWiki,i don't know what Extentions i need to install) . In left menu of app ,there are functions such as : Log in , Today , History ,Saved pages ,Nearby ,Random What i want to do is that i tried to build my own android app which will connect to my local mediaWiki server (192.167.137.1) to get all the data the app need.And all the functions (Log in , Today , History ,Saved pages ,Nearby ,Random ) work well. What i have done : i modify the domain = "192.168.137.1", language ="zh" in Site.java because of that my app can register and login ,app communicates well with my local mediaWiki server. and it will show my username in left menu. Problem i met: after i click "Today" ,the page of Today did not display on my android phone and i got these message : 03-11 15:35:46.176 31202-31202/org.wikipedia.alpha D/Wikipedia�s Using packaged styles 03-11 15:35:46.201 31202-31202/org.wikipedia.alpha W/AwContents�s nativeOnDraw failed; clearing to background color. 03-11 15:35:46.261 31202-31202/org.wikipedia.alpha D/Wikipedia�s Using packaged styles 03-11 15:35:46.276 31202-31202/org.wikipedia.alpha W/AwContents�s nativeOnDraw failed; clearing to background color. 03-11 15:35:46.636 31202-31202/org.wikipedia.alpha I/chromium�s [INFO:async_pixel_transfer_manager_android.cc(60)] Async pixel transfers not supported here is my question: 1: I don't know what happened ,why the page of "Today" did not display ? 2: Is that because I didn't install any extentions on my local mediaWiki ? I saw "Mobile Web" and "Extension:MobileFrontend" in https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering .If that true ,what Extentions do i need to install and how ? 3: Or maybe i need to write some php program in my local mediaWiki server ? because it is my local server not Wikipedia server which may have some php program achieved by it's team 4: the function "Nearby" and "Random" also didn't work,is that the same reason with "Today" ? if not ,what maybe the reasons ? 5: Are there design and api documents about the android app , and where i can get the documents ? 6: Are there design and api documents about the mediaWiki , and where i can get the documents ? I am now really confused with the project ,i have been working on that problem for two days but get nothing, I really hope someone can help . thanks a lot ! shine cxyshine(a)yeah.net

2 2

Mobile Scale
by Corey Floyd 11 Mar '15

11 Mar '15

Well specifically iOS… but most of the articles in this issue are about process and how they collaborate. I highly recommend checking out when you have a moment. They are pretty quick reads and well worth it. The one by Artsy actually focuses on open source. http://www.objc.io/issue-22/ (And if you haven't already, you can subscribe to the monthly mailing list)

2 1

Re: [WikimediaMobile] Node.js service prototype for mobileapps
by Yuvi Panda 11 Mar '15

11 Mar '15

On Tue, Mar 10, 2015 at 11:30 PM, Dan Garry <dgarry(a)wikimedia.org> wrote: > > On 10 March 2015 at 10:33, Bernd Sitzmann <bernd(a)wikimedia.org> wrote: >> >> A few questions for you: >> * Is (a) enough for https://phabricator.wikimedia.org/T91794? >> > > No. One of the primary objectives for doing this is so that we see what > the pain points are of actually deploying this to production, to decide > whether to make a further investment into the service. Deploying it to Beta > Labs doesn't meet this objective at all. > +1. So IMO the thing you are actually testing is the *process* of getting this into production, not the software itself. Putting it in beta is part of the process of getting it into production, but as such is useless if it stops there. Beta is just a place to test the software itself, and the most risky thing here is not the software itself, but ops/tech-community/core acceptance of doing things like this. Only getting it to production will help shake it out, for you and other teams that follow in your wake :) There's a lot of unknowns along that path, so good luck :)

3 2

iOS app: Xcode "Simulator already in use" message when trying to run project...
by Monte Hurd 10 Mar '15

10 Mar '15

I've run into this quite a bit, and it's super annoying as, once this message is shown, it seems Xcode can't run the project in the simulator until you restart Xcode. What I've found seems to help is always hitting *command-period* before tapping *command-r*. ymmv

2 1

Re: [WikimediaMobile] Node.js service prototype for mobileapps
by Tomasz Finc 10 Mar '15

10 Mar '15

On Tue, Mar 10, 2015 at 10:49 AM, Max Semenik <msemenik(a)wikimedia.org> wrote: > As a shared virtualized environment, Labs is not appropriate for performance > measurements. Also, its SLA is too lax for production app use. Moving back to mobile-l@ It's less about it being not appropriate for perf tests and more so that you can't directly compare bare metal to a virtual instance. Load testing virts against virts is fine as long as your factor the drift in shared resourcing. As for LABS production use I'm curious about would it would take to make this work in the future. LABS is a low cost env to spin up hardware that is easily discarded after. To me this is critical in supporting our engineers teams experiment with low cost. I know that isn't something that we do currently but either we need to get production into a state where its simpler to spin up new production instances/products/extensions/etc or we allow LABS to take some small production traffic for experiments. CC'ing Yuvi to get his thoughts. --tomasz

3 2

Re: [WikimediaMobile] Readability of the first sentence on Wikipedia articles
by Dan Garry 10 Mar '15

10 Mar '15

(moving to mobile-l) Thanks Vibha, this is really informative. It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is. So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better. Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), the long term solution is, at least to me, to invest in is getting our engaged readers to write clear, coherent Wikidata descriptions. These can then be used across all platforms to support that workflow. Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it. Thanks! Dan On 6 March 2015 at 16:13, Jon Robson <jrobson(a)wikimedia.org> wrote: > Any reason this is on mobile-tech and not mobile-l (I'd love to hear from > people like Amir on this subject)? It would be good to flag this problem to > a wider audience and part of our problem with most mobile issues is people > just are not aware of this sort of thing. Many probably haven't even heard > of the hemingway app... > > It would be interesting to see how a wikidata generated first sentence > would score with the same app. > > On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > >> Hi Folks, >> Kaity and I used the Hemingway app <http://www.hemingwayapp.com/> to >> analyze the readability of our first sentence, using a few articles. They >> all scored poorly, an ideal grade level of 10 is recommended for clear bold >> writing. >> >> This difficult problem arises from the first sentence containing one or >> more of the following: >> >> - IPA Keys >> - Birth/ death dates >> - Other Names/ AKA's >> - Help/info links >> - Alternate spellings and scripts >> - Additional details >> >> Details like dates are replicated in the infobox, if it exists in the >> article. >> Other templates such as AKA's/IPA's are extremely useful but need to be >> presented in a clear and structured manner. Some of this comes from the Manual >> of style >> <https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_…>, >> but it is abused in many cases. >> >> Its sad, because many readers come to Wikipedia to answer the 'What is >> this/ who is this' question. Google Knowledge panel strips out all brackets >> and presents important details as a list, under the description. >> >> We have started investigating solutions for this on mobile. I would >> encourage you to try this out on mobile web or apps. >> >> Thanks >> Vibha & Kaity >> >> --- >> >> Articles we used: >> Bern <https://en.wikipedia.org/wiki/Bern> >> Genghis Khan <https://en.wikipedia.org/wiki/Genghis_Khan> >> Cephalopod <https://en.wikipedia.org/wiki/Cephalopod> >> Mahatma Gandhi <https://en.wikipedia.org/wiki/Mahatma_Gandhi> >> Nietzsche <https://en.wikipedia.org/wiki/Friedrich_Nietzsche> >> Carthage <https://en.wikipedia.org/wiki/Carthage> >> Phoenicia <https://en.wikipedia.org/wiki/Phoenicia> >> Timur <https://en.wikipedia.org/wiki/Timur> >> >> >> >> ---- >> Vibha Bamba >> Senior Designer | WMF Design >> >> >> >> >> >> >> > -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

9 13

[Apps] New version of Wikipedia Beta released today
by Dan Garry 10 Mar '15

10 Mar '15

Hi all, We released a new version of Wikipedia Beta today! There were two notable changes: * "Read Next": an experimental feature which displays a single, visually appealing suggestion for what you can read next after you've reached the end of an article, replacing the three "Read More" results. This feature is only shown to 50% of users, with the other 50% continuing to see "Read More"; we will use data on which one is used more by our users to decide which to show in the production app. * Fixed a crashing bug caused by highlighting text on some versions of Android. Thanks to our Wikipedia Beta users helping us catch this beta so it never made it into the main Wikipedia app! As always, if you have any questions, let me know! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

Node.js service prototype for mobileapps
by Bernd Sitzmann 09 Mar '15

09 Mar '15

Hi, As part of the Node.js prototype spike <https://trello.com/c/11vVs1El/2-spike-hr-investigate-building-a-node-js-ser…>, I created a Github repo: https://github.com/berndsi/service-mobileapp-node/tree/dev Note that this is the dev branch, where I put the mobileapp specific code for now. Most info is available in the README. It tells you how to get started, install the prerequisites, and how to run and use the service. I also added a troubleshooting section at the end. As mentioned there, I had to nuke the node_modules folder a few times. Besides that, it went quite smoothly. The current version uses mobileview action as the source, and then removes a few DOM elements (via the domino node module). It uses the bluebird node module for the promises implementation, which makes async code nicer. You can try an example once you have it installed with http://localhost:6927/en.m.wikipedia.org/v1/mobileapp/lite/cat. I originally forked https://github.com/wikimedia/service-template-node but needed two repos in my Github account, so I can push template changes upstream, and another to develop the mobileapp code. Marko and Gabriel from the services team created the template and helped me getting started. Thank you! This is just a prototype. So, here's a short list of ideas we could try to make this more useful for a Mobile Lite app that doesn't require use WebViews: * Use Parsoid as mentioned in https://phabricator.wikimedia.org/T90758#1074382 * Split the "text" objects of each section into paragraph and table objects * Add some transformations that currently are being done by the apps and remove some more unneeded data Cheers, Bernd

3 3

[Apps] Summary: Sprint 53, iOS (16 March - 29 March)
by Dan Garry 06 Mar '15

06 Mar '15

Hi everyone, This is the summary of the work the Android team is planning on tackling in sprint 53. You can see the full workboard in Phabricator <https://phabricator.wikimedia.org/tag/mobile-app-sprint-53-ios/>. We're currently on track to get a production release by the end of the quarter which contains lead images, image gallery, and read more. To ensure that we remain on track, our primary priority in sprint 53 will be to fix bugs reported by our release to TestFlight, to keep our production release on track. Our significant feature backlog compared to Android has meant we've pushed really hard on features with little regard for technical debt. While putting our users needs above our own has made us all feel warm and fuzzy, we need to spend a little time tackling the technical debt that we've accumulated over the quarter. We'll be spending sprint 53 setting up a build server so that people have easier access to our alpha testing builds, and we'll be hooking up a dashboard that lets us see our unit tests running in real time. We'll also be auditing our API usage in preparation for our final release that supports iOS 6. We have two stretch goals for the sprint too: getting Jenkins to run our unit tests when a patch is submitted (which is more complicated than for other teams for a variety of technical reasons) and having our build server actually submit beta TestFlight builds to Apple automatically. We're unsure if we'll get to these tasks, so that's why their stretch goals. If you have any questions, feel free to let me know! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l March 2015