I have seen a lot of survey web-pages (among others) that uses checkboxes (multi-selection) as radios (one selection only). The reason they do so is that in their code they have a variable that decides how many selections in one question that can be made. If this is set to 1, it simply limits it to 1 selection instead of using the radio input. I can see the reason for this code-wise. But whenever I see a checkbox I immediately think that I can pick more than one option, however I can not.
Basically my question is:
Shouldn't you, when creating a survey where you use checkboxes to limit the maximum number of pickable options use radios when only one option is pickable?
Yes, you should. But that won't be enough characters to answer the question.
Related
Is there any way to make select, which allows multiple selections look like ordinary?
Like a drop-down, you know…
<select multiple="multiple"></select>
look like
<select></select>
http://jsfiddle.net/UKf5Y/3/
Well, no. If there were, how would the user use it to select multiple items?
The only way that a multiple selection works is because all of the items are displayed at the same time and they can click-and-drag or click while holding down a modifier key.
If it looked like a drop-down box, how would you navigate to a second item without deselecting the first?
The styling of a select list, as well as many different elements in HTML (notably the input[type='file'] element, is really dependent on the browser. If you're looking to make it visually more appealing / different, you'll really need to use some JavaScript and use an "interface" to your select. Some really nice JavaScript libraries for select lists are jQuery Multiselect, jQuery UI Multiselect and select2, maybe you should look at those.
It's worth noting however that only select2 supports the single/multiple variants, and the styles still do look different, but how else would you be able to see multiple selections at one time? You could design your own solution which did look identical, but I think more than anything this would be misleading.
I have a form in which a user can select multiple options in a select menu. From a user experience perspective, what do you think is the most intuitive / best option?
A) Use the "multiple" attribute for select element (then you can hold down control and select multiple options). ADV: Simple, no coding required. DIS: Not intuitive.
B) Have multiple checkboxes and a select all/select none control. ADV: Fairly simple. DIS: Will get cluttered when there are many options
C) Have two select multiple menus side-by-side and have buttons to add/remove options. The chosen options will be on the right and be submitted. ADV: Clean DIS: Will break if JS is not on.
Can anyone think of better options?
I vote for B.
Option A is the "vanilla" option, but I hate having to hold down Control and scroll through a long list. Inevitably something will slip and clear the whole list. I'm sure the folks with arthritis hate it too.
Option C is a common enough paradigm, but when you have more than a few options it gets a little difficult to keep track of, especially if the options have any order or relation to them. I prefer to have one list where I can relate all the options to their neighbors. It depends on your specific use case I suppose.
Option B is easy to code, can be used 95% without JS, and gives you complete flexibility in your layout. It's only as cluttered as you design it to be. This is the way I do multiple-selects and find it very easy to work with.
A) Good if you don't have a very long list. It will be very annoying to use if you have lots and lots of items. Bad because it is not searchable, unlike option B.
B) Good because this will not require the user to understand holding down control. Because of this, the user won't be able to accidentally clear their selection either, which is obviously a good thing. It will also display much more cleanly what options you have chosen. Good because you can group related options under a single headline or other graphical indication. This approach will work without JS, with the exception of a select all button, a select none button can be done using a input type="reset".
C) I think this can be good if the user is clearly adding to a list, instead of selecting options. But as you say, it will not function without JS. I would consider A and B instead of this. Also not searchable unless you provide a custom filter box (which again depends on JS)
I just wondered and wanted to gather together in one place all missing features of our beloved html form elements.
One example could be missing of horizontal scrollbar in a listbox. But I am sure there are a lot of features we would like to see in our form elements by default.
One missing feature per answer please.
Thank you.
Date/Time picker controls, rather than always trying to manipulate a textbox, selects, or some other controls to create them.
Hell, they miss so many features, I wouldn't know where to begin! But here goes:
(Missing in HTML 4, don't know about 5)
Full visual customizability (background colours, borders, and text colours) for all elements (including checkboxes, radio buttons, and select elements)
Native input validation (without needing JS) for text inputs: Numeric only, alphabetic characters only, regular expression
An open enumeration, a "SELECT you can type in" would be handy in some situations.
If pretty much everyone, but not quite, answers the question in one of ten or 15 different ways, you have to either force everyone to type in the answer or have an "other" option with a separate text field.
The lack of intrinsic support for multiple windows (or even just modal dialogs) is ridiculous.
Think of the tens of thousands of programmer-hours wasted on acrobatic manipulation of div elements just to implement a UI that would be trivially easy in a desktop app.
It's somewhat pointless to list what is missing in HTML 4 since so much has been fixed in HTML 5. And then, most of us can't list what is missing from HTML 5 because we are not familiar enough with it yet.
My application has a requirement such that I have to display a huge number of HTML input textfields (maybe 2,000 text fields). The fields can be logically grouped into sections and the sections are repetitive. What is the best way to display it to the user so that they can enter data with minimum clicks?
I'm not sure what kind of users you have that would willingly sit through 2,000 text fields, but if it's a requirement, then you do what you have to. :)
You say it can be grouped into sections and the sections are repetitive. I'm not sure what parts are repetitive, but managing the sections carefully seems of utmost importance. Some sort of Javascript hiding/showing seems likely to be a big help... I think I would choose JQuery's Accordion effect or something similar.
You could add Tab key events to each section in order to assist with navigation and open a new section once an old one was complete. Adding change events to the fields might assist with that as well.
If you need to break the form up across multiple pages, then you'll probably want to utilize AJAX to load new sections/pages and store the submitted data into a session until the user is done.
Depending on the format of the required answer, there are two ways:
If the answer is of a known length or the answer is one of a few choices, you may auto-advance the cursor w/some javascript/jquery. For instance, if you're expecting phone numbers, when the person enters the 10th digit in the box, move the cursor to the next box.
If you don't know and you can't apply (1), the quickest way is to encourage users to tab their way through the boxes.
Speaking of tabs, if the boxes can be logically grouped, you could create tabs and have the users page their way through the questions. This will create more clicks, but will improve user experience.
But holy crap, 2k text boxes on one page is crazy!
I work on a similar product, and perhaps the number one thing would be to make sure that tabbing between fields works logically and quickly. The people who do data entry on this type of thing are lightning fast and fairly mindless (I don't mean that in a pejorative sense), typing in numbers from a log or printout without looking at a screen.
Apart from that, we implement tabs (like tabbed browsing) on the page, group boxes, and other things like "dynamic lists" which is like a data grid of text boxes that the user can add and delete rows from client-side.
Paged format, like a survey? You could then use SESSION to store the input for each page and retrieve the prior answers when the user switch between them. Another method is to use ajax to navigate between different . I think the issue is not the number of clips, but 2000 textfields is going to look scary on just one single page.
I've got a bit of a usability issue that I'd value some input on.
The initial page to my site contains two groups of controls, one for users to login, the other for new users to activate.
The issue is with the latter. When users signup for the service, they recieve an activation code that's in the form XXXX-XXXX-XXXX-XXXX. At the moment they have to enter this into four separate textfields. Whilst I've added some javascript to this to automatically move them back and forwards between textfields as if it were a single control (which works pretty well) the issue is that it lacks a way for the user to paste their data into it and as such is a bit of a pain.
Now this is not a huge issue, but it potentially means that peoples very first experience with my site is a slightly frustrating one, having to hop backwards and forwards between the email containing their activation code and my page. That's obviously not optimal.
At this point you're probably thinking that the glaringly obvious answer would be to make the activation code entry into one single textfield. And you would be right, but I lose one very important thing if I do this: I lose the key visual differentiator between one form and the other, which automatically tells the user which is the form they need to use without reading anything or having to analyse anthing. As it is at the moment, effectively there are two different shaped holes on the page and the users data will obviously only fit one of them so, to an extent, it's a no-brainer which form is relevant to them.
So, does anyone have any good solutions to this? The single restriction is that I need to keep all controls on one single page.
Thanks in advance for any help.
Edit:
Thanks for all the input so far, every bit of which has been valuable. I'm currently thinking that the best solution is not one single thing, but actually an amalgamation of different approaches to make the whole thing more usable.
On that basis, here's what I'm going to do, based on all your suggestions:
In the purchase email, setup the link
to the initial page such that it
contains the activation code in the
querystring. Setup the initial page
to check this and forward them
straight on. This probably means that
the vast majority of users won't even
see the initial page, but there will
still be cases whereby people receive
their codes by other means and will
have to input them directly
Convert the four textfields to a
single textfield with
"XXXX-XXXX-XXXX-XXXX" as an inline
label.
Setup the login controls to forward
on any user that mistakenly enters
their activation code here without just dumping them to an error screen.
And I don't know why I didn't include it in the first place, but here's the URL for anyone that wants to take a look at the current implementation (you'll have to excuse the fact that it's in Italian, but it should be fairly straightforward what's what).
Have given the answer to bryan which contains most of what I'm going to use. If I had the necessary reputation I'd vote up all your answers as they've all helped. Thanks again.
A few easy options:
You can keep them the same physical page, just alter the querystring when you send the activation code. Hide one set of controls if the querystring is available. If you have to display both sections, then grey out one section based on the querystring information.
Change the control to have one textfield, but include "XXXX-XXXX-XXXX-XXXX" as the default text in the New User Activation. If the user clicks on the textbox, remove the text so they don't include the prompting text with their activation code. People will see the default text and gravitate towards it if they're expecting that pattern. People logging in will see the default text and block it out.
You could write an onpaste function in JavaScript which chops up the pasted string in to 4character blocks and them writes them to the appropriate textbox's via the dom.
Sounds to me you’ve a problem of users confusing two text boxes but then you’re making it worse by dividing one text box into four. For example, auto-tabbing through fields is bad usability -see comments and answers to “Moving a focus when the input text field reaches a max length.”
Assuming this isn’t a hypothetical problem and you’ve actually observed people use the wrong field, you need to find another solution for users confusing the fields:
Use terse field labels. Label the field “Activation Code” not “Enter your sixteen character dash-delimited activation code from the email we sent you when you signed up.” Text necessary for explaining where to get the activation code should be after the text box.
Use cueing text or graphic design on the outside of the text box to indicate it has four substrings. For example, put “XXXX-XXXX-XXXX-XXXX” under the text box.
Remove all extraneous elements from the page –the more graphic and text distractions on the page, the less the differences between the two text boxes will be noticed.
Make it so it doesn’t matter which text box the users use. If the string entered in the Username text box doesn’t match any username, then see if it matches any activation code, and vice versa.
Eliminate the activation code text box. Instead, when you send the activation request, include a sign-up URL that includes the activation code as a parameter (more details in answer by bryanjonker).
Sorry, this should probably be a comment, not an answer, but it wouldn’t fit.