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
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…
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)
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
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
>
> 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
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.
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