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

opensearch vs. prefixsearch
by Dmitry Brant 21 Aug '14

21 Aug '14

I was just looking at the Mobile Web search functionality, and I noticed that the drop-down list of search results in Mobile Web is different from the list in our native apps for the same search term. It looks like Mobile Web uses prefixsearch, whereas the apps are using opensearch. I'm curious what was the rationale for using a different API in the apps? (Wouldn't we want the search results to be consistent between the Apps and Mobile Web?) -Dmitry

6 11

Latest Android test build
by Dmitry Brant 19 Aug '14

19 Aug '14

Hi all, Here is a build that contains the latest (final?) iteration of the page issues / disambiguation verbiage, as well as the latest full-text search design! https://releases.wikimedia.org/mobile/android/wikipedia/scratch/wikipedia-2… -Dmitry

1 0

[Mobile web] Notes from user testing 1st mobile Wikidata game prototype at Wikimania
by Maryana Pinchuk 19 Aug '14

19 Aug '14

During Wikimania, me + Kaldari + Sherah did some in-person testing of a prototype mobile Wikidata game that Sherah built during the hackathon.[1] I've finally transcribed the notes from the testing sessions & thought it might be useful/interesting for folks to read through the summary and raw notes: https://www.mediawiki.org/wiki/Design/Research/Guerilla_testing_Wikigrok. The tl;dr is that we've definitely got some iterating to do on the UX and copy to make this a better, more understandable, less intimidating experience for less experienced/non-Wikipedian users – but it was great to get that feedback early on so we can act on it before writing any of the live code :) Lemme know if you have any questions – and Kaldari + Sherah, feel free to add anything you remember from the testing :) 1. Check it out for yourself on a phone or iOS emulator: http://wikigrok -proto.meteor.com/ -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

3 4

Re: [WikimediaMobile] [Wikitech-l] need for an app?
by svetlana 17 Aug '14

17 Aug '14

On Sun, 17 Aug 2014, at 10:54, Daniel Friesen wrote: > On 2014-08-16, 4:56 PM, Yuvi Panda wrote: > > On Sun, Aug 17, 2014 at 12:40 AM, svetlana <svetlana(a)fastmail.com.au> wrote: > >> Why not use in-browser offline storage? > >> http://www.html5rocks.com/en/features/storage > > One of my favorite articles: > > http://alistapart.com/article/application-cache-is-a-douchebag > > On 2014-08-16, 5:15 PM, svetlana wrote: > > ... > > That is OK, you and Yuvi Panda highlighted some important points. > > Thanks to both - I'll follow-up if I find solution to the application cache issues raised in the blog post linked earlier. > > > > svetlana > > Issues? The article is one of my favourites too, if you read through the > whole thing it describes a technique of combining appcache, > localStorage, and an iframe to make it possible for a site like > Wikipedia to be made to work offline. And localStorage could even be > substituted for IndexedDB (with a polyfill for WebSQL only browsers). > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > Could someone please tell me why I'm getting two different threads with this subject in my inbox? I have trouble following. Thought that your point is that offline storage in browser is hard, and that's /why/ mobile apps exist. It's really hard to discuss this by email. svetlana

1 0

Fwd: user testing VE on mobile
by Kaity Hammerstein 16 Aug '14

16 Aug '14

