Јединице
1. Увод у АИ у мобилном развоју: улоге, границе, аутентификација и безбедност 2. Генерисање мобилног кода са вештачком интелигенцијом: Котлин, Свифт и развој на више платформи 3. Дизајн интерфејса и генерисање УИ кода са вештачком интелигенцијом 4. АИ на уређају: Цоре МЛ, ТенсорФлов Лите и МЛ Кит 5. Цлоуд АИ и ЛЛМ АПИ интеграција: ћаскање, ток и безбедност 6. Генерисање тестова са вештачком интелигенцијом: тестови јединица, интерфејса и аутоматизације 7. Отклањање грешака и анализа пада са вештачком интелигенцијом 8. Оптимизација перформанси и батерије: брзе и ефикасне апликације са вештачком интелигенцијом 9. Приватност, дозволе и безбедно коришћење 10. Издање у продавници: Апп Сторе, Гоогле Плаи и компатибилност са вештачком интелигенцијом 11. Пројекат од краја до краја, одговорно коришћење вештачке интелигенције и путоказ у професији
Јединица 3 / 11

Дизајн интерфејса и генерисање УИ кода са вештачком интелигенцијом

Добици:

  • Способност израде робусног кода интерфејса за Јетпацк Цомпосе и СвифтУИ према сврси, компоненти, четири стања (учитавање/празно/грешка/пуна), систем дизајна и приступачност
  • Могућност израде интерфејса који је отворен за све кориснике дефинисањем приступачности од почетка, са исправним означавањем, довољним контрастом и одговарајућим додиром.
  • Способност креирања доследних, вишејезичних и интерфејса спремних за светло/тамну тему читањем боје и простора из централне теме

Успех мобилне апликације је у великој мери одређен њеним корисничким интерфејсом (УИ — екрани које корисник види и додирује) и корисничким искуством (УКС — колико је глатко и пријатно за коришћење). Корисник не види лош код, али осети лош интерфејс у ​​првој секунди. АИ игра две моћне улоге у развоју интерфејса: с једне стране, генерише идеју дизајна, ток и текст (УКС писање); С друге стране, он директно претвара овај дизајн у радни код интерфејса. У овој јединици ћемо научити како да произведемо брзе, приступачне и доследне интерфејсе са АИ, фокусирајући се на модерне декларативне алате интерфејса Јетпацк Цомпосе (Андроид) и СвифтУИ (иОС). „Декларативно“ значи да уместо да објашњавате корак по корак како да нацртате екран, ви описујете „овако би екран требало да изгледа у овој ситуацији“; Алат ради остало.

Од дизајна до кода: прави редослед

Рећи АИ да „направи леп екран“ је нејасно јер се „лепо“ не може измерити. Добра генерација интерфејса следи овај редослед:

  1. Сврха и садржај. Шта ради екран, које информације приказује, шта ће корисник урадити?
  2. Листа компоненти. Делови као што су наслов, листа, дугме, поље обрасца.
  3. Ситуације. Учитавање, празно (без података), грешка, пуно — четири основна стања екрана.
  4. Систем дизајна. Боја, типографија, правила размака; генерално у складу са смерницама за људски интерфејс материјала 3 (Андроид) или иОС.
  5. Приступачност. Ознаке читача екрана, адекватан контраст, величина додирне мете.
  6. Код. Рекавши све ово, Цомпосабле или СвифтУИ Виев генерација.

Корак који се најчешће прескаче је трећи. Програмери узимају у обзир само „пуно“ стање; док се у стварној апликацији корисник углавном сусреће са ситуацијама „учитавања“ и „грешке“. Штампање сва четири стања на АИ је тајна робусног интерфејса.

Савет: Додајте „генерисање учитавања, празног, грешке и пуног одвојено“ на крају упита. Ова појединачна реченица чини ваш интерфејс спремним за стварни свет и значајно смањује број грешака у фази КА (тестирање квалитета).

О приступачности се не може преговарати

Приступачност — могућност коришћења апликације од стране корисника са сметњама у виду, слуху или мотору — је и етичка одговорност и продавница и законска очекивања. АИ производи доступан код по жељи; Враћа интерфејс без ознака, ниског контраста ако није пожељно. Три основна правила: дајте сваком интерактивном елементу смислену ознаку за читач екрана (цонтентДесцриптион / аццессибилитиЛабел), адекватан контраст боја између текста и позадине (однос најмање 4,5:1) и циљ додира од најмање 48к48 дп/44к44 пт. Питајте АИ ове ствари експлицитно.

Опрез: АИ такође може додати дугу ознаку приступачности на декоративну икону; Ово затрпава корисника читача екрана непотребним брбљањем. Чисто декоративни елементи треба да буду „скривени од приступачности“ (дозвољено да их прескочи читач екрана). Прегледајте произведене етикете: нека смислено говори, нека декоративно ћути.

Конзистентност: систем дизајна и тема

Професионалне апликације не користе насумичне боје и размаке; прати систем дизајна (стандардни скуп боја, фонтова, размака и компоненти). Ако АИ дате вредности ваше теме (главна боја, секундарна боја, радијус угла, скала типографије), сви екрани ће испасти доследни. Ако то не учините, сваки екран ће користити другачију нијансу плаве и апликација ће изгледати претрпано. Најефикаснији начин је да прво замолите АИ да генерише датотеку токена теме/дизајна, а затим повеже све екране са том темом.

Предмет

лош приступ

Снажан приступ

Боја

Ручно кодирајте сваки екран у боји

Централна тема, екрани који се читају из теме

ситуације

Само "пун" екран

Учитавање/празно/грешка/пуна четири стања

