Hi all,
I wanted to share the results of our latest round of usability testing with
the current version of the Media Viewer. As a really quick summary we can
say that the basic design concept and the way we present information and
controls seem to work, while some aspects such as the connection with
Commons info page and license details need more clarity.
To get more details check the notes at
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Usability_testing
The idea is to keep testing periodically as new features are added to the
Media Viewer and new prototypes are built for future features.
Feel free to circulate the participation form
link<https://docs.google.com/a/wikimedia.org/spreadsheet/viewform?usp=drive_web&…>
to
those users that may be interested in testing new multimedia features.
thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
It seems like the CURLOPT_MAX_RECV_SPEED_LARGE option [1] can do the job. I
guess now the questions is: what limit should we set?
During the image scaler outage Faidon mentioned that the swift bandwidth
was maxing out. Do you remember what the cap was?
[1] http://www.php.net/manual/en/function.curl-setopt.php
FYI.
----- Forwarded message from Steinsplitter Wiki <steinsplitter-wiki(a)live.com> -----
> Date: Wed, 14 May 2014 21:01:38 +0200
> From: Steinsplitter Wiki <steinsplitter-wiki(a)live.com>
> To: "wikitech-l(a)lists.wikimedia.org" <wikitech-l(a)lists.wikimedia.org>
> Subject: [Wikitech-l] Too much open bugs (Wikimedia Commons, Media storage)
> Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
> Hi,
> I wanted to bring to your attention a few critical issues that are negatively affecting the workof the Commons community and the wider Wikimedia projects.
> First, there are about 36 unresolved bugs [0] in the "Media storage" component. Swift is a vitalcomponent of the projects' ability to show images and other media, and it having so manyopen bugs causes serious ongoing issues, not only on Commons, but everywhere.
> Some of these bugs are high priority, and have been open since 2012. The community of adminsare straining under the load, and it's not getting any better now that additional paths into theupload pipeline are becoming available.
> UploadWizard, too, is fundamentally broken. There are a *lot* of open bugs [1] [2] and the interfaceis in need of design love.
> It would be awesome to see these issues addressed in the coming months. In particular, becauseWiki Loves Monuments will start in September, it would be great to have these issues fixedon or before August 13th, giving Commons about two weeks to test the fixes and changesbefore the contest starts, and plenty of room for backporting urgent fixes.
> Regards,Steinsplitter
> https://commons.wikimedia.org/wiki/User:Steinsplitter
>
> [0] https://bugzilla.wikimedia.org/buglist.cgi?component=Media%20storage&produc…https://commons.wikimedia.org/wiki/Special:PrefixIndex/Commons:Upload_help/…https://bugzilla.wikimedia.org/buglist.cgi?component=UploadWizard&product=M…
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi guys,
Any word from analytics as to when the Media Viewer metrics dashboards will be updated? Is the EventsLogging migration almost done? Now is the time when we need this data. :)
http://multimedia-metrics.wmflabs.org/dashboards/mmv
Also, do we have enough data now to define acceptance performance criteria for Media Viewer and complete card #149?
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/149
Other research questions which we would like to answer based on pilot results include:
* how fast do images load?
I think we now have enough data to make a statement, both on a global and local basis, with breakdowns for warm and cold caches, as well as large images. Want to take a first stab at it, or want me to?
* does performance improve with more users?
It would be great if we could confirm our hypothesis that images load faster when more users are clicking on them.
* any slowdowns during peak hours?
Do we have any data that would show what happens during peak hours? Would this require us to create hourly dashboards in a few pilot sites?
* is the overall performance acceptable?
This question can be answered once we define acceptable performance criteria. It could also be confirmed to some extent by survey responses, particularly if we see a decrease in complaints about the speed.
To that end, I will do another sweep at latest survey results and compile more results tomorrow on this page:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey
Look forward to discussing these questions together in coming days, based on the data now on hand.
Thanks,
Fabrice
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
The number of Apache busy workers on the image scalers spiked between 2:55
and 3:15 UTC, peaking at about 3:12 and overwhelming
rendering.svc.eqiad.wmnet for about a minute.
The outage correlates fairly well with a spike of fatals in
TimedMediaHandler, consisting almost entirely of requests to this URL: <
http://commons.wikimedia.org/w/thumb_handler.php/2/2c/Closed_Friedmann_univ…
>.
The full stack trace is included in <
https://bugzilla.wikimedia.org/show_bug.cgi?id=64152>, filed by Reedy
yesterday. It appears File::getMimeType is returning 'unknown/unknown' and
that File::getHandler is consequently not able to find a handler.
Hi folks,
Here’s another update on our global release of Media Viewer (1), which is rolling out as smooth as silk. :)
1. This week’s releases
Today, we just enabled Media Viewer by default on the Kannada and Telugu Wikipedias, where we plan to study image load performance in areas with slow connections. This Thursday, May 15, we plan to deploy on Wikimedia Commons, devoting an entire release to this important site, so we can keep a close eye on this more complex deployment.
2. Next week’s release
The following Thursday, May 22, we plan to release on the English, German, Italian and Russian Wikipedias, as well as WikiSources in all languages. If all goes well with these releases, we then plan to deploy the tool on all wikis the following week, May 29, as described in our release plan. (2)
3. Survey results
Survey responses from over 1,700 users are generally favorable, across 8 languages:
* 65% of all respondents find the tool useful, 28% do not find it useful, 7% are not sure
* approval rates keep growing (French approval grew from 64% to 70%, Hungarian surged from 42% to 59%)
* last week's releases show the most positive response (82% of Portuguese users like the tool, vs. 79% of Spanish)
Learn more in our survey report (3) and detailed results (4). We’ll update these results next week, and are looking for a volunteer to help with that work.
4. Metrics
We are now tracking about 4.3 million image views globally, across 22 sites, as shown in our new global view dashboard (5).
* Most image views come from Spanish (28%), French (23%), Polish (11%), Japanese (9%), Portuguese (8%) and Dutch (4%) Wikipedias.
* The most frequent actions are thumbnail clicks (60% of views), close button (53%), next image (31%), history (21%) and previous image (13%)
* Images continue to open faster in Media Viewer (1.5 seconds) than in the previous method of opening a separate file page (2.6 seconds)
* The longest image loads are about 2.8 seconds for 90% of our users, 4.8 seconds for the 95th percentile and 14.3 seconds for the 99th percentile
Learn more in our global metrics dashboards (6) and local dashboards (7) (be sure to click on all the tabs).
5. Next steps
Thanks to survey results and onwiki discussions, we identified a short list of issues that are important to our community, and have added them to our current development cycle boards (8). They include: zoom link, easier ways to find info, larger commons icon, disabling some images, support for multiple licenses, more tooltips and pre-rendering images on the backend. We plan to gradually address the most pressing issues in coming weeks, while resuming our work on technical debt and the upload wizard upgrade. We’ll keep you posted on next week’s sprint goals after tomorrow's team meeting.
Thanks as always to all the community and team members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This was a really productive partnership, which we hope to build on for future projects.
Onward!
Fabrice
(1) About Media Viewer: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
(2) Large Wiki Releases: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
(3) Survey Report: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
(4) Detailed Survey Results: http://ur1.ca/ha662
(5) Global Image View Dashboard: http://multimedia-metrics.wmflabs.org/graphs/mmv_image_views_global
(6) Global Actions / Performance Dashboards: http://multimedia-metrics.wmflabs.org/dashboards/mmv
(7) Local Metrics Dashboards: https://www.mediawiki.org/wiki/Multimedia/Metrics#Client-side
(8) Current Cycle Board: http://ur1.ca/h7w5s
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Passing this one along:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49118
Full bug is good content, but in the last comment (as of now) Aaron is
proposing the MM team take a look at media handler tweaks to address the
problem (in addition to his first pass fix).
Thanks!
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi folks,
I am delighted to share the latest survey results for Media Viewer.
This invaluable user feedback is helping us evaluate what our users think of this tool and address issues that are important to our community.
As of May 5, we had collected 1,727 responses in eight different languages: Catalan, Dutch, English, French, Hungarian, Spanish and Portuguese. Most of the responses came from these three large pilots: Dutch, French and Hungarian.
Here are our key findings:
• 65% of survey respondents find Media Viewer useful, across all languages. About 28% do not find it useful, and 7% are not sure.
• 73% of readers find the tool useful -- more so than editors (66%) or active editors (49%).
• The majority of survey respondents are readers (56%), but editors (30%) and active editors (14%) are well represented.
• Approval rates have been increasing over time (e.g.: Hungarian approval started around 42%, and is now up to 57%).
• More users found Media Viewer useful on sites in English (72%) or French (71%) than on sites in Dutch (53%) or Hungarian (57%).
• Here are the most frequent requests from 1,140 comments:
• Want zoom (21%)
• Too slow (20%)
• More image sizes (8%)
• Want full screen or larger images (5%)
• Can't find info (5%)
We’re learning a lot from this feedback and already developing solutions to address these issues.
For a full report with graphs and our next steps, visit this results page:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
For more detailed survey data, check out this spreadsheet:
http://ur1.ca/ha662
We hope you too will find this feedback helpful. Surveys like these are invaluable for hearing what users think of our tools, as well as for prioritizing which issues to address first.
We plan to post more survey updates next week, with a focus on the Spanish and Portuguese releases — and again at the end of May, after the English and German releases.
Regards as ever,
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
