You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main reason for this suggestion my belief that multi-step moves with the four direction buttons are more typical than single-step moves. Just having the autorepeat button on the array adds one scan step to every cycle, which adds up. Add to that the fact that the user is going to be wanting to use it for every multistep move (i.e., often), making the whole operation longer than it would be if autorepeat was tacitly on for the four direction buttons, and the explicit autorepeat button starts to seem like more trouble than it's worth.
Mauricio showed me that you can get a manual repeat if you choose the select button again during the scan interval. One extra push during the interval gives you one extra hop. And the scan counter is reset with each push so that you could theoretically keep hopping in that direction as long as you keep hitting the button with frequency greater than the scanning frequency. The problem I see with this is accessibility for someone with significant motor impairments. If someone is using automatic or inverse scanning, the scan rate is typically already set at the maximum that still gives reliable switch activations. Asking them to hit the button between scan steps is going to be problematic for many.
The alternative I'm proposing is that for the directional arrows and other keys where multi-step movements are likely, we autorepeat automatically instead of requiring the user to change into autorepeat mode first. You would select an arrow and it would automatically repeat until you hit the select button again, at which point the array resumes scanning. That means that every movement requires two switch hits, including the single-hop movements, but I suspect the relative frequency of multi-hop movements justifies the change.
There may be non-navigation uses of the arrow keys that I'm not aware of yet, or some other reason why this idea won't fly. What do people think?
The text was updated successfully, but these errors were encountered:
This makes a lot of sense. The only instance where it may become an issue is when reading a book, since users will likely only want to send a single key event to turn a single page. However, this could be acceptable given that turning a page is not a repetitive task and we would likely still be demanding less switch presses overall. Any more ideas on this?
I was thinking about the book example too. I think reading is one of the applications we would want to examine closely for minimizing effort, but I don't have a clear idea what that might look like yet.
The main reason for this suggestion my belief that multi-step moves with the four direction buttons are more typical than single-step moves. Just having the autorepeat button on the array adds one scan step to every cycle, which adds up. Add to that the fact that the user is going to be wanting to use it for every multistep move (i.e., often), making the whole operation longer than it would be if autorepeat was tacitly on for the four direction buttons, and the explicit autorepeat button starts to seem like more trouble than it's worth.
Mauricio showed me that you can get a manual repeat if you choose the select button again during the scan interval. One extra push during the interval gives you one extra hop. And the scan counter is reset with each push so that you could theoretically keep hopping in that direction as long as you keep hitting the button with frequency greater than the scanning frequency. The problem I see with this is accessibility for someone with significant motor impairments. If someone is using automatic or inverse scanning, the scan rate is typically already set at the maximum that still gives reliable switch activations. Asking them to hit the button between scan steps is going to be problematic for many.
The alternative I'm proposing is that for the directional arrows and other keys where multi-step movements are likely, we autorepeat automatically instead of requiring the user to change into autorepeat mode first. You would select an arrow and it would automatically repeat until you hit the select button again, at which point the array resumes scanning. That means that every movement requires two switch hits, including the single-hop movements, but I suspect the relative frequency of multi-hop movements justifies the change.
There may be non-navigation uses of the arrow keys that I'm not aware of yet, or some other reason why this idea won't fly. What do people think?
The text was updated successfully, but these errors were encountered: