Apps-android-commons: Leaderboard

[nicolas-raoul]

Need

From the research paper "Sharing small pieces of the world": Increasing and broadening participation in Wikimedia Commons:

Respondents also expressed a desire to compete with others
“to be the first to do something” and some said that the
“social component” was missing altogether

A leaderboard would motivate many people, it seems.

Feature description

The score could reuse some numbers from achievements, but should only count edits done with the mobile app, because otherwise Vicuna/etc users will dominate the top of the leaderboard even if they don't use the mobile app.

Actually, I suggest listing in the leaderboard only the users who have ever opened the achievements activity. We must keep track of that information server-side. So the leaderboard would only list app users who have an interest in this kind of game.

Tapping the name of a user in the leaderboard should open the gallery of that user's pictures, probably as a browser URL for now. Knowing they are being watched by their peers will probably reduce the temptation to "cheat" (for instance by uploading 1000 pictures of the same spoon)

The user's name should be highligthed. Random idea: The length of the leaderboard could be dynamic, for instance if I am 3rd it could be 10 people, but if I am 13rd it could be 20 people. Or just make more people appear when scrolling down.

There could be weekly (last 30 days) rankings, yearly (last 365 days) rankings, all-time rankings.

To make it more visually attractive, I suggest using as a kind of avatar the user's most successful picture (the one which is used the most in the wikipedias/etc, or a random one if the user's pictures are not used yet anywhere). Random idea: Users like to personalize their avatar, so we could also offer the option to select one of the user's uploads as an avatar picture, but that may lead to more selfies, so this option could be an privilege to unlock (only users who are above level 5 for instance).

There is a lot of data to show, so we have to think the UI carefully. Here is just an idea:

The vegetable is a placeholder for the user's avatar.
I forgot to write the position number (1, 2, 3, etc). It is important because I want to know whether I climbed from 37th to 36th, and counting is boring.

Implementation

The leaderboard lists should probably be calculated on the server where we currently perform achievement calculations, and cached (re-serve the same results if less old than 1 hour). The user will probably upload a few more pictures in 5 minutes and come see the leaderboard again. So we could recalculate only that user's new scores (and let the other people's scores the same until the next hour comes). In other words, only the users who keep looking at the leaderboard would have their score grow at smaller intervals than 1 hour. That 1-user-only recalculation itself should be cached something like 1 minute because a picture can not be neatly uploaded in less time, and to avoid useless server load.

The avatar miniatures (generated by mediawiki) should be cached by the app for like a month.

[ujjwalagrawal17]

@nicolas-raoul The idea looks great to me but we need to start and manage our own server-side app to integrate this feature as this feature is not there in the commons website and we don't want to count website contribution. Which language/framework do you prefer to write the server side code.

I think we can do this in NodeJS or Django (Python) framework.

[ujjwalagrawal17]

@maskaravivek @misaochan @ashishkumar0207 What are your opinions on the backend tech stack for our app?

[ujjwalagrawal17]

I just noticed that https://github.com/commons-app/commonsmisc has some scripts written for achievement calculations.

[maskaravivek]

Yes we can add the APIs in commonsmisc itself. It's hosted on tools forge and is written in python

[nicolas-raoul]

Feedback about https://github.com/commons-app/apps-android-commons/issues/2367#issuecomment-470164814

I don't think we need an option. Any user who opens Achievements should see the leaderboard (maybe the Achievements activity's tabs could be Level (current activity)/Nearby/Used/Uploads.

There is no Wikimedia API for level/avatar/leaderboard, we have to create our own, probably on commonsmisc.

I don't think we need duration filters. Better get a big JSON from commonsmisc that contains everything already (level/statistics/leaderboards for nearby/used/uploads week/year/all)

Cheers!

[ujjwalagrawal17]

I don't think we need duration filters. Better get a big JSON from commonsmisc that contains everything already (level/statistics/leaderboards for nearby/used/uploads week/year/all)

@nicolas-raoul @misaochan If we get all users at once than that may be possible. But it may take a lot of time.

I think we may still need duration filters in frontend and backend because the number of users in leaderboard may be very large so we need to implement pagination too and in that case we can't sort the list locally (in frontend) and get the correct result as the all time top 10 contributors may not be the same as weekly/ monthly top 10 contributors.

I have updated the project schedule according to feedback.

The project is about adding a leaderboard based on user's edits using Commons. The feature will include only edits made with the mobile app, and users who have shown interest in this activity.

Project schedule :

1. Update UI of achievements activity to display level (current activity) in first tab and Leaderboard in second tab (based on uploads).
2. Designing and implementing the APIs for calculating and displaying ranks of the User (all time, monthly, weekly).
3. Display user's Avatar and rank on Leaderboard screen fetched from API.
4. Designing and implementing the APIs for displaying leaderborad (user list) based on 2 parameters - duration (all time, monthly, weekly), type (uploads, nearby, images used).
5. Use the APIs to fetch leaderboard (user list) based on uploads via mobile app (all time) and display it in Leaderboard screen.
6. Add pagination in the leaderboard screen to load more users on scrolling down.
7. Add duration filters in leaderboard screen and show results based on selected filter (weekly, monthly, yearly, all time). Change the UI to show and select filter.
8. Change the UI to show 3 different results (based on uploads, nearby, used). - add 2 more tabs
9. Tapping the name of a user in the leaderboard should open the gallery of that user's pictures, probably as a browser URL for now.
10. Write unit tests , documentation, fix bugs and Release (at least in alpha) - (2 weeks)
11. If time permits, Add option for users to change Avatar, Store user's Avatar in cache for a month.

[maskaravivek]

@ujjwalagrawal17 Can you also update the description on Outreachy portal. :)

[ujjwalagrawal17]

@maskaravivek vivek Yes have updated the description in phabricator and Outreachy portal.

[nicolas-raoul]

We can not afford to calculate on-the-spot, even if we split durations it is still too much data to calculate.
So, the leaderboards must be calculated little-by-little, probably automatically.

Example:
1) Calculate the whole leaderboard once per day
2) When UserA opens the learboard activity, calculate only UserA's statistics, and fill the rest with pre-calculated data.
3) Save that as the newest version of the precaculated data, so that when UserB opens the leaderboard activity they see the data calculated at the beginning of the day + UserA's data calculated at step 2 + UserB's current data

[Lyndaar]

Hi, so i was supposed to contribute to the application by building the leaderboard activity, i have gotten the fact that it would have to be a tab on the achievement activity.
but i wanted to ask if there is a UI for this. kinda a ui representation and secondly i am finding it hard to locate the api path for leaderboard{i.e what it is fetching or its results, i need help with the exact api path to consume since it is calculated in the server}

[nicolas-raoul]

@Lyndaar There is no API yet, actually designing and implementing the API is part of the project :-)

[Lyndaar]

Okay, so how do we get to implement the leaderboard for the android dev,
because from what I can see, we would have to just build the interface for
where the leaderboard would be seen, till there is a leaderboard Api path,
that can be consumed to that part of the interface.

I stand corrected though.

On Mon, Mar 25, 2019, 08:14 Nicolas Raoul <[email protected] wrote:

@Lyndaar https://github.com/Lyndaar There is no API yet, actually
designing and implementing the API is part of the project :-)

—
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/2074#issuecomment-476080436,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ap73jLgDmofDf-EnsKfti81rISqM_LO4ks5vaHc3gaJpZM4ZAetW
.

[nicolas-raoul]

You have to design the API, then develop both the server part (that takes data from the database and provides it as JSON) and the client part (that consumes the JSON and displays it in the Android app).

[ujjwalagrawal17]

@nicolas-raoul I have updated the project schedule in phabricator, https://github.com/commons-app/apps-android-commons/issues/2074#issuecomment-470481841 and outreachy's website so that students don't get confused.

[nicolas-raoul]

@ujjwalagrawal17

"display level (current activity) in first tab and Leaderboard in second tab (based on uploads)."

I guess you mean "display uploads in the second tab"?

"Leaderboard" is the name of the whole feature.

[nicolas-raoul]

@Lyndaar Are you planning to apply for Outreachy? The deadline is very soon.

[Lyndaar]

yeah, i have made a contribution though, but i am still confused , cause i
thought the api building was for the web guy while we the android dev
consumes the api to build or improve the functionalities of the app

On Tue, Apr 2, 2019 at 11:37 AM Nicolas Raoul [e-mail]
wrote:

@Lyndaar https://github.com/Lyndaar Are you planning to apply for
Outreachy? The deadline is very soon.

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

[nicolas-raoul]

In this case, there is no API available, and we don't have separate web/android teams, so we need to be on both sides :-)

[maskaravivek]

@silkypriya Can you post the designs and database schema here. We can discuss further here. :)

