Sunday, November 14, 2010

Media establishment fighting back

By Nicolás García [CC-BY-SA-2.5], from Wikimedia Commons
I've become aware of two cases of old media trying to take back from the Free media movement.

The first is the usage of Wikimedia Commons images by Encyclopedia Britannica online. We are very diligent about copyright in Wikipedia and Wikimedia Commons. Multiple groups of people concern themselves with nothing but assessing images and global copyright laws, to make sure our materials are as legal and as Free as they can possibly be. Not so much Brittanica it seems. They happily ignore all license and attribution requirements that these images have, often just giving the username in plaintext (Examples image by
, image by Toby Hudson). For Creative Commons, a full link to the license is required if in any way possible. And just for kindness, a link back to the Wikimedia Commons description page might be nice/a good idea. The Wikimedia sites do the same for Flickr, it's very easy. Britannica, if you are listening, please read this Creative Commons FAQ.

Is it really required that our users start sending copyright infringement notices to Britannica in order to get issues like this solved ? I know we don't make it easy atm to reuse our material, but come on, these guys are no amateurs and surely they can do better ?

Another development that is starting to affect Commons, is the partnership of Flickr with Getty images. Flickr users can opt-in to a program whereby people can ask for your image to become part of the Getty images collection. Getty images however only excepts exclusive image deals and it seems that when your Creative Commons image is picked up by Getty, it automatically loses its Creative Commons license in Flickr and is switched to an "All rights reserved" status. This is actually allowed, a Creative Commons license is not revocable but you can stop using it on any further distribution. The earlier distributed copies however will remain licensed under the Creative Commons license.

This is already becoming annoying when we need to check the history of an image that has not been automatically checked by our Flickr bot. The larger danger lies in the possibility that someday Google or another large software company, starts filtering for copyright infringements in image search. Google is already doing this kind of thing for Youtube videos and it is logical that as some point in time image data will follow. With such techniques, it becomes possible that valid distribution of previously Creative Commons licensed material, perhaps hosted on Wikimedia Commons, might be tagged as copyright violations, because at a later time Getty appropriated the rights on an image. It would be wonderful if Flickr could make the "licensing history" of an image visible, that is what we need to defend ourselves against such practices.

I have to hand it to Getty however; Smart way to reclaim territory on the Free media movement. Using your industry power and monetary payout to force people into dropping a licensing model they voluntarily chose. I guess Creative Commons will have much more work to do in the coming years.

Thursday, November 11, 2010

Printing Wikipedia

Last year saw the launch of book printing for Wikipedia articles. A very nice feature that allows you to create a collection of articles and print them as a book. Since yesterday you can even get hardcovers. There is also a wonderful "Print to PDF" feature that piggybacks on the book rendering technology.

Printing webpages has long intrigued me and the results have always been suboptimal, especially with something as complex as Wikipedia articles. However, the web is moving forward and the printing options for the web are getting better with every browser release. The past few days I was revisiting this issue and I have now added some new CSS to the print stylesheet of MediaWiki which should help browsers detect proper spots to insert pagebreaks and more importantly, where to avoid them.
Before pagebreak CSSAfter pagebreak CSS
When your browser supports it, it will try to avoid pagebreaks in images, wikitables and right after headers. It will also try to avoid lone sentences of paragraphs at the beginning or end of the page, keeping paragraphs more readable. This CSS is part of the Paged media subset of CSS. It is best supported by Opera and Internet Explorer 8. Actually it's one of the few spots where Webkit and Gecko are really lagging behind a bit. There are many more options in the paged media specification that would help improve printing of pages, but they are part of CSS3 and only Opera has made some progress on this so far.

Another thing that I have been working on is a new gadget called Print dialog. It helps you influence how pages are printed, right from Wikipedia. You can remove backgrounds, images and references, and mark all the text as black. Really very useful for if you intend to do some quick printing and since there is demand (Bugzilla 25869, bugzilla 22256), we might actually see this one day in the MediaWiki software.

