Is it ever acceptable to break extremely common interaction functions?

Question

There is an adage in web UX which goes 'Don't break the back button' which refers to the fact that the back button in a browser is such a consistent function that to create a situation where it's function is removed or changed leads to a bad user experience.

Within the context of human computer interaction in general there are other established conventions which are also extremely common. Such conventions include select something & Ctrl + C and Ctrl + N.

In some applications these conventions are broken and the user is required to learn application states or contexts before they are able to know when to use these functions or how to complete the same task from any given position, yet the functions could still perform an expected and controllable action while the application is in the aforementioned state.

Examples include Photoshop's transform state, during which copying what is selected does not work, or the PHP Storm removal of Ctrl + N to create new documents. In both cases the application would be capable of responding in an expected fashion to these commands.

Even in the most complex of applications is it ever acceptable to break such interaction conventions?

Answer 1

Of course it's acceptable to break common conventions, but you have to understand the costs of being unconventional.

Control-C was once a very well established command to interrupt and possibly abort the current program. The pioneers of modern windowing GUIs changed to the meaning to copy. Quite a drastic change but the benefits outweighed the cost of changing established convention.

But the instances of this (control-C) kind of drastic convention change working out for the better are rare. I recommend thinking long and hard about the pros and cons of such a change before trying it.

Answer 2

I can't think of an example when I've been pleased to have a program function in a way that was different from my intentions. Not working at all isn't nearly so bad as working-but-not-as-expected ... however ...

I've tried to avoid creating material that does this, simply because I've never seen it done right. Doesn't mean it can't happen - I've just never had a situation where it it just made any sense to do so.

Answer 3

No, you should never break commonly accepted standards. This is especially true for keyboard shortcuts, which people hit intuitively without thinking about them.

Any user is going to have a mental model of the way things should work based on their history of using other applications. If your application's working model does not match the user's mental model then they are going to think that either your application is broken or it's junk (or both).

In the end, they will get very frustrated and not want to use your application. Joel Spolsky has a very good lengthy article on the topic.

Answer 4

Being stateless is also a standard. But some problems are too hard to solve given the current toolkit. I think it's a miracle to be able to pay bills online, and perform banking functions in a browser. But at those sites I am in a forced flow, and wish to only move forward or cancel. The back button has no place in apps like these. Pressing it logs me out, which has become a convention, seemingly in conflict with "Don't break the back button."

Some functionality has to be conditional in complex apps like Photoshop, or when security is the primary design constraint. The trade-off of having a broken back button is outweighed by not having to preserve state.

Another instance where you might have to deviate from convention is when designing for experts or when considering other tools used in concert with your tool. Making sure your keyboard shortcuts don't trigger conflicting actions in JAWS may be a key requirement, so it may mean leaving some out to accommodate your users who require JAWS to work consistently. In this case, accommodating users' toolkit is a good reason to veer off.