Re: [WikimediaMobile] SVG to font (WAS: The future of skins_

[Monte Hurd]

> On Sep 3, 2014, at 8:46 PM, Trevor Parscal  wrote:
> 
> The font-to-SVG workflow was an idea to try and make it possible for 
> designers to use their "font is the source" workflow.


Not quite. The point of the conversion scripts (which are done and seem to work 
pretty well) is to make it possible for designers (and me) to use a "svg is the 
source" workflow and pipe these svgs through the scripts if we happen to need a 
font representation. 
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] SVG to font (WAS: The future of skins_

[Trevor Parscal]

It came out in a meeting about icons, that a major impetus of Wikifont was
the workflow for designers being easier if all icons are sourced from a
single font file, and not individual SVG files. The SVG-to-font workflow is
helpful for the iOS app which uses the font (apparently the Android app
does not). The font-to-SVG workflow was an idea to try and make it possible
for designers to use their "font is the source" workflow.

I personally believe that being a designer at Wikimedia should mean working
with open formats (SVG, CSS, HTML), checking assets into git repositories,
and seeking to make community contribution easier, not more difficult. The
idea that a font file, which is a big blob of binary data, be the official
source of all icons just doesn't scale, and makes contribution much more
difficult.

In the meeting we seemed to agree that it was worth developing further the
tools to have more features and an easier workflow when working with SVG
(with PNG fallbacks). Work is already underway to achieve this, and I am
looking forward to us having an easy to use, easy to contribute to and well
performing system for designing, refining and delivering icons.

- Trevor


On Wed, Sep 3, 2014 at 6:43 PM, Matthew Flaschen 
wrote:

> On 08/27/2014 05:51 PM, Monte Hurd wrote:
>
>> I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document
>> and post these in the next couple days.
>>
>
> Is this just a temporary solution since the SVGs for some fonts have been
> lost?
>
> If not, why do we need a font->SVG workflow?  My understanding is that SVG
> is always the source code, even for WikiFont (which generates font file
> output from SVG source code).
>
> Matt Flaschen
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] SVG to font (WAS: The future of skins_

[Matthew Flaschen]

On 08/27/2014 05:51 PM, Monte Hurd wrote:

I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document
and post these in the next couple days.


Is this just a temporary solution since the SVGs for some fonts have 
been lost?


If not, why do we need a font->SVG workflow?  My understanding is that 
SVG is always the source code, even for WikiFont (which generates font 
file output from SVG source code).


Matt Flaschen


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

[WikimediaMobile] new app specific reports

[Bernd Sitzmann]

There are now some app specific reports in
http://mobile-reportcard.wmflabs.org/#apps-graphs-tab.
Since it takes quite some time to load them when there together with the
other reports on the same dashboard I made them also available as a
separate dashboard: http://mobile-reportcard.wmflabs.org/dashboards/apps.

The first three reports are about app edits showing the various stages of
the edit workflow: one for both Android + iOS total, one for Android only,
and one for iOS only.

The next four reports show basically the same data but from a different
perspective: how many times edit got clicked, preview, save attempts,
successful saves.

The last report shows the number of blocked "app users" on English
Wikipedia. For this report you are considered an 'app user' if you've
created the account on the Android or iOS native app.

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

Re: [WikimediaMobile] [Apps] Featuring the app in Google Play

[Tomasz Finc]

Exciting

On Wed, Sep 3, 2014 at 4:16 PM, Dan Garry  wrote:
> Nobody objected, and it's Wednesday now! I'm going to email our contact at
> Google Play now and tell him we'd love our current production build to be
> reviewed.
>
> Dan
>
>
> On 28 August 2014 21:00, Dan Garry  wrote:
>>
>> Unless there are any objections, I will submit our current production
>> build for UX review on Wednesday 3rd September 2014.
>>
>> Once that review is complete, we can take a look at their feedback to see
>> how much work is in there, and set a hard deadline. If we finish our work
>> before that hard deadline, cool, we can submit forthwith! If not, then we
>> submit on the hard deadline irrespective of how done we are.
>>
>> Dan
>>
>>
>> On 28 August 2014 20:14, Tomasz Finc  wrote:
>>>
>>> On Fri, Aug 22, 2014 at 6:27 PM, Dan Garry  wrote:
>>> > That works well with what Bernd said about wanting to submit the app
>>> > for a
>>> > UX review first. We can round off these features while waiting for UX
>>> > review
>>> > to get back to us, see what we make of the UX review, then submit for
>>> > featured.
>>>
>>> Do we have a date to make this happen? Let's keep the wheels moving.
>>>
>>> --tomasz
>>
>>
>>
>>
>> --
>> Dan Garry
>> Associate Product Manager, Mobile Apps
>> Wikimedia Foundation
>
>
>
>
> --
> 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] Search icon in Android app

