Commons app – Version 2.8 beta

Apologies for the long break between releases – we have been busy working on fixing an issue that many users were reporting with failed uploads, and we are thrilled to announce that we may have finally solved it! ūüôā Additionally, Wikidata integration is now complete, with uploads via Nearby Places automatically editing the p18 property of the associated Wikidata item. There are several other new features, including two recently-completed GSoC projects that we mentored – users can now browse other images on Commons, and view their achievements and upload statistics.

Please feel free to register for beta testing if you would like to help test v2.8. If you experience any bugs or crashes, or if you find any aspect of the new features to be unwieldy, please do let us know on GitHub.

Important bugfixes

Failed uploads

Over the last two months, we have attempted to debug and solve a problem reported by many users – that their uploads consistently fail. We had a lot of difficulty reproducing the problem, figuring out what caused it and obtaining the information needed to fix things, and we almost had to revert the new 2FA feature as a last resort. But we finally have a solution that fixes the problem for our testers (while still keeping 2FA intact), so we hope this works for everyone else too!

For those experiencing this issue, please register for beta testing and update to version 2.8, and let us know if it does not solve the problem for you.

Crashes during upload

We have also fixed a longstanding issue with users occasionally crashing halfway through an upload.

New features

Wikidata p18 edits via Nearby uploads

The “Nearby places that need pictures” feature works by searching for Wikidata items that are located within a certain radius of the user and are missing the p18 property. Now, when you upload an image to a pin on the Nearby map or list, the image will be automatically added to the p18 property of that Wikidata item. ūüôā

To illustrate the workflow, we will again use the example of Queen Street Mall, a Wikidata item that lacks a photo:

  • I selected the “Queen Street Mall” pin on my Nearby map and tapped the camera button on the right side of the screen
  • I took a photo of the mall, and the title and description fields were automatically filled for me based on the properties of that Wikidata item
  • I tapped the arrow button on the upper right, and selected categories based on the suggestions given
  • After the upload completes, I check the Queen Street Mall page on Wikidata, and find that my image has been added to the “image” property
  • After refreshing the Nearby map, the Queen Street Mall pin is gone, because it now has a photo!

This feature is in its infancy, so we are keeping tabs on Wikidata edits that have been made via our app here.

Browse other images on Commons, including featured images, via “Explore”

The “Explore” feature is a GSoC project by Ujjwal Agrawal, mentored by Neslihan Turan and Nicolas Raoul. It builds on top of the “view featured images” feature that we had recently implemented, adding the search function to view other non-featured images. Featured images are displayed by default, but all images in Commons can be viewed by searching for a title or a category. More details about an image can be viewed by tapping on it.

View your achievements and upload statistics

The new “Achievements” feature is part of a GSoC project by Tanvi Dadu, mentored by Vivek Maskara and myself. Accessible by tapping on the “trophy” icon next to your username, you can view your images uploaded, % of images not deleted, and images used, all of which are used to calculate your level.


Quiz for users with high deletion rates

Also part of Tanvi’s GSoC project, this feature aims to help educate users who are found to have excessively high revert rates. A quiz will pop up for them in the app, and they can see the correct answer immediately after attempting a question.

First-run tutorial for Nearby Places

Based on feedback from new users, we have designed a short first-run tutorial explaining the Nearby Places feature.

Upload stats for 2018

We have a record high number of uploads via the app in 2018 Q2, with only a small fraction of them requiring deletion. \o/ Thank you all for your contributions! (Source: Commons app stats courtesy of Yusuke. 2018Q3 still in progress.)

Commons app – Version 2.8 beta

Commons app update: version 2.6

Our Individual Engagement Grant has been renewed! ūüôā Thank you so much to everyone who supported our application – reading all of the wonderful comments has been extremely meaningful and encouraging for us.

We have been hard at work getting version 2.6 of the app out; there was a bit of a rocky start with the first few beta iterations, but we finally have v2.6.5 in production! \o/ Improvements in the current version include:

New UI

  • A brand new login screen
  • New design for the list of nearby places that need pictures
  • New navigation drawer design with username displayed
  • The upload screen has been remodeled to include tooltips for title and description fields, as well as an explicit copyright declaration and a link to Commons policies
  • Improved media details view with links to the selected license, categories and image coordinates

Category search

  • Fixed common issue with category search getting stuck forever
  • If a category has an exact name entered, it will be shown first
  • Added filter for irrelevant categories

Nearby Places that need pictures

  • Fixed issues with GPS that was causing “No nearby places found” errors
  • Improved handling of the refresh button


  • Added product flavors for the beta-cluster Wikimedia servers – this allows developers to test most of the features in our app without having to upload test pictures to the actual Commons server
  • Added RxJava library, migrated to Java 8
  • Switched to using vector icons for map markers
  • Added several unit tests
  • Converted PNGs to WebPs to reduce APK size


  • Modified About page to include WMF disclaimer
  • Modified Privacy Policy link to point to our individual privacy policy
  • Switched to using Wikimedia maps server instead of Mapbox for privacy reasons
  • Removed obsolete EventLogging schemas from app¬† for privacy reasons

Misc improvements

  • Fixed crash when using the camera
  • Reduced memory leaks and battery usage
  • Multiple fixes for various other crashes/bugs
  • Various improvements to navigation flow and backstack
  • Added option for users to send app logs to developers to help us troubleshoot any problems they are experiencing (has to be manually activated by user)

Facebook page

We have created a new Facebook page that we will be posting updates on!

Stats for 2017

The end of 2017 is nigh and the stats are in! Roughly 24,000 new images were uploaded via our app this year, and only a fraction of them required deletion. ūüôā



Coming up next….

We are also currently in the process of implementing a few major new features that we anticipate will be included in our next release:

  • A new and improved Nearby Places UI with hybrid list/map and bottom sheets for individual places
  • Direct uploads from Nearby Places with relevant title, description and categories suggested
  • Two-factor authentication login

Happy holidays, and stay tuned! ūüôā

Commons app update: version 2.6

IEG Update (November)

Not an easy month, what with relocation issues and dental surgery that ended up with complications. ūüė¶ Also, the headers task did not turn out quite as expected.¬†On the bright side, we’ve completed the new tutorial!

Add page to tutorial to educate new users on what types of images are useful (#95).¬†The existing tutorial was elegant, but lacked detailed information on what types of images users should or shouldn’t upload. The number of deleted images (selfies/copyvios) currently uploaded via our app is already within acceptable bounds (see here), but we would like to try and reduce it further.

So, we added new pages to the tutorial with examples of ‘acceptable¬†uploads’ and ‘bad uploads’, as well as an example of how to fill in the form fields for an image.¬†The new tutorial is¬†based on a draft of the Commons section of Pine’s educational video script, and modified to better accommodate issues specific to mobile app uploading.¬†It was released on the 7th of Dec under the¬†Apache 2.0 license (same as the app), and the new pictures used in the tutorial were taken by myself and Nicolas Raoul, and released under Public Domain license.


tutorial-1 tutorial-2 tutorial-3 tutorial-4 tutorial-5

Headers to distinguish where suggestions come from (#76). I spent 2 weeks on this, trying multiple methods. The first method involved simply adding the section headers to the ArrayList that is used as the data source in the adapter. So now our data source contains not just CategoryItems but also header items. Unfortunately, in most of the existing code assumes that every item in the data source is a Category, and operates on it accordingly. Also most of the existing methods rely on using the index of an element in the ArrayList for category selection, assignment, etc. With headers being part of that array, we would have to keep checking for getItemViewType(position) whenever we want to perform any operations on categories, unless we wanted to do an almost complete refactor of  I figured that, instead, I needed a pure UI solution that leaves the data source untouched.

The second method that I tried involved using the open-source CWAC Merge Adapter library, which successfully produced headers for GPS, recent, and title categories without impacting the data source. However, in order to get this to work, I had to create a separate adapter for the empty search field (which displays automatically-generated GPS, recent, and title categories along with their headers), and for the non-empty search field (which displays the results of a manual category search with no headers).

In the app currently, selected categories are aggregated and displayed at the top of the list, from any type of category suggestion (manual or automatic). This is really useful and something I don’t want to lose. But with two separate adapters, I can’t seem to get this to happen anymore – selected categories remain selected but are only displayed in their respective adapter (automatic categories that are selected only display when search field is empty, manual categories only display when search field is not empty).

At the end, I decided that I was back at square one, and the amount of work needed for me to complete this task was¬†exceeding the benefits that it would bring (headers would be really nice but I don’t think it is a dealbreaker for most users). I decided to leave the task¬†and the branch containing my existing code¬†open, and move on to the next task.



IEG Update (November)

IEG Update (September)

This report’s a little early, as I’ll be on vacation from the 20th of September to the 3rd of October. ūüôā But still,¬†lots of stuff has happened since the last one! For one thing, Nicolas passed on the role of app project maintainer to me, as he has been busy with Wikidata projects recently (he plans to remain¬†active and involved with our app, though). There’ll definitely be a huge learning curve involved, but hopefully I’ll do the role and the project justice.

Also, we now have a brand new website – thanks for creating it, Tobias!

Two new features in the app:

Display nearby wiki articles lacking photos (#73)

We now have a list of nearby places that need photos – it¬†pulls locations without photos from a file maintained by the Wiki Needs Pictures project and arranges them in order of proximity to the user’s position. Tapping on an item in the list brings the user to their phone’s map app with the coordinates pinned. To access this feature, select ‘Nearby’ (or the icon of a guy with a flag) from the action bar (menu) of the app.


There’s certainly plenty of room for improvement in this feature¬†–¬†the¬†current implementation is a very basic version, as I was hoping¬†to gauge users’ response and feedback before working on any enhancements. The art for the icons has been kindly provided by Brian MacIntosh¬†on Commons – thanks!

Add geocoding template (#35)

If uploaded photos are geotagged, the coordinates are now sent to Commons via the geocoding template. ūüôā Hopefully we are approaching feature parity with the web-based Upload Wizard with this improvement.



IEG Update (September)

IEG Update (August)

Phase 2 has begun, and I’ve been working on the newbie-friendly enhancements and new location-based features for the app. Below are summaries of the tasks I have completed or are working on this month:


Allow account creation from within the app itself (#48).¬†The ‘sign up’ button previously redirected¬†users to their browser, which breaks flow and poses a bit of an inconvenience. Initially the plan for this task was¬†to embed account registration in the app¬†programatically, but this turned out to pose¬†several challenges that would have significantly increased the # of hours needed to implement this feature if we went that route.

Eventually, we decided to just embed the Commons mobile registration URL in a WebView,¬†and override the ‘success’ page to bring users back to the login screen of the app. This approach appears to be the best of both worlds – we can use the Commons web registration system (so it will automatically update with any changes made to the system), but¬†flow isn’t broken and the user doesn’t need to switch back to the app from the browser.

ieg-create-accountWarn users if they submit image without selecting categories (#61). A dialog was implemented to warn users if they attempt to submit an image without selecting any categories, and to stress the importance of categorization. The user still has the option to choose to continue with submission, as some people might prefer to add categories later.

ieg-no-categoriesWarn users if they press back button without selecting categories (#58). Pressing the back button on the category screen by mistake will irreversibly take the user back to the main screen without allowing them to select categories, whereas the upload has already begun. A dialog was implemented to ensure that leaving the category selection screen is intentional and not by mistake.



In progress

Add page to tutorial to educate new users on what types of images are useful (#95). I have been talking with Pine about the possibility of collaborating on the tutorial, and the plan is to re-use his educational script for Commons as the basis for our tutorial. As his script is not yet complete, this task has been pushed back a little and I have moved forward with the location-based features while waiting.

Display nearby wiki articles lacking photos (#73). This task is currently in progress. I am working on implementing a list of nearby places lacking photos, drawing from a CSV file that is maintained by the Wiki Needs Pictures project. I’ve hit a few snags, but substantial progress has been made and I estimate that this should be done in 1-2 weeks.

Add geocoding template (#35).¬†This task is next on the list if Pine’s scripts are not yet ready for the tutorial task.


All in all, some minor changes and setbacks, but all seems to be going reasonably well. Looking forward to getting more new features in! ūüôā

IEG Update (August)

List of tasks completed or in progress (Phase 2)

I will be updating this post periodically with the tasks that I have completed or am currently working on for Phase 2 of the IEG project.

2(a) Make app more newbie-friendly – (5.5 wks)

  • Allow account creation from within the app itself (#48) –¬†Completed, released
  • Warn users if they submit image without selecting categories (#61) – Completed, released
  • Warn users if they press back button without selecting categories (#58) – Completed, released
  • Add page to tutorial to educate new users on what types of images are useful (#95) – Awaiting Pine to complete Commons module so we can re-use

2(b) New location-based features – (5 wks)

  • Display nearby wiki articles lacking photos (#73) –¬†Completed, released
  • Add geocoding template (#35) –¬†Completed, released

2(c) Enhance titles and categorization – (6 wks)

  • Option to copy title and description from previous upload (#65) – Completed, released
  • Suggest categories based on entered title (#43) –¬†Completed, released
  • Filter out year categories (#47) –¬†Completed, released
  • Headers to distinguish where suggestions come from (#76) – In progress
List of tasks completed or in progress (Phase 2)

IEG Update (July)

We are experiencing what I would term as ‘a good problem to have’. One of our measures of success was a 50% increase in active installs, compared against the benchmark of 217 active installs when my grant was approved. It was anticipated that we would only hit that mark after the publicity phase (Phase 3). However, it is only 3 weeks into the grant, and we’ve already exceeded that!¬†ūüėģ¬†We now have 337 active installs and counting.

Why is that a good ‘problem’? Well, due to the nature of how Android works. Unlike iOS, which is fairly standardized (AFAIK iOS devs only need to target one version and one type of hardware at any time), Android is a much more multifaceted beast. OS updates are not mandatory, so many manufacturers don’t push Android updates to their devices, especially older ones. As a result, the more users you have, the wider the variety of Android versions and hardware your app runs on, and the higher the potential of things breaking. Also, of course, more users try more things that you wouldn’t have thought of.


As you can see from the pie chart, our users are split between several versions. The most popular are Android 6.0, Android 5.1, and Android 4.4. Those are all very different and code that works for a particular version might not necessarily work for another. Also, the existing code for the app is fairly old (from a few years back), so several changes needed to be made to make it compatible with the newer versions of Android. The runtime permissions feature introduced in Android 6.0 in particular has been the source of several bugs.

My initial plan for Phase 1 did account for the possibility of a few new crash reports coming in… but I hadn’t accounted for anywhere¬†near the number that actually did come in. As a ballpark figure, about half of the bugs that I have fixed¬†so far were reported after the start of the grant. As a result, as Phase 1 draws to a close, I find myself needing to prioritize new bugs that were causing significant problems for multiple users (like the API 23 camera bug and the Google Photos bug), and having to potentially put aside¬†some of the less-serious bugs that I was initially intending to fix (for instance, my pet peeve bug is¬†Newly uploaded picture replacing some of the other pics (in My Uploads page)¬†, but that hasn’t yielded any success after spending a few¬†hours on it, and no other users¬†have complained about it).

There is still about a week left in Phase 1, and I will do the best I can to fix what I can manage. Ideally, I would be able to fix everything. But unfortunately, realistically I think that would be unlikely before I have to move on to Phase 2. ūüė¶

Update 29th July: Moving on to Phase 2 as planned. Most of the major bugs have been fixed in Phase 1, so fingers crossed that the new users that we are acquiring on an almost daily basis do not experience much trouble with the app.


IEG Update (July)