Hi folks,
Here are our notes from yesterday’s multimedia team meeting, when we planned our next development cycles.
We discussed our goals for the next 6-week cycle, as well as for subsequent cycles. We agreed to focus on wrapping up feature development and gradually releasing Media Viewer v0.2 in April/May, so we can move on to other important tasks on our roadmap.
To stay focused on this goal, we decided to devote the next 6-week cycle to completing final features for the first pilot release of Media Viewer v0.2 in the next cycle.
We will then switch our focus to Upload Wizard and Structured Data in the subsequent cycle, only fixing Media Viewer bugs as needed. We expect this new work to continue to be our main focus through the summer.
To make rapid progress on these important multimedia priorities, we may need to push back the next version of Media Viewer 0.3 to later in the year — or only do incremental work on it in the next quarters.
Our current goals for the next few cycles are outlined below — and you can read more on our meeting notepad:
http://etherpad.wikimedia.org/p/multimedia-planning-meeting-2014-03-12
We welcome your comments, questions and suggestions about these proposed goals. We expect to adjust them periodically, based on this feedback and other factors.
Please respond by email for now. You can also post comments about Media Viewer on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks as always for your constructive feedback, which is invaluable to us!
Best regards,
Fabrice
on behalf of the Multimedia team
____________________________________________
MULTIMEDIA TEAM GOALS - NEXT CYCLES
Here are our proposed goals for the multimedia team’s next development cycles. (We define a cycle as a 6-week iteration, which includes 6 weekly sprints; it can also include one or more product releases).
We will be discussing these goals with community and team members in coming days. We expect to adjust them periodically, based on this feedback and other factors.
1. Goals for Current Cycle
* Current Cycle started February 6, ends March 19 (second half of fiscal Q3).
* Media Viewer v0.2 - Develop key features for pilot release in April
* Analyze image load metrics, define acceptance criteria
* Bugs & Technical Debt - Ongoing
* See Mingle wall of tasks completed this cycle: http://ur1.ca/gtyvh
2. Goals for Next Cycle
* Starts March 20, ends April 30 (first half of fiscal Q4).
* Media Viewer v0.2 - Complete key features and launch tasks for April release
* Release Media Viewer v0.2 in April/May (MW.org > small wikis > large wikis > all wikis)
* Fix Media Viewer v0.2 Bugs (address most urgent community concerns)
* Upload Wizard - Fix large bugs, collect metrics, unit tests, plan next steps
* Bugs & Technical Debt - Ongoing
* See Mingle wall: http://ur1.ca/gtvvr
3. Goals for Subsequent Cycle
* Starts May 1, ends June 11 (second half of fiscal Q4)
* Upload Wizard - improve UI design, incremental code refactoring, new features
* Fix Media Viewer v0.2 Bugs (focus on most important community concerns)
* Structured Data - start planning and first prototypes, with Wikidata and community
* File Notifications - Your file was used
* See Mingle wall: http://ur1.ca/gtyt3
4. Goals for 'Next-Subsequent' Cycle
* Starts June 12, ends July 23 (first half of fiscal Q1)
* Upload Wizard continued improvements and bug fixes, as needed
* Structured Data - start implementation on Commons, with Wikidata and community
* Fix Media Viewer v0.2 Bugs (focus on most important issues)
As time allows, we will consider incremental work on these goals throughout next year:
* Media Viewer v0.3 - Develop new features (zoom, A/V support, plugins)
* File Feedback - Develop positive feedback tool (Thanks, Watch or Favorite)
Useful links
* Multimedia Project Hub
https://www.mediawiki.org/wiki/Multimedia
* About Media Viewer
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
* Media Viewer Release Plan
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hello everyone,
Thanks for your good comments over the weekend about the Opt-out feature for Media Viewer!
Based on your feedback, we now plan to provide an ‘enabled' user preference (option A), as described on our discussion page. (1)
Today, we would like your guidance on another Media Viewer feature: the link to Commons (or other file repository). (2)
Many people have raised concerns on our discussion pages that the current link is not prominent enough to help power users go to Commons — or to make new users aware of what Commons is. Right now, that link to the Commons file info page is located below the fold, at the top of the right column in the meta-data panel (3); the current label is “Learn more on Wikimedia Commons."
As recommended by many in our onwiki, email and IRC discussions, we have been exploring different ways to make this link to Commons more prominent, as outlined in this Mingle card #270 (4).
This link is trying to solve the needs of two very different user groups:
• Advanced users need a quick link to edit the Commons description page and perform other related editorial tasks for that image.
• New users want to know more about the image, and also need information on what Commons is and why they should go there.
To address these issues for each user group, we are considering different design solutions, prepared by our designer Pau Giner:
A. Simple 'Edit’ button: (5)
Provide an ‘Edit’ tool above the fold, so that advanced users can quickly go to the Commons description page to edit it. Restrict this to logged-in users only?
• Pros: gives editors a much-needed edit tool, in a compact format that is easy to understand (pencil icon), making it easier for them to do their work
• Cons: readers could get confused by this tool, which takes them to a completely different site (so we may want to not show it to them at all).
B. 'Edit’ button with tooltip: (6)
Provide the same ‘Edit’ tool above the fold, but show a tooltip on hover, to explain to new users what it does. Show the edit tool to everybody.
• Pros: gives editors the same useful, compact tool, to help them do their editing work quickly
• Cons: readers should like the tooltip, but it may annoy some editors (don’t show the tooltip to advanced users?)
C. 'More details on Commons’: (7)
Provide a call to action inviting new users to check more details on Commons, explaining what it is and how to get there. Shown below the fold, after key details.
• Pros: Clarifies what Commons is and why users might want to go there: to get more details and share free media. Larger panel makes it easier to find.
• Cons: Below the fold position means many users will not see it. Consider using it in combination with Options A or B above?
We would appreciate your advice on which of the options above would be most helpful for both new users and power users. Note that we may want to use some of these design ideas in combination (e.g.: Option B + C), to offer different solutions to meet the specific needs of each user group.
Please respond via email on this list — or add your comments on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Feedback_…
Later this week, we will ask your advice about adding a button on Commons to open an image in Media Viewer.
Thanks as always for your constructive advice — and speak with you soon!
Fabrice
(1) Discussion of Opt-out Feature for Media Viewer:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Feedback_…
(2) Discussion about Links to Commons:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Feedback_…
(3) Media Viewer Meta-data panel:
https://upload.wikimedia.org/wikipedia/commons/4/4b/Media_Viewer_Screenshot…
(4) Prominent Links to Commons File Pages in Media Viewer - Mingle card #270:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/270
(5) Mockup A: Edit Button - Helps power users quickly edit Commons page
https://commons.wikimedia.org/wiki/File:Media_viewer_access_to_Commons_thro…
(6) Mockup B: Edit Button w/ tooltip - Same tool, but gives new users a tooltip to explain what it does
https://commons.wikimedia.org/wiki/File:Media_viewer_access_to_Commons_thro…
(7) Mockup C: ‘Details on Commons’ - Call to action helps new users get more details on Commons, and explains what it is
https://commons.wikimedia.org/wiki/File:Design_for_more_details_access_to_C…
P.S.: Let's also look for ways to remind power users that they can use keyboard shortcuts to bypass Media Viewer and access images files directly on Commons (e.g.: Ctrl-click or Shift-click).
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi guys,
We would appreciate your advice on the Opt-out Feature for Media Viewer.
Our goal is to enable Media Viewer by default on all wikis when it the tool is ready.
But as recommended by many in our onwiki and IRC discussions, we would also like to provide a way for users to disable Media Viewer on a given site, so they can opt-out from this feature if I don't want it.
To that end, we are considering these different options:
A. 'Enabled' user preference
Provide a preference checkbox with Media Viewer enabled by default (e.g.: 'Show images in Media Viewer'). To disable MV, users can uncheck this preference.
• Pros: preferable from a UX point of view, indicates this is our recommended option, more user-friendy than JS gadget option below
• Cons: this approach has caused problems before, users may not want this option to be selected for them, adds to preference bloat issue
B. 'Disable' user preference
Provide a preference checkbox where Media Viewer can be disabled (e.g.: 'Disable Media Viewer'). To re-enable MV, users can uncheck that preference.
• Pros: addresses user concerns about pre-selection, more user-friendy than JS gadget option below
• Cons: unclear what Media Viewer is, confusing because you have to uncheck the preference to re-enable Media Viewer, adds to preference bloat issue
C. Javascript gadget or script
Provide a site-wide gadget (or personal JS script) that would let users disable Media Viewer.
• Pros: no preference bloat, no cache fragmentation, can simply ride on #263 and provide example JS code.
• Cons: not user-friendly (the gadget has to be installed manually), the bootstrap script would still get loaded.
Notes
• If we implement a user preference, the recommended location would be in the 'Appearances' section, under 'Files'.
• We should also let power users know that they can easily use Ctrl-click or Shift-click to bypass Media Viewer and access images the same way they used to before this feature was introduced. So even with Media Viewer enabled, there are shortcuts you can use to go directly to Commons if you like.
We would appreciate your advice on which of the options above would be most helpful for the majority of our users (not just power users).
Please respond via email on this list — or add your comments on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Feedback_…
Next week, we will ask your advice about other high-priority features for Media Viewer.
Thank you — and have a wonderful weekend!
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi guys,
We presented our new Media Viewer tool today at Wikimedia’s monthly metrics meeting, to show off the latest version and discuss next steps.
Here’s a video of our demo, now on YouTube:
http://ur1.ca/gry4u
Here are the slides:
http://ur1.ca/gry2u
Better yet, we invite you to try out the latest version here on Commons:
http://ur1.ca/gry57
This demo page now features 2013 pictures of the year, and these wonderful images really come alive in the Media Viewer.
It looks like our new multimedia browser is coming together pretty nicely, thanks to all your good feedback :)
Let us know what you think of the latest version on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Enjoy …
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
On Sun, Feb 23, 2014 at 6:43 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> Just an update on this weekend project, see the current demo in your
> browser[1] or watch a video of Theora video playing on an iPhone 5s![2]
>
> [1] https://brionv.com/misc/ogv.js/demo/
> [2] http://www.youtube.com/watch?v=U_qSfHPhGcA
>
> * Got some fixes and testing from one of the old Cortado maintainers --
> thanks Maik!
> * Audio/video sync is still flaky, but everything pretty much decodes and
> plays properly now.
> * IE 10/11 work, using a Flash shim for audio.
> * OS X Safari 6.1+ works, including native audio.
> * iOS 7 Safari works, including native audio.
>
Spent some time tonight on audio/video sync; it's now working both with
native Web Audio API and with the Flash audio shim.
Check out a video with someone talking, and marvel at the synchronization!
https://brionv.com/misc/ogv.js/demo/#file=Sneak_Preview_-_Wikipedia_VisualE…
(Hi Trevor!)
I also snuck in a size selection override, so you can pick the larger 480p
or original files (note that webm originals don't play as only a Theora
decoder is included so far), or down to the tiny 160p, to see the quality
and CPU usage differences.
If there's no objection to use of a Flash shim, I'll keep doing some
experiments in that direction and see if I can rig up a fully-Flash version
that works in old versions of Internet Explorer as well. (The main ogv.js
needs no Flash as long as needed APIs are available, and even runs on iOS
though it's a bit slow for videos.)
-- brion
>
> Audio-only files run great on iOS 7 devices. The 160p video transcodes we
> experimentally enabled recently run *great* on a shiny 64-bit iPhone 5s,
> but are still slightly too slow on older models.
>
>
> The Flash audio shim for IE is a very simple ActionScript3 program which
> accepts audio samples from the host page and outputs them -- no proprietary
> or patented codecs are in use. It builds to a .swf with the open-source
> Apache Flex SDK, so no proprietary software is needed to create or update
> it.
>
> I'm also doing some preliminary research on a fully Flash version, using
> the Crossbridge compiler[3] for the C codec libraries. Assuming it performs
> about as well as the JS does on modern browsers, this should give us a
> fallback for old versions of IE to supplement or replace the Cortado Java
> player... Before I go too far down that rabbit hole though I'd like to get
> peoples' opinions on using Flash fallbacks to serve browsers with open
> formats.
>
> As long as the scripts are open source and we're building them with an
> open source toolchain, and the entire purpose is to be a shim for missing
> browser feature support, does anyone have an objection?
>
> [3] https://github.com/adobe-flash/crossbridge
>
> -- brion
>
>
> On Mon, Oct 7, 2013 at 9:01 AM, Brion Vibber <bvibber(a)wikimedia.org>wrote:
>
>> TL;DR SUMMARY: check out this short, silent, black & white video:
>> https://brionv.com/misc/ogv.js/demo/ -- anybody interested in a side
>> project on in-browser audio/video decoding fallback?
>>
>>
>> One of my pet peeves is that we don't have audio/video playback on many
>> systems, including default Windows and Mac desktops and non-Android mobile
>> devices, which don't ship with Theora or WebM video decoding.
>>
>> The technically simplest way to handle this is to transcode videos into
>> H.264 (.mp4 files) which is well supported by the troublesome browsers.
>> Unfortunately there are concerns about the patent licensing, which has held
>> us up from deploying any H.264 output options though all the software is
>> ready to go...
>>
>> While I still hope we'll get that resolved eventually, there is an
>> alternative -- client-side software decoding.
>>
>>
>> We have used the 'Cortado <http://www.theora.org/cortado/>' Java applet
>> to do fallback software decoding in the browser for a few years, but Java
>> applets are aggressively being deprecated on today's web:
>>
>> * no Java applets at all on major mobile browsers
>> * Java usually requires a manual install on desktop
>> * Java applets disabled by default for security on major desktop browsers
>>
>> Luckily, JavaScript engines have gotten *really fast* in the last few
>> years, and performance is getting well in line with what Java applets can
>> do.
>>
>>
>> As an experiment, I've built Xiph's ogg, vorbis, and theora C libraries
>> cross-compiled to JavaScript using emscripten<https://github.com/kripken/emscripten>and written a wrapper that decodes Theora video from an .ogv stream and
>> draws the frames into a <canvas> element:
>>
>> * demo: https://brionv.com/misc/ogv.js/demo/
>> * code: https://github.com/brion/ogv.js
>> * blog & some details:
>> https://brionv.com/log/2013/10/06/ogv-js-proof-of-concept/
>>
>> It's just a proof of concept -- the colorspace conversion is incomplete
>> so it's grayscale, there's no audio or proper framerate sync, and it
>> doesn't really stream data properly. But I'm pleased it works so far!
>> (Currently it breaks in IE, but I think I can fix that at least for 10/11,
>> possibly for 9. Probably not for 6/7/8.)
>>
>> Performance on iOS devices isn't great, but is better with lower
>> resolution files :) On desktop it's screaming fast for moderate
>> resolutions, and could probably supplement or replace Cortado with further
>> development.
>>
>> Is anyone interested in helping out or picking up the project to move it
>> towards proper playback? If not, it'll be one of my weekend "fun" projects
>> I occasionally tinker with off the clock. :)
>>
>> -- brion
>>
>
>
Oops, that didn't go to the multimedia list.
Juliusz Gonera wrote:
> Gergo Tisza wrote:
>
>> * jquery.color - what for? can we use CSS transitions?
>> * jquery.colorUtil - what for? can we use CSS transitions?
>>
>>
>> Dependencies for doing color transitions with jQuery.animate().
>> Probably can be replaced with CSS; I'll look into that when I have
>> some free time. At any rate, .animate() still runs without those
>> files (just doesn't produce any visible effect) so they can be omitted.
>
> Thanks! In the worst case we could make them a soft dependency, but
> CSS-based transitions would be the best way to go for mobile.
>
>> * moment
>>
>>
>> Used for date localization. Moment is heavy (25K minified) but the
>> browser's built in date formatting is very unreliable.
>> Might be possible doing this on the server side, although it would be
>> ugly from an API design point of view.
>
> Where is it used? The only place I could spot it was "Created on
> [date]." I'm not sure if it pays off to serve 25KB more to a mobile
> user to format one date. Could this, theoretically, be made a soft
> dependency too?
>
>> Probably more preloading? We do a lot of that. You can set
>> mw.mmv.mediaViewer.preloadDistance = 0 to disable. (This only works
>> once you have opened some image already as mw.mmv.mediaViewer is
>> created when the main JS lib is loaded; we don't have a lazy-loading
>> compatible way to configure the viewer yet. Created #275
>> <https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/275> about
>> that.)
>>
>> Also, we request every image twice to get certain performance
>> metrics; this should not result in the image actually being
>> downloaded twice (although we did not test that in mobile browsers),
>> but might confuse the network stats in Chrome. Probably also
>> something that we should make configurable :-)
>
> Yep, that's the major cause of increased size. On my vagrant instance,
> for some reason, those second requests return HTTP 200 and it seems
> that they are fetched from the server again.
>
> Another thing is that I counted 6 API requests. 3 of them are for
> imageinfo, 3 for other APIs. They are small, but as we know each
> request has an HTTP overhead. It would be great to combine them.
>
>> The big win in terms of size would be to make the UI modular and
>> configurable, so you can request a MultimediaViewer instance which
>> does not have most of the information on the metadata panel, for
>> example, and the related files would not be loaded. We have some
>> vague plans about that, but nothing specific yet.
>
> Yes, that's definitely something we should look into when we start
> working on MMV on mobile.
>
> --
> Juliusz
Hi,
As a part of a mobile spike [1], I evaluated the possibility of using
MMV on mobile instead of the custom viewer we have right now in beta.
The good news is that it works. The bad news is that it's quite heavy
compared to what we have right now. We don't know yet when we'd like to
see MMV on mobile, but this moment will eventually come.
Let's start with the additional dependencies I needed to add to mobile
to make it run:
* jquery.fullscreen - not needed on mobile
* jquery.throttle-debounce - make sure that events fire only once, needed?
* jquery.ui.dialog and dependencies - file reuse dialog, can/will be
replaced? (on Multimedia roadmap)
'jquery.ui.core',
'jquery.ui.widget',
'jquery.ui.button',
'jquery.ui.draggable',
'jquery.ui.mouse',
'jquery.ui.position',
'jquery.ui.resizable',
* jquery.color - what for? can we use CSS transitions?
* jquery.colorUtil - what for? can we use CSS transitions?
* moment
Fortunately, Mark told me that removing jquery.ui.dialog is already
planned. I created a simple page with a thumbnail and checked what
Chrome reports in Network tab for no multimedia viewer, the viewer we
currently have on mobile (in beta) and MMV:
* no viewer: 379KB
* mobile viewer:
** 384KB at page load (all JS + LESS + HTML template)
** 390KB when lightbox shows (images used in LESS + API request)
** 561KB when image is loaded (custom size, in this case 171KB for 746px)
** +6KB, +11KB, +182KB
* mmv:
** 395KB at page load (only bootstrap JS loaded)
** 722KB when lightbox shows (the rest of JS and other assets)
** 2.7MB when image is loaded (129KB for 640px and 901KB for 1920px)
** +14KB, +343KB, +2.3MB
** mmv (without jquery.ui.dialog)
** 395KB at page load
** 573KB when lightbox shows
** 2.6MB when image is loaded
** +14KB, +194KB, +2.2MB
Remaining questions/problems:
* There's no indication of overlay loading (on Multimedia roadmap).
* Can we do animations using CSS transitions?
* Why do we load both 640px and 1920px version of images?
* What is loaded at the end apart from images (+2.3MB, images are ~1MB)?
Related patches:
https://gerrit.wikimedia.org/r/#/c/116155/https://gerrit.wikimedia.org/r/#/c/116154/https://gerrit.wikimedia.org/r/#/c/116156/
[1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1688
--
Juliusz
Good morning from San Francisco, Multimedians!
The Multimedia team just finished their weekly planning meeting, and we
decided it would be a fantastic first step to write a quick email each
week describing what sorts of things we're working on and what you can
expect out of us in the coming weeks and months.
== Release-level ==
On the release level, we've made a few plans in our most recent meeting.
We intend to push back our planned release of MultimediaViewer [0] a few
weeks, pending a better view of how well we're doing with estimating our
velocity and keeping it up. If we do really well, we may release it to
MediaWiki.org as the default for logged-in users as soon as March 13th.
Other releases will follow in a staggered manner.
== Last week ==
As this release is focused 100% on finishing MultimediaViewer so we can
release it to wider audiences, last week's accepted cards [1] are no
surprise:
* Several bugfixes to CSS and JavaScript alike, including a nasty bug
involving keyup event handlers [2], a stubborn bug having to do with
foreign database image repositories [3], and a bug arising out of our
lazy-loading patch from the prior week [4]. Also a fix for a race condition
when loading many images quickly. [5]
* Work on technical debt, in particular consolidating the spaghetti code
strung between two class systems into our single "mmv" module set. [6]
* Showing permissions that are more complicated to the user, instead of
just the license name [7] [8] - this is a big win for Commons, where
file permissions can sometimes be...well, a little hairy. :)
* Loading a fuzzy thumbnail of the image while the bigger image is loading
in the interface [9] - gives you a more consistent viewing experience
that doesn't seem as choppy.
== This week ==
Notable cards we've scheduled or continued working on this week include [10]:
* Share [11] and embed [12] features for the lightbox, using oojs-ui that
is newly in core. We'll be giving you wikitext and HTML code that you
can copy and have images on-wiki or off. Also we'll have an easy link
to the image that you can share on whatever Flitter or Macebook site
your heart desires. I'll be sending a separate mail about this shortly
to update you and be a little more verbose.
* Metrics for MultimediaViewer [13] - we've put this off long enough, it's
high time we had dashboards! These will show you things like how many
times the close button is used, how many times people go into fullscreen,
and also load times for images, metadata, and more.
* Download interface for files [14] - this will use the same panel as share
and embed, but will be slightly differently organized.
== Future ==
If you have any questions or suggestions for the Multimedia team regarding
this release, or any of the work we're doing, feel free to contact us
on- or off-list. We'll try to be better about using this list in coming
weeks, and we hope you'll enjoy the updates :)
You can also find us in #wikimedia-multimedia on irc.freenode.net, and
you can leave feedback about our various products on the subpages of our
team page on MediaWiki.org [15].
[0] https://www.mediawiki.org/wiki/Extension:MultimediaViewer
[1] http://ur1.ca/gpp1a
[2] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/236
[3] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/217
[4] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/254
[5] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/242
[6] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/177
[7] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/118
[8] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/197
[9] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/146
[10] http://ur1.ca/gpp39
[11] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/147
[12] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/148
[13] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/54
[14] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/79
[15] https://www.mediawiki.org/wiki/Multimedia
Thanks for reading, and have a good week!
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
