Category archives for "ux"

Fira for OS X

Jens Kutilek újracsomagolta a Mozilla OS betűtípusát a Firát, hogy egy vonzó alternatívát kínáljon a Yosemite rendszerbetűjét, a Helveticát nem kedvelőknek.

Az általam ismert Maces, de mobil eszközök tekintetében egyébként vígan Androidozó ismerőseim, kapva kaptak az alkalmon és ugrottak rá a kérdésre. Szabó Gergő ráadásul linkel a munkáltatójának egy blog bejegyzésére, ahol Alissa Walker próbálja összeszedni a nagy designerek finnyogását az új rendszerbetű miatt.

Nem pontosan értem a kérdést, illetve a problémát.

Eleve úgy tűnik, mintha ezek az emberek még nem láttak volna iOS-t, ahol már egy ideje bevezetésre került a Helvetica Neue egy képernyőre optimalizált rendszerbetűje. Az Apple mindig is hírhedt volt arról, hogy mennyire odafigyel a tipográfiára, most miért lenne ez másképp?

Eleve egy olyan változattal szállítják az OS X-et, ami kis méretben is gyönyörűen néz ki. Aki nem hiszi, az gondolom nem nézi napi szinten a Findert, vagy nem nézi a Safarit. Én nézem mindkettőt. Teljesen értem, hogy miért jobb, mint ami volt. Mindez 1x képernyőn, ami még nagyobb kihívás. Talán retinán még szebb.

A másik dolog, amit nem értek: miért azzal kezdi mindenki az okoskodást, hogy nekiállnak kitalálni mi a rossz, amikor meg sem értették még azt, ami van?

1. Apple OS X Human Interface Guidelines
2. Apple UIKit User Interface Catalog
3. The iOS Design Guidelines

(A posztot nem erre akarom kanyarítani, de ismerem azt a gondolkodást, amikor a designerek azzal kezdik a munkát, hogy na, akkor válasszunk ki egy fontot. Ez nálam a zsírkrétával színezés prodzsekt. Csak egy kérdés: mi lenne, ha az Apple HIG-ben terveznénk meg a prototípusunkat, wireframe-ünket, kontrolljainkat, aztán később, ha ez már mondjuk szépen és konzisztensen működik, akkor kezdenénk el dolgozni a márkázáson?)

Az Apple a legelső iOS 7 bétájában vékony Helvetica Neuét használ bizonyos információk megjelenítéséhez. Akkora volt a felhasználói bepicsogás, hogy visszavettek és áttették boldba a sorokat (sőt, még tovább boldozhatunk a settingsből). Rémes döntésnek gondolom, azóta is, hogy hívok valakit, mindig a félkövéret látom:

Ha jól megnézzük, bizonyos screeneken nem állították át:

Sokkal elegánsabb.

De visszatérve a poszt eredeti felvetéséhez: mi a hozadéka annak, ha elkezdjük áthekizni a rendszerbetűt? Lerakunk egy statementet, hogy elégedetlenek vagyunk? Elkezdünk hozzá jobban érteni? Kifejezzük azt, hogy mi örök megjavítók vagyunk és most megvan a font? Androidon értem, hogy ez egyfajta mentalitás és hozzáállásbeli dolog, hack forever.

Rengeteget foglalkoztam 10 éve én is hasonló dolgokkal. És tudjátok mi van? Minden esetben, amikor bárki másnak a számítógépét nézem, újra ugyanaz az idegenkedés. Az összes privát beállításom durván a képembe röhög az első alkalommal, hogy bárki gépe elé leülök, vagy a Mac boltban odamegyek megnézni egy új Macet.

Logikailag azt meg végképp nem értem, hogy valaki Macet használ, Androiddal és a Macre felrak egy Firefox rendszerbetűt. Ez olyan, mint a paradicsomleves krémessel összekeverve: gyomorforgató.

Meng To Budapesten, csütörtökön (Sketch és Swift)

Annak, aki már használja a Sketchet, egészen biztosan nem kell bemutatni Meng Tót, a Sketch bullish prófétáját. Meng To most csütörtökön Budapesten fog két óra workshopot tartani azon designereknek és ux-szel foglalkozóknak, akik már megtértek (vagy épp ellenkezőleg: megtérni vágynak).

Budapest Mobile Meetup:

Első óra: Sketch + iOS8 + App prototyping
Második óra: Coding in Swift

