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)
Related
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
I am trying to disable and hide a checkbox. So the total amount of HTML is small; I can't imagine performance could be an issue.
As far as writing server code goes, the coding work is about the same.
Given these two options, is one better practice than the other? Or does it not matter which I use at all?
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
No, these two options don’t have "exactly the same behavior".
If you hide an element with CSS (display:none), it will still be rendered for
user agents that don’t support CSS (e.g., text browsers), and
user agents that overwrite your CSS (e.g., user style sheets).
So if you don’t need it, don’t include it.
If, for whatever reason, you have to include the element, but it’s not relevant for your document/users (no matter in which presentation), then use the hidden attribute. By using this attribute, you give the information on the HTML level, hence CSS support is not needed/relevant.
You might want to use display:none in addition (this is what many CSS supporting user agents do anyway, but it’s useful for CSS-capable user agents that don’t support the hidden attribute).
You could also use the aria-hidden state in addition, which could be useful for user agents that support WAI-ARIA but not the hidden attribute.
I mean do you need that checkbox? If not then .hide() is just brushing things under the carpet. You are making your HTML cluttered as well as your CSS. However, if it needs to be there then sure, but if you can do without the checkbox then I would not have it in the HTML.
Keep it simple and readable.
The only positive thing I see in hiding it is in the case where you might want to add it back in later as a result of a button being clicked or something else activating it in the page. Otherwise it is just making your code needlessly longer.
For such a tiny scenario the result would be practically the same. But hiding the controls with CSS is IMO not something that you want to make a habit of.
It is always a good idea to make both the code and its output efficient to the point that is practical. So if it's easy for you to not include some controls in the output by adding a little condition everything can be managed tidily, try to do so. Of course this would not extend to the part of your code that receives input, because there you should always be ready to handle any arbitrary data (at least for a public app).
On the other hand, in some cases the code that produces the output is hard to modify; in particular, giving it the capability to determine what to do could involve doing damage in the form of following bad practices: perhaps add a global variable, or else modify/override several functions so that the condition can be transferred through. It's not unreasonable in that case to just add a little CSS in order to again, achieve the solution in a short and localized manner.
It's also interesting to note that in some cases the decision can turn out to be based on hard external factors. For example, a pretty basic mechanism of detecting spambots is to include a field that appears no different in HTML than the others but is made invisible with CSS. In this situation a spambot might fill in the invisible field and thus give itself away.
The confusion point here is this: Why would you ever use display: none instead of simply not render something?
To which the answer is: because you're doing it client side!
"display: none" is better practice when you're doing client side manipulations where the element might need to disappear or reappear without an additional trip to the server. In that case, it is still part of the logical structure of the page and easier to access and manipulate it than remove (and then store in memory in Javascript) and insert it.
However if you're using a server-side heavy framework and always have the liberty of not rendering it, yes, display:none is rather pointless.
Go with "display:none" if the client has to do the work, and manage its relation to the DOM
Go with not rendering it if every time the rendered/not rendered decision changes, the server is generating fresh (and fairly immutable) HTML each time.
I'm not a fan of adding markup to your HTML that cannot be seen and serves no purpose. You didn't provide a single benefit of doing that in your question and so the simple answer is: If you don't need a checkbox to be part of the page, then don't include it in your markup.
I suspect that a hidden checkbox will not add any noticeable time to the download or work by the server. So I agree it's not really a consideration. However, many pages do have extra content (comments, viewstate, etc.) and it can all add up. So anyone with the attitude that they will go ahead and add content that is not needed and never seen by the user, I would expect them to create pages that are noticeably slower overall.
Now, you haven't provided any information about why you might want to include markup that is not needed. Although you said nothing about client script, the one case where I might leave elements in a page that are hidden is when I'm writing client script to remove them. In this case, I may hide() it and leave in the markup. One reason for that is that I could easily show it again if needed.
That's my answer, but I think you'd get a much better answer if you described what considerations you had for including markup on the page that no one will see. Surely, it must offer some benefit that you haven't disclosed or you would have no reason to do it.
This is a question of how to perform the best practice of storing data from a webpage. Like texts/image-urls/links etc.
I have an CMS were you can create web pages. Here you can edit texts/upload images. In the future it would also be nice to "add new elements", add links to a-tags etc.
I need to have a robust and flexible solution that also have good performance. In both getting/recieving this data.
Lets consider I have 1000 pages with each around 25 elements on each page that can be updated and stored in the database.
Alternative 1)
Create a table and 1 column for each element on these pages for example columns like:
title_1, title_2,image_1,image_2.
Here we have a set of columns that we can update, these we can use on the web page.
Alternative 2)
Create 1 table with the columns (id, namespace, page_id, data)
And for each element on the page I add the namespace in association with the page_id to make the data output unique. In the data I can add any kind of information; text, links etc.
What do you suggest as a good solution for this issue? I'm ofcourse also open for other alternatives.
Thanks!
I would recommend option two, with the addition of a column identifying the element id/or type, if indeed the element id is somehow comparable. That is to say, if anchor text (say) is always stored as element id = 4, then you might want an element id = 4 so that you could compare anchor texts across multiple documents.
If, on the other hand (and this is the scenario I imagine is more likely), you may have 1-25 elements on a page and each of them could be different (eg document one has three anchor texts and four images, document two has one anchor text and no images, etc) it would make sense to add an element_type_id table that stores a bit of information about the element types. This is assuming that you ever have any interest in comparing (say) images across multiple documents, or anchor texts across multiple documents, etc.
Another thing to consider: if you are likely to see the same element over and over again, it actually makes more sense to effectively parameterize those elements by way of a lookup table. So basically store each (say) unique anchor text in one table and reference its id in your actual data table.
If I may add one additional thing: SO may not be the best place for the particular question you are asking. I'm not totally sure of that and maybe I'm wrong... but I would poke around the Stack Exchange network and see if other forums more closely deal with the type of question you asking. In the very least, I'd observe that your question is fairly vague and the goal of achieving a "robust and flexible solution that also {has} good performance. In both getting/recieving this data." is not likely to be accomplished simply by asking for advice on SO. There is a LOT that goes into data architecture, and certainly many of the details I would consider important in designing this myself are not present in your questions. And if you're not sure what those details are, I am not sure if SO is really the best place to set about learning them. I think https://softwareengineering.stackexchange.com/ may be a better fit for this question.
Just my opinion, and I could be wrong. Either way, I would consider learning a bit about database normal forms (http://www.bkent.net/Doc/simple5.htm or Google it) as well as do a little research on the types of design considerations that go into building a database (an old but still good SO article on that is here: What are the most important considerations when designing a database?)
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 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.