Hi folks,
I am happy to let you know that we have just launched Media Viewer 0.2 on our first pilot site, MediaWiki.org, where it is now enabled by default for all users (previously, it was only available as a Beta Feature).
Media Viewer aims to improve the multimedia viewing experience on Wikipedia and Wikimedia sites, to display images in larger size and with less clutter — as well as invite more people to use our images.
We invite you to try out this new tool today, which you can do on this test page:
https://www.mediawiki.org/wiki/Lightbox_demo
Please let us know what you think on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
You can learn more about this new feature here:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
After this first pilot, we plan to enable Media Viewer by default for these next pilot sites:
• April 17 - Confirmed: Catalan, Hungarian, Korean, English Wikivoyage
• April 24 - Proposed: Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Thai, Slovak, Vietnamese
Based on these first pilot results, we plan wider releases on larger wikis in the following weeks, with a goal to deploy to all wikis next month. Our release schedule will be based on new findings at each stage of deployment. If this product performs well and meets user needs, we may accelerate the deployment pace -- or we may slow it down for some sites, as needed.
More details are available on our updated Release Plan:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
To discuss this release and review the final product together, we invite you to join our next IRC chat, on Wed. Apr. 9 at 18:00 UTC (11am PT). We also invite you to try out the tool on your own wikis, where it is available for early testing as a Beta Feature in your user preferences, as described above.
Please let us know if you have any questions, suggestions or comments about this release. And many thanks to all the community members who helped create this feature with us in recent months!
We look forward to bringing a richer multimedia experience to your community very soon.
Regards as ever,
Fabrice
on behalf of the Multimedia Team
https://www.mediawiki.org/wiki/Multimedia
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi,
Cold cache concerns aside (see the other email I just sent), I now have
preliminary performance figures comparing Media Viewer to the status quo
(File: page) in production. I'm still working with QA on getting our test
merged and running automatically on cloudbees. The results I have were
performed on a 2MB DSL connection in France, with nothing else running on
the network.
Since we don't collect browser resolutions in our own stats (that I could
find) I picked "average" and "large" desktop browser window sizes based on
3rd-party "internet-wide" statistics I could find online. These statistics
differentiated desktop and mobile, so mobile's lower resolutions didn't
affect the average. The "small" size was picked specifically to hit a
bucket size identical to the File: page's image.
On an small browser window size (900x700), Media Viewer displays the image
in a little less than 125% of the time it takes to display the image on the
File: page
On an average browser window size (1366x768), Media Viewer displays the
image in a little less than 125% of the time it takes to display the image
on the File: page
On a large browser window size (1920x1080) I found the same result, but I
suspect it might not be true, because my desktop wasn't big enough to
accommodate that size in selenium's Firefox. I think we'll need to wait for
cloudbees to run the tests headless for the real figure.
For the sake of argument, let's look at the difference in file size between
the file page and the "average" browser size:
http://en.wikipedia.beta.wmflabs.org/wiki/File:Sunrise_over_fishing_boats_i…
- on the File: page, the image displayed is 800x600 (480,000 pixels) and
weighs 52.7kb
- on Media Viewer, at the "average" browser resolution, the image displayed
is 1024x768 (786,432 pixels) and weighs 79.6kb
Therefore, the Media Viewer image has 63.8% more pixels on the screen and
weighs 51% more.
But, this is only a consolation prize, because the small browser window
size (900x700) which serves the same 800x600 image as the File: page still
takes 20-25% longer, which seems to indicate that Media Viewer's overhead
isn't due to the image size. Basically, if we made the File: page serve a
1024x768 image, it would certainly still beat Media Viewer.
We've already done multiple rounds of optimizing the performance of Media
Viewer, but I'll investigate further to see if there's anything obvious
that makes Media Viewer slower than opening the File: page.
In my opinion between 20 and 25% of overhead isn't a show-stopper for
launch, considering that Media Viewer serves a bigger image in most
situations, but it's worth giving optimizing one last try to see if we've
missed anything. However, it could very well be that we can't do better and
that the overhead is due to doing adding the image dynamically with JS
instead of it being present in the pageload DOM of a relatively lightweight
page.
Hi everyone,
Last year, I got in touch with a programmer currently located in India who
works for Microsoft. His team developed a DVD-video of the Wikipedia for
Schools fork.
http://www.sos-schools.org/wikipedia-for-schools
The dvd plays on a normal dvd player and a TV. The dvd could be made
available as a disk image torrent file that anyone could burn to a
dual-layer DVD, and sell in any kiosk around the world.
The DVD hasn't been released because of the liability issues with content
that his employer (Microsoft) is concerned about, and unwilling to go out
on a limb on. Other than that, he tells me that his team is totally into
sharing this with the world.
I just received a copy of this DVD and its a clunky prototype, but it works
on my computer as a video-DVD. Unfortunately my home blu-ray player doesn't
recognize the DVD +R DL format.
Thought I should share this with you all :)
--
*Victor Grigas*
Storyteller <https://www.youtube.com/watch?v=3Knv6D6Thi0>
Wikimedia Foundation
vgrigas(a)wikimedia.org
https://donate.wikimedia.org/
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
Hello everyone,
Glad to be back at work, after a wonderful vacation in Bali! (6)
I wanted to give you all a quick update on our upcoming Media Viewer release, so we can prepare together for this long-awaited deployment.
1. First Pilots
We are planning to enable Media Viewer by default for these first pilot sites, on these dates:
• April 10 - MediaWiki.org
• April 17 - Catalan, Hungarian, Korean, English Wikivoyage (confirmed)
• April 24 - Confirmed: Hebrew, Thai - Proposed: Czech, Estonian, Finnish, Polish, Romanian, Slovak, Vietnamese
Many thanks to all the community champions who are helping us introduce this tool in these first pilot sites. Note that the pilot list is still being finalized. If you are interested in being a pilot site, please contact us.
2. Pilot Goals
During these first pilots, we will study the impact of Media Viewer on these two fronts:
• Community: how are editors responding? what are readers saying in the survey? is the overall feedback favorable?
• Performance: how fast do images load? any slowdowns during peak hours? is the overall performance acceptable?
3. Full Release
Based on these pilot results, we plan wider releases on larger wikis in the following weeks, with a goal to deploy to all wikis in May. Our release schedule will be based on new findings at each stage of deployment. If this product performs well and meets user needs, we may accelerate the deployment pace -- or we may slow it down for some sites, as needed.
More details are available on our updated Release Plan. (1)
4. Final features
We are focusing on these final features for this release:
• Opt-out preference (done)
• Prominent links to the file page (done)
• Leave feedback / user survey (done)
• Use this file (share/download/embed)
• Show images in Media Viewer on shared links
• IE 9-11 support
• Improved Media Viewer metrics
• Image load performance metrics
For more info, see our Release Wall on Mingle. (2)
You can also track our progress with usability testing (3), which so far is looking very positive.
5. How you can help
To prepare for a smooth release of Media Viewer, we invite community champions for each site to consider the following launch tasks:
* Translations
* Local test page
* Local discussion page
* Local announcements
* Feedback updates
For more tips on how to help launch Media Viewer on your site, check these Launch Tips. (4)
6. Join our next IRC Chat
To discuss this release and review the final product together, we invite you to join our next IRC chat, on Wed. Apr. 9 at 18:00 UTC (11am PT). (5)
Please let us know if you have any questions, suggestions or comments about this release. And many thanks to all the community members who helped create this feature with us in recent months! We look forward to bringing a richer multimedia experience to your community very soon.
Regards as ever,
Fabrice
on behalf of the Multimedia Team
(1) Media Viewer Release Plan:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
(2) Current Release Wall:
http://ur1.ca/guqwk
(3) Usability Testing:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Usability_testing
(4) Launch Tips:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Launch_…
(5) Next IRC Chat:
https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
(6) ‘Best of Bali’ photos on Flickr:
https://www.flickr.com/photos/fabola/sets/72157643604358084/
(subset coming soon to Commons)
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
