{"id":52280,"date":"2015-10-05T08:20:18","date_gmt":"2015-10-05T06:20:18","guid":{"rendered":"https:\/\/www.humanlevel.com\/sin-categorizar\/mejorar-la-usabilidad-de-formularios-en-movil.html"},"modified":"2021-03-01T11:20:00","modified_gmt":"2021-03-01T10:20:00","slug":"how-to-improve-the-usability-of-mobile-forms","status":"publish","type":"post","link":"https:\/\/www.humanlevel.com\/en\/blog\/seo\/how-to-improve-the-usability-of-mobile-forms","title":{"rendered":"How to improve the usability of mobile forms"},"content":{"rendered":"

Improved usability<\/a> in forms<\/strong> is synonymous with improved conversion<\/strong>, since by reducing the difficulty of purchasing or submitting contact data<\/strong>, the number of users who manage to complete these tasks increases. On mobile devices, this is much more difficult, and therefore we must take some additional considerations into account.<\/p>\n

The subject of usability is very broad<\/strong> and has many books written on it. Making it easy and intuitive<\/strong> for the user to use our web application is complicated, even more so when they have to fill in data on a small screen at the touch of a finger. As general recommendations, we have to make sure that users have to perform as few actions<\/strong> as possible and make them think as little as<\/strong> possible, otherwise they will end up frustrated and give up trying.<\/p>\n

In the following, I will focus on the technologies and patterns that I consider indispensable when it comes to improving usability on mobile and tablets<\/strong>, but most of them are also applicable to desktop web applications.<\/p>\n

HTML5 field types<\/h2>\n

Before the arrival of HTML5, if we wanted to enter a phone number, a zip code, a date or email, we used text fields<\/strong> as follows:
\n
\n<input type=\"text\" id=\"cp\" name=\"cp\" \/>
\n<\/code>
\nWe can now use the following specialized types<\/strong>:
\nTelephone: type=”tel”
\nNumber: type=”number”
\nURL: type=”url”
\nEmail: type=”email”
\nDate: type=”date”<\/p>\n

If the browser does not recognize any of these field types, it will assume that it is of the text type. The complete list can be found here<\/a>.<\/p>\n

The advantage of these types of data is that a different keyboard will appear on the cell phone<\/strong> for each of them. That is, a numeric keypad for the telephone, a keypad with the at symbol for email or the “.com” button for the URL type. This will make it easier for the user to fill in the data.<\/p>\n

When using them we have to be careful with desktop behavior<\/strong>for example, if we set a zip code as type “number”, in desktop we will have buttons to increase\"spinnerdecrease and decrease<\/strong> the value in a unit, being something that in this case does not make much sense, so we can detect what type of device we are in and if it is on desktop use the text type and if it is mobile use the “number” type. Example:<\/p>\n

\"numeric<\/p>\n

Another case where we have to watch whether we obtain the desired behavior is the date type<\/strong>. To implement such a field, we have always used calendars generated using desktop UI<\/a> libraries<\/strong> in JavaScript<\/strong>, which always show the same calendar<\/strong> adapted to the application layout, but these calendars are not suitable for mobile<\/strong> because they are too small.<\/p>\n

If we use a field of type date<\/strong>, in mobile, we will have calendars with a different interface<\/strong> depending on the device, but much more usable<\/strong>:<\/p>\n

\"date
\nLikewise, with the date type, on desktop we will have a different calendar depending on the browser, without the corporate colors. So, if we want<\/strong> or if the browser does not support the date type, on desktop we can discard the use of this data type<\/strong> and continue using the JavaScript library.
\nAnother option is to use JavaScript user interface libraries for mobile, with which we have calendars similar to those shown on the device. In the case of mobile, it is always better to use HTML5 data types instead of libraries, even if we cannot use corporate colors, because this way we do not have to resort to additional code that slows down loading and consumes battery power<\/strong>. With the advantage that the user will see a control to enter dates that he will have already seen on other websites and will be more accustomed to.<\/p>\n

Auto refill<\/h2>\n

\"autofill\"Autofill<\/strong> is a new5 feature that allows you to automatically fill in all the fields of any form, with the data captured and stored in the browser, from other forms that we have previously filled in. If we wish, we also have the option of entering our data manually in the browser.
\nThis functionality is active by default in the latest versions of Google Chrome and Firefox<\/strong> for both mobile and desktop, in Internet Explorer and Safari we can activate it.<\/p>\n

When autofill is active, the browser displays a drop-down list when you start typing in the first field and selecting an option will fill in the rest of the fields with the associated data.<\/p>\n

The autofill tries to guess what data corresponds to each field<\/strong> by the names they have in the code, but we can indicate in the html exactly which field it<\/strong> is by adding the attribute autocomplete=”field name”. For example, to autocomplete with the credit card number we would have a field like the following, where we indicate that the field should autocomplete with the value stored for “organization”.
\n<input type=”text” id=”company” name=”company” autocomplete=”organization” \/>
\nThe complete list of values that the autocomplete property can take can be found in the WHATHWG specification<\/a>.<\/p>\n

Labels with associated fields<\/h2>\n

Form labels<\/strong> must always be associated to the field they refer to<\/strong> by means of the “for” attribute of the “label” tag, so that the user can always click on the label to go to the field. In checkboxes, especially on mobile, this is especially important, as it will be much easier to click on the label than on the checkbox itself. Examples:
\n

Passwords without asterisks<\/h2>\n

Password fields have always been used for passwords, which are of the type “password”. show asterisks instead of the password<\/strong> to protect us from prying eyes, however, we have on the mobile this does not make as much sense<\/strong>because they are more personal devices and it is easier to make mistakes when writing, that is why it is usually included a checkbox that changes the field type to “text” so that we can see what we are entering<\/strong>. It is also a good option not to hide the password after a failed login attempt.<\/p>\n

Fields for self-growing comments<\/h2>\n

The multi-line text fields<\/strong> that are used to enter comments show scroll bars<\/strong> when we go over the preset size, these bars are quite uncomfortable on a small screen, but there are many JavaScript libraries to make “autogrow<\/strong>“in the “textarea” of the form that the field grows as more lines are required<\/strong>.<\/p>\n

Autocomplete<\/h2>\n

When the list of values that can be typed by the user is very long, a list of possible values for the first letters entered<\/strong> is usually displayed via AJAX<\/a>. In these cases, when the user selects the field, we must place the scroll so that the field is at the top of<\/strong> the page. If this is not done, there may not be enough space<\/strong> to see the drop-down list due to the space occupied by the keyboard on the screen.<\/p>\n

Some more tips<\/h2>\n