Írt egy 50 dolláros eBookot is a Sketch/Swift app developmentről (illetve ehhez egy nagyon jó Sketch teaser oldal), gondolom ebbe lesz valamiféle bevezető is a meetup, de annak, aki ismerte volna a könyvét, szintén hasznos lehet a dolog. Illetve nagyon remélem, hogy az lesz, de ha másért nem, hát azért, hogy prezentáció közben lássuk az embert, illetve hasonszőrűekkel üljünk egy légtérben.

Én egyébként elkezdtem megnézni az ausztrál Marc Edwards (Bjango) 1 órás prezentációját arról, hogyan lehet hasonló workflow-t a Photoshop UI fejlesztőként használni, de csak 30 percet bírtam. Sajnos nem nagyon szólt másról, mint arról, hogy aki ott akarna ragadni az Adobe vonalon, hogyan tudja vektorra idomítani és vektoros UI tervezésre használni a Photoshopot. Viszont végig az volt az érzésem, hogy a Bjangós posztokat kapjuk vissza picit koherensebb formában.

De visszatérve Meng Tóra: vajon aki őt követi az is a posztjait és az eBookját fogja visszakapni koherensebb formában? Csütörtökön kiderül. (Én oda megyek Interstellar OV vetítés helyet, Interstellarra pénteken megyek a feleségemmel.)

Dotgrid books & notepads for UI/UX designers

Minden interface tervező munkás meg nem fogalmazott nedves álma a meetingre bevihető dot grid notebook – http://dotgrid.co Papírt is lehet külön vásárolni. 5 ezer forint + szállítás egy notebook, de én itt a Corvinban levő írószerben is láttam brand notebookot ennél drágábban. Angol cég, szállítanak természetesen Magyarországra is.

Photoshop CC: Live Shape Properties ablak előcsalogatása

update: lentiek a Photoshop CC régi verziójára érvényesek, az új, CC 2014.2 már nem tartalmazza a lenti hibát.

Az Adobe Photoshop CC egyik újítása volt, hogy a lekerekített téglalapokon akár sarkonként külön-külön is állíthatjuk a kerekítés mértékét. Hasznos dolog, viszont ha lerakunk egy ilyen shape-et és elkattintunk máshova, a “Live Shape Properties” ablak látszólag örökre eltűnik (14.2-ig nézem). Így konkrétan ezt az ablakot nem lehet visszahozni, helyette a “Properties” ablak jön csak föl, ami teljesen semmitmondó:

A trükk: hozzuk elő a Properties ablakot, aztán a Path, vagy Direct Selection Toollal (A) kattintsunk rá a shape-re, onnantól már átfordul az ablak a live shape nézetre:

Szívem szerint ezt is az “igen rossz UX” kategóriába tenném be, nem is tudom, mennyit kísérleteztem a Shape-ek körül nézelődni, hogy megtaláljam, hogyan jön ez vissza. Persze, utólag ez is triviális. Én azért adnék UI opciót is erre, értem azt a részt, hogy nem minden kijelölt objektum lehet live shape, de akkor is minimum ki lehetne szürkíteni és odaírni, hogy legalább olyan layerre állj előtte. (Haver.)

A legnyomorultabb trackback spam, a legnyomorultabb UX

Mutatok egy frisset:

Kommenteket és trackbackeket nem elég kikapcsolni WordPressben globálisan, az egyedi lapoknak külön állítható a comment/trackback része, ráadásul úgy eldugták, hogy nehéz megtalálni. Akinek hasonló problémája lenne, így tudja kikapcsolni a dolgot: “Pages – Edit”. És most jön a lényeg. A képernyő jobb felső részén van egy “Screen Options” nevű lenyíló. Nyissuk le. Ebben be kell kapcsolni azt, hogy “Discussion”, utána elmenteni az oldalt, majd újratöltés után legördíteni a poszt alá, ott megjelenik a “Discussion” rész “Allow comments” és “Allow trackbacks and pingbacks on this page” opciókkal, ezeket kapcsoljuk ki, aztán mentés újra.

Ez az a User Experience, amit esettanulmányban lehetne tanítani a web designer egyetemeken, mint rossz tervezési példát. Tökéletesen demonstrálja, hogyan kell valamit úgy eldugni és olyan logikát rakni mögé, amit egészen biztosan nem fog megtalálni senki. Én eleve azt vártam volna, hogy a “Discussion” részt kikapcsolva eltűnik a kommentelési lehetőség arról a lapról.

