禁用基于操作系统的“功能”是不好的做法?

时间:2009-05-16 23:15:18

标签: shell user-interface operating-system

我无法理解的一件事就是在这里和网络上的其他地方持续提出关于禁用基于操作系统的“功能”的问题。人们一直在问如何禁用默认的操作系统快捷方式(如复制粘贴,Windows密钥等),或以编程方式禁用功能。

这肯定是非常非常糟糕的做法?要使用您的程序修改用户的操作环境,除非它专门用于帮助修改他们自己的操作环境(在我见过的大多数情况下,我对此非常怀疑)。我永远不会想要一个程序修改我的绑定快捷方式,或者更改我的环境的默认行为/功能集。这是一个普遍的共识,还是仅仅是我?它几乎违反了我能想到的所有基础启发式和可用性/一致性理论 - 尤其是最不惊讶的原则。

问题是: 在操作/更改/禁用操作系统功能时,是否有时间(除了帮助用户修改环境时),或者用户的一般环境,是可以接受的做法吗?如果程序没有得到用户的明确许可,是否应该尝试禁用Windows密钥,复制/粘贴快捷方式,调整“开始”按钮文本或类似的任何内容,并且没有根据实施计划目的所需的改变?

6 个答案:

答案 0 :(得分:4)

我相信如果您正在构建一个“设备”,例如您在书店找到的自助服务终端,这是完全可以接受的。在这些情况下,禁用大多数已知的快捷方式和功能都是有意义的。

答案 1 :(得分:3)

没有。

对于普通应用程序,用户希望控制并且可能正在运行其他应用程序,这种行为只会破坏用户的期望,可能会破坏操作系统的本机可访问性功能,并且通常会导致挫败感。

即使是ocdeciooverslacked注意到的例外情况,尽管是善意的,也可能会陷入这个陷阱(你玩了多少游戏会导致重要的系统功能失效,或信息亭)禁用任务切换但忘记禁用系统通知......)只要有可能,开发人员应首先查看操作系统本身,以获得实现全屏,限制或信息亭应用程序的支持。

BTW - 标记CW,非常主观。

答案 2 :(得分:2)

元回答:如果你的真正这样做的原因符合用户的利益,那么这可能是一个好主意。

并且不要试图欺骗用户为“安全”做这件事。你可以指望被公开命名和羞辱。

如果您限制用户 的优势,而不是他们的优势,那么您确实处于危险的境地。在未经我明确许可的情况下瘫痪我的机器会让你永远处于极端偏见列表的过滤器上......

答案 3 :(得分:0)

是的,我是这么认为的,虽然它很少见,应该是非常短暂的。例如,DVD播放器禁用屏幕保护程序,或演示文稿,游戏或“父件”类型的应用程序禁用Windows密钥。

避免做这些事情是非常好的建议,但有时候这是合适的,甚至是必要的。

答案 4 :(得分:0)

我见过在密码文本框中禁用剪切和粘贴的应用程序(包括Windows操作系统)。

我同意这种情况很少见,但总的来说这是不好的做法。

答案 5 :(得分:0)

与正常接口行为有很好分歧的一个例子是在winblows上的终端仿真器上使用Ctrl-C。

通常,禁用“正常”O / S接口功能显然很愚蠢。你能想象必须在租车中搜索刹车踏板吗?将它驱逐出去是多么安全?必须搜索灯,刮水器,指示器和手制动器已经够糟糕了......刹车踏板应该是中间或左侧的;-)它可以工作。不要因为它而烦恼!

话虽如此:Neil Frasers blog通过评估其应用于古老的TI80可编程caclulator,系统地破坏了UI设计的许多“通用原则”。短语“这会导致一个低劣的计算器”以某种方式将自己标记在我的大脑中。

我认为接口的一致性是至关重要的。例如,我使用名为SOATest的产品。它是一个基于Eclipse的Java应用程序,用于测试SOAP(等)的Web服务。它有一个非常恼人的怪癖。 Ctrl-Insert和Shift-Insert在其任何文本区域都不起作用,但它们在许多(不是全部)文本框中都有效。如果这些密钥始终不起作用,我会更容易适应。我发现这个小怪癖非常讨厌,因为(对我来说,作为一名专业程序员)它代表“只是简单的草率工作”。

所以......基思的UI设计的第一条规则:无论你做什么,FFS都会做到这一点!您的用户很聪明,他们会适应。

干杯。基思。