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
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
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)
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 :)
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
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
(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
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
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
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