Minden, a legelvetümeltebb UI-ok is logikusak és érthetőek – utólag. A WordPressnél úgy gondolták, hogy én ugyanúgy tisztában vagyok vele, mint ők, hogy a “Screen Options” azt jelenti, hogy “Mutasd meg azokat a dolgokat a szerkesztőfelületen, amiket ki lehet még rakni, de alapból nincsenek ott!”, utána azon belül a “Discussion” pedig azt jelenti, hogy “A discussionnel kapcsolatos opciókat rakjuk ki a poszt szerkesztő alá!” Logikus – persze. De sokkal logikusabb lenne, ha azt írnák: “Show Discussion Options”.

Eleve nézzük meg az automatán küldött emailt. Nem oda kéne eleve egy opció, amivel egyből ki lehetne kapcsolni azt, hogy erre az oldalra jöhessen további komment és trackback? Pedig nem lenne túl bonyolult észrevenni, hogy ha globálisan kinyomom a discussion lehetőséget, akkor nem feltétlen akarok visszajelzéseket semmilyen formában.

Én egyébként eleve a problémát oldanám meg másképp. Eleve 2014-ben trackback ebben a formában? SRSLY?

update: a magyar WordPress is megszólalt a témában, de a reakciójuk, hogy MySQL-ben durrantsak el egy query-t, illetve a fentiek az én “saját hülyeségem”, tökéletesen mutatja azt, hogy mennyire rossz a felhasználói élmény ebben a szoftverben.

Apple Watch transitional interface

(klikk a kép közepére és indul a videó)

Ez az egyik legszebb dolog, amit az utóbbi időben láttam. Tényleg gyönyörű. Kedvem lenne olyan toolt fejleszteni, amivel két interface között lehet ilyen tranzíciókat készíteni. Eleve automatán megcsinálja, de kézzel lehetőség van egyik UI elemet átmappelni egy másikra. Jópofa dolog lenne. És ez az irány, nem a crossfade, meg a slide. Ugyanakkor nem szabad túlzásba sem vinni, hanem ennyire, és pontosan ennyire, visszafogottan érdemes csak csinálni, különben ez is elszáll a gagyi holdra, de olyan gyorsan, hogy az ember észre sem veszi.

/via @kollinz

Kell-e a natív UI?

Nem sűrűn használom a Google Mapset, de most Budapesten viszonylag sokat közlekedem közösségben és a tervezéshez a Google Mapset veszem elő. Ha rákeresünk valamire és kiválasztunk egy útvonalat, akkor kerülünk erre a képernyőre. Nekem sok problémát okozott az, hogy rájöjjek, hogyan lehet erről a képernyőről eljutni oda (vagy olyat csinálni), ahol választani tudok a felkínált útvonalak közül.

A hamburgermenüt próbálgattam, tappintottam a képernyőn több helyre is, de semmi. Itt állok ilyen idősen, napi rendszerességű gépnyomóként, mégsem tudtam rájönni. Esküszöm, nem sikerült megfejtenem. Pontosan olyan frusztrációm volt, mint Uj Péternek a Telenor honlapján hat éve:

Mi a megfejtés? Jobbra-balra kell az alsó kártyát tologatni. Persze, így utólag tök egyértelmű. Csak épphogy én nyomogatni próbáltam (arra a részletező jön föl). Egyébként amikor kerestem, megpróbáltam értelmesen közelíteni a kérdéshez és átnéztem, van-e bármi vizuális kulcs hozzá, de nincs. Valamelyik podcastben hallottam, hogy fontosabb navigációs sémákra gesztusokat tenni öngól. Szerintem itt is az történt, és van egy olyan érzésem, hogy ha nekem nem ment, sokaknak nem megy.

Egyébként itt jön be az, hogy a Google a saját UI elképzeléseit egy az egyben portolja iOS-re és egyáltalán nem foglalkozik azzal, hogy ami akár Androidon teljesen egyértelmű, az az Apple platformon nem feltétlenül az. Amennyire én tudom, az Apple szoftvereiben nincs olyan navigáció, amit csak gesztusvezérelve lehet elérni és én teljes mértékben ehhez is vagyok hozzászokva.

Nem tudom, milyen ötlet az, hogy a szoftverünknek asszimilálódnia kellene a gazda felület szokásaihoz. Tudom, hogy ez extra fejlesztési munkát igényel és nem is mindig értelmezhető. Ettől függetlenül ha a usereket rakjuk a saját márkánk elé (HALLÓ), akkor így kellene csinálnunk.

