HTML form input length guidelines (e.g. username, email address)

Are there any guidelines / recommendations for how long to enter input fields in HTML forms. In particular:

  • View length (the length of the input field that the user can see on the screen - without scrolling horizontally, i.e. SIZE, not MAXLENGTH )
  • Capture length (the number of characters that the HTML form will store in the database)

The length of the visible image may be short (20 characters), but does that deprive users of somewhat longer email addresses?

The capture length can be set to 200 characters for all fields, but is that good practice? Were there any downsides to doing this?

The common fields I'm thinking of are:

  • Name
  • Username
  • Password
  • E-mail address
  • User's website address
  • OpenID address
  • Location (for example, city and country).

Fields with known possible values ​​(eg age, phone number, country, manufacturer) can be pre-estimated, so not a problem.

+1


a source to share


6 answers


You can keep them the same, or slightly less than the length of the database fields, assuming they will eventually be saved.



+1


a source


Whichever answer you accept, consider the type of crowd you serve. For example, programming crowd emails might be something like this:

Techboy@example.com

,

while a bunch of basket weavers could be something like:

the-super-incredible-basket-weaver1258@bestbasketweaversintheworld.com.



I will need to modify my answer because you have done editing without scrolling horizontally. that is, SIZE and not MAXLENGTH , so I believe the answer still matters, for fear of the following scenario:

alt text http://img190.imageshack.us/img190/5632/techboy.png

against

alt text http://img199.imageshack.us/img199/6746/weavers.png

+1


a source


There should be no difference in view / capture length. At least I've never heard of this approach, which seems very strange to me.

Names in some cultures can be very different, several hundred characters are very easy.

Username can be within 30 characters, this is the Google limit.

Passwords must be hashed and never stored directly, hashes are 40 characters long.

Letters can contain up to 260 characters. If you allow for the possibility of non-Latin characters, substitutes for such characters will continue to expand this length.

Phone number and postal codes are far from predictable, length and format vary greatly from country to country.

My suggestion for you is to use unlimited fields in the database. If you are using SQL Server use nvarchar (max). You can put restrictions into your code, but be prepared to expand them when a user complains to you that they cannot enter their information correctly due to your restrictions.

0


a source


I try to make them very long - 200+ characters. Making the values ​​more readable when displayed on the site is secondary to actually stop people from posting their own email address.

Given that your underlying database is most likely of a type that allows strings up to a certain length, but doesn't penalize you by storing 200 characters if you only store 10, I don't see any third party references to this approach.

I'm talking specifically about areas like email, name, address, website url, but not things like username and password that you need to have a reasonable limit as your application needs to work with them. IE, if you ask the user to enter data belonging to them, you should never print the following confirmation message:

"Sorry, your name / email address / thing - we need too long from you, you cannot enter it."

0


a source


I actually found this question while looking for an answer myself ... after reading the first installment, I have a few suggestions:

  • If you are creating data for your application, the length of the data field must match the size of the visible one; especially for things like user id. This is what you control.

  • Password fields should have as high an upper limit as possible that you are willing to accommodate. Since the password itself does not have to be stored (store the hash), a field in the form can represent something like 1.5x - 2.0x the minimum length allowed (after all, it will still be closed *****) ./ p>

  • The hard part is information about the peoples. If most of your user base comes from one jurisdiction than you can optimize for that case, and you might have a "different" option for people elsewhere, or just allow an empty field depending on your implementation.

Bottom line: keep the fields as short as possible, but still let most target audiences fill out the form; and reduce complexity by not collecting any information that you do not absolutely require.

0


a source


If you have some existing data, you can do the following to find the lengths:

SELECT
    column       AS 'field contents',
    LEN(column)  AS 'length',
    CUME_DIST() OVER (ORDER BY LEN(column))  -- Fraction with length less than this value length
FROM table

      

(Tested in SQL Server 2012 and also work with oracle )

0


a source







All Articles