ugrás a tartalomhoz

Kattintás helyett érintés?

Joó Ádám · 2010. Már. 4. (Cs), 16.39
Amióta a grafikus felületek trónjától fosztották a terminált, azóta tekintjük a számítógépes interakció elengedhetetlen és legfontosabb módjának az egeret. Ez az, amit hamarosan elfelejthetünk.

Ahogy az iPhone rohamos terjedése megnyitotta az utat az érintőképernyős készülékek hétköznapivá válása előtt, a tradicionális alkalmazásinterakció úgy válik a múltévá.

Első ránézésre úgy vélhetnénk, a kérdés nem okoz gondot, hisz ami eddig az egérmutató volt, az most az ujjunk lesz. Azonban van egy lényeges különbség a kettő közt: az egérmutató folytonos jelenség, mindig van valahol, olyan nincs, hogy egyszer csak megszűnik létezni, majd egy teljesen más ponton ismét megjelenik. Az érintőfelületek ezen tulajdonságának hozadéka továbbá az áthaladás és a kattintás összemosódása. Az iPhone nem tud róla, ha én a levegőben egy elem fölé viszem az ujjam, ő csak azt érzi, ha megérintem.

Ennek folyományaképp az Apple fejlesztői kénytelenek voltak újraértelmezni a böngésző megszokott eseménymodelljét, melyről a Quirksmode-on olvashatunk: az interakció alapja a fókusz, melyet az érintés vált ki; ekkor alkalmazásra kerülnek a :hover stílusok, majd sorban végrehajtódnak a mouseover, mousemove, mousedown, mouseup és a click események. A következő fókuszáláskor a rendszer kiváltja az előző elem mouseout eseményét, majd eltávolítja a :hover stílusokat. Ugyancsak bizonytalanná válik a kettős kattintás, és értelmét veszti a jobbklikk, ahogy a képernyő billentyűzet is nehézkes beviteli eszköz.

Morgan Adams Flash-fejlesztő szerint épp ezen finom különbségek elvesztése a valódi oka annak, hogy az Apple nem támogatja a Flash-t legújabb üdvöskéjén, az iPaden. A legtöbb flashes alkalmazás, legyen az videólejátszó, játék vagy bármi egyéb, a végsőkig kihasználja az egér tulajdonságaiból fakadó gazdag interakciós lehetőségeket. Lévén, hogy a felület ezeket nem támogatja, emulációjuk pedig interakciós katasztrófa volna, így a cég a sok rossz közül a legkisebbet választotta, és úgy döntött, inkább egyáltalán ne jelenjenek meg a Flash tartalmak, minthogy szinte mindegyikük használhatatlanul jelenjen meg.

A Flash-fejlesztőknek tehát érdemes szem előtt tartaniuk ezeket a különbségeket, amennyiben szeretnék, hogy alkalmazásaik mobilon is használhatók maradjanak. Emellett azonban nekünk, hagyományos webalkalmazásokat fejlesztőknek is szolgál tanulságokkal a történet. A legdiverzebb platformra, a webre dolgozva sosem gondolkozhatunk kizárólag egy interakciós séma keretei között, ha minél szélesebb felhasználó réteghez kívánunk eljutni. Ahol csak lehet, kerüljük az egéresemények használatát fejlesztés során, vagy legalábbis nyújtsunk alternatívát. Ahol csak lehet, hagyatkozzunk a hagyományos hivatkozásokra és űrlapokra, hisz ezek mindenféleképp implementálva lesznek, legyen szó bármilyen környezetről.

Olvasóinkat kérdezzük, hányan és mit fejlesztenek mobilra, belefutottak-e már ezekbe a problémákba, hogyan látják maguk előtt a jövő webes ingterakcióját?
 
1

Egér érintéssel

vbence · 2010. Már. 4. (Cs), 18.58
Van már érintés-alapú interfész, ami emulálja az egér akcióit, kis hozzászokás után gondnélkül használható és minden laptopba be van építve :)
2

erőltetett a flashes magyarázat

zzrek · 2010. Már. 4. (Cs), 21.29
Szerintem erőltetett a magyarázat (feltételezés), miszerint ez lenne az oka, hogy az iPad nem támogatja a flasht, hiszen ettől még nagyon sok flashes alkalmazás mehetne szépen. Van sok más érintőképernyős eszköz, ahol nincs tiltva a flash, és ekkor legalább kiderül, ha a fejlesztő nem gondolt ilyesmire.
Szerintem két dolog hiányzhat: a hover(mouseover/out)-szerű események és a jobbklikk, ha valaki érintőképernyősre (is) tervez, ezeket kell mellőzni. Nem lehetetlen feladat úgy felépíteni a felületet, hogy csak klikk esemény van, hiszen pont a klikk esemény a leghasználhatóbb.
Én csináltam érintőképernyős terminálra webes alkalmazást, nem nehéz hozzászokni a korlátaihoz, ugyanis a hover-szerű eseményekre nem szokás komoly műveleteket indítani, a jobbklikk pedig eleve nem is elterjedt webes alkalmazásokban, így nem hiányzott egyik sem.
Azért várnám az olyan érintőképernyős megoldásokat, ahol érzékelik a felhasználó ujjának érintés nélküli elhaladását is, szerintem ez lesz a következő menő feature.
3

Total Commander

vbence · 2010. Már. 4. (Cs), 21.40
Had támogassam meg a hozzászólást egy példával: Total Commanderben a jobbklikk kijelölést jelent, de ha rajtafelejted az újad 2 másodpercig, akkor feljön a helyi menü. - Sok lehetőség van interakcióra, amik megfeleltethetők (akár egy átlátszó emulációs réteggel) a régi eseményeknek is.
4

Amikor a ReceptKioszkot

deejayy · 2010. Már. 8. (H), 09.47
Amikor a ReceptKioszkot fejlesztettük, pont ugyanezeken a problémákon mentünk keresztül :)
5

Kifejtenéd részletesebben?

Török Gábor · 2010. Már. 8. (H), 09.54
Kifejtenéd részletesebben? Így átfutva nem látok sok hasonlóságot a hivatkozott termék és egy webes felület érintőképernyős navigációja között.
6

Például a hover események

deejayy · 2010. Már. 17. (Sze), 19.56
Például a hover események hiánya, illetve gondolkodunk a klikkelésnél hangkiadással, etc. Meg persze előjött az is, hogy ha csak a klikk eseményre teszek "lenyomott" képet, akkor az gyakorlatilag meg sem jelenik (ezért a hover-re tettem, ami meg azt hozta magával, hogy az oldalújratöltés nélküli képernyőkön gyakran lenyomva marad a gomb - az ok egyelőre nem ismert)

Mert ugye a receptkioszk webes alapokon nyugszik.