In the web app I am currently developing I have a form, and one of the fields is a boolean "IsFixedCost" (true/false).
The natural way, to me, to represent it on the form is with a checkbox: FixedCost? (checked = true, unchecked = false).
My boss forced me to change it in a combobox: FixedCost? -> option1: Fixed, option2: Variable
because he says that "it's more clear and understandable".
I find it totally senseless (because if it isn't fixed, it's variable, no other possibilities) and less usable (requires 2 clicks to change instead of one)
I'd like to hear opinions about this.
You should go for checkboxes, since a multiple choice combobox (I assume you mean select) is less accessible. In other words... Your boss is wrong. Radio buttons is to be avoided since they're not accessible.
Whilst you are correct, it isn't 100% obvious. Remember your application has to cater for the lowest common denominator (i.e. the stupidist person needs to be able to use it.)
Related
I find it intriguing and couldn't find any special reason as to why the cursor should not advance to the next form field when the field type is "drop-down selection" or "radio button". As in both cases logically there cannot be any additional input.
Is there any attribute which can be applied so that the cursor moves on to the next field.
Consider how many forms are filled daily worldwide and how much time being wasted if there is no special reason.
STOP! What you are trying to do will break keyboard users. In fact, any change you make will break somebody's workflow.
Auto-tab should not be used for any field, ever.
Who knows your field is going to auto tab? Nobody. Why? Because that's not what fields do on the web. So, I press tab out of habit to get to the next field, what did I do? Oh no, I've tabbed past the next field, thanks to an unexpected auto-tab. Now I'll just have to tab back.
I'm editing a field, there are enough characters in the field already, I want to overwrite some characters in the field, oh no! I'm being auto-tabbed out of it before I can finish!
I'm a keyboard user, I use the up and down arrows to change the value in a select or radio. These are triggering onchange events every time I press them, even though I haven't finished changing the value to the value I want.
When I want to tab to the next field, I'll jolly well press it myself thanks.
There is a very special reason not to autotab, and this doesn't really waste any time (unless you're developing something for somebody to use constantly for several hours at a time). The special reason is you're following the principle of least astonishment.
Start with attribute tabindex="-1"
JQuery style:
$('.something').each(function(){
this.tabIndex = -1;
});
Ok, I was asking for logic and it looks like I have found a reasonable answer to myself.
The cursor stays there and doesn't auto-tab to the next field as next field type may be a radio field or again a drop-down selection field, where auto-tab cannot take any action for example selecting an option from multiple radio options.
But I still feel that there should be an option of auto-tab depending on where it can be used or where it can be omitted.
Auto tab is an important and needed feature. Why, for example, should I have to press the tab key after entering in my area code before I can type in the next 3 numbers? From a user experience perspective, that's really annoying. I would think there would be an attribute built into HTML5 or CSS3 to accomplish this. I found this thread as I'm looking for it. If anyone has an update, please share.
I have a web application for tagging data and viewing data by tag, so my UI is a list of checkboxes for each tag, a list of checkboxes for each data item, a "Tag" button, which adds the checked tags to the checked data, and a "Filter" button, which ignores the checked data and just displays only the data items with the given tag.
My problem is that the former operation (tagging data) is "obviously" a POST operation, whereas the latter operation (viewing data according to a tag) is "obviously" a GET operation. But the method attribute is attached to the form, not the submit button, so I have to choose one or other for both buttons.
I don't want to make two forms, since as far as I can tell this would force me to duplicate the entire tag list. Is there any way I can choose my method based on the choice of submit button?
A JavaScript solution is permissible, but one without would be preferred.
(I am going to post an answer to this question, but I don't particularly like it, so I would welcome alternatives).
In principle, you could use the formmethod attribute in a submit button, as per HTML5. However, it is not recognized by IE, even in IE 9. The existence of the feature in HTML5 indirectly proves that previous versions of HTML lack a feature for this.
On the other hand, the POST method can be used even for simple viewing that does not cause any changes in the outside world, and in many situations it has to be used for technical reasons (e.g., too much data). So I think the method issue is not very relevant; just use POST.
I would honestly go with a javascript solution, in the onsubmit of the form fire a method which a) checks the submit button that was pressed and b) based on this changes the method of the form.
One possible solution would be to use POST, and then have the server give a 303 See Other header to change it into a GET request. This involves making two requests to serve the purpose of one, which is unfortunate, but at least means that the URL will change so people can link to a specific tag selection.
I agree with javascript solution, proposed by Jon Taylor, the problem is not if your form's method is GET or POST, but how do you filter/validate/sanitize user input. If your concern is related to the fact, that the user can manipulate the form's method, then you should implement solution to that matter on server side.
I have a jcombobox in my application.
and i want it to support multiple selection (like it do in a jlist).
is there any code example?
I think it's not possible, unless you use a JList, like you said.
The JComboBox API reports:
The user can select a value from the drop-down list, which appears at
the user's request.
And a JComboBox tutorial:
Lists are not terribly attractive, but they're more appropriate than
combo boxes when the number of items is large (say, over 20) or when
selecting multiple items might be valid.
Update:
I reviewed this answer, because actually it's "possible" to do that using a ListCellRenderer, adding a checkbox to each item. Please consider this answer to implement this "solution".
However, I don't think it's a good idea for the following reasons:
there's a control like a JList that allows multiple selection;
a JComboBox control is designed just for single item selection;
it doesn't make sense to me to still use a JComboBox control and allow a multiple selection.
It's not quite impossible but there's a lot of work to do to get the job done. You'll need to create your own classes to extend/implement all of these:
ListCellRenderer (so you can mark the selected items when the popup is showing and indicate (at least) that there are multiple selections when it is not).
JComboBox (obviously)
BasicComboBoxUI (this is actually where most of the work is)
BasicListUI (at least I had to)
ComboBoxModel
And you'll need to develop your own class that implements ItemListener, MouseListener, PopupMenuListener, MouseMotionListener, PropertyChangeListener, KeyListener, ListSelectionListener.
Hint: you'll need to override a lot of createXXXListener() methods in the UI classes in order to bypass the many places where multiple selections are discarded.
[And it still doesn't allow for an editable multi-selection combo.]
Assume I have a html from, and it contain some submit type. I want to create a "are you sure" popup window that will appear when user click submit button.
My question is that is there any way to create it by using "only" html, not using javascript or any other?
HTML only is possible, but not without a postback
Scenario that could work without javascript:
You have your form with submit button
User clicks (and submits) the form
You display another form with are you sure? form (that contains Yes and No buttons as well as hidden fields of the first form that will make it possible to do the action required on the original data
functionality that executes the action and goes back to whatever required.
This would be completely Javascript free, but it would require several postbacks.
This kind of thing is usually done on the client with a Javascript confirm() function (here's a simple example) or lately with a more user friendly modal dialog provided by many different client libraries or their plugins.
When to choose the script free version?
If you know your clients are going to be very basic ones (ie. vast majority of your users will access your application using clients like Opera Mini that's not able to run scripts at all). But in all other cases it's much better to do this using Javascript. It will be faster, easier to develop and much more user friendly. Not to mention that it will put less strain on your server as well since certain parts will execute on the client without the need of any server processing.
No, there isn't. Despite of the new features in HTML 5, HTML is still a markup language, not a programming language. In order to express dynamic behavior (such as an "are you sure?" box), you need to use a programming language.
Javascript would be the most obvious choice for this, but you could also do it with frameworks that can get you around writing Javascript by hand (for example ASP.NET).
Edit: Actually it appears that it would theoretically possible to do this with without Javascript or other frameworks. As I just learned, HTML 5 + CSS 3 seems to be turing complete. But this is hardly relevant to this question.
It's possible to ask for a confirmation, but it will not be in a "popup window". The creation of the "popup window" requires javascript/other language.
It will be:
Request (first form)
POST
Response (confirmation form)
POST
Response (outcome message)
You can create a form with all hidden elements containing the data from the first form and a "Yes" and "No" button below the "Are you sure?" text. You can use PHP sessions to avoid the hidden form elements. If there is a lot of data or confidential data or you do not want to re-validate the data from the second form, use sessions. Make sure you validate the data from either form before using it.
I know I'm like .. 10 years late. But for anyone still wondering I thought I could be of some help!
What I did for this exact problem was make sure I had multiple "divs" in my code. For me specifically, I had two main ones.
First, one whose id="main", and another whose id="popup" with the 'visible' property initially set to 'false' for the popup div.
Then, on whichever event you're looking for (button click for example) you'll simply set main.Visible = false and popup.Visible = true, then you could have more buttons in your popup (yes, no, cancel, confirm, etc.) which do the exact same thing, but in reverse!
The most important thing to make sure of is that you have the 'runat="server"' property in your divs so that you can access them in your CS code
Hope this was helpful! :)
I'm having an argument with a co-worker, and I'm trying to convince him that it's a bad idea to change checkbox text (label) according to the checkbox state.
For example, we have a combobox that automatically picks selected value (and is disabled) when checkbox next to it is checked and is enabled when checkbox is cleared. His idea is to show Autoselect when checkbox is checked and Manual select when it's cleared. I'm sure that this will confuse the user as users tend to think that checking a checkbox next to a verb will make it true, only to find that the label has changed to something else.
What is your opinion on this matter?
P.S. I remember reading about changing checkbox text somewhere, in a book or blog article, but can't remember where. It would be great to have this in writing :-)
No need to mess with something that already works.
Changing the label would be horribly confusing and counter-intuitive, especially in the way you describe.
If the label describes the current state ("Manual select"), it will not be clear whether it is necessary to click on the checkbox to achieve the described state (like with a button), or whether it already is in that state.
A checkbox is a simple thing. When it is off, it does A. When it's on, it doesn't do A. The label needs to reflect what it does when it's turned on; it is then perfectly clear what doesn't happen when it is turned off.
If you want to show that the choice is between "Auto select" and "Manual select" then you should either reword your checkbox label or have a radio button:
o Manual Select
* Auto Select
Which isn't really ideal either.
But you shouldn't be changing the text on the label - the user won't remember what it was before and will be confused when it changes.
Personnaly i would say that the label shouldn't change.
From my experience changing the text is confusing, I have the same issue with modal buttons that change their text. It is hard to tell whether pushing the button will turn on the selected state or the text is the selected state.
Tick box text should not change.
Changing the text when the checkbox is checked changes the meaning. If it's checked and the label says Autoselect, I expect the Autoselect option to be enabled. If you uncheck, it's clear that the Autoselect option is NOT enabled. If you change the text to be Manual select whenever the checkbox is cleared I would expect that checking the box would enable the Manual select option. It's way too confusing if the text keeps changing.
You're right, he's wrong.
Checkbox labels should not change. That's part of the way checkboxes work.
See Should “toggle buttons” show what they do or the system status? on UXExchange for an alterantive approach using toggle buttons instead of checkboxes.
The label definitely shouldn't change. It's not only confusing, but it's unnecessary and ugly.
The only way I can think to make it less confusing would be to have the label state in brackets the current state, i.e. "Manual(currently auto)[]".
But that's really just a testiment to how ugly it gets.
Don't mess with what people are used to. Especially when you consider that if you do this, one will always be shown WITH a checkmark, and the other WITHOUT. Really confusing.
In the name of compromise, you COULD use a button instead, which toggles the control back and forth, and changes its value with each click.
Current mode: [Manual]
Still kind of confusing though. As I said, don't mess with what people are used to. It's like if you put a scrollbar on the left of the screen. It'll just mess with peoples' heads.
I would not change the checkbox label... I would have it say "automatic." But, depending on what your controls are actually doing, I might modify the selection in the grayed-out combo-box to reflect that it is now under automatic control.
Then to make the logic go both ways, if while the checkbox was unchecked, the user selected the "automatic" value in the combo-box, the checkbox would then become checked.
Or in another scenario:
If, when the "automatic" checkbox is checked, the automatic logic actually chooses a default value that is in the combo-box, then change the selection in the combo-box to show what the automatic setting actually is. The combo would not be editable, but it could be used to provide information about the actual setting that is being engaged.