Apps-android-commons: Show news about ongoing campaigns/competitions

[misaochan]

Suggested by John Cummings at https://commons.wikimedia.org/wiki/Commons:Village_pump#IEG_proposal:_Improve_Upload_to_Commons_Android_app

@Misaochan:, this has a very large potential to increase participation. I wanted ask a question that is outside the current grant request but is related. I know that there has been some previous work on a Wiki Loves Monuments app and could see a clear use for a similar app for Wiki Loves Earth. I don't understand the technical side of Wiki Loves Monuments and Wiki Loves Earth but I can see having an app may help increase the easy of participation for people. Would there be an easy mechanism to have a link somewhere in the front page of the app to contribute to the competitions? I think there are a few advantages of integrating the competitions into a central app rather than having an app for each competition:
If people install the app for the competition it means they can continue to contribute to Wikimedia Commons after the competition has finished
May encourage people to take part in multiple competitions, inccreasing the participation for all of them. E.g someone installs the app for WLE and then continues to add photos afterwards and the app makes them aware that WLM is happening.
Smaller competitions can have contributions by an app without needing to create their own.
Thanks
John Cummings (talk) 13:52, 4 March 2016 (UTC)

[nicolas-raoul]

How about a small "news" that would show up only during such campaigns? since presumably a week or so before.

Implementation could be as simple as loading a text file from a hard-coded URL like https://www.mediawiki.org/wiki/Wikimedia_Apps/Commons/Ad (that page would need to be ultra-protected obviously) and ignoring when the page is blank. Loading would need to be asynchronous to not impact app startup speed too much.

This space could also be used for other communication such as "Now is Categorization Week, please join us at http://commons..org/Categorization_Week" or "Help translate the app to your language, see http://some-url"-type information. If we extend to this, the "news" should be dismissable.

Further integration of WLM-type campaigns used to exist but has been removed as we saw no use to it, and it increased complexity. It used to be built as separate apps if I remember correctly.

[misaochan]

Ahh, is that the Campaigns code that we removed previously due to it being unused? That explains a lot. :)

I like the idea of the ad for other WM campaigns. Who would maintain the URL that switches the ads around though? Or is it already done automatically?

[nicolas-raoul]

Maintainance would be done manually by the community at https://www.mediawiki.org/wiki/Wikimedia_Apps/Commons/Ad

[tobias47n9e]

Ideally we could have some kind of plug-in structure. For example a GeoJSON with the location, description etc.. and also the name of the campaign, start date, end date, custom categories. Ideally a user could create a campaign from query.wikidata.org which will also be able to query commons soon (once Wikidata for Commons goes online).

Something like Wiki loves monuments or Wiki loves earth is probably not more than a few lines of sparql to get the desired items. Non location based campaigns query for certain categories or create the JSON manually. If no locations are provided no map is shows, but a list. Gamification would be possible if points (stars, etc..) are assigned to the items.

[nicolas-raoul]

Indeed.
Would you mind designing the ads for two campaigns that have actually happened? And design the JSON that would define each of these campaigns. Agreeing on a solid format is a requirement before we start coding.

[nicolas-raoul]

@tobias47n9e: This issue is only about the ads (news), so your paragraph about SPARQL probably belongs to https://github.com/commons-app/apps-android-commons/issues/100
Cheers! :-)

[nicolas-raoul]

We could load the JSON file from a hard-coded URL like http://commons-app.github.io/campaigns.json
I now see the point of having SPARQL in this file too.
To summarize, the JSON file could contain for each ongoing campaign:

• Name of the campaign
• Area where the campaign takes place
• Start/end date of the campaign
• Explanation text
• Categories to add to categories suggestions
• SPARQL request for nearby campaign-related items

Anyone willing to write a sample for a few real past campaigns?

[maskaravivek]

As discussed with the team am assigning this task to @ashishkumar468. I would be picking up #604 instead.

cc @misaochan

[ashishkumar468]

Can someone help me with the api's for the same. Also, I was hoping if the right place for it would be the nav drawer ?

[misaochan]

@VojtechDostal @nicolas-raoul @whym @tobias47n9e Would appreciate insight on which API we should use for this?

@ashishkumar468 For the UI, the eventual plan is for it to be on the main screen. But depending on the output of the API, for the time being the nav drawer or even a separate "News" activity could work.

[misaochan]

@nicolas-raoul @VojtechDostal @urbanecm Any ideas on what API we could use? I will try to ask on wikitech-l or the village pump soon if no one here knows. :)

[urbanecm]

Not sure I fully understand the question. What data you want to access in the app?

[misaochan]

The exact data that we will display is somewhat flexible, but we at least need to be able to check (1) dates that the campaigns are running and (2) names of these campaigns.

[urbanecm]

What is a campaign in this context?

[misaochan]

I think we can just start with the international WLE and WLM campaigns for now, but for a future enhancement could include the country-specific ones?

[urbanecm]

I wonder if such campaigns are stored in some app. If not, it's hard to recommend an API.

[misaochan]

Hmm, I guess if an API doesn't exist, we can just go with the manual maintenance and loading of a text file as mentioned at https://github.com/commons-app/apps-android-commons/issues/78#issuecomment-193065060 . IMO this would be less-than-ideal due to the maintenance required, but if it is only WLM and WLE, maintenance would be required only once a year (and even then only if WMF changes their plans, AFAIK those usually have fixed dates every year?).

[urbanecm]

If you decide to maintain the list of campaigns in a TXT file, I think this file should not be stored in app, but somehow publicly available on web. This will make changes simplier, because you won't have to wait for users to update the app.

[VojtechDostal]

Campaign in this context is page in the Campaign namespace on Wikimedia Commons.

https://commons.wikimedia.org/wiki/Commons:Upload_campaigns

[urbanecm]

@VojtechDostal Thank you.

@misaochan Upload campaigns linked by @VojtechDostal can be get either via native MW API (if you need list of all campaigns or know what campaigns you are looking for). Alternatively, I can write something that addresses your needs better than native MW API, if you give me questions you need APIzed answers to.

[nicolas-raoul]

Apparently there is no active campaign right now?
Here is how that page looked when a campaign was active: https://commons.wikimedia.org/w/index.php?title=Commons:Upload_campaigns&oldid=101495150
Seeing the page's history, it does not seem to be maintained carefully. So we would have someone make sure it is kept up-to-date every month or so. Also, we would have to add a few columns, at least start/end time, name+explanation (localized?), ideally location, maybe also a SPARQL query for Nearby.

Not sure which is better:

• Use and extend that page, potentially benefit from the community's maintenance, and possibly face breaking changes from time to time.
• Or start a JSON file from scratch at an URL like http://commons-app.github.io/campaigns.json which would have to be 100% maintained by us.

Here are more photo scavenging events, albeit very unstructured: https://commons.wikimedia.org/wiki/Category:Photo_scavenger_hunts

Keeping track of all competitions might take more time than we can afford.

[VojtechDostal]

That table seems manually updated but it seems like people periodically update campaigns like this one: https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-cz&action=edit

[nicolas-raoul]

I did not know about that namespace, interesting!
Unfortunately it does not seem to have time information, for instance https://commons.wikimedia.org/w/index.php?title=Campaign:FLISoL2017&action=edit is still marked as active.
And there are hundreds: https://commons.wikimedia.org/w/index.php?title=Special:PrefixIndex&namespace=460 so we can not just show all campaigns.

[urbanecm]

The problem is that the campaign you linked is still officially marked as active and if you use an URL referencing this campaign, it will just work.

Maybe we should get Commons administrators and/or campaign admins to disable a campaign when it is no longer necessary, so we can use it in this app?

Alternatively, we can display x newest campaigns, which can display some out of date campaigns and also not display some campaigns that should be displayed. I think the previous solution is better.

[misaochan]

Thanks guys! :)

To clarify, I don't think we want to display a list of campaigns to the user per se. IMO for our current prototype, we would only display active campaigns, with a line like: "This campaign (e.g. WLM) is currently running from Oct 1 - Oct 31! Tap to see more information", and when tapped, the user would be brought to the campaign page.

We also probably don't want to display photo scavenger hunts at the moment, and indeed IMO we want to limit ourselves to the major campaigns. Not just for our own sake (i.e. maintenance), but also because I think users would become desensitized. If they see lots of campaigns active all the time, most users would just ignore them entirely, then the impact would be lost.

It seems like the last edit to https://commons.wikimedia.org/w/index.php?title=Commons:Upload_campaigns&oldid=101495150 was in 2013? In that case I'm not sure we would get any help from the community even if we use that page, lol. Perhaps the publicly-available JSON or TXT file maintained by us would be the better solution. If we restrict ourselves to major campaigns, I don't think we would need to maintain it more often than 1-2 times a year?

[urbanecm]

The campaigns pages themselves do not contain any information about time. If we need info about time, I think there's no other solution than maintaining publicly available JSON file.

[misaochan]

So, I'm working on getting the base information up so that @ashishkumar468 can get started on the JSON file and the task itself.

I have the campaigns below at the moment, please feel free to correct/add:

Wiki Loves Monuments, 1-30 Sep, https://www.wikilovesmonuments.org/contest/
Wiki Loves Earth, 1 May - 30 June (unfortunately it seems that it differs slightly based on country?), http://wikilovesearth.org/

What else? WikiLovesPride seems to have a fixed date every year, but seems fairly small. WikiMuseum?

[JeanFred]

The problem is that the campaign you linked is still officially marked as active and if you use an URL referencing this campaign, it will just work.

Maybe we should get Commons administrators and/or campaign admins to disable a campaign when it is no longer necessary, so we can use it in this app?

This is by design. Upload campaigns have this dual-use − for campaign-as-contest, and as an upload helper. That’s why folks are encouraged to use WLM campaigns even when WLM is not running, as they get fields pre-filled with the monument ID etc. These campaigns are expected to be enabled all year long. (At least for WLM, we rely on {{WLM-is-running}} and manual updates to sort out what really belongs in the campaign-as-contest.)

Couple of other notes:

• campaigns are usually aligned on local-time (from midnight to midnight)
• there are always exceptions − for example this year, Ireland started WLM on Aug 24, Israel finishes on October 10 (not that this level of detail necessarily matters much for the commons app use case)

(I’m part of the WLM international team, and an avid Campaign creator/user :-)

[misaochan]

Thanks for the input! :) Unfortunately I still can't find a way for our app to retrieve specific start and end dates from that namespace. :( As I talked about with @VojtechDostal today, perhaps we could stick to the JSON file for now as time is running short for this task. In the future, especially if a more suitable API is built upstream, we can change our approach.

@ashishkumar468 can you please create the JSON file in our repo with the information below? Then anyone can modify it or add more.

Wiki Loves Monuments, 1-30 Sep, https://www.wikilovesmonuments.org/contest/
Wiki Loves Earth, 1 May - 30 June, http://wikilovesearth.org/

[nicolas-raoul]

I created a new repository, so that we can give reviewer rights to people who are not Android developers.
In the future we can even give this repository to another trusted organization, as maintaining this list is not our core mission.

https://github.com/commons-app/campaigns
https://raw.githubusercontent.com/commons-app/campaigns/master/campaigns.json

[maskaravivek]

@nicolas-raoul thanks for creating the repo. :)

I was thinking about the JSON structure and here are a few things that we should consider:

{
    "config": {
        "showOnlyLiveCampaigns": true/false,
        "sortBy": "title/startDate/endDate"
    }
    "campaigns": [
        {
            "title": "Wiki Loves Monuments",
            "description": "Wiki Loves Monuments",
            "startDate": "2018-09-01",
            "endDate": "2018-12-01",
            "link": "https://www.wikilovesmonuments.org/contest/"    
        }, 
        {
            "title": "Wiki Loves Earth",
            "description": "Wiki Loves Earth",
            "startDate": "2018-09-01",
            "endDate": "2018-12-01",
            "link": "https://www.wikilovesmonuments.org/contest/"    
        }
    ]
}

Am just proposing a suggestion for campaign config. We can have it implemented in the client at a later stage. :)

• showOnlyLiveCampaigns can help the app decide if only live campaign needs to be shown or all campaigns should be shown. As of now, we should show all campaigns but once our JSON has more items, we can decide to show only live ones.
• sortBy to decide which campaign to be shown on top.

[ashishkumar468]

Thanks @maskaravivek This seems to cover all the possible cases (at least those I could think of). If all of us agree, I can proceed with this api contract

[nicolas-raoul]

@ashishkumar0207 I updated the JSON file with Vivek's additions, so feel free to make the app download it from GitHub (URL above) and parse it :-)

[ashishkumar468]

Thanks @nicolas-raoul . I am on it :-)

[maskaravivek]

Oops, I hadn't noticed that the repo already had a JSON. @nicolas-raoul Thanks for adding the updated JSON to the repo.

@ashishkumar468 You might have to update the JSON file to fix the values based on @misaochan's comment. I had just posted a sample. :)

[ashishkumar468]

Thanks @maskaravivek , will do the same

[JeanFred]

Question: Is there a plan to make the news about the Campaigns country-aware or is that out of scope for this task?

[ashishkumar468]

@JeanFred Does not seems something difficult to implement, although it would add complexity in maintenance of the json, IMO, can be taken as an improvement later on, what do others say?

[JeanFred]

@JeanFred Does not seems something difficult to implement, although it would add complexity in maintenance of the json, IMO, can be taken as an improvement later on, what do others say?

Agreed. I think it makes a lot of sense to keep the first iteration simple and not making it country-aware ; but also to keep that in mind for the future as a very desirable improvement: people in Country X might be confused that they get WLM advertised if there is no WLM running in their country. For WLM and WLE it is probably not too bad, because they’re global and take place in lots of countries ; but I can imagine that competitions with smaller scope (for example, there were quite some dedicated Wiki loves X happening in India) would be keen to also get their campaigns surfaced in the app :)

[nicolas-raoul]

I would suggest keeping countries for a second phase because it is not trivial:

• Some users do not allow the app to use the GPS.
• As far as I know, there is no open source library to guess a country from a location (nor from the Android system itself).
• Some competitions might cover Benelux (three countries that very often act as a single one) or Alaska (not a country), adding to the complexity.

[maskaravivek]

This might be out of the scope of the task but for the sake of discussion, we can support country-level campaigns with 2 additional attributes.

{
    "config": {
        "showOnlyLiveCampaigns": true/false,
        "sortBy": "title/startDate/endDate"
    }
    "campaigns": [
        {
            "title": "Wiki Loves Monuments",
            "description": "Wiki Loves Monuments",
            "startDate": "2018-09-01",
            "endDate": "2018-12-01",
            "link": "https://www.wikilovesmonuments.org/contest/",
            "global": false,
            "country": "India"
        }, 
        {
            "title": "Wiki Loves Earth",
            "description": "Wiki Loves Earth",
            "startDate": "2018-09-01",
            "endDate": "2018-12-01",
            "link": "https://www.wikilovesmonuments.org/contest/",
            "global": true    
        }
    ]
}

• if global is true then the campaign would be visible in all countries.
• if global is not set as true then the campaign would be visible only in the country.

@nicolas-raoul's concerns can also be addressed:

Some users do not allow the app to use the GPS.

Users who do not allow GPS/location access can be shown only global campaigns. Others can see global + country campaigns.

As far as I know, there is no open source library to guess a country from a location (nor from the Android system itself).

GeoCoder can be used to retrieve Address which contains country info.

Some competitions might cover Benelux (three countries that very often act as a single one) or Alaska (not a country), adding to the complexity.

The campaign file would contain a corresponding entry for each country. The user would be shown only one of these items based on his country.

• Assuming GPS is never available, we can have a country drop-down list where the user can select the country for which they want to see the campaigns. Some users might be planning a trip ahead and might want to see campaigns in another country.
• Our JSON file won't grow to unmanageable limits as of now but later we can introduce a middle layer so that the app doesn't consume the JSON directly. The client can send country, language, global etc as params.

[misaochan]

Thanks for creating the new repo! I agree that country-specific support would be wonderful, but it would be best to do it as a future enhancement.

Now that we have a rudimentary backend sorted, we need to consider the UI. Do we want this in the nav drawer, or the main screen, or do we want a separate News activity? IMO the news activity would probably be easiest for the time being, and would allow us to tidy up the initial iteration based on user feedback before it is placed in a more prominent location. @neslihanturan

[ashishkumar468]

@misaochan yes, a separate activity which could be opened from the nav drawer

[nicolas-raoul]

At first I thought the most obvious would be to display a red notification. But then I realized that I hate receiving Facebook notifications that are about something not directly related to me (such as a message to me or an event about one of my pictures), so that is probably not a good idea. Showing non-important notifications might lead users to just ignore notifications, and thus not see important ones such as someone asking them about the copyright status of a picture.

How about showing each campaign:

• At the first day of the campaign, on the app's home activity, instead of the Nearby notification. The app should remember (in the local database) whether it has displayed that campaign to the user or not yet, for instance if the user does not open the app for two days then the campaign should be shown during the third day. After that campaign-showing day is over, when the app is opened, do not show it anymore, just show the normal Nearby notification, or just nothing if Display nearby notification is off.
• In the Notifications activity's list, but without triggering the red "new notification" signal.

Note: I wrote "first day of the campaign", but we might prefer "one week before the start of the campaign" or "one week before AND the first day AND at the middle of the campaign" or anything similar, with for each a shown-or-not-yet record in database.

Advantages over a nav drawer activity:

• More visible. Nobody would open a campaign drawer activity each week to check whether a campaign has started or not.
• No need for yet another nav drawer item.

[misaochan]

@nicolas-raoul Hmmm. That sounds a little bit complicated to me. ;) If we are going to have it in the main activity, I think it should be OK to just have the campaign news as an additional card underneath the Nearby card? It can stay up for the duration of the campaign as long as it can be swiped to be dismissed, and we remember the user's preference. It does have to be reasonably small in height so that it doesn't take up too much of the screen.

[ashishkumar468]

@nicolas-raoul So to conclude to what you said

• Apart from showing the campaigns in the notification activity, we show it in the HomeActivity as well, under the contributions tab above the contribution (the visibility of a campaign being based on its age)

[ashishkumar468]

@nicolas-raoul If there are any live campaigns going on, can you please add one of them in the repo mentioned, would be really helpful in testing with the actual api's, currently I am using a fork of your repository for the same

[nicolas-raoul]

I don't know any ongoing campaign unfortunately, but we can fake it until
before release.

On Thu, Dec 13, 2018, 23:25 Ashish Kumar <[email protected] wrote:

@nicolas-raoul https://github.com/nicolas-raoul If there are any live
campaigns going on, can you please add one of them in the repo mentioned,
would be really helpful in testing with the actual api's, currently I am
using a fork of your repository for the same

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

[misaochan]

Umm, wouldn't it work if you just changed the date in the emulator? Pretend it's Sep 15. :)

[misaochan]

BTW, how do we handle recurring dates? Currently the year is hardcoded in the JSON file. Is there a way for us to specify the date and month, but have it applicable for every year?

[misaochan]

Reopening as we still need to sort out the recurring dates before we release this. We can just make them 2019 if we have to, and change them every year, but that would really not be ideal.

[nicolas-raoul]

Hard-coding the next 10 years is probably simpler, and chances are low that
any campaign will keep the same dates for 10 years, I would say.

On Sat, Dec 15, 2018, 01:56 Josephine Lim <[email protected] wrote:

Reopened #78
https://github.com/commons-app/apps-android-commons/issues/78.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commons-app/apps-android-commons/issues/78#event-2027313535,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGFBnlUpfxMZBSC5oEGqQMS_gQrwuliks5u49hbgaJpZM4HqKq2
.

[misaochan]

@nicolas-raoul Ah, good point. Should we just add 2019 and 2020 to the JSON file now, then?

[misaochan]

I've added 2019 to the JSON file and fixed the dates etc. If anyone could double check the file, that would be fantastic, but everything appears to be in good working order otherwise. :)