[Vibha Bamba]

Dmitry - The screenshot looks great. Small spacing tweaks needed for which
I will reach out to you.
Are you going to make the TOC icon consistent with IOS?


Vibha Bamba
Senior Designer | WMF Design








On Fri, Aug 29, 2014 at 10:49 AM, Dan Garry  wrote:

> Agree with the general principle here. I'm on the fence about that
> specific implementation though. Having a grey logo (the magnifying glass)
> next to a black logo (the W) looks clunky.
>
> An option we have is to go with the iOS pattern of having only the icon
> there with no text field (http://imgur.com/8YHklf4), which then expands
> to take up the whole top bar when tapped (http://imgur.com/iztdkhz).
>
> Thoughts?
>
> Dan
>
>
> On 29 August 2014 09:53, Dmitry Brant  wrote:
>
>> 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
>> 
>> ​
>>
>
>
>
> --
> 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] [Apps] Featuring the app in Google Play

[Dan Garry]

Nobody objected, and it's Wednesday now! I'm going to email our contact at
Google Play now and tell him we'd love our current production build to be
reviewed.

Dan


On 28 August 2014 21:00, Dan Garry  wrote:

> Unless there are any objections, I will submit our current production
> build for UX review on Wednesday 3rd September 2014.
>
> Once that review is complete, we can take a look at their feedback to see
> how much work is in there, and set a hard deadline. If we finish our work
> before that hard deadline, cool, we can submit forthwith! If not, then we
> submit on the hard deadline irrespective of how done we are.
>
> Dan
>
>
> On 28 August 2014 20:14, Tomasz Finc  wrote:
>
>> On Fri, Aug 22, 2014 at 6:27 PM, Dan Garry  wrote:
>> > That works well with what Bernd said about wanting to submit the app
>> for a
>> > UX review first. We can round off these features while waiting for UX
>> review
>> > to get back to us, see what we make of the UX review, then submit for
>> > featured.
>>
>> Do we have a date to make this happen? Let's keep the wheels moving.
>>
>> --tomasz
>>
>
>
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>



-- 
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] [Apps] Working on iOS 8 compatibility fixes

[Dan Garry]

After a brief chat with Monte and Kristen, we've decided that we're going
to submit a build to Apple on Friday 5th September. This build will contain
whatever fixes we have for iOS 8 compatibility issues at the time. We've
set this hard submission date so that we don't just spend forever trying to
"get that last fix in!" and never get a build to them... and so that Monte
can relax on his vacation knowing that we've got our fixes in! :-)

We can always submit *another* iOS 8 compatibility build next week if we
get more fixes in. But let's set our initial sights on submitting on the
5th.

Dan


On 3 September 2014 13:32, Dan Garry  wrote:

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



-- 
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] [Apps] Working on iOS 8 compatibility fixes

[Brion Vibber]

To clarify: Apple's got an event scheduled for the 9th which usually means
new product releases in the iOS line, and iOS 8 has been in beta for a
while with a "fall" release plan.

We don't know for sure if that means iOS 8 ships on the day of the 9th, or
if we'll get a release announcement of when it *will* be shipping in new
products and available for upgrades.

But we're a hell of a lot more comfortable betting on early; if we're ready
for 8 early we at worst are behind a week on other stuff; if we're ready
for 8 late we get slammed for some really bad bugs.

-- brion
On Sep 3, 2014 1:42 PM, "Dan Garry"  wrote:

