GUI - különböző felbontások kezelése touch környezetben

Grafika: GUI, OpenGL

Sziasztok,

több különböző cikk hozzászólásai kapcsán előjött az a probléma, hogy mi a korrekt módja annak a problémának a kezelésének, mely szerint különböző méretű grafikus képernyők vannak, melyek mind felbontásban, mind fizikai méretben eltérőek. Ezt a problémakört szeretném egy kicsit feszegetni, ti hogy csináljátok, milyen problémákkal találkoztatok, ezeket hogyan oldottátok meg, milyen keretrendszert használtok, az adott keretrendszernek milyen korlátozásai vannak, stb.

- adott egy widget, ami kinéz valahogy
- ezt a widget-et akarjuk megmutatni különböző felbontású és méretű képernyőkön
- több esetben előfordul, hogy a komponens méretét ne engedjük adott méretnél nagyobbra nőni, egy nagyobb területen mutassunk belőle inkább többet. Természetesen jó lenne megadni azt is, hogy egy adott komponensnek mi a minimális mérete egy adott felbontásban, hiszen mondjuk egy touch-os felületen van egy méret, aminél kisebbet értelmesen nem lehet megnyomni (most a titkárnő a műkörme hegyével céloz című játékokat felejtsük)
- hogy a dolgot tovább bonyolítsuk, előfordul, hogy egy adott widget különböző alelemekből áll, mint például szövegek, vagy ikonok. Ha összenyomjuk a widget-et, akkor ezt hogyan kezeljük? Menjenek összébb a szövegek (betűméret csökkentése)?
- sok felbontást kellene támogatni (mi a jelenlegi megoldásunkban 1x különböző felbontást támogatunk)
- a különböző felbontások támogatása a lehető legkevesebb konfigurálással történhessen
- előfordulhat, hogy egy kisebb felbontásban teljesen más layout-ot érdemes használni, mint egy nagyobban. ezt hogyan kezelnétek?
- mit csinálnátok több képernyő esetén?

( Aadaam v | 2013. 05. 24., p – 22:34 )

Responsive Design-nak hívják a dolgot. breakpointokat szokás betenni, a breakpointok között nyúlik a képernyő.

Olyan toolokkal mérjük ki, mint pl. a gridpak - http://gridpak.com/

A képekre az a trükk (PPI szempontból), hogy alacsony tömörítésű JPEG-eket használnak, vagy vektorokat, ha nem tudják vmiért lekérni a PPI-t.

CSS-ben a megoldás a media query.

Cikkek:
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive…
http://coding.smashingmagazine.com/2012/08/20/towards-retina-web/
http://mobile.smashingmagazine.com/2013/03/21/responsive-web-design-wit…

Könyv:
http://www.abookapart.com/products/responsive-web-design

Design patternek max - érted, itt a megoldás tulképp mi:

1) grid-based design

Nem mindig alkalmazható, amikor igen, akkor viszont lehet azt mondani, hogy vannak az "egyoszlopos", a "kétoszlopos", meg az "x-oszlopos" interfészek, ezekről hozunk egy döntést, hogy ez melyik, és ha adott, hogy hány oszlopos, akkor eldöntjük, hogy annak min és max mérete közt nyújtunk valamit vagy úgy hagyjuk.

2) retina vagy nem retina?

Érdemes-e rá rátölteni egy duplafelbontású képet? Mondjuk ha touch, konzumer és natív (érted, egy étterem pincéreknek szóló rendelőfelülete is lehet touch)

3) mekkora az ujjlenyomatod?

Egyszerűen pl. egy Sony X8-as hiába ugyanúgy touch mondjuk mint egy iPad vagy egy Samsung Note, az ujjad nem lesz a képernyő méretével arányosan kisebb.

4) mekkora a nézőtér

Fogod a telefont, kényelmesen a kezedben. Kb. tisztán központi látással (fovea) lehet látni, környezeti infó szinte nuku egy kis telefonnál, így a minimálra kell szorítkozni.

5) landscape vagy portrait? 4:3 vagy 16:10?

Ez az, ahol a web és a natív elcsúszik egymástól, mert a web marhára nem foglalkozik a függőleges felosztással - szkrollozz, szevasz. Ha nálad is lehet szkrollozni, úgy nem kell foglalkoznod máshogy a függőleges elrendezéssel.

Amúgy Apple, Google, Microsoft (Windows 8) design guidelines-okban kéne rá elvileg hivatalos válasz, de én átnéztem most mindhármat, nem nagyon találtam. Ez a táblázat viszont még lehet hasznos.

