Hi all,
we have recently added some funnel [1] logging to UploadWizard. A nice
dashboard is in the works, but here are some preliminary results, showing
the number of virtual pageviews for each step of UploadWizard.
mysql:research@s1-analytics-slave.eqiad.wmnet [log]> select event_step,
count(*), count(*)/3623 as survival_rate from UploadWizardStep_8612364
group by event_step order by survival_rate desc;
+------------+----------+---------------+
| event_step | count(*) | survival_rate |
+------------+----------+---------------+
| tutorial | 3623 | 1.0000 |
| file | 3496 | 0.9649 |
| deeds | 2433 | 0.6715 |
| details | 2373 | 0.6550 |
| thanks | 2109 | 0.5821 |
+------------+----------+---------------+
This is based on about a day's worth of logs (25.5 hours) - the logging
code was deployed to Commons yesterday.
The big drop is apparently in the file upload step (almost 30% - well over
1000 uploads a day). Some of that might be intentional (upload caught by
badtitle filter etc), but even so the drop is huge. Given that that step is
rather simple from a UX point of view, it seems that upload bugs are a
bigger problem right now than design issues.
(The license selection - deeds -> details - on the other hand is
unexpectedly unproblematic; I would have expected it to be the main source
of confusion, but actually adding description etc. seems worse.)
The next step would be to log JS/upload errors, I suppose.
Also, it would be nice to know which dropoffs are final and which are
reloads/restarts. The Navigation Timing API can tell apart reloads and
normal navigation, alternatively we could maybe group by IP + useragent +
time bucket to find retries.
Thanks Yuri,
CC'ing Multimedia team
Maryana, this could be something interesting for the Mobile Web team
to look at to optimize image delivery.
Have you guys done any perf work around images?
--tomasz
On Thu, Jun 5, 2014 at 4:10 PM, Yuri Astrakhan <yastrakhan(a)wikimedia.org> wrote:
> The reduced quality images is now live in production. To see it for
> yourself, compare original with low quality 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.
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
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
We can definitely add older Operas to the blacklist if they are
problematic. First we need to investigate if the issue is at the OOJS
level, in which case if might be fixable, since OOJS now supports older ES3
browsers thanks to a shim.
Added to the current cycle on Mingle:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/813
---------- Forwarded message ----------
From: Erik Moeller <erik(a)wikimedia.org>
Date: Sun, Jul 27, 2014 at 2:28 AM
Subject: MMV browser blacklist?
To: Gergo Tisza <gtisza(a)wikimedia.org>, Gilles Dubuc <gdubuc(a)wikimedia.org>,
Fabrice Florin <fflorin(a)wikimedia.org>
It looks like we're only blacklisting old versions of MSIE now? I saw a
user report that it completely blocked image views on an older browser and
just went into crossbrowsertesting.com to test with Opera 10 (they didn't
specify a browser but Opera and old IE versions are always my first guess).
Indeed image clicks just die -- and the error console throws oojs errors.
Seems to me like we either want to most likely significantly expand that
blacklist to cover older, more obscure browsers that otherwise lose
complete access to images, no?
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Hi ops,
Has the swift capacity been increased yet thanks to the new hardware? If
so, could we resume the discussion of "pre"generating specific thumbnail
sizes at upload time?
Media Viewer could benefit greatly from this performance-wise. As seen on
this graph, the launch to all wikis affected the average considerably,
since users started hitting a lot of images that didn't have Media
Viewer-sized thumbnails yet:
http://multimedia-metrics.wmflabs.org/dashboards/mmv#overall_network_perfor…
Thumbnailing improvements are still in the works on our end, and the idea
of not using swift anymore for those is definitely on the team's radar
(we've started working on more modest thumbnailing improvements at this
point), but if the capacity is there, we might as well improve the average
image load time for our users, even if the ever-increasing swift use for
thumbnail is still a problem itself.
On Mon, Apr 21, 2014 at 11:16 AM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
> Hi all,
>
> Do you guys have a rough estimate of when the new swift capacity will be
> installed?
>
> Now that we're in the process of Media Viewer's launch to all users on
> pilot sites, the question of when we'll be able to prerender thumbnails at
> desired bucket sizes has come up again.
>
"Commons configuration of Upload Wizard does not belong here" was the
premise under which a patch by a Wikimedia Commons contributor has been
recently rejected in the Upload Wizard repository. There was neither an
explanation of where to put the patch instead, nor anything helpful
about how to achieve it. And it turned out that it's non-trivial.
Okay, so I thought I give the contributor a helping hand and propose
alternative patches. While doing so, I discovered that re-configuring
Upload Wizard in *Settings.php is overly difficult when it comes to
licensing options: While it is possible adding licenses (having a
license label and a template grouped by a key) one has to repeat all the
license groups (this is how the previously defined licenses are grouped)
for example for third party licenses for having just one augmentation.
It has been suggested creating an Extension for licensing options; this
would most likely solve the issue with translation of these options but
it won't solve anything regarding grouping of these licenses. This needs
to be fixed in Upload Wizard. So what could we do about it?
Have the entire license grouping configuration
* … in *Settings.php
* … on-wiki in a page in the MediaWiki namespace
* … on-wiki in a page in the Campaign namespace (i.e. having a "default
campaign")
The 2 latter options would be, from the administrative perspective,
similar to [[MediaWiki:Licenses]], where licenses are listed for
[[Special:Upload]].
I don't know why Upload Wizard decided to store these options in its own
extension repository directory in the first place. Was it a lack of
consideration or time, laziness or intentionally? All I know is that
certain people never appear to get tired emphasizing that MediaWiki -
and Upload Wizard included - is not the right place for Wiki
configuration and when it appears to hurt their feelings when I claim
WMF wikis would be MediaWiki's "primary customer". Come, wake up and
whip your fancy ideology. WMF wikis were used as the base for most
software development in regard to MediaWiki -- and they are used for
alpha-testing. We currently can't neglect that, although, I wouldn't
mind if we try hard to change that.
------------
Why did Commons want to amend the licensing options at all?
Upload Wizard offers an option "free in the U.S. because published
before 1923" -- while a work is free in the U.S., it doesn't necessarily
have to be in "foreign countries", where we usually find a protection
duration of author's live time +70 years. And Wikimedia Commons has
decided to respect the copyright situation of a work in the U.S. and the
country of origin.
------------
-- Rillke
Wikimedia Commons administrator
------------
* Local|Common
Hi everyone,
We appreciate the ongoing conversations about Media Viewer, and wanted to give you a quick update on this project.
This week, we’ve been discussing practical ways to address community concerns on the English Wikipedia and Wikimedia Commons RfCs — and improve metrics used to establish the default configuration for this tool.
We would like to propose a new feature which we think can address many of the issues we’ve heard so far: the Viewing Options Panel (1) would let you quickly disable (or enable) Media Viewer. It would prominently display a ‘cog’ icon at the top right corner of the screen, as shown in the feature's mockup (2) and rough prototype (3).
Clicking on that icon would display a settings panel with two viewing options:
* 'View quickly’ — enable Media Viewer (or keep it enabled)
* 'View all the details’ — disable Media Viewer and show the file page instead
This would make it much easier for users to decide for themselves if they want Media Viewer enabled or not. It would also allow us to collect better user data on whether or not this tool is useful -- which can inform our discussions about default state for different user groups. To that end, we plan to track the number of enable and disable events by user group on the existing Opt-in/Opt-out Dashboard (4) (this dashboard now tracks clicks on the “Disable/Enable’ links at the bottom of Media Viewer, which would be replaced by the Viewing Options Panel).
What do you think of this new feature? Does it seem worth developing at this time? Any suggestions for improvement?
We would greatly appreciate your feedback about the Viewing Options Panel on this multimedia mailing list, or on the Media Viewer discussion page:
http://ur1.ca/hrxqg
We are also considering a controlled experiment on the English Wikipedia. We invite you to comment on that separate proposal on its research page. (5)
Thanks again for taking the time to share your thoughts and feedback on Media Viewer. Your comments are really helpful to us, and we look forward to working with you in coming days to improve this tool together.
To be continued,
Fabrice and the Multimedia Team
(1) Viewing Options Panel - Proposed Spec:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/787
(2) Viewing Options Panel - Mockup:
https://commons.wikimedia.org/wiki/File:Media_Viewer_-_Viewing_Options_Pane…
(3) Viewing Options Panel - Rough Prototype:
http://pauginer.github.io/prototypes/media-viewer/desk/disabling-settings/i…
(4) Opt-in/Opt-out Dashboard:
http://multimedia-metrics.wmflabs.org/dashboards/mmv#opt_in_and_opt_out-gra…
(5) Controlled Experiment Proposal:
https://meta.wikimedia.org/wiki/Research:Media_Viewer_preference_elicitation
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
