Hopefully this won't be too much of an opinion question, if it is, I apologize:
I presented an idea to the UI lead for our project. I am a developer and mainly handle server-side coding, but occasionally dabble in the UI. There is a section on our webpage where the users are only allowed to select one option from a group of options (in our case, brands, when filtering search results). From this group of options, the user may only select 1. That is, if you select 1, any other selected choice is unchecked.
The UI developer implemented these brand choices as checkboxes, and I suggested that they be implemented as radio buttons, since only 1 can be selected from the group at a time.
For some reason, I always associated checkboxes with multiple choices allowed (usually), and radio buttons were used for things that were mutually exclusive, only 1 could be chosen.
Is there any UI/UX design standards or conventions that supports my stance, or am I wrong, is this simply a preference? The UI designer seemed to think that I was way off base in my suggestion.
In my opinion none of the approach is wrong, in fact any of both can be used since we ultimately need to allow user select only one option out of all BUT it all comes down to the degree of customisation and possibility of extensions. In fact 3rd approach could also be using dropdown.
But if I had to choose one of these 3 approach, I would go for the Checkbox approach because of following reasons:
It gives freedom to change. Let's consider in case if in future we ever need to allow user choosing multiple options, checkbox wouldn't need to be replaced. In fact one filter component can be made and it can take option if we need to choose one or multiple and behave accordingly.
Users are familiar with checkbox. Let's admit this we all learn from the leaders, apps like Amazon allow filter through checkbox and users are familiar with that pattern.
In case of radio button the possibility of customisation does lack while I discourage using the dropdown (3rd approach I mentioned above) as user won't be able to see all the options in case of dropdown.
Related
I use a multiple-choice grid in a google form. How can I dieactivated all checkboxes in this form?
I started to do some tests with the Google Forms configurations and settings.
Sadly it would not be possible to remove the checkboxes as you suggest. Mainly due to the way the Forms interface works or is presented, for example:
Due to the rows and columns functionality. It might be a better idea to introduce a drop down menu if you still want to provide multiple choices, for example:
I can see an option in the future to change the style or design of the multiple choices. You can send feedback for something similar in the future here:
https://www.googlecloudcommunity.com/gc/Feature-Ideas/cmp-p/grouphub:workspace-ideas-group
Or
Click on the help icon (at the bottom of the form) and select the option to report a problem to send a suggestion or feedback.
References
https://support.google.com/docs/answer/7322334
The question I have is about the general functionality of the back button in wizards. I was thinking about the possible behaviors of this button and I couldn't find any clue which one is the right choice between these two options.
1- It should show the previous page and the changes made in the current form shouldn't be saved.
2- It should show the previous page and the changes made in the current form should be saved.
I would like to know which option you think is the correct behavior for the back button and why.
The pretty sensible Windows guideline from Microsoft is;
Preserve user selections through navigation.
For example, if the user
makes changes, clicks Back and then Next, those changes should be
preserved. Users don't expect to have to re-enter changes unless they
explicitly chose to clear them.
See UX Wizards guide.
We're trying to show checkboxes for the 700+/- options that the user has. It's to map users to accounts, for all intents and purposes.
The checkboxes start runing extremely slow under Internet Explorer 8. Firefox, Opera, Safari, etc. run like a champ without issue.
Does anyone have a better, faster, and cleaner method (other than checkboxes) to utilize for this?
We wound up going back to the users and showing them the fact that the page rendered like crap, and ultimately, they said "That's not a problem"! So, we're stuck with the 2,100+/- controls :/
There are several options:
Use a select control. Consider using two select controls, and copying the selected values from one control to the other. This is more usable than a large multi-select.
Split your form into multiple, smaller pages.
Allow the user to complete a portion of the form, and load the additional parts via AJAX as needed.
Does anyone have a better, faster, and cleaner method (other than checkboxes) to utilize for this?
I think you should Page your data in a table with multiple page. 700 checkboxes is a UI-Smell from my point of view.
Even if is feasible in the other browsers, from the point of view of user friendliness it would be a nightmare.
One possible solution:
1.- Instead of checkboxes use to select lists, in the left one put all the available one, in the right the ones selected
2.- Categorize and/or divide in multiple steps
3.- Add a addAll and removeAll buttons for each page/category
Why dont you use 10 user controls with jQuery in it and render all the controls at pipe line. This way its not too much load at the server side and your controls will be async with each other.
Just my cents on it..
I have a form for lawyers where they need to be able to select which states they are licensed in.
So, they need a clean way to be able to select a few states from all 50 states.
What I'm not sure is, how to handle this in HTML. Is there some possible way to have a drop down of checkboxes or something similar?
I'm using ASP.NET MVC. I'm also curious how the model binding will look on the return for something like this.
Thanks,
Simpatico
This jQuery plugin might help.
Binding should work like for regular select with multiple selected items allowed.
You cannot put checkboxes in a dropdown unfortunately, the closest you could get is something like
<select multiple="multiple">
<option>One</option>
<option>Two</option>
<option>Three</option>
</select>
but I don't think that would be too useful for 50 states.
You can consider following the approach widely adopted in desktop applications.
Put two select windows together on the form - the one for all available options, the other one for the ones the user has selected. Also put two buttons, preferably between those two windows - "Add item" and "Remove item".
Now the user will have a good overview of the current selection. A little more work but very good from the usability and smooth user experience point of view.
I work on a web application product which allows mnemonics (i.e. an underscore below the character 'C', to allow a keyboard combination and the key C to trigger the "Close" button).
Forms are created by different developers and they can each statically set mnemonics for buttons.
Forms can be nested, so it is not necessarily known at design time the exact mnemonics which will be required for one page.
There can be at most one mnemonic using any character on a page containing many forms.
And here's the kicker, the forms must be able to be localised into any language, meaning that the 'C' for close may not even appear in the... [insert language] word used for "Close".
The ideal solution would be some algorithm where developers didn't have to manually specify a mnemonic, instead they would be worked out at run-time, they would be localised, and they would be both convenient and consistent (I did say the ideal solution ;-D).
So I was wondering, are there any good strategies for achieving something anywhere near the ideal solution?
EDIT: To clarify,
I'm not talking about keyboard accelerators, such as Ctrl+S for save, which is hidden on a menu. The mnemonics are only used for actions which are presented on the screen, under button labels for example. Not hidden keyboard shortcuts that would change on localisation (there are none anyway, we run in a web browser, so the only accelerators are those which are part of whichever browser is being used).
The problem with attempting to choose the mnemonics at design time is that the people responsible for developing the UI are not aware of the localisation, as it could be done months later. Also, the problem of using nested and modular forms means that even without the localisation, there could still be conflict.
Some of the ideas I've batted around include having a global mnemonic registry which forms could use to apply for a certain mnemonic based on it's localised label, the registry would then calculate which was the best use of available characters. Somehow it would have to maintain the state of that - such that the same form does not appear with different mnemonic sets over the course of the application use, it could possibly even be done statically and persisted.
Surely if I was looking to do something like that it would fit a more general algorithm - I just have no idea which one! :-)
I tried to do something similar on a past project, and abandoned it. It was too complicated to get done in any reasonable amount of time.
One of the challenges is that some languages don't have a single displayable "letter" that maps to a single key on the keyboard. Another challenge, in English, was that usability standards required the mnemonic letters to be consistent with those in similar buttons/menus in other apps. This can be difficult if you are dynamically choosing the letters.
I don't know if it could be called "best practice," but consider what Microsoft Internet Explorer does in Japanese. Note the familiar F, E, V, A, and D mnemonics on the menu and the toolbar. I imagine that it follows the same convention, where appropriate, for buttons on forms and such.
(source: sidenet.ddo.jp)
(I snagged that screenshot from a google image search. If it goes stale, you can find other pictures of jp-localized IE pretty easily.)
This is really a design problem, not an algorithmic problem. It turns out that most applications don't localize keyboard accelerators, including most Microsoft ones, although there are some exceptions in certain markets. Not every keyboard shortcut is a mnemonic; really, only a few of the most common ones are.
I should note that this election not to localize accelerators is a rather recent trend; prior to 2000 or so, it was still quite common to localize shortcuts in some products (examples being ctrl-F for "Fett" instead of "bold" in German and Swedish products). But the pendulum has swung in the opposite direction, perhaps as a consequence of MUI and similar features.
A few localization tools will help you on this; I saw this feature as a bullet point on a product I've never used called Visual Localize. I'm not sure how useful automatic assignment is, as it's a fairly hard problem to automatically decide which character is the best mnemonic representation anyway, without domain knowledge of a particular product.
Generally, it only makes sense to localize the underlined mnemonic characters on dialogs, and maybe in menus. Most localization service firms are familiar with this process, and some have tools to detect duplicates in any build-time resources before handing back the localized resource package. You might actually want to invest in locating or building a tool that can do this duplicate check at runtime, and run the tool as part of acceptance criteria.
For regular menu items or keyboard command sequences, it can be more confusing than helpful, unless you have a fully baked keyboard to command mapping customization feature.
The problem I see with doing this is at runtime, is what happens when you deploy a version which has new forms, and changes Close from alt-c to ctrl-c. Or when you have two actions on two different pages but they are both close, you want to make sure close is always alt-c. Even worse would be if the algorithim was based on something non-deterministic and could change over time without a deploy.
It just seems like you might spend more time trying to build an algorithim for something that should be decided upon at design time.