New answers tagged radio-buttons
There are a number of UI issues in this approach The use of radio buttons in titles of accordions : A radio button or radio button group is often used when you are selecting a single value among two values or a collection of values. The use of radio buttons to highlight which all accordions have been opened (not even completed) would confusion as it does ...
I can see they are trying to combine selecting a payment type with entering the details by utilising a non-standard "radio button/accordion" widget, but this does not look like a smooth user experience to me either, e.g. it is adding confusion by offering multiple interaction points, and is forcing the user to think too much. A simple drop-down menu and ...
If the user selects a choice then make the selected button with a selectable style but also change the style of the other button to indicate that it is not selected. The target is to make the user select one or the other. Look at the design below: Yes No If you want to emphasize that this is an important choice allow the user to deselect the selected ...
I recommend using another pattern and ditching the radio buttons. Personally, and according my company pattern library, the maximum for a set of radio buttons is 5-7. For anything higher than that, autocomplete/typeahead (as suggested by @prerit-mogre) or a select menu (as suggested by @gino-van-de-staaij) will provide a simpler interface for your users.
As mentioned by Gino, with bigger label lengths you might run into problems. Whereas a good solution to radio buttons are searchable dropdowns. Something like this should work if Master-Detail interaction pattern doesn't work for you.
From the moment you can only choose one item, could a drop-down also do the job (perhaps even with a grouping as indicated above)? The reason I suggest this, is that judging by your example, you might get into layout problems when you have items with varying label lengths, which in turn might prompt you to choose for a vertical list (and as a result take up ...
There are a number of different strategies that you can apply, depending on the relationship between the applications (or lack of): Grouping: try to group applications of similar function into a subset and provide a label, that way the users can scan the headings first and reduce their search space. This strategy will work if you end up having to add ...
You can use Master-Detail interaction pattern, see the image: The list is fully visible, so you can observe and choose any item quickly. If it's possible, try to group the applications in some meaningful way, like Photo & Graphics, Office, etc. This will help to navigate on the list in a faster way.
Accessibility. Focus state tells keyboard users where their cursor currently is on the page. By just visually looking at a form with a focus state on a radio button I would instantly know that if I press tab then I will move from this field to the next. Without the focus state you won't have any visual indication of where they are on the page. Now, ...
A simple form like you might see at certain kiosks have the choices embedded in the action: This would inherently force a response while also removing the clutter of any "Next" or "Continue" buttons. A button is a one-click response. Why not a radio button or drop-down? It's far easier to push a button on a mobile device than it is to fool around with ...
I would not esitate to use a set the interested checkbox as mandatory. In my opinion UX should take into account the marketing requests too. download bmml source – Wireframes created with Balsamiq Mockups
What about this idea which I attached below? In this you can display the image title below the image as shown here and on mouse hover event you can show the description on light background on the image. One more thing just add paging below the list and fix your screen so only listing portion will get update.
I would recommend a single selection grid. This link has an example (choose "row selection"). If your list is very long, you may also add a search box.
I think the both options which you mention can be use with minor changes. you can give validation/constrain i.e. An error message "Please select your citizenship" when user press the submit button without selecting yes/no. Short and sweet ! No need to think another solution and waste the time in such a small matter.
One potential solution is to use a call-to-action type of interaction, so that at the beginning of the form you can have a button that says something like "US citizens click here" and "non-US citizens click here" that then helps to 'force' people into making a selection before proceeding further. However, I would only use this if none of the other options ...
There're three cases that you have to be able to identify: yes / no / not-specified (i.e., user did not interact with this element). But if you pre-select yes or no then you won't be able to distinguish it from the not-specified case as you pointed. I'd suggest to use radio buttons or a drop-down (as both options are mutually exclusive) without ...
Top 50 recent answers are included