Also, please create an account(@silkypriya and @ujjwalagrawal17) on tools admin(https://toolsadmin.wikimedia.org/) so that I can add you as maintainers. I have created a test project for working with tools forge while developing the leaderboard. Eventually, we will make the deployment in the prod tools forge app.

[maskaravivek]

Regarding the leaderboard, I was wondering how should the user start showing up in the leaderboard?

Option 1: With User consent via some popup

The user can say yes to be included in the leaderboards and from that point onwards, we can consider him for leaderboard rankings.

Option 2: Automatically when the user performs one of the actions

We can automatically add the user in the leaderboard, once he performs any of these actions

• login
• or upload
• or nearby upload

In our backend, we are planning to have:

• a list of users(with option 1 or 2) for whom we need to calculate statistics
• periodically fetch the statistics (every 1 or 4 hours). Update the statistics in our tools forge DB
• When the Commons app does an API call to get leaderboard info, serve the statistics using tools forge DB instead of calculating real-time.

@nicolas-raoul @misaochan @neslihanturan @ashishkumar468 It would be great to have your opinions on this flow.

[nicolas-raoul]

I would say option 2. Less intrusive, and other rankings already exist on the Wikimedia sites so it is not like we require their approval.

Sounds great!

[silkypriya]

Hello @maskaravivek,
The database schema link : https://docs.google.com/document/d/1cb6ABJqcHLR1YxdZoaat53xE9tAbcBvkR4tORvGwBTg/edit?usp=sharing

I have added a Leaderboard table in existing commonswiki database for storing leaderboard information. Would like to get your suggestions.

Have created an account on tools admin (username: Silky Priya 44).
Thank you!

[ujjwalagrawal17]

@maskaravivek I have also created an account on tools admin (username: ujjwalagrawal17)

@silkypriya can you post the design mockups shared in https://github.com/commons-app/apps-android-commons/pull/2978 here also. According to the new UI, we are not merging Achivements and leaderboard.

We will decide this after getting everyone's opinion that we should merge leaderboard with achievements or we shouldn't.

[misaochan]

I agree with Option 2. :)

[silkypriya]

Hello,
Leaderboard UI can be implemented in either ways.

1. Update UI of achievements activity to display level (current activity) in first tab and Leaderboard in second tab.
   PR: #2996
   

2. Add Leaderboard item to navigation drawer
   PR: #2978

Navigation Drawer | Leaderboard Activity
:-------------------------:|:-------------------------:
|

Which one would be better to proceed with? It would be great to have your opinions on this.
Thank you!

[nicolas-raoul]

About the way to open the leaderboard, I would say 1, in order to not cram the navigation drawer.

[ashishkumar468]

Regarding the leaderboard, I was wondering how should the user start showing up in the leaderboard?

Option 1: With User consent via some popup

The user can say yes to be included in the leaderboards and from that point onwards, we can consider him for leaderboard rankings.

Option 2: Automatically when the user performs one of the actions

We can automatically add the user in the leaderboard, once he performs any of these actions

• login
• or upload
• or nearby upload

In our backend, we are planning to have:

• a list of users(with option 1 or 2) for whom we need to calculate statistics
• periodically fetch the statistics (every 1 or 4 hours). Update the statistics in our tools forge DB
• When the Commons app does an API call to get leaderboard info, serve the statistics using tools forge DB instead of calculating real-time.

@nicolas-raoul @misaochan @neslihanturan @ashishkumar468 It would be great to have your opinions on this flow.

Option 2 seems plausible.

[ujjwalagrawal17]

@nicolas-raoul, in the long run, we are shifting the UI to have bottom tabs instead of nav-drawer so I think we can proceed with design 2.
Similar to what is shown in: https://docs.google.com/presentation/d/1bvY8f3Vv9Tf8jzNTVuSfVvvjeaEsLypnlI39mQYOcRE/edit?ts=5cea64ef#slide=id.g57b021ae21_0_19 (We can put the leaderboard in the more section)

@misaochan @neslihanturan What are your opinions?

If everyone is okay with 2nd design we can proceed with https://github.com/commons-app/apps-android-commons/pull/2978 PR.

[misaochan]

I would vote for Design 1. Not necessarily because of nav drawer clutter (as you say, that will only be temporary), but because it feels like it makes more sense and will be more visible to the user. When they go to their Achievements, they have the immediate option to see where they stand compared to others. Putting it in the nav drawer feels like we're not tying together 2 features which are inherently very strongly related.

However, if time is a factor (since it's a GSoC project), I'm OK with either design. I prefer Design 1, but I'm not against using Design 2. We can always change later.

Edit: I just saw that the PR was already up for Design 2. Let's go with Design 2 in that case, no need to redo everything.

[bharathbiju]

would it be better if the leader-board icon was placed near the bell icon ?

[misaochan]

As we discussed in the Hangouts group, I do not think it is a good idea to have the leaderboard icon on the app bar. The notifications icon will not stand out anymore if we clutter the bar up.

[madhurgupta10]

As we discussed in the Hangouts group, I do not think it is a good idea to have the leaderboard icon on the app bar. The notifications icon will not stand out anymore if we clutter the bar up.

With the new Android phones coming in with Notch and Hole Punch Camera we should not put it in a place where the user can't access it easily.

[maskaravivek]

@bharathbiju Can you post the other mockup that contains the UI of the leaderboard screen?

[bharathbiju]

design 1

i came up with this idea after talking to @misaochan on hangouts

design 2

or i was not sure if he was telling like this

what do you think @maskaravivek ? i also loved your idea to bring a bottom navigation bar

[ujjwalagrawal17]

I think white background will look better. As all other pages have white background. (Media details page also will be having white background according to new design).

[kbhardwaj123]

@ujjwalagrawal17 I completely agree, in the default mode we should have White background

[madhurgupta10]

We should have support for both the Dark and Light Themes just like all other activities of the app.

[bharathbiju]

@kbhardwaj123 and @ujjwalagrawal17 i was preparing this for the dark mode and totally forgot about light mode , thanks @madhurgupta10 for remaining of it, will prepare mock ups for both.

[misaochan]

We should have support for both the Dark and Light Themes just like all other activities of the app.

Yes, this would be ideal IMO.

[bharathbiju]

would you guys support a bottom navigation bar ?

[sivaraam]

would you guys support a bottom navigation bar ?

IMO, it would be inconsistent to use it given that we don't have a bottom navigation bar anywhere else in the app.

[bharathbiju]

@sivaraam i meant a common bottom navigation bar , when i looked through the previous suggestions there was a encouraging support for this idea. i would like your opinion also on this @misaochan

[sivaraam]

i meant a common bottom navigation bar

By "bottom navigation bar" if you mean a [navigation bar found at the bottom in the below screen shot, I mean the same thing too :man_shrugging:

Moreover, the material design guideline for using bottom navigation bar _recommends against_ using the bottom navigation bar for single activities/tasks. It's recommended to be used only for top-level destinations.

[318anushka]

For APIs implementation, how about we use flask.
It offers several extensions like Flask-SQLAlchemy as orm. I find SQLAlchemy as a good option for communicating with database due to high level of abstraction and ease to handle changes.

[misaochan]

i would like your opinion also on this @misaochan

Do you mean in the Profile activity? I think sticking to tabs (for Achievements and Leaderboard) would be a better idea than a bottom navigation bar, for the reasons that @sivaraam mentioned.

[madhurgupta10]

I would like to share my mockups for the leaderboard.

There are 2 design choice
Design 1 - Screen 1
Design 2 - Screen 2 and Screen 3

My preference is Design 2 because it is more organised and won't crowd the screen too much

[maskaravivek]

I like Design 2 as its much cleaner. Just to clarify Week, Year, and All are buttons and not view pager tabs, right?

[madhurgupta10]

I like Design 2 as its much cleaner. Just to clarify Week, Year, and All are buttons and not view pager tabs, right?

Yes, similar to the ones we already use in Nearby section

[neslihanturan]

Thanks for the designs @madhurgupta10 , but I think we should avoid usage of nested tabs. Lets think about other ways: https://material.io/components/tabs#placement

[ashishkumar468]

Agree with @neslihanturan on this, how about non-swipeable (and just clickable) bottom nav?

[neslihanturan]

Agree with @neslihanturan on this, how about non-swipeable (and just clickable) bottom nav?

bottom nav is also not suggested for using non app level tasks :/

[neslihanturan]

Also, I think Week, year, month element should also be changed. They can't be chosen all together, logically right? I would instead use a spinner https://developer.android.com/guide/topics/ui/controls/spinner

[madhurgupta10]

Also, I think Week, year, month element should also be changed. They can't be chosen all together, logically right? I would instead use a spinner https://developer.android.com/guide/topics/ui/controls/spinner

Yes, we can select only one at a time. If we can use two spinners to avoid nested tabs?

[sivaraam]

Just a minor thing about the wording. I believe "Usage" would be better than "Used" for the tab name.

[nicolas-raoul]

Yes two spinners sounds good :-)
First spinner: Upload/Nearby/Usage
Second spinner: Week/Year/All time

[sivaraam]

I happened to stumble across this discussion about how "any [wiki] editor must opt-in to allow other editors to see additional statistics". I remember something about an opt-in being discussed here for the Leaderborad. Just wanted to confirm if that's correct. If yes, how would a user opt-in? Also, would there be a possibility to opt-out? 🤔