Прибуток:
- Можливість створювати надійний код інтерфейсу для Jetpack Compose та SwiftUI у порядку цілей, компонентів, чотирьох станів (завантаження/порожній/помилка/повний), системи дизайну та доступності
- Здатність створювати інтерфейс, відкритий для всіх користувачів, визначаючи доступність із самого початку, з правильним маркуванням, достатньою контрастністю та відповідним дотиком.
- Можливість створювати узгоджені, багатомовні та готові до світлої/темної теми інтерфейси шляхом зчитування кольору та простору з центральної теми
Успіх мобільного додатка значною мірою визначається його користувальницьким інтерфейсом (користувальницький інтерфейс — екрани, які бачить і торкається користувач) і досвідом користувача (UX — наскільки зручним і приємним є його використання). Користувач не бачить поганий код, але відчуває поганий інтерфейс в першу секунду. ШІ відіграє дві потужні ролі в розробці інтерфейсу: з одного боку, він генерує ідею дизайну, потік і текст (UX написання); З іншого боку, він безпосередньо перетворює цей дизайн у робочий код інтерфейсу. У цьому розділі ми навчимося створювати швидкі, доступні та узгоджені інтерфейси за допомогою ШІ, зосереджуючись на сучасних інструментах декларативного інтерфейсу Jetpack Compose (Android) і SwiftUI (iOS). «Декларативний» означає, що замість крок за кроком пояснювати, як намалювати екран, ви описуєте «ось як екран має виглядати в цій ситуації»; Решту зробить інструмент.
Від дизайну до коду: правильний порядок
Сказати штучному інтелекту «зробити гарний екран» нечітко, оскільки «красиве» неможливо виміряти. Хороший інтерфейс створюється в такому порядку:
- Мета і зміст. Що робить екран, яку інформацію він показує, що робитиме користувач?
- Список компонентів. Такі частини, як заголовок, список, кнопка, поле форми.
- Ситуації. Завантаження, порожній (немає даних), помилка, повний — чотири основні стани екрана.
- Система проектування. Колір, типографіка, правила інтервалів; загалом відповідає Інструкціям щодо людського інтерфейсу Material 3 (Android) або iOS.
- Доступність. Етикетки програми зчитування з екрана, відповідний контраст, розмір торкання.
- Код. Сказавши все це, створення Composable або SwiftUI View.
Найбільш часто пропускається третій крок. Розробники розглядають лише «повний» стан; тоді як у реальному застосуванні користувач здебільшого стикається із ситуаціями «завантаження» та «помилки». Друк усіх чотирьох станів на ШІ - це секрет надійного інтерфейсу.
Порада: додайте «генерувати завантаження, порожнє, помилка та повне окремо» в кінці підказки. Це одне речення робить ваш інтерфейс готовим до реального світу та значно зменшує кількість помилок на етапі QA (тестування якості).
Доступність не підлягає обговоренню
Доступність — можливість використовувати програму користувачами з вадами зору, слуху або моторики — це як етична відповідальність, так і вимоги закону. AI виробляє доступний код за бажанням; Повертає інтерфейс без тегів із низьким контрастом, якщо це не потрібно. Три емпіричні правила: дайте кожному інтерактивному елементу значущу мітку для програми зчитування з екрана (contentDescription / accessibilityLabel), адекватний колірний контраст між текстом і фоном (співвідношення принаймні 4,5:1) і область дотику принаймні 48x48 dp/44x44 pt. Запитайте ШІ про ці речі явно.
Застереження: ШІ також може додати довгий тег доступності до декоративної піктограми; Це переповнює користувача програми зчитування з екрана непотрібною балаканиною. Суто декоративні елементи мають бути «приховані від доступності» (дозволяється пропускати програмою зчитування з екрана). Перегляньте виготовлені етикетки: нехай значуще говорить, декоративне нехай мовчить.
Узгодженість: система оформлення і тема
Професійні програми не використовують випадкові кольори та інтервали; дотримується системи дизайну (стандартний набір кольорів, шрифтів, інтервалів і компонентів). Якщо ви задасте штучному інтелекту свої значення теми (основний колір, допоміжний колір, радіус кута, масштаб типографіки), усі екрани будуть узгодженими. Якщо ви цього не зробите, на кожному екрані використовуватиметься інший відтінок синього, і програма виглядатиме безладно. Найефективніший спосіб — спочатку попросити штучний інтелект створити файл токенів теми/дизайну, а потім прив’язати всі екрани до цієї теми.
Тема
поганий підхід
Сильний підхід
Колір
Вручну позначте колірний код кожного екрана
Центральна тема, екрани читаються з теми
ситуації
Тільки «на весь» екран
Завантаження/порожній/помилка/повний чотири стани
доступність
Додано пізніше
Це визначено в претензії з самого початку
текст
вбудовані в код
Окреме джерело, готове до кількох мов
три міні-чохла
Випадок 1 — збережено порожній випадок. Команда новинного додатка роздрукувала ШІ окремі стани екрана. Завдяки екрану «неактивний стан» («Новини ще не збережені») 70% учасників тестування користувачів не залишали додаток на порожньому екрані; У попередній версії порожній екран залишався білим, і користувачі думали, що він «зламаний», і пішли. Маленька копія збільшила рівень збереження.
Випадок 2 — Відмова від контрасту. Одна команда звернулася до App Store з екранами з текстом світло-сірого кольору, фірмового кольору. Apple випустила попередження про доступність через низький контраст. Коли штучному інтелекту було сказано «збільшити контраст тексту та фону вище 4,5:1», кольори стали темнішими, і проблема була вирішена. Якби це було запропоновано з самого початку, затримки не було б.
Випадок 3 — Шум декоративної етикетки. Тестер із вадами зору повідомив, що кожна піктограма орнаменту («лінія», «крапка», «тінь») була прочитана вголос на екрані, створеному ШІ, що робило екран непридатним для використання. Зчитування з екрана стало плавним, коли декоративні елементи були приховані від доступності. Урок: доступність означає «правильні теги», а не «забагато тегів».
Слабка підказка / Сильна підказка
Слабка підказка: «Створіть екран профілю».
Потужна підказка: «Створити екран профілю користувача для iOS/SwiftUI. Вміст: аватар, ім’я, електронна пошта, кнопка «Редагувати профіль», список налаштувань. Статуси: завантаження (скелет), помилка (кнопка повторної спроби), повний. Дизайн: нематеріальний, відповідає iOS HIG; системні кольори, динамічний тип. Спеціальні можливості: accessibilityLabel для кожного елемента, декоративні піктограми приховано, сенсорна ціль мінімум 44 pt. Читайте значення теми з окремий файл, не вставляйте кольоровий код на екран, спочатку намалюйте дерево компонентів, а потім експортуйте код."
Шаблони, які можна копіювати
Шаблон генерації екрана: «Генерувати [ім’я екрана] для [платформи/інструмента]. Вміст: [елементи]. Дії користувача: [дії]. Окремо генерувати чотири стани: завантаження, порожній, помилка, повний. Система дизайну: [Матеріал 3 / iOS HIG], зчитування з маркерів теми. Доступність: мітки, контраст >=4,5:1, стандарт торкання.»
Шаблон системи теми/дизайну: «Створення центрального визначення теми для мого додатка ([Створити тему /структура маркера дизайну в SwiftUI]): - Основний колір [hex], вторинний [hex], колір помилки, колір поверхні - Масштаб типографіки (заголовок, основний текст, опис) - Шкала інтервалів (4,8,16,24) - Стандарт радіуса кута Додати підтримку світлих і темних тем.»
Шаблон аудиту доступності: «Перевірте цей код екрана на доступність: 1) Чи є будь-які інтерактивні елементи без тегів? 2) Чи адекватні коефіцієнти контрастності? 3) Чи достатньо великі елементи дотику? 4) Чи декоративні елементи приховані від програми зчитування з екрана? Запропонуйте виправлення для кожної проблеми. [код]»
Шаблон дизайну до коду: "Я описую наступний дизайн: [опис екрана або знімок екрана]. Перекладіть це в код [Compose/SwiftUI]. Зберігайте інтервали та вирівнювання відповідно до дизайну, але додайте всі чотири стани."
Поширені помилки
- Просто думаючи про повну ситуацію. У більшості випадків справжній користувач бачить екран завантаження/помилки.
- Вбудовування кольору та пробілу в код. Якщо тема не є центральною, послідовність втрачається, і обслуговування стає складним.
- Залишаючи доступність наостанок. Додати його пізніше дорого; Це безкоштовно, якщо запитувати з самого початку.
- Надмірне маркування. Зчитування декоративних елементів також порушує роботу програми зчитування з екрана.
- Вбудовування тексту в код. Якщо потрібна багатомовна підтримка, необхідно вручну змінити кожен екран; Тримайте тексти окремо.
- Очікується точна копія зі скріншоту. ШІ-дизайн створює прибл. Точність пікселів встановлюється вручну.
Підсумовуючи
ШІ є потужним у створенні інтерфейсів, але він потребує керівництва. Правильний порядок: мета, компоненти, чотири стани (завантаження/порожній/помилка/повний), система дизайну, доступність, потім код. Доступність не підлягає обговоренню та означає «правильну мітку», а не «забагато міток». Для узгодженості читайте колір і інтервали з центральної теми, не вставляйте їх у код. Сильна воля визначає все це з самого початку; Таким чином, інтерфейс готовий для реального світу, схвалення магазину та всіх користувачів.
Аплікаційне завдання
Використовуючи «Шаблон генерації екрана» для екрана налаштувань, попросіть ШІ код Compose або SwiftUI та запитайте всі чотири стани. Потім перевірте той самий код за допомогою «шаблону перевірки доступності». Знайдіть і виправте принаймні одне вдосконалення спеціальних можливостей (відсутня мітка, низька контрастність або маленька область дотику) і запам’ятайте, який стан (завантаження/порожній/помилка), на вашу думку, найчастіше з’являтиметься під час реального використання.
контрольний список
- [ ] Я чітко вказав призначення та компоненти дисплея в підказці
- [ ] Чотири стани (завантаження/порожній/помилка/повний) були згенеровані окремо
- [ ] Я зробив так, щоб колір і простір зчитувалися з центральної теми, я не вставляв їх у код.
- [] Я хотів позначки доступності та контраст із самого початку
- [ ] Я переконався, що декоративні елементи приховано від програми зчитування з екрана
- [ ] Я тримав тексти окремо, готові для кількох мов