The most esoteric function of Print dialog, is an option to actually kill the print styling. Normally when you print Wikipedia pages, you will use a different set of stylesheets that are optimized for printing instead of the screen. These stylesheets hide the interface components and elements that might not be useful in print. Usually this is wonderful, but sometimes I just want it all, and on my browser (Safari), this was not possible (well you could make a screenshot). With this new option you can actually fake the screen media while you print. Currently it works only for Safari. IE is untested, and Firefox/Opera refuse me to give the access I need to adapt the stylesheets, due to the Same Origin policy, which is violated due to the usage by the Foundation of a separate server for the stylesheets (Bugzilla 25886).

Example print output with no images Print output without references and backgrounds Print output with all non-print elements restored
I think this could be a welcome feature for many, please let me know what you think !

Wednesday, October 27, 2010

How the smallest bugs can take the most time to solve

For the past few weeks, I have been fixing problems that I run into while testing some of the new video tools that Michael Dale has been developing for the Wikimedia Foundation. As with any new software, especially Javascript tools, there are plenty of issues and since I can find them, I might as well fix some of them, instead of throwing it all back at Michael.

This week I ran into one particular annoying issue. For some reason the menu in the new mwEmbed mediaplayer (Demo of the player) was flickering under certain conditions on Safari. I created a video that demonstrates the problem.

So I was looking trough the code of the player, trying to come up with a reason on why this would behave like this and why only in Safari. I spent a few hours tracking all the events, assuming that some event (like mouseover) for some reason was incorrectly telling the menu to hide itself. I was validated in this line of thought by observing that manipulating some of the Javascript events of the player, would influence the time the menu would reappear. I could however not find something that influenced the hiding of the menu. The fact that jQuery uses anonymous functions everywhere didn't make the debugging process any easier.

My other idea was that perhaps it was a bug in the HTML5 <video> element of Safari, or in the XiphQT plugins used to decode the video in combination with z-index or relative positioning. I created a few testcases from scratch, but neither proved to be likely. I could not figure out what the problem was.

After some discussion with a few Webkit people, I decided to reduce the original HTML. The original HTML is a lot of code, which was why I was reluctant at first to take this path, but all other options had run out. After some heavy reducing, I figured out that Javascript was no factor here, pure HTML and CSS showed the same problem. This took me by surprise, since I had earlier observed how certain JS events were causing the menu to reappear. Cutting and weeding some more I finally found the cause. The three elements that are needed to reproduce the problem.

  1. An HTML5 video element
  2. An overflowing element in scroll mode, on top of the video element
  3. Opacity set on that overflowing element.

Finally I had traced the issue and it turned out to be a bug in Safari/Webkit. The reason as to why the Javascript event manipulation would influence the problem was easy to understand in retrospect. Such events were triggering redraw events in the browser, which for some unknown reason solves the drawing problem caused by the scrolling event.

Hours of debugging for a small issue, that had its root cause in a browser bug. A ticket has been filed with the Webkit developers, but it shows how developing for new browser features continues to be a time consuming process. All new code has bugs, and when the new code is relying on other new code, finding those bugs takes quadruple the time.

Wednesday, June 30, 2010

How copyright threatens Democracy

Everyone should look at this video of a talk by Cory Doctorow.

People who know me, are aware that I am very concerned about our rights online. This is because every day we become more reliable on the Internet than ever before, yet our liberties our curtailed ever more. No one speaks more about this topic than Cory and really anyone in policy making or in the arts industry should hear him out. Perhaps not because he is right, but at the very least because he presents incredibly sensible counterarguments for anything that the copyright industry claims.

Nowhere has the problem of the copyright lobbies, become more clearly than in the letter sent by ASCAP last week, in which they try to warn and recruit their members in their fight against the 'copyleft' and 'pirate' movement, which they basically consider equal. However as many have pointed out, Creative Commons is about freedom of choice for producers and consumers of works alike. What the ASCAP letter shows is that these organizations do not represent the interests of composers, authors and publishers like they claim, they represent one single bussiness model that wants to prevent its members from making the choice for any other business model. (ASCAP was joined by NMPA this week)

Before we start increasing penalties and agreeing to incredibly hard to recall ACTA-like agreements, we should carefully consider what effect this can have on our lives. Please listen to Cory.

When you are as concerned as I am, please consider supporting Electronic Frontier Foundation or the Dutch Bits of Freedom.

Monday, May 3, 2010

