pixelzoom
commented
3 years ago - [x] The control panel is too tall for the available space. I've addressed that by moving the "Continuous Waveform" and "Envelope" checkboxes out of the control panel, and putting them below the charts that they are related to. This is similar to what we did in Discrete screen for "Auto Scale" and "Infinite Harmonics" checkboxes. Is this OK?
DECISION: OK
- [x] The Java version had a checkbox whose label changed from "x-space envelope" to "t-space envelope", depending on whether "Function of" was set to "space" or time". It's shortened that to "Envelope", which is a relevant term that is independent of domain. I didn't feel like we needed to repeat the domain information in yet-another place. It's already shown in the x-axis label, many other control labels, etc. Is that OK?
DECISION: OK, but rename to "Waveform Envelope"
- [x] The Java version labeled the top slider in the control panel as "Spacing between Fourier components". This was much too long to fit in the HTML5 version control panel. I shortened it to "Component Spacing", is that OK?
DECISIONS:
-
Needs a stronger connection to "Fourier series".
-
Reorganize the control panel into titled "Fourier Series" and "Wave Packet" subsections, see https://github.com/phetsims/fourier-making-waves/issues/81.
-
Investigate changing terminology from "Component" to "Harmonic" throughout this screen, see #78.
-
[x] Could the top chart benefit from having a title? We have room for a title, and I think it might currently be a little unclear what this is showing, how it relates to "Component Spacing", etc.
DECISION: No title, revisit if necessary later.
- [x] Sliders are not long enough for the number of decimal places in their associated values. For example, the 2 sliders for Wave Packet Width have 2 decimal places, but it's impossible to iincrement by 0.01. The situation was the same in the Java version, and it was not possible to enter specific values with the keyboard. Is that OK in the HTML5 version?
DECISION: Getting to specific values is not important in this screen. Number of decimals is OK, no need for finer-grain control.
- [x] All 4 sliders have labels that change based on whether "Function of" is "space" or "time". That makes using NumberControl relatively complicated. So far, I've made the decision NOT to use NumberControl here. There's a small trade-off for PhET-iO and (perhaps) a11y. Thoughts?
DECISION: Tracking in https://github.com/phetsims/fourier-making-waves/issues/80.
- [x] I'm a little confused about how controls are labeled, and want to double check. For example, symbol "k" is documented in the Info dialog as "wave number". So is it accurate for Component Spacing to show "k1 = 1.5 rad/m"? If k1 is a wave number, how can it also be a value in rad/m?
DECISION: @arouinfar will investigate in https://github.com/phetsims/fourier-making-waves/issues/79.
- [x] For "Wave Packet Width", the 2 quantities shown are not actually the width. The top slider is 1/2 width, and the bottom slider is 1/topSlider. Should there be some changes here to make this clear?
DECISION: Change bottom slider to have ticks at 1/(4pi), 1/pi, 1
- [x] Should we still remove leading '0' from decimal values? The Java version does this for tick marks on sliders and charts, but it feels a little sketchy. e.g. '0.2' -> '.2'
DECISION: do not strip off leading zero
- [x] For "Wave Packet Width", there are 2 sliders related quantities. The relationship is
topSlider * bottomSlider = 1. Having 2 sliders interacting like this is going to be a headache for PhET-iO, since we'll have to do special things to manage state save/restore. The relationship between that values is not at all obvious or easily discovered. The ticks on the bottom slider aren't particularly useful, and we can't label the bottom slider as 1, 1/pi, 1/(2pi), etc. because the tick marks would all be crammed together. I'm wondering if it would be better to remove the bottom slider, and replace it with a readout that says (e.g.) σx = 1 / σx = 0.235 rad/m
DECISION: keep both sliders
- [x] If we continue to have 2 sliders related to Wave Packet Width... When you start dragging a slider, is it OK to disable the other slider? Dragging both at the same time is possible with multi-touch, presents several implementation challenges, and doesn't really seem to be useful or necessary.
DECISION: interrupt input on the other slider instead of disabling
- [x] Do you want the "Minimize graph to improve performance" label on the Components charts, as in the Java version? Performance is very likely to be an issue in the HTML5 version, as it was in the Java version.
DECISION: Ideally no, but TBD for performance.
- [x] What do you want to do for the Components chart when component spacing is zero? (infinite number of components). Do you want to hide the chart and display a message "Cannot show infinite number of components" like the Java version?
DECISION: Hide only the plots. Message "An infinite number of harmonics cannot be plotted." Equation above the chart would remain unchanged -- not like the Sum equation.
- [x] Do you want the charts to update only after the sliders have been released, as in the Java version? This is very unlike other HTML5 sims, and is not directly supported by Slider and other UI components.
DECISION: Try to make it responsive as we're dragging, but OK if it's a performance issue.
- [x] Should the wave packet center or width sliders snap to any intervals? There are currently continous. If they snap to intervals, do we need addition UI controls for entering finer-grain values? (keypad, arrow buttons,...)
DECISION: No. Getting to specific values is not important in this screen. No need for finer-grain control.
The design document section for the Continuous screen has not been fleshed out:
As I started on the Continous screen, I was a little surprised to see this, because PhET typically treats a port to HTML5 as an opportunity to improve and update the sim. @arouinfar clarified in Slack by saying that the Continuous screen should have "identical features to Java, but match any applicable UI changes that we made for Discrete". That works for features that overlap with the Discrete screen, but does not address the many features that are unique to the Continuous screen.
So I'll use this issue to post design questions and suggestion as I implement. And we can spin things off into separate GitHub issues as needed.