Closed jbrennan closed 9 years ago
We have two options here, we could either implement a specific number pad, as in #32, that also has a number scrubber built in, or we could change the math of the number scrubber and just never allow them to "type" a specific number. If we don't do ballistics or a custom input we may have to concede that they'll be dragging the scrubber multiple times to get the right number.
I'm remembering that when we dug into having velocity on the scrubber way-back-when, one of the un-expected side effects was that if you returned the scrubber back to the starting position it wouldn't, necessarily, be the original number that you started with. If we're ok with that then changing it to be a relative velocity actually could be a good solution.
I’m still a little foggy on how the number scrubber works, but I’ll run with the current assumption that it’s currently linear, something like: for every X px I scrub right, increase the value by X. If that’s the case, what if we just did “for every X px I scrub right, increase the value by X/2 (or some other divisor >= 2)”. I think that’d solve the issue of “returning to the starting value” too?
FWIW this is the current logic: https://github.com/Khan/live-editor/blob/master/js/ui/tooltips/number-scrubber.js#L70 and the logic for getExponent is here: https://github.com/Khan/live-editor/blob/master/js/ui/tooltips/number-scrubber.js#L13 -- most of this makes more sense on the desktop (although I honestly don't know how many people use the modifiers that we have in place).
There is also left-click/right-click logic built in for incrementing/decrementing by a single number: https://github.com/Khan/live-editor/blob/master/js/ui/tooltips/number-scrubber.js#L33 Again, doesn't make as much sense on the iPad.
This gives me an idea, what if we had something like:
(-) (< - >) (+)
And you could drag the scrubber or click the +/- to increment/decrement.
Yet another option would be to have a numpad input that's positioned over the toolbox area. Something like:
1 2 3
(123) ------------------------- 4 5 6
7 8 9
With the normal number scrubber beneath the number (or even, we could put the scrubber under the numpad).
Ah nice, thank’s for the explanation!
I think after the testing both days, especially with the kids, it’s clear to me the number scrubber isn’t sufficient for at least primary input (it’s great for playing around and exploring). I think we need a keypad.
Ideally I’d say this belongs as close to the number as possible, or it could be in the toolbox, or we could just use the iPad keyboard. It might actually be a good idea to start with that again, I’m not sure.
I think we should try hard for a scrubbing-like experience, versus an exact-number-experience, as that's part of the promise of our environment. The challenges all have leeways of a decent number of pixels in their solutions , because we want them to be playing around with the numbers semi-freely (H for Hopper is the strictest, and I could replace that with a less strict one if students are struggling in particular with that). I don't want students thinking "oh gosh I have to get this number exactly correct! oh no, I entered it wrong again! And again". They should think "wheeee, now its getting there!". :)
Some sort of slider that pops up, perhaps?
On Sat, Nov 22, 2014 at 9:00 PM, Jason Brennan notifications@github.com wrote:
Ah nice, thank’s for the explanation!
I think after the testing both days, especially with the kids, it’s clear to me the number scrubber isn’t sufficient for at least primary input (it’s great for playing around and exploring). I think we need a keypad.
Ideally I’d say this belongs as close to the number as possible, or it could be in the toolbox, or we could just use the iPad keyboard. It might actually be a good idea to start with that again, I’m not sure.
— Reply to this email directly or view it on GitHub https://github.com/Khan/structured-blocks/issues/44#issuecomment-64093244 .
I think we should try hard for a scrubbing-like experience, versus an exact-number-experience, as that's part of the promise of our environment.
I definitely agree. We shouldn’t be super number-strict. However, I do still think number scrubbing (or number exploring, is another way of thinking of what the scrubber allows) should be in addition to standard input so the kid can get somewhere first, and then explore from there.
The scrubber as a sole input method makes it tedious to say, line up two eyes (kids were trying to do this in testing with both the H for Hopper and the Wild Animal project), but I think it’s really great (and important) to be able to explore the values after you’ve got a good starting point.
Should be much easier now that we have this: https://github.com/Khan/live-editor/commit/8f3de60f25ec91f1d28446f135f5b8ff7a05e2ab
Other than using the arrow buttons.
I’d suggest we dampen with scrubbing “speed” so that it only scrubs half as much (we could get fancy like with mouse ballistics but this is probably sufficient)