IA alatt UML-alapú IA-modellezésről lesz szó, de előtte definiálni kell, mi az IA. A múlt héten a viselkedési modellekről volt szó, azaz milyen a rendszer változásában, most arról, milyen a rendszer az időben állandóan (akár mindig, akár egy adott képzeletbeli pillanatba lepauzálva)
Marika néni kávézójának mobilalkalmazása
Mi is az az IA, és mi az IA modell?
Az angol Wikipédia a cikk írásakor egybe von két definíciót:
Az IA (információs architektúra) az információ szervezésének, rendezésének és címkézésének tudománya/művészete, a megtalálhatóság és a használhatóság érdekében.
Máshonnan nézve az IA az információs rendszerek struktúrális tervezése.
Nekem most van egy ezekhez kapcsolódó, de a cikk (és a Krea képzésstruktúrája, valamint a UXStratégia napi gyakorlata) szempontjából praktikusabb definícióm:
Az IA modell esetünkben egy rendszer vagy forgatókönyv információcsoportjainak modellje, azok vizuális paramétereinek figyelembevétele nélkül.
Azaz az IA modell arra koncentrál, milyen dolgok tartoznak össze, ezeket hogy csoportosítjuk, de azzal közvetlenül nem, hogy ezek a csoportok aztán később hogy férnek ki a képernyőre.
Ez különbözteti meg a drótvázaktól, amelyek azzal is foglalkoznak, egy adott képernyőn ezek milyen elhelyezkedésben jelennek meg. Tehát esetünkben ebben az elgondolásban az IA-nak a drótvázazás nem része, hanem az IA egy azt megelőző tevékenység.
Az IA mindig azzal foglalkozik, mi a tartalom jelentése, nem azzal, mi is ez a konkrét tartalom (pl. a “blogposzt címe” szerepelne egy IA ábrán, az “Hogy specifikálj? II. IA tervek” nem biztos). Az elnevezések arra szolgálnak, hogy az adott tartalmat megtalálják.
Kognitív pszichológiai szempontból ugyanis az IA arra szolgál, hogy kapcsolódó fogalmakkal segítsük navigálni a felhasználót, és megtalálni azt, amiért tulajdonképpen jött.
A gyakorlatban ebbe az IA modellbe értjük a műveletek elnevezését és az információk közötti kapcsolatokat (és azok elnevezését is): ha egy törlés gombra azt írnánk, “ezt nézd meg!”, lehet hogy nagyobb lenne a véletlen kattintások száma.
(Sőt: a usability tesztek többségében találunk elnevezési problémákat műveleteken, amiknek javítása akár kétjegyű konverziójavulást is tud eredményezni)
Úgy is mondhatjuk, az IA az, ami a drótvázból megmarad mire minden önálló elemet szétvagdostunk, és az összes konkrét tartalmat kicseréltük annak funkciójára (pl. 2016-04-28 helyett “A poszt dátuma”). Az IA ezek csoportosításával foglalkozik, a vizualitás figyelembevétele nélkül.
(Ha valaki az UML üzleti modellezéssel rokonságot lát, az nem véletlen.)
Na de hogyan csoportosítunk?
Függőségi lánc alapján
A MÁV vonatjegyvásárlásának sematikus függőségi lánca
Az első és legtriviálisabb dolog a számítási láncok feltérképezése, ezt csináltuk rendszerint a MÁV-nál.
A MÁV jegyvásárló rendszerei a végén árajánlatot adnak. De mi kell ahhoz, hogy tudjuk az árat? Legfőképp tudni kell a távolságot, amit az határoz meg, honnan, hova és min keresztül megy az illető, meg hogy a jegye egyirányú-e. Tudni kell, az illető milyen kedvezményt vesz igénybe, ill. hogy egyáltalán egyedül utazik-e. Bizonyos kedvezmények csak bizonyos napokon, sőt, akár csak megfelelően előre váltva érvényesek, így tudnunk kell az utazás és a jegyvétel napját. A gyorsvonati pótjegyek adott napra, viszont az IC jegyek adott napon adott vonatra érvényesek, tehát az IC jegyek miatt tudnunk kell a konkrét vonatot.
Nem nehéz belátni, hogy ezeket a kérdéseket az előtt érdemes megkérdezni, hogy árajánlatot mondanánk, megfelelő sorrendben (pl. a dátumot az előtt illik megkérdezni, hogy felsoroljuk az IC vonatokat).
A MÁV esetén a függőségi lánc sok évtizedes üzleti gyakorlatból következik, rendkívül vastag szabályzatok szólnak róla, nem egy asztalnál a projekt idejére kitalált sorrend.
A függőségi lánc gyakran a feladatból is következik, de rendszerint az üzleti működés határozza meg.
A függőségi lánc feltérképezése mindig visszafelé, a végeredményből történik: ellenkező esetben hajlamosak lennénk kevésbé szükséges elemeket is bevonni.
De mit tehetünk ha az asztalnál kell kitalálni a sorrendet?
Kártyarendezéses csoportosítás
Először is megkérdezhetjük a felhasználóinkat, szerintük hogy logikus. Ezt csináltuk a MIMOX tudásbázisának csoportosításánál.
Mimox GeekHub kártyarendezés eredménye – a „statisztikailag logikus csoportosítás”
Erre vannak eszközök, amik ezek statisztikai paramétereit vizsgálják. A piacvezető az OptimalSort.
Fontos, hogy ugyanazon elemek csoportosítása más- és más lehet, attól függően, milyen feladatot hajtunk végre. Maga a Card Sorting ebből a szempontból nem jó, mert az egyik felhasználónak az egyik, másiknak a másik feladat járhat a fejében.
Ezen egyfelől demográfiai szűrésekkel, másfelől viszont ellenőrző kérdésekkel tudjuk megoldani, ezt Reverse Card Sorting-nak is hívják. Ennek az eszköze az OptimalSort kistestvére, a TreeJack.
Ez kiadja az egyes felhasználók szerinti “logikus” csoportosítást, amire szerencsés esetben jó statisztikákat tudunk készíteni. Viccesen “statisztikailag logikus” csoportoknak is szoktuk hívni a többségi logikát képviselő rendezéseket.
Többszintű rendszereket az eredménycsoportok csoportosításával érhetünk el.
Amennyivel jobb ez mint az íróasztalnál kitalálni, hogy több nézőpontot vesz figyelembe, ráadásul felhasználóit: aki használja a rendszert, az lehet, teljesen máshogy gondolkodik róla mint aki “csak” tervezi azt!
Természetes csoportosítások és sorrendek
Hogy sorrendezzünk?
Az Information Architecture főművének írója, Wurman 5 különböző csoportosítást és sorrendet különböztet meg:
- Hely alapú (Location)
- Szótári (Alphabetical)
- Időrendi (Time)
- Kategorizált (Category)
- Tornasor szerinti (Hierarchy)
Ezeket hívjuk Wurman- vagy más néven LATCH rendezéseknek.
A hierarchizált kicsit trükkös, volt aki úgy kommentálta, Wurman nem akarta elrontani a már kialakulófélben lévő rövidítését…
4 elemnél vagy az alatt a csoportosítás kb. mindegy: egy sima órai kísérlettel bemutatható, az emberi agy a négy elemet egyszerre képes kezelni, nem keres benne.
Néhány elemnél (egy tucat nagyságrend) érdemes valamiféle valószínűségi, fontossági sorrendet felállítani: egy webshopnál pl. a termékkategóriákat felállíthatjuk az offline bolt forgalmának jelenlegi sorrendje szerint, aztán A/B tesztekkel próbálhatunk változtatni. Ez felel meg a tornasor szerintinek.
Időben elhelyezhető elemeknél általában a legaktuálisabbal kezdünk (pl. ez a blog is így sorrendez). Itt mondjuk ha nem “next”-et írnánk a gombra, hanem “older”-t, lehet egyszerűsítene az archívumok navigálhatóságán.
Térben elhelyezhető elemeknél a valószínűség azt diktálja, hogy az illető a hozzá legközelebb eső elemekre kiváncsi. Ha ezt nem tudjuk, akkor ha van mesterséges, de megszokott sorrend – Budapesten ez a kerületek számozása – akkor használhatjuk azt, vagy megpróbálhatunk hiearchizálni (kontinens, ország, város), az egyes szinteken pedig ABC-rendet követni.
ABC rendet akkor követhetünk, ha feltételezzük az illetőről, hogy egy adott szót használ a keresett dologra: a hivatalos telefonkönyv ilyen – ott senki nem szerepel a becenevén -, az országok neve (Burma vagy Mianmar?) viszont néha életekbe kerül. Volt már olyan amúgy, hogy valakit nem találtál a telefonod telefonkönyvében?
Minek kategorizáljuk? Hívhatjuk a feltaláló gyár miatt Kamjovénak, akkor is ha más márka? Gyorsfőző? Munkahelyi Gongfu? Utazós Gongfu? (Amúgy ez egy teázáshoz való eszköz)
Az oldal- és komponensmodell
Na, most hogy megvannak a csoportjaink, sorrendbe vannak téve, ideje felruháznunk őket a funkciókkal.
Fontos megérteni: a csoportosítás alapja a weben az oldal. Az oldalakba, képernyőkbe rendezés önmagában csoportosítást jelent. Szerencsés esetben persze az oldal megfelel valamilyen tartalomelemnek, de azok a csoportosítási elvek, amiket fent felsoroltunk, mind oldalak között, mind oldalakon belül érvényesek.
Erre pedig bevezetjük az oldalosztály fogalmát, a programozók által használt UML (Univerzális Modellezőnyelv) figyelembevételével. Egy oldalosztály a következő tulajdonságokkal rendelkezik:
- OLDAL NEVE
- Megjelenített információk
- Bekért információk
- Oldalon belüli műveletek
- Navigáció
- Tartalmazások
Az oldalosztály szekciói
A megjelenített információk azon információk tartalmi cimkéinek felsorolása, amelyek az oldalon vannak. Egy blogposzt-oldal osztálya esetén pl.:
- poszt címe,
- poszt szerzője,
- poszt dátuma,
- poszt indítóképe
- poszt szövege
Ez az osztály élesen különbözik attól a blogposzt-oldal példánytól ami a konkrét kitöltött blogposzt (ez)
Bekért információk tipikusan űrlapoknál szerepelnek, de ott is vannak megjelenített információk (pl. egy vonatjegynél a kedvezmény típusa egy bekért információ, az viszont, hogy mik a kedvezmény feltételei, egy megjelenített)
(hivatalosan a bekért és megjelenített információknak UML osztályok esetén ugyanoda kéne tartozniuk, de ne menjünk most bele a metamodellezésbe, ha valakit érdekel, a kiadó szervezet, az OMG rendszerében kutakodhat.)
Az oldalon belüli műveletek azok, amik alapvetően nem visznek minket nagyon más állapotba, vagy az adott szempontból az a más állapot irreleváns. Ilyen lehet egy FB poszton a like gomb, amely az esetek többségében nem visz minket sehova.
A navigációt rendszerint nem az osztálydoboz részeként, hanem a többi oldal felé mutató, induló tövében feliratozott nyílként ábrázoljuk.
A tartalmazás a legtrükkösebb.
Oldalosztály vs komponensosztály
Alapvetően senki nem szeretné az összes oldalt egyetlen nagy, monolitikus osztályként ábrázolni.
Szóval darabokra kéne osztani, célszerű ezt komponensenként megtenni, mondjuk itt ez a blogposzt, alatta a kommentszekció, mellette mindenféle, különböző funkciókat ellátó dobozok, felül egy fejléc, ésatöbbi.
Különösen érdekes ez táblázatos oldalaknál, ahol rendszerint vannak fejadatok (amik az egész táblázatra igazak), aztán jön egy csomó ugyanolyan dolog, ezt hogy ábrázoljuk?
Erre szolgálnak a komponensek: egy oldalnak lehet 0 vagy több komponense. A komponens az oldaltól gyakorlatilag nem különbözik, de URL-je nincs.
Az oldal és komponensei közötti kapcsolat hivatalos jelzése a kompozitor nyíl (rombusz-végű buzogány), de én egyszerűen bele szoktam őket rajzolni, más színnel (ld. fent)
Dinamikus vs statikus modellek
Az IA alapvetően statikus modelleket jelent: vagy a rendszer permanens, vagy a pillanatnyi állapotát ábrázolja.
Ugyanakkor a statikus modellek nem képzelhetőek el a dinamikus modellekre való utalás nélkül és fordítva.
Na de mi van akkor, ha nekünk csak egy szimpla weboldalunk van? Akkor is van dinamikus modell?
Nézetmodell vs Rendszermodell
Sokszor van az, hogy ugyanarról a dologról információk egy adott halmazát megjelenítjük, másokat elrejtünk, más helyen pedig fordítva.
Ezt úgy hívjuk, vetítés (projection).
Miért fontosak nekünk a vetítések?
Mindig vissza kell utalni, hogy az IA az információ rendezésének ÉS elnevezésének (címkézésének) tudománya.
A felhasználó alapvetően két dologért nyit meg egy programot:
- meg akar tudni valamit
- el akar intézni valamit
Ha meg akar tudni valamit, akkor (hacsak az információ nem a kezdőoldal kellős közepén van, pl. az Is it Christmas esetén) a felhasználónak oda kell találnia.
Ezt a navigációs utat mutathatjuk be egy vetített IA modellel.
Természetesen egy adott use case-csoporthoz tartozó oldalakat (pl. belföldi jegyvásárlás) is bemutathatunk.
A rendszermodell
A rendszermodell azért fontos, hogy átlássuk, mit csinálunk. Ilyenek a klasszikus oldaltérképek, menütérképek, de ide sorolható a Content Inventory legtöbb ága, vagy akár a Concept model is.
A rendszermodell a fejlesztők szempontjából is fontos, egy új elem bevezetése így érthető meg, hogy hullámzik végig a rendszeren.
Konklúzió
Az információmodellezés a drótvázazást megelőző szakasz. Fejlesztői szempontból a fontossága óriási, hisz (egyetlen vékony réteget kivéve) ez fogja meghatározni a rendszer komplexitását: befolyásolja az adatbázis-tervezést és a külső felületeket egyaránt.
A mostanában divatos MVVM fejlesztési architektúra esetén a Model az IA rendszermodellel, a ViewModel az IA vetítéses modelljeivel áll meglehetősen közeli rokonságban.
Dizájn szempontból az IA kitalálása az, ami megkülönbözteti a UX-et a hagyományos tervezőgrafikától: a tervezőgrafika ugyanis mindig adott információs architektúrával dolgozik – adott a könyv, amit meg kell jeleníteni, adott a reklámüzenet, amit át kell adni, a kérdés „pusztán” ennek vizuális hierarchiája, megjelenítése. A UX-ben a kérdés eggyel tágabb: nem csak, hogy hogy nézzen ki a termék, hanem hogy mi is legyen az.
