Mobile-l September 2014

mobile-l@lists.wikimedia.org

35 participants
51 discussions

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

Allowing template editors to ship mobile specific styles
by Jon Robson 12 Sep '14

12 Sep '14

In the 2+ years I've been at the Foundation a recurring email thread / bug reports have been in the form "X page doesn't render on mobile" or "Can I have a nodesktop/mobileonly class?" The problem is almost always an issue such as a huge margin left, or some floating or fixed width css. The answer to doing this is to provide a tool for wiki editors to allow them to fix these kinds of problems. There is an RFC [1] open with a suggested solution, and all that is needed now is to implement it. The general consensus was people wanted <style> tags. The original proof of concept however used a separate page (Template:Foo would have a corresponding stylesheet at Template:Foo.css) which was much easier to implement. I truly believe implementing this would reduce the bugs raised about template specific problems, and lead to a better mobile experience. Is this something the mobile team can schedule time for, or some other team? [1] https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templa…

2 2

[WikipediaApp] Android high starttime with WLAN on Motorola Moto G
by florian.schmidt.welzow＠t-online.de 11 Sep '14

11 Sep '14

Hello togeter, especially Android app developers :) in OTRS, there is an android app user (https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=… in german) with a Motorola Moto G who has a high start time (about 50 seconds) of the app using WLAN (mobile network is ok). If he starts the app out of the browser, the app content comes instantly, too. An API request in the browser (http://de.wikipedia.org/w/api.php?action=query&prop=revisions&format=json&r…) is executed without delay, too. Now i have no idea, what happens there, maybe there is something you know? Thanks or advice :) Freundliche Grüße / Kind regards Florian Schmidt

4 3

iOS 8 / iPhone 6 update analysis
by Brion Vibber 10 Sep '14

10 Sep '14

Initial notes from yesterday's Apple announcements and release of iOS 8 & XCode 6 final version to developers: * iOS 8 final version available to developers, but not going out to the public for another week or so -- gives us some more breathing room! * XCode 6 can now be used to submit apps, so we can do a fully 8-ready submission when we're ready. (The update currently in queue has fixes for 8 but is built for 7, which may or may not scale properly on the new devices.) * iPhone 6 introduces a new slightly larger screen size; our existing use of Auto Layout to handle variable screen sizes should handle this fine * iPhone 6 Plus appears to introduce a third screen density/artwork scaling resolution[1] as well as an even larger screen size. I'm investigating to see if we need to scale up any of our SVG/PNG-based icons now for best display. (Use of icon fonts should mean automatic high-resolution icons in most places) [1] What I've seen reported indicates rendering at 3x density, then scaling down slightly to the final 1920x1080 output resolution. I'll see if I can verify this in the Xcode simulators. -- brion

4 7

[Apps] Working on iOS 8 compatibility fixes
by Dan Garry 10 Sep '14

10 Sep '14

Hi everyone, tl;dr: To fit in compatiblity fixes for iOS 8, we're dropping some of our planned iOS work from this sprint. iOS 8 comes out on Tuesday 9th September, right in the middle of our current sprint. Unlike on Android, it's a well acknowledged pattern that iOS users are prolific OS upgraders, so we can expect a significant portion of our user base to migrate to iOS 8 within days of the release. We've discovered a number of compatibility issues between the app and iOS 8. Vibha, Monte and I met to discuss these, and we agreed that having fixes for these in the iOS app is a top priority. This makes these issues a "drop everything we're doing to fix them" situation. Kristen and I have yet to figure out what planned work we need to drop from the current sprint to make up for the extra work, and we're going to figure that out once we've got all the issues documented in cards. Vibha and I are going to do some more comprehensive testing of previously identified pain points for cross-version compatibility (e.g. search), and any additional issues we identify will also be prioritised relative to our current work. To see what we're working on iOS 8 compatibility wise, go to the sprint 39 Trello board <https://trello.com/b/ylAF2Yey/mobile-app-sprint-39-navigation-9-1>, and apply the red "iOS 8 compatibility" filter which we've added specially to track these issues. Let me know if you have any questions! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 3

Standardising icons across projects
by Jon Robson 09 Sep '14

09 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

Re: [WikimediaMobile] Peek Out TOC - Roundup of comments
by Dan Garry 09 Sep '14

09 Sep '14

Forwarding to mobile-l to keep this conversation public. In short, yes. The ToC peekout was a cool idea, but really it looks more like a bug than anything else. But, it's okay that it hasn't worked. The Mobile Apps Team just championed rapid development and experimentation, and that makes us awesome! \o/ I think going with the ToC onboarding for now is fine. The remaining work there is to get it to a state that we're happy with. Then we can see how people respond once that's rolled out, and use that to gate whether we want to further experiment with other ideas. Thanks, Dan On 9 September 2014 16:09, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > Hi team, > Here is a roundup of comments from discussion with design team and a few > other people. In theory the idea makes sense as a continuous idea (Dan came > up with this, recognizing that he forgets to invoke the TOC even though he > is aware that it exists) > > 1. It feels somewhat unpredictable. As a user I'm not sure when this thing > will come out because I can't develop a pattern around it. It seems to > behave differently during up-scroll and down-scroll > > -When you pause scrolling to grab it, it sometimes doesn't come out or > disappears and it feels like you can't get a hold of it. (This makes sense, > because we don't want it to persist if a user has found a section they want > to read. So the delay for dismiss may need to go up a little) > > - As a user I expect it to come out all the way or not at all when you > predict that I need this menu. > > ------- > > Some users brought up that this is an uncommon pattern. While that doesnt > bother me at all, I do believe we want it to feel right i.e predictable > I think we have a great start here but we have some decisions to make as a > team: > > -We can iterate on the speed and timing and test it > -We can wait to see how the TOC onboarding does and tackle this after that > > Dan, we can discuss this next week after the full text search meeting. > > -------- > > ---- > Vibha Bamba > Senior Designer | WMF Design > > > > > > > -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

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

[Apps] iOS 8 testing notes
by Dan Garry 09 Sep '14

09 Sep '14

Hi everyone, The iOS 8 testing notes are available here: http://etherpad.wikimedia.org/p/WikipediaiOSTesting (mw.o page dump <https://www.mediawiki.org/wiki/User:DGarry_(WMF)/Apps/iOS/Testing20140909> ). Note that as we didn't have enough test devices this ended up being more general, but there were a few issues with the iOS 8 build in particular that were identified: - Today doesn't work properly. If you try to scroll after tapping Today, the web view shoots down then gets stuck. (iPhone 5S, iOS 8 build 4.0.2 - 5th September 2014) - In some (unknown) cases, summoning the ToC can cause the webview to resize as expected, but the ToC to never appear and the ToC button to stop working. The only workaround is to manually close the app. (iPhone 4, iOS 7, build 4.0.2.1 - 6th September 2014) - A few esoteric crashes relating to search (e.g. 'click lots of bluelinks' or 'click lots of search results') that I've so far been unable to reproduce. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l September 2014