We did another round of guerrilla testing for VE on mobile today. Overall it was much improved from the last tests! Especially these changes: X icon to back icon, arrow icon to word "next", save page updates, and the switch between edit modes. Here are those findings: - Used back button and it did what they expected - Hesitated when asked to save but all were able to find "Next" button - Filled out the save screen appropriately, although 1 person said it looked like an error screen at first - When asked to switch to wikitext, tapped gear icon almost immediately, but several people still struggled with "edit" and "edit source" language. Everyone also struggled with the pop-up asking them to save before switching. But the link and reference context bars really failed the user tests. :( Most did not notice that the icon in the toolbar was highlighted. Nobody even noticed the context bars, and didn't know what they meant when I pointed to them. More notes https://www.mediawiki.org/wiki/Design/Research/VE_on_mobile#July_30.2C_2014… I would suggest we try adding blue links that say "edit link" and "edit citation" in those context bars, to show a user what they'll be doing specifically. The taller height will also make the bar more noticeable. Then we can test again! Thanks, Kaity

3 3

New Wikipedia Android app production release
by Bernd Sitzmann 15 Aug '14

15 Aug '14

Today's update to the Wikipedia app[1] includes the following changes: Add Today menu Dark theme: appearance of images, background on editing screens, remove inline colors from within tables References with page internal links work now Fix crash when clicking on link in references panel Show number of matches when finding in page (4.1+) Remove flashing of empty message in saved pages/history screens during loading Language variants for Chinese It's basically the same as the beta we pushed on Monday minus the experimental features. It may take an hour or two before it is visible for everybody. A link to the apk is also available[2]. Enjoy! Bernd [1]: https://play.google.com/store/apps/details?id=org.wikipedia [2]: https://www.mediawiki.org/wiki/Mobile/Release_history#Wikipedia

7 17

WG: AW: Article history and categories
by Florian Schmidt 15 Aug '14

15 Aug '14

Forgot mobile-l, so just forwarding. Gesendet mit meinem HTC ----- Forwarded message ----- Von: "Florian Schmidt" <florian.schmidt.welzow(a)t-online.de> An: "Pine W" <wiki.pine(a)gmail.com> Betreff: AW: [WikimediaMobile] Article history and categories Datum: Do., Aug. 14, 2014 13:17 Hello, in Mobile Web there is a feature in alpha mode (settings->beta->settings>experimental) to show categories of a page as a seperate, last expandable section. I don't know when this goes to beta/stable. Kind regards Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Pine W" <wiki.pine(a)gmail.com> An: <mobile-l(a)lists.wikimedia.org> Betreff: [WikimediaMobile] Article history and categories Datum: Do., Aug. 14, 2014 08:28 Any chance of including these links in the Android mobile app and in mobile web? Categories are the subject of a current IEG research project and their omission from mobile might be significant. Article history can be accessed in mobile web through the strapline, but not at all in the mobile Android app. Thanks, Pine

3 2

Browser tests - don't panic
by Juliusz Gonera 14 Aug '14

14 Aug '14

Dan Duvall and I worked on his patch refactoring MobileFrontend browser tests yesterday [1]. We got over half of the tests working on mediawiki-vagrant, but we might have caused some breakage on betalabs/jenkins. The last two builds have lots of failures (over 30), but that doesn't mean that the features themselves are broken. We'll figure it out soon. In general the changes we made were necessary and hopefully will help get everyone running browser tests on their dev instances in the near future. Another nice thing added by Dan is the possiblity of specifying browser tests dependency on other extensions as seen in [2]. Those browser tests will not run (will be skipped) if an extension is not enabled. Instead developers will see a warning saying which extension needs to be enabled to run them. Dan, thanks for all this work. [1] https://gerrit.wikimedia.org/r/#/c/147115/ [2] https://gerrit.wikimedia.org/r/#/c/152993/ -- Juliusz

3 3

Article history and categories
by Pine W 14 Aug '14

14 Aug '14

Any chance of including these links in the Android mobile app and in mobile web? Categories are the subject of a current IEG research project and their omission from mobile might be significant. Article history can be accessed in mobile web through the strapline, but not at all in the mobile Android app. Thanks, Pine

1 0

ToC in Android app
by Dmitry Brant 13 Aug '14

13 Aug '14

True story: My girlfriend was using the Android app yesterday on her device, and she told me, "It would be great if you had an option to jump to specific sections... It's difficult to scroll all the way down to the section I'm looking for!" :)

4 3

Creating a shell app to house Wikidata games
by Monte Hurd 13 Aug '14

13 Aug '14

