There are a great many assumptions people make about names (also: W3C: Personal names around the world.)
Thankfully the W3C have some excellent advice on field design for names, of which the simplest is to use two fields (but not for first/last):
What should we call you? (for example, when we send you mail?)
I've seen this occasionally in usability tests. When I ask it's usually because they have filled in many paper forms where there is a request to 'fill out in block capitals' or similar — so they think that is the default for all forms.
With solicitors I imagine there may be similar issues where court forms have to be filled out in specific formats.
Add a checkbox labelled 'Limit number of queries'.
And only make the input field active if this checkbox is checked.
Alternatively if you must use the infinity icon, keep it simple and place it to the right of the '+' button, in the same style.
This would also adhere to the perception of hierarchy.
i.e. the left button decreases the value, and the right ...
Auto capitalization is impossible. What algoritm would you use to auto capitalize when a lady enters "cléopatra diane de mérode" as her name?
You would probably end up with things like:
Cléopatra Diane De Mérode
Cléopatra diane De mérode
The only correct spelling however is "Cléopatra Diane de Mérode" (wikipedia).
As you can see, capitalization of names ...
Ironically, I could not get by myself what bgeigr meant, but almighty Google helped me out:
So this captcha is quite easy for computers to guess, yet may be hard for humans.
And bear in mind that Google is using an error model for common typos (letters replaced by those adjacent on the keyboard etc.) If you program your computer to only consider anagrams, ...
Option 3 with no intrusive validation.
1 sucks because it's out of the norm. Copy and paste may or may not work. Tabbing to the next field may or may not work. People are good at correcting mistakes and the limited fields mess up their muscle memory. For example I might type
When I meant
My fingers will nearly instantaneously correct that ...
Users enter information in upper case either intentionally, or unintentionally (e.g. they happen to have CAPSLOCK activated). Several other answers mention a variety of reasons for why the user may be doing so intentionally. If it is unintentional, then the user probably wants to know about it, and correct it.
As others have mentioned, designing an ...
Why would this be indecipherable to a computer? Since each word has the correct letters, but they are scrambled, it would seem very easy for me for a computer to crack the correct order of the letters by comparing it to known words. Which defeats the whole point of having this extra barrier.
Secondly, how would this affect folks with dyslexia or other ...
Another solution is the facebook-like "multi select bar". (I don't know the exact name)
You can find an example here. Basically it is like a text input field but the selected items turn into "tags". Just try it out on the page I have linked to.
There is no good way
Here's the design logic:
Backgrounds are perceived by users as backgrounds, i.e. inert and uninteractable. This is obvious.
In order to communicate to users that the background is tappable, you need to tell them that. The most reliable way of doing this is to sign it, i.e. Tap to continue.
Note that trying to do something fancy like ...
I have always known this as Auto Tab or (Auto tab input fields). As a matter of fact a search for Auto Tab gives me different ways of implementation of this element, including:
jQuery Autotab Demo
Cut & Paste Auto tab (form field) script
Auto Tab HTML Input Fields
And even Microsoft dev calls it that way.
This is not effective for keeping out a targeted attack by someone who uses a word list, such as /usr/share/dict/words, to solve your anagrams. A task like "unscramble the words in standard input, assuming the first and last letters are correct, given a word list file for the language" is probably so straightforward that it'd make a good puzzle for our Code ...
Here's a scenario where it might work to your advantage:
The user enters their full name in one field.
The system reverse concatenates the name as best it can.
The field shows the split apart name so the user can verify it.
If it's correct, no further action needed. If it's wrong, a little edit button lets them go to the complex form (two fields) and ...
Because this behavior is rare and therefore unexpected, it will surprise most novice users, which can cause them to misunderstand how to use the interface, and interfere with usability.
(An example of this interference might be if the user fills out the field and presses tab, while you have auto-advanced, and while they think they are typing in the next ...
I've taken the time to draw some wireframed examples that might help you decide on how to design your time-picker control. Below you can see 3 screenshots which show (IMAGE 1) a time-picker control for all units, an increment button, decrement button, numeric input field and unit picker dropdown (if needed.)
IMAGE 2: The idea is that you set it up so that ...
A good captcha would need (ideally) to offer the best possible protection (difficult to get for a computer) and ease of use (easy to get for a human).
But captchas aren't good at this and "typoCaptchas" doesn't seem to improve them. Questions can be rearrenged quite easily and then if the question is easy enough for people is probably easy enough for ...
What is the context of the question the user is answering, and what are the implications? This is the important question that helps guide the appropriateness of "Y" vs. "YES" (or "N" vs. "NO").
In this case you are dealing with a RSA certificate, which is a big deal. Accepting a certificate you don't mean to can have serious implications, so it is important ...
When a person dials an actual phone number with their phone, do they type 1-555-555-555 or do they type 15555555555?
The only reason for forcing a fixed format is because your back-end can't determine the format it needs. Which is an implementation problem and you're forcing the lack of technical nous onto the end user. That's like saying "we aren't capable ...
In theory the correct answer is no upper limit for name lengths. Allow the user to enter whatever their name is using whatever characters are available to them so that you will never run into a circumstance where someone is prevented from entering their valid real name.
In practice that is not possible to implement.
There have to be limitations.
I would suggest no.
Treat a person's name - in terms of capitalization, spelling,
punctuation and spacing - exactly as the person does. 
There are a variety of cultures with names that does not use capitalization in all parts of their names.
It's true that most traditional English, American, north/central European names are written with ...
Will Company Name be stored in the database with spaces and then a separate URL column will have no spaces?
I would recommend building the URL just below the Company Name as they type so when the user types "Super Duper Acme Co." your app will show:
Your dedicated URL will be: www.superduperacmeco.com
This will cause the user to pay attention and ...
Indicating the caps lock is on is a design pattern used for passwords. When the passwords are hidden and every character is only represented by a dot, users might not know they're typing capitals where they shouldn't.
It's easy to overlook the fact your caps lock is on. For example, I'm used to typing with ten fingers. While typing my elbows are set quite ...
Checkboxes vs. Radio Buttons - Nielsen Norman 2004
Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
Checkboxes are used ...
Simply put: DO NOT USE TABS.
This is not what tabs are meant for, so just use the box you have. Once the user selects the type, show the fields you have in second tab, only that right below the select field you have in first box. Basically: use only one box and get rid of tabs , then the "abstract type" will render no use at all, ergo problem solved, type ...
You say the keyboard is for hexadecimal input. And that's the reason why your second try doesn't feel right! As @steveverrill also noticed in the comments, the numeric order ABCDEF1234567890 is wrong. So if you want to go with a 4x4 layout, you should choose one of these:
download bmml source – Wireframes created with Balsamiq Mockups
This is a tricky interaction, mostly because it has to be super intuitive since the end users are not computer savy. I know it because I´ve had to deal with it in the past :)
I had the same problem while working in the UX team at 11870.com (a recomendations website similar to Yelp), this is the way we handled it, might not be the ideal solution but it ...
What's the issue with giving the user a predefined region of space with some sort of indicator that that space is where they should tap to continue - a button with an appropriate continue icon (the right-ward arrow is popular), for instance?
From a UX perspective, you're removing a level of complexity by removing an unnecessary choice, namely where on the ...
I think it can better to make a visual support for such input, that will allow to enter not only breaks, but also days off. Input can look like this:
Clicking on row or cell header (with hour or day) should turn on/off all days or hours. Also you can add popular variants at top of table to select them faster — «24x7», «All days without weekends» etc.