X a bezárás

Teljesen nyilvánvaló, hogy ma egy ablakon elhelyezett X szimbólum az ablak bezárását jelenti. De vajon mikor terjedt el ez a GUI tervezésben? Windows 1.0? Tévedés! Windows 2.0? Nope. 3.0? Still not! Sőt, még a Windows 95-ben is csak a fejlesztés vége felé jelent meg! Íme egy screenshot egy 1993-as bétából:

No, akkor biztos a Mac hozta be először az X close szimbólumot. Nem nyert. Sőt, a Linux is csak kb. a Win95-tel egy időben kezdte használni. De még a minden GUI ősanyja Xerox felületén sem találjuk meg. De akkor hol jelent meg mégis először? Hát kérem, a legelső X, mint close szimbólum, az 1985-ös Atari TOS-ben jelent meg először.

És hogy miért pont X lett a close? Természetesen a japán kultúrához kell visszanyúlni, ahol az X és O nagyon is jelentéssel bírnak. Lauren Archer, aki a kérdést egy nagy posztban fejti ki, ezt írja:

Batsu (x) is the symbol for incorrect, and can represent false, bad, wrong or attack, while maru (o) means correct, true, good, whole, or something precious. Batsu and maru are also common hand gestures. Cross your arms over your chest for batsu, circle your arms over your head for maru.

Mikor van holnap?

Tegnap este 11 óra után László az alábbi üzenetet küldte nekem:

Gyerekes férfiemberként hullafáradtan korán fekszem, az üzenetet csak ma reggel olvastam el. Érdekes, hogy az iOS 7 kinézi belőle a relatív dátumot és felajánlja, hogy készít belőle naptárbejegyzést. Igen ám, csak hova. Eleve én is csak a küldési dátum alapján tudtam beazonosítani, hogy egy este 11-kor küldött “holnap tudok jönni” típusú üzenet a mai napra vonatkozik.

Az iOS 7-en attól függően, mikor koppintjuk meg a feliratot, akarna létrehozni a koppintáshoz képesti időpontra egy bejegyzést. Tehát a 29-én 11 órakor elküldött bejegyzésre 30-án koppintva 31-re készítené a rekordot.

Pedig nem logikus, figyelembe kellene vennie a küldő időpontját, hiszen ő egészen biztosan az üzenet küldésének időpontjához képest értette (ha meg nem, akkor az nem lehet a szoftver problémája).

Ez a fenti kérdés nem grafikai, de design kérdés. Itt lehet még elmondani azt a Steve Jobs idézetet, hogy “Design is not just what it looks like and feels like. Design is how it works.”

Material Design Keynote-ban felépítve

Andrew Haskin kimaxolja a Keynote-ot:

Azt írja róla, hogy teljesen Keynote-ban építette fel, de a szinkronizációt már FCPX-ben csinálta. Még érdekesebb a dologban, hogy bárki letöltheti magának a keynote fájlt (link itt) és kedvére tanulmányozhatja a megoldást. Néhány kulcs gondolat:

It’s easy to learn and use, swapping assets is a breeze (using media placeholder), and most complex animations can be tested with Magic Move (the secret sauce to it all).

Transitional interface prototype toolnak a Keynote ilyen csodálatos lenne? Nem kell megvárnunk a Pixate-et? Akárhogy is, remek munka!

/via @hh

Design Details: Path for iOS

Brian Lovin tekinti át a Path iOS appjának finomságait a product sorozatának keretén belül. Minden részlethez apró videót is mellékel, hogy pontosan láthassuk működés közben is a dolgot. Hihetetlen fantasztikus app a Path (magyar ejtésnek szerintem jó lesz a pát, az eredetit lehet angolul meg amerikaiul is mondani), nincs fenn a telefonomon, nem ismertem ebből a szögből, de remek az UI szög. A Path designerei egyébként az alapító Dustin Mierau, illetve Ed Kim (ő még az Apple-nél is lenyomott egy kört).

Design for Realtime

Dominic Nguyen:

The internet is not a solitary experience. In 2014 we expect our apps to be connected and react to changes from multiple users’ actions. We want to feel as if our digital connections have a physical presence. This is where realtime technology shines.

