Hi... I'm struggling to determine what I should say when instructing learners to click a button (because some will "tap" the button on a mobile device). Does anybody have any suggestions or could point me to a style guide for writing for multiple devices now? Thanks in advance!
Click, tap, select, ... ? The struggle is real, and I feel your pain. :) I've taken to using "click" when the audience includes non-touchscreen devices. I find that mobile users are familiar with the term "click" and intuitively understand it in context. (One could say "click or tap," but I like to keep it simple.)
If the audience is exclusively on touchscreen devices, I use "tap."
Apple stresses using "click" for OSX and "tap" for iOS, but they don't mention how to address mixed audiences: https://help.apple.com/asg/mac/2013/ASG_2013.pdf. "Click" seems to be a safe common denominator.
"Press" is a good option for physical buttons, like volume buttons on mobile devices, or when you need to long-press something on a touchscreen.
I tend to use "select" when the reader needs to make a choice—for example, when they need to choose one (or more) items from a list.
Great question, by the way! I'm looking forward to how others handle mixed touchscreen/non-touchscreen audiences.
Why either/or, when you can have both? For mixed audiences I use a variable in place of click/tap.
For instance: " %action% the clock to start the countdown."
The nice thing about this approach is that you can run a single JS trigger that includes your browser identification/User Agent script and the SetVar for your action variable, at the very beginning of your course once, and never have to worry about it again.
As long as you don't get your User Agents mixed, it works for the most part.
To be fair though, it's a workaround which needs constant attention (new browser/engine/agent versions etc). It would be easier if this was an out-of-the-box Storyline feature, by means of a hashtag in the URL ( such as http://example.com/course_html5.html#desktop ). This would eliminate the need to go back and update the JS trigger every other cycle, since development cycles for browsers are way shorter than they used to be.
Microsoft UI guidelines recommend not using select except where there is an option. I use a combination of click and select when there is an option.
I find select is ambiguous and infers a choice, I believe click is more universal most of these are referred to as onclick events and iOS and Android devices generally play a sound when you tap on them to infer a click.
I find click safe as even on a touch screen users would understand the equivalent action required.
My colleagues and I were having this same discussion in our meeting the other day. I am a firm advocate of "select" as it provides a versatile application.
I would definitely go with "Select" if it's an item on the screen, as people that are going though the course with visual impairments can still use their screenreader to make sense of what is happening on the screen! (we're big on accessibility!)
I've been doing what Alex has suggested. One variable that can be either click or tap, depending on the javascript detection. It's especially useful when you also have "swipe."
I would not use Hover on a touchscreen, because of this I don't use hover interactions, I will add hover effects on buttons but to ensure conformity I avoid hover interactions, you would need to take into account where the finger is and if it occludes what you are trying to show and sometimes the hover effect just does not work on some tablets.
13 Replies
"Select" works nicely.
Hi KR,
Click, tap, select, ... ? The struggle is real, and I feel your pain. :) I've taken to using "click" when the audience includes non-touchscreen devices. I find that mobile users are familiar with the term "click" and intuitively understand it in context. (One could say "click or tap," but I like to keep it simple.)
If the audience is exclusively on touchscreen devices, I use "tap."
Apple stresses using "click" for OSX and "tap" for iOS, but they don't mention how to address mixed audiences: https://help.apple.com/asg/mac/2013/ASG_2013.pdf. "Click" seems to be a safe common denominator.
"Press" is a good option for physical buttons, like volume buttons on mobile devices, or when you need to long-press something on a touchscreen.
I tend to use "select" when the reader needs to make a choice—for example, when they need to choose one (or more) items from a list.
Great question, by the way! I'm looking forward to how others handle mixed touchscreen/non-touchscreen audiences.
Why either/or, when you can have both? For mixed audiences I use a variable in place of click/tap.
For instance: " %action% the clock to start the countdown."
The nice thing about this approach is that you can run a single JS trigger that includes your browser identification/User Agent script and the SetVar for your action variable, at the very beginning of your course once, and never have to worry about it again.
Just my 2c,
Alex
Brilliant solution, Alex!
As long as you don't get your User Agents mixed, it works for the most part.
To be fair though, it's a workaround which needs constant attention (new browser/engine/agent versions etc). It would be easier if this was an out-of-the-box Storyline feature, by means of a hashtag in the URL ( such as http://example.com/course_html5.html#desktop ). This would eliminate the need to go back and update the JS trigger every other cycle, since development cycles for browsers are way shorter than they used to be.
Microsoft UI guidelines recommend not using select except where there is an option. I use a combination of click and select when there is an option.
I find select is ambiguous and infers a choice, I believe click is more universal most of these are referred to as onclick events and iOS and Android devices generally play a sound when you tap on them to infer a click.
I find click safe as even on a touch screen users would understand the equivalent action required.
Thank you for all your responses!
My colleagues and I were having this same discussion in our meeting the other day. I am a firm advocate of "select" as it provides a versatile application.
I would definitely go with "Select" if it's an item on the screen, as people that are going though the course with visual impairments can still use their screenreader to make sense of what is happening on the screen! (we're big on accessibility!)
I've been doing what Alex has suggested. One variable that can be either click or tap, depending on the javascript detection. It's especially useful when you also have "swipe."
This post was removed by the author
Hi, there!
I came across this discussion and also would like to know how you would solve the "hover" instruction for touchscreen devices...!
I would not use Hover on a touchscreen, because of this I don't use hover interactions, I will add hover effects on buttons but to ensure conformity I avoid hover interactions, you would need to take into account where the finger is and if it occludes what you are trying to show and sometimes the hover effect just does not work on some tablets.
There's no such thing as 'hover' on touch screen, you can only have 'touch' or 'select' for buttons / interactions
Sent from Samsung Mobile on O2
This discussion is closed. You can start a new discussion or contact Articulate Support.