I hate to dissent, but I don't think a separate app is the way to go at this time for a few reasons. First, many of the types of contributions to wikidata that we've talked about game-ifying are article specific. ie, "have user read some portion of an article and summarize what it's about in 5 words or less", etc. This would mean we'd need search and browse etc, and my gut tells me a variety of other context and interactions the existing app provides would need to be recreated. If the existing app could launch the game app, that could be one way to provide context, but from a UX perspective, we would otherwise be limiting ourselves to tasks that didn't require heavy back-and-forth comparisons and the transition between apps, at least on iOS, is super annoying (the way Facebook swaps out to Messenger annoys the hell out of me). I also think, at this time, our limited resources are better spent carefully crafting one or two gamed interactions which we can carefully insert into the existing app rather than having to solve the inevitable wider set of challenges a new app would present. The existing app also has a flood of users based on name recognition alone. Although I suppose we could call it "Wikipedia Games"... tl:dr, game-ify yes, other app no/not now > On Aug 9, 2014, at 17:37, mobile-l-request(a)lists.wikimedia.org wrote: > > Send Mobile-l mailing list submissions to > mobile-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/mobile-l > or, via email, send a message with subject or body 'help' to > mobile-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > mobile-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Mobile-l digest..." > > > Today's Topics: > > 1. Creating a shell app to house Wikidata games (Tomasz Finc) > 2. Re: Creating a shell app to house Wikidata games > (May Tee-Galloway) > 3. Re: Creating a shell app to house Wikidata games (Dmitry Brant) > 4. Re: Creating a shell app to house Wikidata games (Moiz Syed) > 5. Re: Creating a shell app to house Wikidata games (Yuvi Panda) > 6. Re: Creating a shell app to house Wikidata games (Bernd Sitzmann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 9 Aug 2014 13:35:41 +0100 > From: Tomasz Finc <tfinc(a)wikimedia.org> > To: mobile-l <mobile-l(a)lists.wikimedia.org> > Subject: [WikimediaMobile] Creating a shell app to house Wikidata > games > Message-ID: > <CAMxhqbdO_ARWufx-LTSruXaDAsjmeOvcrc3MeZdq7dsQiX1acA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > It's been amazing to see the interest in WikiData games here at > Wikimania and i've been approached by a number of people who've wanted > to create them. From label creation to data validation there have been > many ideas of how to engage users in new and creative ways. > > I'm curious to hear from users on this list and beyond about interest > in a WikiData games app that would facilitate simple and quick > contributions. > > The idea would be that the app would act as a simple frontend shell > that would allow anyone to interact with WikiData games to create, > curate, and validate content. Putting aside the difficulties of > dynamic custom user content with the app I'm curious about the > interest in this. > > I know that that mobile web team is already planning a handful of > experiments with this and I'm eager to see if some of you would > frequent an app that collected these and empowered users to contribute > in ways that doesn't exist yet. > > Do let know > > --tomasz > > > > ------------------------------ > > Message: 2 > Date: Sat, 9 Aug 2014 15:11:04 +0100 > From: May Tee-Galloway <mgalloway(a)wikimedia.org> > To: Tomasz Finc <tfinc(a)wikimedia.org> > Cc: mobile-l <mobile-l(a)lists.wikimedia.org> > Subject: Re: [WikimediaMobile] Creating a shell app to house Wikidata > games > Message-ID: > <CAN4BDz4AE=+XCM=6+OY6_1h5sDLbjuzg7d5U72Hjn11cXY1Fug(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > You got a designer here! > > >> On Sat, Aug 9, 2014 at 1:35 PM, Tomasz Finc <tfinc(a)wikimedia.org> wrote: >> >> It's been amazing to see the interest in WikiData games here at >> Wikimania and i've been approached by a number of people who've wanted >> to create them. From label creation to data validation there have been >> many ideas of how to engage users in new and creative ways. >> >> I'm curious to hear from users on this list and beyond about interest >> in a WikiData games app that would facilitate simple and quick >> contributions. >> >> The idea would be that the app would act as a simple frontend shell >> that would allow anyone to interact with WikiData games to create, >> curate, and validate content. Putting aside the difficulties of >> dynamic custom user content with the app I'm curious about the >> interest in this. >> >> I know that that mobile web team is already planning a handful of >> experiments with this and I'm eager to see if some of you would >> frequent an app that collected these and empowered users to contribute >> in ways that doesn't exist yet. >> >> Do let know >> >> --tomasz >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >

6 5

Your account has been limited until we hear from you PP-503-472-206
by mobile-l＠lists.wikimedia.org 11 Aug '14

11 Aug '14

2 1

Lila's keynote speech at Wikimania 2014
by Pine W 09 Aug '14

09 Aug '14

Hi all, I would like to encourage those of us who may have missed Lila's keynote speech at Wikimania to listen to it. [1] In her speech, Lila takes a long view of Wikimedia's history and future. She talks about incremental and disruptive changes that are happening socially and technologically such as the shift toward mobile and wearable computing, and the use of technology in the developing world. She also talks about modes of contribution, and changes inside the Wikimedia projects that would encourage more people to participate actively. Thanks very much, Lila. I look forward to seeing how the trends and opportunities that you describe are addressed in our new strategic plan. Pine [1] http://new.livestream.com/wikimania/saturday2014

1 0

Creating a shell app to house Wikidata games
by Tomasz Finc 09 Aug '14

09 Aug '14

It's been amazing to see the interest in WikiData games here at Wikimania and i've been approached by a number of people who've wanted to create them. From label creation to data validation there have been many ideas of how to engage users in new and creative ways. I'm curious to hear from users on this list and beyond about interest in a WikiData games app that would facilitate simple and quick contributions. The idea would be that the app would act as a simple frontend shell that would allow anyone to interact with WikiData games to create, curate, and validate content. Putting aside the difficulties of dynamic custom user content with the app I'm curious about the interest in this. I know that that mobile web team is already planning a handful of experiments with this and I'm eager to see if some of you would frequent an app that collected these and empowered users to contribute in ways that doesn't exist yet. Do let know --tomasz

6 5

Main page - good practices, future plans
by Amir E. Aharoni 08 Aug '14

08 Aug '14

Hi, The Hebrew Wikipedia community is questioning the current design of the Mobile main page, and this raises some questions about the mobile main page design for all languages. I don't have a strong opinion myself, but the current tendency is to show all the boxes rather than just a few, as it is now. This begs the question - is it really good for mobile readers? For example, is the mobile main page very popular at all, or is there much more traffic to the articles? Is there a difference between mobile main page traffic in the app and in the mobile web? Are there any known good practices for mobile main page design? Finally, what is the plan for the future development of the main page? The current software still uses HTML ids like "mp-tfa"; is there a plan to change it? Thanks! -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

4 4

Documentation of Hooks in MobileFrontend
by Florian Schmidt 07 Aug '14

07 Aug '14

