Re: [WikimediaMobile] Standardising icons across projects

[Jon Robson]

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

Monte any updates on this?

>
> 2) Trevor is going to look into how we can automatically generate
> different colour versions of SVGs and automatically create PNGs from
> them.

Trevor any updates?

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

I'm still working on this. Sam Smith has now suggested a mixin based
approach [1] which I am not too comfortable with as I think it works
against standardisation by allowing far too much flexibility and I
don't see how it will map to us using OOJS for it in future.

A class based approach [2] that follows the http://i.imgur.com/bieQ9zn.jpg

Please chime in on those patches - I'm super keen to make progress on
this to get our icon generation mechanism under control.

[1] https://gerrit.wikimedia.org/r/139368
[2] https://gerrit.wikimedia.org/r/158632

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Peek Out TOC - Roundup of comments

[Dan Garry]

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  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
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] The future of skins

[Jon Robson]

> 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.
>
Hey Trevor
Are you able to update us on the current status of the above?
Have you begun work on them? Are there any patches you can point at us
(even if they are work in progress patches?)

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] OOjs, MobileFrontend and Flow

[Jon Robson]

Update: Roan's patch got merged but Max identified an issue with it in
MobileFrontend which is stopping us switching over to use it in
MobileFrontend [1]

It seems to be related to an event that we use called 'progress' that
we use in our api handler.

You can replicate it by trying to do a wikitext edit in the stable
mode of the mobile site with the above patch.

Uncaught TypeError: Cannot use 'in' operator to search for 'progress'
in undefined 
load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68oo.EventEmitter.emit
load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68(anonymous
function)

Not sure if this is an issue with OOJS or the patch Roan made for us.
Any ideas VE guys?

[1] https://gerrit.wikimedia.org/r/#/c/129336/


On Fri, Aug 22, 2014 at 11:36 AM, Jon Robson  wrote:
> 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.

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] iOS 8 testing notes

[Monte Hurd]

Brion fixed the first issue. 

> On Sep 9, 2014, at 2:26 PM, Dan Garry  wrote:
> 
> Hi everyone,
> 
> The iOS 8 testing notes are available here: 
> http://etherpad.wikimedia.org/p/WikipediaiOSTesting (mw.o page dump).
> 
> 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
> ___
> 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

[WikimediaMobile] [Apps] iOS 8 testing notes

[Dan Garry]

Hi everyone,

The iOS 8 testing notes are available here:
http://etherpad.wikimedia.org/p/WikipediaiOSTesting (mw.o page dump

).

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
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Allowing template editors to ship mobile specific styles

[Jon Robson]

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 

[WikimediaMobile] [Apps] Trial of separate Trello boards for iOS/Android

[Dan Garry]

Hi everyone,

tl;dr: We’re trialling having separate Trello boards for the iOS and
Android apps sprint 40.

The Mobile Apps Team has been chatting about its process around Trello
boards recently, and the following issues were identified with our current
"one board for both iOS and Android" structure:

   - The iOS and Android engineering efforts are completely separate.
   - Each platform has its own tech lead.
  - The iOS engineers only work on iOS cards, and the Android engineers
  only work on Android cards.
  - The codebase between the apps is not shared (except for a little
  bit of JS).
  - Slack on one platform can’t be picked up by the engineers on the
  other.
   - The iOS and Android engineers have different velocities. Part of this
   is because Android currently has an additional engineer, but it’s also
   because the cards are disjoint and therefore slight differences are
   emerging in how the cards are estimated.
   - Tracking these different velocities separately of each other is
   senselessly difficult with a single shared board, because you have to apply
   and remove filters to do so.
   - In the past, features were implemented on both platforms at the same
   time, but that isn’t happening anymore due to velocity differences.
   - Engineers almost always have a filter on to only show the cards for
   the platform they work on, so having the cards from the other team in their
   board has little use.

In short, the team has decided that having a single board for both iOS and
Android isn’t actually serving anyone in the team anymore, and instead it’s
just causing some slight inconveniences.

We’re going to try having separate boards for the iOS and Android apps in
sprint 40. The meeting structure will remain the same; we are still a
single team, and the engineers from both platforms share a lot of expertise
and ideas with each other, and we don’t want to lose that. This experiment
is ultra safe-to-fail, as if we decide it’s not working at any point then
we can immediately move all the cards into a single board then archive the
second board.

Let me know if there are any questions.

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

Re: [WikimediaMobile] Pulling the Commons app

[Bernd Sitzmann]

I agree. It should be pulled from both the store and disabled on
translatewiki.net.

On Mon, Sep 8, 2014 at 9:54 PM, Monte Hurd  wrote:

> I think it should be pulled.
>
> On Sep 8, 2014, at 7:10 PM, Dan Garry  wrote:
>
> On 6 September 2014 15:40, Derk-Jan Hartman 
> wrote:
>
>> I propose we remove the Wikimedia Commons app from the store.
>> Clearly there is no time available to work on it, there is no one
>> maintaining it or following up on the problems that have been reported
>> since 2013.
>>
>
> Thanks for the suggestion.
>
> Practically speaking, maintaining this app would mean cannibalising
> resources currently devoted to the Wikipedia app. Brion and Yuvi are the
> engineers with the most experience in the Commons app. They're currently
> split a few different ways (Brion with his duties as an architect, Yuvi
> with duties to ops) and I'm not eager to split them even further.
>
> Some framing on userbases: The Commons Android app is installed on around
> 7,000 devices, compared to the 10 million devices with the Wikipedia app
> installed on it. The Commons app gets around 300 users per month, and there
> are more edits than that from the Wikipedia app per day to the English
> Wikipedia alone. The Commons app user base is minuscule compared to the
> Wikipedia app.
>
> Remember that sunsetting the app and removing it from the store would not
> uninstall it from the devices it's currently installed on, so those people
> using it would be able to do so. Also, the code would continue to be
> available, so if someone wanted to clean it up as a volunteer we could then
> re-publish it easily enough.
>
> So, in summary, I agree with DJ.
>
> Thoughts, team?
>
> 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
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Jobs page doesn't work

[Jeremy Baron]

On Sep 9, 2014 12:31 PM, "Jon Robson"  wrote:
> I'm the main opposition of a mobile only class. I've been opposing
> many requests for it as I believe it isn't sustainable, it basically
> means you maintain 2 copies of a page and also as a result you
> increase the page load for mobile users by including desktop only
> content in the HTML markup. I'm also keen in future to kill the
> nomobile class but this is a long way off.

2 copies maintained is an option I considered but I had something else in
mind.

Hiding one way or another inline and maintaining only 1 copy. (Instead of
the top level hiding we have now, we could hide (or show) smaller elements
as needed.

-Jeremy
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Jobs page doesn't work

[Jon Robson]

I'm the main opposition of a mobile only class. I've been opposing
many requests for it as I believe it isn't sustainable, it basically
means you maintain 2 copies of a page and also as a result you
increase the page load for mobile users by including desktop only
content in the HTML markup. I'm also keen in future to kill the
nomobile class but this is a long way off.

The real solution to this is to push
https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates
through to completion. I haven't had time to work on this but I really
think it is one of the most important existing RFCs and sadly out of
the realm of my expertise. This would allow designers to use media
queries in markup and style  content differently in mobile/desktop.

Any takers?




On Mon, Sep 8, 2014 at 2:19 PM, Heather Walls  wrote:
> I asked for a mobile only class a number of times. Not a perfect fix by all
> means...
>
> On Mon, Sep 8, 2014 at 2:17 PM, Moiz Syed  wrote:
>>
>> We can also, for the short time being, maintain a mobile-only page with
>> just links to our current job postings.
>>
>>
>> On Mon, Sep 8, 2014 at 2:09 PM, Pine W  wrote:
>>>
>>> I guess we need to hire them to fix the mobile web job page!
>>>
>>> Pine
>>>
>>> On Mon, Sep 8, 2014 at 2:00 PM, Moiz Syed  wrote:

 Our jobs page doesn't work on mobile web.

 I was trying to send someone this page for the mobile web job and it
 wasn't good experience. This is the first thing a potential job candidate
 sees, we should fix this quick.

 Thanks!

 Mobile: http://m.wikimediafoundation.org/wiki/Work_with_us
 Desktop: http://wikimediafoundation.org/wiki/Work_with_us

 ___
 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
>>
>
>
>
> --
> Heather Walls
> Communications Design Manager
> WikimediaFoundation.org
> heat...@wikimedia.org
>
> ___
> 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