它与伊戈尔的回复有些重叠,但这是我的看法:
原生控件外观 - 今天的 UI 控件具有相当复杂的外观。我们本能地从中获得了许多视觉线索,即使它是一个带有框架的白色矩形,加上黄影,它看起来也很奇怪。上下文菜单通常不只是在今天打开,它会从某个方向滑入或淡入。
原生控件行为 - 甚至比 UI 更复杂,行为有很多细节:不同的上下文菜单取决于点击位置、选择或拖动项目时不同的“热”区域、键盘快捷键等。
注重细节- 在任何平台上都可以发现许多一致的 UI 行为。就像箭头键在树形控件 WRT 中选择、打开和关闭节点一样。
看看 Windows:大多数非本地工具包的基本键盘导航错误 - 箭头键、Home、End、PgUp 和 PgDown,使用 Ctrl 修改行为,使用 Shift 扩展选择最多提供 32 种行为。复制和粘贴传统上是使用 Ctrl+C/Ctrl+X/Ctrl+V 和 Shift+INS、Shift+DEL 和缺少的。鼠标双击通常选择一个词,鼠标三击有时选择一个句子、行或段落。
响应时间和肌肉记忆 ——基本上有两种 UI 操作模式:
act-look loop,在决定下一步之前等待响应,
从肌肉记忆中回放,速度更快,需要更少的心理处理资源。
但是,对此有两个要求:响应必须一致且“即时”,并且必须立即正确注册下一个动作(至少在 10 毫秒内)
通常,对于非本地工具包,这会因为响应滞后于一两个动作(大脑锁定差异)以及工具包需要 50 毫秒或更长时间才能显示菜单而变得困难,此时单击不是t 按预期注册。
精致的 UI 需要很长时间才能正确- 一个好的控件库可以解决大多数每个控件的问题,但最后 10% 的问题需要 90% 的时间,并且您可以进行控件交互。你必须尝试不同的方法,你必须期待具有 FPS 训练反应的用户,你必须尝试各种工作流程。
跨平台工具包不能完全正确——它们夹在两难之间:它们可以选择独立于平台的内部一致性,或者与它们当前运行的平台保持一致。为了做到这一点,后者通常需要在调用代码中使用依赖于平台的代码,这是您试图避免的实际情况。