Elég száraznak tűnő, de jó bevezetés a témába: a dinamikus működés megjelenésével a felhasználói felületen is le kell követnünk azt, hogy mi történik, honnan hova jutottunk el, mikor hova jön be valami új tartalmi elem, mi a rendszer állapota. Nguyen blogposztjában sok gyakorlati kérdésre ad választ és vezet be általános ismertetést, mindezt vizuális példákon keresztül. A poszt végén található Luke Wroblewski UX video playlistjét pedig elraktároztam megtekintés szempontjának érdekében történő későbbi visszatekintés céljára.

Bad UX: Apple Calendar

Ez a példa tipikus esete a vizualitás oltárán feláldozott UX-nek. Az Apple naptárát tervező emberek ugyanis úgy gondolták, hogy a “Today” feliratú gomb és a lapozó billentyűk indokolatlanul csúnyák az ablakban, ezért nem is kellenek oda egyáltalán. Ennek az az eredménye, hogy a mai napig nem tudom, hol keressem a gombot, amikor vissza kívánok ugrani arra a mai napra.

Aki esetleg azt gondolná, hogy “de-de, ez szépen látszik”, az valószínűleg beleesett abba a csapdába, hogy kiemeltem most az ablaknak az érdekes részét. Sajnos egy képernyőnyi méretű Calendar ablakon, ahol rengeteg hasonló méretű felirat van, teljességgel eltűnik a fenti funkciógomb. Egyébként érdekes módon gomb az, csak éppen a hoverre mutatja meg magát:

Én egyébként nem féltem volna felvinni a nap-hét-hónap-év nézetválasztó mellé, a címsorba felvinni ezt a három gombot, hiszen ugyanúgy a nézettel kapcsolatos funkciógombok azok is. (Ráadásul fontosnak is érzem, én is rengeteget használom.)

A másik rettenetes UX: a mai nap halvány rózsaszín a jelölése.

Hosszú másodperceken át szoktam keresgélni, hogy ma éppen melyik kockán állunk a héten. Különösen zavaró, ha a halvány szürkéskék hétvégét jelölő napra esik a mai nap, mert akkor tényleg egyáltalán nem lehet már látni. Elképzelésem sincs, hogy ezt miért engedték így ki, de a kezdetek óta Calendar felhasználójaként egészen nyugodtan állítom, hogy egyik döntés sem volt jó.

Szövegbevitel iOS-en

Az Apple jelenleg egy nagyító-féle megoldással teszi lehetővé, hogy a szöveg szerkesztése közben bizonyos pozíciókra ugorjunk. Ahhoz, hogy ezt a módot elérjük, hosszan meg kell érinteni a kijelzőt, megjelenik a nagyító, utána pedig az ujjunkat az üvegen tartva kell elhúznunk oda, ahova menni akarunk.

Nekem ami nagyon hiányzik iOS-ben, az a precíziós szövegbevitel. A használati eset tipikusan az, hogy észreveszünk egy elütést, aztán a gépelési sebesség szempontjából körülményes módon kell egy-két karakterpozíciót módosítani a nagyítóval.

Mi lenne, ha a szövegbeviteli mezőre bárhol koppintással azonnal odaállna valahova a beviteli pont, aztán egy egyszerű megoldással tudnánk ahhoz képest módosítani? A fő gond ugyanis az, hogy a koppintás maga nem pontos, viszont ahhoz képest kell csak aprót változtatni.

Most úgy működik, hogy a szövegbevitelre koppintva csak a menü jön föl: kijelölés, összes kijelölés, beillesztés.

Én a következő képpen változtatnám ezt meg: koppintással a beviteli pontot tesszük le, amelyik pozícióra éppen regisztrálódott a koppintás. Utána viszont az ujjunkat a kijelzőn hagyva jobbra-balra csúszással (pontosan úgy, mint a nagyító esetén) vihetnénk előre hátra a beviteli pontot. A nagyítót nem hagynám benne, hanem bevinném a “Kisegítő lehetőségek” alá opciónak.

Ez így rendben is lenne, de mi történne a kijelölés/beillesztés menüponttal? Ezt a menüt a szövegbeviteli mezőn hosszú koppintással lehetne elérni. Azért is jobb lenne így, mert a nem annyira hozzáértőket folyamatosan megzavarja az, hogy belenyomnak valahová, aztán mindenféle menük jelennek meg. A hosszú koppintást valóban tanulni kellene, de összességében még mindig a legkisebb rossz lenne.