Open markriseley opened 9 years ago
4) When the slider is focused, arrow keys only affect the slider (which would force the user to click away to advance the slides)
Only thing I don't like about 2) is that users would need to know about this option, otherwise they get the broken experience. It would be nicer if that's what automatically happens in a presentation.
Maybe the solution is to have the slider not respond to keyboard input when it's not visible. Things to consider:
The last solution you suggest would still expose the slider to one advance to the right when you key to go to the next slide (because it would still be visible), plus it involves getting the ion.rangeSlider guys to deploy something extra.
I would vote for suppressing the keyboard input as the default on the sliders if (and only if) shiny is being run in presentation mode. It's what most people would expect and I would be surprised if suppressing it created usability issues.
On 5 February 2015 at 22:34, Winston Chang notifications@github.com wrote:
Maybe the solution is to have the slider not respond to keyboard input when it's not visible. Things to consider:
- How is hiding done with ioslides?
- Can we convince the upstream maintainer of ion.rangeSlider to put in a fix?
— Reply to this email directly or view it on GitHub https://github.com/rstudio/shiny/issues/726#issuecomment-73144558.
A Shiny Presentation created with an Rmd file in R Studio that includes sliderInput (the ionRangeSlider) creates a situation where two actions are dependent on listening for the same input - arrow keys (moving slider and advancing the slide). You can see this on the default shiny presentation Rmd file, particularly if you put a slide break between the sliderInput code and the plot.
If the slider is still in focus when a user advances slides with the arrow keys they will unwittingly also advance the slider. In html5 preso scenario, I'd argue the user expects arrows to move slides not widgets.
This creates unintended consequences for the user. If a slider is used to control something on another slide (eg filter your dataset, then view 5 charts about it following), as you advance the charts you might be moving the slider.
Possible solutions could include: 1) building in a submit button to force the user to shift focus 2) offering an option in the code to disable keyboard input on the slider to avoid these conflicts in shiny presentations 3) altering the focusing of the slider (eg with timeouts, if mouse is no longer over the slider).
1) is a workaround, that adds an unnecessary step to the user experience 2) would be my preferred option, given that if you're using a slider you're probably dragging it anyway 3) there are probably additional unintended consequences of this approach