Hello all together, is there a documentation of Hooks implemented in MobileFrontend (i haven't found any)? Like the Hook documentation of Core [1]. [1] https://www.mediawiki.org/wiki/Manual:Hooks#Alphabetical_list_of_hooks Kind regards, Florian

4 7

Dependencies of MobileFrontend vagrant role
by Juliusz Gonera 06 Aug '14

06 Aug '14

I talked to Dan Duvall today and he said that many mobile browser tests fail on default vagrant instance because other extensions that are not hard dependencies of MF are not activated by default when activating the mobilefrontend role (extensions such as Echo, GeoData, VisualEditor). There are two things we can do: 1. Make other extensions that mobile uses dependencies of mobilefrontend role in vagrant 2. Create a separate role, e.g. mobilefrontend-browsertests, that will list mobilefrontend and all those extensions as its dependencies I was wondering if there is anyone who uses vagrant and would like to have MF enabled, but not all the other extensions. If not, 1. seems like a simpler solution. Thoughts? -- Juliusz

5 13

Re: [WikimediaMobile] Wikipedia IOS App - Accessibility Concerns in Voiceover Mode
by Tomasz Finc 06 Aug '14

06 Aug '14

Shifting to mobile-l@ --tomasz On Wed, Aug 6, 2014 at 2:00 AM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > In voiceover mode swiping up, doesn't re-invoke nav controls. > > This prohibits navigation. Currently, the following elements are hard to get > to > > -search ( because its hard to scroll back to top) > > -toc > > -home menu > saved articles > > -previous and next articles. > > -save action > > Twitter carries a special mode when voiceover is switched on. On Google Maps > & Twitter - the top areas for controls have enlarged target sizes and the > content area is much smaller. > > Brion/ Monte - one quick question - Is there a way we can persist navigation > in voiceover mode? > > ---- > > Vibha Bamba > Senior Designer | WMF Design > > > > > >

1 0

Fw: Segue Dados em anexo. (86185)
by mobile-l＠lists.wikimedia.org 05 Aug '14

05 Aug '14

1 0

FYI: Android Wear app
by Max Semenik 05 Aug '14

05 Aug '14

http://www.androidpolice.com/2014/08/04/new-app-attopedia-is-a-surprisingly… -- Best regards, Max Semenik ([[User:MaxSem]])

3 2

New Android beta release
by Bernd Sitzmann 04 Aug '14

04 Aug '14

Today's update to the Wikipedia Beta App[1] includes the following changes: Add Today menu Dark theme: appearance of images, background on editing screens, remove inline colors from within tables References with page internal links work now Fix crash when clicking on link in references panel Show number of matches when finding in page (4.1+) Remove flashing of empty message in saved pages/history screens during loading Language variants for Chinese Experimental: Show flag button for "Page issues" Show "Similar titles" link to go to disambiguation page It may take an hour or two before it is visible for everybody. Please report any bugs you encounter, so we can fix them before we push the bits to the production app. Enjoy! Bernd [1]: https://play.google.com/store/apps/details?id=org.wikipedia.beta

1 0

Accessibility issues on iOS
by Brion Vibber 04 Aug '14

04 Aug '14

We've gotten a couple of reports of accessibility issues with the iOS app, especially with buttons not being read aloud in VoiceOver mode. I've filed https://bugzilla.wikimedia.org/show_bug.cgi?id=69120 so we don't forget to research exactly how to fix that up -- there should be accessibility role and label fields we can set on the labels and buttons to let VoiceOver pick them up correctly, so that part should be an easy fix once we get in there. We may also want to make slight adjustments to content HTML to reduce redundant link titles. -- brion

1 0

Wikipedia iOS 4.0.1 bugfix release pushing to App Store
by Brion Vibber 04 Aug '14

04 Aug '14

Lots of bugfixes and some more UI translations; no major new features introduced (but we did add a 'Today' link in the W menu which brings you back to the main page for the current language). This should help address the issues with crashing on startup, though we need to do further investigation on what might be causing those. There are still known problems on some old iOS 6 devices which we're continuing to poke at. -- brion

3 3

Re: [WikimediaMobile] Unable to edit in Mobile
by Florian Schmidt 04 Aug '14

04 Aug '14

On Desktop you don't have an edit button for the section, too: https://en.wikipedia.org/w/index.php?title=Wikipedia%3AWikipedia_Signpost%2… The content of the section in mobile is included with a template if i see this right, isn't it? To change this content you must edit the template target. Kind regards Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Pine W" <wiki.pine(a)gmail.com> An: <florian.schmidt.welzow(a)t-online.de> Betreff: [WikimediaMobile] Unable to edit in Mobile Datum: So., Aug. 3, 2014 09:04 Hi, then in this case the problem is that on mobile web there is only one pencil icon on this page when there should be pencils for multiple sections. Should this go on Bugzilla? https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-07-30/Wik… Pine Hello! To the mobile web problem: do you mean, that it only lpads one section instead of the entire article? If yes: thats normal and expected. On mobile you can edit only a section, not the entire article. Kind regards, Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Pine W" <wiki.pine(a)gmail.com> An: <mobile-l(a)lists.wikimedia.org> Betreff: [WikimediaMobile] Unable to edit in Mobile Datum: Sa., Aug. 2, 2014 09:34 I get a network error when I try to edit on the Android app, and on moble web only a small section loads in the edit window of the Signpost article I want to edit, but I can read articles ok. Did something break for mobile editing? Thanks, Pine

3 4

WG: AW: Unable to edit in Mobile
by Florian Schmidt 02 Aug '14

02 Aug '14

Damn, forgot mobile-l :) Gesendet mit meinem HTC ----- Forwarded message ----- Von: "Florian Schmidt" <florian.schmidt.welzow(a)t-online.de> An: "Pine W" <wiki.pine(a)gmail.com> Betreff: AW: [WikimediaMobile] Unable to edit in Mobile Datum: Sa., Aug. 2, 2014 10:57 Hello! To the mobile web problem: do you mean, that it only lpads one section instead of the entire article? If yes: thats normal and expected. On mobile you can edit only a section, not the entire article. Kind regards, Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Pine W" <wiki.pine(a)gmail.com> An: <mobile-l(a)lists.wikimedia.org> Betreff: [WikimediaMobile] Unable to edit in Mobile Datum: Sa., Aug. 2, 2014 09:34 I get a network error when I try to edit on the Android app, and on moble web only a small section loads in the edit window of the Signpost article I want to edit, but I can read articles ok. Did something break for mobile editing? Thanks, Pine

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l August 2014