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
>
Dear Faidon,
I would like to follow up on our discussions about pre-rendering thumbnails on the back-end, so users can see images faster when they load them in Media Viewer.
How are you coming along with this project? My understanding is that ops procured the hardware needed for that task weeks ago, but needed more time to set up a server-side image pre-rendering service.
We’re still getting a lot of user feedback that images take too long to load, particularly from users with slow connections. We’ve implemented as many solutions as we could find to speed up image load on the front-end, but are now running out of options. So the back-end pre-rendering approach is our only hope for addressing these user concerns at this time.
What do you think is a reasonable ETA for this solution from your perspective? Is there anyone on your team we should be working with to help make this happen? I know you’ve talked to Gilles about this in the past, but wanted to follow up now, since he’s on vacation this week and you will soon become less available. :)
Look forward to working together to add this last missing piece to improve the viewing experience for our users — as well as address performance issues across our sites.
Cheers,
Fabrice
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi folks,
Brian Wolff (Cc'ed) requested a few days ago for Wikimedia to sign the
Cortado Java applet that we serve as a fallback to play video on
browsers that do not support Ogg video. That's RT #7695.
>From Brian's request: "Java has changed their default security settings
so that unsigned java applets (and even signed applets missing
permissions attribute) generally don't run. In order to make this
fallback work, we should sign the java applet."
A non-EV code-signing certificate costs something between $200-$500 per
year but before we go ahead and consider making this expense, I'd like
to open the discussion about Cortado's future.
I know Brion Vibber (also Cc'ed) has made a significant effort on
implelementing Ogg/Ogv decoding functionality in Javascript and Flash
with an end-goal of replacing Cortado, among others. We also had an
impromptu discussion with Brion and a few others in Zurich
(unfortunately with noone from multimedia, though), during which it was
widely agreed that Java applets provide a very poor user experience in
the modern web landscape.
What's the multimedia team's & community's opinion on that? Do you have
any plans regarding Cortado and/or ogv.js? Do you think we should invest
further into Cortado?
Thanks,
Faidon
Hi folks,
We're happy to announce that Media Viewer is now live on all wikis hosted by the Wikimedia Foundation!
Media Viewer is testing well on all remaining Wikipedias (e.g.: Chinese, Arabic, Hindu, Indonesian, etc.) and sister sites (e.g.: MetaWiki, Wikibooks, Wikiquotes, Wikiversity, Wiktionary).
The multimedia team worked hard in the last few weeks to develop a range of final features, in response to frequent community requests. We hope you will try them out and let us know what you think on the Media Viewer discussion page (1).
1. Features on All Wikis
These features are now available on all wikis as of today:
* View original file (#630)
* Scroll down to see more info (#697)
* Show Commons link to logged out users (#429)
* Easy opt-out for registered users (#703)
* Opt-out for anons (#704)
You can test these features on this Featured Pictures page. (2)
2. Features on MediaWiki.org only:
These features are now available on MediaWiki.org and will be deployed to all wikis in coming days:
* Make it easier to find image information (#706)
* Prominent links to different image sizes (#664)
* Add more tooltips to Media Viewer (#546)
* Disable MediaViewer for certain images (#511)
* Track 'View original file’ and ‘Commons link' clicks (#715, #726)
* Track Media Viewer Opt-outs (/#558, #675)
You can test these features on this demo page (3) — and learn more on the updated help page (4).
3. Features in development
Other tasks in development or analysis include:
* Show attribution credits in download tool (#598)
* Make 'Commons link' and 'Use this file' more discoverable (#732)
* Click on image in Media Viewer to help view original file (#712)
* Improve Media Viewer UI on tablets (zoom/scroll) (#716)
* Remember the last selection for ‘Use this file' (#660)
You can view more details about these features on our planning site. (5)
4. Feedback
We keep getting generally positive feedback worldwide, with these latest results: (6)
* A majority of global respondents find the tool useful (60% average across surveys)
* Cumulative approval by language: English 29%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 28%, Hungarian 62%, Catalan 71%
* Daily approval rates have increased on English Wikipedia from about 23% a day after launch to 39% two weeks after launch (and German approval has also increased from 23% to 56% in the same period).
* We anticipate further approval increases on these sites, as more new features get rolled out in coming days, based on community feedback.
We are also starting to track the opt-out rates to see how many people turn off Media Viewer in their preferences. As of June 16, about 875 users had disabled this feature on the English Wikipedia, two weeks after launch: this represents about 0.34% of all registered users who viewed images on the site since launch. We are sorry that this small minority of users don’t like the tool, but we are glad that so many other users are finding it useful.
Please let us know what you think of these new features on our main discussion page (1). Which do you like most? least? Are there other must-have features that need to be developed right away, before we move on to other projects?
Thanks to all the community and team members for all you’ve done to make Media Viewer possible. :)
Onward!
Fabrice — for the Multimedia Team
(1) Discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#New_featu…
(2) Featured Pictures:
https://en.wikipedia.org/wiki/Wikipedia:Featured_pictures
(3) Demo page:
https://www.mediawiki.org/wiki/Lightbox_demo
(4) Help page:
https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer
(5) Planning site:
http://ur1.ca/gtyrp
(6) Survey results:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Team,
We had an spike on EL yesterday nite that was caught by our alarms. The
spike can be seen here:
http://graphite.wikimedia.org/render/?width=588&height=311&_salt=1403681192…
As far as I can see it caused no service issues so there is no need to
notify users. I am cc-ing the Media team on this e-mail cause from a brief
inspection of events it looks like they started to log at a higher rate on
the 25th.
Thanks,
Nuria
---------- Forwarded message ----------
From: <icinga(a)neon.wikimedia.org>
Date: Wed, Jun 25, 2014 at 4:46 AM
Subject: ** PROBLEM alert - tungsten/Throughput of event logging events is
CRITICAL **
To: nuria(a)wikimedia.org
❤❤❤❤❤ Icinga ❤❤❤❤❤
Notification Type: PROBLEM
Service: Throughput of event logging events
Host: tungsten
Address: 10.64.0.18
State: CRITICAL
Date/Time: Wed Jun 25 02:46:22 UTC 2014
Additional Info:
CRITICAL: 7.14% of data exceeded the critical threshold [500.0]
Love, Icinga
Hi folks,
I just wanted to provide a brief (and belated) announcement regarding some
added help we've enlisted over the summer on the Multimedia team.
Brian Wolff has been doing little bits of contracting work over the course
of his school year (as well as a lot of volunteer development), and this
summer will be doing a lot more contracting work. He plans to spend his
time taking out various bugs in all multimedia components. He's been at it
for a few weeks now, and has already made a lot of headway.
Neil Kandalgaonkar will be working with us this summer on unit tests for
UploadWizard. Neil originally wrote and maintained UploadWizard as an
employee of Wikimedia Foundation between 2009 and 2012. We're delighted to
have him back for a little while to help bootstrap our work on improving
UploadWizard.
Welcome guys! \o/
Rob
Hello everyone,
This week, the multimedia team completed its planning for our next development cycle, which started on June 11 and ends on July 22, 2014.
Here are our plans for this 6-week cycle, which are informed by results of our last cycle.
1. Last Cycle Results
Here are our key accomplishments from the last cycle, which ended on June 10:
* released Media Viewer on most large wikis (25 million image views/day !)
* developed metrics system to track image views, key actions, image load and network performance
* collected 13k survey responses (~60% approval) and talk page feedback, processed comments to identify key issues
* developed final features and bug fixes based on community feedback (e.g. view original file, file page link, metadata visibility)
* solved critical bugs and technical debt for other multimedia tools (e.g. Image Scalers, GW Toolset, TimedMediaHandler)
* started Upload Wizard project: planning, bug fixes, code review, refactoring, metrics, user feedback, designs
* started Structured Data project: planning, discussions, research, code review
* defined annual plan for multimedia in 2014-15
We completed about 112 points in the last 6-week cycle (vs. 128 points in previous 6-week cycle, with 4 engineers instead of 3). That's about 19 points per week (or 15 points of planned development per week, excluding scope increase and meetings). Our estimated capacity for this new cycle is about 10.5 points/ week of planned development, as two of our engineers are taking vacations this cycle.
2. Next Cycle Goals
For this next 6-week cycle, we plan to wrap up the Media Viewer project and start work on our next two big projects for the coming year: Upload Wizard and Structured Data — while reserving about a third of our time to address critical bugs and technical debt for other multimedia tools.
This cycle, we propose to invest our time evenly between these main projects:
* Media Viewer - fix critical bugs, important feature tweaks (to address latest community feedback)
* Upload Wizard - planning and first steps (bug fixes, metrics, feedback, discussions, designs, code review, unit tests)
* Critical Bugs / Tech Debt - fix serious issues that need quick solutions (e.g. image scalers, GW toolset, timed media handler)
* Structured Data - planning with Wikidata and first steps (mockups, specifications, discussions, code review)
The Current Cycle wall now includes separate columns for Media Viewer (14-22 points), Structured Data (9 points), Tech Debt (18 points) and Upload Wizard (14-22 points). We don't expect to complete all these tasks in this cycle, as they exceed the anticipated team capacity for this period, but wanted to have the flexibility to choose between different options as circumstances dictate.
For an overview of the tasks we are planning on, read below or visit this updated cycle wall:
http://ur1.ca/h7w5s
3. Media Viewer
For our first two weekly sprints, our focus will be on these Media Viewer improvements, to address community concerns on English and German Wikipedias:
* View original file (#630)
* View different image sizes (#664)
* Scroll down to see more info (#697)
* Show Commons link to logged out users (#429)
* Instant Opt-out (#703)
* Opt-out for anons (#704)
* Add tooltips to Media Viewer (#546)
* Disable MediaViewer for certain images (#511)
The features above are expected to deploy on all wikis tomorrow. Many of them are live already on Media Viewer sites, and we are starting to hear positive responses on our talk pages, with survey approvals trending up for English and German users.
Other tasks in development or analysis include:
* Make it easier to find image information (#706)
* Show attribution credits in download tool (#598)
* Make 'Commons link' and 'Use this file' more discoverable (#732)
* Improve Media Viewer UI on tablets (zoom/scroll) (#716)
* Remember the last selection for ‘Use this file' (#660)
* Track Media Viewer Opt-outs (/#558, #675)
* Track 'View original file’ and ‘Commons link' clicks (#715, #726)
To learn more, click on the relevant cards in our current sprint wall:
http://ur1.ca/gtyrp
4. Upload Wizard
We have started planning and development on Upload Wizard, which will be our main user-facing project in the coming year. For now, we are focusing on metrics, feedback, bug fixes, unit tests, code refactoring and a few small user interface improvements.
Here are some of the tasks we plan to take on this cycle:
* Metrics & Funnel Analysis (#305, #541, #603, #587)
* Analyze user feedback for Upload Wizard (#624)
* Code Refactoring Plan (#344)
* UI Improvement Plan (#342)
* First Unit Tests (#70)
* Show progress bar during upload (#651)
* Upload Wizard FAQ links (#625)
To learn more, check out this updated project page:
https://www.mediawiki.org/wiki/UploadWizard
5. Structured Data
We are starting to work with the Wikidata team to plan this project, which aims to provide machine-readable data for media files on Wikimedia Commons.
Our main activities this cycle include:
* Planning meetings with Wikidata
* Mockups and schemas for a new metadata structure
* Community discussions to understand user needs and workflows
* Definitions for a high-level class for image metadata
To learn more, check out this new project page:
https://www.mediawiki.org/wiki/Multimedia/Structured_Data
6. Critical Bugs / Tech Debt
We will continue to allocate about a third of our time to address urgent bugs and technical debt to gradually improve our multimedia infrastructure.
Here are some tasks we are considering for this cycle:
* Create poolcounter group for expensive thumbnails (#623)
* Pre-render thumbnails in all sizes on the back-end (#301)
* Fix TimedMediaHandler resource loading (#543)
* Push messages to logstash from JS (#127)
* Create vagrant role for Commons (#632)
* TimedMediaHandler Improvements (e.g. #729)
* GW Toolset Improvements
To learn more, click on the relevant cards in our Technical Debt wall:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards?favorit…
For a roadmap of our goals for these projects in future cycles, visit this planning page for 2014-2015:
https://www.mediawiki.org/wiki/Multimedia/2014-15_Goals
Please let us know what you think of this plan — and if you have any questions or comments. You are invited to post your feedback on this mailing list, or on the discussion for this cycle plan page:
https://www.mediawiki.org/wiki/Multimedia/Meetings/Next_Cycle_3_Q4_2013-14
We look forward to discussing these topics with some of you in coming weeks.
Onward!
Fabrice - for the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi all,
For the past week or so, the Multimedia team has been trying to plan a
meeting about UploadWizard refactoring. It turns out we're all super busy,
and anyway, a bunch of the community members probably have a bunch to say
about what needs fixin' in the UW code base. So, without further ado, here
are a few of the things I think we at least need to make sure we're touching
on as we work on other issues, but ideally that we would work on in a
sustained manner on some level:
* Refactor base functionality for transports and handlers into base classes
because that's what object-oriented programming is for
* Fix code conventions, because ugh
* Fix jQuery use - it's currently pretty messy, and there are patches out
to fix most things, but this could maybe be solved by a switch to OOUI
(which is a separate email, and not from me)
* Make uploads the primary object, instead of an upload batch. This would
mean decoupling the state of the upload list as a whole from the application
progression logic, and it would allow us to do cool stuff like going
backwards, filling in descriptions and licenses while uploads are still
going, and many other cool things.
* Fix error handling. What all this means, I'm not sure, but there's a
lot that can go wrong in the upload pipeline, and for the most part,
we just straight up don't handle it. This is pretty frustrating to see,
when users submit bugs like "api-stasherror-unknown"...
* Unit testing. This is hard, but once we start in on refactoring the
classes to be more based on each other, it will get way easier. This
can get started pretty soon on some of the more utility-oriented classes
like the license inputs and the category inputs. Stuff like the main
UploadWizardUpload class may have to wait until we tear out bits of it.
* Split things into different modules, maybe lazy load them. Meaning we
don't need to load the description/details script files for the people
who don't make it to that step for whatever reason. Not a huge improvement,
but a mite better (IMO) than loading everything. Also opens us up to
support other tools with our license chooser, our file description UI,
and so on. (see e.g. the work already done on the PronunciationRecording
extension)
This is obviously just a start, but I'd love to hear other things that
need doing, and discussion on priorities. We'll come back to this list
when we start to track and prioritize refactoring targets.
Cheers,
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
Is it by any chance possible to run cucumber tests under Safari on
Cloudbees? If not, are there alternative solution to running the Cucumber
tests on Safari automatically?