A lecke végére érted, hogy a komponens ismétlődő szereppel és szabályokkal bíró felületi egység, nem csak másolható grafikai doboz. A komponens lényeges állapotait és egy képernyő reszponzív viselkedését a feladat szempontjából meg tudod tervezni.
Miért gondolkodunk komponensekben?
Ha egy projektben tíz képernyőn szerepel a „Jelentkezés” gomb, és mindegyiket külön rajzoltad, két baj van. Az egyik: ha módosítani akarod, tízszer kell. A másik, a súlyosabb: a tíz gomb apró eltérésekkel készül, és a felhasználó nem tudja, hogy ugyanazt jelentik-e. A komponens-szemlélet azt kéri, hogy az ismétlődő elemet egyszer gondold végig, és a szabályait rögzítsd. Ez a design systemek alapja, amellyel a 9. fejezetben foglalkozunk.
Mi a komponens?
A komponens ismétlődő szerepű, dokumentált viselkedésű felületi egység. Az ismétlés nem öncél. Ha két kártya más feladatot támogat, nem kell erőltetni az azonos formát. Ha viszont egy „Jelentkezés” gomb három helyen más következményt jelez, a felhasználó nem tudja korábbi tudását használni.
Egy komponens általában rétegekből áll: egy eseménykártya például képből, címből, időpont-sorból, árjelzőből és gombból. A tervező dönt arról, melyik rész kötelező, melyik opcionális, és mi történik, ha hiányzik (például nincs kép).
Állapotok dokumentálása
A komponensállapotok a 3. fejezetben tanult UI-állapotok kisebb léptékű megfelelői. A komponensállapot a komponens adott helyzethez tartozó megjelenése és működése. Készíts állapotlistát minden kritikus komponenshez. Egy szövegmezőnél például: alap, fókusz, kitöltött, érvényes, hibás, tiltott és betöltő.
Ne csak színváltozást tervezz: legyen látható, érthető és képernyőolvasóval is közvetíthető a változás. Tiltott gombnál mondd el, milyen feltétel hiányzik; hibaállapotnál a javítás módja is legyen világos.
Gondolj a szélsőséges tartalomra is: nagyon hosszú esemény-cím, hiányzó kép, hat címke egyszerre, kétsoros ár. A komponens addig jó, amíg ilyenkor sem törik össze.
Reszponzív viselkedés
A reszponzív tervezés a felület feladathoz igazított alkalmazkodása képernyőhöz és használati körülményhez. A reszponzivitás nem az, hogy a desktop elrendezés kisebb lesz. Kis képernyőn megváltozhat a prioritás, a sorrend, a beviteli mód és a rendelkezésre álló figyelem.
Módszer: mobile first (mobilról kiinduló) szemlélet. Először azt döntsd el, mi a nem elveszíthető feladat- és információmag a legkisebb képernyőn, majd erre építsd a nagyobb nézet bővítéseit. Ez azért jó, mert kényszerít a priorizálásra.
A nagyobb nézetváltások helyét töréspontok (breakpoints) jelölik: azok a szélességek, ahol az elrendezés érdemben megváltozik (például egy oszlopról két oszlopra). Nem kell sok; kettő–három (mobil, tablet, desktop) általában elég egy tananyagprojekthez.
Gyakori reszponzív mintázatok:
Egymás alá rendeződés: a két oszlop mobilon egymás alá kerül.
Összecsukás: a másodlagos tartalom lenyitható résszé válik.
Átalakulás: a vízszintes menü alsó tab barrá vagy hamburger menüvé alakul.
Elrejtés / áthelyezés: a nem lényeges elem másodlagos rétegbe kerül; ne vesszen el fontos információ.
A nagyítás is reszponzív helyzet: ha 200%-on a tartalom levágódik vagy a művelet elérhetetlenné válik, a felület nem eszközfüggetlen (lásd a WCAG-ot a 3. fejezetben).
Végigvezetett példa: a Mai program eseménykártyája
Egy eseménykártya desktopon kép, cím, leírás, címkék és két gomb mellett jelenik meg. Mobilon a két gomb és a hosszú leírás elnyomja az időt és helyet, amelyek a gyors döntéshez kellenek. A reszponzív változat megtartja a címet, időt, helyet, árat, nyelvet és a jelentkezési feltételt, valamint a fő műveletet; a részletes leírás és másodlagos művelet külön megnyitható. Ez nem tartalomvesztés, hanem feladat szerinti priorizálás.
Komponensállapotok: alap, mentett (kiemelt jelöléssel), betelt (szürkített, magyarázattal: „Betelt, értesítést kérek”), hiányzó ár („Ár nem ismert”).
Gyakori tévhitek
Állítás
Pontosítás
„A komponens csak vizuális elem.”
A komponens szerepet, viselkedést és állapotot is hordoz.
„A reszponzivitás a skálázásról szól.”
A prioritás, a sorrend és az interakció is változik.
„Az állapotok a fejlesztő dolga.”
A tervező dönti el, milyen állapot létezik és mit mutat.
Komponensek és reszponzív állapotok
Célok
A lecke végére érted, hogy a komponens ismétlődő szereppel és szabályokkal bíró felületi egység, nem csak másolható grafikai doboz. A komponens lényeges állapotait és egy képernyő reszponzív viselkedését a feladat szempontjából meg tudod tervezni.
Miért gondolkodunk komponensekben?
Ha egy projektben tíz képernyőn szerepel a „Jelentkezés” gomb, és mindegyiket külön rajzoltad, két baj van. Az egyik: ha módosítani akarod, tízszer kell. A másik, a súlyosabb: a tíz gomb apró eltérésekkel készül, és a felhasználó nem tudja, hogy ugyanazt jelentik-e. A komponens-szemlélet azt kéri, hogy az ismétlődő elemet egyszer gondold végig, és a szabályait rögzítsd. Ez a design systemek alapja, amellyel a 9. fejezetben foglalkozunk.
Mi a komponens?
A komponens ismétlődő szerepű, dokumentált viselkedésű felületi egység. Az ismétlés nem öncél. Ha két kártya más feladatot támogat, nem kell erőltetni az azonos formát. Ha viszont egy „Jelentkezés” gomb három helyen más következményt jelez, a felhasználó nem tudja korábbi tudását használni.
Egy komponens általában rétegekből áll: egy eseménykártya például képből, címből, időpont-sorból, árjelzőből és gombból. A tervező dönt arról, melyik rész kötelező, melyik opcionális, és mi történik, ha hiányzik (például nincs kép).
Állapotok dokumentálása
A komponensállapotok a 3. fejezetben tanult UI-állapotok kisebb léptékű megfelelői. A komponensállapot a komponens adott helyzethez tartozó megjelenése és működése. Készíts állapotlistát minden kritikus komponenshez. Egy szövegmezőnél például: alap, fókusz, kitöltött, érvényes, hibás, tiltott és betöltő.
Ne csak színváltozást tervezz: legyen látható, érthető és képernyőolvasóval is közvetíthető a változás. Tiltott gombnál mondd el, milyen feltétel hiányzik; hibaállapotnál a javítás módja is legyen világos.
Gondolj a szélsőséges tartalomra is: nagyon hosszú esemény-cím, hiányzó kép, hat címke egyszerre, kétsoros ár. A komponens addig jó, amíg ilyenkor sem törik össze.
Reszponzív viselkedés
A reszponzív tervezés a felület feladathoz igazított alkalmazkodása képernyőhöz és használati körülményhez. A reszponzivitás nem az, hogy a desktop elrendezés kisebb lesz. Kis képernyőn megváltozhat a prioritás, a sorrend, a beviteli mód és a rendelkezésre álló figyelem.
Módszer: mobile first (mobilról kiinduló) szemlélet. Először azt döntsd el, mi a nem elveszíthető feladat- és információmag a legkisebb képernyőn, majd erre építsd a nagyobb nézet bővítéseit. Ez azért jó, mert kényszerít a priorizálásra.
A nagyobb nézetváltások helyét töréspontok (breakpoints) jelölik: azok a szélességek, ahol az elrendezés érdemben megváltozik (például egy oszlopról két oszlopra). Nem kell sok; kettő–három (mobil, tablet, desktop) általában elég egy tananyagprojekthez.
Gyakori reszponzív mintázatok:
A nagyítás is reszponzív helyzet: ha 200%-on a tartalom levágódik vagy a művelet elérhetetlenné válik, a felület nem eszközfüggetlen (lásd a WCAG-ot a 3. fejezetben).
Végigvezetett példa: a Mai program eseménykártyája
Egy eseménykártya desktopon kép, cím, leírás, címkék és két gomb mellett jelenik meg. Mobilon a két gomb és a hosszú leírás elnyomja az időt és helyet, amelyek a gyors döntéshez kellenek. A reszponzív változat megtartja a címet, időt, helyet, árat, nyelvet és a jelentkezési feltételt, valamint a fő műveletet; a részletes leírás és másodlagos művelet külön megnyitható. Ez nem tartalomvesztés, hanem feladat szerinti priorizálás.
Komponensállapotok: alap, mentett (kiemelt jelöléssel), betelt (szürkített, magyarázattal: „Betelt, értesítést kérek”), hiányzó ár („Ár nem ismert”).
Gyakori tévhitek
Röviden
Ellenőrző kérdések