Thank-You VLC

Something that caught me by surprise was the release of libbdplus which happened almost exactly one year ago. This filled a gap in the free software community that had been open since 2007 when the first BD+ discs came out.

The story here is that Bluray discs won the format war against HD-DVD because they don't just encrypt their files with AACS. They include a diabolical piece of self-modifying code called BD+ which gained an early reputation for thwarting decryption efforts. For many years, open source Bluray decryption tools only existed for discs that were BD+ free. Those cracking tougher nuts had to use MakeMKV and AnyDVD which kept the source code hidden thereby making important knowledge vulnerable to censorship.

In 2009, when I first heard about VideoLAN's plan to develop libbdplus, the lack of a git repository was suspicious. Why would a group known for prompt code releases in all of their other projects suddenly decide to develop one behind closed doors? Especially the most anticipated advancement since libdvdcss. Years went by and rumours of an imminent release became less frequent. Not only that, but other BD+ projects ceased development because they saw no need to duplicate effort. By 2013, I was not just accusing the developers of changing their minds, but causing outright damage to free software in the process. The end of December 2013, when they released libbdplus after all, was the time for me to take it all back. But hey, it's Christmas... a time to be pleasantly surprised!

That Christmas, I also got into an argument with some Wikipedia admins and developers of the MediaWiki software who thought that it was okay to make search suggestions mandatory. I hate it when search boxes spawn a drop-down list and condescendingly try to predict what you are about to type. As soon as Wikipedia acquired this "feature", I navigated to the checkbox in Preferences > Appearance and disabled it. However, in MediaWiki 1.22 which came out in late 2013, the developers removed this option because only 112 active editors on the English Wikipedia were using it. This is about 1 in 300. While I admire the fact that they actually collected data, popularity is not the right criterion to use when dealing with options that are objectively good. Some points against suggestions are:

1. They are slow. The annoying boxes keep changing as you type with the help of your own CPU cycles. They are implemented in AJAX which hinges on the most inefficient of all programming languages; Javascript. Type one letter and it performs a search. Type another letter and it performs another search. If you type quickly on a slow computer, the suggestions cause a significant delay by the time you actually want searching to be done. The "why don't you just disable Javascript" argument is not a very good one. Features on Wikipedia that use smaller doses of JS are actually quite useful. The 112 people who felt the need to disable suggestions did so because they wanted JS, just not the stupid parts.
2. They violate web standards. The HTML5 autocomplete attribute defaults to on. This means that typing text is supposed to trigger a drop-down list of previous items that you have typed. Not previous items that someone else has typed. Here is a comparison between the two drop-down lists.
   
   
   You can see that the boxes cover the "Search" and "Go" buttons in the Wikipedia Monobook skin. These buttons stay hidden forver with the suggestion box because there is an endless list of things it can display. However, the history box goes away as soon as the query becomes different from one of your previous ones.
3. They use non-native widgets. Something else you can see above is that the suggestion box has a blue cursor (decided by them) while the history box has a purple cursor (decided by me). AJAX gets the worst of both worlds; it slows down your own hardware without being able to use a theme that blends into your system. Uniformity between interface elements should be followed whenever possible. This is why HTML standard bodies and browsers have worked together to make sure buttons, checkboxes and text inputs are rendered by the user's operating system. It looks ridiculous when websites bypass these to have a native text input spawn a non-native drop-down list. Some people have mentioned that Google does this too. Even though Google is hardly a role model, I should rush to their defence here. They use a non-native text input as well so the juxtaposition doesn't look nearly as bad. And besides, there is a little known way to disable search suggestions in Google.
4. They fly in the face of neutrality. This is my real problem with the feature, and something that seems lost on the Wiki admins. When I try to stay up to date on the politics of my country, I want to search for "Justin Trudeau". I do not want to see a list that includes "Justin Timberlake" and "Justin Bieber". And someone on the other side of the world will see a list full of American topics simply by typing "U". Being assaulted by a list of things that could be searched instead of what you intend to search lends bias to particular topics and this should be avoided on an encyclopedic site. Wikipedia is not a tabloid. If a celebrity wants to appear on the front page, there are supposed to be only two ways. The first is to do something truly newsworthy in order to appear in the world news section. The second is to inspire so much interest in the community that people write a world class article and get it through FA.

So when I suddenly noticed search suggestions with no way to turn them off, I went to the Village Pump to ask why. From there, a debate ensued and since not everyone knew about it, six people from the 112 joined in to agree with me. This debate continued on the bug tracker where the prevailing sentiment was to keep the code base as clean as possible. This invalidates the idea of adding search suggestions in the first place. If the devs really wanted a clean code base, they would've made the suggestions opt-in rather than opt-out. A small opt-out rate allows you to drop two or three lines of code while a small opt-in rate allows you to drop hundreds. Any time a feature has to be specifically enabled to be seen, a very small number of people are going to enable it.

Some people who wanted to hide the suggestions customized their Wikipedia profiles with a CSS hack. This was unsuitable to me for two reasons. Firstly, typing is still delayed because nothing stops the scripts from running when the drop-down list is hidden. Secondly, hiding the suggestion box does not bring back the history box so its strange absence is a constant reminder that you are using a cheap hack. Luckily there is a better hack that can legitimately turn off the suggestion code. With a bit of jQuery, the MediaWiki API can disable this and restore the search history feature as soon as the text input loads.

Wikipedia has a gadget repository for making these profile scripts pseudo-official. As soon as I figured out how to undo one crappy piece of Javascript with another, I set out to make the script into a gadget. Disabling suggestions in Preferences > Gadgets instead of Preferences > Appearance is not so bad. It took me awhile, but I eventually found an admin willing to add my script to the gadget interface, thus restoring sanity to Wikipedia. From his profile page, I saw that he was a developer of VLC media player. Coming full circle, this gave me two reasons to raise my hat to VLC for making it a very merry holiday season.