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