( sz332 v | 2013. 05. 26., v – 13:02 )

Mi a következő megoldást választottuk. Mivel alapvetően java-ban fejlesztünk, ezért a swing és a javafx 2.0 között vacilláltunk, végülis a swing győzött, mert a javafx 2.0-ból hiányoztak dolgok, amik nekünk kellettek.

Tehát írtunk egy css framework-öt, ami a swing-re alapul, és saját propertiary css formátumban lehet elemeket style-olni. Amivel kiegészítettük, az a változók definiálása @var(x=13) amit azután a css-ben lehet használni: #myComponent { width: @expr(x);} illetve a változó érték az egy kifejezés is lehet, és használhat másik változókat is: @var(y=13*x+14) Amivel ez többet tud, mint a javafx 2.0, hogy lehetőség van css-ből widget méretet állítani, illetve a változó deklarálása, valamint a css egymásba ágyazhatósága (@import). (meg valószínűleg egy csomó minden más :))

E fölött van egy layout engine, a trükk az, hogy egy container méretét nem fixen határozzuk meg, hanem a layout-nak megfelelően. Pl. van olyan layout, ahol egy lista a bal felső sarokban 200x300 pixel 1024x768 felbontásban. Egy másik layoutban a lista a jobb alsó sarokban van, 400x530 pixel méretű 1024x768 felbontásban. Ezekre az anchor pontokra lehet az egyes containerek becsatolni, akik átveszik a szülő container méretét, és a benne lévő widget-ek méretét pedig globális változóból, és a container méretéből számoljuk. Ezt megint csak azért tudjuk megtenni, mert saját framework-ünk van.

A különböző felbontást úgy kezeljük, hogy minden egyes felbontás/layout kombinációhoz külön css file-unk van, a rendszer pedig felismeri a képernyő felbontását, és annak megfelelő css-t tölti be.

Az alap widget-ek leírását egyetlen css file-ban tároljuk, a layout file-ok elég kicsik, néhány kb-osak.

Ne haragudj, de én ezt nem feltétlenül tartom jó iránynak.

Egyszerűen nem illeszkedik a "felhasználók" (felülettervező grafikus, UX designer, stb) domain-modelljébe: a felületeket nem így fogalmazzák meg.

A CSS-nek az volt a legnagyobb baja, hogy nem támogatta jól a hasábokat, holott a grafikusokat erre képezték szarrá.

A felületek tervezésekor három meghatározó elem van:

1) Gestalt-principumok, a látás működésének elvei
2) Tervezési minták, az öntudatlanul beégett "behaviour, look & feel" minták ismétlése
3) Vizuális hierarchia, ami az 1-es pont "implementációja".

Ezek közösen adnak feltételezett affordanciát (perceived affordance), legalábbis jó esetben.

Ennek a klasszikus, elfogadott megvalósítása a grid-rendszerek (nem összekeverendő a grid layouttal!). Ez a modernista tipográfiából jön, egy egyszerűsítés tulképp, a legtöbb honlap és a mai legújabb felületek (pl. Android, ) ezt használják. (Ez a kép nem perfekt, de valszeg tervasztalon nekik is jobban nézett ki)

Ennek megfelelően a legtöbb responsive design tool (gridpak, adobe edge flow...) ebben gondolkozik.

Az egész felülettervezésről múlt héten szó szerint könyvet írtam (ill. pontosabban tanfolyamjegyzetet), ezért van ennyi linkem most :)

Ha te azt mondod, hogy de nem grafikus csinálja a grafikát, nem is fogja soha, és ti könnyen lefordítjátok a grid-modellt erre, vagy van egy olyan modelletek, amivel érthető vizuális hierarchiát csináltok és mégse grid, rendben, ez a grid dolog most felkapott, de már 2005-ben is ezt követelték rajtam (fejlesztőként) a grafikusok...

Szia,

köszi szépen a linket (illetve könyveket) átolvasom az összeset, mert nagyon érdekes témának tűnik,
és úgy látom, mást is foglalkoztat. Az UI tervezési minták különösen tetszettek, régóta kerestem ilyet, de eddig nem találtam, ez szuper jó.

A grid rendszert néztem, de még nem igazán látom, hogy ezt egy alkalmazás fejlesztésénél hogy lehetne használni, de mindenképp beleásom magam. Ettől függetlenül az összes grafikát mi csináljuk, UX designer nincs, és valószínűleg soha sem lesz (bár igény, na az volna rá :))

Most lehet, hogy hülyeséget kérdezek (még nem ástam bele a témába magam, előre is elnézést), de: adott egy form, amiben van 5 darab label, mellette 5 darab gomb, alul pedig egy submit és egy cancel. Ha jól értem, a grid rendszer azt mondja meg, hogy vizuálisan hova kellene ezeknek az elemeknek kerülni, hogy egységesen nézzen ki?

Az androidos cikkben lévő density-independent pixels egy érdekes koncepció, nagyjából 1-2 nap alatt át is tudnánk írni a rendszerünket, hogy ezt a méretezést használja, bár azt nem látom, hogy mennyivel lennénk előrébb.

A vizuális hierarchia alatt mit értesz? A gridpak, adobe edge flow, ezek mind-mind webes megoldások, ahol mint már korábban írtad, ott lefele lehet scrollozni, viszont cserébe jórészt szövegből áll, míg
egy alkalmazásnál erre nincs mód, ott egy fix képernyőt látsz,illetve drasztikusan kevesebb a szöveg, szóval ott ez a logika mennyire használható?

Szia,

Kérdésedre válaszolva (form): igen, ez a logika. Mutatok egy formot, szintén én terveztem, de ott a többiek válasza és kommentjei is. Egyszerűen gyorsabb előkaparni ezt mint megtalálni a 10 éves jegyzeteim közt a Visual Basic-es egyetemi példát :) Ha megnézed, ez is grid, de az Access tervezőjében is van, és a Win7 design doksiban is hivatkoznak rá.

Szóval a logika mindenhol használatos. Desktopon mondjuk nem csodaszer, mert nagyon sok minden szerepet játszik, de ott is jellemző, hogy az számít letisztultabbnak, ami ilyen, szerintem. Eredetileg könyvekre volt - az oldalméret is véges...

Láttad, hogy a gmail is így néz ki mobilon, a Win8 totál (nekik már nem teljesen a klasszikus grid-logika van, de ez is grid-logika, csak kevésbé programmatikus)

A grid rendszer pedig mindig egy egyszerűsítés. Alapvetően a történet arról szól, hogy az emberi szem (jórészt függőleges) igazító vonalakat keres, így van beállítva, fák az erdőben, slussz. Azok a dolgok amik egy falhoz vannak állítva, számára összetartoznak.

Az arányokkal is úgy vagyunk, hogy szeretjük, ha valami görbére illeszkednek. A twitteré a híres, de ha az elemek pont egyharmadai, egynegyedei valami másik elemnek, az is teljesen jó. Ne legyen véletlenszerű, az zavarja a szemet.

Ezt egyszerűsíti le az, hogy fogsz valamilyen egységet, ami lehet téglalap alakú is, de mindenesetre nagyobb, mint egy pixel, és gyártasz belőle valamilyen ritmus szerint dolgokat (mittomisén, az egység a képernyő szélességének 1/12-e, és van 3, 4, meg 6 egységes elem). Ez a grid, némi szünetjelekkel közbeiktatva. Az 1/1024 is grid valahol, de nem tudunk ekkora számokat kezelni.

A vizuális hierarchia az, hogy látod, mi tartozik össze mivel. Ha ránézel egy könyvre, vagy egy jobb tervező által csinált plakátra (svájci dizájnos link teli van vele), egyértelmű, mi hova tartozik, egyértelműek a szemednek a belépési pontok. A linkelt példákban az egyik srác az időpontokat, a másik az alcímeket tartotta fontosabbnak.

A vizuális hierarchia lényege, hogy a felhasználó:

1) ne tegye fel a kérdést az interfészre nézve, hogy "és én itt most ezzel mi a f.szt kezdjek"
2) ha valamit keres, nagyon jó tippjei legyenek arra nézve, hol találja a szemével

Az UI tervezési mintákat design patterneknek hívják éppúgy mint a programozásban, de picit más a hatásmechanizmusuk: programozásban explicit megtanulod, mi az az Observer, itt meg elég sok ilyen-olyan szerkezetet látsz ahhoz hogy automatikusan feltételezéseid legyenek a működésükről. Oldalai a Quince, a UI-patterns, a Patternry, könyvei az O'Reilly Designing Interfaces sorozata, a rád illő a "Designing Mobile Interfaces", 2011-es.

Az Androidnak van hivatalos pattern library-je by Google, meg hat rakás nem hivatalos (google: android patterns).

UX designer: konkrét appot így ingyen fórumon nem UX-elek (max ha opensource), pénzért... :)

Ó, ez nagyon tetszik. Igazából valami ilyesmit csináltam eddig is, csak teljesen szemmértékre (ez így nem néz ki jól, akkor még hegesszük egy kicsit, hogy jó legyen), de így leírva egészen van mögötte logika. Köszi szépen.

Nyilván, nem akartam, hogy az appunkat UX-eljed, gondolom a céges policy miatt nem is lenne rá lehetőség, épp elég amit belinkeltél.

Viszont belegondoltam abba, hogy nálunk hogyan készül egy form/panel, és igazából annyira nagy különbség nincs. Mivel a css-ben a méreteket képlettel tudom számíttatni, amit bemutattál, azt
teljesen ugyanígy meg tudnánk csinálni.

Oké, rendben, én csak ezt néztem:

E fölött van egy layout engine, a trükk az, hogy egy container méretét nem fixen határozzuk meg, hanem a layout-nak megfelelően. Pl. van olyan layout, ahol egy lista a bal felső sarokban 200x300 pixel 1024x768 felbontásban. Egy másik layoutban a lista a jobb alsó sarokban van, 400x530 pixel méretű 1024x768 felbontásban. Ezekre az anchor pontokra lehet az egyes containerek becsatolni, akik átveszik a szülő container méretét, és a benne lévő widget-ek méretét pedig globális változóból, és a container méretéből számoljuk. Ezt megint csak azért tudjuk megtenni, mert saját framework-ünk van.

Szerintem egyszerűbb azt mondani, hogy: tableteken ez az elem X oszlop széles, és Y sor magas (ahol az oszlop kb. a képernyő negyede-tizenkettede, a sor kb. negyede-nyolcada fekvőnél), a benne lévő elemek pedig egyenletesen vannak elosztva. Ha csak két oszlopnyi hely van, a következőképpen rendeződünk át:... Ha pedig sok oszlopos a felület, akkor legyen Y oszlop széles.

És persze egy elég általános frameworköt ennek biztos meg lehet feleltetni, csak a fenti nekem picit assembly-nek tűnik ehhez képest, pláne a rengeteg matekkal (nem jó ha egy layout-nyelv turing-teljes szerintem)

UI-tervezésre amúgy Axure-t vagy Fireworks-öt szokás (macen OmniGraffle), bár a héten nagyon reklámoztam a UXPin-t. Az ilyen oszloposdihoz kell egy rács (azt is gridnek hívják sok helyen), kell egy oszlopgrid, meg be kell tudni húzni vonalakat (ezt rendszerint a vonalzó mögül tudod).

De az igazán fontos, hogy a user az előtt kattintgassa a UI-t, mielőtt belenyomtatok volna kiscsillió forintot a kifejlesztésébe :)

Azon gondolkodtam, hogy mi a helyzet különböző felbontásoknál, nekünk ugyanis tényleg rengeteg nagyon furcsa felbontást kell támogatnunk, amik igazából monitor felbontások (1024x768 és 1920x1080 között sikerült vagy 10-12 különböző felbontású monitort találni).

Tehát, ha jól értem, akkor mondjuk első körben megpróbálhatjuk azt, hogy minden egyes képernyő felbontást ugyanúgy osztunk fel egy griddel, a különbség csak annyi, hogy egy cella mekkora lesz, és innentől kezdve a gridmérettel számolunk.

Viszont azt nem látom még, hogy nálunk tényleg dinamikus layout-ok vannak, tehát egy container az bármikor lehet lényegében bármekkora, tipikus példa erre az eventlista, aminél egy listában eseményeket sorolunk fel. Ha ez egy képernyős módban fut a programunk, akkor adott méretű (most hogy ez pixelben van direkt, vagy grid egységben, és abból lesz pixel számítva, az jelen esetben lényegtelen), viszont ha két monitor van, akkor lehet olyan megoldás, hogy az egyik képernyőn nem jelenítjük meg, viszont a másik képernyőnek meg mondjuk a 90%-át elfoglalja, aztán lehet egy olyan perspektíva (a perspektíva az lényegében egy olyan képernyő/layout, hogy 0. képernyő A layout, 1. képernyő B layout, stb.) ahol az első képernyőn nincs semmi, a második képernyőn pedig 20%-ban az eseménylista látszódik, meg közben még 3 másik panel...

Nem, itt az van, hogy breakpointokat határozol meg.

Mondok egy példát, legyen 3 breakpointod:

1) 1024 és 1280 között 8 hasáb
2) 1281 és 1440 közt 12 hasáb
3) 1440 felett 15 hasáb

A betűméret picit függ attól is, mennyi helyed van lefele, mert ugye te mondod, hogy scroll, az nincs, meg mondasz itt 16:9-es meg 4:3-as arányt is.

Ha ez ennyire átkonfigurálható, akkor valszeg átméretezhetőséget akarnak elsősorban, így kevésbé a hasábokra kéne koncentrálni (az erre annnyira nem jó), hanem hogy mennyi legyen a padding és a betűméret, és max alapból hasábra rakni, de felkészülni hogy ezt nyújtják / tömörítik.

Az a baj, hogy ide már nagyon kellenek a konkrétumok, és konkrétan meg kéne tervezni az appot szőröstül-bőröstül 2-3 képernyőméretre, és ebből visszafejteni a dizájnnyelvet, de ehhez meg meg kéne tudni, mi ez az app, milyen elemekkel dolgozik, kik és mire használják, hol (pl. milyen messziről nézik azt a monitort), szóval egy csomó tényező számításba jön.

Ennek a konkrétumok nélküli "programja" (dizájnban így hívják a ha ez tedd ezt ha az tedd azt rendszereket) viszont egy kisebb könyv lenne.

Amiket mondtam az nem web.

Nekem is volt amúgy (weben írt, de vállalati/intranet, kb. call center) app amihez ez kellett.

Kötelezően dual monitoros setupok vannak a cognolinknél, és azon varázsoltam, hogy tudnám megoldani, hogy egy adott információ a másik monitoron jelenjen meg, mindezt anélkül, hogy a felhasználónak configolni kéne. named window-k voltak asszem a megoldások végül (arról a chrome megjegyezte, hova nyissa).

szóval értem én a problémát, rendben, persze, de akkor se xinerama van, hogy egy nagy montorként kezelődnek, minden monitornak gondolom önmagában értelmezhetőnek kell lennie, ezért nem számít a több monitor az esetedben, az számít, hogy többféle részletességű nézetet szeretnének ugyanarról az infóról, viszont effektív a panelnek is reszponzívan kell gondolkoznia.

Tehát lehet az akármekkora felbontású monitor, elkezdi húzni a splitternél az egeret, és neked meg kell határozni a töréspontokat, hogy hol váltasz layoutot az adott panelre. Nem az adott képernyőre, az adott panelre. Tehát nem a képernyőd lesz reszponzív, hanem a panel. A képernyő mérete n-edleges, minden panelt gondolj külön képernyőnek gondolatban.

Lehet, hogy neki 1024x768-as monitora van,de csak 2 panelt akar rajt, de az is, hogy az 1920-ason akar egymás mellé 10-et.

Azon belül is meg fogja húzkodni az egyes elemeket, mert lehet hogy neki egy cellában olyan hosszú dolgok vannak hogy az még jó lenne ha egy picit hosszabb lenne.

Erre azt tudod mondani, hogy van a minimál hely, ami neked valamire kell, ez lehet hogy 0 (egy táblázat oszlopára, max nem látszik benne hogy mi van), és lehet mondjuk 100 egység (pt), és gondolatban van egy fizikai egységrendszered, ami a legkisebben 1 px, a legnagyobbon meg 2 vagy 4.

De ha maga a panel méret változik 2-3 hasábnyira, úgy már nem a tartalmat nyújtod benne, hanem layoutot váltasz, tehát megtervezed 100 px-re, megtervezed, hogy mi nyúljon ha 101-99pt és váltasz layoutot 200 pt-nél. Megint váltasz 400pt-nél, előtte nyújtasz. Megint váltasz 800pt-nél.

Igen, bár ez neked pont nem jó, mert középre igazít.

A töréspontok logikája viszont változatlan: vannak töréspontok és azok közt átmenetek. Ez épp csak a margót növeli, mások a hasábok szélességét.

Van, aki a betűméretet is piszkálja a töréspontok közt, más teljesen más layoutot ad, megint más csak annyit mond hogy "a legkisebb layout 4 hasábos, ezért semmi nem lehet 4 hasábnál szélesebb, de 12 hasábnál 3 lehet egymás mellett".

A régi desktop paradigma amúgy az volt (pl. adobe Photoshop régi verziói) hogy a töréspontok közt nem volt átmenet, photoshopnak volt 2 layoutja, és felbontásfüggően kínálta fel őket. Hogy mit csinált ha átirtad a rendszer-betűméretet, azt nem tudom.

Én a helyetekben továbbra is panelt terveznék, max a perspektívákban egész hasáboknál lenne panelszél.

Előbb-utóbb jöhet olyan ügyfél akinek kell az átméretezősdi, és nem lesztek meglőve :)

Persze ez csak vélemény, a "tudomány" lényegét szerintem már érted :) Nem egy Lovász-tétel, meg biztos lehet máshogy is, most ez a mainstream.