October 2011 Coding Challenge winners

Translate This Post

In October 2011, we tried a new experiment in attracting volunteer developers and advertising opportunities to get involved with Wikimedia’s open source codebase. The October 2011 Coding Challenge invited developers to submit projects in three categories:

  • Mobile Wikipedia: Uploading images and other media via your smartphone
  • Slideshows: Showcase Wikipedia’s beautiful multimedia
  • Realtime: Surface changes to Wikipedia’s content more dynamically

While we received lots of interesting submissions in all three categories, ultimately we had to pick three winners. The grand prize winners in each category get to attend a 2012 Wikimedia event of their choice at our expense. Two runners-up in each category are receiving a certificate of excellence acknowledging the high quality of their submission.
The submissions were reviewed by three judges: Tomasz Finc, Brion Vibber, and Timo Tijhof. Many thanks to all three for offering their time. Without further ado, the winners:

The "Upload to Wikimedia Commons" app is a straightforward, fully functional uploader for Android smartphones

Mobile

The winning submission is Upload to Wikimedia Commons” by Michiel Minderhoud (User:Michiel1972). It’s a fully functional Android app which makes it easy to share any picture taken on a smartphone by using the “Share via” menu.
What impressed the judges most about this implementation is that it just works, including the fact that it’s already available in the Android market for easy installation. The app source code is available on GitHub for anyone who’d like to participate in its continued development.
We’d like to also recognize two excellent runners-up:

  • Thomas Pellissier Tanon (User:Tpt) created the Mobile Upload Wizard building on the code of the Wikipedia Android app. While not a complete experience yet, the choices of architecture and workflow, and the quality of the completed pieces of implementation, merit its recognition as an excellent submission.
  • Linas Valiukas created WikiShoot, an iOS app “to take photos of unphotographed locations and upload them to Wikimedia Commons”. Like the previous submission, it doesn’t provide a full upload experience yet, but has a nice implementation of selecting locations and photos, as well as a great workflow document.

 

Michael Müller's "mostEdited" lists not only articles, but specific sub-sections which are being frequently modified.

Realtime

The winning submission is mostEdited” by Michael Müller (User:Schnark), which “shows you a list of those pages that were edited many times in the last hour (or any other period). These pages seem to be interesting to other users just now, so they are probably interesting to you, too, at least some of them.” The judges recognized Michael’s work as a great foundation for “condensing ‘interesting activity’ out of a raw Recent Changes feed.” The code is available as a user-script on-wiki; Michael also maintains a sizable libraryof user scripts on his German Wikipedia userpage.

  • John Du Hart’s LiveEdit extension gives a visual indication (by highlighting the edit tab, and showing a balloon tip when mousing over it) that another user has recently attempted to edit the page you’re on. This can help to avoid edit conflicts, and beautifully fits the theme of “Making Wikipedia More Alive”.
  • Omar Ziranhua’s project builds on the wikistream codebase and makes innovative use of node.js and the IRC feeds of recent edits to notify the user about changes to the page they’re on. A bit complex to set up and use, but an interesting use of the underlying open source technologies.

Slideshow

The winning submission is the slideshow script by Marian Beermann (User:Phiarc). It’s a very elegant implementation which, when installed, adds a “Slideshow” tab which appears only on articles with images. The tab triggers a scaled up lightbox view of images in the article, as well as any images included in a linked-to Wikimedia Commons category. The images are captioned as in the article. Other features include a mobile viewing mode, user preferences accessed via a “slideshow settings” dialog, and keyboard navigation.
There were two really great runners-up in this category, too:

  • Magnus Manske, who is known for creating the very first PHP implementation of Wikipedia’s software, as well as for many other inventions, created wikiPic, a true labor of love. It adds a menu when mousing over an image which makes its various features accessible. Its slideshow feature tries to identify files, using a variety of characteristics, which are similar to the current one, and displays up to 50 of them in a lightbox mode, and optionally in a full-screen mode. A really beautiful implementation and worth trying out.
  • Aleksejs Popoffka submitted a really lean implementation of a slideshow viewer. It also adds a tab, and is a lot less feature-rich than Magnus’ or Marian’s implementation, but quickly and simply pulls up large, lightboxed versions of images in an article.
Once activated by clicking the "Slideshow" tab on an article with images, the user script allows the viewer to comfortably see larger versions of those images.

More coding challenges?

This was the first-ever Wikimedia coding challenge. We’re really impressed with the effort and love that participants have put into these and other submissions. We’ve made many connections through this process with developers we’d otherwise never have interacted with, and have received concrete and useful additions to the corpus of software which enriches the user experience on Wikimedia sites. So overall, this has been a resounding success.
But there are always things we can improve. In future iterations of this, we’d love to aim for:

  • More teamwork. The model we tried was designed for a one-submitter-per-submission approach, but we think we could have created more sustainable momentum by inviting folks to work together on specific approaches that are identified ahead of time through a “project pitches” phase.
  • More public feedback. While we’ve sent feedback to the winning submitters, some parts of the process (like viewing submission details) were private by default, only visible to judges. This was to ensure that judges can express honest and explicit views without accidentally offending submitters, and to protect the privacy of submitters, especially if they don’t end up in the final lot. But all things considered, a very public review process would probably have lots of advantages that outweigh those considerations.
  • Better tips to get started. The newly created gadget kitchen was heavily utilized by many people new to user script development, and we’ll need (and are developing) more comprehensive training materials and tutorials for all parts of the MediaWiki ecosystem.
  • Faster turnaround. In the end, it took us too long to review all the submissions, which is partially owed to the bottleneck-y review process and could be mitigated by a more public approach.

Did you (try) to participate and have some feedback? Let us know in the comments!
Big thanks to everyone who made the challenge possible, including Greg DeKoeningsberg, Sumana Harihareswara, Jeroen de Dauw, Sam Reed, Tomasz Finc, Brion Vibber, Timo Tijhof, Dana Isokawa, Heather Walls, Brandon Harris, Roan Kattouw, Trevor Parscal, and Alolita Sharma.
Finally, to everyone who participated: Thank you. We hope you’ll continue your involvement in Wikimedia and MediaWiki.
— Erik Moeller
VP of Engineering and Product Development, Wikimedia Foundation

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

5 Comments
Inline Feedbacks
View all comments

I just tried a couple of these, and they’re great. What’s readily apparent though: the user experience of installing these scripts sucks! It would be really nice if there was a cleaner, more elegant way to try out some of these cool new gadgets, rather than having to edit your common.js like this.
At the very least, there should IMHO be a WMF-sanctioned page describing the process as nicely as possible, that userscript authors should link to. Following instructions from someone you don’t know, to install custom javascript feels wrong…

Hi Steve, there’s already a mechanism for managing user scripts built into the software, called “Gadgets”. Great user scripts can be promoted to gadget status, which makes them available in user preferences for easy selection. See http://en.wikipedia.org/wiki/Wikipedia:Gadgets for details. That process is definitely a bit complicated, and we’re aiming to improve management and code-sharing for gadgets soon. If you’re interested, you can read more about future plans regarding gadgets/user scripts infrastructure here: http://www.mediawiki.org/wiki/RL2 and test the current implementation here: http://www.mediawiki.org/wiki/RL2TEST I’d say a good design goal would be to make it possible for any newbie developer to get a user… Read more »

I can’t understand this jury: Why User:Phiarc’s slideshow won!?
* It queries full-size images. Not possible to view within an appr. time with my connection!
* It uses wrong path!
http://upload.wikimedia.org/wikipedia/commons//c/cb/Collision_of_Costa_Concordia_DSC4191.jpg
Notice the “//”

“It queries full-size images.”
If so, then that’s bad. Use thumb.php to for dimensions fitting max into the user’s monitor.

Wow, they must be proud! 🙂