Multimedia March 2014

multimedia@lists.wikimedia.org

32 participants
26 discussions

Usability testing for media viewer
by Pau Giner 15 May '14

15 May '14

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

2 3

How to make templates readable to MediaViewer
by Gergo Tisza 03 May '14

03 May '14

Hi all, I've been asked how to make templates that can provide information for MediaViewer to display on the metadata panel; I will try to give a few pointers. == Metadata types that are already handled == If you want to ensure the some type of metadata that is already handled by MediaViewer (license, description, author name etc.) will be read correctly for files which have been uploaded to your wiki, you need to present it in the same way it is presented on Commons. See the first two sections of COM:MRD [1] (infobox templates, license templates) on how to do that. (Also, COM:GEO [2] although currently it is not very helpful for figuring out how to make location templates in other wikis compatible.) tl;dr: you need to add a certain HTML id or class to some container element in the template, and another one to the specific text that you want to be machine-readable (such as the license name) - this usually means wrapping the text in a <span> which does not change anything visually (or maybe hides the text completely) but has a certain class or id. So in practice it will look something like this: <div class="licensetpl"> (lots of fancy HTML) Licensed under the <span class="licensetpl_long">Do What the Fuck You Want to Public License</span> (<span class="licensetpl_short">WTFPL</span>). <span class="licensetpl_attr_req" style="display: none">false</span> (more fancy HTML) </div> Alternatively, if you don't want to mess with existing template code, you can just add all the information in hidden fields, the way the PD templates do it on Commons [3]. If you have lots of templates for the same license, and they do not share a common layout template, this way it can be done by a bot. == New metadata types == If you want to add some new kind of information to MediaViewer, you need to make sure there is a template which will provide it in the way described above (have a class that wraps the whole template plus a class for each specific piece of information you want to read from it). Just marking up the template as a whole will probably not be enough. That way MediaViewer gets a big HTML blob instead of proper metadata. We would really like to avoid displaying big blobs of HTML which will clash with the design of the viewer in uncontrollable ways. We made an exception with permission templates, because they are important (also there is lots of them, and marking all up properly would be herculean work), we would prefer if we didn't need to make more. So please try to figure out what is the specific text (or link, logo image, whatever) that needs to be shown, and add specific markup for that. (Also, before putting a lot of work into making some templates provide metadata, make sure somebody is willing to implement it on the MediaViewer side!) == IQ&A (answers to imaginary questions) == Q: Is the class wrapping the whole template ("licensetpl" in the above example) important? A: Yes! We use it to know which fields belong together when multiple templates of the same type are used on the page. Q: I am adapting templates for a new type of metadata. Should I use ids or classes? A: Classes. Please. Using ids is almost always a bad idea. Using the same id twice on a page is invalid HTML and can cause unexpected behavior (XML parsers choking on the page, CSS selectors not returning all matching elements etc). You might think that the template will never need to be used twice on a page, but you will probably be proven wrong eventually. (Also, ids are more trouble when adding CSS styles. Although using the same id/class for marking up metadata and for styling the content is probably a bad idea in itself.) Q: I want to mark up templates on my local wiki to be compatible with Commons templates. Are all the fields described on COM:MRD used by MediaViewer? A: No, most aren't. You can check the source code [4] if you need an exact list. (It is not as hard as it sounds!) Q: Does all information come from the templates described on COM:MRD? A: No, some comes from categories (specifically assessment data such as featured image status - although we do not display it yet). That will not work for non-Commons-hosted images :( If you want to help with fixing that, see the previous section. Q: What about internationalization? A: If the template uses MediaWiki messages for localization, that will work. Other methods probably won't. (Language templates like {{en}} work in {{Information}} and similar templates, but that's probably not a method that can be used for other types of metadata.) [1] https://commons.wikimedia.org/wiki/Commons:Machine-readable_data [2] https://commons.wikimedia.org/wiki/Commons:Geocoding [3] https://commons.wikimedia.org/w/index.php?title=Template:PD-Layout&action=r… [4] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCommonsMetadata/mas…

3 4

Wikimania Presentations on Multimedia
by Fabrice Florin 11 Apr '14

11 Apr '14

