Remove selection from radio button

[Charity]

If I create a value list with custom values and begin it with a carriage return before I type my choices, the pop-up displays a blank at the beginning so that the option is also to blank the field. But if I use the same value list and attach as radio button, it does not provide the blank 'circle'. Why is the behavior inconsistent?

It makes sense not providing the blank on checkboxes because they can be unchecked but radio buttons can't. I read about using shift to 'remove' a radio button selection it does not seem like the right approach. I would have to put a message above all my radio buttons (which I will allow removal of data).

Also too, why does it then insist on centering the items in the field instead of left justify as I have specified (please see attached). All I can think of is to create my own circle or just a button and put it next to this field and call it "clear."

Ideas on how others handle this please? It seems like I want to make that field toggle each entry when selected again, item on then item off but still only one allowed to be selected.

Char

radio button.zip

[Skye]

Hi Charity,

Simple answer is that Check Boxes and Radio Buttons are different animals. I also leave a return (blank space) if my application is a Menu item that I want a fixed set of data for and would like the option to have "blank". But Menus and Check Boxes are independent logic, meaning they are on or off (yes or no logic) regardless of the status of other Check Box or Menu items in the same list. A Radio Button is either/or allowing one selection of the items in the respective list you have made. The method for creating the list is the same, but the logic use is different, hence the results you are getting. Adding a return should just add some space on the let side of the left circle.

Radio buttons can be cleared by using the delete key, or as you suggest (and I have used for clearing forms) making a Clear Button.

Hope that helps...

-Bob Skye-

[comment]

It makes sense not providing the blank on checkboxes because they can be unchecked but radio buttons can't. I read about using shift to 'remove' a radio button selection it does not seem like the right approach.

Radio buttons are not supposed to be unselected. You could use "<none>" or a space as one of the value list items - but it would be a rather strange animal: is the selection supposed to show? Or is selecting a blank supposed to deselect it? Both are possible, and both exhibit a jarring inconsistency.

[Vaughan]

I use these options for gender:

Unknown

-

Female

Male

... with an auto-enter calc on the field that selects the first value (ie, Unknown) as the default, and does not allow the selection of more than one value.

Case(

isempty( self ) ;

getvalue( valuelistitems( get( filename ) ; "Gender " ) ; 1 ) ;

getvalue( rightvalues( self ; 1 ) ; 1 )

)

[comment]

Do you also auto-enter "Unknown" into the FirstName field?

[Vaughan]

This is for radio buttons, which work well for Gender.

As for First Name field, not sure where you're going with this question... it may be appropriate in some circumstances to have Unknown entered.

I have a case management database for a phone-in abuse hotline that does this for First Name and Surname because often the callers don't leave names, or only leave their first name or last name. Something has to appear.

[comment]

As for First Name field, not sure where you're going with this question...

I was trying to illustrate the illogic by providing an absurd example of the same. I presume you aim to give your users a chance to change their mind and revert the field back to empty. I am not sure how often they need this ("Oh, I thought it was a guy, but now I'm back to undecided"?), but in any case I don't think using a data-level device (an arbitrary value to represent "empty") is a good solution to a presentation-level problem.

[Vaughan]

In his case the client is generating reports and they need to be able to say that 34% are male, 36% are female and 30% are Unknown. The Unknown is important because often it is the largest percentage due to poorly gathered stats.

And yes, if they don't know that the case is male or female then it is unknown. The field is never empty, it starts off as being unknown through the auto-enter calc on record creation. An empty field indicates that something is wrong with the data.

This method has been developed through years of people getting reports with an empty blank line at the top and asking what that means. Solution = no empty values.

[comment]

Well, the question here was how to make a radio buttons field deselectable - i.e. return it to its initial empty state.

Your approach requires a non-empty selection to be made and provides an initial one. So if we ignore for a moment the question when is "Unknown" a legitimate non-empty value, you are saying the same thing as I am: that radio buttons are not supposed to be unselected.

[LaRetta]

Radio buttons are not supposed to be unselected. You could use "<none>" or a space as one of the value list items - but it would be a rather strange animal: is the selection supposed to show? Or is selecting a blank supposed to deselect it? Both are possible, and both exhibit a jarring inconsistency.

Radio buttons are not supposed to be unselected? Of course they are.

A pop-up menu and drop-down list also expect only one selection but they provide ability to add a blank (thus remove the selection). Even FMI realizes that a User might make a mistake on radio button and need to remove their selection:

"Click the button to select the value. To clear a button, Shift-click it."

A User, if they have the rights, should be able to modify or remove their entry; simply they can change their mind or make a mistake. It is upsetting if they cannot clear a field because their finger slipped and they accidentally selected something from a bear-trap radio button.

The issue is not whether radio button should be allowed to be cleared but rather that, since FMI did not provide a User-obvious method of removal, we must handle it ourselves. I use CLEAR button next to field like Bob uses but I also like Vaughan's idea of <unknown> in the value list. A <clear> in value list could eliminate the Clear button which adds clutter. Then auto-enter replace can remove it as:

