Closed samreid closed 4 months ago
@samreid and I worked on this and ran into the following design issue:
I don't see a way to get the heat map tools to also serve as a history tool. The speed and angle tools were designed to display data as they are collecting it, similar to a 'radar gun' as it is registering speed data. It was not designed to be a way to navigate prior data, but rather a live stream of data with a qualitative snapshot of the spread (the heat map itself).
In light of this design limitation, I think this issue can be closed. If we decide to redesign the speed/angle tools, then this may be possible in the future.
If we decide to pick this up at a later date, here is the patch from the work that @samreid and I started on this before running into design limitations:
I am not fully understanding why this issues was closed.
@terracoda and @matthew-blackman I discussed this further:
Reopening for design meeting discussion
Was this re-opened because of interview feedback?
@terracoda I reopened this to discuss the QA question as to whether some users could possibly be confused by this (although QA was not confused by this).
After meeting with the design team, it was determined that there are significant challenges to changing the design of the heat map tools due to the following constraints:
One proposed idea is to "null out" the heat map readout/needle when selecting a previous projectile. This could improve confusion in some cases, but also introduces a new source of confusion:
If the projectiles land out of order, and then the user selects previous ones, and then goes back to selecting the most recent one, the number/needle would now reappear, despite being out of sync with this projectile. This would send the message that they are in sync with the most recently landed projectile (since the value/needle just become non-null), whereas this will not be the case. I find this design to be more complicated and error-prone than the current design.
The original design of the sim (and its current behavior) calls for the heat map tools to update when a new projectile is launched. Changing this rule be conditional when a previous projectile is selected is more complicated, and in my opinion will leave even greater room for user confusion. It was also noted by @KatieWoe that she was not actually confused by this behavior and figured it out within a few seconds. As of now, no user interviews or workshop attendees have expressed confusion in the behavior of these tools.
In the interest of simplicity/consistency, @ariel-phet @samreid @Nancy-Salpepi and myself are recommending that we leave the heat map tools as is. If the user selects a previous projectile and the tools are not updating, it should be clear that those readings are not tied to the selected projectile.
It might look disruptive to have the launcher switch wile navigating data points, but would it make sense to make the launcher match the launched data point when navigating the the data points?
I do not fully understand the purpose of navigating the data points. What is a learner supposed to be looking for when navigating the launched data points.
@terracoda this would introduce several other issues. I'm happy to discuss synchronously since they are not directly related to this issue.
The following patch was used for demo/discussion during the 4/11 design meeting. It is an initial draft for the behavior in which the heat map tools are always synced with the selected projectile:
I hear the points raised above. Discussing this with @ariel-phet, we summarized the design considerations for this issue as follows:
For these reasons, we are recommending to keep the heat map tools the way they are. We feel that they are doing a good job at addressing the learning goals of the sim, are consistent with lab tools, and have a very straightforward and learnable UX.
Closing this issue, but anyone is welcome to reopen it if there are further ideas to discuss or explore.
Thanks for the example. It seems clear the red heat-map lines are not supposed to be directly connected to the purple path lines.
My main concern is/was how will the additional launch angle variability be audibly presented down the road through TTS (voicing or interactive description). Some variability is already represented through sound. I feel it is important to think about this now as it helps determine what information is truly essential to the learning goals.
I completely understand that not every piece of information is essential for the main learning goals, but everyone needs equitable access to readily available information.
Its about finding the right place from which we can interactively make the additional launch angle variability values accessible down the road.
As recommended by @terracoda in https://github.com/phetsims/projectile-data-lab/issues/107#issuecomment-1986172915, When selecting an earlier projectile, the speedometer and angle gauge needle should indicate the selected projectile. When a new projectile is launched, it can show that data.