Hello friends of multimedia … and greetings from Bali! I’m on vacation here through the end of the week, but just took a break from my yoga retreat to submit these session proposals for Wikimania 2014, since the deadline is today: * Multimedia_Overview Presentation - 30 mins. https://wikimania2014.wikimedia.org/wiki/Submissions/Multimedia_Overview * Multimedia Roundtable Workshop/Discussion - 150 mins. https://wikimania2014.wikimedia.org/wiki/Submissions/Multimedia_Roundtable The first proposal is intended for folks who just want a quick update on what we’re working on. The second one is going to be a more interactive, in-depth brainstorming session to help plan our next steps together, much as we did last year in Hong Kong: https://meta.wikimedia.org/wiki/Roundtables/Roundtable_3 If you plan to go to Wikimania this year and you are interested in either of these sessions, please sign up at the bottom of the submission pages to let the organizers know of your interest. Namaste, Fabrice P.S.: I will not respond to emails on this account until I return to work next Monday. But in my absence, Gilles Dubuc and others on the multimedia team can address any questions you might have about these sessions, as well as make any tweaks to the submissions, as needed. _______________________________ Fabrice Florin Product Manager Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

4 5

Improving TIFF handling (display and interface issues)
by Dominic McDevitt-Parks 08 Apr '14

08 Apr '14

I've been spending a lot of time recently looking--from a user's perspective--at how MediaWiki handles TIFFs. I'm interested in this because in my work with the U.S. National Archives, we uploaded many tens of thousands of TIFFs. I am planning to upload far more by the end of this year, potentially at higher resolutions, and the new GLAMwiki Toolset raises the possibility that other institutions may do the same in the future. Even though TIFFs seem esoteric, I think there is a high potential for impact in improving the user experience around them. The main issue is that MediaWiki's handling of TIFFs is unsatisfactory enough that projects like Commons are resorting to asking contributors to upload exact duplicates of any TIFFs as JPG as well and treat the TIFF as just an archival copy for downloading, but not for categorizing or embedding on Wikimedia projects--even though MediaWiki generates JPG thumbnails of TIFFs for display in articles and even (thanks to Brian) now let users download full-resolution copies of TIFFs in JPG format. This a bad workaround, since it introduces unnecessary duplication, and identical pages which are left out of sync. I'm hoping to interest you all in resolving a few of the outstanding bugs related to display of TIFFs so we can abandon this practice in the future. A couple of these are relatively minor interface design issues. Here are the 5 bug reports I think are most critical here: 1.) TIFFs are less sharpened than JPG equivalents. See https://bugzilla.wikimedia.org/show_bug.cgi?id=45212 2.) Display file format of preview if different format from original file See https://bugzilla.wikimedia.org/show_bug.cgi?id=56546 3.) More prominent display of both full-resolution files available for download See https://bugzilla.wikimedia.org/show_bug.cgi?id=62305 4.) Consider raising $wgMaxImageArea limit for images See https://bugzilla.wikimedia.org/show_bug.cgi?id=62463 5.) Better error handling for files that break the megapixel limit See https://bugzilla.wikimedia.org/show_bug.cgi?id=62306 Anyone have thoughts about these? Dominic -- Dominic McDevitt-Parks Cultural Partnerships Coordinator, Wikimedia District of Columbia http://wikimediadc.org dominic(a)wikimediadc.org @Dominic_MP | @wikimediadc

2 1

ogv.js media player update: Flash and GPU acceleration
by Brion Vibber 30 Mar '14

30 Mar '14

