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.
Related
We've got a checkbox on a form that we'd like to be able to check/uncheck even whilst the form is opened as read-only (it's a sales/product form and when an order has been invoiced, we want to prevent changes).
I know I could add a command button in its place and even make that button look like it's a checkbox with some images, or even set up a key combination to be used instead of the checkbox, but first I'd like to know if it's possible to simply exclude one checkbox from being read-only on a read-only form.
No. You must go the other way around:
Make the form read-write, then disable all controls bound to data fields except this single checkbox.
I want to "prevent browsers from prefilling form inputs when hitting the "back" button". Indeed, I want the initial values to be filled in (added via jsp), not the browser's (cached) values.
Solution 1: I found out that this can be done by disabling the browser caching for the current page. This seems a rather extreme solution considering that I "only" want to disable this prefill feature for a "form" (hence disable caching for the form only, not the whole page).
Solution 2: Then, the obvious next solution is to use javascript: that is, store the initial value in a data-* attribute, then, on page load, replace the input value by the initial value if they differ.
Both solutions seem rather unperfect (these are rather work arounds) I turn to you guys hoping to hear of a better one.
Resources:
How does SO's form remember previous input values?
Disable Firefox's Auto-fill
Pressing back prefills inputs with value from right before submit
HTML form values and 'Back' button
The first thing that comes to my mind is to use a <input type="reset"> button. These aren't seen often nowadays because the user rarely actually wants to reset the form, but here it might just be what you need.
You could also do it in javascript on page load with form.reset(); instead of providing a button for the user.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement.reset
This is similar to your solution 2 and thus still a workaround of the browser behavior, but it is a(n old) part of standard forms and I think it'll do the trick with very little additional code (no need for data-* attributes), so wanted to throw it out there.
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 think I'm looking directly at an Access 2003 bug. Here's what I did (I think):
I'm developing a Continuous Form (i.e. multiple records per page).
I have an unbound textbox in the background of the Details section. Under Data Properties, I have Enabled=No and Locked=Yes. (In other words, I don't want the user to select it. I only want it for the background color)
This textbox also has some conditional formatting to change the background color for that row. (e.g. If we haven't spoken to that customer in awhile, the background for that record is red)
If I choose a record where the conditional formatting is active (i.e. the background is red), I can actually click on this textbox. There's not much that I can do, of course, but this shouldn't happen and surely would be confusing to the end-users.
Has anyone else seen this? What's your workaround?
Enabled is a property that can be controlled via conditional formatting. By default when you add a new condition, the Enabled property is set to True. If you don't want your control to be enabled you must explicitly set Enabled = False within the conditional formatting rule.
The property is toggled via a button in the lower right corner of the conditional formatting dialog. It's easy to miss (I forget about it all the time).
Personally, I think the property should be three-way: True, False, or Inherit (with Inherit as the default). Unfortunately, Access forces you to be explicit when adding conditional formatting rules and state whether the rule should make the control Enabled or Disabled.
Here's my workaround (I was waiting to see if anyone else would suggest something better. Apparently not.)
In my conditionally formatted textbox, add an Event Procedure for GotFocus. Enter this code: Me.Txt_FocusHere.SetFocus.
Make a 2nd unbound text box somewhere on the form. Shrink it until it's just 1 line thick. Call it Txt_FocusHere.
So whenever the user clicks on the colored background, the focus is immediately taken to this dummy textbox which can't store any data and is so small that the user doesn't see the blinking cursor.
I successfully used the method on the following page: http://www.mvps.org/access/forms/frm0047.htm - "Changing the Background Color of the Current Record in a Continuous Form"
I have an html form with a checked checkbox:
<input type=checkbox name="somebox" value="somevalue" checked />
When I get this form, uncheck the checkbox and post the form again, the checkbox is still being passed on together with submitted data. So, unchecking in does nothing finally.
Is there a way to uncheck it? Or may be there is another way to indicate that the checkbox is checked (without using "checked" keyword)?
Thanks in advance
UDP
Finally it was a bug in another place. Checkbox logics is all right. Thanks everyone.
If you have unchecked the checkbox, the "somebox" will not be passed a request parameter.
You must have made a mistake somewhere else.
You could use javascript or jQuery to uncheck it but that's hardley solving the problem.
Sounds like your fighting with viewstate and you'll either need to place this in an update panel, or out side the panel depending on needs, or in your code behind set the checked value of the control before you come back to the page.
get rid of the "checked" property in the control might also be a good start as everytime it comes back from a post it will try to check the box. instead, set it's checked state in the code behind.
If its not checked the name may be passed (often libraries do this when building a request) but the value will not, so if the value of somebox is not somevalue, its not checked.
See How come checkbox state is not always passed along to PHP script?