Commons app – our plans for the next 6 months

We are excited to announce our (tentative) plans for the Wikimedia Commons app for the next 6 months! ūüôā

A little background: The Wikimedia Commons app was funded via an Individual Engagement Grant (IEG) last year. Several new features and improvements were made to the app over the course of the previous grant. Examples include a list and map of nearby places that need photos (based on Wikidata), category suggestions based on the image title, prevention of duplicate uploads, and a new tutorial to educate new users on what types of photos should or should not be uploaded. 20554 new files were uploaded via the app during the grant period with an overall deletion rate of 15.74% (11.7% in the final two weeks after the new tutorial was implemented), and 3485 images that were uploaded via the app were used in Wikimedia articles.

While we are very happy with the progress made, users have requested many other improvements that we would like to make but were not able to fit into the scope of the previous grant. Thus we are proposing a renewal of the IEG in order to work on these. Highlights of the proposed improvements include:

Mock-up of the planned new UI
  • Enhancing the “Nearby places that need photos” feature by (1) allowing users to upload their image directly from a location on the list or map, with suggested title and categories based on the associated Wikidata item, and (2) displaying the user’s real-time position on the map to allow easier navigation to the location they wish to photograph
  • Improving user education by displaying Commons account and user talk notifications (e.g. picture nominated for deletion) in the app, adding a gallery of featured images, and adding various notices and explanations in the upload screen
  • A sleeker, more intuitive, and more interactive user interface – a floating action button for uploads, “Nearby places that need photos” in a tab alongside the user’s contributions, and a panel to display Commons account notifications and information about the nearest place that needs photos
  • Various technical and quality-of-life improvements, such as two-factor authentication login, multiple uploads, preventing overwrites, and fixing memory leaks and battery drain issues

 

We would very much appreciate feedback and suggestions on the renewal proposal. Please do take a look at it, feel free to ask questions and make new suggestions on the Discussion page, and/or endorse the proposal if you see fit. If you would like to be part of the project, new volunteers and additions to our diverse team are always welcome – please visit our GitHub repository or Google groups forum and say “Hi”. ūüôā

Advertisements
Commons app – our plans for the next 6 months

Wikimedia Hackathon Vienna 2017 & Prague pre-hackathon

Had a blast at the Wikimedia Hackathon in Vienna! ūüôā A few of us also got together for a pre-hackathon in Prague a few days before the start of the hackathon, courtesy of our hosts (Wikimedia Czech Republic).

Prague pre-hackathon

 

We worked together from the 12th to the 16th of May in Wikimedia Czech Republic’s co-working office. 5 days and several sv√≠ńćkov√°s later, we produced:

A map of nearby places that need pictures!

Every pin on that map is a Wikidata item that needs pictures. You can scroll around and browse, or you can select an item to get more information about it, or directions to it. (Many thanks to Mapbox for their API)

 

 

Also… a navigation drawer!

So very much better than using an overflow menu in the action bar. ‘Nuff said.

Users can now view the coordinates of their uploaded image, and date of upload.

Also, we added a logout option, and are now giving users the option of choosing how many of their previous uploads they would like to view on the main screen.

Flyers were created to publicize the app in the hackathon, videos were made, breathtaking sights were seen… oh, and Adam wrote a blog post covering the pre-hackathon, too.

Commons Uploader flyer

Wikimedia Hackathon Vienna

 

After a short break, we met up again (in Vienna this time!) for the Wikimedia Hackathon (19 – 21 May). While we possibly weren’t as prolific during the hackathon, some memories that stand out in my mind include:

  • Learning how to detect and fix memory issues in our app from Dmitry Brant (Wikipedia Android app team).
  • Introducing new contributors to working on the app – Adam Baso and Fitos made their first commits on our Android app¬†GitHub repo¬†(welcome guys!)
  • Being given UI help and pointers by Rita and Pau
  • The tremendous amount of support shown by the community during our¬†slot at the open mic and showcase ūüôā
  • Being taken around Vienna by Praveen and Tobias on the final night, including an amazing Italian dinner
  • Realizing that no matter how excited I am about a new patch, I should NOT push anything to production without going through beta (oops. sorry all those who crashed!)

 

Thank you

To the folks at Wikimedia Czech Republic (Vojtech, Jan, Petra, Martin, and others) who tirelessly worked to make the pre-hackathon happen, hosted us in their office, helped us with whatever we needed and showed us around Prague: Thank you.

To my team who put up with me at the pre-hackathon and hackathon (Neslihan, Vivek, Dinu, Tobias, Adam Shorland, John, and hopefully I haven’t forgotten anyone…): Thank you.

To the Wikimedia Hackathon organizers and scholarship committee, and the wonderful people we worked with at the hackathon (Dmitry, Rita, Johann, Pau, Adam Baso, Fitos, etc): Thank you.

It was all amazing, and I hope to do it all over again next year. ūüôā


The Commons app is free to use, no ads. You can download it here.

We are resolving a few bugs with the new improvements listed in this post, so the new features are currently only available in beta. Anyone can sign up for beta testing here. When the bugs have been resolved, the new features will be released to everyone.

Wikimedia Hackathon Vienna 2017 & Prague pre-hackathon

March 2017 update

Lots of new stuff in the app recently!

version 2.0

We finally released v2.0 of the app, after one and a half years in v1.x! ūüôā It felt appropriate, given that the app has changed considerably from the early version 1s, and has diverged quite a bit from the original legacy app.

Beta testing

With over 2000 active installs, we decided that we should migrate to using a beta version for testing new releases, rather than pushing directly to production and hoping for the best. Opt in at https://play.google.com/apps/testing/fr.free.nrw.commons

Notification if picture is a duplicate 

As requested on the Commons village pump, we implemented a check to see if the exact same image already exists in the Commons database, in order to prevent unintentional duplicate uploads. This was done by checking for similar SHA1 hashcodes using this API

 

Updated licenses and added option to select them in upload screen

Users can now select their licenses directly from the upload screen instead of just via Settings! This has been implemented via a drop-down menu underneath the title and description fields. CC-BY-4.0 and CC-BY-SA-4.0 have also been added to the available licenses to choose from.

New and improved UI

The UI has received an update, and is now in line with Material design guidelines. Also, a light theme has been added, which is more suited for daytime use. This can be accessed via Settings as shown below.

Updated Google Play store listing

Our Google Play store listing has received an overhaul, with a new description and new screenshots that reflect the current state of the app.

New volunteers

We would like to welcome first-time contributors Aditi Bhatnagar, Veyndan Stuart, Vivek Maskara,¬†and Neslihan Turan on board! ūüôā Many of the recent improvements in the app have been thanks to them.

New volunteers are always welcome. Join us at https://github.com/commons-app/apps-android-commons.

Prague pre-hackathon and Vienna hackathon

We will be sending a team to the Wikimedia Hackathon Vienna to work on improving the Nearby function of the app, and development will start during the Prague Pre-Hackathon that Wikimedia Czech Republic has kindly organized for us. More details in our discussion thread.

March 2017 update

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 CategorizationFragment.java 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 CategorizationFragment.java.  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 (October)

Things have been pretty crazy lately. I’ve been scheduled for dental surgery, and will likely be moving to Australia in a couple months’ time, with all the necessary preparations yet to be made! On the bright side, an exciting new development for the app – a few folks have expressed interest in coming together to work¬†on new features for the app during the¬†Vienna hackathon next year, so we’ve been trying to make that happen.

3 new features in the app:

Option to copy title and description from previous upload (#65). A button was added to allow users to use the same title and desc as the previous upload, to make it more convenient for people who upload several images of the same topic consecutively.

ieg-copy-title-desc

Suggest categories based on entered title (#43). In addition to suggestions for recent categories and nearby categories, we have added a new type of suggestion: title-based categories. A search is performed for categories matching the title that the user has entered for the image, via asynchronous queries to the Commons MediaWiki API. This is the same API call used for the category search tool.

An issue with this implementation is that it is subject to the same limitations as¬†the category search tool. For instance, it works well for simple titles such as “pancakes”. However, if someone titles their image “Nintendo sign at Tokyo branch in Taito”, it searches for that exact string instead of searching for “Nintendo”, “sign”, “Tokyo”, “branch” and “Taito”. This issue has been documented at #306. Solving it would likely require substantial language processing capabilities (splitting into words, extracting keywords, etc), so it will have to be left for future work.

ieg-title-cats

Filter out year categories (#47).¬†Categories such as”X in 2006″ are very unlikely to be appropriate, so¬†we have filtered out categories containing 4-digit numbers¬†starting with ’19’ and ’20’ from all category suggestions. An exception is made for categories containing the current year or previous year. E.g. if a user searches for “Burning Man”, he¬†should¬†see a suggestion for ‘Burning Man 2015’ but not ‘Burning Man 2005′. The rationale for this design choice is that people are unlikely to store more than 2 years’ worth of pictures in their phone. So if someone has pictures of Burning Man on their phone, it is likely to be for the 2015 or 2016 event, not for 2005 etc.

We are open towards the possibility of use cases that we have not thought of, though, so please feel free to chime in in GitHub issue if you disagree with our rationale.

IEG Update (October)

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.

ieg-nearby-listview

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:

Completed

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.

ieg-back-button

 

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)