Modern approach to radio buttons





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}








22















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




  1. Create New Work Order

  2. 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



enter image description here



My suggested options:



enter image description here










share|improve this question






















  • 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


















22















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




  1. Create New Work Order

  2. 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



enter image description here



My suggested options:



enter image description here










share|improve this question






















  • 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














22












22








22


4






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




  1. Create New Work Order

  2. 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



enter image description here



My suggested options:



enter image description here










share|improve this question
















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




  1. Create New Work Order

  2. 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



enter image description here



My suggested options:



enter image description here







forms gui-design radio-buttons






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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










6 Answers
6






active

oldest

votes


















79
















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






share|improve this answer























  • 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



















15
















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.



work order UI



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.






share|improve this answer

































    6
















    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.






    share|improve this answer























    • 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



















    3
















    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.



    toggle buttons example



    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.






    share|improve this answer





















    • 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



















    3
















    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.



    optional select



    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?".






    share|improve this answer

































      1
















      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.



      Visual Studio Example



      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.






      share|improve this answer



























        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
        });


        }
        });















        draft saved

        draft discarded
















        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









        79
















        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






        share|improve this answer























        • 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
















        79
















        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






        share|improve this answer























        • 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














        79














        79










        79









        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






        share|improve this answer















        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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        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














        • 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













        15
















        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.



        work order UI



        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.






        share|improve this answer






























          15
















          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.



          work order UI



          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.






          share|improve this answer




























            15














            15










            15









            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.



            work order UI



            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.






            share|improve this answer













            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.



            work order UI



            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered May 28 at 20:20









            ChloeChloe

            5474 silver badges13 bronze badges




            5474 silver badges13 bronze badges


























                6
















                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.






                share|improve this answer























                • 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
















                6
















                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.






                share|improve this answer























                • 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














                6














                6










                6









                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.






                share|improve this answer















                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                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














                • 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











                3
















                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.



                toggle buttons example



                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.






                share|improve this answer





















                • 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
















                3
















                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.



                toggle buttons example



                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.






                share|improve this answer





















                • 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














                3














                3










                3









                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.



                toggle buttons example



                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.






                share|improve this answer













                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.



                toggle buttons example



                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                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














                • 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











                3
















                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.



                optional select



                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?".






                share|improve this answer






























                  3
















                  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.



                  optional select



                  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?".






                  share|improve this answer




























                    3














                    3










                    3









                    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.



                    optional select



                    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?".






                    share|improve this answer













                    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.



                    optional select



                    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?".







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered May 30 at 13:43









                    BeejaminBeejamin

                    5403 silver badges11 bronze badges




                    5403 silver badges11 bronze badges


























                        1
















                        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.



                        Visual Studio Example



                        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.






                        share|improve this answer






























                          1
















                          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.



                          Visual Studio Example



                          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.






                          share|improve this answer




























                            1














                            1










                            1









                            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.



                            Visual Studio Example



                            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.






                            share|improve this answer













                            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.



                            Visual Studio Example



                            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.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            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


































                                draft saved

                                draft discarded



















































                                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.




                                draft saved


                                draft discarded














                                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





















































                                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







                                Popular posts from this blog

                                He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                                Bunad

                                Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum