Útmutató a DPI-hez tervezőknek

Ez az útmutató afféle bevezetőként íródott, hogy “hogyan is lássunk neki”- olyan tervezők részére kezdőtől a középhaladó szintig, akik többet akarnak tudni a cross- DPI és kereszt-platform tervezésről az alapoktól kezdve.

Nem lesz szó bonyolult számításokról, és nem lesznek kibogozhatatlan mondatok sem, csak egyszerű magyarázatok tömör bekezdésekbe rendezve, melyeket megértve azonnal beépíthet saját tervezése során

Eredeti szöveg: Sebastien Gabriel.

Én sem tudhatok mindent, így ha olyasmire bukkan, mely félreértés lehet, vagy magyarázatra szorul, esetleg lenne egyéb ötlete, javaslata, mitől lehetne az útmutató még jobb, kérem, írjon info@digitaldraw.hu címre.

Mi a DPI és a PPI

DPI vagy Dots Per Inch, ami a pontok sűrűségét jelenti, melyet kezdetben nyomtatásnál használtak. Megmutatja, hány tinta pontot hagy a nyomtató egy hüvelyk papírlapon. Az alacsonyabb DPI szám kevésbé részletes képet eredményez.

Ezt az elgondolást használják számítógépek esetében is, PPI néven, mely jelentése: pixel per hüvelyk. Az elv ugyanaz: azon pixelek száma, melyeket a képernyő egy hüvelyk területen megjeleníteni képes. Képernyők esetén is használt a DPI kifejezés is.

A Windows gépek esetén az alapbeállítás szerinti PPI 96. A Mac esetén 72, noha ez az érték a ‘80as évek óta nem helytálló.

A hagyományos, nem-retina kijelzős gépek (a macet is beleértve) PPI értéke a minimális 72-től 120-ig terjedhet. 72 és 120 közötti PPI érték melletti tervezés esetén biztos, hogy a munka egyformán méretarányos lesz mindenhol.

Lássunk egy példát:

A Mac Cinema Display 27” PPI értéke 109, vagyis 109 pixelt jelenít meg a képernyő 1 hüvelyknyi területén. A szélesség az éllekerekítéssel 25,7 hüvelyk (65 cm). A képernyő valódi mérete kb. 23,5 hüvelyk, vagyis 23.5*109~2560, így a képernyő natív felbontása 2560x1440px.

*Tudom, hogy 23.5*109 nem pontosan 2560. Valójában csak 23.486238532 hüvelyk. Pontosabb lenne pixel per centiméterben megadni, de a lényeg azért érthető.

Hogyan befolyásolja ez a tervezést?

Mondjuk, hogy tervezett egy 109*109px méretű kék négyzetet a fent bemutatott képernyőre.

Ennek a négyzetnek a fizikai mérete a képernyőn 1*1 hüvelyk. De ha a felhasználó képernyőjének PPI értéke 72, a kék négyzet ennél nagyobban fog megjelenni. Mivel a PPI 72, a képernyőnek kb. 1,5 hüvelykre lesz szüksége ahhoz, hogy a 109px méretű kék négyzetet megjelenítse. Lásd a hatást a képeken alább:

Megjegyzés:

A szín és felbontás beli különbségeket félretéve, ne tévessze szem elől, hogy a tervezett dizájnt mindenki másképp fogja látni. Törekedjen a legjobb megoldásra, mellyel a felhasználók legnagyobb százalékának kedvez. Ne vegye biztosra, hogy a felhasználó hasonló, és hasomlóan jó képernyővel rendelkezik, mint Ön.

Képernyő felbontás (és natív felbontás)

A képernyőfelbontás nagyban befolyásolja azt, ahogyan a felhasználó az Ön által tervezett dizájnt látja. Szerencsére, mióta az LCD monitorok felváltották a CRT monitorokat, a felhasználók többnyire olyan natív képernyő felbontással rendelkeznek, melyek jó képernyő méret/PPI arányt szavatolnak.

A felbontás meghatározza a képernyőn megjelenített pixelek számát (pl: 2560*1440px 27in. mozi kijelző esetén) ahol 2560 a szélesség, 1440 a magasság. Most, hogy már tudja, mit jelent a PPI, azt is tudja, hogy ez nem lehet a fizikai megjelenítés mértékegysége. A 2560x1440 képernyő méret jelenthet olyan méretet is, mint a fala, de akkorát is, mint a feje.

A mai LCD monitorok előre meghatározott alapbeállítás szerinti vagy natív felbontással rendelkeznek, mely pontosan annyi pixelt kezel, amennyit a képernyő megjeleníteni képes. A régi CRT monitorok esetén ez kicsit másképp működött, de mivel ezek mára tulajdonképp kihaltak, ne menjünk bele a részletekbe (azért sem, hogy ne derüljön ki, hogy csak részben értem, hogyan is működtek a jó öreg televíziók)..

Vegyük a 27” mozi kijelzőnket, mely 109 PPI kijelzésre képes 2560*1440px natív felbontás mellett. A felbontás csökkentésével az elemek nagyobbnak tűnnek majd. Végülis 23,5 vízszintes hüvelyket kell lényegében/virtuálisan kevesebb pixellel kitölteni.

Azért mondom, hogy virtuálisan, mert ez esetben erről lesz szó. A képernyő natív felbontása 2560*1440px. Ha a felbontás csökken, a pixelek itt maradnak, 109PPI kijelzési érték mellett. Az operációs rendszer az üres hely és a teljes képernyő kitöltésének érdekében mindent meg fog nyújtani. A GPU (grafikai processzor) /CPU(központi feldolgozó egység) minden egyes pixelt újraszámol az új aránnyal.

Ha a felbontást 1280*720-ra módosítja (az eddigi magassági és szélességi értékek fele) a 27” képernyőn, akkor a GPU egy kétszer akkora pixel szimulálására szorul ahhoz, hogy a képernyőt betöltse. Mit eredményez ez? Nos, elmosódottságot. Míg az arány fele nagyjából elfogadhatónak tűnik az egyszerű osztónak köszönhetően, ha az arány 1/3 vagy 3/4 részét állítjuk be, akkor tizedes számokat kapunk, azonban egy pixel NEM osztható. Lásd az alábbi példát.

Nézzük meg az alábbi példát is. Vegyünk egy 1px csíkot egy natív felbontású képernyőn. Most vegyünk egy 50%-al kisebb felbontást. A képernyő betöltéséhez a CPU 150% képet / látványt kell, hogy generáljon, mindent megszorozva 1,5-el. 1*1,5=1,5, de fél pixel nem létezik. Ilyenkor az történik,. hogy ha a környező pixeleket kitöltjük a szín töredékével, az homályos lesz.

Ezért van az, hogy Retina Macbook Pro esetén, ha meg akarja változtatni a felbontást, megjelenik az alábbi figyelmeztető ablak, miszerint (a lenti képernyőképen) a felbontás 1280*800px –nek “néz ki”. A felhasználó felbontás élményét használja a méretarány kifejezésére.

Ez egy meglehetősen szubjektív megjelenítés, mert pixel felbontást használ a fizikai méret mértékegységeként, de ettől még nem valótlan, az ő szemszögükből nézve.

Megjegyzés: 

Ha a dizájnját, (vagy bármilyen dizájnt) tökéletes pixel felbontásban szeretné látni, soha ne használjon a natív felbontástól eltérőt. Meglehet, hogy egy kisebb arány kényelmesebb, de ha a pixelekről van szó, fontos, hogy olyan precíz legyen, amennyire csak lehetséges. Sajnos sokan a felbontást használják arra, hogy az, ami a képernyőn megjelenik, jól látható legyen (különösen asztali gép esetén), miközben a kezelési beállításokon (accessibility settings) kellene változtatniuk. Ettől még mindig nem lesz szép a dizájn, de ilyen esetekben a felhasználó jó olvashatóságra vágyik és nem szépségre.

Mi az a 4k?

Valószínű sokat hallott a 4K-ról mostanában (legalábbis akkor, amikor ez íródott, 2014 elején), a 4K nagyon felkapott téma. Megértéséhez nézzük meg előbb, hogy mit jelent a “HD” fogalma.

Vigyázat, nagyon leegyszerűsítem a dolgokat. Csak a leggyakoribb felbontásokról fogok beszélni. A HD különböző kategóriákra bontható. A HD kifejezés bármilyen felbontásra alkalmazható 1280x720px felbontástól kezdődően, vagy 720p 720 vízszintes sor esetén. Ezt a felbontást SD felbontásnak is nevezik.

A full HD kifejezés használatos a 1920x1080px méretű képernyőkre. A legtöbb TV ezt a felbontást használja, és a legtöbb felső kategóriás telefon készülék is (Galaxy SIV, HTC one, Sony Xperia Z, Nexus5).

A 4K 3840x2160 pixelnél kezdődik. Nevezték Quad HD-nak is és UHD-ként (Ultra HD) is utahatunk rá. Leegyszerűsítve, egy 4K-s képernyőben a pixelek számát tekintve 4 1080p fér el.

A 4K másik lehetséges felbontása 4096x2160. Ez egy kicsit nagyobb, és projektorok, valamint professzionális fényképezőgépek esetében használatos.

Mi történik, ha 4K képernyőt csatlakoztatok a gépemhez?

A jelenlegi Operációs rendszerek nem arányosítják a 4K-t, vagyis, ha egy 4K képernyőt csatlakoztatunk egy Chromebookhoz vagy egy macbookhoz, azok az elérhető legmagasabb DPI-t fogják használni, ez esetben a 200% vagy @2x értékeket, és normál arányban jelenítik meg őket, mely szép, de kis képet eredményez.

Elméleti példa: Ha egy 12” 4K képernyőt csatlakoztatunk a 12” hi-res képernyőjű számítógéphez (2x), minden fele akkorában fog megjelenni.

Megjegyzés: 

- a 4k a Full HD felbontás négyszerese.

- A jelenlegi operációs rendszerek kezelik a 4K-t, de nem arányosítják, vagyis még nincsenek 4K specifikus készülékek

- Ma még egy telefon vagy táblagép sem használ 4K felbontást.

Monitor Hertz

Térjünk el kicsit a PPI és képernyő felbontás témakörétől. Biztos észrevette már, hogy a képernyő felbontás beállításai mellett a monitor Hz értéke is megtalálható. Ennek semmi köze a PPI-hez, de ha érdekli mi is az a monitor Hertz – vagy frissítési sebesség- ez az a sebesség, amellyel a monitorja egy fix képet vagy filmkockát (frame) másodpercenként kijelezni képes. Egy 60Hz monitor 60 filmkocka megjelenítésére képes másodpercenként. Egy 120Hz monitor 120 kockát jelenít meg stb…

A felhasználói felület esetén a monitor Hertz (Hz) azt határozza meg, hogy mennyire lesz egy animáció zökkenőmentes és részletgazdag. A legtöbb képernyő 60Hz-es. Ne feledje, hogy a másodpercenként megjelenített filmkockák függ a készülék feldolgozási és grafikai teljesítményétől is. 120Hz-es képernyőt alkalmazni egy Atari 2600 esetén értelmetlen volna.

Hogy érthetőbb legyen, nézzük meg az alábbi példát. A dino A pontból B felé halad gyors és azonos sebességgel egy 60Hz és egy 120Hz monitor esetén. A 60fps képernyőn 9 filmkocka jelenik meg az animáció során, míg a 120fps logikusan ennek kétszeresét jeleníti meg ugyanannyi idő alatt. A 120Hz képernyőn az animáció sokkal gördülékenyebb.

Megjegyzés: 

Egyesek szerint az emberi szem nem lát 60fps fölött, Ne higgyen nekik, tudomást sem véve róluk menjen tőlük minél messzebb.

Mi az a retina kijelző?

A “retina kijelző” elnevezés az Apple nevéhez fűződik, az iPhone 4 piacra dobásakor vezették be. Retinának hívják, mivel a készülék PPI-je olyan magas volt, hogy az emberi retina nem tudott különbséget tenni a képernyő pixelek között.

Ez a kijelentés igaz azon készülékek kijelzőinek esetén, ahol használták, de a kijelzők növekedésével és kifinomultabbá válásával a szemünk elég edzett lett ahhoz, hogy észlelje a pixeleket – különösen lekerekített UI elemek esetén.

Lényegében annyi történt, hogy ugyanakkora területen kétszer annyi pixelt jelenítettek meg mind széltében, mind hosszában.

Az iPhone 3G/S 3,5 inch volt átlósan 480*320px felbontással, mely összesen 163PPI.

Az iPhone 4/S átlósan 3,5 inch volt, 960*640px felbontással, vagyis 326PPI.

BUMM! Pont a kétszerese. Egyszerű szorzó. Így ahelyett, hogy kisebbek lettek volna, a képernyőn megjelenő elemek vizuálisan kétszer olyan élesek, hiszen kétszer annyi pixelből állnak, és méretükben pontosan egyezőek. Egy egyszerű 1 normál pixel= retina pixel, négyszer annyi pixel.

Vegyük az alábbi példát egy komplex dizájnban történő direkt alkalmazás esetén:

Megjegyzés a képekhez: Nehéz két különböző készülékről származó képek közti minőségkülönbséget egy harmadikon megjeleníteni, vagyis az éppen vizsgált képen. A fenti retina zenelejátszó esetében, még azonos megjelenítési tér esetén is, a képminőség kétszer olyan jó és éles az iPhone 4 esetén. Ha szeretné eredetiben megtekinteni, demonstrálás céljából ingyenesen letölthetővé tettem itt: Forrás letöltése.

A “retina” kijelző elnevezés az Apple tulajdona, így más vállalatok vagy a “HI-DPI” megnevezést használják, vagy a “Szupererős pixel maximum sp33d kijező” kifejezést (utóbbit levédetem) vagy egyáltalán semmit. Csak Önön múlik, hogy a készülék specifikációjának elolvasásakor kibogarássza-e, hogy mi a DPI és képernyőméret (milyen jó móka).

Megjegyzés: 

Az Apple termékek tökéletesen alkalmasak a DPI átalakítás megismerésére, valamint arra, hogy megértsük a különbségeket felbontás, PPI és fizikai méretarány között, mert csak 1 szorzó miatt kell aggódnunk.

Mi az a szorzó?

A szorzó a matematikai mentőöv, ha arról van szó, hogy egy dizájnt különböző PPI-ké kell alakítani. Ha ismerjük a szorzót, többé nem fontos a készülék részletes specifikációja.

Vegyük például az Phone 3G és 4 készülékeket. Ugyanabban a fizikai méretben kétszer annyi pixel van. Így a szorzónk kettő. Ez azt jelenti, hogy ahhoz, hogy az adott készülék kompatibilis legyen a 4G felbontással, nem kell mást tenni, mint a készülék méretét kettővel megszorozni és kész is van.

Mondjuk, hogy létrehoz egy 44*44px gombot, mely az iOS szerint javasolt érintő felület (erről később lesz szó). Adjunk neki egy tipikus gomb nevet, legyen ez: “DRAW”.

Ahhoz, hogy DRAW jól mutasson egy iPhone 4 készüléken, kétszer akkora verzióban kell őt létrehozni. Ezt fogjuk most megtenni.

Ilyen egyszerű. Most DRAW rendelkezik egy DRAW.png verzióval a normál PPI-hez (iPhone 3) és egy DRAW@2x.png verzióval a 200% PPI-hez (iPhone 4).

Joggal merül fel, hogy biztosan vannak más szorzók is, nemcsak a kettő. Természetesen vannak – és ettől válik az egész rémálommá. Na jó, talán nem rémálommá, de valószínű bárki szívesebben vasalgatná otthon egy napig a zoknijait, minthogy kezelje a tömérdek szorzót. Szerencsére annyira azért nem vészes a helyzet, később majd visszatérünk rá.

Beszéljünk előbb a mértékegységekről, mert a pixelen kívül más mértékegységre lesz szükség a multi-DPI dizájn meghatározásához. Itt jön be a képbe a DP és a PT.

Megjegyzés: 

Bármilyen dizájnon dolgozunk, ismernünk kell a szorzót. A szorzó az, ami összetartja a képernyőméret és PPI alkotta káoszt, és teszi érthetővé a földi halandó számára.

Mi az a DP, PT és SP?

A DP vagy PT az a mértékegység, melynek segítségével megírhatja egy multi-készülék, multi-DPI vagy ezek modelljeinek specifikációját.

A DP vagy DiP a Device independent Pixel (készülék független pixel), a PT pedig a Point (Pont) rövidítése. A PT Apple kifejezés; a DP az Android hoz kapcsolódik, de lényegében ugyanazt jelentik.

Röviden, a készülék szorzótól függetlenül fog méretet megállapítani. Ez sokat segít, amikor a különböző szereplők, mint dizájner és mérnök, megbeszélik a specifikációkat.

Térjünk vissza az előző “DRAW gombunkhoz.”

DRAW 44px szélességű normál, nem-retina kijelzőkön, és 88px széles retina kijelzőkön. Most foglaljuk a 20px DRAW-t egy keretbe, mert szereti, ha kényelmesen elfér. Ekkor a keret 40px lesz a retina kijelzőn. De nincs értelme retina pixeleket számolni, ha nem retina kijelzőre tervezünk.

Így most mindenhez normál, 100% nem-retina arányokat veszünk alapul.

Ebben az esetben DRAW mérete 44*44DP vagy PT a kerete pedig 20DP vagy PT. A specifikáció létrehozható bármilyen PPI-ben, DRAW megjelenése mindenképp 44*44dp vagy pt.

Az Android és iOS ezt a méretet alkalmazzák a kijelzőn és konvertálják a megfelelő szorzóval. Ezért könnyebb szerintem mindig a képernyőnk alapbeállítás szerinti PPI-jével tervezni.

Az SP használatában különbözik a DP-től és PT-től, de ugyanígy működik. Az SP a skálafüggetlen pixel (scale-independent pixel) rövidítése, és a betűméret meghatározására használatos. Az SP-t a felhasználó Android készülékén beállított betűméret befolyásolja. Egy tervezőnek az SP meghatározása olyan, mint bármilyen más DP meghatározása. Az alap az legyen, hogy mi olvasható 1x skálán (16sp például egy nagyon jól olvasható betűméret).

Megjegyzés: 

Specifikáláskor mindig felbontás/arány- független értékekkel dolgozzon. Mindig. Minél változékonyabbak a képernyőméret/ felbontási értékek, annál karakterisztikusabb lesz.

A PPI konfiguráció

Most, hogy tudja, mi az a PPI, a retina és a szorzó, fontos megemlíteni még valamit, melyet sokszor megkérdeznek tőlem, és zavaros lehet:”Mi történik, ha a PPI konfigurációt megváltoztatom a dizájn eszközökben?”

Ha eljutott már eddig a kérdésig, az azt jelenti, hogy konyít valamit a szoftver tervezéshez. Meg kell értenünk valami nagyon fontosat, ami nekem is beletelt egy kis időbe;

Az, ami nem nyomtatott, a kezdeti PPI konfigurációtól független pixel értékeket használ.

A PPI konfiguráció a szoftverben a nyomtatás hagyatéka. Ha csak a webre tervez, a PPI semmilyen hatással nincs a bittérkép méretére.

Éppen ezért használunk szorzókat a direkt PPI értékek helyett. A képeket és a grafikákat a szoftver a megfelelő szorzót használva mindig átkonvertálja pixelre.

Nézzünk egy példát. Kipróbálhatja egy olyan programmal, mely alkalmaz PPI konfigurációt, például a Photoshoppal. Rajzoltam egy 80*80px négyzetet és egy 16pt méretű szöveget 72PPI konffiguráció mellett. Majd utána ugyanezt 144PPI konfiguráció mellett is.

Látható, hogy a szöveg megnőtt, pontosabban kétszeresére nőtt, ugyanakkor a négyzet mérete nem változott. Ennek az oka, hogy a program (ez esetben a Photoshop) a pt értékeket arányosítja (ahogy kell) a PPI érték alapján, melynek eredményeképp a kétszeres PPI érték hatására a megjelenő szöveg mérete is a kétszeresére változik. Másrészről viszont, amit pixel megadásával definiáltunk, vagyis a kék négyzet formája, ugyanakkora maradt. A pixel az pixel, és pixel is marad, bármilyen PPI konfiguráció mellett. Ami megváltoztatja, az az őt megjelenítő képernyő PPI értéke.

Fontos megjegyezni, hogy ha digitális vonalra tervezünk, a PPI csak annyiban számít, hogy hogyan érzékeljük a dizájnt, valamint a munkamenet és az olyan pt alapú grafikák szempontjából, mint a betűméret. Ha a munkamenet során különböző PPI konfigurációkat használ, a program újraméretez minden átvitt vizuális elemet a fogadó fájl PPI arányával. Ez Önnek jelentene problémát.

Hogy mi a megoldás ? Válasszon egy PPI-t (1x dizájn esetén lehetőleg a 72-120 tartományban) és ragaszkodjon hozzá. Én a 72PPI mellett tettem le a voksom, mert a Photoshopban ez az alapbeállítás szerinti érték és a kollegáim nagy része is ugyanígy érvel.

Megjegyzés: 

- A PPI konfigurációnak semmi jelentősége nincsen webre történő exportálás esetén.

- A PPI konfiguráció csak olyan grafikákat befolyásol, melyek alapja PPI-független mérés, mint például a PT.

- Bárminek, ami digitális, mértékegysége a pixel.

- Tartsa szem előtt a szorzókat és azt, amire tervez, ne a PPI-t. 

- Digitális tervezés esetén válasszon reális PPI konfigurációt, olyat, amiről tudja, hogy fog kinézni a használni kívánt készüléken (pl: 72-120ppi 1x web/asztali gép esetén).

- Minden fájl esetén ugyanazt a PPI konfigurációt használja.

Ebben a témában hasznos olvasmány továbbá ez az érdekes: StackExchange post.

PPI kezelése iOS esetén

Ideje betekintést nyerni a platform-alapú dizájnba is.

Lássuk, mivel rendelkeznek az iOS készülékek 2014 elejétől.

Ha képernyő méretről és DPI-ről beszélünk, az iOS kétféle mobil készülékkel és 2 féle laptop/asztali gép képernyővel bír.

Mobil esetén nyilván ott van az iPhone, és az iPad. . 

Telefon kategóriában ott a jó öreg 3GS (még az iOS6 is támogatja) és ettől felfele. Csak az iPhone 3GS nem-retina kijelzős. Az iPhone 5-től felfelé a kijelző magasabb, a DPI megegyezik az iPhone 4 és 4s esetén alkalmazottal. Lásd az alábbi puskát:

Ott van még az iPod érintőképernyős kategória. Ha tervezésről van szó, kezelje őket úgy, mint egy iPhonet. A 4. generációs iPhone és az annál korábbi verziók iOS6-t használnak, és nem-retina kijelzősek. Az iPod 5 és ettől fölfele retina kijelzősek és iOS7 kompatibilisek. A képernyőjét tekintve az iPod 5 generáció az iPhone 5-tel megegyező méretű képernyőt használ.

És végül itt az iPad. Az iPad 1. generációját leszámítva (ma már elavult), mindegyik iOS7 alapú és csak az iPad2 és az iPad mini első generációja nem-retina kijelzős. Tervezés szempontjából az iPad mini hagyományos iPad (ugyanolyan PPI képernyő), csak fizikailag kisebb. Vagyis ugyanolyan felbontás mellett 9.7in helyett a mérete 7.9in. Az arány megmaradt, miáltal a pixel sűrűség nőtt. A vizuális tartalom valamivel kisebben jelenik meg.

Az asztali gép/laptop kategóriában nem nézünk meg minden képernyő méretet az Apple palettájáról. Ma, az Apple által kínált képernyők 1x szorzósak (Macbook, Macbook Air, régi Macbook prok, asztali képernyők). A retina kijelző csak a 13 és 15” Macbook Prok esetén elérhető. A szorzó 2x, az iPadekhez és iPhonokhoz hasonlóan. Ha az asztali gépre tervezés nem mobil, ugyanúgy hozunk létre tartalmakat a 2 különféle képernyő esetére.

Egyetlen szorzó mellett iOS-re és OSX-re a tartalom létrehozása meglehetősen egyszerű. Kezdje a tervezést az alap PPI-re (pl. 100%/1x) majd ezt szorozza meg kettővel a 2x akkora képernyőre a 2x akkora tartalom(asset) létrehozásához. Ha már könnyedén váltogat 1x és 2x között, képes lesz azonnal 2x érték mellett tervezni, és lekicsinyíteni a tartalmat az alacsonyabb felbontáshoz. Ez különösen hasznos lesz retina képernyőre történő tervezés esetén (Macbook pro).

Szükséges tartalmak, Chrome példa.

Látható, hogy minden alkalommal két képet kell létrehoznunk tartalmanként. A nem.retina képek kiterjesztése név.png. A retina képekhez @2x tartozik, így a megnevezésük @2x.png. iOS esetén ez a bevett szokés, melyet követni kell.

Olyan kép létrehozása esetén, mely csak iPaden lesz használva, ~ipad használatos a .@2x után. Ez a Chrome esetén bevett csupán. Ismételje meg ezt a folyamatot minden szükséges tartalom esetén. Soha ne egy verzióban adjon meg egy tartalmat; gondoljon minden DPI-re.

Megjegyzés, iOS szabályok:

- @2x tartalom az 1x tartalom kétszerese kell legyen, mindig.  

- Használja a @2x retina tartalmak esetén.

- Mindig 100% és 200% képeket hozzon létre.

- Az 1x és 2x tartalmakat mindig ugyanúgy nevezze el.

- Kezdje a tervezést 100%-n, majd szorozza be.

- .png képeket gyártson.

- A specifikációt pt adja meg px helyett.

PPI kezelése Android esetén

Az Androidos készülékek választéka nagyobb, mint amit az iOs esetén láttunk. Ennek az az oka, hogy bármelyik OEM összerakhat egy készüléket minimális korlátozás betartásával, majd erre rátöltheti a saját Android verzióját. Ennek eredménye a lényegében korlátlan számú képernyőméret és DPI, táblagép nagyságú telefonoktól az olyan apró táblagépekig, mint egy telefon. Épp emiatt, a dizájnnak minden esetben alkalmazkodnia kell.

Ebben a részben más megközelítést alkalmazunk, mint az iOS során. Először a DPI szorzókról és kategóriákról lesz szó.

Csakúgy, mint az iOS esetén, két készülék kategóriáról beszélhetünk: telefonok és táblagépek. Mindkét kategória különböző DPI kategóriákba sorolható: ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi and xxxhdpi.

Szerencsére, vannak, amik gyakrabban használatosak a többinél, van amelyik nem is használatos.

Az első lépés, hogy meghatározzuk az alapegységet, mely megfelel az iOS 1x egységnek. Az Android esetében ez az MDPI.

Lássuk a szorzókat az alábbi puskán:

Igen, jó sok, és még nincs vége. Van még egy.

Gyakorlatban négy DPI-t használunk: MDPI, HDPI, XHDPI és XXHDPI.

Az LDPI egy régi DPI, már nem használjuk, a TVDPI a TV UI speciális esete volt, és lényegében a Nexus 7 2012-es verziója használta. Telefon és táblagép esetén nem szükséges számolni a használatával. Érdemes megjegyezni viszont, hogy a TVDPI szorzója (1,33x) használatos egyes Android Wear (viselhető) termékek esetén, mint például az LG G karóra, de erre majd később visszatérünk.

Foglaljuk össze mindezt úgy, hogy az Android telefonokat és táblagépeket párosítjuk a hozzájuk kapcsolódó DPI-vel.

Előfordulhat, hogy egy készülék jelenleg XXXHDPI-t használ egyes tartalmak esetén, bár még meglehetősen ritka. Amennyiben van ideje XXXHDPI tartalmak létrehozására, azzal biztosíthatja az applikációja hosszútávú jövőjét.

Szükséges tartalmak, Chrome példa

Minden tartalomra 4 sorozatot kell elkészíteni MDPI-től XXHDPI-ig. Az LDPI kimaradhat a sorból. Az alábbi Chromera készült verzióban a TVDPI is exportálva lett, ezért ebben az esetben 5 sorozat látható minden tartalomra.

Csakúgy, mint az iOS esetén, javaslom a 100% vagy 1x szorzó alkalmazását a tervezés alapjául. Ez leegyszerűsíti a dizájn más szorzókhoz történő előkészítését, különösen Android esetén az olyan szorzókéhoz, mint 1,33 és 1,5.

Nézzük példaképpen a Chrome “Vissza” gombját Androidon:

A fent használt DPI megnevezések nem kötelezőek, nem előírás az Android hivatalos szabályzatában. Azért neveztük így el a tartalmakat, mert a jelenleg limitált tervezői eszközök használatával nehéz volna az egyes tartalom exportok specifikus útvonalát meghatározni.

Tekintve, hogy egy tartalom forráshoz olykor több száz tartalom is tartozhat, ezzel leegyszerűsíthető az exportálás folyamata és tervezői oldalon kiküszöbölhető a duplikált megnevezés használata. Considering that an asset source can sometimes hold hundreds of assets, it is a way to make the export process less painful and to avoid duplicated names errors on the designer’s side. A tartalom csoportok az alábbi módon jelennek meg a forráskészletek közt:

- drawable-mdpi/asset.png

- drawable-hdpi/asset.png

- stb...

Látható, hogy a tartalom egy 32*32dp négyzet. Az Androidos szorzókkal a probléma az, hogy némelyik tizedeseket használ. Ha egy számot 1,33-mal vagy 1,5-tel szorzunk, nagy valószínűséggel a végeredmény is tizedes lesz. Ilyen esetben értelemszerűen kerekíteni kell. Pl: 32*1,33=42,56 esetén a kerekített érték 43px.

Ügyelni kell az olyan pixel-méretezésű elemekre, mint a vonal. A vonal legyen 1x széles vagy 2x széles, de ne legyen homályos, mint ahogyan azt a képernyőfelbontás kapcsán már megbeszéltük.

Megjegyés, Android szabályok:

- Az Android 7 fajta DPI-vel rendelkezik, de számunkra csak 4 lényeges: mdpi,hdpi,xhdpi,xxhdpi esetleg még egy, ha hosszútávra tervezné az applikációt: XXXHDPI 

- MDPI az alap DPI, vagy 1x szorzó

- Az Android specifikációban dp használatos, és nem pt, de a kettő ugyanaz

- Tizedes számok esetén józan ész szerint kerekítsen.

- .png képeket alkosson.

- Egyeztesse a megnevezések alapját és az exportálási folyamatot az alkalmazásért felelős személlyel.

Mac és Chrome OS PPI

A Mac (OSX) és Chrome OS nagyon hasonlóan viselkednek PPI kezelés szempontjából.

Mindkét OS támogatja a hagyomásnyos PPI-t (100%) és hi-res / retina PPI-t (200%). Az iPhone és iPad készülékekhez hasonlóan csak 2x szorzó létezik.

Még ha a legtöbb felhasználó (Mac és Chrome OS esetén is) alacsony felbontású készülékeket használ is (egyelőre), erősen javaslom a csúcstechnológiás képernyőkhöz igazítani, és hosszúéletűvé tenni az alkalmazásokat. A Chrome OS esetén a hosszú élethez hi-res tartalmakat kell létrehozni a web-alkalmazáshoz vagy web oldalhoz, ami soha nem elfecsérelt idő.

Jelenleg összesen 3 laptop képes ezt a PPI-t kezelni: a Macbook pro 13”, 15” valamint a Chromebook Pixel. Ezen kívül a Chromebook Pixel érintőképernyős is.

Szükséges tartalmak, Chrome példa

A tökéletes példa a hasonlóságra a Chrome eszközsorának “személyre szabások” gombja lenne. Pontosan ugyanazokat használjuk mindkét platform esetén. Ha a kód eltérő, a Chrome gomb példáját.

Megjegyzés:

- A Chrome OS és OSX által használt szorzó azonos, 2.

- A Chrome OS magas felbontású kijelző érintőképernyősként is funkcionál.

Nyújtható kellékek (assets)

Függetlenül attól, hogy alkalmazása asztali gépre, vagy mobilra készül, szinte mindig szüksége lesz nyújtható kellékekre.

A nyújtható kellék úgy épül fel, hogy a kód segítségével olyan nagy legyen, amekkora csak lehet anélkül, hogy az a megjelenés rovására menne.

Nem azonosak az ismétlődő kellékekkel, melyek másképp működnek akkor is, ha olykor ugyanazt eredményezik.

Lásd az alábbi Chrome példát. Az eszközsor iOS generált és egyetlen ultra vékony kelléket használ, mely az X tengelyen ismétlődik a képernyő teljes szélésségében.

Most, hogy ezzel végeztünk, lássuk, hogyan kezelik a különféle platformok a nyújtható kellékeket

Nyújtható kellékek iOS esetén

Az iOS megkönnyíti a tervező dolgát, mert a nyújtást inkább a kódban határozza meg, nem pedig azáltal, hogy különféle megjelölésekkel látjuk el a kelléket. Nincs más dolga, mint létrehozni egy alap képet és- ha nem saját maga fogja kivitelezni- a specifikációban nyújthatónak megadni a kelléket vízszintes, függőleges vagy mindkét irányba. Lásd az alábbi példát: az alapbeállítás szerinti Chrome tartalom gomb iOS esetén.

Nyújtható kellékek Androidos rendszerben

Az Android másképp kezeli a nyújtható kellékeket, mint az iOS. Jobban a tervezőre támaszkodik.

Ennél a platformnál 9-patch guide-okat fog használni. Ezek mindegyike 4 vonalból áll, melyek magát a kelléket veszik körbe. Úgy kell megalkotni őket a szeletben/képben, mintha maguk is a látvány részesei lennének, szó szerint ezeken belül kell megjeleníteni a specifikációkat. They have to be delivered in the slice/image like it is part of the visual itself, literally visually display its specs within it. 

Két dolgot határoznak meg: a skálázandó területet és a kitöltendő területet. Ha ezeket meghatároztuk, a kód csak azt fogja tudni megnyújtani, amit meghatározott, és csak ott képes tartalmat megjeleníteni, ahol annak helyét meghatározta.

Az alábbi példában láthatja a korábban látott Chrome gomb Androidos verzióját. Az illusztrálás kedvéért felnagyítottam.

Látható, hogy a 9-patch 4 tiszta #000000 szegélyből áll. Bármely DPI esetén szélességük értéke 1px; ez a kód szerinti követelmény. A nyújtható terület nem tartalmazza a kerekített sarkokat, mert az nem olyasmi, amit ismételni lehetne (vagy a végeredmény szörnyű lenne). Ebben az esetben 10dp kitöltés került a gomb köré. Ez olyasmi, amit a specifikációnak nem kell tartalmaznia. .9 indicators also need to lay and a 100% transparent part of the asset cut. Ha nem, nem fog működni, és változtatásra szorul majd.

A 9-patch használata megkívánja, hogy illesze a .9 –t a névhez, olyan módon, ahogyan a @2x –t az iOS esetén. Nézzük az előbbi gomb példánkat ismét:

Ne feledkezzen meg a kellék méretéről. Én a jól magyarázat kedvéért elég nagyra állítottam, de nagyon fontos, hogy a kelléket optimalizálja, a lehető legkisebbre csökkentve a méretét, az alábbiak szerint. A sarkokat megtartottam, ahogy voltak, de a nyújtható és a tartalmi területeket a minimumra csökkentettem.

Győződjön meg róla, hogy a 9-patch megjelölések nincsenek átfedésben a dizájnnal és hogy a kellék levágása pontos. A .9 olyan közel kell legyen a kellékhez, amennyire csak lehetséges, anélkül, hogy átfedésbe kerülne vele. Próbáljon kitöltés beépítése nélkül dolgozni. Az előbbi példa köré csak az árnyékolás miatt került kitöltés.

A 9-patch nem jelenti, hogy elkerülheti a kellék minden DPI-be történő exportálását. Ezt a kellék minden egyes verziója esetén végre kell hajtani.

És végül, a .9 esetén beszélhetünk többszörös nyújtható területekről (a felső és a bal oldaliak). Nem mondom, hogy gyakran találkoztam ezzel munkáim során- ha valaha, egyáltalán- de azért érdemes megemlíteni.

Megjegyzés:

Mindig kérdezze meg a a dizájnt alkalmazó személyt, hogy várhatóan melyik a legoptimálisabb megoldás, különösen asztali gépek esetén. Minél több a kép, annál nehezebb lesz az applikáció, és annál bonyolultabb lesz Önnek nyomon követni és frissíteni a kellékeket. A 9-patch használata csak a források jó elnevezése és jó rendszerezése mellett javallott.

Érintőképernyő és érintési célok

Először is azt kell megértenünk, hogy annak, hogy valamit érintésre-alkalmassá teszünk, semmi köze nincsen a DPI-hez. De ha UI létrehozásáról vagy kellékek generálásról van szó, fontos megérteni az érintés és a DPI közti kapcsolatot.

Az, hogy valami érintős vagy nem érintős lesz, nagyjából az applikációnak a függvénye, hol lesz használva illetve milyen felhasználói élményt kívánunk elérni.

Válasszuk szét egyszerű kategóriákra: asztali gép, nem-érintőképernyős és mobil.

Asztali gép, nem érintős

Nem áll szándékomban történelem órát tartani, de amennyiben nem 2005-ben született, tudja, hogy a kompjúter technológia nem az érintőképernyő szem előtt tartásával született meg. Egeret és billentyűket használunk, melyek igen magas precizitással irányítják az UI-t. Az egér kurzorának precízsége 1pt. Elméletileg gyárthatnánk egy 1x1pt gombot, melyre bármelyik szuper-ember rá tudna kattintani.

Lásd az alábbi ábrát.

Ez a Chrome OS kurzorának 20x verziója.

Az aktuális felületen látható piros zóna az, mellyel műveletet hajthatunk végre az UI-n. Elég pontos. Ugye érzi, mire célzok? Mi az, ami nem pontos? Az ujjunk.

Hogyan tervezünk tehát érintésre? Mindent felnagyítunk.

Ujjméret

Lássuk az UI interakció során két leggyakrabban használt ujj átlag méretét: a mutató- és a hüvelykujjét. Ez jelenti az érintő zónát is és az ujj által elfoglalt területet is. A valós érintő zóna (vagyis az ujjunk azon része, mely ténylegesen érintkezik a kijelzővel természetesen kisebb és egy fokkal precízebb, kivéve, ha nagyon nekinyomjuk az ujjunkat a képernyőnek. 

Ha érintőképernyőre tervezünk, az érintéshez szükséges becsült terület mindig inkább nagyobb, mint kisebb legyen.

Hogyan alkalmazzuk ezt a tervezés során?

Mint már láthattuk, az inch és a cm nem a legalkalmasabb mértékegységek a pixelek világában végzett számítások esetében. Mi több, maga a pixel sem a legalkalmasabb a számolásra. De akkor hogyan tegyük érintésre alkalmassá a dizájnt?

Evidensnek tűnhet, de mindig tartsa szem előtt a megcélzott készüléket/platformot a tervezés során.

Hogy ne fecséreljünk túl sok időt, van pár alap pixel-alapú méret, melyek használata biztonságos és OS alapon a használatuk javasolt.

Javasolt érintési cél platform szerint

Itt is legyen elővigyázatos, ezek a méretek a kényelmet szolgálják és nem a valós életbeli mérésekhez igazodnak. Azért működnek, mert az OEM és a gyártók bizonyos irányelvek betartása mellett dolgoznak a konzisztens kijelző méret/dpi arány érdekében.

Látható, hogy minden OS más javasolt értékkel dolgozik, de mindegyik 48pt körül van. A Windows a kitöltést is megadja a specifikációban, ezért írtam ide.

A méretbeli különbség különböző tényezők eredménye. Az Apple kontrollálja a hardvert, annak érdekében, hogy ismerje az érintőképernyő minőségét és a pontos arányt ellenőrzése alatt tarthassa. Kisebb érintő felülettel számolhatnak. Ráadásul többnyire a hardverük is fizikailag kisebb.

Az Android és a Windows ellenben más OEM-el rendelkezik, mindegyikük saját hardvert épít, és a nagyobb érintő felület “biztonságosabbá” teszi őket. Az UI is tágasabb esetükben (különösen a windowsnál), és a készülékeik többnyire nagyobbak.

Chrome példa

A Chrome így alkalmazza ezt. A kódolt érintési célok kékkel jelölve.

Jól látható, hogy mindkét platform esetén az eszközsor a javasolt érintési cél magasságában helyezkedik el. A képet körülvevő terület is 44x44pt az iOS és 48x48pt az Android esetén. Nemcsak ez teszi méretezés szempontjából az UI-t konzisztenssé az OS-sel, de ez egy jó megoldás arra, hogy megadjon egy minimális méretet mindennek, amivel a felhasználó érintkezni fog.

Windows 8 és Chrome OS

A Windows 8 és a Chrome OS az érintő- és nem érintő interfészeket is támogatja. Ha Windows 8 alkalmazásra tervez, javaslom az ő érintő felületre vonatkozó irányelveiknek követését.

A Chrome OS irányelvekre még várni kell, de a Pixel használata nem nagy. Mivel azonban minden Chrome OS alkalmazás webes alapú, javaslom az érintőképernyőre tervezést. Ehhez javaslom az Android érintő felületre vonatkozó útmutatását.

A web, hibrid készülékek és a jövő.

Ha mobilra tervez, egyértelmű hogy a döntés: érintős. Ha asztali gépre tervez, akkor legyen nem érintős. Egyszerűnek tűnik, de ezzel kihagynánk egy feltörekvő irányzat képviselőit, a hibrid készülékeket.

Egy hibrid készülék természetesen alkalmas érintős és nem érintős megoldásokra is. A Chromebook Pixel, a Surface Pro és a Lenovo Yoga jó példák erre. 

Mi a teendő ilyen esetben? Erre nem egyszerű felelni, de megpróbálkozom, és mondok valamit, az érintős verzióhoz. A technológia ezen az ágon fog fejlődni. 

Ha webre tervez, vagy tulajdonképpen bármire, rögtön az érintősre gondoljon.

Megjegyzés:

- Gondolkodjon mobilban, gondolkodjon érintőképernyőben, bármibe is kezd a jövőben. 

- Minden OS esetén alkalmazza a javasolt érintési célokat. Ettől dizájnja nemcsak jobb lesz, de következetes is marad az OS-en belül. Az érintési célok csak referencia értékek, nem kell szükségszerűen az utolsó betűig betartania őket. Végtére is, az élmény az Ön kezében van. Use recommended touch targets for each OS. This will help make your design better and help you reach consistency within the OS.

A szoftver

Nem a szoftver teszi a tervezőt, de a megfelelő szoftver kiválasztása produktívabb és zökkenőmentesebb munkát eredményezhet. A szoftver “know-how” nem a legfontosabb tudás, de a megfelelő eszköz magas szintű elsajátítása nagy segítségére lehet az ötleteinek megvalósításában.

Ha a DPI variáció kezelésről beszélünk interfész tervezés kapcsán, a különböző szoftverek különböző módon működnek. Egyesek jobbak bizonyos feladatok esetén, mint mások. A legelterjedtebbek:

Photoshop

Az interfész tervezői eszközök atyja. Valószínűleg a leggyakrabban használt eszköz manapság. A kapcsolódó források, oktató anyagok, cikkek száma végtelen. A Photoshop szinte az interfész tervezés kezdeteitől velünk van.

Ahogy a neve is mutatja, a programot eredetileg nem interfész tervezéshez hanem fénykép- bagy bittérkép módosításához szánták. Az évek előrehaladtával fejlődött és az interfész tervezés megszületésével a tervezők kisajátították és saját céljaikra fordították. Ez részben azért történt. mert hozzá voltak szokva, és mert ez volt az egyetlen program, mely képes volt a szükséges színvonalon megoldani a feladatokat.

A Photoshop máig a Bittérkép szerkesztés mestere, és még mindig a leggyakrabban használt program az UI tervezés területén. Több évtizedes háttere azonban nehezen emészthető és tanulható programmá teszi. Egy szoftver hatalmas svájci bicskájaként bármit képes lesz megalkotni, de nem mindig a leghatékonyabb módon.

Mivel a kezdetekben bittérkép alapú volt, DPI függő- az alább bemutatott Illustrator és Sketch ellentéte.

Illustrator

A Photoshop vektor alapú testvére. A neve is mutatja, hogy fő célcsoportja az illusztrátorok, de interfész tervező eszközként is használatos.

Az Illustrator nyomtatott anyagok tervezéséhez is használt, így az interfésze, a színkezelése, skálázása, vonalzói és egységei eleinte elrettentők lehetnek. Szükség van néhány trükkre, melyek segítségével kifejezetten interfész tervezésre alkalmassá válik. A Photoshophoz hasonlóan, nagyon hatásos eszköz, melyet megtanulni cseppet sem könnyű.

A Photoshoptól abban különbözik, hogy vektor alakzatokra épülésének köszönhetően DPI független. A bittérképekkel vagy raszterekkel ellentétben, a számításokon alapuló, vektor alakzatok felhasználásával készített grafikák minőségveszteség nékül méretezhetők át.

A raszterizált és vektorizált képek közti különbség megértése a méretezhető vizuális dizájn és kellékek megalkotásának kulcsa.

Ha szívesen használna Illustratort web/interfész tervezéshez, javaslom elolvasásra: “My vector workflow” by @janoskoos.

Sketch 3.0

A Sketch a Photoshophoz és az Illustratorhoz viszonyítva új. A maga négy évével ez a program egy (jó értelemben vett) divathullámot indított el az UI iparban. Ennek az az oka, hogy a Sketch a kezdetektől fogva az interfész és UX tervezők csoportját célozta meg. A Photoshop vagy az Illustrator hagyatéka nélkül, a Sketch az interfész tervezők szűk csoportja számára tökéletes eszközként hirdeti magát.

A Sketch alkalmas gyors vázkészítésre, de összetettebb vizuális tervezésre egyaránt. Az Illustratorhoz hasonlóan teljességgel vektor alapú, minimális és jól megtervezett UI mellett. A rajtáblák, az egyszerű felhasználás, valamint a rugalmas kellék-generáló rendszerének kombinációja az, ami a multi-DPI és multi-platform tervezés leggyorsabb eszközévé teszi. A közelmúltban kiadott 3.0 verziója a Photoshop tökéletes alternatívája.

Hátránya, hogy a Sketchnek kisebb a háttértámogatása és még viszonylag újnak számít. A mögötte álló csapat rendkívül reaktív, de meg sem közelíti az Adobe (Photoshop és Illustrator) méreteit. A Sketch (tervezés alapján) csak a minimumot nyújtja, ha bittérkép szerkesztésről van szó. Ilyen munkához a Photoshop alkalmasabb. És végül, fiatal korának köszönhetően a rendelkezésre álló források, oktató anyagok és egyéb információk mennyisége jelentősen kisebb, mint a Photoshop esetében. Mindezzel együtt, a közösség roppant aktív és motivált.

Én személy szerint 8 évvel ezelőtt kezdtem tervezéssel foglalkozni, és azóta a Photoshopot használtam, de nemrégiben Sketch 3.0-ra váltottam a tervezési folyamat legnagyobb részében. Ez azonban semmit nem minősít, a Photoshop még mindig elsőrangú program, csak nekem a másik megfelelőbb.

Ha érdeklik a személyes tapasztalataim, javaslom olvasásra: “A month with Sketch 3.0” cikkemet vagy a “Sketch tutorial_01” oktató anyagot.

Jobban elmélyedne abban, hogy hogyan működnek a vektorok a sketchben? Olvassa el @pnowelldesign’s cikkét: “Harnessing vector awesomeness in Sketch”

Megjegyzés:

Egy munka elvégzésének a legtökéletesebb eszköze az, amit magabiztosan használ. Ha ideje és pénztárcája engedi, javaslom, próbálja ki mindegyiket és döntsön saját maga!

Dokumentumok és források

Ez a leírás nem több, mint egy bevezető, de most eljött a kicsit mélyebb tanulás ideje! Az alábbiakban talál néhány linket, ha többet szeretne tanulni vagy akár mélyebben elmélyedni az itt említett témakörökben:

Platform dokumentáció

Android UI guidelines

Google Material guidelines

iOS7 UI guidelines

Windows UI guidelines

Google dev Principles of site design

Puskák és sablonok

Screen sizes, ratio and PPI

iOS7 designer cheat sheet

iOS7 design resource (requires Apple account)

App icons template, Android and iOS

Bjango blog (A design article gold mine)

iPhone GUI and iPad GUI(.psd) by @teehanlax

Eszközök

Density converter by @brdrck

Android asset generation by @brdrck

Android design tips by @destroywerk and @BPScott

9patch creation in Android by @romannurik

Android asset studio by @romannurik. Lots of great tools for Android specific asset creation.

További olvasmányok

Device independent pixel formula for Mobile devices

More information about 4K by Cnet.com

More informations about touch targets by Smashing Mag

The Android Screen Fragmentation Myth

Észrevételek és javítások: info@digitaldraw.hu

Vissza a főoldalra