#MediaWiki - #MediaViewer rehashed

Some things are plain stupid, sometimes I am and sometimes someone else is. I filed a bug about my experience of the MediaViewer. For me it is a show stopper; it prevents me from using it easily.

The problem is that Chrome shows a really awful URL for an image with funny characters in its title. When I look at it using the MediaViewer it is bad but it looks fine when I look at it from the Commons page.

• File:%C3%89cole_normale_sup%C3%A9rieure_de_Paris,_26_January_2013.jpg
• File:École normale supérieure de Paris, 26 January 2013.jpg

According to the Bugzilla triage I must be stupid because it works; it complies with specifications and, indeed technically it works. It just stopped working for me.

Several reactions are possible. My choice was to shrug, mutter "it is the user experience stupid" and I got on with my life. Others find it a precursor to the invasion of an evil overlord who does not understand the world and prepare for war.

By filing a bug, by posting this blog I have rid myself of my frustrations. I know several developers; I met many of them at Wikimania and I know they are really dedicated and mean well. I also know that such things pass. I am sure someone will see the light or Google will fix Chrome (if that is where the bug lives). In the end I do not look at images that often as a result.
Thanks,
       GerardM

#Mediawiki - the #Media viewer

The #Wikimedia Foundation has a problem with people accepting new functionality. The reasons why are often irrational and steeped in conservatism but that is another story. A blog post does not help much at that.

What may help is the assessment of bugs. In bug 68372 it has been identified that in certain browsers a name like MilutinDostanić.jpg will show up properly in the URL when seen from Commons and not from within the Mediaviewer. The Mediaviewer will show it like MilutinDostani%C4%87.jpg.

Technically, technically there is nothing wrong with that. From a user perspective it looks like shit. When a bug is closed because technically there is nothing wrong and a difference in behaviour is not considered as being of enough relevance, a user gets pissed off.

When bugs are reported and when user acceptance is important, differences between expected behaviour and actual behaviour become important because they are often what prevents acceptance of new functionality.
Thanks,
     GerardM

#Commons and #Wikidata - the architecture of the #Wikimedia storage of the meta data of #media files

Commons was created to centralise the storage of media files. When it started, MediaWiki was not able to use any media files in any Wikipedia, that came later. Only those files that could be used everywhere were included. As a result, strict rules are applied and the copyright laws of the whole world are considered.

Commons is scheduled to be included in the scheme of Wikidata. This is easy and obvious for much of the meta data that is involved. It will include for for instance the Mona Lisa who the artist is and, what institution takes care of that most famous painting. This information will be available in every language and when the labels have been added, it will be properly readable and searchable in that language.

With Wikidata integration, the data is no longer strongly associated with the "page" of the media file. Effectively it does no longer matter where the media file is located. What matters is that media files are annotated with Wikidata technology. As this strong association will no longer exist, it is possible to change the outlook from a Commons integration project to a media file integration project.

Some use-case scenarios:

• a file has been marked for inclusion into Commons on the English Wikipedia because it fits the Commons criteria
• a file has been marked for deletion on Commons as it no longer fits its criteria. It does fit the criteria for "fair use" on the English and other Wikipedias
• a GLAM is interested to share its meta data and welcomes viewers of its media files that cannot be used in Wikimedia projects because of copyright restrictions

With a Wikidata integration it is just a matter of managing the values in the meta data. Many more media files will become available as a result of one common approach. The management of all this data will become easy and much more effective.

From a storage point of view, things will also become easier; all media files will need to be stored only once. The meta data of those files becomes available in any language and, the meta data will remain available even when the media file no longer is. Files restricted in a Wikimedia context may still be available through external sources.

Effectively a global approach to all media files will make us more effective in sharing them as part of the sum of all knowledge.

Thanks,

       GerardM

#Wikimedia #Multimedia Features/Vision 2016

Having a vision of what the future may have in store is wonderful. Watch the video and, you are bound to like what you see. What it describes are "user stories", stories that describe how people will actually use multimedia and what functionality they will have available to them.

The stories are to the point, they indicate functionality that will foster a sense of community. These stories do not represent the complete vision for Wikimedia Multimedia Features for 2016.

• a Guarani class room where children use Commons pictures because they can be found in Guarani
• an Indonesian GLAM conservator who uploads images with its meta data that is of interest to a Dutch audience
• a blogger who uses freely licensed images because he can find them at Commons

The integration of Wikidata technology in Commons will make these three user stories a reality. The start of the software development is scheduled for the second half of 2014. The development of the data needed to support this project began a year ago with the start of Wikidata. All the statements and labels that are added will be leveraged when Commons becomes accessible to a world that does not understand English.

Thanks,

     GerardM

On project management and the Wikimedia Foundation

I have been reading the blog of Guillaume Paumier, the project manager for the Multimedia usability project. Reading it, I am of two minds.. it is tagged as his personal opinion but on the other hand, this is the opinion that he promotes. The question is should I analyse and critique it or not and, to what extend and where.

As a blogger, Guillaume is the opposite of me. I do not use bold, I use illustrations. Thinking on projects, I prefer the scrum approach for the Wikimedia Foundation because the WMF has a track record of waterfall projects that have not delivered on time. Main advantages of scrum are more visible results and consequently easier communication with our communities.

In Guillaume's view a project manager decides on what to do when. Having a keen interest in scrum, I have a problem with this, for me it is the customer who decides what gets done when. NB Customer as understood by scrum. There is one KEY problem though; there is nothing in our communities, in our organisation that serves the role of customer. The result is that the WMF may be doing well but it is increasingly seen as an ivory tower.

When I query his blog there are two words missing: language and culture. Given that translatewiki.net supports 327 languages, it is unlikely that anyone can truly appreciate and predict the needs for software that is to accommodate all these languages. I am really looking forward how Guillaume intends to deal with linguistic and cultural issues. This is maybe a good subject for his next blogpost.

The Usability Initiative did a good job by promoting the localisation of its software and setting up test environments for languages in several scripts.

Finally I disagree with Guillaume that there are no people in our community who fulfil a role of project manager. They do not have the title but they have taken the burden of that role.
Thanks,
GerardM