August 2014 - Mobile-l - lists.wikimedia.org

need for an app? (was: [Wikitech-l] Future platforms, devices, and consumers)
by svetlana 26 Sep '14

26 Sep '14

(Duplicating this mail, as I wasn't subscribed to mobile-l a minute ago.) On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: > [...] > The Wikipedia app is currently under good development and I think its doing > great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana

6 10

OOjs, MobileFrontend and Flow
by Jon Robson 20 Sep '14

20 Sep '14

Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API.

3 6

[Apps] Featuring the app in Google Play
by Dan Garry 18 Sep '14

18 Sep '14

Hi everyone, On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s Android Play Partnerships team. I’ve split up the most relevant information into a few separate emails, to keep the discussion on each separate point focussed. Joe informed us of the process for getting featured in Google Play. The long and short of it is that once we decide we’ve got a build that’s worth featuring, we upload it to Google Play and contact Joe. There is a board at Google that makes the decision about whether or not to feature an app and that decision is multifactorial, including factors like what other apps are featured at that time and whether it fits with the current theme of the store (e.g. “Back to School”, etc.). We made need to make some tweaks to get it featured (e.g. he said they might say something like “Make the app more tablet-friendly and we can feature it”), and we’d be informed of what those were. We’ve got a choice with how we proceed with this: 1. We submit the current form of the production build to be featured. 2. We wait to finish some of the current threads of work (e.g. wrapping up page issues and disambiguation), upload and hold that build unpublished, then submit that to be featured, coordinating the release date with Joe. I have a mild preference for option 2 as then we can coordinate the release of the new features with the featuring, and get more bang for our buck. That said, I am extremely proud of the app that we have out there right now, so I would be more than happy to submit to be featured if that’s the consensus. Thoughts? Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

6 14

Mobile App Retrospective Notes
by Kristen Lans 17 Sep '14

17 Sep '14

The Mobile App team had their monthly retrospective today. Notes, actions and further discussion items are below. https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-August… = Actions/Further Discussion = *Set up quarterly "unstructured sprint" [Kristen/Dan] *Give Vibha & Moiz iTunes account login access [Tomasz]; Waiting on Design iTunes account [Vibha] *Give Vibha & Moiz access to data about user actions [Dan] *Set up monthly apps data review meeting [Dan/Vibha] *Blog post and social media to recruit testers [Monte/Vibha/Moiz] *Explore paid testing services [Tomasz] Velocity Graph has been updated to reflect recent sprints: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0AlEIL4N8KjNndH… Thanks apps team and friends! -Kristen

3 4

Low-quality images are live
by Yuri Astrakhan 16 Sep '14

16 Sep '14

The reduced quality images is now live in production. To see it for yourself, compare original <http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…> with low quality <http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…> images (253KB => 99.9KB, 60% reduction). The quality reduction is triggered by adding "qlow-" in front of the file name's pixel size. Continuing our previous discussion, now we need to figure out how to best use this feature. As covered before, there are two main approaches: * JavaScript rewrite - dynamically change <img> tag based on network/device/user preference conditions. Issues may include multiple downloads of the same image (if the browser starts the download before JS runs), parser cache fragmentation. * Varnish-based rewrite - varnish decides which image to server under the same URL. This approach requires Varnish to know everything needed to make a decision. Zero plans to go the first route, but if we make it mobile, or ever site wide, all the better.

7 11

Nearby screenshot.
by Monte Hurd 14 Sep '14

14 Sep '14

Here's a screenshot of an experimental nearby interface in the iOS Wikipedia app. The little green directional arrows take into account device orientation to guide you to the coordinate. Distances update in real time as well.

8 9

When is mobile search index updated?
by Monte Hurd 14 Sep '14

14 Sep '14

No results for the napa quake page from either apps or mobile web:

5 6

watchlist removal on mobile web
by Amir E. Aharoni 14 Sep '14

14 Sep '14

Hi, A user in the Hebrew Wikipedia pointed out to me that it's uncomfortable to her that after removing a page from the watchlist it is still displayed there. It is gone after refreshing the watchlist, but she says that for her it would make more sense if it disappeared immediately. This is a design question more than a bug, so I'm asking here: what do the designers think? I can see pros and cons in both ways and I wonder how was the current behavior decided: design and user testing or only the developers' intuition? Thank you! -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

4 3

Thoughts on using different wikifont icon for TOC (Wikipedia App)
by Monte Hurd 13 Sep '14

13 Sep '14

When the TOC is closed it would use the one on the left, and when open the one on the right (see attachment). (Reversed for RTL langs of course) I think this would really help distinguish it from just being a "hamburger" type settings icon.

2 1

Standardising icons across projects
by Jon Robson 10 Sep '14

10 Sep '14

Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation

4 5

The future of skins
by Jon Robson 09 Sep '14

09 Sep '14

Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

6 11

VE edits & editors in first 24 hours
by Maryana Pinchuk 04 Sep '14

04 Sep '14

Just an update on VE editing since we pushed it to stable for tablet users (as an opt-in secondary editor on all projects) yesterday: Since yesterday, we're getting about 0.2% of total mobile edits across all projects coming from VE, and about 2% of unique mobile editors having made at least 1 successful VE edit. So the volume is, as expected, pretty low – which is good because it gives us lots of breathing room to fix bugs and improve features before we make VE any more prominent of an editing experience :) For fun, here's a breakdown of which projects those unique editors were on: Project # of unique editors making at least one successful VE edit enwiki 42 eswiki 5 frwiki 4 itwiki 3 svwiki 2 cswiki 2 nlwiki 2 cawiki 1 jawiki 1 thwiki 1 dewiki 1 ukwiki 1 <-- this was me :) -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

2 2

Search icon in Android app
by Dmitry Brant 03 Sep '14

03 Sep '14

Hi Designers, Is there any reason we shouldn't put a search icon next to the "search" text box in the app? (see image) The reason I ask is: - We've received more than one complaint on OTRS saying that the Search field is not discoverable (because it doesn't look like a normal text box). - Every other app that implements any kind of "search" functionality has an icon, so it's universally recognizable. -Dmitry device-2014-08-29-123320.png <https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1V0pLNjh0VGI5cjA…>

4 4

[Apps] Our app code on the Android help pages?
by Dan Garry 03 Sep '14

03 Sep '14

Hi everyone, Yesterday, Katherine, Tomasz and I met with Joe Castorena from Google’s Android Play Partnerships team. I’ve split up the most relevant information into a few separate emails, to keep the discussion on each separate point focussed. Tomasz put forward the idea of using the Wikipedia app as a code tutorial. Have you ever been on the Android help pages online and seen code snippets? Tomasz suggested that since our app is totally open source, they could actually use living examples from the Wikipedia app on those pages if they wanted. It’d be good PR and branding for them to use the Wikipedia app as an example, and it would expose our code base to a much larger group of people, and specifically those people would be developers! This idea is obviously in its infancy, but I think we should definitely try to push forward on this. Many thanks to Tomasz for suggesting this. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

2 1

[Mobile web] Important: putting the mobile web upload features on ice
by Maryana Pinchuk 02 Sep '14

02 Sep '14

*tl;dr: * The Mobile Web team has decided to hide the uploads features (upload & add to article + upload from left nav) on the mobile site until we have the time/resources to rebuild them into a more productive contribution stream. *Background:* Before wikitext or VE editing, the mobile web team built an upload-to-Commons pipeline as the first proof-of-concept of mobile contribution. When we first launched the two upload features (upload and add to article + upload to Commons via the left nav) ~2 years ago, we saw a high ratio of these images being deleted (because they were copyright violations, test images, selfies, etc.). Since then, we've continued to make incremental improvements to address these issues: we added interactive tutorials and instruction screens, and also gradually increased the permission levels required to see these features (from everyone –> logged-in-only –> autoconfirmed only –> 10+ edits). However, despite all these changes, the ratio of kept to deleted uploads has not changed significantly; though the absolute number of uploads per month has gone down,[1] 70-80% of these files still get deleted.[2] This is both a crappy experience for the end-user and a major headache for the team – in addition to the pure engineering effort of continuing to adjust the parameters of the feature, every incremental change to the workflow requires a browser test rewrite, analysis time to figure out if the improvements have actually made a difference, and lengthy back-and-forth communication with a very unhappy set of Commons admins on Bugzilla. And none of the changes to date seemed to have made much of a difference. In trying to address these issues, we've shifted from focusing on the new user persona to the power user... but we're not explicitly revisiting the interactions, messaging, or feature set, because we don't have the bandwidth to make larger changes. I.e., despite the fact that the feature is now not even being shown to brand-new users, we still show a tutorial targeted at people who've never contributed before. I think we've reached diminishing marginal returns on incremental improvements at this point. If we want uploads to succeed, we need to start from scratch: decide who the persona we want to target is and then build the set of features that this user is going to need. But rethinking how to instruct newbies (since tutorials don't seem to work) or coming up with a whole new workflow aimed at experienced users isn't something the team can take on at this point. It requires dedicated product and design attention and quite a bit of engineering work, none of which we have the resources for. Since our focus for the year is new active editors and uploads are not part of our annual targets, I recommended to the team that we hide the mobile web uploading features for now and revisit them either later this year or next fiscal year. The team agreed to this at today's planning meeting, and we'll be making this change in the coming days. I know it's not a great feeling when the software we create isn't a rousing success, but I think it's really important to be upfront (with ourselves as much as with the community) when we see that a feature just isn't doing what we want it to do. Lila has been talking a lot lately about how it seems like we've been trying to do! all! the things! in WMF engineering – which comes at the cost of fragmenting our attention and making it hard to really excel at any one of those things. I think she's totally right, and I'd like to see our team lead by example and strive for more focus and rigor in terms of what we work on and how :) As always, if you have questions/concerns, feel free to voice them here. I'll probably communicate this more broadly sometime early next week. 1. http://mobile-reportcard.wmflabs.org/graphs/unique-uploaders 2. http://mobile-reportcard.wmflabs.org/graphs/deleted-uploads -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

4 4

[Apps] Syntax highlighting - next step is "everything grey!" :-)
by Dan Garry 30 Aug '14

30 Aug '14

Hi everyone, Dmitry, Monte, James, Vibha and I just met to discuss where to go with syntax highlighting in the apps. For a variety of technical reasons, implementing VisualEditor in the apps is a gigantic undertaking. The Mobile Apps team left wondering whether there are lower-hanging fruit that we can run with in the meantime. So we're looking at syntax highlighting for wikitext to make it easier for users to understand. Dmitry has a working prototype (example screenshot <https://trello-attachments.s3.amazonaws.com/52607de6737250777a000201/538f52…>). On discussing this prototype, we were wary that while multi-coloured highlighting makes a lot of sense for programmers it may not make sense for newer users who aren't programmers, and may actually have the opposite of intended effect of making wikitext *more *scary. Oops! The way we're going to proceed is by changing the colour of all the highlighting to grey. That way, the actual content in the wikitext is brought to the foreground. The exception will be wikilinks; the text will be black, but the brackets will be grey. Hopefully this will help users make the association between the wikitext and the reader experience more apparent. We need to choose the right colour such that the text doesn't look disabled and disincline people from touching it if they want to, but we can do that! Since this is a side-project and potentially could make the experience a lot worse if we do it wrong, this is just going to be pushed to the Wikipedia Beta app on Android, and we'll analyse the data. We are *only* going to push this to production if the data strongly supports our hypothesis (i.e. the bounce rate on the edit screen is significantly reduced). If the data does not support this, or is inconclusive, we'll look at other ways to test this hypothesis. Special thanks to James for offering his editing domain knowledge to us for this meeting. :-) Let me know if there any questions! Thanks, Dan *tl;dr: EVERYTHING GREY* -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

6 7

Re: [WikimediaMobile] [Design] Standardising icons across projects
by James Forrester 28 Aug '14

28 Aug '14

On 28 August 2014 11:22, Max <max(a)koehler-kn.de> wrote: > You're welcome. Do you guys have a grunt workflow set up? I'd love to help > out. > Yes, here for OOjs UI <http://git.wikimedia.org/blob/oojs%2Fui.git/HEAD/Gruntfile.js> – we'd definitely welcome suggestions and patches. :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Re: [WikimediaMobile] [Design] Standardising icons across projects
by James Forrester 28 Aug '14

28 Aug '14

On 27 August 2014 12:14, Max <max(a)koehler-kn.de> wrote: > There's a grunt task called grunticon that does #2. > https://github.com/filamentgroup/grunticon Max, That's a pretty awesome find; thank you! J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

[Apps] UX review from Google's Android team
by Dan Garry 26 Aug '14

26 Aug '14

Hi everyone, On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s Android Play Partnerships team. I’ve split up the most relevant information into a few separate emails, to keep the discussion on each separate point focussed. Joe mentioned something that Google offers its partners, called a UX review. He said that he could get the build passed to the Android engineering team at Google, and in short they’d critique every aspect of the user experience. The result would be a long document (on the order of 20 pages) where the Android team at Google would make recommendations about how we could improve the UX of the app. He said that this process is entirely voluntary, so we could take or leave the feedback as we see fit. He did suggest, however, that doing something like this is going to massively increase the way that we’re perceived by Google, and would increase the possibility of getting featured as a “Best App 2014” or “Best Designed App”. Basically, we’d be seen as a shining example of what Android could do. Given that we can take and leave the feedback as we see fit, I think we should definitely do this. Once we have the feedback, we can figure out where the individual items of feedback sit in our priorities. I'm really excited to get some feedback from the people who literally wrote the book on Android design. Thoughts? Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

4 3

[iOS app] Left-hand navigation menu
by Steven Walling 26 Aug '14

26 Aug '14

Now that the left-hand navigation menu has expanded to six links, I'm having a little trouble quickly scanning it to find the item I need. Previously it was no issue, since there were only three or four links. Have we considered adding icons? -- Steven Walling, Product Manager https://wikimediafoundation.org/

4 4

Reviews on iOS
by Moiz Syed 25 Aug '14

25 Aug '14

This is a good app to keep tabs on app reviews on iOS. http://reviewsapp.io/

2 1

iOS Wikipedia app beta 4.01 beta 10
by Monte Hurd 23 Aug '14

23 Aug '14

Today's beta includes the following newness: - Fix for table of contents sometimes causing the article to jump around erratically when selecting a section near the bottom of an article. This fix incidentally made the TOC animation much more smooth :) - Networking crash fix. - More responsive article touch event handling. - Fix for reference panel sometimes flickering to blank. - Better table of contents swipe gesture responsiveness. - Slight increase in size of Nearby item distance label for better readability. If you haven't already signed up to the beta program you can do so here: http://tflig.ht/1dhqz8j Feel free to share this link too!

2 2

Wikipedia Android app Automated builds
by Yuvi Panda 22 Aug '14

22 Aug '14

Hello everyone! Automated builds of the Wikipedia app are now available at http://tools.wmflabs.org/wikipedia-android-builds/ That is a nice little (and barebones) page that simply shows the last time the app was updated, and also offers a download link. You can click 'download' and then install the apk that is received. The app downloaded from this page can also be installed side by side with the normal and beta apps from the Google Play store, so you can have all three! :) Thanks to Dmitry and Bearnd for helping with this. Coming soon: A small app that'll keep checking for updates and nag you if there are any... -- Yuvi Panda T http://yuvi.in/blog

2 4

Playground - Best Android Apps 2014
by Vibha Bamba 22 Aug '14

22 Aug '14

http://time.com/2946631/best-android-apps-2014/ I'm playing with some of these now a days. Dmitry/ Bernd - Please do play with these if you have some time. Specifically good ones are - Google keep (swipe away notes is nice) Open table (Background lead Image loading is interesting, clean typography) Circa News (Clean Layout, nice visual details on the right slider) Photo Editor By Aviary (Strong workflow right from download) ---- Vibha Bamba Senior Designer | WMF Design

1 0

Android Beta release
by Dmitry Brant 21 Aug '14

21 Aug '14

This week's Beta release of the Android app [1] incorporates the following new features and updates: - Rolled up "page issues" boxes into a link that shows them as a popup dialog. - Rolled up disambiguation links into a single link that shows them as a popup list. - Frequently-used languages are now kept at the top of the list, for easier selection. - Improved performance of search auto-completion. - Improved page loading speed and data usage by using compression in network requests. - Using updated versions of Android support libraries Enjoy! (btw, the Beta app now has just shy of 100K active users!) [1] https://play.google.com/store/apps/details?id=org.wikipedia.beta -Dmitry

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l August 2014