Map (or list) of nearby places without photos

[justinormont]

Including a list of nearby places (wiki articles) which lack photographs can inspire users to upload needed images. In addition it can list pages without high quality images. This feature could be viewed as a photo scavenger hunt.

Wikipedias

The CSV file below is maintained by the https://github.com/alemela/wiki-needs-pictures project and contains the name/latitude/longitude/type of Wikipedias articles that are geolocalized and marked as needing a picture: https://tools.wmflabs.org/wiki-needs-pictures/data/data.csv

Commons

This is far-fetched, as picture requests are currently in prose, but it is worth checking feasibility every few years. https://commons.wikimedia.org/wiki/Commons:Picture_requests

Wikidata

We could use the same API calls as https://tools.wmflabs.org/wikishootme/ Unfortunately, a lot of Wikidata items lack an image even tough the articles in various languages have pictures.

[misaochan]

Great idea, @justinormont , thanks!

[justinormont]

@misaochan: Quite welcome.

Sorting the places without a photograph by number of page views / month, if shown in a list (vs. a map), will encourage photographs of more important places.

[nicolas-raoul]

Thanks Justin! Let's talk about the selfie idea in this different issue I just created: https://github.com/nicolas-raoul/apps-android-commons/issues/74

[misaochan]

Where do you guys think we should put this list? Shall we create a separate screen for it that users would access by clicking a button or such? (Maybe next to the camera and gallery buttons?)

[nicolas-raoul]

The action bar is getting really crowded, so I suggest creating a navigation drawer: http://developer.android.com/training/implementing-navigation/nav-drawer.html We could put Settings and Feedback there too.

[misaochan]

Thanks! That sounds good. :)

[nicolas-raoul]

Should we just look at the English Wikipedia? If the English article has no pictures, often the articles in other articles have no pictures either.

Besides, ideally if a nearby article (in any language) has a dedicated Commons category then we should probably look whether this category has pictures.

Random thought: Sometimes an article has no pictures even though there are pictures in Commons that could be used to illustrate it. Even in that case taking another picture might be a good idea as maybe none of the existing pictures are great.

Also, I think we should show #28 (map of existing Commons pictures) on the same map. It would help users spot interesting but not-well covered areas.

[nicolas-raoul]

wikishootme seems to be powered in part by PHP. We can probably modify it and host it on WMF servers if needed. wikishootme does not count images in infoboxes, which results in a lot of false positive in my experience, I created an issue about it: https://bitbucket.org/magnusmanske/wikishootme/issues/1/do-not-show-articles-that-have-an-infobox-image

[misaochan]

Right, I have been testing it and wondering why it was bringing up some locations that did have images in their articles. Hm. Alternatively there is a previous IEG project that seems to touch on this: https://meta.wikimedia.org/wiki/Grants:IEG/Wiki_needs_pictures . Apparently they have an API that we can use, but not sure if that is what we need/want.

[misaochan]

Hi @justinormont ,

We are still discussing the details of the implementation, but in the meantime I have proposed this feature as part of an IEG proposal, so hopefully I will be able to work on it if it is approved. :) Would appreciate it if you could take a look at the proposal and review/endorse it if you see fit? Thanks!

[justinormont]

@misaochan: The proposal looks great; I endorsed.

[misaochan]

Thanks @justinormont ! :)

[nicolas-raoul]

wikishootme's map displays Wikidata items that lack an "image" parameter. PROBLEM: In many areas, there are Commons pictures available, but just nobody has assigned one to each Wikidata item yet. SOLUTION: https://tools.wmflabs.org/fist/wdfist is a fun tool to easily assign pictures to Wikidata items around you. So after using it for like 5 kilometers around you, and after waiting a few hours for wikishootme to refresh, wikishootme only shows the items for which really no picture is available yet. So, I suggest adding a link to https://tools.wmflabs.org/fist/wdfist too.

[misaochan]

Marti has suggested that we try and collaborate with Alessio and Alex from https://meta.wikimedia.org/wiki/Grants:IEG/Wiki_needs_pictures if possible for this, to reduce potential duplicate work. Their API is not completed yet, but it seems they have a prototype ready, from what I see.

Do you think it will be viable to try and use their API for this task?

[nicolas-raoul]

Yes that would be a good idea indeed! This map could even be the main activity of our app: After all, this is an app to upload new pictures, not to see the pictures you have uploaded already.

It looks reasonably fast: http://tools.wmflabs.org/wiki-needs-pictures/ Data is so scarce though, I find it hard to believe that there are only 3 requested pictures in New Zealand. Apparently their phase 2 is to add geolocalized Wikidata items missing an image, so we will get many times that eventually.

[misaochan]

I like the idea of the map being the main activity, I agree that it would be more useful than looking at old pics. But should we poll users first before we do that?

I'm glancing at their GitHub page and I don't think we can reuse their map code easily, as it is in JS/CSS? So even if we want to go the map route, we will probably need to use their API and code the map by ourselves, right? Not sure how long that would take, would it be a feasible addition within the IEG time frame or would it be best left for later?

[nicolas-raoul]

Indeed, posting the idea to the mailing list is a good practice for such a big change. We might even get a few replies, never know :-)

How about a webview? This raises a few questions, by the way:

• If there is no internet, should we show the gallery instead?
• For privacy reasons, we should do everything over HTTPS, but https://tools.wmflabs.org/wiki-needs-pictures/ does not seem to work.
• For privacy reasons, should we load map/etc elements only from Wikimedia-owned servers? http://tools.wmflabs.org/wiki-needs-pictures launches requests to mqcdn.com

Might be a bit big for this time, for great for another iteration, which hopefully would coincide with wiki-needs-pictures getting more mature and data-rich.

[nicolas-raoul]

A cheap option might be to just embed http://tools.wmflabs.org/wiki-needs-pictures/ or have a link to it.

[nicolas-raoul]

I created a small proof of concept: It loads CSV data at the https://tools.wmflabs.org/wiki-needs-pictures/ format Tapping an item reveals a page with more space for details (no details yet though haha) and a button to open with a map app. Source code: https://github.com/commons-app/ShootMe (I have put the project here without thinking much, just because it is related)

[misaochan]

Nice! Will try to build it soon. :)

I think we can use this layout... but...why are there pictures for each of the items? Isn't this supposed to be a list of nearby places that LACK photos?

[nicolas-raoul]

@misaochan: These are only "type" illustrations. Each requested picture has a type like "landmark", "event", "edu", etc. So I just chose an illustration for each. I believe it makes the app more visually appealing, but indeed it can be confusing I guess...

[misaochan]

Got your code to work with the wikishootme CSV file with a few edits:

What do you think of it? I still like the layout in general but can't really decide what to do with the images. I agree that it looks more appealing, but I think it would be confusing. If we do go the picture route maybe we could put a big 'Example' over each sample pic?

[nicolas-raoul]

As you noticed, I have not defined pictures for waterbody and river yet ;-)

How about using icons instead of real pictures? For instance https://openclipart.org/detail/60307/student-hat-rmx for "edu", etc

We have very little information for now (article name, coordinates, type), so better use them as much as we can to make the app interesting.

I haven't used the app yet, but I believe having illustrated types can make it more fun to use? For instance if I ride my bicycle I might make a detour to a nearby lake, but ignore schools as I don't want want to be that creepy guy taking pictures inside schools while wearing fluorescent cycling tights.

On Mon, Aug 15, 2016 at 4:26 PM, Josephine Lim notifications@github.com wrote:

Got your code to work with the wikishootme CSV file with a few edits:

[image: wikishootme-screenshot] https://cloud.githubusercontent.com/assets/3611199/17658162/b5428484-631d-11e6-80ed-3adf7b2af5e5.png

What do you think of it? I still like the layout in general but can't really decide what to do with the images. I agree that it looks more appealing, but I think it would be confusing. If we do go the picture route maybe we could put a big 'Example' over each sample pic?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-239743796, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBvj3-dWdd1tCdCaWjB_YM-5WfMpUks5qgBSVgaJpZM4HiE00 .

[misaochan]

Lol! Yes, I think icons would be a great idea. Will look up some.

What do we do with items that have an 'undefined' type? There are quite a few like that in WikiShootMe. I guess in that case the "?" icon is fine?

[misaochan]

I will try merging this with the real app soon. Will use a navigation drawer as suggested to house the links to this list (along with Settings and Feedback).

[nicolas-raoul]

Unfortunately I am not sure it is an easy merge, because of https://github.com/commons-app/ShootMe/issues/4 (I would love to be proved wrong)

On Mon, Aug 15, 2016 at 4:48 PM, Josephine Lim notifications@github.com wrote:

I will try merging this with the real app soon. Will use a navigation drawer as suggested to house the links to this list (along with Settings and Feedback).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-239746793, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBqD3u5ya85H6MNu25uZygJtzUeyoks5qgBndgaJpZM4HiE00 .

[misaochan]

Hm, can we not include Google Play Services and Google Maps as a dependency in our real app? I think it would come in useful eventually anyway (aside from this usage, I mean).

[nicolas-raoul]

No, because it is not open source: https://commonsware.com/blog/2013/05/22/remember-google-play-services-proprietary.html

Apps relying on Google Play Services are not accepted on F-Droid.

I also believe it sends some statistics to Google, which would violate Wikimedia's confidentiality agreement.

Finally, Google Play Services is unavailable on many devices, especially non-Google-endorsed phones, and many popular China-produced phones.

On Mon, Aug 15, 2016 at 5:36 PM, Josephine Lim notifications@github.com wrote:

Hm, can we not include Google Play Services and Google Maps as a dependency in our real app? I think it would come in useful eventually anyway.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-239753800, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBiYuaTWV_7m-mnL9qQLpn5f3yWDtks5qgCTzgaJpZM4HiE00 .

[misaochan]

Oh, okay, didn't know that. I'll try and see if I can find a way around that then.

[misaochan]

I'm setting up the navigation drawer to house the link to this, along with About, Settings, and Feedback. It seems that the drawer works best with fragments, so I'll need to convert AboutActivity and SettingsActivity from Activities to Fragments. That should be okay, right? There's no reason why they need to remain as Activities?

[nicolas-raoul]

Sounds good :-)

On Wed, Aug 17, 2016 at 3:25 PM, Josephine Lim notifications@github.com wrote:

I'm setting up the navigation drawer to house the link to this, along with About, Settings, and Feedback as suggested. It seems that the drawer works best with fragments, so I'll need to convert AboutActivity and SettingsActivity from Activities to Fragments. That should be okay, right? There's no reason why they need to remain as Activities?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240324257, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBizQSduNlMVMzXK9mlEHa7AnMqm9ks5qgqlggaJpZM4HiE00 .

[misaochan]

The non-deprecated nav drawer class requires API 14 as minimum SDK version. I checked on our statistics and this will exclude 0.26% of our users. Is this OK?

[nicolas-raoul]

Yes, I think it is OK.

On Wed, Aug 17, 2016 at 4:09 PM, Josephine Lim notifications@github.com wrote:

The non-deprecated nav drawer class requires API 14 as minimum SDK version. I checked on our statistics and this will exclude 0.26% of our users. Is this OK?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240331172, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBmxQMwDxd2AkO1ZJAESGzMJlSRoTks5qgrOZgaJpZM4HiE00 .

[misaochan]

Hmm. I've been trying to get a 'menu' button up on the left of the actionbar that brings up the nav drawer if tapped. But the way our app works, this seems to clash with the 'back' button that lets users go back when viewing a pic. And if I did turn About and Settings into fragments, I'd assume we would want a 'back' button for those as well. So do we want a 'menu' button only on the main fragment and a 'back' button elsewhere, or is it OK if we have no menu button at all and the only way to access the nav drawer is to swipe?

[nicolas-raoul]

Swipe-only would be too difficult to discover, I think...

On Wed, Aug 17, 2016 at 5:00 PM, Josephine Lim notifications@github.com wrote:

Hmm. I've been trying to get a 'menu' icon up on the left of the actionbar that brings up the nav drawer if tapped. But the way our app works, this seems to clash with the 'back' icon that lets users go back when viewing a pic. And if I did turn About and Settings into fragments, I'd assume we would want a 'back' icon for those as well. So do we want a 'menu' icon on the main fragment and a 'back' icon elsewhere, or is it OK if we have no menu icon at all and the only way to access the nav drawer is to swipe?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240341028, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBmjUKOCmd9hDyBfKgOcxsJsTG8Ayks5qgr-NgaJpZM4HiE00 .

[misaochan]

Yeah, true. So the upper left button should bring out the nav drawer, but only on the main fragment right? We probably want to retain back-button functionality for other fragments?

[nicolas-raoul]

To get back from settings to gallery, requiring the user to press Home > Gallery is not a problem, I think. If that makes implementation easier.

On Wed, Aug 17, 2016 at 5:18 PM, Josephine Lim notifications@github.com wrote:

Yeah, true. So the upper left button should bring out the nav drawer, but only on the main fragment right? We probably want to retain back-button functionality for other fragments?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240344786, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBi-eXx9IjFQqRmlafOSr9i4JcOqPks5qgsO7gaJpZM4HiE00 .

[misaochan]

What about when they are viewing the pictures individually though? They won't mind using the hardware 'back' on their phone instead to go back?

[nicolas-raoul]

Indeed... I haven't checked the code, what prevents the back button from working in that case?

On Wed, Aug 17, 2016 at 5:28 PM, Josephine Lim notifications@github.com wrote:

What about when they are viewing the pictures individually though? They won't mind using the hardware 'back' on their phone instead to go back?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240347083, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBpwexEnvL2Rwi1ygjqS9qdJhtzmLks5qgsY7gaJpZM4HiE00 .

[misaochan]

Because it has been replaced with the menu button. I'll submit a PR (#236) so you can test it and see. It's not complete, it just shows the nav drawer (the links in the drawer don't work yet), so don't merge it.

[nicolas-raoul]

Just commit, I can test your branch. Pull requests should only be used when you want to request a pull, in general :-)

On Wed, Aug 17, 2016 at 5:37 PM, Josephine Lim notifications@github.com wrote:

Because it has been replaced with the menu button. I'll submit a PR so you can test it and see. It's not complete, it just shows the nav drawer (the links in the drawer don't work yet), so don't merge it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/73#issuecomment-240349011, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBmdcPgKia2s4DOcQp8_tI_QuXWobks5qgsgvgaJpZM4HiE00 .

[misaochan]

Oh, OK. It's on https://github.com/misaochan/apps-android-commons/tree/nav-drawer-hamburger

[misaochan]

Ah, I stumbled upon a solution while looking up a different bug. Apparently I just need to set mDrawerToggle.setDrawerIndicatorEnabled(false); in the fragments that don't need the nav drawer, and the back button will replace it there.

[misaochan]

Still encountering issues with nav drawer, posted at http://stackoverflow.com/questions/39010912/actionbardrawertoggle-disappears-when-addtobackstacknull-is-used

[misaochan]

Can't fix the nav drawer issues, so for the time being I will just use an ActionBar button, and will create a task to switch to nav drawer later. I'm copying over pertinent code from the ShootMe repo, currently still trying to figure out how to get it to work without using a LatLng object to store coords. Maybe I'll make my own LatLng object?

Current branch that I am working on is https://github.com/misaochan/apps-android-commons/tree/menu-nearby

[nicolas-raoul]

Indeed, creating your own LatLng object seems to be the best.

[misaochan]

Update: Currently working on https://github.com/misaochan/apps-android-commons/tree/nearby-listview . I think I've mostly managed to implement the backend stuff - it pulls places from the wmflabs .csv file and sorts them by distance from the user's current location. Just need to get it displayed in the UI now via adapter, and think about how I want to implement the detailed view of the place when it is tapped.

[nicolas-raoul]

Cool, looking forward to trying it :-) As it is a big file and updated only once per day, it probably makes sense to cache it locally (that can be done later of course).

[misaochan]

Ah yeah, good point. :)

Also, do we need to do it in an AsyncTask? ShootMe seems to do it on the main thread and it is fast enough apparently?

[nicolas-raoul]

I am sure it should not be done on the main thread, as it can take time. ShootMe is not an example to follow ;-)