And for those wondering who all is on the mobile team you can find them here
https://www.mediawiki.org/wiki/Mobile_web/Team
Congrats to the team for their success.
--tomasz
On Fri, Jul 11, 2014 at 3:47 AM, Àlex Hinojo <alexhinojo(a)gmail.com> wrote:
> +1
>
> I've been doing wiki workshops for Amical during last couple of years and
> since 6 months ago or so I ONLY train newbies with the visual editor. My
> role on the workshop now is reduced to explain how extra features are done.
>
> So kudos to the mobile team. And I know is not perfect. Is just wiki ;)
>
>
>
>
> 2014-07-11 10:16 GMT+02:00 Pierre-Selim <pierre-selim(a)huard.info>:
>
>> 2014-07-11 10:06 GMT+02:00 Pine W <wiki.pine(a)gmail.com>:
>>
>> > While we're talking about technology issues on WIkimedia-l, I'd like to
>> say
>> > that now that I've worked my way over a few speedbumps with mobile
>> editing
>> > I'm happy with the direction that mobile editing is going, so thank you
>> > Mobile team.
>> >
>>
>> +1
>>
>> I also want to add, that I'm happy with the Visual Editor. It's not
>> perfect, but for basic editing it works just fine. I've had very nice
>> feedback from new user during training on how Visual Editor works.
>>
>>
>> >
>> > Pine
>> > _______________________________________________
>> > Wikimedia-l mailing list, guidelines at:
>> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> > Wikimedia-l(a)lists.wikimedia.org
>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>>
>>
>>
>>
>> --
>> Pierre-Selim
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> Wikimedia-l(a)lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Today I took a stab at combining ogv.js JavaScript-based media playback
with MobileFrontend by adding a loader shim to TimedMediaHandler on the
'mobile' target (the rest of TimedMediaHandler's desktop support code is
not loaded, so the UI is mobile-specific but very bare-bones).
Demo page can now play back audio and video in iOS 7's Safari in mobile
mode as well as desktop mode:
* https://ogvjs-testing.wmflabs.org/
The TMH+ogv.js patch in progress:
* https://gerrit.wikimedia.org/r/#/c/145756/
The mobile loader code checks for any <audio> or <video> elements and asks
them if they canPlayType() on any of their available sources, so it only
loads if non-native playback is actually required. (So for instance it
disengages on Android Chrome which can play Ogg Vorbis audio and WebM
video, or in theory in Safari if you have locally enabled MP4/H.264 files.)
It needs more work to check for browser compatibility, sufficient
JavaScript engine speed, etc, but I find it encouraging that it works so
far. :)
Some thoughts and questions:
* Currently ogv.js gets loaded if any audio/video elements are present that
require it to play, even if they don't get played. I can delay the loading
to when 'play' is clicked fairly easily.
* [[Media:]] or other direct file links, often used for pronunciation
markers in Wikipedia articles, are not picked up by this system. Need to
extend things a bit to detect clicks on such links and display a player
instead of just downloading the file. Same problem occurs in Safari and IE
on desktop mode.
* Should we show the video in an overlay like the mobile media viewer for
images, instead of playing inline? This is a good place to add additional
controls to reach file info details, as with images. If so should I try to
extend the same overlay code in MF or create a near-lookalike that lives in
TMH?
* If so, that should probably be used for *all* mobile browsers, using the
native playback when available instead of loading ogv.js...
* Should we have a manual resolution switcher, as on desktop? (Controlling
source selection via code could also fix a problem with Android being
unable to play Ogg Theora videos, to force it to WebM which does work
natively.)
* On iOS, should the source selector offer to launch higher-res and WebM
videos in the external VLC app? 360p is about the limit of good performance
in ogv.js on current A7-based iOS devices, and slower models max out at
160p if they can even handle that.
-- brion
Yay, that looks awesome! (+mobile-l)
On Tue, Jul 22, 2014 at 4:46 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote:
> OMG this looks great! And so fast :)
> Two small changes
>
> 1. The flag and message should be top aligned
> (let me know if the canvas are is getting in the way for this)
> I can provide a flag icon in a 24 dp focus area with no padding.
>
> 2. The date when the template was added needs to be on its own line, no
> parenthesis. All caps in color #555, 2-3 types sizes smaller than the
> description (I can provide an exact type size value if I know the
> relatives values)
>
> Thanks!
> Vibha
>
>
>
>
> ----
> Vibha Bamba
> Senior Designer | WMF Design
>
>
>
>
>
>
>
>
> On Tue, Jul 22, 2014 at 1:33 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org>
> wrote:
>
>> Vibha,
>>
>> Thank you for the flag icon. Attached you can find some screen shots for
>> the page issues dialog for your review: one with light theme, another one
>> with dark theme. Let me know what needs to change, while I'm working on
>> getting the flag image to show up in the WebView.
>> Now looking at some real-world page issues I see that maybe the original
>> name "article issues" is not so far off since most of the issues seems to
>> mention the word article instead of page.
>>
>> pageIssuesLight.png
>> <https://docs.google.com/a/wikimedia.org/file/d/0BxUyJSM66jQvZUk3Uy1VWEVLX1E…>
>>
>> pageIssuesDark.png
>> <https://docs.google.com/a/wikimedia.org/file/d/0BxUyJSM66jQvWUMwcHdXeW02bHc…>
>>
>> Cheers,
>> -Bernd
>>
>>
>> On Mon, Jul 21, 2014 at 6:07 PM, Vibha Bamba <vbamba(a)wikimedia.org>
>> wrote:
>>
>>> This is consistent with wikifont.
>>> It is set in a 32 dp canvas with 24 dp focus area.
>>> Please lmk if you see any issues :)
>>>
>>>
>>> ----
>>> Vibha Bamba
>>> Senior Designer | WMF Design
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
On Friday afternoon, Juliusz, Dan Foy and I sat down to test the mobile
site on a few lower-end phones and browsers. Specifically, we looked at
en.m.wikipedia on a Nokia not running JavaScript and a higher-end Samsung
phone (Juliusz's) running Opera Mini.
Some issues we may want to figure out/fix at some point in the
near-to-medium future, in order of priority:
1) Using screen size detection to decide whether to serve certain features
to lower-end devices results in some unexpected issues, like the watchlist
star showing up in landscape mode but not portrait mode on Nokia no js.
More pressingly, the search field frame doesn't show up on Opera Mini on a
higher-end phone, despite the fact that it's a no-JS experience (and has no
placeholders in the search field, making the search area weirdly blank and
confusing). According to Dan, the Opera Mini + higher end Android phone
combo is pretty common in the developing world, so we probably need a
better way to handle it. There's an open bug on this here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64926
2) Another issue with Opera mini not showing placeholders: the login and
create account forms appear blank, so it's pretty much impossible to figure
out what to enter into each of the fields. Bug here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68758
3) The watch/unwatch workflow in no-JS mode is pretty wonky: when you tap
the watch star, you get taken to a separate page (which has the article
title at the top, making it look sort of like the article is
broken/missing) that tells you you're now watching the article, but the
star doesn't change state and there's no way to get back to the article
without using browser/device back.
# 2 & 3 point to a larger issue, which is whether login is really worth it
for these users, if pretty much all they can do is watch/unwatch articles
and look at changes to them – the watchlist features might be more
confusing than beneficial, especially in the suboptimal way they're now
implemented, and the Mobile Web team doesn't really have the time/bandwidth
to improve them at this point. I'm leaning toward suggesting that *we
remove login/account creation entirely on no-JS devices and Opera Mini
browser* and only revisit it when we can build a robust set of features
that meet clear end-user needs – but I'd be interested in hearing what you
guys (Zero + Mobile Web) think, and how we might test to figure out what
these user needs are.
The full notes from our testing are here:
http://etherpad.wikimedia.org/p/Lower_end_devices_checkup
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Wait... I'm not convinced by this. I'm not convinced you measured the
right things. How exactly did you measure this? Did you include the
HTTP response time?
I struggle to believe that non-lazy loaded pages could ever be faster
and that the improvement was on a half second.
Can you post more details on the tests you ran?
Really you should be looking at numerous things, namely:
1) Time from user request (refresh page) to being able to read the
content (DOM content loaded) - e.g. time the HTTP request takes when
just using the api and just using HTML
2) Time the JavaScript loads and the page becomes interactive (with a
lazy loaded page this will always be 0s and on a non-lazy loaded page
this will always be more as the entire HTML, JS and CSS has to be
loaded)
cc'ing mobile-l
On Mon, Jul 28, 2014 at 11:39 AM, Maryana Pinchuk
<mpinchuk(a)wikimedia.org> wrote:
> Thanks, Kaldari – I've changed the description in this card[1] to reflect
> your recommendation. Unless anyone objects, we'll remove lazy-loading
> entirely in the next sprint.
>
> 1. https://trello.com/c/fFoRlvxl/3-5-remove-ajax-page-loading-from-alpha
>
>
> On Mon, Jul 28, 2014 at 11:00 AM, Ryan Kaldari <rkaldari(a)wikimedia.org>
> wrote:
>>
>> I did a spike on the effects of lazy loading pages on save. I tried a
>> variety of different articles and did at least 10 tests in each mode.
>>
>> On stub size articles, lazy loading resulted in a half-second improvement
>> in page loading on average. On larger articles, there was greater variation
>> in lazy-loading time and the averages were virtually identical
>> (non-lazy-loaded time was actually 0.15 seconds faster on average, but this
>> was not statistically significant).
>>
>> So basically, lazy loading results in a small improvement for small
>> articles and no improvement for large articles. Given the extra maintenance
>> required (we have to keep maintaining virtually all of the lazy loading code
>> for this specific use even if we don't use it elsewhere), and the frequent
>> bugs that arise, I would still favor removing this feature.
>>
>> Ryan Kaldari
>
>
>
>
> --
> Maryana Pinchuk
> Product Manager, Wikimedia Foundation
> wikimediafoundation.org
We've been receiving a number of crash reports related to clicking on
reference links in certain pages. [1]
Unfortunately I haven't been able to reproduce the error, even when
browsing the very same page as implied in the crash report. The only clue
so far is that the issue seems to be restricted to Japanese pages.
Would anyone with access to an Android device please try to reproduce this?
Here are a couple pages mentioned in the crash reports:
Try clicking reference #4 in this page:
https://ja.wikipedia.org/wiki/%E6%A1%83%E8%8F%AF%E6%9C%88%E6%86%9A
...and reference #3 in this page:
https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%88%E3%83%BC
Let us know if you get a crash from any of the above!
-Dmitry
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=68656
Some articles have beautiful images (See Picasso’s Rose Period) but take up
an entire screen which delays the user from getting to the lead section. We
will attempt to create a stable content areas for illustrative images that
are critical to understanding the article while ensuring that the lead
section is visible on first fold.
Since both landscape and portrait images have to be examined, the team will
take a stab at conserving vertical real estate by either cropping an image
or horizontally stacking relevant images to create a collage of
illustrative content. Click behaviors will ultimately be fairly close and
consistent with media viewer.
At this stage the key objective is getting users to the lead section and
the info box. The objective of this exercise is to make better use of the
space available on small devices. While users can flick and layouts can be
adapted on desktop and tablets, mobile screens are small, hence
choreographing a user's attention is important.
----
Vibha Bamba
Senior Designer | WMF Design
Hi everyone,
The Wikimania Hackathon is coming up, and there's unstructured time after
that. So you may be looking for things to do to help the team get ahead on
its goals. Or, perhaps you've run out of story points in this sprint and
you want to get a head start!
Sprint 38 currently has a number of stories with agreed designs that have
already been estimated. If you're looking for some features to get started
on, that's the place to look!
For iOS, there's lots of miscellaneous stories that were punted from the
current sprint. For Android, there's the release management stuff and
analytics dashboards stuff. :-)
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation