Voitot:
- Kyky tuottaa kestävää käyttöliittymäkoodia Jetpack Composelle ja SwiftUI:lle käyttötarkoituksen, komponentin, neljän tilan (lataus/tyhjä/virhe/täysi), suunnittelujärjestelmän ja saavutettavuuden järjestyksessä.
- Kyky tuottaa kaikille käyttäjille avoin käyttöliittymä määrittämällä saavutettavuus alusta alkaen oikealla merkinnällä, riittävällä kontrastilla ja sopivalla kosketuksella.
- Mahdollisuus luoda johdonmukaisia, monikielisiä ja vaalea/tumma teemavalmiita käyttöliittymiä lukemalla värit ja tilan keskeisestä teemasta
Mobiilisovelluksen menestys määräytyy pitkälti sen käyttöliittymän (UI – näytöt, joita käyttäjä näkee ja koskettaa) ja käyttökokemuksen (UX – kuinka sujuvaa ja miellyttävää sitä on käyttää). Käyttäjä ei näe huonoa koodia, mutta tuntee huonon käyttöliittymän ensimmäisessä sekunnissa. Tekoälyllä on kaksi vahvaa roolia käyttöliittymäkehityksessä: toisaalta se luo suunnitteluideoita, virtausta ja tekstiä (UX-kirjoitus); Toisaalta se muuntaa tämän mallin suoraan toimivaksi käyttöliittymäkoodiksi. Tässä osiossa opimme tuottamaan nopeita, helppokäyttöisiä ja johdonmukaisia käyttöliittymiä tekoälyllä keskittyen nykyaikaisiin deklaratiivisiin käyttöliittymätyökaluihin Jetpack Compose (Android) ja SwiftUI (iOS). "Deklaratiivinen" tarkoittaa, että sen sijaan, että selität vaihe vaiheelta, kuinka näytön piirtäminen, kuvailet "tältä näytön pitäisi näyttää tässä tilanteessa"; Työkalu hoitaa loput.
Suunnittelusta koodiin: oikea järjestys
Tekoälyn käsky "tekeä kaunis näyttö" on epämääräistä, koska "kaunista" ei voi mitata. Hyvän käyttöliittymän luominen seuraa seuraavaa järjestystä:
- Tarkoitus ja sisältö. Mitä näyttö tekee, mitä tietoja se näyttää, mitä käyttäjä tekee?
- Komponenttiluettelo. Osat, kuten otsikko, luettelo, painike, lomakekenttä.
- Tilanteet. Ladataan, tyhjä (ei tietoja), virhe, täynnä — näytön neljä perustilaa.
- Suunnittelujärjestelmä. Värit, typografia, välisäännöt; noudattaa yleensä Material 3:n (Android) tai iOS:n Human Interface Guidelines -ohjeita.
- Esteettömyys. Näytönlukijatarrat, riittävä kontrasti, kosketuskohteen koko.
- Koodi. Kaiken tämän sanottuaan Composable- tai SwiftUI View -sukupolvi.
Useimmiten ohitettu vaihe on kolmas. Kehittäjät ottavat huomioon vain "täyden" tilan; kun taas todellisessa sovelluksessa käyttäjä kohtaa enimmäkseen "lataus"- ja "virhe"tilanteita. Kaikkien neljän tilan tulostaminen tekoälyyn on vankan käyttöliittymän salaisuus.
Vinkki: Lisää kehotteen loppuun "luo lataus, tyhjä, virhe ja täynnä erikseen". Tämä yksittäinen lause tekee käyttöliittymästäsi valmiin todelliseen maailmaan ja vähentää merkittävästi virheiden määrää QA (laatutestaus) -vaiheessa.
Saavutettavuudesta ei voida neuvotella
Esteettömyys – näkö-, kuulo- tai liikevammaisten käyttäjien mahdollisuus käyttää sovellusta – on sekä eettinen vastuu että kauppa ja oikeudellinen odotus. AI tuottaa saatavilla olevaa koodia haluttaessa; Palauttaa tagittoman, vähäkontrastisen käyttöliittymän, jos sitä ei haluta. Kolme peukalosääntöä: anna jokaiselle interaktiiviselle elementille merkityksellinen otsikko näytönlukuohjelmalle (contentDescription / AccessibilityLabel), riittävä värikontrasti tekstin ja taustan välillä (vähintään 4,5:1 suhde) ja kosketuskohde vähintään 48x48 dp/44x44 pt. Kysy tekoälyltä näitä asioita suoraan.
Varoitus: tekoäly voi myös lisätä pitkän esteettömyystunnisteen koristekuvakkeeseen; Tämä kuormittaa näytönlukijan käyttäjän tarpeettomalla puheella. Puhtaasti koristeelliset elementit tulee "piilottaa esteettömiltä" (näytönlukija voi ohittaa ne). Tarkista valmistetut etiketit: anna merkityksellisen puhua, anna koristeen olla hiljaa.
Johdonmukaisuus: suunnittelujärjestelmä ja teema
Ammattimaiset sovellukset eivät käytä satunnaisia värejä ja välilyöntejä; noudattaa suunnittelujärjestelmää (vakiosarja värit, fontit, välit ja komponentit). Jos annat tekoälylle teema-arvot (pääväri, toissijainen väri, kulman säde, typografiaasteikko), kaikki näytöt tulevat yhtenäisinä. Jos et, jokainen näyttö käyttää erilaista sinisen sävyä ja sovellus näyttää sekavalta. Tehokkain tapa on pyytää tekoälyä ensin luomaan teema-/suunnittelutunnistetiedosto ja sitten sitoa kaikki näytöt kyseiseen teemaan.
Aihe
huono lähestymistapa
Vahva lähestymistapa
Väri
Värikoodi jokaisen näytön manuaalisesti
Keskeinen teema, teemasta luetut näytöt
tilanteita
Vain "koko" näyttö
Ladataan / tyhjä / virhe / täynnä neljä tilaa
saavutettavuus
Lisätty myöhemmin
Se on määritelty vaatimuksessa alusta alkaen
tekstiä
upotettu koodiin
Erillinen lähde, monikielinen valmius
kolme minilaukkua
Tapaus 1 — Tyhjä kotelo tallennettu. Uutissovellustiimillä oli tekoälytulostuksen yksittäiset näytön tilat. "Idle status" -näytön ("Ei vielä tallennettuja uutisia") ansiosta 70 % käyttäjätestaukseen osallistuneista ei jättänyt sovellusta tyhjälle näytölle. Edellisessä versiossa tyhjä näyttö pysyi valkoisena ja käyttäjät luulivat sen "rikkinä" ja lähtivät. Pieni kopio lisäsi säilytysastetta.
Tapaus 2 – Kontrastin hylkääminen. Yksi tiimi haki App Storeen näytöt, joissa oli vaaleanharmaa teksti, merkkiväri. Apple antoi esteettömyyssyistä varoituksen alhaisen kontrastin vuoksi. Kun tekoälyä käskettiin "lisäämään tekstin ja taustan kontrastia yli 4,5:1", värit tummeutuivat ja ongelma ratkesi. Jos sitä olisi pyydetty alusta alkaen, ei olisi ollut viivytystä.
Tapaus 3 — Koristeetiketin kohina. Näkövammainen testaaja ilmoitti, että jokainen koristekuvake ("viiva", "piste", "varjo") luettiin ääneen tekoälyn luomalla näytöllä, mikä teki näytön käyttökelvottomaksi. Näytönlukijakokemus muuttui sujuvaksi, kun koriste-elementit piilotettiin esteettömyydestä. Oppitunti: saavutettavuus tarkoittaa "oikeita tunnisteita", ei "liian monta tunnistetta".
Heikko kehote / Vahva kehote
Heikko kehote: "Suunnittele profiilinäyttö."
Tehokas kehote: "Luo käyttäjäprofiilin näyttö iOS/SwiftUI:lle. Sisältö: avatar, nimi, sähköposti, "Muokkaa profiilia" -painike, asetusluettelo. Tilat: latautuu (luuranko), virhe (yritä painike), täynnä. Suunnittelu: Ei-materiaalinen, iOS HIG:n mukainen; järjestelmän värit, dynaaminen tyyppi. Helppokäyttöisyys: piilotettu elementti, esteettömyystarra4 piilotettu, 4 pt. erillinen tiedosto, älä upota värikoodia näytölle ensin komponenttipuusta ja vie koodi.
Kopioitavat mallit
Näytön luontimalli: "Luo [näytön nimi] [alustalle/työkalulle]. Sisältö: [elementit]. Käyttäjän toimet: [toiminnot]. Luo neljä tilaa erikseen: latautuu, tyhjä, virhe, täynnä. Suunnittelujärjestelmä: [Material 3 / iOS HIG], luetaan teematunnisteista. Helppokäyttöisyys: tunnisteet, kontrasti >=4.5:1, kosketusstandardi."
Teema/suunnittelujärjestelmämalli: "Tuo sovellukselleni keskeinen teemamääritelmä ([Compose Theme / suunnittelutunnisterakenne SwiftUI:ssa]):- Ensisijainen väri [heksa], toissijainen [hex], virheväri, pinnan väri- Typografiaasteikko (otsikko, runko, kuvaus)- Välimittakaava (4,8,16,24 vakiomainostuki)- kulma."
Esteettömyystarkistusmalli: "Tarkista esteettömyys tästä näyttökoodista: 1) Onko olemassa tunnistelemattomia interaktiivisia elementtejä? 2) Ovatko kontrastisuhteet riittävät? 3) Ovatko kosketuskohteet riittävän suuria? 4) Ovatko koriste-elementit piilotettu näytönlukijalta? Ehdota korjauksia jokaiseen ongelmaan. [koodi]"
Suunnittelu malliin: "Kuvailen seuraavan mallin: [näytön kuvaus tai kuvakaappaus]. Käännä tämä [Compose/SwiftUI]-koodiksi. Pidä välit ja tasaus mallin mukaisina, mutta lisää kaikki neljä tilaa."
Yleisiä virheitä
- Ajattele vain koko tilannetta. Suurimman osan ajasta todellinen käyttäjä näkee lataus-/virhenäytön.
- Värin ja tilan upottaminen koodiin. Jos teema ei ole keskeinen, johdonmukaisuus katoaa ja ylläpito vaikeutuu.
- Esteettömyys jätetään viimeiseksi. Sen lisääminen myöhemmin on kallista; Se on maksuton, jos sitä pyydetään alusta alkaen.
- Päällemerkintä. Koriste-elementtien lukeminen häiritsee myös näytönlukijakokemusta.
- Tekstin upottaminen koodiin. Kun tarvitaan monikielistä tukea, jokainen näyttö on vaihdettava manuaalisesti; Pidä tekstit erillään.
- Odotetaan tarkkaa kopiota kuvakaappauksesta. AI-suunnittelu tuottaa n. Pikselin tarkkuus asetetaan manuaalisesti.
Yhteenvetona
AI on tehokas käyttöliittymätuotannossa, mutta se vaatii ohjausta. Oikea järjestys: käyttötarkoitus, komponentit, neljä tilaa (lataus/tyhjä/virhe/täysi), suunnittelujärjestelmä, saavutettavuus, sitten koodi. Helppokäyttöisyydestä ei voida neuvotella, ja se tarkoittaa "oikeaa etikettiä", ei "liian monta tunnistetta". Johdonmukaisuuden vuoksi lue värit ja välit keskeisestä teemasta, älä upota niitä koodiin. Vahva tahto määrittelee kaiken tämän alusta alkaen; Siten käyttöliittymä on valmis todellista maailmaa, kaupan hyväksyntää ja kaikkia käyttäjiä varten.
Sovellustehtävä
Käytä "Näytön luontimallia" asetusnäytössä ja pyydä tekoälyltä Compose- tai SwiftUI-koodia ja pyydä kaikkia neljää tilaa. Tarkista sitten sama koodi "Esteettömyystarkistusmallilla". Etsi ja korjaa ainakin yksi käytettävyyden parannus (puuttuva etiketti, alhainen kontrasti tai pieni kosketuskohde) ja pane merkille, minkä tilan (lataus/tyhjä/virhe) luulet näkyvän useimmiten todellisessa käytössä.
tarkistuslista
- [ ] Selitin kehotteessa näytön tarkoituksen ja komponentit
- [ ] Olen luonut neljä tilaa (lataus/tyhjä/virhe/täysi) erikseen
- [ ] Tein värin ja tilan luetuksi keskeisestä teemasta, en upottanut sitä koodiin.
- [ ] Halusin alusta alkaen esteettömyystarroja ja kontrastia
- [ ] Varmistin, että koriste-elementit ovat piilossa näytönlukijalta
- [ ] Pidin tekstit erillään, valmiina useille kielille