When a user updates a value in a groov gadget the outer border of the gadget turns color for a moment to #C60 (tawny), but changes back to #666 (gray) before the updated value is displayed in the gadget. I’m not sure what the reasoning is behind that behavior, but wouldn’t it be better for the gadget to leave the border color #C60 until it reads the value back from the device?
This is what a user currently sees when checking a checkbox gadget:
Checkbox with blue square - unchecked
User checks the box and the square turns tawny colored - cool something is happening
A second passes and the square turns blue again (still unchecked) - crap it didn’t work
Another second passes and the check shows up. - oh it did work!
I would like step 3 to be eliminated. That is the step where a user is tempted to click the check box again.
I would also like to see an option in the project settings that allows the value the user enters to appear immediately in the gadget (like how the slider gadget currently operates). If the write fails, then the value should be restored to its original value. So in that case the check box would show up immediately - the border should stay tawny colored until the value is successfully written or read back from the device.
Jumping on this;
The text box behavior used to be such that when a user clicked in the box to change the setting, the cursor popped up and/or the current value was highlighted in the data entry box and text could immediately be entered.
Now a user needs to click in the text box and then click in the text entry box when it appears. Ugh. Why the extra click?
Funnily enough, I’ve had the opposite complaint about the slider: we’re overly optimistic about updating the value displayed there and sometimes it’ll flick back to the previous value for a moment until we get a confirmed update from the device. It could all use some tweaking in general, I agree.
Now a user needs to click in the text box and then click in the text entry box when it appears. Ugh. Why the extra click?
That’s probably an unintended side effect of adding support for the virtual keyboard we use on the GRV-EPIC-PR1’s touchscreen. I’ll take a look into it.
If the border color stayed tawny until the write was confirmed that should solve that complaint I would think.
I’m not sure if a confirmed update would be sufficient to clear the border color since there could be a read response in transit before the write was received by the device- unless these read responses are ignored if the read request was prior to the write request.
I wonder if that’s why my virtual keyboards started working… I remember after reporting a Login Bug, being told there was nothing wrong with groov/no way to fix it…
If it’s a choice between working virtual keyboard and having the input focus set, I choose Keyboard.
Yeah, hitting Enter on the sign in screen should have been fixed as of 3.5.
It’s a bog-standard HTML form: hitting Enter is supposed to Just Work, but I kept running into weird cases where it wouldn’t for no good reason so I finally got fed up and started watching for the Enter key manually. Sorry it took so long.
I agree with you philip. The step 3 will make users confusing. And, some unnecessary things can be removed from it in order to make the gadget awesome to use.
before the updated value is displayed in the gadget. I’m not sure what the reasoning is behind that behavior, but wouldn’t it be better for the gadget to leave the border color #C60 until it reads the value back from the device?