Re: [WikimediaMobile] Sunsetting Trending Edits Service before the holiday
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks! On Fri, Dec 1, 2017 at 4:16 PM Federico Leva (Nemo) wrote: > Corey Floyd, 01/12/2017 22:30: > > The experimental Trending Service[1] will be sunset on December 14th, > 2017. > > > > We initially deployed this service to evaluate some real time features > > in the mobile apps centered on delivering more timely information to > > users. After some research [2], we found that it did not perform well > > with users in that use case. > > Thanks! It makes sense to reduce exposure here. > > Federico > -- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] Sunsetting Trending Edits Service before the holiday
Hi all, The experimental Trending Service[1] will be sunset on December 14th, 2017. We initially deployed this service to evaluate some real time features in the mobile apps centered on delivering more timely information to users. After some research [2], we found that it did not perform well with users in that use case. At this point there are no further plans to integrate the service into our products and so we are going to sunset the service to reduce the maintenance burden for some of our teams. We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and mostly from our own internal projects. If you this adversely affects any of your work or you have any other concerns, please let the myself or the Reading Infrastructure team know. Thanks to all the teams involved with developing, deploying, researching and maintaining this service. P.S. This service was based off of prototypes Jon Robson had developed for detecting trending articles. He will be continuing his work in this area. I encourage you to reach out to him if you were interested in this project. [1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_read_and_trending_edits_for_Top_Articles_feature -- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wikipedia app v5.5.0 released
Congrats on a great release everyone! I’m pretty excited about this one. So much good stuff... it is major in every sense of the word. I really think this is the best ever release of the iOS app - both in polish and features. I know that it took a lot of effort, both mental and emotional - but it definitely shows. To me, this release, along with recent Android releases and features like page previews on web, signify an increasing level of maturity in our teams, products and processes. I feel fortunate to work with people who won’t accept good enough, and are willing to take the sometimes long and difficult paths required to ship something great while balancing our culture and values. Congrats again to the iOS team! 🎉 On Tue, Jun 20, 2017 at 3:32 PM Jon Katz wrote: > Congratulations, iOS team!! > > On Tue, Jun 20, 2017 at 3:28 PM, Joshua Minor > wrote: > >> Hello mobile Wikimedians, >> >> The iOS team is excited to announce that v5.5.0 of the Wikipedia app for >> iOS is now available in the app store: >> https://itunes.apple.com/us/app/wikipedia/id324715238?mt=8 >> >> This is a MAJOR update with tons of bug fixes and improvements. >> Highlights include: >> >>- New Places tab lets you find Wikipedia articles about places near >>you, or across the globe. Use maps to find the most interesting articles >>next door, or anywhere your curiosity takes you. >>- Quick search box on the Explore screen lets you easily access the >>search menu to find the information you need, now. >>- Streamlined "In the News" design, makes it easier to learn more >>about what’s happening around the world. >>- Updated Explore design makes discovering new content even easier. >>Added "infinite" scroll so you can catch up on what you missed just by >>scrolling down. >>- Clear app caches from the Settings menu, to reclaim storage the >>Wikipedia app takes on your device. >>- Overall performance improvements mean faster loading and smoother >>scrolling >> >> As usual I'd like to thank our beta volunteers, translatewiki localizers >> and all the folks that participated in user feedback rounds. I also want to >> particularly thank volunteer contributor NHarateh for her several patches >> on this version! >> >> Thanks, >> Josh Minor >> PM, Wikipedia for iOS >> > > -- Corey Floyd Engineering Manager Reading Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Results from similar articles A/B test
+ JMo On Fri, Feb 26, 2016 at 4:19 AM David Causse wrote: > Thanks! > > yes this is not exactly what we expected :( > I guess it was too good to be true: reduce latency and improve quality at > the same time :) > On our side I'd say that perf was the main issue, Erik added a cache at > the backend-end level which seems to have a good impact. > Morelike queries are still routed to the new datacenter in dallas to > reduce stress on eqiad. We could maybe try to reroute them to eqiad and see > if caching is sufficient? > If it's the case I'd say that we don't need to run any A/B test. > > Random questions: > Is it possible to analyze the correlation between the chosen article and > the presence of an image? > Rescoring options are slightly different for enwiki, is it possible to > have the detail for e.g. enwiki/frwiki/dewiki? > > If it does not require huge effort on your side I'd say that you could run > another A/B test by disabling boostLinks, you just have to add > cirrusBoostLinks=no to api URL. > > Thank you > > > Le 26/02/2016 00:33, Erik Bernhardson a écrit : > > ouch, that is not at all the result we were hoping for. Just goes to show > why we have to test these things and not just take a few examples that > perform badly in one set and look to do a better job with some different > options. Thanks for putting this together! > > > On Thu, Feb 25, 2016 at 3:06 PM, Dmitry Brant > wrote: > >> Hello all, >> >> As mentioned previously, the current version of the Android app contains >> an A/B test where it presents "read more" suggestions to the user, based on >> (a) the standard "morelike" query, or (b) the new "opening_text" query. >> >> Here are the results from the last ~10 days of the test[0]: >> - The clickthrough rate using the default morelike query is (and has >> been) around 15%. >> - With the new opening_text query, the clickthrough rate decreases to >> about 12%: >> >> >> >> Therefore, it seems that the new query has a nontrivial negative effect >> on CTR :( >> We'll plan on removing this test in the next release of the app, but >> we'll be happy to plug in a different or updated query, if it will be of >> further use to Discovery. >> >> >> [0] >> https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BFsrAcPgexQyNVemmJ3k3IX5rtPvJ_5vdYOyGgS5R6Y/edit?usp=sharing >> (queries embedded as comments in the headers) >> >> -- >> Dmitry Brant >> Senior Software Engineer / Product Owner (Android) >> Wikimedia Foundation >> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering >> >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > ___ > Mobile-l mailing > listMobile-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mobile-l > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Corey Floyd Engineering Manager Reading Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] New Android production release
Awesome work on the latest release all! All of the focus on offline support is really cool… I’m sure there will be lots of happy users! On Wed, Apr 26, 2017 at 9:49 AM Dmitry Brant wrote: > I should add to the list of new features: > - We're now continuing our rollout of editing Wikidata descriptions by > expanding the languages for which descriptions can be added/edited. For > more details, please see the announcement > <https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2017/04#Wikidata_description_editing_in_the_Wikipedia_Android_app> > on Wikidata. > > > Cheers! > > > On Mon, Apr 24, 2017 at 4:48 PM, Dmitry Brant > wrote: > >> Hello! >> >> We're pleased to bring you an updated version of the Wikipedia Android >> app, available now on the Google Play Store! [1]. Here are the highlights >> from this update (or browse the complete change history >> <https://phabricator.wikimedia.org/diffusion/APAW/history/master/;beta/2.5.195-beta-2017-04-21> >> ): >> >> - Numerous improvements to the UI for managing your reading lists. >> - Individual reading list articles can now be toggled on/offline. >> - Improved caching of images for offline availability. >> - Random feed card now pulls a random article from the user's reading >> lists when offline. >> - Many other bug fixes and design updates. >> >> Many thanks to our volunteers who contributed patches to this release, >> including Amir Aharoni (IRC: aharoni, Wikipedia User:Amire80), Codrut Grosu >> (Github: superCodrut, Twitter: @GrosuCodrut), and Dinu Kumarasiri (IRC: >> sandaru, Github: sandarumk). >> >> If you'd like to help improve the app yourself, take a look at our getting >> started >> <https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/App_hacking> >> guide. We're looking forward to your contributions! >> >> >> [1] For devices without Google Play services, you may download >> <https://releases.wikimedia.org/mobile/android/wikipedia/stable/wikipedia-2.5.195-releasesprod-2017-04-21.apk> >> the app directly. >> >> Cheers, >> >> -- >> Dmitry Brant >> Senior Software Engineer / Product Owner (Android) >> Wikimedia Foundation >> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering >> >> > > > -- > Dmitry Brant > Senior Software Engineer / Product Owner (Android) > Wikimedia Foundation > https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering > > -- > You received this message because you are subscribed to the Google Groups > "android" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android+unsubscr...@wikimedia.org. > To post to this group, send email to andr...@wikimedia.org. > -- Corey Floyd Engineering Manager Reading Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] New Android production release
Haven’t had time to respond earlier, but wanted to congratulate the team on a really awesome release! I really love the Wikidata Description editing and can’t wait for it to ship on English after we are done evaluating it. …And to build on Pine’s comment: It is obvious how much work has been put into the app over the past year. It’s great to hear how old users now come back to the app and find a reason to keep using it. Thanks to the Android team for all their effort! On Thu, Mar 2, 2017 at 9:52 AM Stephen Niedzielski < sniedziel...@wikimedia.org> wrote: > My apologies for this poor experience! The app language and search > language are tied together currently but the issue is being tracked here: > > https://phabricator.wikimedia.org/T159000 > > Stephen > > On Thu, Mar 2, 2017 at 1:38 AM, Derk-Jan Hartman < > d.j.hartman+wmf...@gmail.com> wrote: > > > Changing the wiki language now also changes the app UI language. > > That doesn't sound too handy for myself. I often change to a different > language, many that I can't read at all. If the app's ui language were to > follow me in that, I'd be rather unpleasantly surprised. Is there some form > of confirmation or warning to the user (the first time this happens) ? A > way to override or avoid possibly ? > > DJ > > > On Mon, Feb 27, 2017 at 10:35 PM, Dmitry Brant > wrote: > > Hi all, > > We're excited to bring you an updated version of the Wikipedia Android app > <https://play.google.com/store/apps/details?id=org.wikipedia&hl=en>, > rolling out now to the Google Play Store! [1]. Here are the highlights > from this update (or browse the complete change history > <https://phabricator.wikimedia.org/diffusion/APAW/history/master/;r/2.5.190-r-2017-02-24> > ): > > - Contribute to Wikipedia by editing title descriptions for articles that > you browse! (Powered by Wikidata, and currently limited to Russian, Hebrew, > and Catalan Wikipedia. More languages will follow, once we analyze > engagement data with this initial group of communities. If you're > interested, here is the original project outline > <https://www.mediawiki.org/wiki/Wikimedia_Apps/Short_descriptions>, and > the rollout announcement > <https://www.wikidata.org/wiki/Wikidata:Project_chat#Wikidata_description_editing_in_the_Wikipedia_Android_app> > ) > > - Support for two-factor authentication when logging in. > - Improved multi-window support for Samsung devices and for Android Nougat. > - Improved network performance and offline support for cached page > previews. > - Minor UI refinements to image gallery, link previews, and reading lists. > - Changing the wiki language now also changes the app UI language. > - Numerous bug and crash fixes. > > Special thanks to the volunteer contributors who submitted patches for > this release: > > The Discoverer - [[mw:User:The Discoverer]] > Dinu Kumarasiri - IRC: sandaru, https://github.com/sandarumk > Odysseas Kristalakos - https://github.com/OdysseasKr > Kunal Grover - https://github.com/kunalgrover05 > > If you'd like to help improve the app yourself, take a look at our getting > started > <https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_hacking> > guide. > We're looking forward to your contributions! > > > [1] For devices without Google Play services, you may download > <https://releases.wikimedia.org/mobile/android/wikipedia/stable/wikipedia-2.5.190-releasesprod-2017-02-24.apk> > the > app directly. > > -- > Dmitry Brant > Senior Software Engineer / Product Owner (Android) > Wikimedia Foundation > https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > -- > You received this message because you are subscribed to the Google Groups > "android" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android+unsubscr...@wikimedia.org. > To post to this group, send email to andr...@wikimedia.org. > > > -- > You received this message because you are subscribed to the Google Groups > "android" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android+unsubscr...@wikimedia.org. > To post to this group, send email to andr...@wikimedia.org. > -- Corey Floyd Apps Engineering Manager Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] New “On this day” service and location data in summaries
A couple updates for the Mobile Content Service and RESTBase: A new MCS service was deployed yesterday that returns events, holidays, birth and deaths. This service is powered using Wikipedia contributed by our volunteers. It currently works for EN, DE, FR, SV (with rollout to more languages being planned). For example, to see today’s births: https://en.wikipedia.org/api/rest_v1/feed/onthisday/births/02/14 (Source: https://en.wikipedia.org/wiki/February_14) Even better, it returns the curated list selected anniversaries: https://en.wikipedia.org/api/rest_v1/feed/onthisday/selected/02/14 (Source: https://en.wikipedia.org/wiki/Wikipedia:Selected_anniversaries/February_14) For more information, check out the docs: https://en.wikipedia.org/api/rest_v1/#!/Feed/aggregatedFeed_0 Thanks to Monte and Bernd for working on this and creating a very useful endpoint! Another minor, but useful improvement made earlier this month was the inclusion latitude and longitude in RESTBase summaries by Petr: https://en.wikipedia.org/api/rest_v1/page/summary/atlanta Special thanks to Petr, Marko and the rest of the Services team for all their help and consultation. They continue to be great partners for the Reading team and their contributions have been key to so much of our work over the past year. -- Corey Floyd Apps Engineering Manager Wikimedia Foundation cfl...@wikimedia.org ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Wiki-specific parsing in mobile "services"
Hey all, just want to drop in some thoughts on his thread… I would say the premise of this email is absolutely right: Parsing out this data by hand coding against specific HTML structures is untenable. On Wikipedia we have a wealth of community curated information: featured articles, in the news, on this day, etc… Over the past year, the Reading team has been working with Services to setup some basic infrastructure for ingesting some of this data and making it available as structured data via an API that any client can ingest. This includes our own WMF maintained projects (apps, mobile web, desktop) Because of the nature of our projects, it is difficult to extract this information in a uniform way across all wikis. Though this is clearly the target (and in line with our mission), before we invest significant time in developing such a standardized method for each service, we need to first deploy an API to test whether these services are actually a good direction for our products, services, and mission. To that end, we develop each new service on en.wikipedia first in a method that we do not intend to scale. Now that some of these services have proven useful, we have begun efforts to develop a way for all project maintainers to opt in to making their curated content available for consumption in these APIs. You can see some tickets focused on this effort here: https://phabricator.wikimedia.org/T150806 https://phabricator.wikimedia.org/T152284 https://phabricator.wikimedia.org/T148680 We have also created some draft documentation that we are currently gathering feedback on to see if it is viable for all projects here: https://www.mediawiki.org/wiki/User:CFloyd_(WMF)/Feed_Markup_Documentation Additionally, we have also added additional resources to our Reading Infrastructure team (which maintains our services) in part to help with this effort. All this is to say, is that creating and scaling these services to multiple wikis is a continuing effort. While we would love to deploy a solution to all projects at once, in order to make the problem tractable, we are tackling it in steps and re-evaluating our assumptions along the way. Hopefully this explains our thinking and the projects in a way that make sense. Because this is a large project, we are looking for solutions and help to spread these services across all wikis - If you have or anyone time and would like to help, the tickets and documentation above are great place you to contribute to the process. Thanks for any help Corey On Thu, Jan 12, 2017 at 10:45 AM Monte Hurd wrote: Thanks Florian. I see your point about ease of forking. Would you have time later, perhaps off thread, to detail the challenges you faced? Regarding the data endpoint topic of this thread, it isn't app-specific despite being part of 'mediawiki/services/mobileapps'. We'll probably want a more generic name with only truly app specific endpoints named accordingly. On Thu, Jan 12, 2017 at 10:05 AM, Florian Schmidt < florian.schmidt.wel...@t-online.de> wrote: What is also in my mind: the app wasn't easy to fork and use on other (third-party) projects before that, too, however with the track in this direction (specific Parsons of contents, which apply to Wikimedia projects only) makes it, in reality, impossible to fork (and maintain) the app projects to other, MediaWiki based, third-party projects. I understand, that this might not be the goal of the WMF, which in my personal opinion isn't quite correct, however it's very very sad. I tried to maintain an up-to-date version of the Wikipedia app some time ago, but it takes so much time, as it is so Wikimedia, and not MediaWiki specific, that I ended up mostly stopping the effort in this direction. This is probably not a response which should be in this thread, and I apologize for that, however I wanted to say that somewhere. Best, Florian ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Fwd: [Analytics] [Pageview API] Data Retention Question
For the iOS app I can say that 18 months is more than enough for our current feature set and upcoming plans. Even if we began displaying graphs of page views over time… I can’t see any need to go back more than a few weeks or months. For historical data the idea of degrading is an interesting one. I think that the daily data becomes much less important as you go back in time. Even if we only kept daily data for 6 months, that would be enough for our use cases. This is probably true for Android as well, since we have pretty similar UI, but I’ll let them chime in to be sure. Let me know if you want to know any further info. On Fri, Jul 29, 2016 at 10:31 AM, Adam Baso wrote: > Cross posting. > > > -- Forwarded message -- > From: *Dan Andreescu* > Date: Friday, July 29, 2016 > Subject: [Analytics] [Pageview API] Data Retention Question > To: Analytics List > > > Dear Pageview API consumers, > > We would like to plan storage capacity for our pageview API cluster. > Right now, with a reliable RAID setup, we can keep *18 months* of data. > If you'd like to query further back than that, you can download dump files > (which we'll make easier to use with python utilities). > > What do you think? Will you need more than 18 months of data? If so, we > need to add more nodes when we get to that point, and that costs money, so > we want to check if there is a real need for it. > > Another option is to start degrading the resolution for older data (only > keep weekly or monthly for data older than 1 year for example). If you > need more than 18 months, we'd love to hear your use case and something in > the form of: > > need daily resolution for 1 year > need weekly resolution for 2 years > need monthly resolution for 3 years > > Thank you! > > Dan > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Reading / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Fwd: geo search is now live
Super excited to start working on the UI for this. Thanks again for getting this implemented! 🎉 On Thu, Jul 14, 2016 at 5:51 PM, Erik Bernhardson < ebernhard...@wikimedia.org> wrote: > This week we shipped a new feature at the request of the mobile apps team, > geo integration to full text search. > > (bare bones) Documentation: > https://www.mediawiki.org/wiki/Help:CirrusSearch#Geo_Search > > Quick example usage for bounded geo search: > > > https://people.wikimedia.org/~ebernhardson/mapsearch.html#Pittsburgh|intitle:bridge > > https://people.wikimedia.org/~ebernhardson/mapsearch.html#San_Francisco|hastemplate > :"National_Register_of_Historic_Places_in_California" > > https://people.wikimedia.org/~ebernhardson/mapsearch.html#200km,Moscow|incategory:Kremlins > > Direct search example: > > > https://en.wikipedia.org/w/index.php?fulltext=1&search=incategory%3AKremlins+neartitle%3A200km%2CMoscow > > Also implemented a "boost" version which increases the search score of > pages within a particular area, rather than the default which limits to a > geographic area. Compare: > > > https://en.wikipedia.org/w/index.php?fulltext=1&search=boost-neartitle%3A%22Paris%22+museum > > vs. > > https://en.wikipedia.org/w/index.php?fulltext=1&search=museum > > > > _______ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Reading / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Client-server request-response contract meeting minutes
Thanks Stephen! On Tue, Jun 28, 2016 at 1:01 PM, Stephen Niedzielski < sniedziel...@wikimedia.org> wrote: > *Action items:* > >- Audit any assumptions apps make about contents of HTML returned by >API and make tickets for tests [*Jon Robson*] > - Make sure all edge cases are covered e.g. What if srcset is not > present? What if there are no img and the figure tag is being used? > - Rely less on HTML wherever possible - explore if it would make > more sense to pull out metadata in API responses > - Capture in a task for Reading Web team to write a > MobileFrontend test to protect app requirements > - Write new tests for MobileFrontend (wherever they make most > sense) to make sure they cover what is needed by iOS and Android > and they > need to be triggered by MobileFrontend commits >- Could add some MCS tests for HTML content > > >- Look into hooking up Jenkins Android / iOS to the mobile front end >tests so that MobileFrontend merges are blocked when they break things in >apps [*Corey Floyd + Michael Holloway*] > - Explore if TemplateData could be used by Apps for replacing > editor created template constructs e.g. infobox > > >- Look at testing apps against beta cluster [*Monte Hurd*] > > >- Android / iOS should try to get CSS / JavaScript into MobileFrontend >more rather than changing it on the client [T137992 ><https://phabricator.wikimedia.org/T137992>] > > > > *Copy and paste of Etherpad > <https://etherpad.wikimedia.org/p/Client-server> for posterity:* > > Agenda > 9:00-9.15: What happened. Let's get a shared understanding of the problem > hit. Demo would be useful here if this can be arranged. > 9:15-9.40: How could this have been avoided? What APIs would have made it > better? > 9:40-10:00: Actions/story writing. > > From Google invite: > > >- "I think this is something we should probably discus more next week >- probably as a separate meeting. It would be good to talk about the >strategies we use in the apps to get the content and what we can do to >improve them. This is also very relevant for the content service." > > >- > > >- I've marked some as mandatory and some as optional, but I don't >think it would hurt to join and even just listen passively even if you're >optional, especially if you have an interest. > > >- > > >- The removal of srcset led to some breakage in the iOS app's >galleries. > > >- > > Notes: > > App clients have two different calls: > Meta data: search, something powering the feed > Content: HTML <-- This is where the issue is. > > HTML content: > >- HTML is valid but... We extract somethings (with selector >queries) to do things natively. This is kind of hacky generally because >content is tough and variable. For example, table of contents (the sections >themselves are parsed out server side...? it's pulled down and seperated). >Any changes to the structure of this HTML can break things. > > >- Content Service does this kind of thing too but at least the output >is from Parsoid. > > >- Web does very little with HTML content. The stuff we do is very >minimal. Somethings get stripped out but generally considered small. > > >- More tests would be nice for content specifically. For instance, if >you clients are expected a src set, then write a test for that. > > >- iOS added a test for srcset. Content Service has lots of content >tests. > > >- It's tricky for native apps since the tests are written in a >different environment than the other app tests? Just need to make sure the >HTML isn't messed up. > > >- MobileFrontend has some Jenkins automated tests. Probably could use >some fleshing out to make sure they cover whatever the apps need. This >won't be super simple. > > >- Can we move some of the Android screenshot tests to Mobile Frontend >somehow? > > >- testwiki gets code drops on tuesdays > > >- beta cluster (en[.m].wikipedia.beta.wmflabs.org) gets whatever's >merged to master like within 30 minutes of merge > > >- > > Action items: > Audit any assumptions apps makes about contents of HTML returned by API > and > make tickets for tests [JR] > >- Make sure all edge cases are covered e.g. What if srcset is not >present? What if there are no img and the fi
[WikimediaMobile] New iOS Beta 5.0.3
Hello, mobile Wikimedians, The iOS team is excited to announce the first beta of our upcoming 5.0.3 release. 5.0.3 is a minor release to address bugs and usability issues reported by users. We've fixed the Main Pages so that they update as, patched an issue with log-ins and fixed some crashes, especially with image display. In addition to bug fixes, this release also adds text size adjustment for articles, supports iPad split-view multi-tasking, and gives users much more control over language preferences (including re-order and deletion). We are working on a few more changes, but wanted to get this in testers hands while we finish up. If you are not already a beta tester, and would like to join, please sign up here: http://goo.gl/forms/eAN1qjcm7I Feedback about the beta can be given via this form: http://goo.gl/forms/rLVmFLzus2 Thanks, Corey -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [reading-wmf] Pageview drop
On Wed, Oct 14, 2015 at 1:43 AM, Toby Negrin wrote: > - Does this mean that mobile users are less likely to fall into the > rabbit hole? I'd be interested in getting some more targeted research > around how mobile and desktop use differ. Maybe the apps can help I think this is pretty much a given - session length on mobile is known to be shorter than desktop. The upside here is that we should be able to get more sessions from a user over a given time period because a users phone is with them at all times. So we should be able to compensate for length of session with number of sessions. Upping number of sessions is tied pretty tightly to notifications - Facebook and Twitter get people to come back to their apps by pushing notifications when something interesting happens. Pushing notifications for items in a users feed, or changes to watched/saved pages, etc could be a way to accomplish this. -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Global South = web, Global North = apps
On Fri, Aug 28, 2015 at 4:10 PM, James Alexander wrote: > "people using apps more and more" EXCEPT for news/reference in which case > they were almost not using apps at all and only using mobile web According to the most recent annual study conducted by the IAB, even consumption of news, search, and information in the US favors apps: 57% of users in these categories use mobile apps OVER the mobile web. This is less than the usage across all categories (which is 88% to 12% in favor of apps), but even in the news, search, and information categories, app usage still represents the MAJORITY of internet time spent by people in the US. I think this pretty much supports the thesis of the original email of apps = Global North, web = Global South. Reference: http://www.iab.net/media/file/IAB_Apps_and_Mobile_Web_Final.pdf (See page 5) -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Fwd: Interesting WSJ article: "The Rise of Phone Reading"
Definitely interesting… not too surprising that there has been a bump in
mobile reading over that past few years - seeing as everyone's phone
screens are twice as big as they were in 2012. Anecdotally, I am more
likely to read on my phone now than I was a few years ago (I always used to
reach for my iPad before I had an iPhone 6).
When reviewing these stats, we should keep in mind the primary use case of
Wikipedia - a reference. While it is true that some will read significant
portions of a book or a blog posts on their phones, most people aren't
looking to read a Wikipedia article from top-to-bottom. Some will read a
section or 2, while many others will only need to ready the first paragraph
to get the answer that they need.
So even as the number of "long form readers" increases on mobile, that
might not directly translate into more "full article Wikipedia readers" on
mobile.
I definitely believe we should continue improving our mobile reading
experience - it will only become more important as these numbers increase,
however we shouldn't draw to many conclusions from this article as the
content being discussed is quite different.
On Mon, Aug 17, 2015 at 12:31 PM, Tilman Bayer wrote:
> Forwarding to the public list too.
>
>
> -- Forwarded message --
> From: Tilman Bayer
> Date: Sun, Aug 16, 2015 at 9:40 PM
> Subject: Interesting WSJ article: "The Rise of Phone Reading"
> To: Internal communication for WMF Reading team
>
>
>
> Some food for thought - it's probably not entirely surprising in 2015,
> but this article collects a lot of information showing that the
> assumption "few people want to read long texts on a phone" is too
> simplistic:
> http://www.wsj.com/articles/the-rise-of-phone-reading-1439398395
>
> TLDR from our perspective: Smartphones are becoming a major venue for
> reading ebooks, ie. really long-form texts, more than was predicted a
> few years ago. ("In a Nielsen survey of 2,000 people this past
> December, about 54% of e-book buyers said they used smartphones to
> read their books at least some of the time. That’s up from 24% in
> 2012.") One reason is convenience - “The best device to read on is the
> one you have with you"/"Most people who read on their phones toggle
> back and forth between devices, using whichever is closest at hand
> when opportunity strikes". Another is that screen sizes are getting
> bigger.
> Also has some bits about how book publishers react to this, which may
> of course be less applicable to us.
>
> [...]
> --
> Tilman Bayer
> Senior Analyst
> Wikimedia Foundation
> IRC (Freenode): HaeB
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] In-app editing / talk pages support
But can the apps' reading experience make the Kessel Run in less than 12 Parsecs? And, quite frankly, we have to remind ourselves that the apps are still light years away from having a good editing experience. On Wed, Jul 22, 2015 at 4:42 PM, Gergo Tisza wrote: > On Wed, Jul 22, 2015 at 10:52 AM, Dmitry Brant > wrote: > >> But more importantly, you mentioned yourself that talk pages are really >> part of the _editing_ experience. And, quite frankly, we have to remind >> ourselves that the apps are still light years away from having a good >> editing experience. Therefore, providing access to talk pages without >> providing the other fundamentals that are central to editing (moderation >> tools, watchlists, diffs, notifications, etc) may be putting the cart >> before the horse, and may lead to confusion. In fact, I'm not sure if any >> *one* of those editing features makes sense without all the others. And to >> implement all of those features in the apps would require a department-wide >> focus on editing, which is currently not the case. >> > > Most editors probably own multiple devices, so a partial but good editing > experience is probably more useful than a full but poor one. Large-scale > article editing is never going to be competitive on mobile due to the > inherent limitations of the platform such as the tiny display and slow text > input, so most editors will always use their laptops for that. But if other > pieces of their workload, which *can* be done well on mobile (such as > messaging or patrolling or processing certain backlogs) are well-supported, > that means more desktop time for actual article editing. > > So I don't think the kind of interdependencies that you mention exist. > Much of the talk page communication can be detached from editing and done > in a different part of the day, and providing an interface for that will > mean that editors can check their messages while on the bus and do the > editing when at home. (And for users who do not have other means to access > Wikipedia than a phone, a partial experience is probably still better than > no experience.) > > _______ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS TWN syncs
@Brian - yeah lets discus schedule sometime soon - I prefer to hold off until we get more of the 5.0 UI built so we don't split focus. This could be a rabbit hole and really isn't needed for 5.0 until we get closer to shipping. On Wed, Jul 22, 2015 at 12:58 PM, Bernd Sitzmann wrote: > Brian: > > If you want this to be automated then you could let l10n-bot just do them. > This implies automatic merging as well. > > If not then you should submit a ticket to the translatewiki.net Phab > project to get ssh access to translatewiki.net for yourself. > > I just split up the instructions for TWN sync between Android and iOS. The > iOS part will need to be updated further for the Github parts. Stephen is > going to take over the TWN sync for Android. > > Cheers, > Bernd > > On Wed, Jul 22, 2015 at 9:09 AM, Brian Gerstle > wrote: > >> +mobile-l >> >> Corey: Using existing infra for 4.1.7 is fine. Just to be clear, I think >> we should do this as simply (even manually) as possible to avoid expanding >> scope of this to include automating it just yet. >> >> Given that we don't (currently) plan on doing another 4.y.z release after >> 4.1.7 and before 5.0, I suggest that we get translations hooked up to 5.0 >> immediately after 4.1.7. This follows the same rationale behind syncing >> master & 5.0 branches after 4.1.7 and will prevent future translations from >> targeting obsolete strings or being hard to port over. >> >> On Wed, Jul 22, 2015 at 10:41 AM, Adam Baso wrote: >> >>> Okay to move this discussion to mobile-l now? >>> >>> On Wednesday, July 22, 2015, Corey Floyd wrote: >>> >>>> Since the existing infrastructure is still working for 4.1.7 and we >>>> already have the patches ready to go, we should just get it merged. >>>> >>>> Agree that we need to get to this, but I think it would be less >>>> disruptive to deal with this as part of 5.0, rather than add development >>>> time to a legacy bug fix release. 5.0 will have new language keys and >>>> (likely) a new directory structure anyways. >>>> >>>> Let plan on discussing translation impacts on 5.0 after we get moved to >>>> Github. That we we have our new CI setup in place before making any Phab >>>> tasks. >>>> >>>> >>>> >>>> On Wed, Jul 22, 2015 at 6:20 AM, Brian Gerstle >>>> wrote: >>>> >>>>> Correct, the ticket for the transfer >>>>> <https://phabricator.wikimedia.org/T105056> has been filed. My >>>>> (potentially naive) assumption is that, based on the docs, we can at least >>>>> use the current "export" step to apply localization updates locally, then >>>>> push a commit or pull request manually (at least for now). >>>>> Assuming this is feasible, we should be able to take ownership of TWN >>>>> sync independent of when we switch to GH. >>>>> >>>>> Corey, what do you think of TWN ownership (and sync) as part of >>>>> releasing 4.1.7? We've been kicking this can down the road for a while, >>>>> so >>>>> I like the idea of making the next TWN sync one we run ourselves. >>>>> >>>>> As far as when the switch will happen, I still need to work that out >>>>> with Corey to make sure we've thought through (and hopefully avoided) any >>>>> potential negative impact on our ability to deliver 5.0 in Q1. My rough >>>>> estimate is that moving to GH and hooking up Travis should only be a >>>>> couple >>>>> days work, just need to talk through it & prioritize the tasks in the >>>>> backlog. >>>>> >>>>> On Wed, Jul 22, 2015 at 2:11 AM, Bernd Sitzmann >>>>> wrote: >>>>> >>>>>> That would be fine with me. As long as the TWN guys don't have a >>>>>> problem with that to have multiple points of contact that would work >>>>>> nicely. >>>>>> >>>>>> When is the Github move going to happen? >>>>>> >>>>>> Bernd >>>>>> >>>>>> On Tue, Jul 21, 2015 at 7:20 PM, Corey Floyd >>>>>> wrote: >>>>>> >>>>>>> I think Bran wants us to take ownership for the iOS translations >>>>>>> anyways. Since we are moving to github, this may be a good time to &
Re: [WikimediaMobile] deep-linking in apps
https://phabricator.wikimedia.org/T97785 On Mon, Jul 13, 2015 at 11:48 AM, Toby Negrin wrote: > Thanks for quick answers folks! > > Brian -- is there a phab ticket for the iOS work? > > -Toby > > On Mon, Jul 13, 2015 at 8:47 AM, Dmitry Brant > wrote: > >> For the Android app, we do indeed. If you look at the HTML of any wiki >> article, you'll notice an "alternate" link in the tag that looks >> like this: >> >> >> >> This is a deep link that tells Google that it's possible to open this >> page in our Android app. >> >> >> On Mon, Jul 13, 2015 at 11:28 AM, Toby Negrin >> wrote: >> >>> Do we support any deep-linking[1] scheme for our apps? I know that we've >>> made some steps in integrating with google search on this but I don't know >>> what our general approach. >>> >>> thanks, >>> >>> -Toby >>> >>> [1] https://en.wikipedia.org/wiki/Mobile_deep_linking >>> >>> ___ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] iOS 4.1.6 released to the App Store
The newest version of the iOS app is available for download here: https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8 This was mostly just some bug fixes with a few updates for article language selections. Check it out if you get a chance. As always you can leave us feedback here, on the app store, or using our in app feedback. Thanks! -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] The path to video: media playback for the iOS app
Brion - have a question about existing OGG players: Currently there is an iOS framework called VLCKit (https://wiki.videolan.org/VLCKit/) by the VideoLan crew that appears to handle OGG/WebM and seems to be under active development. It is also being used in several shipping apps (including the VLC iOS app) I see you forked it at sometime in the past… was there a reason why you didn't pursue modifying it or using it as is within the iOS app to play media files? On Thu, Jun 25, 2015 at 1:05 PM, Monte Hurd wrote: > Brion this is so exciting! :) > > On Wed, Jun 24, 2015 at 3:53 PM, Brion Vibber > wrote: > >> We've been stalled for years on adding media playback to the Wikipedia >> iOS app due to the impasse between Wikimedia's insistence on free formats >> and Apple's insistence on only supporting patented formats. >> >> I'm trying to route around that impasse by getting Ogg and WebM playback >> up and running on iOS through a native widget library, which I've been >> cleaning up to ready it for CocoaPods packaging. >> >> Here's the high-level library: >> https://github.com/brion/OGVKit >> >> and provisional CocoaPods specifications for the low-level open-source >> libraries it needs: >> https://github.com/brion/OGVKit-Specs >> >> Once I finish some further fixes and do an API cleanup (version 0.5 on my >> provisional milestones <https://github.com/brion/OGVKit/milestones>) I >> plan to publish my podspecs and write a patch to the Wikipedia app that >> uses OGVKit to handle media playback. >> >> >> Rough patch plan: >> * add OGVKit as dependency >> * enhance the photo carousel view to instantiate a player view for >> audio/video files, just like on Android >> * add content CSS to clean up those video thumbnail 'Play media' links >> * add a JS click handler for 'Play media' links to launch the carousel >> * add a JS click handler for and elements in content >> * add a bunch of libraries to the list on the about page >> >> Ideally this should be a "surgical" patch and relatively minimal, though >> an update of the Pods dir will pull in a lot of files. :) >> >> -- brion >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Mobile content service Phab project
Since this is technical, I would say Brian is the best one to talk to. @Brian it would be good if you could figure out what is the smallest step we can take when first moving to the service. Also keep in mind we will have a requirement to measure and compare the user perceived loading time so we can show that we actually made an improvement. As a start, this can be just be measured by developers (UI testing?) without involving Event Logging. On Wed, Jun 24, 2015 at 1:03 PM, Bernd Sitzmann wrote: > If you have any requirements that are missing please let me know. > > Who on the iOS side would be the best contact person to occasionally run > things by? > > In particular, right now I'm wondering if the html route is something that > iOS devs are comfortable with. Or would you prefer a different route > initially, which would be a smaller step for the client, where we still > have a JSON payload, similar to what we're using right now, (mobileview, > with two requests: lead + rest), but all the DOM transformations already > done, unneeded parts of payload removed server-side, plus some data added > for gallery in the rest portion? > > Thoughts? > > Cheers, > Bernd > > On Wed, Jun 24, 2015 at 9:07 AM, Corey Floyd wrote: > >> Thanks again for all the work you put into the docs - really great. >> >> On Mon, Jun 22, 2015 at 2:36 PM, Corey Floyd >> wrote: >> >>> woot! >>> >>> On Mon, Jun 22, 2015 at 1:17 PM, Bernd Sitzmann >>> wrote: >>> >>>> We've got a Phabricator project for the Mobile Content Service at >>>> https://phabricator.wikimedia.org/tag/mobile_content_service/. >>>> >>>> Reminder: docs are at >>>> https://www.mediawiki.org/wiki/RESTBase_services_for_apps >>>> >>>> Cheers, >>>> Bernd >>>> >>>> _______ >>>> Mobile-l mailing list >>>> Mobile-l@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>> >>>> >>> >>> >>> -- >>> Corey Floyd >>> Software Engineer >>> Mobile Apps / iOS >>> Wikimedia Foundation >>> >> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] iOS 4.1.5 released to the App Store
Hello everyone - our latest and greatest as just gone live in the app store. You can check it out here: https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8 This release has further UX refinements, better visibility of article translations, and several stability improvements (Fixed a nasty crash bug for our users in Norway) Please check it out and let us know what you think. -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Mobile content service Phab project
Thanks again for all the work you put into the docs - really great. On Mon, Jun 22, 2015 at 2:36 PM, Corey Floyd wrote: > woot! > > On Mon, Jun 22, 2015 at 1:17 PM, Bernd Sitzmann > wrote: > >> We've got a Phabricator project for the Mobile Content Service at >> https://phabricator.wikimedia.org/tag/mobile_content_service/. >> >> Reminder: docs are at >> https://www.mediawiki.org/wiki/RESTBase_services_for_apps >> >> Cheers, >> Bernd >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > -- > Corey Floyd > Software Engineer > Mobile Apps / iOS > Wikimedia Foundation > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS simulator, changing version of OS
Yeah when you update your version of Xcode, you only get the latest simulator. You always have to download "legacy" simulators as separate downloads. this effectively means that you always need to download new simulators when you update Xcode. On Tue, Jun 23, 2015 at 2:57 PM, Joaquin Oltra Hernandez < jhernan...@wikimedia.org> wrote: > Magically updating to yosemite and upgrading xcode made my simulator 8.3. > It's actually removed 8.2 so I'll download it if I need it. > > Thanks for all the advice! > > ps; I'm only getting 7.1, 8.1, 8.2 and the 8.3 that I already have. > > > > On Tue, Jun 23, 2015 at 4:24 PM, Corey Floyd wrote: > >> You need the latest version of Xcode fro get 8.3 >> >> On Tue, Jun 23, 2015 at 6:33 AM, Joaquin Oltra Hernandez < >> jhernan...@wikimedia.org> wrote: >> >>> *Sent message again without the embedded image:* >>> >>> Thanks all for answering! >>> >>> This are the options I get on Xcode -> Preferences -> Downloads: >>> >>> https://i.imgur.com/ICZZMZn.png >>> >>> Which leaves me confused since for example in my iPad I have 8.3, but my >>> simulator is stuck on 8.2 and there doesn't seem to be an option in the >>> downloads tab to download that version. >>> >>> Are 8.2 and 8.3 the same thing regarding component versions? >>> >>> >>> On Mon, Jun 22, 2015 at 5:36 PM, Corey Floyd >>> wrote: >>> >>>> What Adam said… and love that gif! Thanks for making my morning. >>>> >>>> >>>> On Mon, Jun 22, 2015 at 11:18 AM, Adam Baso >>>> wrote: >>>> >>>>> In Xcode, go to Preferences and download more simulators. It won't get >>>>> you every OS, but a pretty good selection. >>>>> >>>>> >>>>> On Monday, June 22, 2015, Joaquin Oltra Hernandez < >>>>> jhernan...@wikimedia.org> wrote: >>>>> >>>>>> Hey, when debugging web stuff on the iOS simulator, I see that I can >>>>>> change the device going to the menu bar Hardware > Device. But I can't >>>>>> seem >>>>>> to find how to change operating system versions, I'm stuck with 8.2. >>>>>> >>>>>> I'm sure this is super obvious for the iOSers and I would appreciate >>>>>> some pointers :) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ___ >>>>> Mobile-l mailing list >>>>> Mobile-l@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>> >>>>> >>>> >>>> >>>> -- >>>> Corey Floyd >>>> Software Engineer >>>> Mobile Apps / iOS >>>> Wikimedia Foundation >>>> >>> >>> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS simulator, changing version of OS
You need the latest version of Xcode fro get 8.3 On Tue, Jun 23, 2015 at 6:33 AM, Joaquin Oltra Hernandez < jhernan...@wikimedia.org> wrote: > *Sent message again without the embedded image:* > > Thanks all for answering! > > This are the options I get on Xcode -> Preferences -> Downloads: > > https://i.imgur.com/ICZZMZn.png > > Which leaves me confused since for example in my iPad I have 8.3, but my > simulator is stuck on 8.2 and there doesn't seem to be an option in the > downloads tab to download that version. > > Are 8.2 and 8.3 the same thing regarding component versions? > > > On Mon, Jun 22, 2015 at 5:36 PM, Corey Floyd wrote: > >> What Adam said… and love that gif! Thanks for making my morning. >> >> >> On Mon, Jun 22, 2015 at 11:18 AM, Adam Baso wrote: >> >>> In Xcode, go to Preferences and download more simulators. It won't get >>> you every OS, but a pretty good selection. >>> >>> >>> On Monday, June 22, 2015, Joaquin Oltra Hernandez < >>> jhernan...@wikimedia.org> wrote: >>> >>>> Hey, when debugging web stuff on the iOS simulator, I see that I can >>>> change the device going to the menu bar Hardware > Device. But I can't seem >>>> to find how to change operating system versions, I'm stuck with 8.2. >>>> >>>> I'm sure this is super obvious for the iOSers and I would appreciate >>>> some pointers :) >>>> >>>> Thanks! >>>> >>>> >>>> >>>> >>> ___ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Mobile content service Phab project
woot! On Mon, Jun 22, 2015 at 1:17 PM, Bernd Sitzmann wrote: > We've got a Phabricator project for the Mobile Content Service at > https://phabricator.wikimedia.org/tag/mobile_content_service/. > > Reminder: docs are at > https://www.mediawiki.org/wiki/RESTBase_services_for_apps > > Cheers, > Bernd > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS simulator, changing version of OS
What Adam said… and love that gif! Thanks for making my morning. On Mon, Jun 22, 2015 at 11:18 AM, Adam Baso wrote: > In Xcode, go to Preferences and download more simulators. It won't get you > every OS, but a pretty good selection. > > > On Monday, June 22, 2015, Joaquin Oltra Hernandez < > jhernan...@wikimedia.org> wrote: > >> Hey, when debugging web stuff on the iOS simulator, I see that I can >> change the device going to the menu bar Hardware > Device. But I can't seem >> to find how to change operating system versions, I'm stuck with 8.2. >> >> I'm sure this is super obvious for the iOSers and I would appreciate some >> pointers :) >> >> Thanks! >> >> >> >> > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [reading-wmf] A plan for the "new" mobile view service
You both are pointing out the real challenge here: The inline content.
The good news is that we don't have to worry about the wiki text or
templates. Parsoid already has dealt with that and is providing additional
markup. This makes it possible to do a 2 way conversion between
HTML<->Wikitext for VE. The goal is to build upon that work to the same
thing with "ParsoidHTML"->JSON.
The hope is that if the markup provided by Parsoid is enough to allow VE to
do the 2 way conversion, there should be enough information for us do at
least a 1 way conversion into JSON without loosing data.
Beyond using the markup to translate the HTML into JSON, we also have to
figure out how to actually represent that in JSON. Especially for inline
entities. Also, we have questions about wether we should still use a subset
of HTML to describe the text styles (like bold, italics, etc…) The
definition of the article JSON spec may be just as challenging as the
actual engineering work.
On Thu, Jun 11, 2015 at 9:51 PM, Gergo Tisza wrote:
> On Thu, Jun 11, 2015 at 6:14 PM, S Page wrote:
>
>> In the case of entities existing within a paragraph, we can decide (with
>>> a little help from Design) whether it's important to keep them inline with
>>> the text, or strip and move them outside of the paragraph.
>>>
>> Will clients be able to request different kinds of stripping? It seems
>> really hard.
>>
> It's even harder if you want it to work outside the English Wikipedia -
> different wikis might use different templates which generate slightly
> different HTML.
>
> The skinnable content snippets proposal from the brainstorming could be
> abused to handle this:
> ** Explore the possibility of wikitext markup for handling over control
> over sections of content to the skin (like
> https://phabricator.wikimedia.org/T25796 but bigger / more generic;
> Winter had some great design ideas that could be implemented with such a
> feature)
>
> Editors would write something like this in the source code:
> '''Vincent Willem van Gogh''' {{#snippet|role=pronunciation|IPA=ˈvɪnsɛnt
> ˈʋɪləm vɑn ˈɣɔx}}{{#snippet|role=birth and death|birth=30 March
> 1853|death=29 July 1890}} was a major [[Post-Impressionist]] painter.
> and the snippets would turn into different templates on different
> devices/skins, in some cases not producing wikicode output at all but
> instead pushing the information to a side channel.
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS Beta 4.1.5 available for testing
Just posted a new version: 4.1.5 (144) with the fix in place. Thanks again for testing! On Thu, Jun 11, 2015 at 1:45 PM, Corey Floyd wrote: > And thats why we beta test… :) > > We actually omitted the commit patch that puts that back in place. Thanks > for finding that, expect a new beta to be distributed soon. > > On Thu, Jun 11, 2015 at 1:11 PM, Legoktm > wrote: > >> Hi, >> >> On 06/11/2015 09:11 AM, Corey Floyd wrote: >> > Thanks for testing and please send us any feedback you may have! >> >> The language selector is now more prominent which is nice, however I >> can't figure out how to get to the history view. Was that removed? >> >> -- Legoktm >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > > > > -- > Corey Floyd > Software Engineer > Mobile Apps / iOS > Wikimedia Foundation > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS Beta 4.1.5 available for testing
And thats why we beta test… :) We actually omitted the commit patch that puts that back in place. Thanks for finding that, expect a new beta to be distributed soon. On Thu, Jun 11, 2015 at 1:11 PM, Legoktm wrote: > Hi, > > On 06/11/2015 09:11 AM, Corey Floyd wrote: > > Thanks for testing and please send us any feedback you may have! > > The language selector is now more prominent which is nice, however I > can't figure out how to get to the history view. Was that removed? > > -- Legoktm > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS Beta 4.1.5 available for testing
Tony - yes version is 4.1.5(143) On Thu, Jun 11, 2015 at 1:05 PM, Toby Negrin wrote: > Hi Corey -- what's the version #? 4.1.5(143)? > > On Thu, Jun 11, 2015 at 9:11 AM, Corey Floyd wrote: > >> Hey everyone, we have a new iOS release in the hopper. If you are part of >> the beta channel, you can download the new version using Apple's TestFlight. >> >> If you would like to be in the beta, just email me, Brian or Monte to get >> access. >> >> Here are the highlights of this release: >> >> * Lead images now load faster and fade in smoothly >> * More article layout improvements >> * More reliable loading of articles from the cache >> * Added a link to the FAQ in Settings > More >> * Fix crash on startup for some device languages (Like Norwegian) >> * Several other crash fixes >> >> Also of note: this our last "scheduled" iOS 6 release. After release, >> this version will be available for download indefinitely for our users >> who are unable to upgrade to iOS 7. >> >> For users who are running iOS 7 or higher, this will allow us to >> support more great features in future versions of the iOS application. >> >> Thanks for testing and please send us any feedback you may have! >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] iOS Beta 4.1.5 available for testing
Hey everyone, we have a new iOS release in the hopper. If you are part of the beta channel, you can download the new version using Apple's TestFlight. If you would like to be in the beta, just email me, Brian or Monte to get access. Here are the highlights of this release: * Lead images now load faster and fade in smoothly * More article layout improvements * More reliable loading of articles from the cache * Added a link to the FAQ in Settings > More * Fix crash on startup for some device languages (Like Norwegian) * Several other crash fixes Also of note: this our last "scheduled" iOS 6 release. After release, this version will be available for download indefinitely for our users who are unable to upgrade to iOS 7. For users who are running iOS 7 or higher, this will allow us to support more great features in future versions of the iOS application. Thanks for testing and please send us any feedback you may have! -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
We made a bug ticket template that clearly asks for both “Actual Results” and “Expected Results” to help with this. T98466 <https://phabricator.wikimedia.org/T98466> On Mon, Jun 8, 2015 at 2:25 PM, Derk-Jan Hartman < d.j.hartman+wmf...@gmail.com> wrote: > > > On 8 jun. 2015, at 19:52, Jon Katz wrote: > > I think we could go a step further and call out bugs with the prefix > "bug:" for more clarity. > > > > -J > > Please also discuss such a thing with Andre and other Phab people. We only > just got rid of prefixes since we dumped bugzilla. It might be wise to make > sure a sustainable route is chosen for any new conventions. > > DJ > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] iOS 4.1.4 is live
This version has a lot of visual updates, performance improvements, and bug fixes - we even tweaked the icon. Overall this is a pretty nice release that applies some much needed polish in a lot of places. Please check it out when you get a chance and let us know what you think. https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8 -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] maps w/ nearby
Any reason to import a 3rd party library for functionality built in to the iOS SDK? Seems like work to explore/integrate a dependency where none is needed. Without this extra work, this is something that can be built in < 1 day. On Wed, May 27, 2015 at 10:01 PM, Brian Gerstle wrote: > Cool, looks like mapbox has an iOS SDK > <https://www.mapbox.com/mapbox-ios-sdk/>. Is there somewhere that the > progress on funding is being tracked? Put another way, where should I > direct PM, design, etc. to get this prioritized? Also, I think it'd be > worth it to ship this to a percentage of users to (further) validate the > feature. > > On Wed, May 27, 2015 at 3:56 PM, Yuri Astrakhan > wrote: > >> Current state of affairs: https://karta.wmflabs.org/static/ is up and >> running, and should have all the data soon. It uses mapbox stack, which >> means that it generates vector data tiles, and creates a PNG tiles on the >> fly. This also means that in a few days, you will be able to view WebGL >> based maps there too - rendered on the browser, with multiple styles, and >> rotatable. >> >> The community needs this service, and has already built a large number of >> amazing projects even without the production-level vector service. Examples >> include >> * atlas-style drill-down map >> <http://umap.openstreetmap.fr/de/map/wikipedia-clustermap_36725> (umap, >> see more info <http://umap.openstreetmap.fr/>) >> * Wikidata-based map of pages by class >> <https://tools.wmflabs.org/wp-world/wikidata/superclasses.php?lang=en>, >> e.g. all rollercoasters >> <https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=en&uselang=en&zoom=3&lat=0&lon=0&classes=204832> >> . >> * There is an amazing presentation >> <https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.pdf> (pdf) >> by Kolossos (Tim Adler), that gives many more examples of the >> community-built map services and projects (OpenOffice format >> <https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.odp>) >> >> >> P.S. Tomasz, it's Yuri, not Yuvi, and don't blame IRC auto-complete :) >> >> On Wed, May 27, 2015 at 7:57 PM, Max Semenik >> wrote: >> >>> Hey - yes, we're workig on serving map tiles. Both raster and MapBox >>> vectors. Our current demo implementation is at >>> https://karta.wmflabs.org/static/ - only raster tiles ATM, vectors >>> coming in 1-2 days. The main problem, however, is budgeting - yet if we get >>> very little hardware, concentrating on maps for apps might even be a >>> reasonable option as apps traffic might be lower than if we exposed maps to >>> all web users. Getting no bugdet at all is also a possible outcome, though. >>> >>> ___ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > -- > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Some EventLogging events failing validation
Just to be clear… not looking for exact percentages, just a note of “iOS”, Android” or “both". On Fri, May 15, 2015 at 4:49 PM, Corey Floyd wrote: > Marcel, do you have breakdown per platform? Not sure if each of these > issues is shared between iOS and Android or specific to one or the other. > Would be nice to know as we check things out. > > On Fri, May 15, 2015 at 4:38 PM, Adam Baso wrote: > >> Marcel, thanks for the links and Dmitry thanks for coordinating this. >> >> A couple notes from my memory: >> >> iOS: >> EventLogging.h >> <https://git.wikimedia.org/blob/apps%2Fios%2Fwikipedia.git/HEAD/Wikipedia%2FEventLogging%2FEventLoggingFunnel.h#L12> >> defines WMFEventLoggingMaxStringLength_Snippet >> and WMFEventLoggingMaxStringLength_General, which are only currently used >> for Share a Fact in WMFShareFunnel.m >> <https://git.wikimedia.org/blob/apps%2Fios%2Fwikipedia.git/HEAD/Wikipedia%2FView%20Controllers%2FShareCard%2FWMFShareFunnel.m> >> . >> Not sure if URL-encoding on the request path or actual database bytes >> (Unicode?) occupied causes overflows despite this. >> >> As I recall, Android does something similar on Share a Fact ( >> ShareAFactFunnel.java >> <https://git.wikimedia.org/blob/apps%2Fandroid%2Fwikipedia.git/HEAD/wikipedia%2Fsrc%2Fmain%2Fjava%2Forg%2Fwikipedia%2Fanalytics%2FShareAFactFunnel.java#L19>). >> Same thing here with URL-encoding and actual database bytes (Unicode?). >> >> -Adam >> >> >> On Fri, May 15, 2015 at 1:21 PM, Marcel Ruiz Forns >> wrote: >> >>> Dmitry, >>> >>> you're totally right, it was in the email, but it should have been in >>> the wikis. >>> I added some documentation on it here: >>> https://wikitech.wikimedia.org/wiki/EventLogging#Log_size_limit >>> >>> Thanks! >>> >>> On Fri, May 15, 2015 at 10:00 PM, Dmitry Brant >>> wrote: >>> >>>> [brain fart] it's in your email. :( Thanks! >>>> >>>> On Fri, May 15, 2015 at 3:59 PM, Dmitry Brant >>>> wrote: >>>> >>>>> Thanks for reporting this, Marcel! >>>>> I've created a task for us to correct the behavior of our EL funnels: >>>>> https://phabricator.wikimedia.org/T99276 >>>>> >>>>> Is the actual character limit of EL messages specified somewhere? >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On Fri, May 15, 2015 at 3:41 PM, Marcel Ruiz Forns < >>>>> mfo...@wikimedia.org> wrote: >>>>> >>>>>> Hi Mobile, >>>>>> >>>>>> Analyzing EventLogging logs we percieved that a significant share of >>>>>> MobileWikiAppSavedPages, MobileWikiAppArticleSuggestions and >>>>>> MobileWikiAppShareAFact events are failing validation. >>>>>> >>>>>> *1) MobileWikiAppShareAFact: 1.5% not validating* >>>>>> In this schema, the field "text" stores long fractions of text >>>>>> sometimes. >>>>>> This exceeds the size limitation of EL, specially when the text >>>>>> contains special characters, like chinese, greek, etc. >>>>>> >>>>>> *2) MobileWikiAppArticleSuggestions: 1% not validating* >>>>>> In this case, it's the field "readMoreList" that is sometimes very >>>>>> long, >>>>>> specially when it contains special characters. >>>>>> This, again, exceeds the log size limit. >>>>>> >>>>>> *3) MobileWikiAppSavedPages: 1% not validating* >>>>>> Some events do not contain the required field "appInstallID". >>>>>> >>>>>> In cases 1) and 2) the percentage is not big overall, but it can be >>>>>> that for a given language, a lot of events are lost. >>>>>> >>>>>> EventLogging performance is not compromised by these validation >>>>>> errors, but we are receiving monitoring alerts, and would like to >>>>>> maintain >>>>>> the validation rate close to 100%. >>>>>> >>>>>> Is it possible for you to somehow reduce the size of the logs of 1) >>>>>> and 2)? >>>>>> If so, have in mind that the log size limit is 1k, and that the >>>>>> highest priority for us would be 2). >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Marcel >>>>>> >>>>>> ___ >>>>>> Mobile-l mailing list >>>>>> Mobile-l@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>>> >>>>>> >>>>> >>>> >>> >>> ___ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > -- > Corey Floyd > Software Engineer > Mobile Apps / iOS > Wikimedia Foundation > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Some EventLogging events failing validation
Marcel, do you have breakdown per platform? Not sure if each of these issues is shared between iOS and Android or specific to one or the other. Would be nice to know as we check things out. On Fri, May 15, 2015 at 4:38 PM, Adam Baso wrote: > Marcel, thanks for the links and Dmitry thanks for coordinating this. > > A couple notes from my memory: > > iOS: > EventLogging.h > <https://git.wikimedia.org/blob/apps%2Fios%2Fwikipedia.git/HEAD/Wikipedia%2FEventLogging%2FEventLoggingFunnel.h#L12> > defines WMFEventLoggingMaxStringLength_Snippet > and WMFEventLoggingMaxStringLength_General, which are only currently used > for Share a Fact in WMFShareFunnel.m > <https://git.wikimedia.org/blob/apps%2Fios%2Fwikipedia.git/HEAD/Wikipedia%2FView%20Controllers%2FShareCard%2FWMFShareFunnel.m> > . > Not sure if URL-encoding on the request path or actual database bytes > (Unicode?) occupied causes overflows despite this. > > As I recall, Android does something similar on Share a Fact ( > ShareAFactFunnel.java > <https://git.wikimedia.org/blob/apps%2Fandroid%2Fwikipedia.git/HEAD/wikipedia%2Fsrc%2Fmain%2Fjava%2Forg%2Fwikipedia%2Fanalytics%2FShareAFactFunnel.java#L19>). > Same thing here with URL-encoding and actual database bytes (Unicode?). > > -Adam > > > On Fri, May 15, 2015 at 1:21 PM, Marcel Ruiz Forns > wrote: > >> Dmitry, >> >> you're totally right, it was in the email, but it should have been in the >> wikis. >> I added some documentation on it here: >> https://wikitech.wikimedia.org/wiki/EventLogging#Log_size_limit >> >> Thanks! >> >> On Fri, May 15, 2015 at 10:00 PM, Dmitry Brant >> wrote: >> >>> [brain fart] it's in your email. :( Thanks! >>> >>> On Fri, May 15, 2015 at 3:59 PM, Dmitry Brant >>> wrote: >>> >>>> Thanks for reporting this, Marcel! >>>> I've created a task for us to correct the behavior of our EL funnels: >>>> https://phabricator.wikimedia.org/T99276 >>>> >>>> Is the actual character limit of EL messages specified somewhere? >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> On Fri, May 15, 2015 at 3:41 PM, Marcel Ruiz Forns < >>>> mfo...@wikimedia.org> wrote: >>>> >>>>> Hi Mobile, >>>>> >>>>> Analyzing EventLogging logs we percieved that a significant share of >>>>> MobileWikiAppSavedPages, MobileWikiAppArticleSuggestions and >>>>> MobileWikiAppShareAFact events are failing validation. >>>>> >>>>> *1) MobileWikiAppShareAFact: 1.5% not validating* >>>>> In this schema, the field "text" stores long fractions of text >>>>> sometimes. >>>>> This exceeds the size limitation of EL, specially when the text >>>>> contains special characters, like chinese, greek, etc. >>>>> >>>>> *2) MobileWikiAppArticleSuggestions: 1% not validating* >>>>> In this case, it's the field "readMoreList" that is sometimes very >>>>> long, >>>>> specially when it contains special characters. >>>>> This, again, exceeds the log size limit. >>>>> >>>>> *3) MobileWikiAppSavedPages: 1% not validating* >>>>> Some events do not contain the required field "appInstallID". >>>>> >>>>> In cases 1) and 2) the percentage is not big overall, but it can be >>>>> that for a given language, a lot of events are lost. >>>>> >>>>> EventLogging performance is not compromised by these validation >>>>> errors, but we are receiving monitoring alerts, and would like to maintain >>>>> the validation rate close to 100%. >>>>> >>>>> Is it possible for you to somehow reduce the size of the logs of 1) >>>>> and 2)? >>>>> If so, have in mind that the log size limit is 1k, and that the >>>>> highest priority for us would be 2). >>>>> >>>>> Thank you! >>>>> >>>>> Marcel >>>>> >>>>> ___ >>>>> Mobile-l mailing list >>>>> Mobile-l@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>> >>>>> >>>> >>> >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] [iOS][Apps] Wikipedia Mobile 4.1.3 for iOS
Hey everyone… The latest for iOS is live on the app store. You can download it here: https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8 We are continuing our quest to squash bugs and tighten up the screws, but you’ll see a few new features in there as well. This also represents our 3rd release in just over a month after a nearly 4 month drought - our release pipeline in full effect! Automated builds + Crash Reporting + Phabricator Tasks FTW! Please check it out if you get a chance and let us know what you think - mailing list, in app feedback, or an app store review - all are appreciated! Thanks for reading! -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Knowledge Transfer on MaxSem's API / Extension Work to Reading
I have the same question as Sam, are we officially supposed to be doing this type of work internally? If so, Do we have a services engineer for the reading team? Or if not, do we have an open rec? it would be nice to have a resource dedicated for this work (we are developing a rendering service for apps as well) preferably embedded in the reading team since we have so many service needs. It would be nice to lock these things down while the reorg is still "flexible". On Tuesday, May 12, 2015, Sam Smith wrote: > It's great to see this written down. I'd assumed that the Mobile Web > *teams* were now responsible for maintaining those extensions and had > been triaging bugs that landed in the mediawiki-extension-MobileFrontend > and mobile-web projects as such. > > Max: would you be up for a doing a techmosis – a recored presentation – > covering all of those features? Specifically, I'd like to hear the areas > that need improving. > > –Sam > > On Mon, May 11, 2015 at 9:12 PM, Adam Baso > wrote: > >> Hi all - >> >> Max Semenik, now on Search & Discovery (he's been working on geo stuff >> for a while), spoke with me earlier today about transferring >> Reading-oriented extension components / API endpoints off his plate. I'll >> add the bullet points to the Etherpad for the recurring APIs/Services >> meeting instance tomorrow. >> >> * API action=mobileview : the apps are heavy users of this endpoint. >> >> * pageimages extension: Max noted that the algorithm needs improvement >> for targeting the "best" image. >> >> * featuredfeeds extension (RSS/Atom) >> >> * TextExtracts is still an open question. Max said he can maintain it in >> maintenance mode, if necessary. But if there's interest in Reading taking >> over future work on this, that would be even better. Max noted the >> persistence of the results is an area for improvement. Incidentally, some >> people have been communicating about this stuff today. >> >> Thanks. >> -Adam >> >> ___ >> Mobile-l mailing list >> Mobile-l@lists.wikimedia.org >> >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] User Testing
Good read on how to conduct user testing. We are doing more prototyping now, so its nice to see what others have been doing. https://medium.com/cluster-ideas/how-to-run-live-user-testing-sessions-fef630e3620b -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Skynet is winning the battle on IRC
I think this is a good idea… the only thing I think should be in the main channel is something like breaking the build (at least for the apps guys) On Thu, Apr 30, 2015 at 1:29 PM, Joaquin Oltra Hernandez < jhernan...@wikimedia.org> wrote: > Hi! > > I've been feeling that the signal to noise ratio on #wikimedia-mobile > since the addition of wikibugs and our new apps engineers (more grrrit-wm > spam) is turning to be 0 (that is, no signal because of too much noise). > > It is really difficult to talk about anything when somebody else is > working (and that is what we do, so...). > > I would like to propose moving the machines to a different channel, maybe > a couple of them ( #wikimedia-mobile-web-bots & #wikimedia-mobile-apps-bots > for example ) so that they continue to be useful but in a different > channel, and so that we can read again the chats with just the > conversations. > > What do you think? > > Cheers. > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] [Apps][iOS]
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-vs-fastimage/ 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 ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] [Apps] [iOS] XCActionBar
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 ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] DHH Testing Key Note at Railsconf 2014
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 ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Jury duty
You have juries over there now? I thought the Queen just decided… On Mon, Mar 23, 2015 at 11:45 AM, Sam Smith wrote: > Hey y'all, > > Just a reminder that I've been doing jury duty today and will be for up to > two weeks – I found this out today – which is far from ideal. > > The court sits until 4:30 PM so there's time for me to do some code review > in the evening, which'll be a welcome break from, well, everything else. > > Boo in general. > > –Sam > > > > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Read next vs Read more: the verdict
Nice results. I am not sure how the wording affected it, that is an interesting point. It would also be interesting to try a 3 pane "Read More" the slides left/right. Meaning we have the larger more visual representation, but we still provide 3 options that the user can swipe left right. Maybe we even auto scroll to the right… On Sat, Mar 21, 2015 at 2:57 PM, Florian Schmidt < florian.schmidt.wel...@t-online.de> wrote: > Hi Dan! > > > > Very interesting, thanks for sharing! Personally I can totally understand > the result and would welcome it, if “read next” will not be introduces in > Wikipedia (stable app). I want to see interesting articles and decide by > myself, what topic I want to read next and don’t want, that a computer > decide, what are interesting articles for me, if it isn’t based on my > personal interests :) > > > > Best, > > Florian > > > > *Von:* mobile-l-boun...@lists.wikimedia.org [mailto: > mobile-l-boun...@lists.wikimedia.org] *Im Auftrag von *Dan Garry > *Gesendet:* Samstag, 21. März 2015 06:30 > *An:* mobile-l > *Betreff:* [WikimediaMobile] [Apps] Read next vs Read more: the verdict > > > > Hi everyone, > > > For those of you who aren't aware, the Mobile Apps Team has been running > an experiment in Wikipedia Beta on Android. We're trialling a single, > visually appealing result at the end of articles instead of the three from > "Read more". We're calling this "Read next". What happens is that > approximately half of Wikipedia Beta users are shown read next on every > article, and the other half are shown read more. Here's some example > screenshots: > >- Read next: http://i.imgur.com/StTLAPU.png >- Read more: http://i.imgur.com/ecb2cy2.png > > Here's the verdict of the test! > >- Read more has a clickthrough rate of 15.4% (65,448 views, 10,600 >clicks) >- Read next has a clickthrough rate of 10.4% (59,668 views, 6,180 >clicks) > > So it would seem that read next is not as effective at driving clicks as > read more is. Interesting! > > > > Thanks, > > Dan > > > > -- > > Dan Garry > > Associate Product Manager, Mobile Apps > > Wikimedia Foundation > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Improving Android release cadence
Yeah - after listening to the podcast I was on the fence about it too… I think they bring up good points on the tradeoffs of both (even the hosts were split on their preference at the end). I was initially attracted towards the git methodology as it gets these business decisions out of the code base - but I also think that having these flags that work at runtime (from a debug menu) is really valuable for testing purposes. One thing I am not convinced on is that there will be "less work at the end" when integrating features into a release with the feature flag methodology - I feel like that could still be a problem if you are not merging/rebasing. They discussed this in the podcast almost as an aside - but it is entirely possible to develop conflicting features using feature flags if developers do not coordinate (I feel this is really an orthogonal issue to enabling features). Still - I think the feature flag solution has promise - but I am way more interested in it if we do it as run time option to get the testing/QA benefits. On Wed, Mar 11, 2015 at 4:08 PM, Bernd Sitzmann wrote: > I have not listened to the podcast yet, but my opinion is similar to what > Brian described. > So, +1 for feature flags. > > Bernd > > On Wed, Mar 11, 2015 at 1:40 PM, Brian Gerstle > wrote: > >> Listened to it this morning, gotta say I think I'm on "Team Flag," if >> it's done well. IMO we should try one (or both) and see how it goes. >> Here's my take on each approach: >> >> Branches are cheap to implement, but come at the a potentially high cost >> if you don't continually rebase and try to keep the work scope as small as >> possible. At a previous job we used git submodules as pseudo feature >> branches. There were common problems w/ dependencies between branches and >> between branches and the main repo, which as the hosts mention are often >> pushed later in the process. >> >> Flags are more expensive to implement up front, but allow for truly >> continuous integration and delivery—as well as the potential for gradual >> rollout. IMO it could also lead to better architected code since feature >> flags require you to codify the boundaries between the "platform" and the >> features (and between the features themselves). You also need to limit >> global state and have good test coverage (which we should do anyway) in >> order to keep undesired side-effects to a minimum. My previous job also >> switched to this model and was able to improve their release cadence and >> sync between features (IIRC, don't have any concrete evidence to back it up >> unfortunately). >> >> >> On Tue, Mar 10, 2015 at 11:16 PM, Corey Floyd >> wrote: >> >>> As luck would have it, a very good tech podcast I subscribe to recently >>> discussed this subject. It is a pretty good listen and discusses trade offs >>> for both feature flags and branching. >>> >>> >>> http://edgecasesshow.com/123-whats-the-deal-with-nsinteger.html >>> >>> (Topic is covered in the 2nd half of the show) >>> >>> >>> On Monday, March 9, 2015, Dan Duvall wrote: >>> >>>> One very simple model that I think works well with distributed software >>>> (and should play somewhat nice with Gerrit) is to branch per minor release >>>> (assuming somewhat semantic versioning). In this model, master can continue >>>> to serve as an integration branch, bug fixes are developed against the >>>> release branch and merged following each patch release, and features are >>>> developed against master per usual. With Gerrit in the mix, you're >>>> essentially left with a two-stage merge for bug fixes which can be a bit of >>>> extra work to get them merged into master, but at least the pipeline is >>>> greased for getting them released. >>>> >>>> I can't say whether this would fit your team's workflow and, as Corey >>>> mentioned, there are many different branching models to consider, each with >>>> its own focus and drawbacks.[1][2] The one I've outlined above is geared >>>> more for stability and maintenance but can probably be tweaked for more >>>> frequent releases of features as well. I'm happy to brainstorm further. >>>> >>>> [1] >>>> http://blog.codinghorror.com/software-branching-and-parallel-universes/ >>>> [2] https://msdn.microsoft.com/en-us/library/bb668955.aspx >>>> >>>> >>>> On Mon, Mar 9, 2015 at 2:30 PM, Corey Floyd >>>> wrote: &g
[WikimediaMobile] Mobile Scale
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) ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Improving Android release cadence
As luck would have it, a very good tech podcast I subscribe to recently discussed this subject. It is a pretty good listen and discusses trade offs for both feature flags and branching. http://edgecasesshow.com/123-whats-the-deal-with-nsinteger.html (Topic is covered in the 2nd half of the show) On Monday, March 9, 2015, Dan Duvall wrote: > One very simple model that I think works well with distributed software > (and should play somewhat nice with Gerrit) is to branch per minor release > (assuming somewhat semantic versioning). In this model, master can continue > to serve as an integration branch, bug fixes are developed against the > release branch and merged following each patch release, and features are > developed against master per usual. With Gerrit in the mix, you're > essentially left with a two-stage merge for bug fixes which can be a bit of > extra work to get them merged into master, but at least the pipeline is > greased for getting them released. > > I can't say whether this would fit your team's workflow and, as Corey > mentioned, there are many different branching models to consider, each with > its own focus and drawbacks.[1][2] The one I've outlined above is geared > more for stability and maintenance but can probably be tweaked for more > frequent releases of features as well. I'm happy to brainstorm further. > > [1] > http://blog.codinghorror.com/software-branching-and-parallel-universes/ > [2] https://msdn.microsoft.com/en-us/library/bb668955.aspx > > > On Mon, Mar 9, 2015 at 2:30 PM, Corey Floyd > wrote: > >> Feature flags would help, but they also add an extra development >> investment to make sure all features are engineered in a way that a flag >> can shut them off without other bad things happening (not necessarily a bad >> thing, but require more effort). >> >> Another route to go is to manage this in git using the branches. There >> are several methodologies for this, and your branching strategy will depend >> mostly on how the team wants to operate. Pretty much all of them boil down >> to NOT merging features into master that are not going to be deployed after >> the current sprint. >> >> >> >> >> On Mon, Mar 9, 2015 at 5:19 PM, Tomasz Finc > > wrote: >> >>> Excited to see this. In order for this to be successful we'll want to >>> developer a health dashboard for the app and set alarming for it >>> whenever we dip above/below certain thresholds. One of the challenges >>> that you face when releasing often is that the amount of attention you >>> keep during small iterative releases. It's easy to keep very focused >>> for 2-3 releases but after that attention can drift to just the major >>> releases. And while it's great to read reviews and find out a >>> subjective metric of how we're doing we need to get in front of it >>> with objective metrics. >>> >>> Thus having an app health dashboard showcasing: search, readership, >>> editing, etc can easily show you if you've had any regressions. These >>> would not only be useful for small bug fix releases but would also >>> help validate our major product releases. >>> >>> I'll leave it with you guys to define what metrics are necessary to >>> define a healthy app. >>> >>> --tomasz >>> >>> On Mon, Mar 9, 2015 at 1:31 PM, Dan Garry >> > wrote: >>> > 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 >>> > >>> > __
Re: [WikimediaMobile] [Apps] Improving Android release cadence
Feature flags would help, but they also add an extra development investment to make sure all features are engineered in a way that a flag can shut them off without other bad things happening (not necessarily a bad thing, but require more effort). Another route to go is to manage this in git using the branches. There are several methodologies for this, and your branching strategy will depend mostly on how the team wants to operate. Pretty much all of them boil down to NOT merging features into master that are not going to be deployed after the current sprint. On Mon, Mar 9, 2015 at 5:19 PM, Tomasz Finc wrote: > Excited to see this. In order for this to be successful we'll want to > developer a health dashboard for the app and set alarming for it > whenever we dip above/below certain thresholds. One of the challenges > that you face when releasing often is that the amount of attention you > keep during small iterative releases. It's easy to keep very focused > for 2-3 releases but after that attention can drift to just the major > releases. And while it's great to read reviews and find out a > subjective metric of how we're doing we need to get in front of it > with objective metrics. > > Thus having an app health dashboard showcasing: search, readership, > editing, etc can easily show you if you've had any regressions. These > would not only be useful for small bug fix releases but would also > help validate our major product releases. > > I'll leave it with you guys to define what metrics are necessary to > define a healthy app. > > --tomasz > > On Mon, Mar 9, 2015 at 1:31 PM, Dan Garry wrote: > > 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 > > > > ___ > > Mobile-l mailing list > > Mobile-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] beta testing win
Actually it was Monte - it was fixed for free™ in his patch. On Thu, Mar 5, 2015 at 8:36 PM, Tomasz Finc wrote: > Props to Corey for getting this fixed up. > > --tomasz > > On Thu, Mar 5, 2015 at 2:34 PM, Dan Garry wrote: > > Thanks Amir! > > > > And, in return, I want to say how grateful both myself and the team are > that > > you're diligently testing our RTL support. Thanks so much. :-) > > > > Dan > > > > On 5 March 2015 at 14:16, Amir E. Aharoni > > wrote: > >> > >> Hi, > >> > >> Just wanted to say how happy I am that the mobile team releases beta > >> versions of the iOS app! > >> > >> Thanks to this bugs like https://phabricator.wikimedia.org/T90032 can > be > >> reported and fixed. > >> > >> It's the whole point of beta testing, but I like saying it out loud and > >> not taking positive things for granted :) > >> > >> -- > >> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי > >> http://aharoni.wordpress.com > >> “We're living in pieces, > >> I want to live in peace.” – T. Moore > >> > >> ___ > >> Mobile-l mailing list > >> Mobile-l@lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/mobile-l > >> > > > > > > > > -- > > Dan Garry > > Associate Product Manager, Mobile Apps > > Wikimedia Foundation > > > > ___ > > Mobile-l mailing list > > Mobile-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Masonry (iOS 3rd party library)
d verbose methods are too cumbersome, use Masonry > if it helps achieve the task with greater clarity, easy, and correctness. > > I trust we'll all be able to make reasonable case-by-case judgments about > when to fall back from XIB+VFL+builtins to Masonry. > > -Adam > > > > > On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd > wrote: > >> Yeah we could swap them out when we need to pretty easily >> >> On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd wrote: >> >>> Oooh interesting! I hadn't considered calling back to the Obj-C version >>> from Swift land... >>> >>> On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber >>> wrote: >>> >>>> It looks like it is possible to use the Obj-C version from Swift: >>>> >>>> https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720 >>>> >>>> so one could probably migrate UI classes using it bit by bit. >>>> >>>> But the new all-Swift version in Snap apparently has a cleaner syntax >>>> that fits with Swift better... >>>> >>>> Actually, do they conflict? Could we start with one in Obj-C and >>>> transition to the Swift one in Swift classes, while both sit in place? In >>>> theory they're creating regular layout constraints so it's just the setup >>>> calls that are different... >>>> >>>> -- brion >>>> >>>> On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd >>>> wrote: >>>> >>>>> I found this Swift version of Masonry: https://github.com/Masonry/Snap >>>>> >>>>> Are we confident in it, or does anyone know if the original Masonry >>>>> repo maintainers have Swift plans? >>>>> >>>>> If not, assuming one of our long-term goals is to eventually convert >>>>> as much of the codebase to Swift as is practical, wouldn't adopting >>>>> Masonry >>>>> further entrench Obj-C implementations? >>>>> >>>>> i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry >>>>> syntax back to VFL strings and/or NSLayoutConstraints. >>>>> >>>>> If there's not a solid Swift implementation, I'd be unsure if Masonry >>>>> use is wise strategically. Thoughts? >>>>> >>>>> Any concern that Masonry's syntax, while concise/elegant, raises the >>>>> bar for outside contributions in that it deviates from the "standard" >>>>> approach at all? >>>>> >>>>> >>>>> On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < >>>>> bgers...@wikimedia.org> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd >>>>>> wrote: >>>>>> >>>>>>> We were evaluating Masonry prior to our new 3rd party lib vetting >>>>>>> process (See here for more info: >>>>>>> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), >>>>>>> but still wanted to do a write up for everyone. >>>>>>> >>>>>>> Masonry is a library that allows developers to write autolayout code >>>>>>> similar to the Visual Format Language, but instead of error prone >>>>>>> strings >>>>>>> to describe relationships, it provides a compact compiler checked >>>>>>> syntax. >>>>>>> You can read more here: >>>>>>> https://github.com/Masonry/Masonry >>>>>>> >>>>>>> >>>>>>> Below are answers to our standard questions: >>>>>>> >>>>>>> >>>>>>>- Is the license permissive? >>>>>>> >>>>>>> Yes - MIT >>>>>>> >>>>>>>- Is the library ubiquitous? >>>>>>> >>>>>>> Yes 4,362+ stars and 475 forks on Github. >>>>>>> >>>>>>>- Is it installable via CocoaPods? >>>>>>> >>>>>>> Yes >>>>>>> >>>>>>>- What is the impact on binary size? >>>>>>> >>>>>>> Negligible - no included assets >>>>>>> >>&g
Re: [WikimediaMobile] Masonry (iOS 3rd party library)
Yeah we could swap them out when we need to pretty easily On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd wrote: > Oooh interesting! I hadn't considered calling back to the Obj-C version > from Swift land... > > On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber > wrote: > >> It looks like it is possible to use the Obj-C version from Swift: >> >> https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720 >> >> so one could probably migrate UI classes using it bit by bit. >> >> But the new all-Swift version in Snap apparently has a cleaner syntax >> that fits with Swift better... >> >> Actually, do they conflict? Could we start with one in Obj-C and >> transition to the Swift one in Swift classes, while both sit in place? In >> theory they're creating regular layout constraints so it's just the setup >> calls that are different... >> >> -- brion >> >> On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd wrote: >> >>> I found this Swift version of Masonry: https://github.com/Masonry/Snap >>> >>> Are we confident in it, or does anyone know if the original Masonry repo >>> maintainers have Swift plans? >>> >>> If not, assuming one of our long-term goals is to eventually convert as >>> much of the codebase to Swift as is practical, wouldn't adopting Masonry >>> further entrench Obj-C implementations? >>> >>> i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry >>> syntax back to VFL strings and/or NSLayoutConstraints. >>> >>> If there's not a solid Swift implementation, I'd be unsure if Masonry >>> use is wise strategically. Thoughts? >>> >>> Any concern that Masonry's syntax, while concise/elegant, raises the bar >>> for outside contributions in that it deviates from the "standard" approach >>> at all? >>> >>> >>> On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle >>> wrote: >>> >>>> +1 >>>> >>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd >>>> wrote: >>>> >>>>> We were evaluating Masonry prior to our new 3rd party lib vetting >>>>> process (See here for more info: >>>>> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), >>>>> but still wanted to do a write up for everyone. >>>>> >>>>> Masonry is a library that allows developers to write autolayout code >>>>> similar to the Visual Format Language, but instead of error prone strings >>>>> to describe relationships, it provides a compact compiler checked syntax. >>>>> You can read more here: >>>>> https://github.com/Masonry/Masonry >>>>> >>>>> >>>>> Below are answers to our standard questions: >>>>> >>>>> >>>>>- Is the license permissive? >>>>> >>>>> Yes - MIT >>>>> >>>>>- Is the library ubiquitous? >>>>> >>>>> Yes 4,362+ stars and 475 forks on Github. >>>>> >>>>>- Is it installable via CocoaPods? >>>>> >>>>> Yes >>>>> >>>>>- What is the impact on binary size? >>>>> >>>>> Negligible - no included assets >>>>> >>>>>- How severe, if at all, are inbuilt subdependencies? >>>>> >>>>> No 3rd party dependencies >>>>> >>>>>- Will this make the code more, or less, understandable for >>>>>volunteers? >>>>> >>>>> More understandable - it provides an expressive "english" syntax for >>>>> creating autolayout constraints. It introduces no new concepts, just type >>>>> checking and syntax. >>>>> >>>>>- What are the performance ramifications of using this library? >>>>> >>>>> None, it uses cocoa autolayout under the covers. >>>>> >>>>>- What are the complexity ramifications of using this library? >>>>> >>>>> Masonry allows developers to write layout code in a much more concise >>>>> and expressive way - this should reduce number of lines while increasing >>>>> expressiveness. >>>>> >>>>>- Is it actively maintained? >>>>> >>>>> Yes
[WikimediaMobile] Masonry (iOS 3rd party library)
We were evaluating Masonry prior to our new 3rd party lib vetting process (See here for more info: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries), but still wanted to do a write up for everyone. Masonry is a library that allows developers to write autolayout code similar to the Visual Format Language, but instead of error prone strings to describe relationships, it provides a compact compiler checked syntax. You can read more here: https://github.com/Masonry/Masonry Below are answers to our standard questions: - Is the license permissive? Yes - MIT - Is the library ubiquitous? Yes 4,362+ stars and 475 forks on Github. - Is it installable via CocoaPods? Yes - What is the impact on binary size? Negligible - no included assets - How severe, if at all, are inbuilt subdependencies? No 3rd party dependencies - Will this make the code more, or less, understandable for volunteers? More understandable - it provides an expressive "english" syntax for creating autolayout constraints. It introduces no new concepts, just type checking and syntax. - What are the performance ramifications of using this library? None, it uses cocoa autolayout under the covers. - What are the complexity ramifications of using this library? Masonry allows developers to write layout code in a much more concise and expressive way - this should reduce number of lines while increasing expressiveness. - Is it actively maintained? Yes and receives frequent pull requests. - Is it compatible with current deployment targets? Yep - Does it hinder interop (e.g., with Swift)? Nope - What is the exit plan if the library becomes unmaintained? Since Masonry is basically just a syntax veneer of autolayout - it should be possible for us to maintain if needed. There aren't any foreign concepts to understand. If we choose not to maintain - the constraints can be translated to the VFL language (or Interface Builder) easily. If anyone has questions / comments - please reply here. ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] iOS code style
Thanks - will take a look today and get to working on the uncrustify script. On Fri, Feb 13, 2015 at 8:13 PM, Monte Hurd wrote: > Great! Thanks again for note taking and updates! > > > On Feb 13, 2015, at 3:17 PM, Brian Gerstle wrote: > > After a meeting in which the team reviewed Corey's suggested coding style > guidelines, I've made the following edits: > >- Use of dot-notation for instance methods that are cheap & free of >side-effects >- Added note about auto-trimming trailing whitespace via Xcode settings >- More "if" statement examples (one-line w/ curly brackets) >- *Ternary statement with ?: operator (Ruby/JS "or" behavior)* >- ObjC method declaration and invocation spacing guidelines >- Block declarations as typedef and method arguments >- Category instance method prefix >- Use of extern for public constants, and static for private ones >- Replaced FJ & Flying Jalapeno w/ WMF & Wikimedia Foundation > > I decided to leave some other stuff for "best practices" (i.e. not coding > style), e.g. telescoping methods and use of *const* for local variables. > > Feel free to leave comments on the talk page or add in anything I missed. > > -- > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] Blockskit (iOS App 3rd Party Library)
(Testing out our new 3rd party library vetting: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries ) Early today I interviewed BlocksKit for a potential position in our codebase (Specifically BlocksKit/Core). BlocksKit is a popular functional veneer for the cocoa frameworks. You can find out more about BlocksKit here: https://github.com/zwaldowski/BlocksKit Read BlocksKit's responses to our interview questions below: - Is the license permissive? Yes, I have an MIT license! Use me how you will. - Is the library ubiquitous? I have 3,100+ stars and 407 forks on Github - people like me. - Is it installable via CocoaPods? Of course! - What is the impact on binary size? Negligible, I don't contain any assets and consist mostly of small categories. - How severe, if at all, are inbuilt subdependencies? I don't need no stinking dependencies. - Will this make the code more, or less, understandable for volunteers? Depends on the volunteer - Those with with functional programming skills will be more comfortable with my syntax. I am however a pretty well documented and lightweight library, so I should be easy to understand for anyone how to use me. - What are the performance ramifications of using this library? None, I use foundation classes to perform enumerations so I get all the performance benefits of the Cocoa collections. - What are the complexity ramifications of using this library? My primary purpose is to remove boiler plate code and make developer intent more clear. I should decrease complexity of your code. - Is it actively maintained? Yes - I am very well cared for and have a nice test suite. - Is it compatible with current deployment targets? Yes - I still have a soft spot for iOS 6. - Does it hinder interop (e.g., with Swift)? I love and Obj-C and Swift (but Swift does include some of my functionality in the standard library) - What is the exit plan if the library becomes unmaintained? Since I am pretty lean and have good test coverage, your team should be able to maintain me if needed. If you decide to not maintain me, you can move some of your codebase to swift to replace some of my functionality. Thanks for reading… If you have any other questions for BlocksKit, be sure to leave them here and we will forward them on. ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Open Source Third Party Libraries in iOS
@Adam - we could try blockskit - that is a relatively simple non-UI library. On Fri, Feb 13, 2015 at 12:51 PM, Adam Baso wrote: > I don't think we have anything just yet, but maybe we could try looking at > _one_ of the recently added libraries just as a proof of process? iOS crew, > any particular simple one we could try this on? > > -Adam > > On Thu, Feb 12, 2015 at 4:49 PM, Tomasz Finc wrote: > >> Good to see this drafted. >> >> What's our first use case to vet our criteria ? >> >> --tomasz >> >> On Thu, Feb 12, 2015 at 4:46 PM, Adam Baso wrote: >> > Following up, here's where we arrived: >> > >> > >> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries >> > >> > -Adam >> > >> > On Wed, Feb 11, 2015 at 9:37 AM, Adam Baso wrote: >> >> >> >> The apps crew is going to be having a meeting to go over third party >> >> library usage in iOS. We're currently use CocoaPods for package >> management. >> >> >> >> In advance of that meeting tomorrow, anybody have advice we should >> >> consider? >> >> >> >> -Adam >> > >> > >> > >> > ___ >> > Mobile-l mailing list >> > Mobile-l@lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > >> > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Face detection service?
en/+/master >>>>> [2] https://github.com/lqs/neven >>>>> >>>>> -- >>>>> Best regards, >>>>> Max Semenik ([[User:MaxSem]]) >>>>> >>>>> ___ >>>>> Mobile-l mailing list >>>>> Mobile-l@lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>> >>>>> >>>> ___ >>>> Mobile-l mailing list >>>> Mobile-l@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>> >>>> >>> >>> ___ >>> Mobile-l mailing list >>> Mobile-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> >> -- >> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle >> IRC: bgerstle >> > > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