приступачност

Додато касније

У тврдњи је дефинисано од почетка

текст

уграђен у код

Одвојени извор, спреман за више језика

три мини кофера

Случај 1 — Празан случај је сачуван. Тим апликације за вести је имао АИ штампање појединачних стања екрана. Захваљујући екрану „статус мировања“ („Још нема сачуваних вести“), 70% учесника у корисничком тестирању није напустило апликацију на празном екрану; У претходној верзији, празан екран је остао бео и корисници су мислили да је „покварен“ и отишли. Мала копија повећала је стопу задржавања.

Случај 2 — Одбијање контраста. Један тим се пријавио на Апп Сторе са екранима са текстом у светло сивој боји, у боји бренда. Аппле је издао упозорење због приступачности због ниског контраста. Када је АИ речено да „повећа контраст текста и позадине изнад 4,5:1“, боје су постале тамније и проблем је решен. Да се ​​то тражило од почетка, не би било одлагања.

Случај 3 — Шум на украсној етикети. Тестер са оштећеним видом пријавио је да је свака икона украса („линија“, „тачка“, „сенка“) прочитана наглас на екрану генерисаном вештачком интелигенцијом, што екран чини неупотребљивим. Искуство читача екрана постало је флуидно када су декоративни елементи били скривени од приступачности. Поука: приступачност значи „праве ознаке“, а не „превише ознака“.

Слаби промпт / Јаки промпт

Слаб упит: „Дизајнирајте екран профила“.

Снажан упит: „Генериши екран корисничког профила за иОС/СвифтУИ. Садржај: аватар, име, е-пошта, дугме 'Измени профил', листа подешавања. Статуси: учитавање (костур), грешка (дугме за поновни покушај), пуна. Дизајн: нематеријалан, у складу са иОС ХИГ; системске боје, динамички тип. Приступачност: приступачност: аццессибилитимецорЛабел, додирни циљни елемент, мин. вредности из засебне датотеке, немојте уграђивати код боја на екран Прво нацртајте стабло компоненти, а затим извезите код.

Шаблони који се могу копирати

Шаблон за генерисање екрана: „Генериши [име екрана] за [платформу/алатку]. Садржај: [елементи]. Корисничке радње: [радње]. Засебно генеришите четири стања: учитавање, празно, грешка, пуна. Систем дизајна: [Материал 3 / иОС ХИГ], читање из токена теме. Приступачност: ознаке, контраст >=4,5:1, стандард за додирну мету.“

Шаблон система теме/дизајна: „Направи централну дефиницију теме за моју апликацију ([Састави тему / структуру токена дизајна у СвифтУИ]):- Примарна боја [хек], секундарна [хек], боја грешке, боја површине- Скала типографије (наслов, тело, опис)- Скала размака (4,8,16,24)- Стандардни радијус светла и тамне подршке.“

Шаблон ревизије приступачности: „Проверите приступачност у овом коду екрана: 1) Да ли постоје неозначени интерактивни елементи? 2) Да ли су односи контраста адекватни? 3) Да ли су мете за додир довољно велике? 4) Да ли су декоративни елементи скривени од читача екрана? Предложите исправке за сваки проблем. [шифра]“

Шаблон дизајна до кода: „Описујем следећи дизајн: [опис екрана или снимак екрана]. Преведите ово у [Цомпосе/СвифтУИ] код. Задржите размак и поравнање у складу са дизајном, али додајте сва четири стања.“

Уобичајене грешке

  • Само размишљам о целој ситуацији. Већину времена прави корисник види екран учитавања/грешке.
  • Уграђивање боје и простора у код. Ако тема није централна, конзистентност се губи и одржавање постаје тешко.
  • Остављамо приступачност за крај. Додавање касније је скупо; То је бесплатно ако се захтева од почетка.
  • Оверлабелинг. Читање украсних елемената такође ремети искуство читача екрана.
  • Уграђивање текста у код. Када је потребна вишејезична подршка, потребно је ручно променити сваки екран; Држите текстове одвојено.
  • Очекује се тачна копија са снимка екрана. АИ дизајн производи прибл. Прецизност пиксела се подешава ручно.

Укратко

АИ је моћан у производњи интерфејса, али захтева смернице. Тачан редослед: сврха, компоненте, четири стања (учитавање/празно/грешка/пуна), систем дизајна, приступачност, затим код. О приступачности се не може преговарати и значи „праву ознаку“, а не „превише ознака“. Ради доследности, прочитајте боју и размак из централне теме, немојте је уграђивати у код. Јака воља све ово дефинише од почетка; Тако је интерфејс спреман за стварни свет, одобрење продавнице и све кориснике.

Задатак апликације

Користећи „Шаблон генерисања екрана“ за екран са подешавањима, затражите од АИ за Цомпосе или СвифтУИ код и затражите сва четири стања. Затим проверите исти код помоћу „Шаблона за проверу приступачности“. Пронађите и поправите најмање једно побољшање приступачности (недостаје ознака, низак контраст или мали додирни циљ) и забележите за који статус (учитавање/празно/грешка) мислите да ће се најчешће појавити у стварној употреби.

контролна листа

  • [ ] У промпту сам разјаснио сврху и компоненте екрана
  • [ ] Имао сам четири стања (учитавање/празно/грешка/пуна) генерисана одвојено
  • [ ] Направио сам да се боја и простор читају из централне теме, нисам то уградио у код.
  • [ ] Желео сам ознаке приступачности и контраст од почетка
  • [ ] Проверио сам да су декоративни елементи скривени од читача екрана
  • [ ] Држао сам текстове одвојено, спремне за више језика