Multimedia July 2014

multimedia@lists.wikimedia.org

28 participants
24 discussions

Media Viewer Update: Quick access to enable/disable, opt-in/opt-out metrics
by Fabrice Florin 18 Jul '14

18 Jul '14

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

4 3

Upgrading TMH to latest upstream mwEmbed Player
by Michael Dale 15 Jul '14

15 Jul '14

Lately there has been some exciting activity on the player / video front; Brion has done a first pass at integrating ogv.js[1], multimedia team and volunteers have been submitting fixes and enhancements to the TMH extension[2], including long standing issues such as dynamically loading the lib to reduce page payload [3]. In this email we outline: why upgrade, how things have diverged, and architecture choices to be made. = Why Sync with Upstream? = Over the past two years a teams of developers have been hard at work on the kaltura player library. . Some of the relevant notes: * Modern skin, theming, templatized plugins components with inherited plugin types, clean separation of JSON config, CSS, html / templates, and Javascirpt plugins. * Native bridge; enables js-buisness & display logic with of native software video playback; i.e would enable wmf components ( captions and content license ) to be used with native playback software such as the oggKit experiments Brion has done [5] See Architecture overview [4] * Iframe isolation from parent CSS / JS, Robust embed API. Thumbnail embed API for example; captures user gesture for playing iframe video on mobile-web ( would not require two clicks ) * Bugs that show up within WMF such as some versions of android forcing content duration to 1 second, were addressed up-stream long ago. * Kaltura invests in testing a truly massive QA matrix of library features across dozens of platforms. * Keep up-to-date with new features and industry trends; MPEG-DASH, WebVTT etc. * Plugins for everything but "only loading what you need” we leverage the resource loader to load only whats needed based on json config. If WMF ever need analytics or wanted to run a preroll during fundraising or whatever, would be simple modification to JSON player config. = Things have diverged = The original synchronization architecture had both mwEmbed[6] and TMH share identical copies of "mwEmbed modules”. Within mwEmbed we packaged the mediaWiki resource loader so that it works as a stand alone library. This is used within the mwEmbed project to this day [7]. Through the course of development of “v2” dependencies emerged against an additional module ( KalturaSupport ) which hosts the component definitions.[12] Additional minor enhancements to the resource loader were added to map JSON player plguin definitions to resource loader module lists, so that iframe build out logic can include all required resources prior to player invocation. There are likely other hidden dependencies on iframe based buildout introduced, and the kWidget embed / player API [8] assumes that the player always lives in an iframe. Furthermore within player v2 has more decencies on normalized metadata and source definitions, i.e plugins templates reference properties like {mediaProxy.entry.description} or {mediaProxy.entryMeta.customKey} that gets substituted for the respective value. = Stuff we need to regardless of Architecture choices = 1) Remove MwEmbedSupport extension, since TMH is the only consumer, bootstrap logic should be moved there. 2) Synchronize shared resources / update libraries as paladox has started doing upstream [9] 3) Upgrade jQuery usage “promises" instead of custom code that pre-dated promises for doing similar things like triggerQueuedCallback [10] 4) other mediaWiki updates ( JSON language files [11], etc. ) = Architectural options going forward = We have to decide between some options: 1) update the modules, ( most similar to existing TMH architecture ) Add kalturaSupport module, support hard coded JSON player config, keep projects in-sync via shared module copies. Update the player libraries to deal with inline playback ( loses iframe isolation ) Update embed logic to work against stand alone sources or video tag embed. ( loses some embed api features ) Add mapping / bootstrap for player metadata and sources. 2) Use an ApiProxy within TimedMediaHander ( use WMF resource loader, but proxies the data services instead of an alternate embed API, i.e half way between 1 and 3 ) 3) Completely isolate the player separate server / service that consumes mediaWiki API ( most similar to how we integrate with other non-kaltura playable entity services ) Would mean player does not consume the same "resource loader" as other extensions The player would be a self contained service run on separate servers. Would mean kWidget.embed calls would be used to embed the player. Would be easy to keep in-sync with upstream since we essentially just have to maintain a "JSON xslt” = links = 1) http://lists.wikimedia.org/pipermail/multimedia/2014-July/000727.html 2) https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions… 3) https://gerrit.wikimedia.org/r/#/c/145583/ 4) http://knowledge.kaltura.com/kaltura-player-v2-toolkit-theme-skin-guide#Kal… 5) https://brionv.com/log/2014/07/05/ogvkit-native-ogg-vorbistheora-playing-on… 7) https://github.com/kaltura/mwEmbed/tree/master/includes/resourceloader 8) http://player.kaltura.com/docs/api 9) https://github.com/kaltura/mwEmbed/pulls/paladox2015 10) https://bugzilla.wikimedia.org/show_bug.cgi?id=65428 11) https://blog.wikimedia.org/2014/04/10/mediawiki-localization-file-format-ch… 12) https://github.com/kaltura/mwEmbed/tree/master/modules/KalturaSupport/compo…

2 1

Changes to how videos play on iPhones/iPads
by Brian Wolff 14 Jul '14

