What is always 'Standard'? If the spec didn't say it, it should be assumed?

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 cance开发者_JAVA百科l 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.

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

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. ;-)

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"):

Pressing the Esc key always closes an active dialog box. This is true for dialog boxes with Cancel or Close, and even if Cancel has been renamed to Close because the results can no longer be undone.

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:

1. If you're developing for something that has its own UI guidelines (e.g. the Mac or iPhone) those are the rules to follow. Microsoft's market share makes theirs an obvious choice for a target that doesn't have its own UI guideline.
2. This is clearly a matter of customer relations. You clearly don't want to lose your best customer over something you could implement fairly easily. If auto-resizing columns makes a huge difference to them, and they're a good customer otherwise, it may make sense to do it for them -- but let them know you're doing them a favor because of how much you value them. You just have to be careful about balancing the warm-fuzzy "because you're special" part with the mild guilt-trip of "so we're doing you a favor and now you owe us..." (IMO, it's usually better not to say the "and now you owe us" part out loud, but I don't know your customer).

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.

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.

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.