Hi folks,
We're happy to let you know that our multimedia team has completed all the requested 'must-have' improvements to Media Viewer for this year’s release, based on community feedback.
These improvements have now been released on all Wikimedia-hosted sites, as described here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Improvements
We would appreciate your advice on one last community request, which seems important to address before we wrap up.
Many editors have asked for a quick way to copy and paste the full file name from Media Viewer, so they can use that file in an article without extra clicks.
They can already copy the file name from the URL, or from the Share or Embed panels, but have to remove extra characters, which slows them down. And now that we have replaced the file name with a caption right below the image, there is no easy way to copy it in Media Viewer.
To address this issue, we propose to show the file name right below the license label, as illustrated here:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/798 <https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/798>
Here are a few questions we’d love your feedback on:
1. Is this file name feature useful for editors?
(We know it’s not that useful for readers, which is why we propose placing it below the fold — but we wanted to offer it for editors who requested it, if it’s helpful.)
2. Is the placement below the license practical?
(Note that you have to scroll down to see the file name; but that seemed faster than placing it in the Share panel, which would be one click away and may be harder to find.)
3. Should we include ‘File:’ before the file name?
(Does it help editors if we display ‘File:Chamonix flowers.jpg’ — instead of just ‘Chamonix flowers.jpg’, as shown in the mockup above?)
4. Any other suggestions for improvement?
Please let us know what you think, so we can make any final tweaks based on your feedback. You can respond by email to the list or just to the me and the four team members in the Cc: line.
We will post one last project update in a few weeks, to share our research findings.
Best regards,
Fabrice — on behalf of the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi Jesse,
Thanks for sharing this nice success story!
I’m really happy to hear that over 400 videos were added to articles within three weeks of your event.
This is a great accomplishment, given that there is still not a lot of video on Wikipedia at this time. Nicely done!
I just tweeted it here, if you’d like to retweet:
https://twitter.com/fabriceflorin/status/539847861178212353
I also recommended it to our social media team, and am sharing it with our multimedia and commons mailing lists.
Keep up the great work :)
Be well,
Fabrice
> On Dec 2, 2014, at 5:24 AM, Jesse de Vos <jdvos(a)beeldengeluid.nl> wrote:
>
> Hi all,
>
> I have written a blogpost about our positive(!) experiences with organizing a video-challenge on the UNESCO World day for Audiovisual Heritage. You can find it here:
>
> http://www.beeldengeluid.nl/en/blogs/research-amp-development-en/201412/vid… <http://www.beeldengeluid.nl/en/blogs/research-amp-development-en/201412/vid…>
>
> Most notably, over 400 videos were added to articles within three weeks.
> We're very open to suggestions how we can improve these type of 'contests' and perhaps there are people who would like to join in for next years' World Day of Audiovisual Heritage (7th October 2015)? :)
>
> Best,
> Jesse
> --
> Met vriendelijke groet,
>
> Jesse de Vos
> GLAM-wiki coördinator
>
> T 035 - 677 39 37
> Aanwezig: ma, di, do
>
> <http://www.beeldengeluid.nl/>
> Nederlands Instituut voor Beeld en Geluid
> Media Parkboulevard 1, 1217 WE Hilversum | Postbus 1060, 1200 BB Hilversum | beeldengeluid.nl <http://www.beeldengeluid.nl/>
> _______________________________________________
> Wikivideo-l mailing list
> Wikivideo-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
(Hat-tip to Nemo for noticing this)
We're writing up and redefining the pageview definition. Amongst other
things, it uses MIME type filtering and folder-level filtering to exclude
non-pageviews.
Problem: the multimedia viewer false anchor (an example is
https://az.wikipedia.org/wiki/Mar%C3%A7ello_Malpigi#mediaviewer/File:Marcel…
is both text/html (one of the recognised and appreciated MIME types) and
/wiki/ (one of the recognised and appreciated domains).
The result of this is that it's currently going to be counted as a
pageview, even though it's...well, not.
Is there any way you lot could avoid the false anchor strategy and pick a
URL scheme that won't trigger this? If not, we can just write an exception
- but I'd rather that we not have to do that every time anyone decides to
make software.
Thanks,
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
Hey folks :)
We'll be doing another office hour to answer all of the questions
about structured data for multimedia files. We'll try...
It'll happen on November 20th at 19:30 UTC in #wikimedia-office on
freenode. See http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=30&sec=0&d…
for your timezone.
Hope to see many of you there!
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Greetings all,
My apologies for cross-posting lists. I would like to invite everyone
interested in the proposal for Structured Data on Wikimedia Commons[1] to
join our third Office Hours today, 20 November, from 19:30 to 20:30 UTC[2
for time conversion]. The conversation is free to join on IRC using
freenode[3] in #wikimedia-office.
Discussion will continue about the different possible data structures, very
early development work, and touch base on some work that was done during a
small hackathon in Amsterdam[4] working with structured data and GLAM. As
always, other questions and discussion about the topic are always welcome.
I look forward to seeing you there!
1. https://commons.wikimedia.org/wiki/Commons:Structured_data
2.
http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=30&sec=0&d…
3. http://webchat.freenode.net/?channels=#wikimedia-office
4. https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2014
--
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
Actually copying in the multimedia mailing list correctly this time.
Note: this mailing list is open to the public, and any emails you send
to it will be publicly archived forever at
https://lists.wikimedia.org/pipermail/multimedia . This is standard
fare for Wikimedians, but the Microsoft people on this thread may not
be used to this.
On Wed, Nov 12, 2014 at 7:13 PM, Roan Kattouw <rkattouw(a)wikimedia.org> wrote:
> Copying in:
> * Multimedia team because this concerns video playback
> * Oliver because he maintains ua-parser
> * Erik Z because he maintains browser statistics
> * Timo because he cares about browsers and relationships with the browser
> communities
>
> On Wed, Nov 12, 2014 at 6:42 PM, Rob Macias (Axelerate)
> <v-romac(a)microsoft.com> wrote:
>>
>> Hello All,
>>
>>
>>
>> As you may have heard, we rolled out a new Windows 10 preview build with
>> significant IE interoperability updates and wanted to make sure our
>> Wikipedia partners are in the loop. A major part of this update is the
>> “Edge” mode platform, which seems to affect how IE is being detected – this
>> is leading to Video playback errors when visiting the wikimedia.org domain.
>> More info on ‘living on the edge’ exists here
>> http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-edge-our-next-s…
>>
>>
>>
>> To our Wikipedia folks:
>>
>> Mind taking a look at this? Bug detail has been pasted below including
>> steps to reproduce and developer notes. If you aren’t already a member of
>> the Windows Insider Program, we recommend doing so OR you can download
>> RemoteIE, which provides another option for testing your site in the latest
>> version of IE.
>>
>>
>
>
> I'm not aware of us being a member. Timo, could you look into whether we
> are, and whether we should be?
>
> RemoteIE looks really useful. It doesn't seem to be available for Ubuntu
> though? Our engineering staff is split roughly 50/50 between Mac OS and
> Ubuntu / other Linux flavors, so if RemoteIE is only available for Windows
> and Mac OS on desktop, then it's only useful for about half our staff. But
> that's still a heck of a lot better than passing a Windows laptop around the
> office :)
>
>>
>> (Bug Specs)
>>
>> Reference #: 741977
>>
>> Description of the Problem: commons.wikimedia.org: Video is not being
>> played
>>
>> Steps to Reproduce:
>>
>> 1. Navigate to URL: http://commons.wikimedia.org/wiki/Main_Page.
>>
>> 2. Scroll down to video window
>>
>> 3. Invoke Play button to play video/ audio on the page.
>>
>>
>>
>> Actual Result:
>>
>> Video is not being played only black screen is displayed and instead of
>> playing video, it is asking to save the file.
>>
>>
>>
>> Expected Result:
>>
>> Video should load and play properly.
>>
>>
>
>
> Multimedia team, could you guys look into this?
>
>>
>> Developer Notes:
>>
>> With the introduction of the Edge mode platform, the site needs to account
>> for the latest UA string changes. See below:
>>
>>
>>
>> Mozilla/5.0 (Windows NT 6.4; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/36.0.1985.143 Safari/537.36 Edge/12.0
>>
>>
>>
>> These changes help prevent IE from being (incorrectly) identified as an
>> earlier version.
>>
>>
>
>
> Thanks for letting us know that the UA string changed.
>
> Timo, Oliver and Erik Z: you guys should know about this UA string change.
> It'll affect jquery.client, ua-parser, our browser stats, and probably other
> bits of code here and there that will presumably identify this UA as Chrome
> 36 rather than IE 12.
>
>>
>> Please let me know if you have an estimated timeframe to address this
>> issue, and if our team can further assist in this process.
>>
>>
>
>
> Most likely, someone on the multimedia team will file a ticket for this in
> our public bug tracker, which you can subscribe to.
>
> Roan
interesting short thread/idea here, regarding the "play icon" overlay on
video thumbnails. To somehow make it less dominating:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28idea_lab%29#Less_in…
I think this has been discussed before, but I forget where. Perhaps someone
here could summarize the options and pros/cons, or can find links to older
threads?
https://bugzilla.wikimedia.org/show_bug.cgi?id=69362
It looks like Aaron was/is/did write a script to find disappeared
files but there hasn't been an update for a while.
Help?
--
Greg Grossmeier
Release Team Manager
Hi,
Google Code-In (GCI) will soon take place again - a contest for 13-17
year old students to contribute to free software projects.
Wikimedia wants to take part again.
Last year's GCI results were surprisingly good - see
https://www.mediawiki.org/wiki/Google_Code-in_2013
We need your help:
1) Go to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner and
read the information there. If something is unclear, ask!
2) Add yourself to the table of mentors on
https://www.mediawiki.org/wiki/Google_Code-in_2014#Contacting_Wikimedia_men…
- the more mentors are listed the better our chances are that Google
accepts us.
3) Please take ten minutes and go through open recent tickets in
https://bugzilla.wikimedia.org in your area of interest. If you see
self-contained, non-controversial issues with a clear approach which you
can recommend to new developers and would mentor: Add the task to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Proposed_tasks
Until Sunday November 12th, we need at least five tasks from each of
these categories (plus some less technical beginner tasks as well):
* Code: Tasks related to writing or refactoring code
* Documentation/Training: Tasks related to creating/editing documents
and helping others learn more - no translation tasks
* Outreach/research: Tasks related to community management,
outreach/marketing, or studying problems and recommending solutions
* Quality Assurance: Tasks related to testing and ensuring code is of
high quality
* User Interface: Tasks related to user experience research or user
interface design and interaction
Google wants every organization to have 100+ tasks available on December
1st. Last year, we had 273 tasks in the end.
Note that you could also create rather generic tasks, for example fixing
two interface messages from the list of dependencies of
https://bugzilla.wikimedia.org/show_bug.cgi?id=38638
Helpful Bugzilla links:
* Reports that were proposed for GCI last year and are still open:
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=ALL%20whiteboard%3Ag…
* Open Multimedia tickets created in the last six months (if I got your
products and components right):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
* 16 existing Multimedia "easy" tickets (are they still valid? Are they
really self-contained, non-controversial issues with a clear approach?
Could some of them be GCI tasks that you would mentor? If so, please tag
them as described above!):
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
Could you imagine mentoring some of these tasks?
Thank you for your help in reaching out to new contributors and making
GCI a success again! Please ask if you have questions.
Cheers,
andre
PS: And in a future Phabricator world, Bugzilla tickets with the 'easy'
keyword will become Phabricator tasks with the 'easy' project.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
I've gotten some great review feedback from Gilles on the desktop-web
integration of my ogv.js JavaScript & Flash compatibility layers for Ogg
Theora/Vorbis media files -- thanks Gilles!
* libraries: https://gerrit.wikimedia.org/r/#/c/165477/
* desktop integration: https://gerrit.wikimedia.org/r/#/c/165478/
These are getting pretty close to ready to land, I think.
I would love to get some review on the mobile overlay I've whipped up as
well. This supports both native WebM playback (Android Chrome, Android
Firefox, Firefox OS) and ogv.js playback (iOS 7/8 Safari).
* mobile overlay: https://gerrit.wikimedia.org/r/#/c/165479/
* Live demo: https://ogvjs-testing.wmflabs.org/
A few open questions:
1) Is this the right way to do mobile overlay code? (It's basically a rip
of the existing photo viewer overlay in MobileFrontend, but lives in
TimedMediaHandler.) Is the overlay interface stable enough for other
extensions to use it for mobile-specific features? (I had to make updates
for object-model and template things that changed since this summer.)
2) Is the inline icon too huge/ugly here for audio files? Should it be
arranged differently, or display the player inline instead of as an overlay
for audio?
3) Should more controls be added to the overlay's bottom toolbar, such as
manual resolution selection or an 'Open in VLC' link to support HD playback
on iOS?
4) Should we autoplay when opening the overlay, or require a second tap?
5) How should we handle devices with no native playback that are either too
slow (iOS 6 Safari) or lack necessary features needed for the player
(Windows Phone)?
Current known bugs in the mobile overlay:
* CPU speed check not yet integrated to force to lowest resolution for old
iPhones/iPads (this exists on the desktop integration, just needs to be
moved to common code)
* autoplay doesn't seem to work with native playback right now
-- brion
