3

I would like to prevent users from being able to submit a form where the selection hasn't been changed from its original state.

Example:
enter image description here

In the wireframe above, when the user sees this form, the original selected option is Option 1. Since the user didn't change the option, I disabled the Save button. If the user selects Option 2, the Save button will be enabled.

I'm worried that users would be confused as to why the Save button is disabled, but this may be the best solution to prevent them from submitting a form that has no changes.

Thoughts?

EDIT:

Came up with a design that I thought could potentially solve the problem, but a developer mentioned that the disabled-looking text doesn't really make sense. May be better to get input from UX-ers!

enter image description here enter image description here

  • 1
    When would you want to prevent a user submitting a form if no changes are made? What if the user doesn't want to make a change? Do they have to select Option 2 then select Option 1 again? – Michael Lai Mar 26 '15 at 1:09
  • In the example above, if the original state is Option 1, we would not want them to be able to be able to "Save" as Option 1 again until the setting has saved as Option 2. I hope that makes sense. – Yeezy Mar 26 '15 at 15:36
  • 1
    The updated design is very confusing IMO. I don't understand why you wouldn't go with one of the options below since this is a very common pattern and it has lots of precedents. Why force users to try to understand an unusual interface when there are common patterns to use. Is there something different about what you are trying to do? – tohster Mar 26 '15 at 18:42
  • I appreciate the feedback, @tohster. In regards to the alternatives you posted, I was told by the dev team that they want to avoid writing code to do a "check" to see what the selection was before since it would take an extra day of coding so I'm attempting to come up with a design solution that would avoid that situation – which means a solution that would prevent the user from re-selecting their current option as well as needing to check their current option. That basically rules out alternative #1 and #2. – Yeezy Mar 26 '15 at 20:09
  • @Yeezy got it. Given that they are prepared to render different content for different choices, this is something that should be impmementable client side using Javascript, but I sympathize that this is a battle you may not want to fight :-) – tohster Mar 26 '15 at 20:33
3

This is OK and acceptable behavior. BUT:

common alternatives are:

  1. Allow the user to press save. Disabled buttons can be frustrating to users, and after all, there is no harm done by just re-saving the existing option. This also fixes an awkward case where the user selects Option 2 (enabling the save button) and then re-selects option 1 (do you then disable the button again? if so that can be confusing, if not then the form has inconsistent behavior).

  2. Disable the submit button but inform the user. If the user clicks on the save button, show a notice below the button telling the user that they haven't change their selection.

  3. Hide the submit button unless the user changes the form. This is an outdated pattern because a form without a submit action is confusing. Don't use it except in corner cases which I won't go into.

I have a strong preference for #1, because disabled controls can be disorienting to users. It's better to have a consistent form (UX consistency) and hide the complexity by handling it yourself.

  • It's probably good to mention that clicking submit would hide the radio buttons and bring up a status message showing that the task is being completed. If they select Option 1 when it is already in Option 1, the dev noted that it will never complete since it's already in Option 1. I'm thinking your third suggestion might be a good idea, but why is this to be avoided other than the fact that the submit button is not immediately available? – Yeezy Mar 25 '15 at 20:31
  • 1
    @Yeezy for option 1, you could still bring up the notice to say Save complete. Remember, user flow is different from application flow and sometimes you need to do redundant things in the app to ensure consistency of UX. For option 3, it's disorienting to users to see a form with no indication of how to finish the workflow. This is another example of how application logic differs from UX logic. Logically you cannot submit the form without making a selection, but from a UX perspective the Save button serves more than just a function purpose: it communicates workflow too. – tohster Mar 25 '15 at 20:39
0

If you need the user to change the selection, disabling the save/submit when the user wants to retain the selection may not be the optimal experience.

Some alternate strategies would be:

  1. Make the button show Save, and then Submit so that if the user wants to retain option 1 there is an explicit confirmation. If the user wants to change to option 2 there is also a save confirmation before submitting. However, this is also confusing if there is a chance that the user may change their mind again so it is not recommended.
  2. If the user doesn't make a selection change, when they click on save/submit you can bring up a confirmation dialog asking if they want to make a change, and get their confirmation for retaining the selection.
  3. Show their previous selection but clear the radio button selection states and allow them to explicitly make a selection for option 1 or 2.
0

I'm not sure I have understood your problem, anyway I see 2 solutions:

  1. Use a checkbox like confirm option 2, the user will be forced to check it (modern browsers will add a prompt if the required attribute is present) . This is seen on many website where you have to accept Terms of Service to complete an order, etc.
  2. Use <input type="submit" ... > or <button type="submit"> ... </button> for each option (use the name"... " attribute to differentiate the choices), so the user will have to choose an option by clicking on it.
0

Make the change option explicit

Eg if option 1 is the existing choice and the are 4 other options

Layout would be

You current choice is

Option 1 (x)

Change to.....

Option 2 ( ) Option 3 ( )

Etc

Makes change explicit and reduces cognitive load

How you choose to present will depending on your programming overhead(eg sort order etc)

Also by making colour. Eg the selection bos is highlighted, coloured green etc

Save button would only activate if a change request was made

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.