Case ( Self ≠ "<clear>" ; Self )

In this way, invalid selections will not remain in the field which can mess up searching for non-empty values, counting them etc.

Edited December 26, 2011 by LaRetta

[LaRetta]

BTW, I am opposed to using Shift-click and I never want Users to even know about it. Why? Because if they know to shift-click to deselect an entry, they can figure out that they can shift-click to select more than one. Of course we can validation to every single pop-up, drop-down and radio button field to prohibit more than one entry and maybe we should. Then we can teach shift-click to all our Users so they can use it on ALL value lists. But I feel that is not the best approach.

[comment]

IMHO, radio buttons should be used where a user is required to make a choice*. I cannot come up with a good example of an exception, but if there is one, then either teach users to shift-click or to press delete (perhaps provide a tool-tip for this) or give them a button to clear the field.

I am still hoping to evade the "null vs. empty" discussion, but it needs to be said that a deliberate entry is NOT the same as no entry at all.

---

(*) BTW, I am not the only one to think so:

http://www.useit.com/alertbox/20040927.html

[LaRetta]

I too considered the null vs empty issue and decided not to pursue it.

Comment said, "radio buttons should be used where a user is required to make a choice*"

Radio buttons are used to clearly notify the User that only one entry is allowed and to show all possible entries for ease and clarity of selection, not to attempt to force them to select something. We force by other means, radio button or not.

Useit.com in your link also said, "Always offer a default selection for radio button lists. By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection."

Okay, then the auto-enter default selection should be <empty> or <null> or <not specified> meaning no value has yet been selected by the User. Pressing Delete is also bad because if they are not careful, they can be in another field and delete a value. They can delete from pop-up also but FMI realized need to provide blank.

Anyway, it is rare that I do not agree with you and even then, your logic usually sways me but not this time, I'm afraid. If a User makes a selection and changes their mind, they need the ability to remove it. And if that means changing it back to the original default value then so be it. But a default value is not a User-selected value so it should clearly be a word which indicates its null quality meaning 'no selection made by the User.' :sleep:

[RodSierra]

I've always thought of a radio button set as having one value as the default or preset, never a condition where the field is empty. In cases where the field is required to be empty I believe a radio button set is the wrong choice for the interface. We always error on empty or multiple selections. Sort of like a rotary switch that all of a sudden can have two settings at once, or none at all, it seems to me to be intuitively wrong.

[comment]

Radio buttons are used to clearly notify the User that only one entry is allowed and to show all possible entries for ease and clarity of selection, not to attempt to force them to select something.

True, but I still cannot think of a case where radio buttons would be a suitable choice AND an empty choice would be acceptable.

Anyway, my issue is with introducing a fake non-empty value just to get over the users' lack of skill in resetting radio buttons back to empty.

Useit.com in your link also said, "Always offer a default selection for radio button lists. By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection."

Well, that may be a bit too rigid for my taste. For example, I can't find fault with using radio buttons to classify a transaction as Parts, Sales or Service (as per the value list in the OP file) and I don't see why any one of these should be pre-selected as default.

I do, however, find fault with allowing the choice to be empty - and therefore cannot see a case where user would want to cancel a choice (as opposed to correcting it).

[LaRetta]

Hi Char,

Regardless of one's preferences, here is valuable tool in deciding how to use Controls and most aspects of design. I see they have just updated it again. Nobody does UI better than Apple.

http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/OSXHIGuidelines.pdf

[LaRetta]

Hi Michael,

My original suggestion left the field clean and only affected the display. I am glad we agree that default-entered value is not the issue and empty radios are fine. My agreeing to accept ‘always enter default’ was attempt to compromise.

I do, however, find fault with allowing the choice to be empty - and therefore cannot see a case where user would want to cancel a choice (as opposed to correcting it).

One inescapable case … mistakes happen. You believe they should correct their entry immediately but they can only correct it if they know the correct answer. Many times, the value selection comes from outside source …

Customer chooses 2ndDay for ShipMethod while on phone to UserA then says, “Oh wait, let me check with my son, don’t ship 2ndDay, and I’ll call you back.” Should UserA leave it 2ndDay or change it to Ground? Clearing the field does two things, 1) it adheres to the customer request about removing 2ndDay and 2) it tells the business that there is information yet to be gathered on this order. Information in a field should be correct (or corrected) or it should be removed.

Customer calls back. UserA is on vacation. UserB sees 2ndDay specified and it is assumed that the ship method was already gathered by UserA because otherwise it would be empty. Later it is determined that UserA had added a note in the customer file and had also told their supervisor (who promptly forgot) but that was after the fact. So when customer gets side-tracked talking about their new grandson to UserB and forgets to bring up the ship method, UserB has no reason to question 2ndDay. The order moves through. Customer is livid. Customer's file clearly shows that they requested to remove 2ndDay. Note in file says bear-trap radio button is at fault (LOL).

