Skip to end of metadata
Go to start of metadata

Generic input field standards

Sizes

Input fields should be sized appropriately to the location they are in. There is not single rule regarding sizing. Small spaces will have input fields go edge-to-edge, large spaces will have them sized appropriately for the space. It's up to the designer to figure out which pattern suits the best given the circumstances around that particular input.

Character limit

On the generic side, all input fields should have at least maxlength set to some reasonably big number, but it should be set. 1024 seems to be a good number, and if needed we could bump it up to 2048. This is to always prevent various malicious usages of inputs where bots could paste large quantities of text.

Sanitisation

All of the input fields should be checked for code-like characters, in order to prevent various Javascript injections and similar malicious attacks.

Error handling

Refer to chapter Inline Validation for details on how to handle errors during text entry.

Frontend and backend pairing

All of the text entered in the fields will be checked at the frontend via various small mechanisms, however, once that text has been sent to backend, the backend has to perform an additional check of the sent text before it gets locked in. It's not that the backend doesn't trust the frontend, it's just that it's simply better to verify it once again. As that old saying goes: "Trust, but verify".

Specific input field standards

Character limit for certain cases

Driven by where the text inputted in some filed will later be shown, it makes sense to lower character limit on occasion. For example, Requirements Gathering tool shows Projects as tiles, and the name of that Project is a single line where we can reasonably fit around 50 characters of text. Therefore, limiting the input field where this name is entered to 50 character makes sense, as the place which consumes that input can only show about that many characters. 

Allowance of special characters

Due to security reasons, some input fields might include Regular Expressions to exclude some special characters from being entered. This will have to be defined for each particular case, as some inputs are more sensitive than the others.

Character countdown marker

At the moment we are not showing any character countdown as the users are approaching limit of character input. At some point in the future we should consider this.


Labels

Capitalisation

Labels should be Sentence cased, with first character being upper case. Of course, in the label we could have some brand names, or some words which require capital first letter, and we should obey those.

Direct language

The labels should simply communicate what is underneath them, and not tell to the users what should they do. For example, we should not have a label "Please enter password", rather it should just be "Password". The simple fact this label is above an input field is enough to communicate password should be entered into it. In general, there shouldn't be words like "Select", "Enter", "Pick" and similar in labels. Users know that they can select an option from a dropdown, enter something into an input field, or pick an option from an array of presented options. We should just label a particular input element, or a block, with it's function. 

Punctuation

Labels should not have any punctuation. Labels should not ask questions as to require a question mark, or be excited as to require an exclamation mark.



  • No labels