Mobile-l April 2015

mobile-l@lists.wikimedia.org

47 participants
42 discussions

Fwd: [Apps] Stripping content inside brackets from the first sentence of articles
by Derk-Jan Hartman 10 Apr '15

10 Apr '15

---------- 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

1 0

Re: [WikimediaMobile] Great Expectations
by Adam Baso 09 Apr '15

09 Apr '15

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. >>>> >>>

1 0

[Apps][iOS]
by Corey Floyd 09 Apr '15

09 Apr '15

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

1 0

MobileFrontend and module deprecation
by Florian Schmidt 08 Apr '15

08 Apr '15

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

3 4

Templates in core, let's use them
by Joaquin Oltra Hernandez 06 Apr '15

06 Apr '15

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-…

3 2

Android Wikipedia beta app release
by Bernd Sitzmann 06 Apr '15

06 Apr '15

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

2 1

Wikipedia Android App running with ARC Welder on OSX
by Tomasz Finc 03 Apr '15

03 Apr '15

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

3 3

DHH Testing Key Note at Railsconf 2014
by Corey Floyd 03 Apr '15

03 Apr '15

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

5 6

Content missing from mobile apps and mobile web
by Pine W 03 Apr '15

03 Apr '15

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

8 13

[Apps] [iOS] XCActionBar
by Corey Floyd 02 Apr '15

02 Apr '15

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

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l April 2015