Replace ballpit quest-view in user profile with something else about streetcomplete HOT 13 OPEN

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.

from streetcomplete.

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

from streetcomplete.

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

from streetcomplete.

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?

from streetcomplete.

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)

from streetcomplete.

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

from streetcomplete.

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 😸)
• 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 😄), 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 😄 )

from streetcomplete.

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)

from streetcomplete.

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.

from streetcomplete.

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

from streetcomplete.

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.

from streetcomplete.

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.

from streetcomplete.

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 😄

from streetcomplete.