[Bug]: On the personal page, some numerical values are not legible on the smartphone (too small)
Summary
On the personal page, some numerical values are not legible on the smartphone (too small)
Steps to reproduce
go to personal overview
Expected behaviour
the figures should be displayed larger
Actual behaviour
the numerical values are too small
-
On the personal page, some numerical values are not legible (too small).
-
Their meaning is unclear to me (also (i) does not clarify sufficiently (what number of what: 4317/2560 or 709/1280? What refers to what?))
-
An overview of the images used would be nice (by tapping on (here) "(709/1280)")
Device name
Google Pixel 7 Pro
Android version
Android 14
Commons app version
4.2.1~14b6c455b
Device logs
No response
Screen-shots
https://commons.wikimedia.org/wiki/File:20231215_xl_0658_xl_CommonsApp-Screenshot.png https://commons.wikimedia.org/wiki/File:20240218_xl_1731-Commons_App_Feedback.png
https://commons.wikimedia.org/wiki/Commons:Mobile_app/Feedback#Feedback_from_Molgreen_for_version_4.2.1~14b6c455b_7
Would you like to work on the issue?
None
How about removing the circle around the text OR replacing it with Linear Progress Bar, since it will give more space for text to breathe?
Linear progress bar sounds good. :-)
I would like to take it up.
@nicolas-raoul Few Questions before starting it up. is there any way to test the code on production environment. This requires testing on production environment (currently leaderboard is only supported on production environment not on debug).
Few Questions before starting it up. is there any way to test the code on production environment.
Yes, you can use the prodDebug build variant to test the production server.
This requires testing on production environment (currently leaderboard is only supported on production environment not on debug).
Actually, the leaderboard is supported on the prod flavour, not on the beta flavour. But it works on debug variant correctly (since to test the release variant you'll have to sign it, it's better to use the prodDebug variant). To know more about flavours and build variants look up this
I would recommend always using prod, unless you are actually uploading and have zero self-authored encyclopedic pictures.
@nicolas-raoul just a proposed solution, not a thought towards complexity & priority.
This is the current the UI we currently have
** This is the solution which will solve this issue, increase performance, and good user experience, removal of third party dependency (<com.dinuscxj.progressbar.CircleProgressBar)**
If we wish to go with this my view would be revamp the fragment_achievement due to linear nesting, third party dependency and not use the recycler view as of now.
Once this get merged we can start working on adapting this towards recycler view if we wish. Thus reducing the complexity and number of changes.
This is what I thought feel free to leave the feedback is it worth a go?
Just a friendly ping @nicolas-raoul, Can i implement the proposed solution?
Is a recycler view really required?🤔I don't think we've too many changes from the server side, the list isn't dynamic (I do not see a possibility of 100s of list items in future too). Only the stats change, and we need an appropriate way to display them so that they're legible enough as the number of digits increases.
Is a recycler view really required?🤔
Well, you are right there is not much need for it. Listview will do all the work.
So, in order to fix 1/2 issue of the current above issue, can I alter this like this and this refactor will fix the issue on smaller devices.
What do you think about this @RitikaPahwa4444 ?
The numbers are much more readable indeed. :-)
Keeping this page attractive and fun is important, it should look like a game stats page.
How about something like this (with a green progress bar, and 18/25 instead of 60%):
How about something like this (with a green progress bar, and 18/25 instead of 60%):
Works fine. Working on it.
@neeldoshii I unassign for now, but if you are you still working on this, please let us know. If no answer, someone else may be assigned to it. Thanks a lot. :-)
Hi @nicolas-raoul, I am quite occupied lately It would be best if someone who can take it ahead. for someone who's working on this u can take this reference #5666
@neeldoshii Understood, thanks! 🙂