Plans for 2018 - WMCZ proposal

[misaochan]

As some of you may know, Wikimedia Czech Republic has kindly offered to include us in their grant proposal for 2018 funding. :) We will need to come up with a list of improvements that we intend to implement in 2018. @VojtechDostal has informed me that their proposal is due on 1 Oct 2017, so we will need to "finalize" the list by the end of September ideally.

Feedback on the proposed improvements, as well as suggestions for new improvements, are most welcome. The scope will be for 10 months of development (most likely by the same team as the renewal proposal), starting March 2018 and ending Dec 2018. Development time must also include time needed for fixing bugs and issues with implementation, as well as for mandatory reporting.

Legend:
[HP] - High-priority improvements
[Optional] - we are currently undecided on whether we should include these

User-focused improvements

Further Nearby enhancements

• [HP] Edit Wikipedia article to include image that was just uploaded In Contributions list, add an icon for images uploaded via Nearby that allows users to use that image in associated Wikipedia article(s) #872 - as discussed in Upload a picture directly from list of nearby places needing photos #252, we might want to allow the user to edit the associated Wikipedia article to add the image, after the user has successfully uploaded a pic for a Wikidata item. This would complete the "chain" of seamless workflow after the other improvements at Upload a picture directly from list of nearby places needing photos #252 are completed during the renewal - users can browse the places that need photos, select one and move to the location, directly upload the photo after taking it (with suggested titles and categories based on the Wikidata item), and THEN add it to the Wikipedia article that is associated with that item. We could see if the Wikipedia app allows us to do that, or otherwise link to the web view, or we could also implement the functionality in our own app if other options don't suit. Considerations: we must include a tutorial on how to do so, we must consider the user's Wikipedia language version as well as how to implement the UI in a clean manner, and we should log the edits that are made via our app to ensure that we aren't vandalizing articles.

• [HP] Android system notifications - There are currently 2 different suggestions for this, Send system notification when user is close to a location on the Nearby Places list #79 and When user takes a photo, send push notification - "Is this a picture of A/B/C? Is it in administrative area D/E/F? (then link Wikidata/Commons)" #259 . The former triggers when the user is close to a location on the Nearby list, whereas the latter triggers when the user takes a photo while close to a location on the Nearby list. We can implement either one, or both. Input would be very welcome on the pros/cons of either. These notifications should be opt-in.

• [HP for compass] Improve map navigation - implement compass and routing to minimize the need for user to switch to their map app

• Localize the Nearby map/list Localize nearby map #669

• Allow user to manually select a location for Nearby search Allow sharing of location for Nearby search from other apps #537

Others

• [HP for ads] Add campaign support Show news about ongoing campaigns/competitions #78 Add support for campaigns #545 - There are varying levels of "support" possible, ranging from simply displaying news/ads for ongoing campaigns, to full integration that allows users to submit photos for the competitions directly through the app. Personally I would start with the former, and wait and gauge the response before trying for the latter. While a central app for submitting WLM, WLE, etc submissions sounds great, AFAIK the winners and perhaps even most of the participants of such competitions might primarily use DSLRs and not mobile phones?

• Peer review for images submitted by other people Peer review - review the latest pictures uploaded by other people #780 . This could help relieve the burden on Commons volunteers (and help increase our acceptance by the Commons community, which has been a long hard road thus far ;)).

• [HP] Add limited connection mode Add limited connection mode #746 - This would be especially useful for travelers, which is a big target demographic for our app

• [HP] Badges & light gamification Feedback on how my pictures get used: Statistics, barnstars, light gamification #85 - There were many suggestions for this during the pre-hackathon and hackathon. Badges would "gamify" uploading somewhat, thus inspiring users to upload photos because it feels more "fun". I think we want to stay away from pure quantity badges like "200 uploads" so we don't inspire bad uploads. Rather, we could offer badges for quality, like when the user maintains a 90% no deletion rate, or when their pictures are used in articles or selected as picture of the day etc. Considerations: How to keep track of this in the backend?

• Modify desc/category/etc from within the app Modify categories/description afterwards #161

• [HP - at least a prominent link to a web view if we can't implement the entire thing within the app] Implement user polls within the app Polling users #445 - This would be extremely useful for planning new features, in that we can easily get user input before implementing anything. Of course, there are simpler ways to create polls (in forums, external poll services or even in GitHub, etc), but IMO this is the best way to ensure that all users get a say while minimizing the extra work needed for the user (e.g. if we use GitHub, they would need to create a GitHub account to post). However, the tradeoff is that it is a lot more work for the developers (but I believe this would be worth it, especially if the app continues to grow). We would likely need to do some server-side implementation to host the results.

Finally

• [HP] Design and develop a new main screen displaying various information Create welcome screen #568 - This can only be done at the end of 2018, after most of the previous improvements have been completed. We can display ongoing campaigns, the badges that the user collected, some contribution statistics, any recent news/polls for the app, the nearest location that needs photos... all alongside the upload from gallery/camera button(s) (which should of course be very prominent), and links to the user's recent contributions and the Nearby list/map. I personally believe this would be the best utilization of the main screen real-estate, although it is a very long-term goal.

• [HP] Implement a walkthrough of the new UI and various features for the user - Design a first-run experience around the MaterialShowcaseView library mentioned at Add brief explanation to Nearby Places UI #706

Technical improvements

No Library Needed	Library Needed
[HP] Move to JSON based WIkimedia API (formerly, 'use Retrofit'). We already include OkHttp and GSON in the build.	[HP] Use Glide library instead of asynctask load of images. Glide already developed for loading images, and its support different paths for imageview (URI, URL, file path at SD card and etc). Simple use, simple result
[HP] For fragments, use newInstance pattern instead of creating new objects. Fragment newInstance() pattern prevent memory leaks	[HP] Add dagger implementations to project. Dagger is dependency injection library which will help to remove many initializations of some utils/loaders/api workers and etc. For example in current project it will help to initialize SharedPreferences client once for using in many parts of app. (the runtime for Dagger is tiny, it's mostly compile-time annotation processing)
[HP] Most common sizes must be moved to dimens.xml and separated by screen-sizes folders. Too much values are hardcoded in layouts	Move layouts to ConstraintLayout where its possible, it much smoother and easy to operate. (but it's a Google support library)
[HP] Move icons to SVG format instead of PNG, which will decrease APK size and improve icon multi-screen support
User shrinkResources = true in build.gradle to remove unused resources from APK file on release.
Add rxAndroid to project - it will speedup application, remove logic from main thread and provide huge possibilities make multithreading apps (already underway)
[Optional] Android data binding for activities, fragments, viewholders. Android data binding - powerful technique which simplify view code, and let you add some boilerplate logic to XML instead of some operations directly in activity, fragment, viewholder. Renderers can be replaced by Android data binding implementations
[HP] Address the very high cyclomatic complexity we are seeing from Codacy by breaking up Activities & Fragments according to one of the well-respected architectural patterns (MVP / MVVM / etc)

[VojtechDostal]

Hi all and thanks @misaochan for starting this. I am also posting @tised 's suggestions on the technical side of the app which you might or might not find useful - just wanted you to have them at your disposal:

• Use Retrofit instead of volley or mwapi. As i understand, in project there are some org.mediawiki:api dependency which provides client-server integration in Android part, but it looks like too messy and code are too complex. Retrofit can replace that boilerplate code by simple lines of code which will be more readable and much more understandable. Especially in project already are used GSON library, which in chain with retrofit will provide good boost.
• Use Glide library instead of asynctask load of images. Glide already developed for loading images, and its support different paths for imageview (URI, URL, file path at SD card and etc). Simple use, simple result
• Add dagger implementations to project. Dagger is dependency injection library which will help to remove many initializations of some utils/loaders/api workers and etc. For example in current project it will help to initialize SharedPreferences client once for using in many parts of app.
• Android data binding for activities, fragments, viewholders. Android data binding - powerful technique which simplify view code, and let you add some boilerplate logic to XML instead of some operations directly in activity, fragment, viewholder.
• For fragments, use newInstance pattern instead of creating new objects. Fragment newInstance() pattern prevent memory leaks
• Most common sizes must be moved to dimens.xml and separated by screen-sizes folders. Too much values are hardcoded in layouts
• Move icons to SVG format instead of PNG, which will decrease APK size and improve icon multi-screen support
• User shrinkResources = true in build.gradle to remove unused resources from APK file on release.
• Move layouts to ConstraintLayout where its possible, it much smoother and easy to operate.
• Add rxAndroid to project - it will speedup application, remove logic from main thread and provide huge possibilities make multithreading apps
• Renderers can be replaced by Android data binding implementations

[psh]

On the technical topics, generally a "yes" to all with the following notes:

• Retrofit - Retrofit works wonderfully when you have a REST API with multiple endpoints. Since we hit a single endpoint we'd mostly be using Retrofit for its ability to build a multipart form encoded request. Building that request is something that's super easy to do, so we can use the underlying OkHttp / Okio libraries directly. That said, we need to move over to the JSON based Wikimedia API and off the deprecated XML one. This is as good a heading as any to do the work under. That said, the main Wikipedia app uses Retrofit. I have a branch where I've almost finished the work.

• Glide - There are 3 major image management libraries (Picasso, Glide and Fresco) that would do the job nicely. Picasso is the smallest but Glide has better performance, and both are virtually the same as far as API goes. Fresco does a good job of image memory management but I (personally) cant justify it based on its enormous method count and size. Glide is a nice middle-ground of performance and size.

• Dagger - Again, a technology I'm very familiar with, and a conversion that I have staged and ready to go on a branch.

• RxAndroid - already under way, let's finish the work of removing the Async tasks and look at how it integrates with Retrofit.

• Databinding - Interesting library but it does hide GUI implementation details in the XML. I'm on the fence on its usefulness.

Codacy is reporting some very high cyclomatic complexity numbers for classes like ShareActivity and MediaDetailsFragment. I think we should take a look at breaking up some of these big / complex classes to make the code more maintainable. Some (architectural) separation between View, Model and other code (MVP / MVVM / etc) would also help to structure the codebase.

[misaochan]

Thanks for the suggestions, all! I am on board with most of the technical changes suggested, especially refactoring the large and complex classes (ShareActivity especially would be top priority IMO), and switching the deprecated XML queries to JSON ones.

@psh and @maskaravivek , would you two like to collaborate to come up with a list of technical improvements that we would add to my user-focused list above? Preferably with input from @whym , @nicolas-raoul and anyone else who is interested, too.

@VojtechDostal , to what extent do you think WMF would be willing to fund technical improvements that would make the codebase significantly cleaner but have little or no impact on the end user? If, say, 33% of our proposed improvements were technical, would that be viewed as reasonable by WMF?

[VojtechDostal]

@misaochan I would not be afraid of including the "technical" changes, which do not affect the appearance or functionality, into the proposal. As long as they are well reasoned and are supplemented with changes that do matter for the user, I'm fine with everything. A good code is the basis for all future improvements.

[misaochan]

Wonderful, thanks for the clarification! :)

We can definitely go ahead with including some of the technical improvements, then. Personally, I would suggest that we focus first on the improvements that do not require adding new libraries, and then judiciously select which new libraries we want to include. This could be a personal preference, but my opinion is that the more libraries/external frameworks we include, the higher the barrier of entry to new contributors/volunteers. So IMO each new library is a trade-off that needs to be considered carefully.

That being said, I have not been doing Android development for very long, so if the more experienced devs come to a consensus that there is a very good reason for any or all of the libraries suggested, I'm happy to go with it.

[psh]

Classifying things according to "library" / "no library" gets us a list that looks something like this (based on details from @VojtechDostal with 2 additions)

No Library Needed	Library Needed
Move to JSON based WIkimedia API (formerly, 'use Retrofit'). We already include OkHttp and GSON in the build.	Use Glide library instead of asynctask load of images. Glide already developed for loading images, and its support different paths for imageview (URI, URL, file path at SD card and etc). Simple use, simple result
For fragments, use newInstance pattern instead of creating new objects. Fragment newInstance() pattern prevent memory leaks	Add dagger implementations to project. Dagger is dependency injection library which will help to remove many initializations of some utils/loaders/api workers and etc. For example in current project it will help to initialize SharedPreferences client once for using in many parts of app. (the runtime for Dagger is tiny, it's mostly compile-time annotation processing)
Most common sizes must be moved to dimens.xml and separated by screen-sizes folders. Too much values are hardcoded in layouts	Move layouts to ConstraintLayout where its possible, it much smoother and easy to operate. (but it's a Google support library)
Move icons to SVG format instead of PNG, which will decrease APK size and improve icon multi-screen support	Design a first-run experience around the MaterialShowcaseView library. (#706)
User shrinkResources = true in build.gradle to remove unused resources from APK file on release.
Add rxAndroid to project - it will speedup application, remove logic from main thread and provide huge possibilities make multithreading apps (already underway)
Android data binding for activities, fragments, viewholders. Android data binding - powerful technique which simplify view code, and let you add some boilerplate logic to XML instead of some operations directly in activity, fragment, viewholder. Renderers can be replaced by Android data binding implementations
Address the very high cyclomatic complexity we are seeing from Codacy by breaking up Activities & Fragments according to one of the well-respected architectural patterns (MVP / MVVM / etc)

I'm being really strict with both Dagger and ConstraintLayout - both libraries are from Google and could be counted as "core" to the platform, but then again, they are additional items in build.gradle

[misaochan]

Thanks for the sorting, @psh ! I would also add your suggestion to the "no library needed" -

Codacy is reporting some very high cyclomatic complexity numbers for classes like ShareActivity and MediaDetailsFragment. I think we should take a look at breaking up some of these big / complex classes to make the code more maintainable. Some (architectural) separation between View, Model and other code (MVP / MVVM / etc) would also help to structure the codebase.

MaterialShowcaseView appears to have very tangible benefits for the user (which I am not sure how we could easily replicate without it), so I would vote that that particular library is worth adding. Dagger, Glide and ConstraintLayout is up to the rest of you.

[sivaraam]

We could see if the Wikipedia app allows us to do that,

Could you describe a little more about what you expect the app to allow you to do? This might help in assessing the feasibility.

and we should log the edits that are made via our app to ensure that we aren't vandalizing articles.

You could just tag the edits triggered from the app rather than logging it.

or we could also implement the functionality in our own app if other options don't suit.

I don't like the sound of that. It seems to be a feature creep that could waste developer time which could be used to in improving something else. It's better to leave that to the android app or mobile web.

This reminds me of ES file explorer which despite of claiming to be a file explorer implements all sorts of totally unrelated things. I find that to be an ugly decision.

Improve map navigation - implement compass and routing so that there is no need for user to switch to their map app for navigation. The idea is that the user can then do everything they need without leaving our app. Not sure how technically feasible this is - it might not be worth the work

Shortly (in the line of my previous comment), It's a feature creep and not worth the work. Just leave that to a navigation app. In case you try to implement navigation you'll have to address all sorts of issues regarding navigation which isn't something the app should be focusing on.

N.B. : These are just my opinions so please don't take them seriously.

[maskaravivek]

Hello, all!
Already a lot of good suggestions for what we could include in the WMCZ proposal. @misaochan and @psh's list are very extensive and we probably just need to prioritize things in it for the proposal.

Few comments from the current discussion:

• Improve map navigation might be a lot of effort. Even some of the most popular apps use the users' map app for navigation.
• Add limited connection mode could be one of the top priority items for the app.
• Including Dagger looks to be an important task in our technical improvements list. @psh It would be great to have your branch merged and then document the process for beginners. Even I have a branch nearing completion around dagger.
• We should definitely start using Glide for all image loading purposes.
• Am still an advocate of Guava over RxAndroid but I haven't followed the whole discussion surrounding it. We can evaluate it separately.

[neslihanturan]

Hello team,
Firstly, I loved reading this thread. It is very well organised discussion of our distributed ideas. Thanks to all contributors and all the tables and bullets, everything is clarified.

I can add some small notes:

• For nearby push notifications from @misaochan 's first comment, I would say "both" should be implemented.
• I agree, we don't need to handle navigation in app.
• I am not sure about Databinding either.

[nicolas-raoul]

@sivaraam While directions is probably overkill, compass on the Nearby map would be really helpful. As a heavy user of Nearby, I always head towards the nearest cluster of items, and only open a real map app when I don't know what is the direction I should head to. This is not feature creep, this is an essential feature if we are serious missing pictures.