Population graph design issues

[pixelzoom]

The Proportions graph differs from the Java version, there are some new requirements. It has a data probe, and there is no pause that occurs when environmental factors are applied. So there are a few significant issues that have not been addressed by the design:

• If plots overlap, one or more sets of data will be hidden. For example, if there are equal numbers of bunnies with white fur and brown fur, only one data set will be visible.

• If points are connected with a sloped line (as shown in the design doc), that presents 3 big problems: (1) The data probe will be taking invalid measurements along the slope. The slope is showing something that never happened. Snapping the data probe to avoid the sloped portion of lines will significantly complicate implementation of the graph and data probe, not to mention feeling wrong and jerky to user. (2) The sloped line can't be plotted until both points are known, but the graph is supposed to be continuously updating at the "now" position. So how do we draw a sloped line when we don't know its endpoint? And what do we draw until we know the endpoint? Backtracking and revising the line is the only way to work around this - it will look odd, and it will be complicated. (3) If we figure out how to address (2), the actual bunny population will be out-of-sync with what's shown on the graph between the 2 points that define the slope. This is problematic when using the Step button and the data probe.

• If applying food and wolves is "continuous" versus "all at once", it will result multiple data points per cycle of the generation clock. This will cause the sim to hit its memory limit more quickly. One thought is to apply at a few discrete points during the clock cycle, rather than on every step.

I'm working on the Population graph now, so working out these design issues is relatively high priority. I'm going to proceed and do the best that I can to implement something that is flexible.

[amanda-phet]

If plots overlap, one or more sets of data will be hidden. For example, if there are equal numbers of bunnies with white fur and brown fur, only one data set will be visible.

I think we can order the graphs in the order they are seen in the panel. So, if there are equal values to plot, Total would be on top and would occlude the other graphs with equal values. And so one. It is a bit of a usability issue with line/step graphs, but I'm not sure there are great options here. Happy to brainstorm some more.

Let's discuss the other issues with the team since @pixelzoom you and I have already talked about them.

[amanda-phet]

6/11/20 design meeting: will draw a step function with vertical connection lines between jumps. At the leftmost edge of a horizontal line there will be a circular dot to indicate where the probe is collecting data.

[amanda-phet]

Another idea that @oliver-phet thought of is putting circles right on the probe at the point where it overlaps the graph, so it's really clear where we are reading the data.

@pixelzoom Does this seem like a feasible option too? I think we still want to move forward with the above decision, but perhaps this could be an additional visual cue.

[pixelzoom]

... Does this seem like a feasible option too? ...

Yes, it's feasible. It will be a significant chunk of work - likely a day or two. There's already a lot going on with this graph, so I'm concerned about information overload. And I'm also concerned about how the circles will be interpreted, because they are not connected to the displays at all. So... I'm going to hold off on "circles on data probe" until the graph is working. There we can evaluate to see if we feel that the circles are necessary.

[amanda-phet]

OK, well let's keep it in mind but not move forward with the circles on the probe. Let's see how it looks when we implement the above decision.

[pixelzoom]

One potential problem with the solid (filled) points is that they are not differentiated for mutation vs normal alleles. For example, this example could be a little confusing at the rightmost edge of the graph:

[pixelzoom]

@amanda-phet this is ready for review in master and 1.0.0-dev.58.

Everything is implemented except the points that move along the data probe (as described in https://github.com/phetsims/natural-selection/issues/101#issuecomment-642927906). I'll be happy to implement that if you feel it's necessary or want to see how it feels. But this graph is already feeling pretty "busy" to me.

Of the bullets listed in https://github.com/phetsims/natural-selection/issues/101#issue-634979291, the overlapping plots seems like the biggest issue currently. I don't know how to address that, or whether it needs to be addressed. Keep that in mind as you review.

[amanda-phet]

Can we make the solid filled points slightly smaller? Maybe 80% the current size?

I also wonder if we can do anything to the dotted lines, since sometimes a change in population has a funny looking "jump". can you make the spaces between dashes a bit smaller? And possibly make the dashes a tiny big longer, depending on how that looks.

I am not sure there is much we can do about overlapping graphs, and the current graph seems superior to the Java version because of the handy data probe, and the fact that you can choose which graphs to view at any given time. All of those features increase the usability of the graph, IMO.

I'd like to also review this with @kathy-phet and @ariel-phet for their insights.

[amanda-phet]

5/25/20 meeting: we'd like to consider the white intersection circles after interviews. Otherwise this all looks good.

[pixelzoom]

@amanda-phet Does "Otherwise this all looks good" mean that you don't want any changes? Or do you still want the diameter of the points and the line-dash spacing tweaked?

[pixelzoom]

I've reduced the radius of the points to "80% the current size", from 3 to 2.4.

Re the line dash...

Scenery specifies line dash as an array that describes the dash pattern. It's currently [3,3], which means that the dash and space between the dashes are both 3. It's easy to change that to anything that you want. But if the dash is made too long, it may look like a solid line between closely-spaced points. And we will such points if/when we kill bunnies incrementally instead of all at once.

If I understand the "funny looking jump" that you reported, there is also no way to eliminate that. There will always be such jumps where points occur within the line dash pattern. A plot is not individual line segments where the dash starts over for each segment. For performance, each plot is a single scenery Path, and the line dash continues along that entire path.

Not reported is a more noticeable issue with the dashes lines occurs when the graph begins to scroll. The dashed lines appear to strobe, instead of staying in a fixed location. I'm not sure how (or whether?) to deal with that yet.

[amanda-phet]

The dot size looks good to me, but I think others on the team disagreed that it needed to be smaller. @kathy-phet @ariel-phet @oliver-phet want to weigh in? In particular, when I zoom out and see more graphs layered, I like how the smaller dots overlap less. However I'm fine with the larger too if others prefer it.

For the dashes, I'm not sure which is the dash length and which is the space, but can you try changing the spacing to be 2? If it doesn't look good we can revert it, I just thought it would be worth playing around with some values. I understand the plot is not individual line segments, which is why I wanted to tweak the spacing. A different dashed line pattern would produce a different looking plot, but I'm not sure exactly where to make the tweaks, or if any will "fix" the situation I observed.

[pixelzoom]

The general form of the lineDash array is [dash, space, dash, space,...]. I've changed it to [3, 2] in master, so that the dash is 3 and the space is 2.

[pixelzoom]

@amanda-phet and I discussed this issue on Zoom, summary:

• We're happy with the revised point radius and line dash pattern.
• The revised line dash pattern has eliminated the "funny looking jump".
• The issue of the dash appearing to move along the line has been moved to #111.

There are no other outstanding issues here, so this issue can be closed.