4

Context: In our application we implemented a responsive disclosure. Currently the choices the user can make are rendererd as a set of radio buttons. Currently there a two valid options, A and B. When the user initially opens the dialog NONE of these is selected. The user can close the dialog with ok even if he didn't choose any options in the disclosure. The underlying object is in an error state as long as the user didn't choose any option in the disclosure but the user can fix this at a later time, so he isn't force to make the choice right away (the first time the dialog is opened).

Question: In rare cases the user should be able to "deselect" his choice. Radio buttons usually cannot be deselected. To give the user the possibility to "double click on a selected radi obutton to deselect" seems to me like a break in consistency (on a component level).

The cleanest solution would be to add an additional "Not selected"-Option to Option A and B. The problem is that this error state is rendered equal to the other two Options although its an error state for the underlying object. (We intend to render an error marker for all fields which are not correctly filled out) Our current approach would be to render a combobox with an empty selection with "Please select" like we see it in web forms. Other parts of the application also use this behavior of an empty selection in a combobox so its nothing knew to them.

But is this a good idea? Is it ok to render an option in a radio group even if its choice is an error state? Are their any other options?

Edit: Clarification: In the end the user has to make a decision. Dialog is used from multiple users bot not every user has the knowledge to make a decision for the radio buttons.

6

I think all options you have are not that good.

  1. Adding "none" option spoils the overall idea, because "none" is not an option. It just shows options can't be used.
  2. Radio buttons without selection is an anti-pattern
  3. ComboBox is not a good replacement for a radio buttons.

According to my understanding of the problem, you have two options. In some cases those two options are not applicable at all. (Please correct me if I'm wrong).

So will it be a solution to clearly render that additional state (when no options can be selected)?

For example, here is a rough idea:

enter image description here

Ok, so after all clarification provided I can suggest two options:

  • Option A: Use something like ON/OFF button in order to clearly highlight answer has been postponed.
  • Option B: Provide another option to let user clearly specify the answer will be (should be) provided later.

enter image description here

Here is how "Remind be later" switch could work:

enter image description here

  • I like the idea of the enable state, but the problem is, that the user has to decide an option. The dialog is used from multiple users thats why the decision about the options are delayed. (I Updated my question) – morpheus05 Jan 26 '15 at 12:56
  • Thank you for the clarification. Please check updated answer. – Renat Gilmanov Jan 26 '15 at 13:46
2

Since the selection doesn't need to be made "right away", my suggestion would be to place the mandatory decision at a later place in the routine where the user is at a point where the user MUST make the decision, if that's possible of course. It might even result in cleaner coding.

  • That idea would not be bad but the problem is, that at least two users work on the same data. In 99% of the cases only one of the user has the knowledge to choose the correct option and not even at the beginning. The application has not possibility to know when this will be. – morpheus05 Jan 26 '15 at 17:01

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.