Forwarding to a relevant list -- I hope this is useful feedback to the Multimedia team itself
svetlana
----- Original message -----
From: John Mark Vandenberg <jayvdb(a)gmail.com>
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments
Date: Mon, 25 Aug 2014 14:37:19 +1000
On Mon, Aug 25, 2014 at 2:07 PM, Marc A. Pelletier <marc(a)uberbox.org> wrote:
> On 08/24/2014 11:19 PM, Pine W wrote:
>> I have
>> heard people say "don't force an interface change on me that I don't think
>> is an improvement."
>
> I do not recall a recent interface change deployment that wasn't
> accompanied with, at the very least, some method of opting out. Did I
> miss one?
Did you try opting out of MediaViewer on the mobile version?
I think the response that I received confirmed it wasnt possible.
Per-user opt-out aside, the WMF was still forcing an interface change
onto the community at large. With VE, the WMF needed the community to
add TemplateData to all templates to help the newbies who were using
VE; with MV, the WMF needed the community to 'tag' images which
shouldnt be shown in the MV, and there is an ongoing need for the
community to 'fix' the image page syntax in order for the information
to display correctly to the end users in MV.
In both cases, significant amounts of volunteer time is required to
avoid a bad user experience.
WMF needs 'buy-in' for that, if it wants volunteers to be happy
volunteers while doing mundane work to make the new software suck
less.
--
John Vandenberg
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
FYI - User:TheDJ has made a very handy tool that will let you see the
machine-readable data (per COM:MRD) for a given file on the File: page.
This helps ensure that any automated re-use can be done in a manner that's
license compliant and consistent with authors' wishes. To give it a spin,
import this guy into your common.js:
https://commons.wikimedia.org/wiki/User:TheDJ/datacheck.js
This should definitely help leading into the systematic structured data
efforts. Still early days and would make a nice gadget down the line :)
Erik
Hello friends of Multimedia,
Time for another update about our multimedia project. We’re sorry about the radio silence in recent weeks, as many of us were tied up at Wikimania and/or traveling.
Here are some highlights of what we’ve been working on this month:
1. Media Viewer Improvements
We are now working to improve Media Viewer in coming weeks, to address editor concerns while making it even more useful for readers — our main target users for this product. Here are some of the improvements we are planning to test and develop for the next version:
* a much more visible link to the File: page;
* an even easier way to disable the tool;
* a caption or description right below the image
* remove additional metadata below the image, directing users to the File: page instead.
As described in our improvements plan (1), these features are now being prototyped and will be carefully tested with target users in coming days, so we can validate their effectiveness before developing and deploying them in September. You can see some of our thinking in this presentation we discussed with community members at Wikimania in London (2) -- with positive responses from many experienced users. We’ll keep you posted on what we learn from this research in coming days, based on our latest prototype (3). Please contact us if you are interested in testing the prototype, with the understanding that we are now optimizing it for casual users, not power users.
2. Community Discussions
While Media Viewer has generally been well received on most wikis, you’ve probably heard by now that it was the subject of three separate Requests for Comments on the English and German Wikipedias, as well as on Wikimedia Commons.
The Wikimedia Foundation has now responded to all three RfCs, as briefly summarized below. We understand that a majority of editors participating in these RfCs would prefer that Media Viewer be disabled by default for all users. Yet many of those editors have also correctly pointed out that Media Viewer is primarily aimed at readers — and the feedback we have collected so far shows that many readers find this tool useful, across our projects. We also note that if Media Viewer were to be disabled by default, it would be very difficult for those readers to re-discover it and re-enable it. So it seems important to keep it enabled for logged-out users, instead of preventing them from using it, if they find valuable. And while we recognize that enabling Media Viewer by default can be inconvenient for logged-in editors, it’s also easy to disable -- either within the tool itself, or in their preferences -- and we plan to make it even easier to opt out in the next version. For software tools like these, our view is that we should let individual users decide for themselves if they want to keep new features enabled.
For these reasons, the foundation respectfully declined to disable Media Viewer by default for either logged-in or logged-out users on the English and German Wikipedias at this time. On Wikimedia Commons, however, the tool has just been disabled for logged in users by default, as a special exception due to that project's primary focus on media curation. Each community has responded in different ways to the foundation’s statements. In one case, our decision to leave Media Viewer enabled by default led to a conflict escalation between the foundation and some German community members, which we deeply regret. In coming weeks, we will exert our best efforts to resolve these issues in a variety of ways, from improving Media Viewer itself (see above), to improving the process by which new features are developed, tested and released (see below).
3. Working Together
As our executive director Lila Tretikov stated on her talk page (3), the foundation is committed to working with the community towards a constructive resolution of this and any future disputes. We are now reviewing our current development processes and exploring new approaches to allow for feedback at more critical and relevant junctures. With that in mind, we invite you to help brainstorm ideas that might improve community engagement for future product rollouts, on this special page (4). I will also be going to Germany in about a month to discuss some of these issues in person with community members, whom I really look forward to meeting face-to-face.
4. Wikimania Update
Most of our multimedia team was present at Wikimania in London, where we hosted 7 different roundtable discussions and sessions, which we found extremely productive. Topics ranged the gamut from the Structured Data to Upload Wizard, Media Viewer, Video, Community Engagement — and yes, even Kindness. We really enjoyed our many constructive conversations with hundreds of community members, who worked with us as partners to improve our plans and products in a variety of useful ways. We’re very grateful for these special collaborations, which keep getting stronger year after year. In coming days, we will share what we learned together in some of these sessions. For now, you can check each session's slides and notes, which are linked on this overview page (5). You might also enjoy some of my favorite photos from this exceptional gathering (6), as well as the latest installment in my ongoing series of community ideas on how to improve Wikipedia (7). Finally, those of you who read German might appreciate User:Ziko’s excellent article for the Kurier on our in-depth conversation in London (9).
Overall, the wonderful collaborations we’ve enjoyed with many of you at Wikimania are a great example of what is possible when we all work together in good faith and with mutual respect for each other.
Thanks to everyone who made this inspiring event possible!
I am sorry about the length of this message, but we had a lot to catch up on: I wanted to cover some of the recent events, so we can move forward with a shared understanding of how we got there, where we’re going, and how we can improve things together.
We all look forward to more collaborations with you on Structured Data, Upload Wizard, Video and other projects looming on the horizon — above and beyond Media Viewer. :)
To be continued …
Fabrice — for the Multimedia Team.
(1) https://docs.google.com/a/wikimedia.org/document/d/1iCDNOUK14D7xb47o33k1p0D…
(2) https://docs.google.com/a/wikimedia.org/presentation/d/1FNGLEzVsoELZqxiso_1…
(3) http://multimedia-alpha.wmflabs.org/wiki/Rapa_Nui_National_Park
(4) https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
(5) https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
(6) https://wikimania2014.wikimedia.org/wiki/Multimedia_Events
(7) https://www.flickr.com/photos/fabola/sets/72157646189670769/
(8) https://www.flickr.com/photos/fabola/sets/72157646308694626/
(9) https://de.wikipedia.org/wiki/Wikipedia:Kurier
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi everyone,
I was talking with several people here at Wikimania about the
Rijksmuseum website. Take for example
https://www.rijksmuseum.nl/nl/collectie/SK-A-2344 . I like the design a
lot. Maybe a good inspiration for future designs?
Maarten
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