I am now a MediaWiki developer (and Commons admin)

I have been filing and maintaining bug reports in MediaWiki for a while now, trying to communicate issues found by the editor community back to the developer community. Over time, increasingly I have been submitting patches to fix some of the bugs that I find. I never really had the intention to become a MediaWiki developer to be honest, but I guess I filed enough patches that people suggested to me that I should request commit access myself. So last week I sent off an email to Tim Starling and last night I was granted commit access to MediaWiki.

I'll be taking this slow, because much of what interests me (the media and file repository work) is unfortunately not well tested on a day to day basis by others, while still able to create quite the havoc if you make mistakes.

In other news, I also recently became an administrator on Wikimedia Commons. I'm reasonably active on Commons due to image moves from Wikipedia to Commons and recently I fixed up Cat-a-lot, which is a very useful Javascript gadget to move multiple files from one category to another, as well as some other userscripts that were having problems with the Vector skin.

As you can see those are quite a few roles that I am now active in and of course my time is limited. I'll try to do my best to alternate between those roles, so please be patient if you need my attention, but don't hesitate to ask me for help if you need it. You know the way.

Thursday, April 1, 2010

April fools' continues to fool

Wikipedia has developed this nice tradition that on April Fools' Day, content on the Main Page should be TRUE and link to actual encyclopedic articles, instead of being simple jokes. So today's Featured article, is on Wife selling and although the practice might come across as unbelievable, awkward and unrealistic, it is all part of our history. The Topics in the news are all recent news events, though not of the usual importance and the wording is more playful than on other days. Similarly, Did you know contains not a single lie. Lastly the Picture of the day, featuring a picture of a "GET FAT" advertisement campaign as a secret to beauty. Unthinkable perhaps in current times, but very real in 1895.

Just cliches, obfuscation and wordplay are used to trick the reader into making assumptions, that though understandable, are simply incorrect. The page is probably one of the most carefully prepared main pages of the entire year. All selections have to adhere to the same content rules about quality as every other day of the year.

What is most fun is how people react. Some people are truly upset that an encyclopedia would have material like this on its frontpage. Most of those people do not realize that everything on the page is true. Basically the editors are putting the joke on the "quick critics". The people with an opinion about Wikipedia, without truly knowing what and why they are critiquing. The rest of the people are confused and often enticed into reading. If they persevere, they will have a laugh or two and actually learn something. Journalists don't seem to be the best readers btw. Few seem to have actually clicked beyond the front page. 1, 2, 3, 4 Ah well, deadlines I guess. :D

I find it a great tradition and hope that it will be continue for years to come.
P.S. Wikipedia April Fools' main pages from: 2006, 2007, 2008, 2009.

Thursday, March 18, 2010

New Youtube interface

Today I was greeted with a new interface for Youtube. It seems that there are a lot more collapsible elements now, and the biggest functionality change seems to be a new "like" vs. "dislike" option, where we used to have the "Favorite" button. There are also new Share buttons, and there is a nice toggle for "Autoplay" of your recommendations. I'm not sure yet if I like everything, it seems to require a bit more work to be perfect, but with all the functionality of Youtube, this probably is a good thing.

Wednesday, March 17, 2010

Template editor

The Wikipedia Usability Initiative is finally making good progress on their template folding and template editor. Much of what the project has been doing with the edit screen has been in preparation of this work. The editor now folds complicated templates into a small block. One of the sandboxes the project uses now has the code deployed and it seems to be working quite well. Be aware that this is a development platform, and that browser peculiarities might not be fully dealt with yet. It is also NOT final.

The wiki editor with folded templates.

You can unfold the block, by clicking on the arrow to show the template code, or you can click the block and you are presented with a template editor that makes it easier to change the values of the template. This should be very helpful, because research showed that much of the trouble people had with editing Wikipedia, was the complex code on the edit pages. The template code is by far the most obscure and complicated code of all our wiki markup in my opinion. I suspect we will see more of these kinds of additional markup in the editor in the future (headers and links seem like a logical next step).

By clicking the folded Infobox template, you get this template editor.

You might be interested in this video that shows the experience some of the Usability Study subjects were having on the edit page a year ago.

Video On Wikipedia

