Closed matthew-blackman closed 1 year ago
Here's a mockup of all 30 balls stacked in the same location with the accordion box remaining the same size and the soccer balls auto-scaling in the y-direction only.
And one where the accordion box also resizes. Note the soccer balls still have to shrink even when the accordion box is expanded.
@kathy-phet said on slack:
I actually prefer not making the accordion box bigger.
The auto-scale seems like a good solution so you can see all of the data points together in the abstract representation in the accordion box. Since users will have to manually stack the balls in the same location, the auto-scale will not be jarring as they will shrink one ball at a time.
I tried to make the modelViewTransform a Property. Is this the right approach?
Here's a start at scaling the data points through a scaleProperty
. It's a bit of a rough implementation, I think the logic can be cleaned up quite a bit, and it is also only handling when the data points need to scale down, doesn't handle scaling up quite yet. I think it would be good to pair with @samreid for next steps to see if we like this better than the MVT route.
Patch:
Updated patch:
Screen recording of sim with above patch:
@chrisklus and I chatted through a couple of different scenarios with this autoscale, and we think it should be brought to designers... there's some behavior that seems potentially confusing or undesirable.
A common solution for all of these is to scale when we know a ball could potentially end up in a tall stack. This would make it clearer to the user that something is being added to the stack.
This patch is not much different than Matt's but just cleaned up some vestigial code.
Met with @catherinecarter and we decided that we do not want to autoscale due to the complexity that arises in dev implementation as well as user interactions. We decided that instead we will scale the data points down as maxKicks goes up.
For example:
These percent scales are just examples to illustrate the decision and will probably not be the actual numbers used in the end
The data points are now scaling based on the maxKicks preferences. @catherinecarter sending your way to interact with and see if this solution works for you to handle the visualization of more data points. Changes are pushed up to master.
I like how there's a 1/2 an 'x' and 1/2 a dot at the top to indicate the markers are going off the screen and there are more up there.
The 70% is pretty small. Since there's a half object to indicate going off the screen, I'm thinking they don't need to be quite that small when the max kicks is set to 30. Let's try 100%, 95%, 90% and 85% and see how it looks. Thanks, @marlitas!
Awesome! I made them a bit bigger in the above commit. Just for reference the scaling you were actually looking at was:
Now they are:
We tweaked the scales to line up so that only half of a datapoint is obscured. Do those sizes look better?
They look better, but I think the points on the max = 30 are still a bit small. It looks like a pretty big difference (noticeable) between 25 and 30. Thanks for the actual references percentages - when I was looking at max = 15 and 20, I was having trouble noticing any difference at all, so I'm glad it wasn't me! Haha!
Let's bring up the percent on the max = 25 and 30 so the increments are smaller between them and hence, less noticeable. I'm becoming less and less worried about it now that I have in my mind the info box will show all the data. Maybe rather than leaping by 9% and 11%, we leap by 4% and 7% or something?
Okay, here it is with a smaller difference between the 25 & 30 data points. I wasn't able to have maxKicks = 25 at 94% because it didn't line up with cutting off the "x".
MaxKicks = 15, DataPointsScale = 98% MaxKicks = 20, DataPointsScale = 98% MaxKicks = 25, DataPointsScale = 91% MaxKicks = 30, DataPointsScale = 83%
From 6/6/23 meeting, the scaling is good to go! Closing.
If the user has a tall stack of soccer balls, we want to autoscale the size of the data points in the accordion box so that all of the data is visible.