Modern approach to radio buttons
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
I am working on updating the UI/UX of a 20-year-old application and I seem to be stuck at this particular use case.
On clicking on the New button, the system asks the user to choose one of two options
- Create New Work Order
- Create a new Task/Subtask for a pre-existing Work Order
Keep in mind that the system does ask for more information. It's not just this and based on the architecture of the application, it needs to know this (and some other) information before proceeding further.
My question is, what would be a modern way of showing the two choices to the user? Could it be one of the options mentioned in the screenshot below?
The old application screen
My suggested options:
forms gui-design radio-buttons
|
show 10 more comments
I am working on updating the UI/UX of a 20-year-old application and I seem to be stuck at this particular use case.
On clicking on the New button, the system asks the user to choose one of two options
- Create New Work Order
- Create a new Task/Subtask for a pre-existing Work Order
Keep in mind that the system does ask for more information. It's not just this and based on the architecture of the application, it needs to know this (and some other) information before proceeding further.
My question is, what would be a modern way of showing the two choices to the user? Could it be one of the options mentioned in the screenshot below?
The old application screen
My suggested options:
forms gui-design radio-buttons
35
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
2
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
1
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
25
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
6
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51
|
show 10 more comments
I am working on updating the UI/UX of a 20-year-old application and I seem to be stuck at this particular use case.
On clicking on the New button, the system asks the user to choose one of two options
- Create New Work Order
- Create a new Task/Subtask for a pre-existing Work Order
Keep in mind that the system does ask for more information. It's not just this and based on the architecture of the application, it needs to know this (and some other) information before proceeding further.
My question is, what would be a modern way of showing the two choices to the user? Could it be one of the options mentioned in the screenshot below?
The old application screen
My suggested options:
forms gui-design radio-buttons
I am working on updating the UI/UX of a 20-year-old application and I seem to be stuck at this particular use case.
On clicking on the New button, the system asks the user to choose one of two options
- Create New Work Order
- Create a new Task/Subtask for a pre-existing Work Order
Keep in mind that the system does ask for more information. It's not just this and based on the architecture of the application, it needs to know this (and some other) information before proceeding further.
My question is, what would be a modern way of showing the two choices to the user? Could it be one of the options mentioned in the screenshot below?
The old application screen
My suggested options:
forms gui-design radio-buttons
forms gui-design radio-buttons
edited Jun 24 at 15:49
Madalina Taina
3,2862 gold badges14 silver badges40 bronze badges
3,2862 gold badges14 silver badges40 bronze badges
asked May 27 at 9:19
Shreyas TripathyShreyas Tripathy
5,5554 gold badges22 silver badges38 bronze badges
5,5554 gold badges22 silver badges38 bronze badges
35
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
2
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
1
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
25
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
6
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51
|
show 10 more comments
35
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
2
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
1
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
25
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
6
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51
35
35
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
2
2
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
1
1
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
25
25
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
6
6
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51
|
show 10 more comments
6 Answers
6
active
oldest
votes
Short answer: Option 1
I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.
The other options presented by you are meant/better suited for other cases.
Basic rule of thumb is:
Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.
Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.
I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.
See this answer here explaining the differences:
https://ux.stackexchange.com/a/88135/67657
Or this NN Group article:
Checkboxes vs. Radio Buttons
Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
|
show 2 more comments
I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.
https://www.bootply.com/Ur1q177i95
This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.
add a comment
|
It depends on the context.
- Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
- A dropdown is useful if you do not have / want to use too much space
- option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
- Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
add a comment
|
You could use toggle buttons.
The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.
If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.
You can also use a more contemporary design where the selected choice is "highlighted" with a different color.
If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.
For desktop interfaces, radio buttons are still a good choice if the number of options is limited.
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
add a comment
|
One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.
If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.
If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".
add a comment
|
You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".
Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.
In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.
add a comment
|
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "102"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f125905%2fmodern-approach-to-radio-buttons%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
Short answer: Option 1
I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.
The other options presented by you are meant/better suited for other cases.
Basic rule of thumb is:
Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.
Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.
I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.
See this answer here explaining the differences:
https://ux.stackexchange.com/a/88135/67657
Or this NN Group article:
Checkboxes vs. Radio Buttons
Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
|
show 2 more comments
Short answer: Option 1
I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.
The other options presented by you are meant/better suited for other cases.
Basic rule of thumb is:
Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.
Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.
I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.
See this answer here explaining the differences:
https://ux.stackexchange.com/a/88135/67657
Or this NN Group article:
Checkboxes vs. Radio Buttons
Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
|
show 2 more comments
Short answer: Option 1
I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.
The other options presented by you are meant/better suited for other cases.
Basic rule of thumb is:
Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.
Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.
I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.
See this answer here explaining the differences:
https://ux.stackexchange.com/a/88135/67657
Or this NN Group article:
Checkboxes vs. Radio Buttons
Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus
Short answer: Option 1
I don't see any reason to make this more complex than two normal radio buttons. We have had these UI elements for so long for a reason.
The other options presented by you are meant/better suited for other cases.
Basic rule of thumb is:
Use radio buttons for up to a handful (max. 5-7) of mutually exclusive choices and when you want all choices to be visible.
Use dropdowns for a list of more than 5-7 options, where presenting them all would be visual overload.
Option 4 with a switch does not fit at all, as that is used for on/off metaphors, not choices between two equal options.
I guess option 3 would be possible too, but it doesn't really add any value over normal radio buttons, it might even confuse some users.
See this answer here explaining the differences:
https://ux.stackexchange.com/a/88135/67657
Or this NN Group article:
Checkboxes vs. Radio Buttons
Or this:
7 Rules of Using Radio Buttons vs Drop-Down Menus
edited May 27 at 14:00
answered May 27 at 13:26
Big_ChairBig_Chair
3,5871 gold badge16 silver badges33 bronze badges
3,5871 gold badge16 silver badges33 bronze badges
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
|
show 2 more comments
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
10
10
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
This. There is no reason to reinvent the wheel.
– Evil Closet Monkey
May 27 at 14:47
7
7
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
Why even complicate the design with 3 widgets (2 radio buttons and a "New" button) instead of having separate "New Work Order" and "Add Task to Existing Work Order" command buttons?
– jamesdlin
May 27 at 19:57
3
3
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
@jamesdlin - I agree and that's what I suggested too. But, that step would need to be introduced prior to the current one and there are some architectural bottlenecks which doesn't allow the system to make that change
– Shreyas Tripathy
May 28 at 4:54
10
10
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
+1 for "I don't see any reason to make this more complex." When web designers over-focus on aesthetics and forget functionality, the result might be beautiful, but it's unusable (Verizon's user website is a good example) - and therefore fails the purpose of its existence. You can paint a pencil any color and design you want, so long as the tip is easily sharpened and the led allows the user to write and draw.
– JBH
May 28 at 6:18
7
7
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
Agreed - also, I am always unsure about what Option I have chosen in the Option 3 method. Unless you add more text, like "Your selection is in blue background", it's never super clear to me. (And there are the even more terrible sites where clicking the options switch back and forth between them, adding to further confusion).
– BruceWayne
May 28 at 16:47
|
show 2 more comments
I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.
https://www.bootply.com/Ur1q177i95
This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.
add a comment
|
I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.
https://www.bootply.com/Ur1q177i95
This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.
add a comment
|
I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.
https://www.bootply.com/Ur1q177i95
This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.
I would create entirely new screens and buttons for the two tasks. Label them "Edit Work Order" and "Create Work Order". Edit is for editing an existing work order or add sub-tasks. Create is for making a new work order. The Edit button will be next to the work order in a list of open work orders. The Create button will be at the top of the page.
https://www.bootply.com/Ur1q177i95
This applies to your specific situation. For regular radio buttons doing radio button things (selecting from a short list of options), I would not change them.
answered May 28 at 20:20
ChloeChloe
5474 silver badges13 bronze badges
5474 silver badges13 bronze badges
add a comment
|
add a comment
|
It depends on the context.
- Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
- A dropdown is useful if you do not have / want to use too much space
- option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
- Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
add a comment
|
It depends on the context.
- Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
- A dropdown is useful if you do not have / want to use too much space
- option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
- Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
add a comment
|
It depends on the context.
- Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
- A dropdown is useful if you do not have / want to use too much space
- option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
- Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
It depends on the context.
- Radio buttons are great at showing the user all the possible options and clearly highlights what's selected
- A dropdown is useful if you do not have / want to use too much space
- option 3 (tabs?) are a very interesting approach if the content is dynamic, so the user instantly sees what changes with each choice. Although as mentioned in comments it might look confusing to users. Tabs separate categories of content; what happens with the content of the non-selected tab?
- Switch-type buttons are more familiar for on/off choices, and is the only option that won't scale well if you decide to add more options to your form in the future.
edited May 27 at 14:55
answered May 27 at 11:48
LucianoLuciano
9708 silver badges17 bronze badges
9708 silver badges17 bronze badges
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
add a comment
|
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
2
2
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
Tabs do not represent choices, they represent categories. Choices on a tab that is not currently visible are still valid. This is why "radio buttons" are troublesome.
– Evil Closet Monkey
May 27 at 14:47
2
2
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
@EvilClosetMonkey indeed, updated my answer to reflect that.
– Luciano
May 27 at 14:56
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
Option 3 looks a lot like a reskinned radio button collection I did once: Each "button" was a box in a row of boxes, the selected one had the background highlighted. Our users got it and liked it. In WPF, it was easy to do.
– Ed Plunkett
May 29 at 21:01
add a comment
|
You could use toggle buttons.
The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.
If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.
You can also use a more contemporary design where the selected choice is "highlighted" with a different color.
If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.
For desktop interfaces, radio buttons are still a good choice if the number of options is limited.
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
add a comment
|
You could use toggle buttons.
The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.
If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.
You can also use a more contemporary design where the selected choice is "highlighted" with a different color.
If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.
For desktop interfaces, radio buttons are still a good choice if the number of options is limited.
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
add a comment
|
You could use toggle buttons.
The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.
If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.
You can also use a more contemporary design where the selected choice is "highlighted" with a different color.
If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.
For desktop interfaces, radio buttons are still a good choice if the number of options is limited.
You could use toggle buttons.
The concept is thus of push buttons that offer mutually exclusive choices : when one button is pushed down, the other one goes up.
If using an old "push button" design, make sure it is obvious which button is down and which one is up. The picture below is not so good in this regard but only to illustrate the concept.
You can also use a more contemporary design where the selected choice is "highlighted" with a different color.
If your main goal is making the old interface compatible with touch devices like smartphones, a simple alternative is extending the sensitive area of you radio buttons to include the labels. However, is won't be obvious that the labels are clickable, unless you draw a frame that surrounds the radio button and its label.
For desktop interfaces, radio buttons are still a good choice if the number of options is limited.
answered May 28 at 10:47
OuzoPowerOuzoPower
391 bronze badge
391 bronze badge
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
add a comment
|
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
5
5
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
As Big Chair pointed out (and I myself have often to struggle), this approach is very unintuitive for the users eye. Example: If you don't know the system behind your UI, which value is now selected? The one with color or with white as background?
– Smartis
May 29 at 12:36
2
2
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
yes I have no idea which is selected in your 2 examples
– WendyG
May 29 at 13:16
1
1
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
There's a high probability that it would have taken me some time to figure out these are actually toggles and not buttons themselves and that there's a "Next" button too, and I would have been left wondering why the application just doesn't work at all, and also why the right button is disabled.
– EKons
May 29 at 18:44
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
I was aware that the examples I posted were for sure not the best ones as their look is unintuitive, but the graphic example was done in a hurry to illustrate that toggle buttons could serve as alternative to radio buttons, especially on small devices with touch-screen interface. I apologize for the poor illustration. There are tons of better examples if doing an image search, but I could not insert those pictures for copyright reasons. Sorry.
– OuzoPower
Jun 12 at 15:49
add a comment
|
One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.
If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.
If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".
add a comment
|
One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.
If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.
If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".
add a comment
|
One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.
If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.
If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".
One thing I haven't seen raised yet is that radio buttons should always have a default option selected, which suggests that the workflow here is primarily for adding a new work order and secondarily for adding a task - that is, if the user doesn't touch this control, and fills in the rest of the form, they get a WO, not a task.
If that assumption is correct, you could just ask them to choose a parent WO if required with a select. This might be tricky, depending on if you can look up a list of candidate tasks at this stage, and how many there might be.
If you can't get that information, or if it's not practical to choose from the candidates here, you could go with a simple checkbox "Attach as sub-task?".
answered May 30 at 13:43
BeejaminBeejamin
5403 silver badges11 bronze badges
5403 silver badges11 bronze badges
add a comment
|
add a comment
|
You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".
Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.
In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.
add a comment
|
You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".
Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.
In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.
add a comment
|
You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".
Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.
In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.
You could replace the original "New" button with two buttons, one for "New Work Order" one for "New Task".
Consider the screenshot from a Microsoft application below. The File -> New menu item is actually a menu that lists the different types of New "things" the user may want to create.
In your case, there would be no need to place the buttons in a separate menu, just replace the original "New" button with the two options.
answered May 29 at 15:04
Harrison PaineHarrison Paine
1,8642 gold badges7 silver badges10 bronze badges
1,8642 gold badges7 silver badges10 bronze badges
add a comment
|
add a comment
|
Thanks for contributing an answer to User Experience Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f125905%2fmodern-approach-to-radio-buttons%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
35
Your option 4 is not the same as radio buttons; I'd say these are more appropriate as switches for status (on/off is the most common) that can be changed at any time, while radio are more used on permanent choices (before submitting a form for example). Check this ux.stackexchange.com/questions/90532/…
– Luciano
May 27 at 10:02
2
After user clicks New, and then again Clicks on one of these options (no matter what scenario), does something happens? Is he redirected on another Adding screen, are fields loaded, is there some system message?
– xul
May 27 at 10:21
1
@Luciano - I agree. Switches make sense for Yes/No choices. What about Option 3? Would that be considered as a selector or a switch?
– Shreyas Tripathy
May 27 at 11:11
25
Is nobody asking why "create new work order" and "add task to existing work order" are combined into one screen to start with? I would expect that "create new work order" would be a button on the page listing all of the open work orders, and to add a task to an existing work order, I click on that work order, and then click "add task to work order".
– immibis
May 28 at 0:54
6
@immibis, also why would this be a radio button in the first place? There are two different actions, there should be two different action buttons.
– Simon Richter
May 28 at 12:51