---------- Forwarded message ----------
From: Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.com>
Date: Thu, Apr 9, 2015 at 4:50 PM
Subject: Re: [WikimediaMobile] [Apps] Stripping content inside brackets
from the first sentence of articles
On 9 apr. 2015, at 08:44, Dan Garry <dgarry(a)wikimedia.org> wrote:
Hey Derk-Jan,
Thanks for chiming in. It's great to have your input.
On 8 April 2015 at 23:22, Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.com>
wrote:
>
> This is me waving my red flag and telling you that you are walking
> into/picking a huge fight with ‘the community’. You can’t win anything
> here, there will only be losers.
>
As a long time community member myself, I am aware of how contentious this
change is. But I disagree that there will only be losers, as there are
plenty of readers who will benefit from the change.
My experience with WMF launches shows me that there are a few golden rules:
1: Don’t do contentious changes without working on the root causes of why
some things are contentious
2: Measure the shit out of it.
3: Be prepared that it will still be contentious and rollback.
4: Analyze the data, find more solutions
> If you want to convince users that something needs to be done here, you
> should consider handing tools to the community to detect that something is
> wrong. Like https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive
I'd love to solve this more systematically. What are your suggestions for
how we could do that? We've not had much luck thinking of any so far.
Isolate:
1: Measure user response to the bracketed text
2: Graph user response to the bracketed text
3: Add graph to every single follow up action that you do
4: First add all the code to parse what is in there.
5: Log what is in there (or do it based on a db dump)
6: Classify what is in there (yes, that means manual labour, make it a
wikigrok-like game ? ) Note, the long tail is probably more interesting
here than the 80% that you already know about.
7: Ask for semantic classes and help rolling them out, so it is easier to
strip this stuff.
8: Start by stripping things that are duplicate (if in infobox then strip,
else not)
9: Selectively strip something like IPA, because you have measured that
people are not interested in it
10: Intelligently output what remains in there (if everything hidden, skip
the () altogether, take care of trailing , etc).
Hope that helps you forward.
DJ
Moving discussion over to mobile-l. Clever subject.
On Wed, Apr 8, 2015 at 6:54 PM, Brian Gerstle wrote:
> I didn't mean to suggest you can't mix and match. The author of that
> article endorses Specta/Expecta and OCMockito, but AFAIK Expecta matchers
> still aren't natively supported in OCMockito
> <https://github.com/jonreid/OCMockito/issues/56>. Whereas OCHamcrest can
> be used inside OCMockito expressions
> <https://github.com/jonreid/OCMockito#argument-matchers>.
>
> On Wed, Apr 8, 2015 at 9:45 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
>
>> Looks like Expecta / Specta are able to work with OCMockito pretty well
>> actually, so that shouldn’t be a concern:
>>
>> http://www.annema.me/why-i-prefer-testing-with-specta-expecta-and-ocmockito
>>
>> There are even some nice Xcode templates with OCMockito/Specta/Expecta:
>> https://github.com/mtynior/SpectaXcodeTemplates
>>
>> Even though we haven’t written any Swift yet, we should look into those
>> new libraries as well for completeness.
>>
>> On Wed, Apr 8, 2015 at 9:07 PM, Brian Gerstle wrote:
>>
>>> The other two new kids on the block are Quick
>>> <https://github.com/quick/quick> (BDD specs, similar to Specta) and
>>> Nimble <https://github.com/Quick/Nimble> (expectations). The main
>>> advantage of these two are Swift & ObjC compatibility (future-proof).
>>>
>>> Here's how I see w.r.t. matching frameworks, since IMO BDD stuff is
>>> orthogonal:
>>>
>>> - OCHamcrest
>>> - pros
>>> - it integrates *really* nicely w/ OCMockito (same author)
>>> - we could try to write adapters for Nimble/Expecta
>>> matchers, but IMO it's tedious
>>> - also assumes we're using OCMockito too (mocking isn't
>>> really possible in Swift yet due to the lack of a reflection API)
>>> - assertion failures are nicer than XCTest
>>> - cons
>>> - API is macro-heavy and clunky, but gets teh job done
>>> - Expecta
>>> - pros:
>>> - really nice API, even has crazy "objectification" so you
>>> don't need to box primitives (i.e. expect(YES).to(beTrue()) just works)
>>> - has async matchers
>>> - cons:
>>> - not compatible w/ any mocking frameworks AFAIK
>>> - Nimble
>>> - pros:
>>> - really nice API, similar to Expecta
>>> - also has async matchers
>>> - built with Swift in mind, but maps really well to ObjC
>>> - cons
>>> - minor, but doesn't have auto-boxing of primitives like
>>> Expecta does, but that's not necessary in swift anyway
>>> - uses bleeding-edge swift language features, so you need
>>> Xcode 6.3 beta to run it
>>>
>>> For now, Id vote for sticking w/ OCHamcrest given that we're using
>>> OCMockito. There's also OCMock, which I have experience with, which also
>>> accepts OCHamcrest matchers.
>>>
>>> That being said, we can always use Nimble in Swift tests :-)
>>>
>>> On Wed, Apr 8, 2015 at 8:59 PM, Corey Floyd wrote:
>>>
>>>> Hey guys keep forgetting to write this… We added OCHamcrest before we
>>>> really started formally evaluating 3rd party libs. So wanted to open the
>>>> discussion now, especially since we have been writing tests in earnest.
>>>> Also I hadn’t used OCHamcrest before, so wanted to try it out for a bit
>>>> before discussing.
>>>>
>>>> After looking around it looks like Expecta (
>>>> https://github.com/specta/expecta) is the other big matcher framework.
>>>> These 2 articles compare Expecta and OCHamcrest:
>>>>
>>>> http://appleprogramming.com/blog/2014/01/18/tdd-with-specta-and-expecta/
>>>> http://pivotallabs.com/expectations-in-ios-testing/
>>>>
>>>> Personally, I find the Expecta matchers much more readable to
>>>> OCHamcrest.
>>>>
>>>> This is confirmed when I read our OCHamcrest code. I notice that my
>>>> eyes have to bounce around a bit to actually understand what is happening.
>>>> The expectation is nested at the end and sometimes you jam in a description
>>>> in the middle which makes me stop and look at it for a bit. This is an
>>>> example in our code:
>>>>
>>>> assertThat((a)([self.controller.fetchedIndices
>>>> containsIndexesInRange:attemptedBatch]),
>>>> describedAs(@"batch range to be optimistically marked as
>>>> 'fetched'",
>>>> isTrue(), nil));
>>>>
>>>> I don’t know if we need to say we can only write tests using one
>>>> framework or another, but we should probably discus it as a group and then
>>>> formalize it into a best practice.
>>>>
>>>>
>>>> Related to this conversation is Specta (
>>>> https://github.com/specta/specta) which can be used with either
>>>> Expecta or OCHamcrest but adds some BDD syntax.
>>>>
>>>
We are currently evaluating some 3rd party image caching libraries for use
in the iOS app.
At the moment, we have our own caching layer which is a bit entangled in
our data layer. We are making some changes to better encapsulate image
caching now, but as we do, we are also evaluating these libraries which are
general purpose and used throughout the iOS community.
This website gives a great rundown of the available libraries and why you
would choose to incorporate one:
https://bpoplauschi.wordpress.com/2014/03/21/ios-image-caching-sdwebimage-v…
As the title suggests we are currently looking most closely at SDWebImage
and FastImageCache.
If you have any insights or feedback please feel free to post here.
Thanks!
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
Recently i noticed, that Jon wants to deprecate a module (he moved it to
another location and changed the module name)[1], so I thought about a
better way of deprecating a module (like core functions with a visible
deprecation warning in the browser console, e.g.). So I uploaded a change
for review[2] to extend module.js to support the definition of a deprecated
module (it will log a warning every time someone access the module with
M.require). Jon already posted, that he don't know, if this is the right
approach and suggested to extend core's mw.log.deprecate. I'm not sure, if
it's a better approach to extend a core module in this way, so I hope for
some feedback on this mailing list: What do you think? :)
[1]
https://gerrit.wikimedia.org/r/#/c/202053/3/javascripts/ContentOverlay.js
[2] https://gerrit.wikimedia.org/r/#/c/202069/
Best,
Florian
Given templates are in core now, usable from both JS and PHP, do you guys
think we should halt HTML generation with PHP and make all future HTML
generation with templates, and slowly migrate existing HTML generation to
templates (in mobile web projects)?
Thanks for all the work on getting this done, it is awesome.
Docs:
https://www.mediawiki.org/wiki/Manual:HTML_templates#mw.template_.28client-…
Just pushed out a new release for the beta app, which should be available
soon.
beta / 2015-04-03 (versionCode 99... Luftballons)
==================
Page load performance:
* Reuse the same WebView for article navigation. -> No animations between
page transitions anymore.
* Reduce size of face detection image
Design:
* ShareAFact: use static image for English WP wordmark
* Display local article name in 'Read in other languages' list
Bugs:
* Fix possible crash when failing to clear shared image folder.
* Fix possible crash when highlighting text to share.
Please report any new bugs you encounter.
Enjoy,
Bernd
I just took Googles new Chrome/Android (LLVM & Arc) bridge "ARC
Welder" for a spin with the Wikipedia Android App and I've very
impressed with how smoothly everything works.
Near By, Saved pages, theme switching, etc all work flawlessly. Minus
not being able to figure out the hardware back button it looks lovely.
This really showcases how future proof we are by being native. Excited
to see what else we find out at I/O.
Screenshots: https://imgur.com/a/LxQ99
--tomasz
[1] - https://developer.chrome.com/apps/getstarted_arc
This is from a while back, but I finally got around to watching it. I think
it is a really good questioning of our assumptions around testing (and of
course it is a controversial talk - it is DHH)
To me, the TL;DR was:
- The main goal of writing code should be creating maintainable code with
clear intent.
- While unit testing is good, it is not a panacea for planning good
architecture or system testing.
- Good unit testing coverage will not spontaneously birth good architecture
and at times it can even work against code clarity.
- System testing is a better representation of how our code works
- Unit testing should support our goals, and not become a goal in and of it
self.
I highly encourage everyone to carve out some time to watch.
http://www.youtube.com/watch?v=9LfmrkyP81M
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
Hi mobile teams,
Awhile ago I pointed out (https://phabricator.wikimedia.org/T91621) that
the important template in content pages that directs readers from article
subsections to "main articles" is missing from mobile web pages. I have
since found other templates with relevant reader-oriented content to be
missing from mobile web. With the latest Android app release this problem
appears to be happing at greater scale in mobile apps now as well. For
example the audio demonstration of jazz that I placed at the top of the
"Jazz" article on English Wikipedia is missing from Android and from mobile
web. Please, please __do not__ use technical means to delete content or
templates from mobile views when they are intended for our readers on all
platforms and were placed in articles through the efforts of volunteers,
especially not without a community discussion first. Formatting tweaks are
negotiable, but this kind of content elimination makes me upset. I feel
that it degrades Wikipedia's value to readers, and as a person who adds
audio and other templates to articles I find it discouraging to have my
efforts removed from the view of so many Wikipedia readers.
Thank you for your work to make Wikipedia reading be a good experience on
mobile.
Pine
So this is just absolutely amazing…
https://github.com/pdcgomes/XCActionBar
Install as fast as possible…
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation