Feedback on how my pictures get used: Statistics, barnstars, light gamification

[nicolas-raoul]

One-way communication can become boring, so how about a page that shows how the pictures I have uploaded are being used?

• Number of images used in Wikipedia/Wikivoyage/etc articles
• Number of images that have been edited by someone else (including simple description typo fix and categorization)
• Number of images that have been featured or received other kinds of awards
• Received barnstars
• Received thanks if the feature becomes available on Commons

The main goal is to give uploaders an incentive to continue (light gamification), but the statistics could also include some negative statistics too:

• Number of deleted images (must be with a link to the deletion discussion/reason)

[tobias47n9e]

I think "streaks" are also a great gamification element, that are used by many language learning apps (e.g. Duolingo). The most recent consecutive days/weeks are counted that a user has uploaded an image. I think it would be possible to get that from the Commons API.

[nicolas-raoul]

Ideas from @tobias47n9e:

something like number of downloads would be motivating. I also like the concept of streaks (e.g. Duolingo). For this app that could be the count of consecutive weeks/days that the user has uploaded a picture (Not just on mobile, which probably makes it easier to query that from Commons API?).

Number of downloads would be great, but I am not sure we can know it? If it is possible please someone give an example query for a user, thanks!

While streaks are great for study software, I am a bit afraid that streaks for Commons might result in people in uploading more pictures of their cat? Imagine I worked from home today, did not go outside, and haven't seen anything Commons-worthy at all, if I am in a streak I might be tempted to upload a picture that I would otherwise consider unworth of Commons.

[nicolas-raoul]

Web request to get the number of images used on Wikipedia, and all other details: https://tools.wmflabs.org/glamtools/glamorous.php?doit=1&username=Syced&use_globalusage=1&ns0=1&show_details=1&projects[wikipedia]=1&projects[wikimedia]=1&projects[wikisource]=1&projects[wikibooks]=1&projects[wikiquote]=1&projects[wiktionary]=1&projects[wikinews]=1&projects[wikivoyage]=1&projects[wikispecies]=1&projects[mediawiki]=1&projects[wikidata]=1&projects[wikiversity]=1

[nicolas-raoul]

For what it's worth, here is how Google motivates people to upload more pictures. I guess they are as interested in data quality as us. I wonder how they deal with people who upload crap.

[urbanecm]

Hello all,

I've created a simple API that allows you to fetch numbers needed for such statistics more fastly than by asking MediaWiki API directly.

It's at https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback.py?user=Martin_Urbanec. This script return JSON.

By default, the script returns all data that it can get from database. This may take long time so the script accept another parameter called "fetch" that can restrict what will be calculated. Just pass the key from the JSON returned without fetch parameter and only such value will be calculated. If you want to calculate multiple values at once, just pass them at once divided by '|'.

For example, if you want to know only the number of thanks, the url will be https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback.py?user=Martin_Urbanec&fetch=thanksreceived . If you want to know number of thanks plus number of featured imges, the URL will be https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback.py?user=Martin_Urbanec&fetch=thanksreceived|imagesfeatured.

Explanation of values returned

• status - can be ok or error, indicate if the request was successful
• errorcode - if status=="error", then errorcode describes what actually happened - currently, the only possible value is "mustpassparams" which means that you didn't pass the user get parameter
• imageseditedelse - returns number of uploads that have been edited by somebody else
• imagesfeatured - returns number of uploads that are featured/recieved some kind of award, it's a dictionary, key of that dictionary is a category name on commons that contains images that received particular award
• imagesused - number of images that was used somewhere on Wikimedia projects
• imagesnumofusings - number of usings of uploads of examined user - for example, if you uploaded 1 image and it was used 100 times, imagesused will be 1 and imagesnumofusings will be 100
• thanksrecieved - number of thanks received
• user - user who was examined

Hoping this will help you with this issue. If somebody want to examine my script and SQL queries that was used, see https://github.com/urbanecm/commonsmisc/blob/master/feedback.py.

Be warned that this script may execute for quite long time. If needed, I can add some caching to that script. I suggest implementing some "loading data" screen in the app.

Feel free to contact me if you need some other data or similar script.

Best regards, Martin Urbanec Wikimedia Czech republic https://meta.wikimedia.org/wiki/User:Martin_Urbanec

[nicolas-raoul]

@urbanecm : Very cool! Would you mind adding this documentation to https://github.com/urbanecm/commonsmisc/blob/master/README.md ? Do you plan to maintain this tool for a few years?

[urbanecm]

Docs) Not at all, just forgotted... Will ad ASAP.

Plans) Yeah, that's my plan.

[nicolas-raoul]

@maskaravivek "Thanks" are now available on Commons, I just tried.

By the way, it would be great if the statistics could be shown in an encouraging way. For instance, "Thanks: 0 Awards: 0" is discouraging, on the opposite a greyed-out "achievement" box like in games or like in Snapchat (screenshot below) feels encouraging, I think.

[misaochan]

Thinking about how to get this to work with GSoC/Outreachy. Since this is going to be only half of the intern's project, we probably don't want something too involved.

My suggestion would be to let users access their "profile" through clicking an icon next to their username in the nav drawer. In this profile page, we would display stats like:

• Number of images used in Wikipedia/Wikivoyage/etc articles
• Number of images that have been edited by someone else (including simple description typo fix and categorization)
• Number of images that have been featured or received other kinds of awards

We can use the API created by @urbanecm for all of these.

Thoughts anyone?

[maskaravivek]

Yes, the scope of this task looks feasible to me. As a stretch goal, we could consider showing the statistics as suggested by @nicolas-raoul to make it visually more appealing. :)

[misaochan]

Sounds good to me, indeed the UI design should be part of this task. :)

[gupta-meghna64]

I had thought of an idea, wherein we could grant titles to a user based on the statistics obtained. For instance, a title could be "Lightning Uploader" which signifies that the user has his current number of uploads > a threshold(say 25). Could these titles be added to the mediWiki pages of the user in titles received section? Since, if we are awarding a title to the user, then we should give the user a privilege that he/she should be able to show it off to everybody else, otherwise this won't serve as a strong incentive. Please give your suggestions on this @nicolas-raoul @misaochan @maskaravivek :)

[ayushin78]

I was thinking that we should create levels like in games where levels will be updated according to the game points earned by the user. The user can be awarded game points according to his statistics such as

• For every new Thanks Received, 5 points

• For every Quality image, say 10 points

• For every Featured Image, 20 points

Whenever the user will cross the threshold for each level for example , 50 for level 1 , the level can be updated to the next one. In the profile dashboard, A progress bar can be shown along with the points received and the points required for next level.

In a section below the progress bar, We can display the name of Awards/titles in an achievement box as suggested by @nicolas-raoul and users can be given the titles such as 'Centurion' on receiving 100 thanks or 'Veteran' if featured images > 10. It will look something like this :

@nicolas-raoul @misaochan @maskaravivek, Kindly provide your suggestions on this :)

[maskaravivek]

Sounds like a great idea to me. Gamification is what we want to drive more engagement.

I am just not sure about the feasibility of this task as part of GSoC/Outreachy. :)

[misaochan]

@gupta-meghna64 I personally like your idea of having titles. However... perhaps @nicolas-raoul can confirm, but I don't know if adding that to the MediaWiki page of the user will be feasible? As it would only be available for app users, so it may possibly drive a larger wedge between us and the browser-based Commons community (I don't know if it will, just hypothesizing).

@ayushin78 Levels looks nice to me, too. :) But like Vivek says, it may be a bit too much for the scope of a GSoC/Outreachy project, especially given that our project has 2 tasks (this and tutorial/quiz) already. Perhaps add this as a stretch goal, where if you finish your project ahead of time then you can start on it?

Another thing to note (for both of your suggestions) is that we don't want to grant titles/levels for pure quantity. We need to encourage users to upload quality photos. So if we go with this, my suggestion would be to award for images used in articles or images featured, or maintaining a low deletion rate of, say, <5% (if we can find the API for it).

[nicolas-raoul]

Here are a few examples of ranking systems for inspiration: https://community.jivesoftware.com/thread/258122 https://ux.stackexchange.com/questions/67013/alternative-reward-levels-to-gold-silver-bronze https://community.canvaslms.com/thread/15047-name-the-levels

The best would be to have a photographer-themed or reporter-themed ranking system, here are a few examples (but feel free to come up with something else or modify as you wish):

• Point-and-shoot newbie -> Autofocus novice -> Digicam enthusiast -> Reflex master -> Composer -> Bokeh ninja -> Focus stacker -> White lens whisperer -> Studio chef -> Large format -> Raw guru -> (hidden)Hot pixel -> (hidden)Chromatic aberration -> (hidden)Burned out
• Mowgli (because he lived extraordinary adventures but did not document much of it) -> Benjamin Franklin -> Judith Miller -> Ibn Battuta -> Bob Woodward -> Joseph Pulitzer

If "points" is too boring, we could use focal lengths, for instance 45mm, etc.

@gupta-meghna64 The relevant Wikipedia tradition https://en.wikipedia.org/wiki/Wikipedia:Barnstars is to post the award on the person's talk page, and the person who received it can then move it to their user page if they wish. Modifying wiki pages is tricky (ex: conflicts) so how about just saying "You can add the award on your user page if you want", with a link to a page where the wikicode for all awards is available?

@ayushin78 The screenshot looks great!

[tanvidadu]

In many of online games I have played, instead of providing points they provide coins. We can also provide coins to users instead of points and allow them to buy stickers( of different cost) . We can allow users to share the stickers they bought. Coins can be given to user on the basis of barnstars, appreciations as well as images featured. This encourage users to upload quality images. we can initially start with few stickers in the initial release and then add more stickers depending upon current challenge on wikimedia or any viral theme in subsequent release.

[gupta-meghna64]

@nicolas-raoul even being able to add the award/title on your own user page could be a big incentive for the user, as by this way you atleast have your awards on web and your app! So, we could probably take this idea forward.

[nicolas-raoul]

How about "reputation"? "Reputation" sounds more in phase with the Wikipedia spirit (free, collaborative) than "coins" or just "points".

Reputation could "unlock" some features that are dangerous for newbies. For instance, I firmly think that multiple upload is not a feature to put in the hands of newcomers, who sometimes use it to upload their whole photo roll. The implementation of unlocking can wait until later, but that's an incentive to keep in mind.

[misaochan]

Oh, I had no idea a framework for barnstars already existed! It would be good to post it on the user's talk page indeed. However, who do we post "as", since AFAIK only users can post on another user's talk page?

I also agree with reputation sounding better than coins.

[ayushin78]

The idea of using the photographer-themed ranking system is great and the levels mentioned are also very cool. Using focal length or reputations also seems better than points/coins.

[tanvidadu]

@nicolas-raoul @misaochan reputation sound even better than coins and we can allow users to unlock stars on the basis of their reputation and depending upon stars we can allow users to access restricted features. In the Initial release we can focus on the stars part and in the later releases we can add the functionality of restricted features. The more stars the person has more reputed or experienced he is. P.S. : it will require less work than designing stickers and will be more interactive.

[tanvidadu]

@nicolas-raoul @misaochan @maskaravivek @tobias47n9e when a user receives a barnstar on a image uploaded via commons, is he/she notified through notifications?

[urbanecm]

I just unsubscribed from this issue. If you need anything about my API or anything else similar APIs (existing/new), please either re-add me as subscriber or if not possible (I don't know GitHub iface so much), ping me on-wiki (Martin Urbanec) or by e-mail (martin.urbanec@wikimedia.cz). Cheers, Martin

[harisankerPradeep]

The idea of reputation and awarding tags sounds great! But it becomes attractive only if we can show some kind of statistics on how many people have x points or who has the most coveted tag or so on. If the user doesn't have any context i.e if he doesn't know how many people have x reputation or how coveted the tag of "Raw guru" is it becomes rather pointless, doesn't it? @nicolas-raoul @misaochan @maskaravivek, what do you guys think?

[nicolas-raoul]

@tanvidadu Giving a barnstar is just writing a paragraph on a user's talk page, so there is no special notification, just the generic notification that someone wrote on your talk page.

@harisankerPradeep Most wiki editors edit for their own pleasure and don't compare themselves to others ( notable exception: https://en.wikipedia.org/wiki/Wikipedia:Editcountitis ) I have never seen any page listing the number of times barnstars have been given. StackOverflow says how many times a certain badge has been given, but most social apps do not. I don't think we really need to add the information, especially if it is not readily available.

[nicolas-raoul]

New York Times' insight on contributor motivation, that might give us some ideas: https://www.nytimes.com/2018/03/28/nyregion/if-you-see-something-write-something.html

[harisankerPradeep]

That was an interesting read...

[tanvidadu]

For the implementation of the Gamification feature, I have come up with a strategy: Depending upon the images Featured, used and thanks received , we can calculate "reputation" earned and depending upon the "reputation" earned we can assign titles.
In second phase I will extracting no of reverted uploads. They can also be used as a parameter to calculate "reputation".

Please let me know any changes needed ! I have some doubts : 1) No of images modified by someone else should be used as a positive parameter or negative parameter. 2) I am unable to come up with a strategy for fetching Barnstars. In case there is a method or strategy that can used , please let me know. 3) should I work on badges instead of titles?

[nicolas-raoul]

1. In the wiki spirit, having your work edited is a good thing. It means the content was considered important enough to build on. But of course, if it was edited because you entered no description/categories then it is not so good... how about counting edits as positive, but also give reputation for a description over 30 characters and over 2 categories?

2. Commons people don't use barnstars much, unlike Wikipedia. No need to take them into account, I would say.

3. Badges are probably easier to translate, so yes I guess 🙂

On Fri, Apr 27, 2018, 21:32 Tanvi Dadu notifications@github.com wrote:

For the implementation of the Gamification feature, I have come up with a strategy: Depending upon the images Featured, used and thanks received , we can calculate "reputation" earned and depending upon the "reputation" earned we can assign titles. In second phase I will extracting no of reverted uploads. They can also be used as a parameter to calculate "reputation". In case I get time in the end I can work to incorporate badges in the feedback module. Please let me know any changes needed ! I have some doubts :

1. No of images modified by someone else should be used as a positive parameter or negative parameter.
2. I am unable to come up with a strategy for fetching Barnstars. In case there is a method or strategy that can used , please let me know.
3. should I work on badges instead of titles?

— 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/85#issuecomment-384956349, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBqkzaTDpiesFNxnDuIYyo__0Gfxhks5tsw_hgaJpZM4HscBp .

[tanvidadu]

Thanks @nicolas-raoul for your feedback ! Based on the discussion and time constraints I have come with two mock-ups : one for title and other for badges. Please suggest improvements in these mock-ups. Thanks :) https://marvelapp.com/5450777

[maskaravivek]

Great to see you come up with these mockups so quickly. :)

The mockups look quite clean and intuitive at first look. Here's my feedback on the same,

• The username isn't exactly required as of now because the user can just see his Feedback in the app.
• The text (The more quality images...) could possibly be replaced by a question mark (?) and on tapping it, this tip/description can be shown. This would make the screen a bit cleaner.
• Consider adding some units after the number (maybe 100 points or something).
• Check if there's a native element present form progress bar(100 to next title... bar). If not you can consider modifying the design so that a custom UI element need not be built.
• Inside the circles (featured images, images used by Wikimedia etc.) you can add the actual counts. Moreover, can you briefly explain what does the progress in the circle signify?

Seeing the second mockup, I like it more because it is visually more appealing.

• Maybe you could consider showing the current level with a progress bar below it showing how much points are needed for the next level. The progress bar can be a bit thinner in that case.

[tanvidadu]

Thanks @maskaravivek for your feedback. I have modified the mock-ups as suggested.

• The circles will be show the percentage ( wrt to maximum value that can be attained in each level) of the progress in each of the respective field.
• I will implementing the progress using horizontal progress bar.

[misaochan]

Great job with the mockups, @tanvidadu ! 👍 The UI looks fantastic to me in general, and I really liked that you took the initiative to add 2 minor features (the Share option and information icon - those will indeed be very useful).

A few suggestions:

• Minor change: The title of the activity. Generally we don't use ALL CAPS for our titles, but rather Camel Case. Also, "Feedback" feels a bit vague to me - I know that is the title of our GSoC project but it isn't terribly useful to the user. How about "Achievements"? Anyone have any thoughts on this?

• In addition to the percentages for "Images used by Wikipedia" etc, how about letting the user know the exact number needed for the next level? Something like 24/100 (in small text somewhere) could indicate that they need 76 more, which might be more helpful than solely a percentage.

• A more general discussion point: I am uncertain how we intend to make the 3 metrics correspond to a level. Featured images in particular are VERY hard to obtain (I am not sure if I even have one, haha), so blocking levels behind that could feel rather frustrating to the user. To quote Commons: "There are currently 11,176 of such images in the Commons repository which is roughly 0.024% of the available images (46,444,974)". Thanks received also fluctuates a lot depending on other users.

Instead, I think we might want to separate "Statistics" and "Progress" metrics. "Statistics" would not contribute to the level, but would just be there. Whereas "progress" would be required for the level.

So we would have something like:

Level 1

Progress to next level - user needs all requirements satisfied to progress

• Images used by Wikipedia articles: 2/5
• Percentage of uploads NOT reverted: 90% (minimum required: 85%) - side note: I think using images NOT reverted would be better than the inverse since higher is better
• Images uploaded: 25/30 - side note: I know we said we didn't want this, but IMO this would not be a bad metric as long as % of reverts is also a requirement? It might give users incentive to upload, but they can't upload crap because if they fail the revert check, they will not progress. The code for this can be copied from contributions activity.

Statistics

• Featured images: 2
• Thanks received: 5
• [Optional: If time allows] Images edited by other users: 30

And so on and so forth for level 2, level 3 etc? What do you guys think?

Edit: Also, uh, I'm not sure why but I'm only seeing 1 mockup, not 2 like Vivek mentioned? I think it may be best for you to post your mockups as screenshots in comments here rather than in a link that is often modified (you can still keep the link, but additionally provide screenshots). That way we can keep track of which suggestions have already been implemented and what a mockup looks like at a particular point of time. Currently I'm not sure which of Vivek's suggestions have already been implemented. :)

[tanvidadu]

Thanks @misaochan for the feedback! I completely agree on separating "progress" from "statistics". The suggested "progress" and "statistics" parameters looks great to me ! I will start incorporating all the changes suggested.

I have already worked on Changes suggested by Vivek, as result on the latest mock-up was available on the link. I have included all the mock-ups I have made and shared up till now both here as well as on the link.

After Change

Before changes : 1) For titles

2) For Badges

I had a doubt regarding badges : Should the badges be made level specific or achievement specific. I am more inclined towards achievement specific badges like when a user has one of its upload featured, received 50 thanks etc. What do you guys think ?

[misaochan]

Thanks for clarifying! :)

For the badges, I think both would be nice. But due to time constraints, maybe we could go with level badges first (like the one you have in your mockup) and just list the number of thanks etc. Then if you have time at the end of the project, you can add badges for the achievements you mention?

[tanvidadu]

Sound good to me ! I will incorporate the changes mentioned above ! Thanks :)

[maskaravivek]

Separating statistics and progress metrics seems to be a great idea. I also agree with the basis on which @misaochan has defined the levels.

I was wondering what exactly the Share button would do. IMO, it would be nice to take a screenshot [programmatically]of the whole Feedback/Achievements page and let the user share the image. Android exposes a very simple to use API for this purpose.

[tanvidadu]

I initially added share button to share the image of badges and level on different social media platforms but taking screenshots of whole screen sounds much better. To make separation more pronounced in the achievements screen I have changed the mock-ups a bit.

[misaochan]

@tanvidadu That mockup looks great to me!

One final note - I think we need to make it clearer to the user what the minimum % of non-reverted images is to progress (since this metric is a bit different from the others). The simplest way I can think to do it is adding the text "(min req: 85%)" after "Images Not Reverted". However, that does look a bit unsightly, so if you can think of a better way to put it that would be great. If not, we can go with that for the MVP.

[nicolas-raoul]

Background information about thanks

All thanks given, by day: https://commons.wikimedia.org/w/index.php?title=Special:Log&limit=500&type=thanks As you can see, in 6 days, 938 thanks were given (156 thanks per day), to 459 different users. Unfortunately, most thanks are about discussions rather than for uploads. For instance user Jeff received 11 thanks last week but none for uploads. So, receiving 1 thank should be considered a great achievement already :-)

Background information about featured images

Currently zero picture uploaded from the app has been featured. It might be because of the rather low resolution of mobile pictures compared to professional cameras. Featured images must be really really perfect.

Background information about quality images

Currently zero. Many of our pictures would get the award, but the nomination process is web-based and people usually nominate their own pictures, which is not easy from mobile.

Ultimately, getting used in Wikipedia or another wiki is the best thing that can happen to a picture :-)

[maskaravivek]

The mockup looks great @tanvidadu.

IMO the (i) button at the top could have information about the requirements to get to the next level. If we wish to make it more visible then maybe we could have a little (?) in front of the tags for eg. Images not reverted (?). The (?) could be a link

• that opens up a dialog showing more information or
• expands and shows a subtext explaining how to get to 100%

[tanvidadu]

Thanks for feedback :) Thanks @maskaravivek ! Its a great idea and solves the problem addressed by @misaochan above. I will incorporate it the mock-ups .
Thanks @nicolas-raoul for giving me an insight on how the parameters work :)

[misaochan]

@tanvidadu I guess the next step would be to search for the appropriate APIs to extract the data you need? If you are having trouble, especially with the revert rate API, I would recommend posting at https://commons.wikimedia.org/wiki/Commons:Village_pump to ask if anyone knows. They might be able to point you in the right direction. :)

[tanvidadu]

thanks @misaochan , I was facing some difficulty finding the required api to fetch number of reverts. I will post my query on village pump for the same.

[tanvidadu]

In second criterion of the level where less than 10% uploads should be reverted. Should we cover only the revert scope( reverted to its previous version ) or should we All include in our scope other parameters like nominations for deletions and no of rollbacks ?

[misaochan]

Sorry for the lack of clarification, I personally think we actually want "deletions", as in number of pictures uploaded by that user that were "deleted". I don't think "reverts" is the commonly-used term in Commons, but rather more suited for Wikipedia (anyone, please correct me if I'm wrong). I don't think we should include nominations for deletions, but only those cases where the nomination passed and the file was actually deleted. We don't need a % per se (although it would be nice), but if we get the number, we can simply calculate percentage by dividing by their number of uploads (which we already have).

Would be good to wait for consensus first, though. :)

[tanvidadu]

For the info button on top right corner of the screen, I was thinking of going with Material Showcase to give user information about the different parameters. On clicking the info button we can display information about the different parameters. What do you guys think ?

[misaochan]

Just the info button will do for now I believe, we can consider additional improvements after the MVP is finished. :) My thoughts on level requirements as you requested (others, please feel free to comment):

Level 2 Images used by Wikipedia articles: 5 Percentage of uploads NOT reverted: minimum required 85% Images uploaded: 20

Level 3 Images used by Wikipedia articles: 10 Percentage of uploads NOT reverted: minimum required 86% Images uploaded: 30

Level 4 Images used by Wikipedia articles: 15 Percentage of uploads NOT reverted: minimum required 87% Images uploaded: 40

So on and so forth in a linear manner for images used and images uploaded. We probably want to cap % uploads not reverted requirement at 90% and keep that for all the following levels.

Thoughts?

[tanvidadu]

For level up badges I was thinking of designing single structure which can be done used for different level with few changes like color, level up information. This approach will provide allow us to have flexibility in terms of increasing the no of levels as an when required without actually increasing or designing more badges. And also maintain the size of the apk.

In Middle I will be writing the Level Number dynamically using Canvas ( e.g. LEVEL 1 )

There are two sample designs for structure :