有一件事我无法理解，那就是在这里和网络上的其他地方，关于禁用基于操作系统的“功能”的持续质疑。人们总是在问如何禁用默认的操作系统快捷方式（如复制粘贴、Windows键等），或者通过编程禁用功能。
当然，这是非常非常糟糕的做法吗？用你的程序修改用户的操作环境，除非它专门针对帮助用户修改他们自己的操作环境（在我见过的大多数情况下，我对此表示高度怀疑）。我永远不希望程序修改我的绑定快捷方式，或者改变我的环境的默认行为/特性集。这是一个普遍的共识吗？或者这只是我一个人？它几乎违反了我能想到的每一个基本启发式和可用性/一致性理论-尤其是最不惊讶的原则。
**那么问题是：**是否有这样的时候（除了帮助用户修改其环境之外），操作/更改/禁用操作系统或用户的一般环境的功能是可以接受的做法？ 程序是否应该在没有用户明确许可的情况下，并且在没有执行程序目的所必需的基本更改的情况下，尝试禁用Windows键、复制/粘贴快捷方式、调整“开始”按钮文本或任何类似的行为？
6条答案
按热度按时间xytpbqjk1#
我相信如果你正在建立一个“设备”，例如你在书店里找到的信息亭，这是完全可以接受的。在这样的情况下，禁用大多数已知的快捷方式和功能是有意义的。
cu6pst1q2#
没有。
对于普通应用程序，用户希望控制应用程序，并且很可能正在运行其他应用程序，这种行为只会颠覆用户的期望，可能会损害操作系统的本地可访问性功能，并且通常会导致失败。
即使是像ocdecio和overslacked这样的例外，尽管初衷是好的，也可能落入这个陷阱（你玩过多少游戏会崩溃，使重要的系统功能禁用，或者信息亭禁用了任务切换，但忘记禁用系统通知......）只要有可能，开发人员应该首先寻找操作系统本身对实现全屏、受限或信息亭应用程序的支持。
顺便说一句-标记CW，非常主观。
tpxzln5u3#
** meta答案：**如果且仅如果您这样做的 * 真实的 * 原因符合用户的利益，这可能是一个好主意。
不要试图欺骗用户说这样做是为了“安全”，你可以指望被公开点名和羞辱。
如果你限制用户是为了你自己的利益，而不是他们的利益，那你就真的处在危险的境地了。未经我的明确许可就破坏我的机器，会让你永远被列入带有极端偏见的过滤名单......
zmeyuzjn4#
是的，我想是的，尽管这种情况很少见，而且应该是非常暂时的。例如，DVD播放器禁用屏幕保护程序，演示文稿、游戏或“家长软件”类型的应用程序禁用Windows键。
避免做这些事情是非常好的建议，但有时候这是适当的，甚至是必要的。
yhxst69z5#
我见过一些应用程序（包括Windows操作系统，我想）在密码文本框中禁用剪切和粘贴。
我同意有很少的原因，但这是总的来说不好的做法。
o2g1uqev6#
一个很好地偏离正常接口行为的例子是Winblows上的终端模拟器上的Ctrl-C。
总的来说，禁用"正常"的操作系统界面功能显然是愚蠢的。你能想象在租来的车里寻找刹车踏板吗？把它开离停车场会有多安全？不得不寻找车灯、雨刷、指示灯和手刹已经够糟糕的了...刹车踏板应该是中间的，或者左边的;- ）它很有效，不要用它来起作用!
话虽如此：Neil Frasers blog通过评估UI设计在古老的TI80可编程计算器上的应用，系统地破坏了UI设计的许多"通用原则"。"这导致了劣质计算器"这句话不知何故烙印在了我的脑海中。
我相信接口的一致性是最重要的。例如，我使用一个叫做SOATest的产品。它是一个基于Eclipse的Java应用程序，用于测试SOAP它有一个非常烦人的怪癖。Ctrl-Insert和Shift-Insert在它的任何文本区域都不起作用，但它们确实在许多（不是全部）的文本框。如果这些键一直不起作用，我会更容易适应。我发现这个小怪癖非常烦人，因为（对我这个专业程序员来说）它代表的是"普通的ole草率的工作"。
所以... Keiths UI设计的第一条规则是：无论你做什么，FFS都要始终如一!你的用户很聪明，他们会适应的。
干杯。基思。