-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace ballpit quest-view in user profile with something else #5595
Comments
I had a first look into this. As a dataset, I used the 2024 counts from https://piebro.github.io/openstreetmap-statistics/#6773, divided by 1000, to have a rough estimate. Here is a CSV file with those numbers for use in data visualization software: streetcomplete_fake-2024-counts.csv Then I played around with these numbers in Datawrapper (a tool I can definitely recommend for data visualization!), but unfortunately, I could not really create actually interesting plots. These are the ones worth sharing:
|
One note, Jetpack Compose does currently not (yet) have an API to animate appearing list items in a |
More playing around with a different tool, Flourish this time. They have much more chart types, including the more interesting ones you suggested:
|
Problematic ideas (IMHO):
Usable ideas:
As Flo's new list demonstrates, basically everything that tries to put hundred+ entries on one fixed small mobile phone screen is not really going to be usable. So as some general categories of UI:
|
Wow, thanks for the input so far! 👍 @FloEdelmann some flourish diagrams look quite nice! @mnalis , keep in mind that the chart will not contain the names of the quests, but the icons, though. Anything that is not scrollable would probably ideally need to be zoomable and panable to be quite useful, e.g. the tree map, the packed circles, etc.. The bubbles have some kind of physics simulation. But maybe it is too early to be worried about how the hell this could be implemented. As for the pie chart, that is the one I discarded as one of the first, see my remark on the sketch. It also does not use the space very well and even if there was some kind of zooming possible, it would not be very useful. This is why I also deemed the tree chart the best initially, because it can initially fill the whole screen and because the quest areas are rectangular, possibly allowing to zoom in there would be useful. Theoretically, quests could be grouped on one level by the background color of their icon. But anyway, I imagined it would look a little different than what it actually looks like, given Flo's flourish visualization. As far as the fun factor is concerned, and maybe because it looks closest to the current implementation, I like the bubble stats and packed circles the most. These would need to be aligned not roughly in a circle, but roughly to fill the screen though. I will just ask into the room: Does an idea for an algorithm come to mind how to arrange the circles in such a way? Or, as for the bubbles, maybe a physics simulation based on circles that repel each other would be quite easy to implement? (but then, they should also be repelled by the box that delineates the display boundaries) |
I found out that zooming and panning in Compose is almost trivial to implement. Also, I have an idea how physics in such a "bubble chart" could work: Each bubble applies a force towards other bubbles - the closer it is, the higher the force. If it is far away enough, no force is applied. So, basically, imagine it as springs pointing away from the center of each bubble. Each force is a vector with a certain length. For each bubble that is affected by forces, all the vectors are added and the result is the new vector in which the bubble should be pushed. Additionally adding a gravity vector on each simulation frame would be then trivial to add. The screen bounds are then just bounds, i.e. the positions of the bubbles are coerced to always stay within the bounds. The end result may look quite similar as we have now, maybe a bit more quirky / unexpected / squishy. The bubbles would always stay upright, though. (No idea how to calculate radial force) But anyway, not likely that I'll implement this anytime soon because even if I get the simulation right, I don't know Compose well enough yet that I would know how to implement a custom layout that would do this. But in case anyone else would want to play around with this, please go ahead! An intermediate goal could be to not migrate to Compose yet but replace the JBox2D simulation with the simplified one described above. |
Can't you fix this and other related problems by adding some hierarchy? E.g. linked to the awards things are tied to, or the layers. I guess some of it would need either de-duplication or ignoring some awards as I believe some like rare duplicate. Likewise countries could be grouped by continent, although having travelled with SC at some point I'd like to be able to compare in general too. FWIW despite having used it in lots of countries, I've "only" got fifteen countries, but as you say my home one dwarfs most others, and its hard to compare the others because of scaling (maybe it should become logarithmic, but then minor might vanish). TBH a table may be easier/more informative for countries. Country wise, I'm probably a bit abnormal, but my biggest is well over 1000 times more quests done than my smallest (actually Vatican City, but international connections at foreign airports will be similar). |
At the moment, though, being new to Jetpack Compose, the only stats I would know how to implement are the ones on the upper left. As there are enough other things to do anyway, I will just leave this sitting here before implementing the easy (and not so interesting) solution for the slim chance that someone with the necessary know-how and motivation to create cool and fun statistics in Compose sees this. |
Oooh I love these types of challenges in compose, I'd love to take a swing at this once I get a bit familiar with the codebase! 🚀 |
Ohh, wow! Let me provide some more information. Happy to answer anything more. (Find me also on the #streetcomplete channel on OSM slack). That specific view is quite separate from the rest. The fragments this is about are Each, a list of data class CountryStatistics(val countryCode: String, val count: Int, val rank: Int?) or data class EditTypeStatistics(val type: String, val count: Int) The to-be-removed For playing around with this and when you are already proficient with Compose but not with this app, it might actually be easier to do this in a small new compose project because then you don't need to worry about how to rewire it all or worry about what should happen when one clicks on one of the items etc. Note that the compose-stuff is currently on a branch (#5607), but it will be merged soon. |
I just had another possibly fun idea: Bar chart, but with a horse-race kind of animation. I.e. the order of the quests is initially not sorted but they are re-sorted by their current bar chart width and all animate in at the same speed. So, the first second or so will be super chaotic (maybe that can be skipped by pre-sorting them at least a little) and then towards the end you will see which quest will be the "winner". Usually this kind of representation is used when over-time data is available but maybe it will look interesting also like that. |
I've had a vision of Hackers (1995) "Crash Override beats Acid Burn score", but thought it little over the top. It would look quite cool though 😄 |
Just a more general thought, the ones by area (bubbles, tree size or abstract - heat map) have the side benefit of squaring (or thereabouts) as the size increases, rather than linearly. Unless we're going to do logarithmic scales on the bar graphs or something to deal with the rare versus popular quests/countries? |
Sorry for the radio-silence, life has gotten in the way. I'm stilling hyped about making something cool here, but I don't have a timeframe on when 🌼. |
As my funding for the endeavor of porting the app to iOS comes to a close soon, I may soon replace the ballpit quest-view in the profile with a more boring quest statistics screen in order to leave open as little surface area between old UI code and compose code - for consistency and code cleanliness. |
Just my 2 cents: I thought the bubble idea was funny, but I never saw a purpose in them. Why not replace it with something practical, gamification like? I also think the current approach of batches is, well ehm, boring? I mean I'm nearly 50k stars and I really don't care if I get a batch. There's just no value behind it. It's just a couple of things cleared and I get a batch. What do I care if there are 53 or 54 batches for "Cyclist" in my profile? How about doing something else then entirely on the "Star" page then?
(I know that the batches don't align with the bubbles right now, but I think the batches are better as broader categories) This would encourage me do maybe go for another walk on Sunday and there's real value for me behind a batch, because I was the most active user for a week on a category. :) |
Uh well, that would be new features. I just want to be replacing the statistics of solved quests by type and by country.´ Anyway, all that gamification, especially the achievements are a feature that is somewhat aimed at new users to get them hitched on OpenStreetMap in general. This has several reasons:
By the way, my first full-time job was in such a MMO gaming company, so I speak of what I observed there, I am not hallucinating. So anyway, later on when there are no links to unlock anymore through the achievements, achievements don't really make much sense anymore except for the occasional nice picture (that however you've seen 1000 times already). So, maybe something could be done about that... e.g. only show unlocked achievements when there are actually links in it, or something. |
The main issue I bring this up is that the current gamification doesn't work. Like at all. I've showed this app to 3 friends which like to hike and they were questioning me what that weird messages meant. And all I could say is that you randomly get those if you completed some tasks. And that they should just ignore them. 🤷♂️ There's just nothing to back those shiny plates in terms of value. If such a thing would get value, it would mean something to the users to collect them, apart from stars and thus would animate them to do more mapping. It would certainly animate me more, to do some regular mapping. I just remember from time to time to do something, then complete a couple of hundred tasks and then I forget it for half a month again. And yes, any gamification can become addictive. But I'm hard pressed to think that anyone would go visit a doctor because he/she is going for too many walks to map. That's a bit far fetched. Anyway, maybe there should be a "disable all gamification" switch in the settings, just to rest our minds about the possibility of doing harm with that. And yes, that's a new feature, but you plan a new feature to replace the old one. So if everything is even for you, this would be what I would go for: Better gamification. |
TL;DR: I don't think that this proposal would work to entice user to contribute good data to OSM.
Most of gamification problems are exactly the opposite -- the people would stay at home and try to game the system and enter unverified data in the app to avoid getting out and doing the actual on-the-site verification (as going out is too time consuming and inefficient, and thus extremely likely to result in them not winning). Thus damaging both themselves and OSM data / community at large. Anyway, back to your proposal; if I understand you correctly, you basically want to make "stars ⭐" page a duplicate of "trophies/achievements 🏆" page (which you call "batches"?) but instead of having each trophy be based on all-time-solved-quests-count, make it be I-was-first-on-worldwide-scale-this-many-times? Am I getting a gist of it? If so, for vast majority of users (i.e. everybody except exactly-one-person-per-trophy-per-week) all those counters would always remain at zero? Also, you seem to say that your friends all found even original trophies non-motivating and useless. Why do you think that almost-impossible-to-achieve-trophy which would require extreme hardships (i.e. to become number 1 worldwide in some area competing with dozens of thousands of other users) would be more motivating to them? And yet remain healthy at the same time? Footnotes
|
I think there is a misunderstanding.
I am not redoing the statistics, I am redoing the visualization of statistics (for solved quests by type and country), thats all.
…On August 25, 2024 12:09:56 AM GMT+02:00, Matija Nalis ***@***.***> wrote:
**TL;DR:** I don't think that this proposal would work to entice user to contribute good data to OSM.
---
> And yes, any gamification can become addictive. But I'm hard pressed to think that anyone would go visit a doctor because he/she is going for too many walks to map. That's a bit far fetched.
Most of gamification problems are _**exactly the opposite**_ -- the people would stay at home and try to game the system and enter unverified data in the app to _avoid_ getting out and doing the actual on-the-site verification (as going out is too time consuming and inefficient, and thus extremely likely to result in them _not winning_). Thus damaging both themselves _and_ OSM data / community at large.
(and also, problem with addictions is that most people _won't_ go to see the doctor, but rationalize to themselves that _"they're not actually addicted"_, thus making further addiction progress even more likely and more damaging)
---
Anyway, back to your proposal; _if_ I understand you correctly, you basically want to make _"stars :star:"_ page a duplicate of _"trophies/achievements :trophy:"_ page (which you call _"batches"_?) but instead of having each trophy be based on all-time-solved-quests-count, make it be I-was-first-on-worldwide-scale-this-many-times? Am I getting a gist of it?
If so, for vast majority of users (i.e. everybody except exactly-one-person-per-trophy-per-week) all those counters would always remain at zero?
If I understood how that would work correctly, I fail to see how such thing is supposed to be motivating for the vast majority of the mappers (who would _never_ be number one in _any_ of the categories)? Or is it supposed to be motivating to rare few, at the expense of being demotivating to everyone else?
Also, you seem to say that your friends all found _even original trophies_ non-motivating and useless. Why do you think that almost-impossible-to-achieve-trophy which would require extreme hardships (i.e. to become number 1 worldwide in some area competing with [dozens of thousands](https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_users_(distinct_uids)) of other users) would be more motivating to them? And yet remain healthy at the same time?
I mean, I like SC gamification, but **I doubt extreme-spartan-training for many hours each day for near-zero-chances-of-success** (less than `0.04476%` chance per week[^1]) **would motivate me much** (in fact, I likely would find such extremely low chances of getting a trophy equally extremely depressing and not worth even attempting _trying_ for! Even worse would be if I found it worthwhile goal, as it would likely mean I'd not care about quality of data as I did about getting that _"almost unattainable score worthy of bragging about"_ - you just can't care about both issues at the same time: _one of priorities would have to give up_; and it likely would _not_ be the addiction).
[^1]: Given [12 achievements](https://github.com/streetcomplete/StreetComplete/blob/9c567ccea2dc4151121e91c2b749b53d6e7dc04b/app/src/main/java/de/westnordost/streetcomplete/data/user/achievements/AchievementsModule.kt#L23-L36), and 2023's [26 809 SC users](https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_users_(distinct_uids)). So, if all users were motivated enough (i.e. assume uniform distribution for simplicity), each one would have about 1:2234 chance of getting a single trophy. And if the trophies were given once-per-week (and assuming ~52-week years), and I didn't botch the calculations, **each user would get one trophy on average every 53 years**. I.e. about once in a lifetime (_if_ they were a _really dedicated_ lifelong mapper).
Of course, in reality, some users will try significantly harder, but that would mean (1) others will have even less chance to ever win a single trophy even if they map every day of their lives, and (2) that the **rewarded users** will be heavy outliers on that Gaussian curve, quite likely to have **serious addiction problems** (and thus also quite likely not to care about OSM data quality as much as they did about their addiction of trying to getting a trophy)
--
Reply to this email directly or view it on GitHub:
#5595 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Well, no. Not world-wide but instead break it up into smaller regions. I've seen a lot of people respond well online to number 1 in their country for a week. So the idea is to make this thing which works great to be more easily achievable by splitting it up into the categories we currently already have. So you'll get a medal if you're the best one in one category in your region, highlighting the local improvements in one aspect. I think that could work well. |
We are currently using
org.jbox2d:jbox2d-library
for the physics simulation that is happening in the ballpit view in the user profile for the quest solved statistics (per-quest-type and per-country).There is no Kotlin Multiplatform replacement for this.
While Box2D exists as a C++ library and thus it is theoretically possible to add bindings to that in Kotlin, I deem this far too much effort to preserve functionality that is essentially a fun gimmick. A gimmick that has clear downsides, too: With the number of quests we already have, the view is becoming more and more imperformant and most quest types are not properly clickable because they are just too small. Also, the ballpit never worked that well for the per-country-stats because there is usually one bubble that dominates all.
So, we need a replacement for this, ideally something that is also fun and interesting to look at. But the effort or feasibility to implement it (in Jetpack Compose) needs to be taken into account, too.
Proposed Solution
For now, I'd like to collect some ideas what could be done. I created some sketches.
Do you have other ideas? Do you have ideas or hints how to implement one or the other?
Especially the tree map I find interesting, but not sure how to implement it or if the end result actually looks fine, given the lack of really hierarchical data. I would appreciate if someone interested would squeeze some actual quest statistics data through a program that is able to create such a visualization to be able to judge if the end result can look good.
The text was updated successfully, but these errors were encountered: