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.
Related
I am not really experienced with coding so I apologize in advance if this is a stupid question with an obvious answer...
I use a google sheet to keep track of things at work, and my employees use it multiple times a day. They will either type one of three phrases into a certain cell on a row, so I have created buttons using the drawing feature that they can simply click, which will insert the appropriate text into the highlighted cell.
Once this text is inserted into the cell, I would like to add something to the end of the function that automatically selects the next adjacent cell in the row (to the right) so they can continue typing in. Currently, once they click the button to insert text into one cell (e.g., B23) they have to use the mouse to manually select C23 before typing into that cell. For some reason you cannot use the right arrow key or tab key on the keyboard to move over, so I am wondering if there is a way to add the selecting process into the script (or even a workaround for allowing the tab or right arrow keys to work).
I realize this may seem like a tedious question and folks may think it is awfully lazy of me to ask for a more efficient way to move over to a cell than using the mouse, but my employees use the sheet hundreds of times a day, so I'd really like to maximize the efficiency for them to make it as easy and convenient as possible. Inputting data can be tedious enough, so I am trying to simplify things and make it as least painful as possible :)
Thanks so much!
There are several ways to select the cell at the right. One way is to use offset(rowOffset,columnOffset):
range.offset(0,1)
You are correct. When using a button the focus stays in the button when it is clicked. After some trial and error, I think I found a way that will work fot you. I created a html sidebar that is opened from a custom menu. Once opened, you can leave it opened, HTML allows control over the focus using 'google.script.host.editor.focus()'. Then you can type in the cell. Attached is my sample spreadsheet you can copy and try. Let me know if you need any help changing the button names or text. Sorry my first try didn't work correctly. https://docs.google.com/spreadsheets/d/1KlNSJnZDNIb2chUK3SlKJg79VNIrsAbIbUvHyLwTLWk/edit?usp=sharing
Pretty new to windows phone development...
I'm trying to create an input view that contains a number pad for inputting a sales amount. I know that if you were inputting a number into a text box, you can set the input scope to numeric and then when you click in the text box, a number pad will come up but that's not what I'm trying to do.
I quite literally want the lower half of this screen to be just a number pad that is always up. There is no text box. Rather, as the user is punching in numbers, it'll be displayed in a textblock (a lot like you'd see in a calculator app). I'm not seeing a control for this and google just keeps bringing me back posts about InputScope. I was even thinking of maybe a hack-around where there's an invisible textbox that always has focus, causing the numberpad to always be up, but I don't even know how to cause that behavior either.
Is there a control or technique for this or am I going to have to roll a new user control? Can anyone point me in the right direction?
I would recommend creating your own custom control. That would be the best solution for your condition. There is no inbuilt solution for this situation. I was stuck in the same condition and created a new control with a custom keyboard and a textblock.
And for the hack you mentioned. You can register the LostFocus event of the textbox control and focus the control again using Focus() method of Textbox everytime is loses focus.
There are tons of things wrong with this page, but I'm looking for some ideas about how (if it's possible) to combine two controls on the page before I go any further.
The page presents a stream of real-time stock-market data. The page is at:
http://www.sellmycalls.com/cgi-bin/chain
(works on the PC under ff 3.6.13, safari 5.0.3, chrome 9.0.597; fails in IE 6, untested in IE 7,8,9)
The two controls I'm asking about are at the top: one on the "refresh" button; and the other on the adjacent combo box.
The user can refresh the data manually any time by pressing that "refresh" button. And the user can set up auto-refresh by selecting an interval from the combo box.
The separate button and combo box take a lot of room, though. And the two separate but related controls seem kind of clunky to me.
Is there some nice, obvious, intuitive, satisfying way I can combine the two while at the same time allowing the user to:
use the single combined control to do a manual refresh any old time, over-riding auto-refresh;
use the single combined control to set up auto-refresh;
see from the single combined control whether or not auto-refresh is in effect; and
quickly and easily suspend auto-refresh, thus freezing the display.
Any ideas very welcome and attribution will be given, natch.
Thanks so much!
-- pete
Maybe not the most intuitive solution, but perhaps a combobox with the top item being labeled as Refresh, and if that is selected, it does a manual refresh.
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.)
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.