-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keypad allows you to enter values that are out of range #135
Comments
The above notifies the user that they are out of range, and does not allow them to enter. @arouinfar and I looked at it and liked it. @pixelzoom , assigning to you to review. |
Comments/suggestions: (1) The "Range" message needs to be localized. Add something like (2) Consider making the message 'red', and changing the foreground or background of the invalid value to 'red'. Test for colorblindness. (3) Consider interviewing to see if students have a problem with this. It's a non-standard way of indication an error, and the value and message are about as far apart as they could possibly be. |
To support the case whether there are no units, run the string through I.e.:
|
Thanks for reviewing @pixelzoom! @andrea-phet I really like suggestions (1) and (2). There have been a few other changes made, such as #88, #126, #132, #134, so it may be worth doing 1-2 confirmation interviews. What do you think @ariel-phet? |
Re:
In Unit Rates, we used 'red' foreground (vs background) to indicate an incorrect answer to a question. It also seems more consistent to use red foreground for both the value and message. So I would start with changing the foreground color and see how it looks. Then change the foreground of the value back to 'black' the next time one of the Keypad keys is pressed. |
@pixelzoom how about that? I also checked with @arouinfar already. |
When the user presses any Keypad key (numbers, decimal point, backspace), shouldn't the message be hidden and the value fill be restored to 'black'? |
For example:
So far, so good. Now here's what I'd expect:
But what I see is:
|
Thinking about this more.... Perhaps it is appropriate to keep the "Range" message visible until the user hits Enter again -- since they've made a range error, it's useful to see what that range is. But I think the text should turn to 'black' as soon as they begin to edit the value. |
More... I don't understand the logic for turning the value 'black' when there's 1 digit. For range 1-5000, if I enter '5001' (for example) and hit the backspace, then '500' is a valid value. For range 10-100, if I enter enter '1', then later press '2', then '12' is valid. |
I was trying to turn the value black when the user presses another digit (because it should turn black with next key press, so that was a workaround), but I see now that there are loopholes. |
I like it @andrea-phet! @ariel-phet are you ok with returning "Range"? |
Doesn't "Range" have another meaning in this sim's domain? How about using the quantity's name, e.g. "Mass: 1 - 5000 kg". "Drag Coefficient: 0.04 - 1" would likely get scaled down a bit. |
It does @pixelzoom, but @andrea-phet told me that there are two different string keys which have some context to separate the x-distance "Range" from the min-max "Range". Thanks for the screenshots @pixelzoom! I think "Mass: 1-5000 kg" looks great, but I don't really love the look when the strings get longer. Using the variable name may also be more challenging (length-wise) when it comes to i18n, so I'm leaning towards sticking with "Range". @ariel-phet can you review and advise? |
Thought not completely correct, could also just go with "Drag: 0.04 - 1" since it is explicitly labeled as the drag coefficient in the panel. My thought was actually just do things like "1 -5000 kg" since the fact it is mass is obvious from the unit label, and for the special case of drag do "Drag: 0.04 - 1" I am hesitant about using the word Range. What do you think about that solution @arouinfar? |
@arouinfar said:
I wasn't worried about a conflict in string keys. I'm concerned about confusion caused by showing "Range" in the user interface with 2 different semantics. I.e.: |
@ariel-phet said:
Complicates the code by having an optional "abbreviated form" of the label that's used for quantities in the control panel. |
@arouinfar we could also use "C_d" (as in "C" with "d" as a subscript) since that is a very common abbreviation of drag coefficient. I think if for drag it came up as "C_d: 0.04 -1" might also work just fine. Your main concern was it looked like an expression. This is a pretty particular use case, and I think it would be OK. |
@arouinfar or perhaps the simplest solution: For drag do "0.04 to 1" so it does not look like an expression. I really really don't like using the redundant and possibly confusing "Range" or "Domain" prefix when we are just trying to make the drag case cleaner. |
Imo, using different labels in the keypad and control panel is fundamentally problematic. It's potentially confusing to the user, it complicates the code, and it's being considered for the wrong reason (to address space constraint, rather than improve user experience). I would consider making the keypad wider (to accommodate identical labels) before resorting to using different labels. |
@ariel-phet said:
Not in favor of a solution that is specific to "Drag Coefficient". That is an English-specific solution. Treat all quantities the same. |
@arouinfar I think @pixelzoom and I agree that using "to" for all would work fine "1 to 5000 kg" That keeps things compact, consistent, and clear |
Also should require minimal code changes. Change this: "rangeMessage": {
"value": "Range: {{min}} - {{max}} {{units}}"
} to this: "rangeMessage": {
"value": "{{min}} to {{max}} {{units}}"
} |
Love it @ariel-phet!! |
All good. Assigning to @pixelzoom to review and close. |
👍 Closing. |
This is probably not related to #127, since it behaves this way in 1.0.0-dev.8. But the keypad allows you to enter values that are out of range, and are then changed when you press Enter.
Example:
Example:
I realize what's going on here -- Mass must be >= 1 and <= 5000. But you shouldn't be able to enter invalid values, it's confusing to the user.
See the marker editor in Unit Rates, for example. You can't enter '0' for the numerator. In the same way, you shouldn't be able to enter '0' for Mass , or any other value that is out of range.
The text was updated successfully, but these errors were encountered: