什么是永远的“标准”？如果规范没有说明，那么应该假设吗？
您是否认为某些标准非常明显，以至于被认为存在于任何规范中？
例如，点击 escape 是否总是会取消表单？是否应该双击列标题分隔符调整列大小？
当客户说“这是显而易见的‘标准行为’，因此没有它是一个错误”时，他们有时是正确的吗？如果是这样，是否有一些资源可以帮助调解？
我记得有一位教授要求我们写出简单任务中涉及的每一个细节——这可能会变得多么荒谬。我不希望我们的规格变得荒谬，但我厌倦了听到这些，并且认为我们的规格不够具体。
Are there some standards that you consider to be so obvious that they would be assumed to be in any spec?
For example, should hitting escape always cancel a form? Should double clicking a column header separator resize the column?
When a customer says "this is obvious and 'standard behavior' therefore it is a bug to not have it" - are they sometimes correct? If so, are there some resources that can help mediate?
I remember having a professor ask us to write out every detail involved in simple tasks - and how ridiculous it could get. I don't want our specs to be ridiculous, but I get tired of hearing this and am thinking that our specs are not specific enough.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可能需要查看 Windows 用户体验指南，了解 GUI 组件的“预期”行为：http://msdn.microsoft.com/en-us/library/aa511258.aspx
You may want to check out the Windows User Experience Guidelines for the "expected" behavior of GUI components: http://msdn.microsoft.com/en-us/library/aa511258.aspx
标准做法是指定用户界面标准，而不是假设它们，
例如，双击网格中的列标题来调整其大小不是标准的 Windows GUI 行为。但是，双击列分隔符可以调整列的大小。
值得付出努力来指定标准 GUI 行为，这样就不会造成混乱；如果你可以引用现有的标准，那很好，但要确保客户在其上签字
“我无法读懂你的想法，这样那样的行为不是标准/默认行为”是合乎逻辑的反驳......但不是一个很有礼貌的人。 ;-)
it is standard practice to specify the user-interface standards, not assume them
for example, double-clicking the column header in a grid to resize it is not a standard windows GUI behavior. Double-clicking the column separator to resize the column is, however.
it's worth the effort to specify the standard GUI behaviors so there is no confusion; if you can reference an existing standard that is fine, but make sure the customer signs off on it
"I can't read your mind, and such-and-so is not a standard/default behavior" is the logical retort...but not a very polite one. ;-)
对于用户界面问题，您可能需要查阅现有的 UI 指南，例如 Apple 的 或 Microsoft 的 。还有很多，但这两个都是足够大的参与者，他们的指南可能比大多数其他人更大程度地反映了用户的期望。
编辑：使用 Escape 键关闭对话框包含在 Microsoft 指南< /a>（向下滚动到“交互”）：
我并没有仔细查看，但我没有看到任何有关自动调整列大小的信息——而且它非常不寻常，如果它存在的话我会感到相当惊讶。
因此，如果我负责这件事，我会说这是一个分歧的决定（可以这么说）。客户期望转义键关闭对话框（没有明确指定）是合理的，并且未能做到这一点应被视为错误。
在不指定它的情况下，响应双击列标题边框而自动调整列大小是不合理的，因此实现它应该被视为一项附加功能。
注意事项：
For user interface questions, you might want to consult an existing UI guideline, such as Apple's or Microsoft's. There are quite a few more, but those two are large enough players that their guidelines probably reflect what your users expect to a greater degree than most others.
Edit: closing a dialog with the Escape key is covered in the Microsoft guideline (scroll down to "Interaction"):
I didn't look very hard, but I didn't see anything about auto-resizing columns -- and it's sufficiently unusual that I'd be rather surprised if it was there.
As such, if I were in charge of this, I'd say it's a split decision (so to speak). It's reasonable for the customer to expect the escape key to dismiss a dialog (without explicitly specifying it), and failure to do should should be considered a bug.
Auto-resizing the column in response to double-clicking the border of the column header is not reasonable to expect without specifying it, so implementing it should be considered an added feature.
Caveats:
我最喜欢的大学名言“标准的伟大之处在于有很多可供选择”。
我认为您问这个问题是因为您不幸卷入了“但您没有要求”的争议。这会让你陷入困境。通常，您首先希望公司向您提供他们的标准，或者正如其他人提到的那样，您可以共同商定第三方标准。如果您经营的公司生产许多相同类型的应用程序，您应该花一次时间来生成您的“标准”。
如果您在签署时发现有人因为“标准”功能而拒绝付款，那么您需要提供一些不标准的示例。例如，在您的示例中，转义键上的关闭形式仅是 Windows（而非网络）上的标准，并且仅真正适用于 Microsoft。我刚刚在计算机上打开了三个应用程序，其中 ESC 对表单没有任何操作。
几乎没有什么是标准的。在任何特定的人看来，“标准”的含义都略有不同，如果没有指定一些可测量的定义，将会导致争论。
My favorite quote from college "The great thing about standards is that there are so many to choose from".
I assume you are asking this question because you've unfortunately become embroiled in a "but you didn't ask for that" dispute. That can put you in tough spot. Generally up front you want the company to provide you with their standard or, as others have mentioned, you can mutually agree on a third party standard. If you are running a firm that produces many of the same type of application, you should spend the time once to generate your "standard".
If you're sitting at the point of sign-off and someone is refusing to pay because of "standard" features then you need to have a few examples of places where this is not standard. In your example for instance, close form on the escape key is only standard on Windows (not the web) and then only truly for Microsoft. I just opened three applications on my computer where ESC did nothing at all on a form.
Almost nothing is standard. In any given persons mind "standard" is going to mean something slightly different and, if not specified to some measurable definition, will result in arguments down the road.
创建一个样板规范，您可以在具有相同总体设计的所有项目中包含/引用该规范。随着您对客户/客户需求的了解更多，此规范应该不断发展和变化。本规范还应参考 Apple 或 Microsoft。即使您使用一个平台，我也强烈建议您阅读其他规范，以深入了解更好的做事方式或识别可能出现的问题。还有几本关于 UI 设计的好书你不妨借阅。
Create a boiler plate specification that you include/reference in all of your projects of the same general design. This specification should grow and change as you learn more about your clients/customer demands. This specification should also reference the appropriate UI guidelines provided by Apple or Microsoft. Even if you are on one platform I highly recommend reading through the other specification for insights into better ways of doing things or to identify possible hiccups. There are also several good books on UI design that you may wish to borrow from.
没有什么是标准的，除非它被写下来并在与您的项目相关的地方指定（或从规范链接到）。如果没有写下来，就不是标准，因此客户必须定义它。
另请注意：
如果您的 UI 库以一种方式执行此操作，并且需要编码以另一种方式执行此操作（愚蠢的示例：您希望用户使用鼠标右键单击按钮），那么您应该停下来重新考虑用户可能期望的内容。
Nothing is standard unless it's written down and specified somewhere related to your project (or linked to from the spec). If it's not written down it's not standard so the customer has to define it.
On another note:
If your UI library does it one way and it would require coding to do it another way (stupid example: You want that users click buttons with the right mousebutton) then you should stop and rethink about what users might expect.