Статті
20+ правил для полів введення тексту: детальний розбір
Як спроєктувати заповнення даних або реєстрацію на сайті
17 липень, 2019

Поля введення тексту на сайті або в додатку мають підказувати, яку інформацію вводити, помітно повідомляти про помилку та зменшувати когнітивне навантаження на користувача. Але буває і навпаки – як заповнювати порожні рядки і навіщо зрозуміло не завжди. Щоб уникнути таких ситуацій, продуктова дизайнерка Вікторія Доброденчук зібрала правила створення текстових полів, які підходять для всіх платформ.

Читайте також: Проєктування checkout форми

Цей матеріал – корисний результат дослідження. Використовуйте його як шпаргалку, але обов’язково перевіряйте інформацію перед застосуванням. Дизайн текстових полів взято з попередньої версії Material Design. З новою версією можна ознайомитись тут.

Логіка полів введення:

Текстове поле може бути представлено в 4 станах:

  • Пусте поле;
  • Заповнене поле;
  • Активне поле, куди користувач вводить інформацію, поле, на якому зараз фокус;
  • Поле з помилкою, яке може бути як активним, так і ні.

Коли користувач заходить на сторінки з декількома порожніми текстовими полями, наприклад, для введення адреси, бажано робити перше поле одразу активним і відкривати клавіатуру, якщо це додаток. При успішному заповненні поля і переході на наступне, воно стає заповненим.

Існує два типи валідації даних:

  • в процесі введення: вид поля змінюється на помилковий, поки користувач вводить інформацію;
  • поствалідація: перевірка відбувається після переходу до наступного поля, або при натисканні на сіру кнопку.

Активна і «сіра» кнопка

Сіра кнопка – неактивна кнопка дії. Вона виключена, коли не відповідає умовам для її активації. У випадку з полями введення – кнопка сіра, якщо користувач не ввів всі обов’язкові поля, або ж заповнив деякі поля з помилкою.

Є практика – робити сіру кнопку повністю позбавленою функціоналу. Я вважаю це неправильним. Програми аналізують поведінку користувачів та фіксують, що якою б сірою не була кнопка, користувачі все одно тиснуть на неї, сподіваючись просунутися далі без заповнення поля, або без розуміння, чому вона сіра.

Для таких користувачів необхідно поміщати на сіру кнопку функціонал валідації, або ж використовувати будь-який інший формат пояснення, чому користувач не може йти далі. Наприклад, якщо користувач не ввів свою вулицю в адресі доставки і натиснув на сіру кнопку – над нею з’являється фраза «Поле вулиці не заповнено» і незаповнене поле стає червоним.

Довжину полів бажано адаптувати під передбачувану довжину контенту. Наприклад:

Слід використовувати максимально короткі слова і фрази, оскільки кількість місця обмежена. Намагайтеся писати не «В імені повинні використовуватися тільки латинські символи», а «Тільки латинські символи» або навіть «Тільки латиниця».

Часто зустрічається фраза «Мінімум 5/16/25 символів». Простий спосіб – міняти цифру не змінюючи слова. Однак, щоб зробити це грамотно, необхідно використовувати скасування для чисел. Детальніше про те, як це працює в коді, можна подивитися в цій статті.

Чекліст для зручних полів введення

Список пунктів, за якими можна перевірити зручність полів введення для користувачів:

  • Текстове поле введення безпомилково розпізнається;
  • По текстовому полю введення очевидний його статус (заповнене / пусте, в фокусі / не в фокусі);
  • Немає зайвих полів;
  • Очевидним є порядок текстових полів;
  • Формат і розмір полів відповідає даним, які вводяться;
  • Є система попередження помилок введення: назва поля, показаний формат вводу інформації або підказка про те, що очікується в цьому полі, присутній індикатор введення заборонених символів;
  • Ясно показані правильно заповнені поля;
  • Ясно показані неправильно заповнені поля;
  • Очевидний функціонал підтвердження і збереження введеної інформації.

Специфікації типів полів введення

У цьому блоці зібрані технічні специфікації для полів введення. Я використовувала свої кольори, ви можете використовувати свої. Однак пам’ятайте про колірний код: активне – кольорове, неактивне – сіре.

1. Порожнє поле з хінтом (підказкою)

  • Кольори не є обов’язковими

Це неактивне поле. У ньому немає введеної інформації, присутній тільки хінт з даними, які потрібно буде ввести в це поле (Наприклад «Ім’я:» «Країна:»);

  • У хінтів завжди є двокрапка

2. Поле з введеними даними

  • Так виглядає заповнене поле, на якому немає фокусу

3. Індикатори помилок

3.1 Активне поле помилок (помилка в процесі введення):

3.2 Неактивне поле з помилкою:

Поле з помилкою забарвлюється червоним в процесі введення тільки при введенні:

  • заборонених символів;
  • нелатинських букв там, де вказано Only latin characters;
  • невірного формату.

Помилку, що сигналізує про порожнє поле і занадто маленьку кількість символів (червоний хелпер-текст «Повинно бути мінімум n-символів»), ніколи не виводимо в процесі введення, тільки якщо користувач активував поле, нічого не ввів або ввів мало символів і вручну перейшов до наступного поля;

У всіх інших випадках він ставав червоним при переході до наступного поля введення, або при натисканні на сіру кнопку. (Наприклад, помилка Required field *);

При натисканні на сіру кнопку відбувається анімація незаповнених полів:

У сірої кнопки є функціонал. В даному прикладі кнопка має Elevation, однак я рекомендую робити неактивну кнопку очевидно неактивною.

  • Користувач не може ввести більше символів ніж дозволяє лічильник.

4. Активне поле:

Так виглядає активне поле – хінт піднявся нагору і зменшився, з’явився хелпер і лічильник (каунтер), смуга і хінт забарвилися в основний колір програми. У моєму випадку це помаранчевий, в вашому випадку – колір вашого застосування. Раджу вибирати такий колір, який би контрастував з червоним кольором помилки.

Деталізація валідації різних полів:

Тут я наводжу приклад правил для поширених типів полів. Я використовувала обмеження, які діють в нашій компанії. При використанні орієнтуйтеся на свої. Наприклад: якщо можна використовувати нелатинські букви в імені, то підберіть фразу замість зазначеного Only latin characters, відповідну вашим обмеженням.

1. Ім’я-прізвище

  • Хелпер – «Тільки латинські букви»;
  • Лічильник – максимум 70 (В нашій компанії встановлено обмеження в 35 символів, що обумовлене кількома факторами);
  • Користувач не може ввести більше символів, ніж дозволяє лічильник;
  • Хелпер – сірий в процесі введення, стає червоним, якщо користувач вводить нелатинські символи або інші заборонені знаки;
  • Помилки цього поля: Only latin characters і * Required field.

2. Поле назви компанії

  • Без хелпера;
  • Лічильник – максимум 50 символів;
  • * Required field при порожньому полі.

6. Пароль

  • Око, в поле пароля, сірий при приховуванні пароля і помаранчевий при розкритті;
  • Максимум символів – 35;
  • Поле і хелпер в процесі введення стають червоним, якщо користувач намагається ввести пробіл;
  • * Required field при порожньому полі і хелпер Min lenght: 4 non-space characters.

3. Як ввести свій номер телефону

  • Прапор та код підтягуються автоматично;
  • Курсор автоматично ставиться на друге поле;
  • Максимум символів другого поля – 30;
  • Максимальна довжина коду міста – 4 символи;
  • При введенні однієї цифри з’являються обмежені варіанти кода міста з прапором і країною:

  • Помилкою може бути незаповнене поле * Required field або Not valid code / Not valid number;

4. Поле введення пошти

  • У хелпер-тексті показаний приклад заповнення поля пошти;
  • Максимум символів – 255;
  • При використанні неправильних символів, підсвічується червоним приклад заповнення в хелпері.
  • Required field при порожньому полі.

5. Zip-code

Зверніть увагу на розмір поля – воно менше/вужче, оскільки індекс не може бути довгим

У хелпер-тексті відображається підказка формату індексу в залежності від обраної країни (сайт з індексами www.statkod.ru), наприклад:

  • Німеччина: хелпер – 01000, лічильник – максимум 5
  • Франція: 01000, лічильник – максимум 5;
  • Італія: 01000, лічильник – максимум 5;
  • Нідерланди: 1 234 AB, 6 (автоматичне проставлення пробілу);
  • Люксембург: L-1111, 4 (автоматично додавати на початку L-);
  • Португалія: 1000-001, лічильник – максимум 7 (автоматичне проставлення дефіса);
  • Литва: LT-04340: 5 (автоматично додавати на початку LT);
  • Польща: 00-950, 5 (автоматичне проставлення дефіса);
  • Латвія: LV-1000, 4 (автоматично додавати на початку LV-);
    Максимум в цілому можливий – 7 (або 9 з урахуванням винятків Данії та можливих інших, дивіться по вашим країнам);

Підсвічується червоним приклад заповнення в хелперах при використанні невірних символів або букв для деяких країн, і * Required field при порожньому полі.

6. Місто

  • У хелпер-тексті відображається столиця обраної вище країни;
  • Максимум – 24;
  • Помилки: Invalid name при використанні заборонених символів і * Required field при порожньому полі.

7. Адреса

  • В адресі використовується валідація за допомогою гугла;
  • Максимум для Street – 255 символів;
  • Максимум для Address extension – 35 символів;
  • Максимум для House № – 10 символів;
  • Помилки: Only latin characters и *Required field при порожньому полі.

8. Tin

Приклад оформлення специфіки форматів для Tin:

– Італія:

Кількість: 16

Хелпер: LLLLLL99L99L999L

Документ

Сайт ЕU з правилами

  • Помилки: червоним підсвічується приклад заповнення в хелпері за неправильного формату і * Required field при порожньому полі.

9. VAT

Назва поля введення VAT (ПДВ) змінюється в кожній країні. Міняємо назву в залежності від обраної країни, відповідно міняємо хелпер і максимальну кількість символів. Назва цього текстового поля не перекладається на інші мови, тільки змінюється в залежності від країни додатки. Джерело тут.

Приклад таблиці форм VAT для кількох країн (країна / назва VAT для цієї країни / формат / максимальна кількість символів):

  1. Austria
    – UID
    – ATU99999999
    – max 11
  2. Belgium
    – n° TVA
    – BE0999999999
    – max 12
  3. Bulgaria
    – ДДС номер
    – BG999999999
    – max 11

Помилки: підсвічується червоним приклад заповнення в хелпері при неправильному форматі, і * Required field при порожньому полі.

10. Номер карти

Програма мінімум (реалізовано):

  • Хелпер-текст (Minimum 12 numbers) сірий, поки користувач не змінив поле / не натиснув на сіру кнопку;
  • Проставляємо пропуск замість нього, пропуск вводити забороняємо;
  • Каунтер не ставимо;
  • Помилка: *Required field, якщо поле залишилося порожнім при переході до наступного, або при натисканні сірої кнопки. «Мінімум 12 чисел», якщо користувач натискає на сірий колір або змінює поле, ввівши менше ніж 12 чисел.

Програма максимум:

  • Раджу реалізувати показ типу карти (Visa, Mastercard, etc.) маленьким логотипом після введення перших цифр. Тут можна подивитися, які номери карт у різних типів;
  • Не показуємо каунтер, поки не визначимо тип карти користувача з перших цифр. Використовуємо таблицю вище. Наприклад: максимум 12 символів, якщо з перших цифр визначено, що карта належить до платіжної системи Visa або Mastercard. Якщо з перших цифр визначили, що платіжна система Maestro або American Express – 18 символів.
  • Більше про реалізацію можна почитати тут.

11. Ім’я на карті

  • Лічильник – 26, але його можна і не використовувати зовсім, оскільки ім’я на карті частіше потрібно для диспутів з шахрайства;
  • Min. 2 latin characters – сірий колір, поки користувач не змінив інпут / не натиснув на сіру кнопку.

12. Дата

  • “/” проставляємо замість користувача;
  • Помилка Not valid виводиться червоним в процесі введення, якщо користувач вводить невірний формат (не цифри);
  • Якщо користувач ввів тільки частину дати і перейшов на інший рядок – пишемо Invalid field;
  • Немає лічильника.

13. CVC

  • Minimum 3 numbers – сірим, поки користувач не змінив поле / не натиснув на сіру кнопку;
  • Немає лічильника.

Своєму інтересу в проектуванні полів введення я зобов’язана статтям Дмитра Коваленка. Ця стаття – адаптації рекомендацій Дмитра для компанії, в якій я працюю.


Раніше Telegraf.Design писав про 16 дизайн принципів, які спростять заповнення будь-якої форми.

avatar
Вікторія Доброденчук
Product Designer in AUTODOC
Колонка

У нас є ще дещо для вас