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.
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.