> On 3 September 2014 13:34, Sjoerd de Bruin  wrote:
>
>> Any source for the release date of iOS 8?
>>
>
> The source was my lead iOS engineer and my user experience designer. The
> real issue is that Apple hasn't officially announced anything, so sure,
> we're kind of guessing. That's a fair point.
>
> However, even if we're a week or so off, then this email still stands, as
> the compatibility fixes need to be handled in the current sprint since it
> runs to Friday 12th September.
>
> 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] Media Attribution on Mobile

[Erik Moeller]

tldr: Attribution for media on the mobile lightbox viewer is a bit
inconsistent right now, fixing it is IMO worthwhile and doable (and users
do care a fair bit about how it's handled) but you might land on disabling
mobile lightbox or trying a different approach.  I understand the mobile
lightbox is not a top priority for the team right now.

- - -

Hi,

There's a bit of a discussion here
https://bugzilla.wikimedia.org/show_bug.cgi?id=69656

on how to do attribution in the mobile lightbox viewer. If you're not
involved with that, feel free to ignore the below.

Attribution is a hot topic for a lot of people, because it is viewed as
fundamentally being a matter of respect and recognition of their work. So
if you don't get why this is a big deal for people, please trust me that it
is, and that we need to show some senitivity in how we handle it. :)
Organizationally, we also want to be an example for how to use CC licenses
correctly, and how third parties should re-use content from our projects.

Since I've been participating in the related discussions on desktop MMV a
fair bit, let me try a concise summary of what the issues are. I'm CCing
Luis who can jump in with clarifications (Luis, one "legal requirement"
question for you below, feel free to answer offlist to Maryana/Kaldari if
you prefer).

1) Creative Commons licenses allow for attribution "reasonable to the
medium or means" by which a file is being utilized. That means some level
of variance between desktop and mobile may be defensible.

Other licenses (used for some files) may or may not include similar
provisions; even without them you could argue that the differences in
medium/means justify a different approach.

2) Lightboxes introduce additional step between user and attribution. We do
not show attribution right below the image in an article, and as you
introduce more steps, you stretch the "reasonableness" definition.

On desktop, the paradigm we follow is "Show required attribution wherever
possible, err on the side of including source information since it _may_ be
required" (the metadata is currently very messy on that aspect).

3) Small variations (such as not linking to the username, which makes some
usernames effectively meaningless without going to the File: page) can
stretch the "reasonableness" definition in the eyes of media contributors.
Note, however, that the username sometimes will point to e.g. a Flickr URL,
and will be ambiguous outside the context of Flickr.

4) Right now mobile MMV does not show any links related to the author, and
does not show the source.

- - -

The specific argument in the bug is that mobile devices have limited
displays and input precision and therefore the introduction of too much
detail can confuse and disorient users if they hit these links by accident,
and that the fallback to the File: page ought to be sufficient for
additional details.

There are two separate sets of questions here:

- What's the right thing to do to show the appropriate level of recognition
for media contributors? Can this be done without violating good UX
principles for mobile?

- What's the legal requirement, e.g., is it OK to omit the source link when
an author may explicitly request a source to be linked to?

Here's how I think this question should be decided:

* Hard legal requirements are non-negotiable;

* Legal and the community at large should be a partner in defining what
good attribution practices (beyond hard requirements) should look like, so
a recommendation from legal or repeatedly expressed community wishes that
are not a dealbreaker from a UX perspective should be taken seriously into
account.

My recommendation: Add the link(s) (including the source link if it
contains a URL), if you're concerned about link precision, throw some
mobile user tests at it and see if it actually causes a problem --
abbreviate if needed. But I'm OK with a different outcome, with full
consideration to the above issues.

I don't think that's actually very complicated, though getting abbreviation
and potential layout explosions from rich HTML content right while
retaining basic links may be the biggest development cost. Gergo  / the MM
team may have some advice on how to handle it.

Thanks,
Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Working on iOS 8 compatibility fixes

[Dan Garry]

On 3 September 2014 13:34, Sjoerd de Bruin  wrote:

> Any source for the release date of iOS 8?
>

The source was my lead iOS engineer and my user experience designer. The
real issue is that Apple hasn't officially announced anything, so sure,
we're kind of guessing. That's a fair point.

However, even if we're a week or so off, then this email still stands, as
the compatibility fixes need to be handled in the current sprint since it
runs to Friday 12th September.

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