I spent a little more time the last few weekends on ogv.js (JavaScript-based player for Ogg Theora and Vorbis media in IE and Safari) and have gotten two major things working: * an all-Flash version -- should work in older IE and Safari versions that can't run the JS code * optional GPU acceleration with WebGL or Flash Stage3D where available More details on my blog: https://brionv.com/log/2014/03/29/ogv-js-now-in-webgl-and-flash-flavors/ The Flash version generally runs a bit faster than the JS version on IE 10/11, about the same as JS on Safari 6.1/7, and slower than JS on current Chrome and Firefox. Note that the player demo page currently requires IE 9 or later although the player itself should work on IE 6/7/8. I've also compared performance to the Cortado Java applet we currently use -- Cortado is still a little faster in terms of CPU usage, but getting the applet to actually *run* with the current version of Java is a nightmare -- even the signed version of the applet from theora.org requires adding a security exception -- whereas JS or Flash "just works". GPU acceleration in both JS and Flash combines YCbCr->RGB colorspace conversion into the drawing step and can be a *huge* speed boost at higher resolutions. At 360p or 160p it's a modest improvement of a couple milliseconds per frame on my test machines. Note that WebGL is available in IE 11, but is disabled by default in current versions of Safari (and cannot be enabled on iOS without a jailbreak). The main missing feature left is seeking, which I think can be left for later. I expect to do a bit more performance tuning and code cleanup, but I think it's time to devise some integration into TimedMediaHandler so people can try it out "in-place" on Wikipedia & Commons... -- brion

3 2

Thumbnail Generation on Hovercards (Extension:Popups)
by Prateek Saxena 30 Mar '14

30 Mar '14

The design team recently deployed the Popups[1] extension to English Wikipedia as a Beta Feature. We are using the PageImages[2] extension to get a thumbnail with a `pithumbsize` of 300. This was initially 290, but someone on IRC - I forget who - mentioned that it would be faster if it were 300. We are facing two problems with this approach - 1. Some images are taking too long to load [3] 2. Sometimes the first relevant image is not picked up [4] Any ideas on how these bugs could be resolved would be helpful. The code for the current implementation can be found on git [5]. --prtksxna [1] https://www.mediawiki.org/wiki/Extension:Popups [2] https://www.mediawiki.org/wiki/Extension:PageImages [3] https://bugzilla.wikimedia.org/63156 [4] https://bugzilla.wikimedia.org/63177 [5] http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FPopups.git/abafedb99…

6 11

Re: [Multimedia] [Design] Going full-screen on image click
by bawolff 30 Mar '14

30 Mar '14

> > The WMF Engineering Team is kindly working on Media Viewer, which would show a pop-up of some sort when you click an image. Sorry for being overly pendantic, but probably better to say WMF multimedia team is working on media viewer. WMF engineering is a very big group of people - the vast majority of whom are not working on multimedia viewer. </obnoxious pendantic rant> Cheers, Bawolff

1 0

Going full-screen on image click
by Gryllida 30 Mar '14

30 Mar '14

Hi all. I apologize for cross-posting; I'm trying to reach all projects here, and encourage you to translate and spread this message to relevant village pumps. It came to my mind that the Media Viewer goes full-screen, which doesn't meet the "I stay on the article" expectation. I feel it may be important to an average reader to gain orientation. I opened a discussion, with some people calling my idea a "metadata pop-up" rather than a "media viewer". I feel that may be good thing: the existing default opens a lot of image info and tells people what Commons is. I feel the media viewer should do something close to the same, with the advantage of not leaving the page, and some interactive means of viewing the image if the user clicks some buttons. As opposed to that, a "Media Viewer" would show a bigger image and make use of space. But the mock I have is slightly bigger already, like the existing "File:*" page. I am not assuming that the reader wants a bigger image; I'm assuming he may also be interested (and it would be more transparent to) in reading some metadata, description, date, author. Please see the discussion here and weigh in, basing on your preferences and Wikimedia projects experience. https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Please_do… Regards, Gryllida.

1 0

Sprint planning notes...
by Aaron Arcos 27 Mar '14

27 Mar '14

Notes <http://etherpad.wikimedia.org/p/multimedia-weekly-meeting-2014-03-27> and Current Sprint Wall<https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/grid?ag…>, as always feel free to correct/add anything missing.

1 0

minimal-ui directive in iOS 7.1
by Ori Livneh 26 Mar '14

26 Mar '14

The newest release of Mobile Safari adds support for a new meta tag property, 'minimal-ui', which allows you to hide the browser chrome. It looks really great. I thought it might pair well with MultimediaViewer. http://darkblue.sdf.org/weblog/ios-7-dot-1-mobile-safari-minimal-ui.html --- Ori Livneh ori(a)wikimedia.org

5 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Multimedia March 2014