Or UserC who accidentally marks an estimated earnings field “over 100,000” because his elbow was bumped. UserC has no idea of the correct earnings (which is why it was left blank to begin with). UserC cannot make a different choice because that would be just as incorrect as his accidental selection.

The simple answer is – if it started out empty to begin with and a User makes a mistake, allow a User to return it to empty (again skipping null vs empty discussion) if they cannot correct it. Radio button IS the right tool - we want only one value and want all of the choices displayed.

Anyway, I am not trying to convince anyone; I only wished to address the different between cancel or correct and why we might need to cancel. At a small company where I worked in same room with Users (early in my FM career), they would come to me to clear a radio button until I finally provided the Clear button. And they all had good reasons for needing to clear it; in every case, it was because it was chosen by mistake and they did not know the correct choice to re-select. :-)

[comment]

OK, so where is the part that we disagree upon?

[Raybaudi]

Also too, why does it then insist on centering the items in the field instead of left justify as I have specified (please see attached).

The misalignment was due to the empty invisible "circle".

Now you can push the same radio to clear itself.

radio button MOD.zip

[LaRetta]

Oh good because I was trying to shift my thinking to yours and simply could not do it, LOL. I could have sworn by reading what you have written, particularly what I last quoted, that you disagreed with User cancelling their selection instead of correcting it. So we agree on the following?

• Radio button is right tool if you want only one value selected and want to display all possible values.
  
• No predetermined default value is required for radio button; empty is okay when record is created.
  
• If User does not know the answer, User should not make a selection.
  
• If User makes selection and changes their mind, User should correct it by choosing a different item.
  
• If User cannot correct it (does not know the right choice) because they chose it by accident then User should delete their value and return the field to empty.
  

If so then we are back to the only issue being ... how to delete an invalid entry. I agree that only valid data should remain in a field but an option of Unknown (as in Vaughan's example) seems legitimate as well.

1. Use Delete key: Radio button does not show cursor position so it is easy for User to not realize they are in different field and they can delete something else by accident. If used, I suggest using active field highlight so User is very clear of which field they are in when they hit Delete.
   
2. Use Tooltip: I like it. But if tooltip tells them to Shift-Select then it opens problems because if they do it wrong, they will notice more than one entry can be selected (BTW, I consider this a bug). If tooltip tells them instead to hit Delete then see 1 above.
   
3. Use Clear button: Works well, can be kept small right next to the field.
   
4. Sentence on layout: Place under the radio button explaining how to remove the entry.
   
5. Use Radio button itself: Add <clear> inside the radio button as one of the options (file attached).
   
6. Use script as Daniele suggests ... best choice, in my opinion.
   

TestRadio.zip

[comment]

I could have sworn ... that you disagreed with User cancelling their selection instead of correcting it.

Well, yes - sort of. But that's a business rule, isn't it? In most cases, I would validate such field as not empty (and perhaps a member of value list). But if you have a business case for reverting the field to empty, then what I said in post #12 applies.

I liked Daniele's solution, too.

[David Jondreau]

Very nice, Daniele. Seems pretty easy to add another If[] statement to prevent a user from shift-selecting multiple values.

One of my biggest bugbears is a user can still paste into a radio button (checkbox, etc) field. That drives me nuts. You could solve that in the same script, by hardcoding the Value List name into another If[] statement. But I hate hardcoding names.

Is there a way to get the name of a value list attached to a field?

[Raybaudi]

I must say however that I am not happy with my solution.

If, through drag & drop, I bring the value of another field in the radio field, the script clears the field of origin.

[comment]

And now?

RadioButtonToggle.zip

[Raybaudi]

Yes, so it works w/o clearing the origin field but now we have to avoid that someone could insert an incorrect value in the Value field.

Try to drag Name ( or any other field contents ) and drop to Value ( or to Status ).

BTW: I'm near to the solution, again with a composite Script Parameter. The one thing that I cannot solve is the pasting.

[comment]

someone could insert an incorrect value in the Value field.

They can do that with a "regular" radio button field, can't they? That's where validation comes in, I think.

[Raybaudi]

... but I bet we can avoid resorting to the validation, sure for drag&drop, not so sure for copy&paste.

[comment]

Sure you can: run another script OnObjectValidate. What does this (data integrity) have to do with deselecting a radio button (layout behavior)?

[Raybaudi]

It seems like I want to make that field toggle each entry when selected again, item on then item off but still only one allowed to be selected.

Done.

Seems pretty easy to add another If[] statement to prevent a user from shift-selecting multiple values.

Done.

One of my biggest bugbears is a user can still paste into a radio button (checkbox, etc) field.

Done.

The example shows that the field formatted as radio button:

1) allows the deselection of an item already selected

2) does NOT allow multiple selection

3) does NOT allow drag and drop

4) does NOT allow copy and paste

P.S.: I forgot to say that the scripts are independent of the field used ( but need the script parameter ) and then portable

better radio buttons.zip