This week at SXSW (South by Southwest Conferences & Festivals), the Open Video Alliance presented a new campaign and portal for video on Wikipedia. The project is called "Let's get video on Wikipedia" and available at The goal is to make it easier and more understandable how to upload video for usage in Wikipedia and is made possible by the Open Video Alliance, the Wikimedia Foundation, Kaltura, Miro and Mozilla Drumbeat. (Blog and press releases: Open Video Alliance, Miro, Wikimedia Foundation)

In some ways this project resembles a bit Wikiportrait, a project to help people upload their own portrait photo for usage in Wikipedia articles. Video On Wikipedia tells you what steps you need to take in order to create and upload a video for usage on Wikipedia. It also attempts to explain why uploading video for Wikipedia is different from uploading to most other places, a good bit of evangelism for Free and Open formats for information.

It helps people use the latest upload and display tools that have been developed by Michael Dale as part of the effort to improve video for Wikipedia. Not only that, but it also has a portal, that presents the latest uploads, editor's pick and most watched videos. The player of the portal uses the new HTML5 player that I recently blogged about, and you can comment on videos.

This is a great new development and hopefully it will continue to be developed and improved upon. The image on the left shows the welcome page of Video On Wikipedia and the image to the right the portal for recent uploads etc.

Monday, March 1, 2010

HTML 5 video player for mediawiki now with fullscreen support

Michael Dale has been working hard on a new media player for the mediawiki projects. This media player is based on the HTML 5 <video> tag. You can compare it to the demo players of Youtube and Vimeo and DailyMotion. It should support Firefox 3.5, Google Chrome 3, Opera 10.5 and if you install the Xiph QuickTime components it works with Safari 4 for the Mac. If your browser doesn't support HTML5, the player will use the JAVA cortado player, like it does in the old version of the Ogg player.

Recently both Apple and Firefox introduced Fullscreen support for the <video> tag in their development versions of the browsers, and these features can now be used with the new player for Wikimedia. The controls automatically show and hide, and you can even add and display subtitles with it.

How do I test it ?

It is rather easy, you go to this example video. If you want to enable it for all videos, you need to be registered on Wikimedia Commons or the English Wikipedia. You go to your preferences. Then select the "Gadgets" section. Now enable mwEmbed and Save.


The first image shows the player after the page has loaded. The second image shows the options for selecting and authoring subtitles. The third image is a movie with subtitles enabled. There are two modes for subtitles, either underneath the video, or drawn on top of the video.


This kind of work is exactly what was needed for Wikimedia. Focused development of advanced features. As a former VLC media player developer I follow the work with great interest, and occasionally report some problems that I encounter. It may seem easy to develop something like this, but I know how difficult it is and how much issues you need to take into account. This project started in January 2008 and really got going in August 2008. A lot of that time was spent preparing the MediaWiki software for the more advanced, dare I say, Web 2.0 type of functionality. Much of this mostly Javascript related work has gone parallel with the Usability project. Truly a big thank you to the developer Michael Dale and to Kaltura, which is sponsoring this development.

P.S. The work is far from finished of course. I'm sure more refinement is coming, and the authoring of subtitles is only just getting started. Still I find that having it enabled on a daily basis is a positive experience, even with the occasional glitch.

Community documentation for Wikimedia Mobile

As some may know, I have been working a lot on Wikimedia Mobile as of late. It's interesting to work on this software, because it has to support so many devices, languages and wiki's. So far the project hasn't been to good at informing the various Wikipedia communities, on how they can participate in making the mobile version of their community's Wikipedia. I have now started a draft of how to translate the software, create a mobile home page and how to do the redirects for supported mobile devices. When I have refined the information, I will probably move it to meta. If you have a better idea, please let me know.

Also, take a look at the documentation for readers.

Starting once more

I have tried it many times before, but I guess you have to persist. I find blogging difficult. I often spend too long on writing it and don't post often enough. Twitter is more my thing, because it is just short blurps. Still lately I have found that Twitter is not enough. I have ideas and comments that I feel I need to write down in more than 140 characters and many of them have to do with Wikipedia. So I'll attempt it one more time. Topics will mostly be Wikipedia, online rights and software development, but other issues might come up. Welcome everyone.