Make thrustcurve selection clearer for users#2900
Conversation
Clear motor selection when typing in search field
When a motor is selected, bring up motor detail pane The user is still able to switch panes manually, so (for instance) while a motor is selected the motor filter panel can be brought up without clearing the motor selection
…se, and use it for database operations instead of reimplementing them in ThrustCurveMotorSelectionPanel (I wonder if there are other places this should be done?)
…ThrustCurveMotorSet
Move elements of ThrustCurveMotorSelectionPanel relating to selecting a specific thrustcurve and setting ejection charge delay to the MotorInformationPanel.
Specifically, move
ejection charge delay combobox
hide similar thrust curve
select thrust curve combobox
Also move thrust curve plot from bottom of pane to just under thrust curve selection combobox
… corresponding thrust curve.
|
I had to stare at it a bit but I think I like it. I'm wondering if there's a way to improve the delay selection, while we're at it. I'm thinking a visible list of available delays with radio buttons, plus a blank custom delay field that is also selectable. The current combobox fools a lot of people. I'll try to throw together a mockup, or maybe there's another better way to do it. |
|
I generally like it. I'd like to see a color chip, vs. color text in the curve selection droplist. More color onscreen to assist in discernment. The color text is subtle for me. 
|
|
Here's my proposed enhancement, for consideration (does not include Dave's suggestion above, but I agree with it and would make that change as well): Changes include:
I think that looks pretty good, but will await feedback. |
|
I'm not a fan of moving the ejection charge to under the Show Details as it is now. If however when I highlight a motor the Show Details is automatically switched, then cool.... that makes sense. The ejection charge, the different thrust curves, etc. is all right there. I like the chip color, but for people who are color blind, that makes it hard. Still prefer dropdown with custom text box as opposed to radio buttons. |
|
This is all why I requested comments! Yes, the color chip makes the difference clearer -- I want to do that. Using color at all causes issues for color blind people (my father was red-green color blind. I've got stories....), but I don't have a better idea here. I really like the radio buttons for delay (sorry @thzero). It seems like a clearer way of letting the user know their options. I put the "hide similar" at the top of that section for consistency with "hide OOP", Not important? Yes, when you select a motor it automatically switches to the motor detail pane. While I like all the other changes (I'd better, since I did most of them), that automatic switch is the single most important one. |
|
As the token color-deficient team member, @thzero , I agree that using color can be problematic. For me, I have a hard time discriminating color in thin lines and light text. (Not all colors, but everyone is different...). The general interaction design practice on color is to never rely exclusively on color, but where color is used, have a textual or non-color graphic difference to back it up. Having the text "C6" alongside the color chip is one way this gets backed up (ideally the C6 is in the main text color (black to very dark grey in a "light mode" display)). One could also use boldness in the curve graph to indicate which line is selected: the selected curve is bold and the same color as the color chip, labeled by a black (in "light mode") "C6". I like the radio buttons too. In doing interaction design for about 15 years, one of my biggest enemies was "information hiding". Sometimes you have to use drop lists, but they're really bad at this. For every "State" drop list, where you can reasonably assume the US user is pretty sure they'll find "Alabama, Alaska, Arkansas...", there are dozens of drop lists with non-obvious names, and unknowable hidden contents. It's quite common for usability test participants in an unfamiliar context not to know there are other selectable values in drop lists - even though they're used to choosing "State" from a drop list in a familiar context like an address flow. If the selectable values are unseen, they're as good as nonexistent in the average user's mind, until she's explored and memorized the drop list contents. And many people are not explorers. By contrast, putting the information in radio buttons shows the user the universe of fixed choices available for the datum, and which value is currently selected. In this context, where motors have maybe 3-4 fixed choices for eject delay, radio buttons are a good solution that puts more information at the user's command. (They'd be an awful choice for one-of-very-many values like "State". You can design a show-all-values interface for one-of-many, but you really have to work hard to make it understandable, compact, mobile friendly and more. |
|
Still like dropdowns over the radio buttons, but thats just a personal thing.. radio buttons with the limited # of possible selections is fine. The color swatches can work with like hatch marks or other designs (i.e. a diamond, a square, a circle, etc) to help separate out when color doesn't help. That said, its harder to do the same on the graph... |
No, not in my opinion. Once consistency starts making things worse then it gets tossed out the window. I would venture to guess that use of the "hide similar" checkbox is extraordinarily rare, and so it should be moved out of the way of what the user is really interested in. I would probably also prefer that the "hide out-of-production" box be moved below the table, but I don't think it's causing much harm being up top so it doesn't feel like an urgent change.
It is fundamental to this whole PR; without it you could not in good conscience move critical controls into the details tab. |
…leave the foreground color alone and use a color chip with the same color as the thrustcurve.
Put comments right under thrustcurve chart Move "similar curves" checkbox under chart
One of our not infrequent complaints from users is that a motor in the database has an inaccurate thrustcurve, or that its thrustcurve has changed for the worse. This is typically because our motor selection dialog fails to make clear to the user that a motor may have multiple thrustcurves to choose from. This PR attempts to address this.
At present, when a motor is selected in the dialog, the only indication that the user has a choice of thrustcurves is the presence of the "Select thrust curve" combobox in the upper left corner of the dialog. Notably the "Filter Motors" pane remains selected, as shown in the following screenshot:
In order to see the motor details, the user must select the "Show Details" pane:
Even now, the thrustcurve selection combobox is literally as far away from the thrustcurve plot as it can possibly get and be in the same dialog. Also, the label in the combobox doesn't reflect the selected thrustcurve, as it's black (through version 23.09, the color matched the color of the curve; in 24.12 it does not. I'm actually not sure how that changed; I haven't found where in the code it was set to match in the old versions).
This PR attempts to improve this situation. First, when a motor is selected, the motor detail pane is selected automatically (the user can switch back to the filter pane either by selecting the pane, or by entering text in the search field). The thrust curve selection combobox, "hide similar motors" checkbox, and ejection charge delay are all moved to the detail pane. The thrust curve plot is moved to just under the comboboxes, and the color of the thrust curve selection combobox matches the color of the currently selected thrustcurve.