使用箭头键导航
使用箭头键在画布中不规则放置和大小的元素(例如表单上的控件)之间导航有哪些普遍接受的做法?
例如,如果当前聚焦的元素是一个高元素 (A),其高度包含其右侧的三个较短元素(B、C 和 D):
####### #######
# # # B #
# # #######
# #
# # #######
# A # # C #
# # #######
# #
# # #######
# # # D #
####### #######
当用户按 Right 时,应聚焦其中哪个元素箭头? 顶部元素 (B)? 中间那个(C)?
如果在用户通过按 Left
将焦点移至 A 之前 D 已获得焦点会怎样? 当用户随后按下 Right
时,焦点是否应该返回到 D?
我想知道是否有针对这些场景的一些已发布的指南。
What are some generally accepted practices for navigating between irregularly placed and sized elements in a canvas (such as controls on a form) using the arrow keys?
For example, if the currently focused element is a tall element (A) whose height encompasses three shorter elements to the right of it (B, C and D):
####### #######
# # # B #
# # #######
# #
# # #######
# A # # C #
# # #######
# #
# # #######
# # # D #
####### #######
Which of these elements should be focused when the user presses the Right
arrow? The top element (B)? The one in the center (C)?
What if D was focused before the use user moved focus to A by pressing Left
? Should focus return to D when the user subsequently presses Right
?
I'm wondering if there are some published guidelines for these scenarios.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我还没有研究过任何具体的指导方针或任何东西,但似乎在第一种情况下,当你在 A 上并向右推时,它应该转到 B。
如果当你推时你已经在 C 或 D 上答,回到那个可能是有意义的。 我对此不太确定,因为用户可能已经从底部转到 A 作为到达 B 的“捷径”(如果右列中有很多元素,这是有意义的,所以不要去(向上-向上-向上-向上-向上-向上,你向左向右移动)。
I haven't looked into any specific guidelines or anything, but it seems that in the first case, when you're on A and you push Right, it should go to B.
If you're already on C or D when you push A, it probably makes sense to go back to that one. I'm less sure about this one, because the user might have gone to A from the bottom as a "shortcut" to get to B (This makes sense if there are a lot of elements in the right column, so instead of going (Up-Up-Up-Up-Up-Up you go Left-Right).
我认为注意您要导航到的元素“B”也很重要。 假设B是一个文本框。 如果从 A 转到 B,您是否会假设用户想要输入内容并自动将光标聚焦在文本框中? 这将使用户可以立即使用在框中键入内容,但如果他/她想移至 C 或 D,则会立即出现问题。
我认为更重要的是向用户提供有关他/她所在字段的反馈。Windows 控件往往不太擅长显示突出显示的字段,而在 OS X 中,您会在所选控件周围获得独特的突出显示(在大多数情况下)例)。
如果用户想去其他地方,请注意不要妨碍他们。 如果他们只想移动到另一个元素,请不要在进入 AD 后锁定键盘。
I think it's also important to note what element 'B' is that you're navigating to. Suppose B is a text box. If you go from A to B, will you assume the user wants to enter input and automatically focus their cursor in the text box? This would give a user immediate use of typing into the box, but immediate problems if he/she wanted to move to C or D instead.
I think it's more important to give the user feedback on which field he/she is in. Windows controls tend to suck for showing a well highlighted field, while in OS X, you get a distinctive highlight around the control that is selected (in most cases).
Just make it a point not to get in the way of the user if they want to go somewhere else. Don't lock down their keyboard after moving into A-D if they only want to move to another element.
一般来说,控件导航应遵循用户的自然阅读顺序。 在西方文化中,这是从左到右,从上到下。 这是 Microsoft 的可用性标准,可以追溯到优秀的软件设计的 Windows 界面指南 和 Microsoft Windows 用户体验。
在您的示例中,通过控件进行导航应该采用 ABCDA-...
In general, navigating through controls should follow the user's natural reading order. In Western cultures, that's left-to-right, top-to-bottom. This has been a usability standard at Microsoft going back to the excellent The Windows Interface Guidelines for Software Design and Microsoft Windows User Experience.
In your example, navigation through the controls should go A-B-C-D-A-...
如果你在 A 上,点击向右,你应该去 B。
如果你在 D 上,点击向左,有两个选择:“向左走”,即 A,或“返回”,即 A意味着去B。如果你选择第二种方式,就没有地方可以迷路,尽管一开始看起来有点奇怪。
也就是说,如果你选择第一种方式,我认为正确的方式是去B:不需要记住你在哪里,只要你在哪里,就知道你会在哪里。 (“状态很糟糕。不要让用户思考它。”)
If you're on A and you hit right, you should go to B.
If you're on D, and you hit Left, there are two options: "going left", which is A, or "going back", which would mean going to B. If you choose the second way, there's no place to get lost, although it can look a bit weird at first.
That said, if you choose the first way, I think the proper would be going to B: no need to remember where you were, just where you are, to know where you'll be. ("State is bad. Don't make the user think about it.")
查看 Microsoft 对于 Vista 应用程序的说法。
Take a look at what Microsoft says for Vista applications.
尽管上述答案在机械上是正确的,但在上述情况下使用箭头并不是一个好的做法。 箭头非常适合作为替代方案或与上一个/下一个按钮一起推进记录,但在示例中最好使用 Tab 和 Shift + Tab 键,因为您可以遵循 Tab 键顺序并跳过任何您不希望出现的字段包括。
例如,您从 A 切换到 B,然后切换到 C,但如果 C 设置为禁用切换,则切换将直接从 B 转到 D。然后,shift + tab 将再次跳过 C,从 D 切换到 B,然后再切换到
A。并不总是我应该怎么做,但常常是为什么我不应该这样做。
Though the above answers are mechanically correct, using the arrows in said situation is not a good practice. Arrows are great for advancing records as an alternative or alongside previous/next buttons, but in the example it is better to use the tab and shift + tab keys because you can follow the tab order and skip any fields you don't want to be included.
For example, you tab from A to B then C, but if C is set to tab is disabled the tab will go directly from B to D. Then shift + tab will skip C again and go from D to B then to A.
It's not always how should I do it, but often why should I not.