Replace ballpit quest-view in user profile with something else

[westnordost]

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.

[FloEdelmann]

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:

• Bar chart
• Pie chart with outer labels (max. 8 sectors → 7 quest types plus one "Other" sector)
• Pie chart with inner labels (max. 20 sectors → 19 quest types plus one "Other" sector)
• Table with heatmap

[westnordost]

One note, Jetpack Compose does currently not (yet) have an API to animate appearing list items in a LazyColumn (Compose replacement for RecyclerView), which means that e.g. the bar chart could not be animated in in some interesting way but would be - bam - just there :-/

[FloEdelmann]

More playing around with a different tool, Flourish this time. They have much more chart types, including the more interesting ones you suggested:

• Packed circles
• Bubble chart
• Treemap
• Sunburst (basically a donut chart, but with no maximum number of sectors)

[mnalis]

Problematic ideas (IMHO):

• "most boring" example is indeed most boring. Does not suit SC "fun" style.
• not a big fan of Flo's "Table with Heatmap" either. Too boring.
• "pie chart" and "tree map" do not look like they'd be usable - especially as it doesn't look like it would scale too good either (so usability problems), but after seeing @FloEdelmann examples where it seem crowded even with less than 10 quests... For hundreds of them, I think they would likely be completely unusable (checking new Flo's post: yeah, unusable IMHO for real-world scenarios).
• I've had idea of "stack" (i.e. like stack of books one atop the other, some fatter and some thinner), but that wouldn't work either for scalability of 100+ quest for the same reasons as above ones.
• another idea is Tag cloud but that would need shortened text versions (i.e. not full questions texts, but like more folder names from app/src/main/java/de/westnordost/streetcomplete/quests, e.g. recycling, smoking, place_name, oneway, seating, roof_shape etc.). I haven't tried it but it would likely also hit scalability problems. (Also probably not as fun in mid-2020s as it was in early 2000s :smile_cat:)
• from the "fun" perspective, I really like the current "bubbles". While many of them are OK-ish, smaller ones are not very usable to actually get useful information out of them, especially for those who solved more than few question types (like e.g. much of the default set). While that usability part could perhaps be fixed (or at least improved) by combination of "minimum size" and "non-linear scale"; if existing library is going away, it would IMHO likely be too much wasted effort to reimplement all of that from scratch just for "fun effect" - effort which could probably better be used elsewhere. But current implementation is uncontestedly most fun so far.

Usable ideas:

• "Pie chart" looks both quite usable and scalable to big number of quests. Not as fun as bubbles, though -- although if way to animate the bars is found, "fun factor" could be much improved (e.g. start it from the left and start speeding up to the right, and then have small "bounce effect" when it hits the target value. But even regular grow-bar would improve the "fun" factor significantly).

• Another possible alternative, which I guess would be frowned upon (I just don't know by how much :smile:), but just to mention it anyway since we're brainstorming here: have parts of the codebase differ (e.g. OsmAnd style -- some parts are not looking 100% the same on Android and iOS versions). Yeah, I know that that is not desirable from maintainability perspective, nor from UI perspective (it is obviously best if the app looks the same everywhere), but perhaps it might be workable for transition period until better solution is found / written (e.g. keep current fun bubbles on Android where they already work, and put some less fun replacement on iOS for now until better solution is found)

---

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:

• multi-page (i.e. scrollable) solution (like e.g. "bar chart"); probably easiest to implement too
• single page but zoomable (several of ideas above which fail usability test for 100+ quests on fixed screen might work if one could zoom-in on them, as noted. Don't know how problematic such zoom/pan would be to implement, though)
• one fixed small mobile phone view - that IMHO will have to sacrifice much of the usability in the name of fun. IMHO not worth it, unless it is as least as fun as current bouncing bubbles (quick test: put the small kid in front of that screen to play with it and unless they have fun for at least a full minute, it's not worth it. Current "bubbles" implementation passes the test :smile: )

[westnordost]

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)

[westnordost]

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.

[peternewman]

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.

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).

[westnordost]

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.

[trymnilsen]

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! 🚀

[westnordost]

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 StatisticsByEditTypeFragment and StatisticsByCountryFragment, both display each different data currently in this kind of Box2D-powered ball pit view. What data? See Statistics.kt:

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 BallPitView then decides how big the quest bubbles should be based on the count of each and the available space and runs the physics via the to-be-removed PhysicsWorldController (which uses JBox2D). It updates the position and size of the bubbles on each frame from the box2d physics world. All of this is of course not that relevant because that's all Android-View stuff and another interesting visualization with Compose may look and work quite different in the end. But just so you know.

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. After all, the interface for a composable like that would be probably to just accept a List<Pair<Painter, Int>> as parameter (picture + count)... or something....

Note that the compose-stuff is currently on a branch (#5607), but it will be merged soon.

[westnordost]

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.

[mnalis]

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 :smile:

[peternewman]

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?

[trymnilsen]

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 🌼.

[westnordost]

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. This ticket I will keep open of course, just a warning that the code surrounding this screen might change soon.

[RubenKelevra]

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?

• Keep the batches page, as it is, but reset the batches to 0.
• Create a leaderboard for each category and the current week on the star page. So you can see on which place you are and how many more you need until your one place further up.
• If you're at place one at the end of the week, you get a batch.

(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. :)

[westnordost]

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:

• The "conversion rate" of new app users to regular OSM contributors is very low, and I think it makes sense to improve here. So, you will find little features in terms of gamification later on, when you already contributed a lot.

• the achievements and link collection mostly exist to introduce new users to the wider OSM ecosystem and community, get them interested. Basically, the pretty pictures are just there to foist these links onto the users. It's a suggestion to dive deeper packaged in a "gift"

• power-users don't need that much gamification, they are already hitched. Plus, I am aware of that certain people have certain tendencies that would make them easily exploitable through gamification. These tendencies are preyed upon heavily by makers of certain, if not all successfully (free to play) MMO games and in gambling in general (the latter is heavily regulated, the former is not). I am wary of that, because I don't want to be complicit in people exploiting themselves, even if it is for something productive.

• So, this argument is old, and I keep bringing this up all the time even though this might be a bit petty, but if the "game" becomes more important than feeling good about contributing per se, then this may result in a negative impact on data quality. Now, will some leaderboard have this effect? Probably not, but see above, this is not the only reason why I am wary about adding this kind of uh... competitive ... gamification.

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.

[RubenKelevra]

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 bag 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.

[mnalis]

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 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, and 2023's 26 809 SC users. 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)

[westnordost]

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 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, and 2023's 26 809 SC users. 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: https://github.com/streetcomplete/StreetComplete/issues/5595#issuecomment-2308554467 You are receiving this because you authored the thread.

Message ID: @.***>

[RubenKelevra]

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? 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?

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.