14 Jul '14

Hi all, With a lot of help from Brion (thanks :), I've now changed the way that videos are handled on Commons on iOS devices (when browsing from the desktop site). The change will go live on July 15th. Previously, you clicked play, not much happened. There was a small easily ignored pop-up linking you to a help page, and a play button which in theory linked to the src video file (but in practice was possibly unclickable due to having too low a z-index). Now, you are directed to install the vlc-for-iOS app. If you have the app already installed, the video will automatically open in the app upon pressing play. This change will only affect the desktop site, as TimedMediaHandler is totally not loaded at all on the mobile site (However, if you have the vlc app installed, you can download the video from the mobile site, and it should play). For reference, iOS users represent roughly 11% of our user base. Its unclear how many of those browse the desktop site vs mobile site, although I imagine most use mobile and are not affected by this change :( . Nonetheless, every bit helps. Cheers, Bawolff p.s. For reference, relavent links are https://bugzilla.wikimedia.org/show_bug.cgi?id=61095 and https://gerrit.wikimedia.org/r/#/c/144349/

4 7

MMV disablement on private wikis
by Mark Holmquist 12 Jul '14

12 Jul '14

https://gerrit.wikimedia.org/r/145612 This seemed like a reasonable (and fast) enough request for me, so I made a patch. Does anyone have any good reason that the feature which, frankly, is broken on private sites, should be enabled there? IIRC Chrome users cannot use the feature at all, Firefox users are hit or miss. Plus, most of those private wikis aren't *viewed* by anyone, they're just communities of editors who discuss issues in private. Thoughts? -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

4 4

Pre-rendering thumbnails on the back-end
by Fabrice Florin 11 Jul '14

11 Jul '14

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)

3 4

Multimedia team update, a bit tardy
by Mark Holmquist 11 Jul '14

11 Jul '14

Happy Thursday to y'all! Let's do the run-down. == Media Viewer == This project is winding to a merciful close - we're seeing the final few patches going out this week and next, and we're switching our work focus to UploadWizard and other smaller projects. There is an RFC [0] on English Wikipedia to remove the viewer by default, which has been closed. The WMF has decided not to disable the viewer by default, but refer to the talk page [1] for the latest. There are also RFCs on Commons [2] and dewiki [3]. == UploadWizard == We're starting work on planning and metrics for this part of our upload pipeline. We've started tracking our work on refactoring the software in Phabricator [4][5], and we have a bigger patch out [6] that's looking to make the codebase a little more in line with more modern code conventions in various extensions. We also have some work underway to replace outdated one-use libraries with more modern, widely re-usable software. == Core work == We have a few changes open to make thumbnailing a little faster and also easier to handle. The platform team is reviewing those changes and we should push them out in the next few weeks. == Other == If I've missed something you have questions on, feel free to bother the list! Have a nice week, all. [0] https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC [1] https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC [2] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewe… [3] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter [4] http://fab.wmflabs.org/T433 [5] http://fab.wmflabs.org/T438 -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

4 4

UploadWizard and GPLv3 libraries
by Gilles Dubuc 11 Jul '14

11 Jul '14

Hi Luis, We are currently studying open-source libraries to be used in a refactor of UploadWizard, and FineUploaded is currently being considered: http://fineuploader.com/ That library is licensed under GPLv3, while UploadWizard is GPLv2. UploadWizard doesn't specify "2 or later". Is that a problem? Does that mean we need to work on a license change for UploadWizard? If so, what would be the process?

5 7

Future of Cortado
by Faidon Liambotis 08 Jul '14

08 Jul '14

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

6 6

Support for Chemical table files [Cross-posted to Commons-l]
by Rainer Rillke 08 Jul '14

08 Jul '14

As of now, images of structural formulas have to be created using third party software and converting the output to SVG or PNG. With MolHandler[1] we aim for a solution capable accepting and rendering chemical markup files and providing a web-interface for easily creating, modifying and re-mixing formula files. This does not only make re-using existing structures easier and simplifies creation of structures, moreover it allows Wikis to adopt a unified style for rendering these structures, makes structures searchable (sub-structure search) allows pulling, pushing and verifying data from big databases like ChemSpider and PubChem. In the future we plan to enable support for spectra and more sophisticated file formats to have at least some minimum support for chemistry-related Wiki-works. I am currently looking for features you would find helpful and therefore created a test wiki[2] at which you can create user accounts. A non-exhaustive list of features is available for raking by drag&drop. Or just write here what you at least want, what you would like to see soon and what is less important to you. -- Rillke [1] https://www.mediawiki.org/wiki/Chemical_Markup_support_for_Wikimedia_Commons [2] http://mol.wmflabs.org/

1 0

Multimedia's EventLogging consumption
by Gilles Dubuc 08 Jul '14

08 Jul '14

Hello analytics, My last round of reducing our EL consumption was right after the launch of Media Viewer to all wikis. I see now that the per-schema graphite stats are back: http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1404769845… Is that a reasonable amount of EventLogging usage for MediaViewer? Or should we do another pass of reducing our usage?

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Multimedia July 2014