R – Usability: Should the ENTER key close a wizard form as OK even if the focus is not set on the OK/DONE button

controlsformsusability

I have the in my opinion odd request to close a wizard form as Done or OK if Enter was pressed on the keyboard even if the OK/DONE button is not focused.

In my opinion that would be a usability mistake. For example: In the wizard you may have multiple controls, buttons, check boxes, multiple line controls and they all have a different behavior on actions from the ENTER key. And don't forget the other buttons in the navigation of the wizard, what if they are focused?

Should these controls don't react on Enter like expected before? Should they do their actions but in other cases where Enter does no further action for the control it should close the form == inconsistent?

I think that is a typical request where the needs of one person would help him but confuse many other.

In my opinion Wizards are very special because they are not only made to make things easier but also very often focus on people with less experience with the functionality of an application. So I take every request serious and try to look into all arguments for and against the request.

Is my point of view to narrow? Are there some usability studies or guidelines especially for Wizards to backup my opinion or maybe proof me wrong?

Thank you very much!

Michael

Best Answer

I think the key is to test. You can't really guess what your users will find comfortable, you have to watch them try it. Especially since there are multiple incompatible standards you could follow, you are just going to have to see if this change works for most users in your audience.

Related Solutions

Explicit API methods vs. generalised parameter-based API methods

I would personally argue for (a), since our goal is to make the "static" code as accurate and reliable as possible.

By using the generalized form, we are introducing a risk for runtime errors. For example, I could set an attribute of type age with a value that is actually a string, etc.

This is very similar to the argument for defining and using enums or explicit types rather than using and returning ints in the old C style, as you get one more level of assurance.

While I agree that (b) allows extensibility, I have not seen too many APIs that would require this sort of extensibility for completely different types of attributes. The only common use of (b) is in polymorphic code, where the function could technically accept anything, including extensions.

Html – How to overcome the HTML form nesting limitation

I know this is an old question, but HTML5 offers a couple new options.

The first is to separate the form from the toolbar in the markup, add another form for the delete action, and associate the buttons in the toolbar with their respective forms using the form attribute.

<form id="saveForm" action="/post/dispatch/save" method="post">
    <input type="text" name="foo" /> <!-- several of those here -->  
</form>
<form id="deleteForm" action="/post/dispatch/delete" method="post">
    <input type="hidden" value="some_id" />
</form>
<div id="toolbar">
    <input type="submit" name="save" value="Save" form="saveForm" />
    <input type="submit" name="delete" value="Delete" form="deleteForm" />
    <a href="/home/index">Cancel</a>
</div>

This option is quite flexible, but the original post also mentioned that it may be necessary to perform different actions with a single form. HTML5 comes to the rescue, again. You can use the formaction attribute on submit buttons, so different buttons in the same form can submit to different URLs. This example just adds a clone method to the toolbar outside the form, but it would work the same nested in the form.

<div id="toolbar">
    <input type="submit" name="clone" value="Clone" form="saveForm"
           formaction="/post/dispatch/clone" />
</div>

http://www.whatwg.org/specs/web-apps/current-work/#attributes-for-form-submission

The advantage of these new features is that they do all this declaratively without JavaScript. The disadvantage is that they are not supported on older browsers, so you'd have to do some polyfilling for older browsers.

Related Topic