What is a standard? If the specification didn’t talk about it, would it be accepted?

Question

Are there any standards that you consider so obvious that they can be considered in any specification?

For example, if a successful exit always cancels the form? Should double-clicking on the column header separator resize the column?

When a client says "this is obvious and" standard behavior ", so it’s a mistake not to have it" - are they sometimes correct? If so, are there any resources that can help the intermediary?

I remember how the professor asked us to write every detail related to simple tasks - and how funny it is. I don't want our specifications to be ridiculous, but I'm tired of hearing this and I think our specifications are not specific enough.

Answer 1

You can check the Windows User Guides for the “expected” behavior of GUI components: http://msdn.microsoft.com/en-us/library/aa511258.aspx

Answer 2

For user interface questions, you can read the existing user interface guide, such as Apple or Microsoft . There are many more, but these two are big enough players that their recommendations probably reflect what your users expect more than most of the others.

Edit: closing the dialog using the Escape key is described in the Microsoft manual (scroll down to “Interaction”):

Pressing the Esc key always closes the active dialog box. This is true for dialogs with Cancel or Close, and even if Cancel was renamed 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 rather unusual that I would be very surprised if he were there.

Thus, if I were responsible for this, I would say that this is a split solution (so to speak). It is reasonable for the client to expect that the escape key will reject the dialog (without explicitly specifying it), and failure to do so should be considered a mistake.

Automatic resizing of a column in response to a double click on the border of the column header is impractical to expect without specifying it, therefore, its implementation should be considered as an added function.

Cautions:

• If you are developing for something that has its own user interface recommendations (like Mac or iPhone), then these are the rules to follow. Microsoft's market share makes them the obvious choice for a goal that does not have its own user interface guide.
• This is obviously a customer relationship issue. You obviously do not want to lose a better customer for something that you could implement quite easily. If the auto-separation of the columns is of great importance to them, and otherwise they are a good client, it may make sense to do it for them, but let them know that you are doing them a favor, because you value them, you just have to be careful in balancing the warm fuzzy "because you are special" part with a moderate guilt-trip ", so we do you a favor, and now you owe us ..." (IMO, it’s usually better not to say that “now you owe us” the part out loud but I don’t know your client).

Answer 3

standard practice is to specify user interface standards rather than accepting them

for example, double-clicking a column heading in a grid to resize is not standard Windows GUI behavior. However, double-click the column separator to resize the column.

it is worth specifying the standard behavior of the GUI, so there is no confusion; if you can reference an existing standard, that’s fine, but make sure the client signs it up

"I can’t read your mind, and such and such non-standard default behavior / behavior" is a logical cue ... but not very polite .; -)

Answer 4

My favorite college quote is “The great thing about standards is that there are so many to choose from.”

I assume that you are asking this question because you, unfortunately, got involved in the question "but you did not ask about it." This may put you in a difficult position. In general, you want the company to provide you with its own standard, or, as others have mentioned, you can mutually agree to a third-party standard. If you work with a company that produces many applications of the same type, you should spend time once to create your own “standard”.

If you are sitting at the entry point and someone refuses to pay because of the “standard” features, you need to have some examples of places where this is not standard. For example, in your example, the closed form on the evacuation key is standard only for Windows (and not for the Internet), and then only for Microsoft. I just opened three applications on my computer where ESC did nothing on the form.

Almost nothing is standard. In any particular case, the mind "standard" will mean something a little different and, if you do not indicate some measurable definition, will lead to arguments in the future.

Answer 5

Create a boiler plate specification that you include / reference in all your projects of the same overall design. This specification should grow and change as you learn more about your customers / customer requirements. This specification should also refer to relevant user interface recommendations submitted by Apple or Microsoft . Even if you are on the same platform, I highly recommend reading another specification to learn about the best ways to do things or to identify possible hiccups. There are also some good interface design books you might want to borrow.

Answer 6

Nothing is standard unless it is written down and indicated somewhere related to your project (or related to a specification). If it is not recorded, it is not standard, so the client must determine it.

In another note:
If your user interface library does this one way, and it requires coding to do it differently (silly example: you want users to click the right-click buttons), then you should stop and rethink what you can expect users