#1. Ознайомлення з поширеними станами UI компонентів - javascript.org.ua

Створення UI компонентів у Figma:
#1. Ознайомлення з поширеними станами UI компонентів | #2. Проектування UI компонентів орієнтованих на інженерні вимоги

Ця серія статей допоможе вам глибше зрозуміти, як створювати професійні UI компоненти в Figma. Ми розглянемо від знайомства з найпоширенішими станами UI компонентів, до створення компонентів, що відповідають вимогам інженерії.

UI компоненти відіграють важливу роль у процесі розробки веб- і мобільних продуктів. Перед тим як почати створювати UI компоненти в Figma, давайте розглянемо найосновніше: зрозуміємо, з якими основними станами UI компонентів користувач стикається під час щоденної взаємодії. Розуміння цих основ допоможе створювати більш повноцінний і ефективний досвід взаємодії з користувачем.

Ця серія статей підходить для таких читачів:

Новачки-дизайнери, які хочуть...

Зрозуміти основні стани взаємодії UI компонентів, створюючи міцний фундамент для дизайну інтерфейсів.
Навчитися створювати розвинену систему UI компонентів.

Досвідчені дизайнери, які хочуть...

Створювати більш зручні для співпраці з інженерними командами специфікації дизайну.

1. Основні стани взаємодії

Rest, Hover, Focus і Active

Різниця між Rest, Hover, Focus і Active

Ці чотири стани є типово зустрічаються для кнопок, тому давайте розглянемо ці стани на прикладі кнопки:

Rest (стандартний стан)

Це початковий стан кнопки, також відомий як Default. Це стан, коли користувач ще не взаємодіяв з кнопкою.

Hover (під час наведення курсору)

Це стан, який з’являється, коли курсор миші знаходиться над кнопкою. Це візуальний відгук, що кнопка активна і з нею можна взаємодіяти.

Focus (фокусування)

Це стан, що виникає, коли кнопка отримує фокус через Tab клавішу або клік. Цей стан надзвичайно важливий для доступності (Accessibility).

Active (натискання)

Це стан, коли кнопка натискається, але ще не відпущена. Метою цього стану є надання негайного зворотного зв'язку під час натискання.

В залежності від пристрою, на якому використовується продукт, дизайн взаємодії повинен бути відповідним. Наприклад, якщо продукт орієнтований на Desktop, треба врахувати всі чотири стани при створенні UI компонентів. Але якщо продукт призначений для Mobile, можна зосередитись лише на станах Rest і Active.

2. Стан доступності

Enabled і Disabled

Різниця між Enabled і Disabled

Enabled стан

У стані Enabled користувач може виконувати нормальні взаємодії та операції. Наприклад, при наведенні миші з’являється стан Hover, при натисканні кнопки з’являються Focus та Active стани. Компоненти у стані Enabled зазвичай мають більш виразний колірний контраст, що дає зрозуміти користувачу, що з ними можна взаємодіяти.

Disabled стан

У стані Disabled компонент не реагує на взаємодії з користувачем. Компонент в стані Disabled зазвичай має знижений контраст, наприклад, за допомогою прозорості, сірого відтінку або без тіней, які використовуються в активному стані, щоб візуально показати, що компонент не доступний.

Можливі ситуації для стану Disabled:

Кнопка для відправлення форми може бути в стані Disabled, якщо не всі поля заповнені.
Коли користувач не має прав доступу до певних функцій, ці функції будуть у стані Disabled.
Якщо система обробляє запит, щоб запобігти багаторазовому натисканню кнопки, кнопка буде в стані Disabled.

3. Стан валідації форми

Valid (за замовчуванням, успішно) і Invalid (помилка)

Різниця між Valid і Invalid

Коли ми заповнюємо поля форми, іноді з'являються підказки, які вказують на помилки, такі як неправильний формат електронної пошти чи необхідність використання великих літер і спеціальних символів. Це є станом валідації Invalid.

У валідації форми є два стани: [Valid] та [Invalid], які визначають правильність введених даних.

Valid стан

Коли введена інформація відповідає вказаним вимогам, форма має статус Valid. Valid також може бути поділено на за замовчуванням (Default) та успішно (Success). У стандартному стані Valid не виділяється, але в деяких випадках (наприклад, при перевірці формату пароля в реальному часі) можна додати зелену позначку, щоб підкреслити стан Valid.

реальна перевірка пароля від airbnb

Invalid стан

Коли введена інформація не відповідає вимогам, форма переходить в Invalid стан. В цьому випадку, зазвичай, з’являються повідомлення червоного або помаранчевого кольору, що вказують на помилку.

Стан валідації форми може з’являтися в таких випадках:

При створенні нового пароля перевіряється, чи відповідає пароль вимогам. Коли всі правила виконуються, з'являється позначка Valid Success, яка підтверджує правильність введення.
Коли користувач намагається відправити форму з не заповненими обов'язковими полями, форма показує Invalid стан і вказує, що потрібно заповнити ці поля.

4. Інші стани

A. Стан завантаження (Loading State)

Стан завантаження кнопки

Стан Loading призначений для того, щоб повідомити користувачу, що система обробляє запит. Наприклад, коли ми змінюємо персональні дані і хочемо, щоб система зберегла зміни, кнопка переходить у стан Loading, щоб показати користувачу, що зміни зберігаються.

Зазвичай використовуються обертальні круги з текстовими підказками, наприклад: “Збереження...” або “Завантаження даних...”.

B. Unchecked і Checked (статус вибору)

Checkboxes

Різниця між Unchecked, Checked і Indeterminate

Ці стани характерні для компонентів Checkbox.

До того ж, я помітив, що іноді дизайнери чи інженери плутають, коли використовувати Checkbox (Checked / Unchecked)
Inactive та Active (стан активації)

Різниця між Inactive та Active

Коли ми дивимось на вкладки (Tabs), з'являються два стани для кнопок: [Inactive] та [Active].

Inactive стан

Щоб не зробити кнопку в Active стані надто виразною, візуально для Inactive стану зазвичай використовують світлі або нейтральні сірі відтінки, але залишають достатній контраст для видимості.

Active стан

Кнопка в Active стані виглядає виразніше, щоб користувач зрозумів, що саме ця кнопка є активною.

Різниця між вкладками (Active) та кнопками (Active)

Коли я тільки почав створювати UI компоненти, я часто задумувався, чим відрізняються Active стан вкладки і Active (натискання) стан кнопки. Ось що я з'ясував:

Active стан вкладки (Tabs):

Означає вибрану вкладку.
Це тривалий стан, поки користувач не перемкнеться на іншу вкладку.
В рамках вкладок лише одна вкладка може бути в Active стані, всі інші — Inactive.
У CSS коді для цього використовують CSS клас [.active].

Active стан кнопки:

Означає стан, коли кнопка натискається.
Це тимчасовий стан, який триває лише в момент натискання. Після відпускання кнопки стан Active зникає.
Дає користувачу миттєвий зворотній зв'язок, показуючи, що кнопка натискана.
У CSS коді для цього використовують CSS селектор стану [:active].

Ось приклад CSS для Active стану вкладок та кнопок:

/* Tabs використовує Class для керування Active станом */
.tab.active {
  background-color: white;
  border-bottom: 2px solid blue;
  color: blue;
}

/* Кнопки використовують селектор стану для Active */
.button:active {
  background-color: darkblue;
}

D. Readonly (Тільки для читання)

Різниця між Rest, Hover, Active та Readonly станами

Readonly стан здебільшого використовується для текстових полів (Text Input), коли користувач може переглядати, але не змінювати вміст.

Enabled (Rest), Readonly та Disabled (Rest) — візуальні відмінності

1. Колір фону

Enabled (Rest): Зазвичай має білий фон [#ffffff].

Readonly: Зазвичай використовується світлий сірий фон, наприклад, [#f2f4f7], щоб показати, що вміст неможливо редагувати.

Disabled (Rest): Може мати той самий фон, що і Readonly.

2. Колір тексту

Enabled (Rest): Зазвичай темно-сірий або чорний текст [#101828].

Readonly: Може бути таким самим, як у Enabled (Rest).

Disabled (Rest): Зазвичай світло-сірий текст, наприклад, [#667085].

E. Visited (Відвідано)

Стан кнопок посилань

Visited стан з'являється, коли посилання (Links) вже було відвідане. Його мета — допомогти користувачу зрозуміти, які посилання вже були відвідані. Наприклад, у списку статей цей стан дасть змогу користувачеві відрізнити прочитані від непрочитаних статей.

Це основні стани UI компонентів, з якими користувачі зазвичай стикаються під час взаємодії. Під час розробки можна подумати, на якому пристрої буде використовуватись ваш продукт, і відповідно до цього адаптувати взаємодії з компонентами для покращення досвіду користувача.

У наступній статті ми покажемо, як застосовувати ці стани при створенні інженерно-орієнтованих UI компонентів у Figma.

Посилання на статті

Опис станів CSS:

[

W3Schools.com

W3Schools пропонує безкоштовні онлайн-уроки, довідники та вправи з основних мов веб-розробки. Детально розглядаються...

www.w3schools.com

](https://www.w3schools.com/css/default.asp?source=post_page-----4fc0402d9f35--------------------------------)

WCAG — стандарт доступності веб-контенту:

[

Web Content Accessibility Guidelines (WCAG) 2.1

Web Content Accessibility Guidelines (WCAG) 2.1 охоплює широкий спектр рекомендацій щодо поліпшення доступності веб-контенту...

www.w3.org

](https://www.w3.org/TR/WCAG21/?source=post_page-----4fc0402d9f35--------------------------------)

Звичні стани компонентів для користувача:

[

Всі стани, з якими стикається користувач

Стан, з яким стикається користувач, — це те, що він відчуває при взаємодії з елементом або спробі взаємодіяти з ним...

ericwbailey.design

](https://ericwbailey.design/published/all-the-user-facing-states/?source=post_page-----4fc0402d9f35--------------------------------)

🌟 Наступна стаття #2. Інженерно-орієнтовані UI компоненти

#1. Знайомство з основними станами UI компонентів | #2. Інженерно-орієнтовані UI компоненти

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

Бажаєте дізнатися більше про Design System? Залишайтеся на зв'язку!

Перекладено з: #1. 了解常見 UI 元件狀態