Category archives for "pixelbuzeráció"

Billentyűzetkombinációk megjelenítése írásban a helyes Unicode karakterekkel

Valamelyik nap szükségem volt a kurzormozgató nyilak elhelyezésére dokumentumokban, aztán rájöttem arra, hogy érdemes inkább összeszedni a “proper” Unicode karaktereket. Következő kérdés: több módosítóbillentyű lenyomásakor mi számít helyes (canonical) sorrendiségnek? Shift-Cmd-Opt vagy Opt-Cmd-Shift?

Ha megnyitjuk a System Preferences – Keyboard – Shortcuts menüben levő App Shortcuts szekciót és ott a + jelre kattintunk, tetszőleges billentyűzet parancsot kipróbálhatunk, ha belekattintunk a Keyboard Shortcut mezőbe.

Innen ugyan közvetlenül másolni nem tudunk, de ki tudjuk az ott megjelent karaktereket draggelni valahova. Szerencsére a canonical sorrend is helyesen jelenik meg, azaz: Ctrl-Opt-Shift-Cmd, vagy még másként ⌃⌥⇧⌘ Ha tehát egy billentyűzet kombinációt akarunk megjeleníteni írásban, helyesen járunk el, ha ebben a sorrendben írjuk a billentyűt, pontosan ugyanúgy, ahogy a keyboardon is szerepel, nagy betűvel, azaz például:

⌥⌘A

Bátorítanék mindenkit, hogy ezeket a karaktereket tegye a Character Viewer recent listába és amikor valakinek üzenetben billentyűzetkombinációkat kell írni, akkor a helyes canonical rendben, korrekt formában tegye.

Végeredményben összeszedve:

balra nyíl
jobbra nyíl
le nyíl
fel nyíl
Control
Option (gyarmatokon Alt)
Shift
Cmd
Caps Lock
Return (és nem Enter)
Enter (Macen fn-Return)
Enter (deprecated)
Backspace
Tab
Esc (ritkán használt)

mindez így néz ki egy rendes számítógépen

The Invisible Design Behind the Apple Watch’s Many Faces

Wired:

“We shot all this stuff,” Dye says, “the butterflies and the jellyfish and the flowers for the motion face, it’s all in-camera. And so the flowers were shot blooming over time. I think the longest one took us 285 hours, and over 24,000 shots.”

(…)

They built a tank in their studio, and shot a variety of species at 300 frames-per-second on incredibly high-end slow-motion Phantom cameras. Then they shrunk the resulting 4096 x 2304 images to fit the Watch’s screen, which is less than a tenth the size.

További pixel-gondok Yosemite alatt

Legutóbbi januári pixelbuzerációs posztomban már kiszúrtam egy éktelen foltot a Yosemite-ben. Ebben a posztban rámutatok egy újabb problémára, amit ha egyszer észrevettél, soha többet nem fogod nem észrevenni. Retinán fehér menüben ha wifi jelet keres a gép, így néz ki az animáció:

Látod? Nem? Itt van 400%-on a problémás animációs lépés:

Bizony-bizony. A fentről második behúzott csík ábrája sajnos blurry, nem pixel alignolt, pontatlan.

Pixelhibák Yosemite-ben

Grafit módban (1) retina kijelzőkön (2) jelentkezik az alábbi pontatlanság QuickTime Playerben (3):

A bal oldali bezáró gomb pontosan két pixellel került lejjebb, őrület csálé. Előjön gyorsan, ha hoverolunk rá. Csináltam is egy animgifet belőle. Ha egyszer megláttad, soha többet nem fogod tudni elfelejteni.

Hogyan kell tervezni iPhone 6 Plusra?

Azt kezdtem el megnézni, hogy egy iPhone 6 Plus layout tervezésének hogyan kell nekiállni? Az alapvető probléma onnan indult, hogy Sketchben felraktam az iPhone 4s-5s-6-6p artboardokat egymás mellé és ezt látom:

A 6 Plus az egyetlen nyilvánvaló kivétel, hiszen bitang nagy a többihez képest. De miért is ne lenne az, ha egyszer a szoftver 1242×2208 tényleges pixellel számol (3x), amiből az eszköz megjelenít végül 1080×1920 képpontot? A valóságban egyébként a következőképpen néz ki a méretbeli különbség:

Jól látszik, hogy a fizikai méretek között nincs ekkora különbség. Persze, mivel nem lehet összemérni őket, hiszen a 6-os 2x-ben, a 6 Plus 3x-ben gondolkodik. Jó ötlet lehet ezek után 2x-ben felrakni az artboardokat, hogy akkor hasonló arányokat lássunk.

Ez már alkalmas arra, hogy tervezzünk rá egy képernyőt, viszont ha erre rátesszük a valós méretet, látszik, hogy a valós méret (amit a kezünkben tartunk), nem az, ami a Sketchben 2x 6 Plusnál látható:

Ennek az okát nem fogom tudni levezetni, de szívesen látnék ezzel kapcsolatos pontosítást. Eleve onnan kezdődik, hogy a poszt fenti ábráján levő fizikai milliméter adatok nem pontosak (és nem is tudom, mik a pontos számok, ennél jobbat nem találtam). iPhone 6 esetén (58 mm)2 + (104 mm)2 = 14180, ellenben a derékszögű háromszög átfogója (120 mm)2 = 14400. Egyébként a fizikai pixelek aránya szépen kijön 16:9-re (0,5625), ugyanakkor a fenti milliméter adatok nem (0,5577). Photoshopban 58x104mm 326 PPI-vel 744×1335 pixelre jön ki a 750×1334-gyel szemben – pixel aspect ratio?

Feketével jelöltem be, hogy mekkora lesz a valóságos mérete – egy icipicit nagyobb. (Számításaim szerint 6,6%-kal.) Mit jelent ez a gyakorlati dizájnernek? Azt, hogy nyugodtan tervezzünk 2x-ben 6 Plusra, de legyünk tisztában azzal, hogy a fizikai, ténylegesen megjelenített méret a kézben picit nagyobb lesz. Ez azt jelenti, hogy egy ugyanakkora méretű felirat készüléken lemérve 6,6%-kal hosszabb és magasabb.

Próbaképpen Xcode Simulatorben is megnéztem azt, hogy az Apple mit alkalmaz design stratégiához, vagyis ők a tervezéskor milyen szabályokat követnek. Szerettem volna megtudni, az Apple hogy dizájnol 6 Plusra, milyen méreteket, arányokat tart, hogyan áll neki a kérdésnek.

Szeretném jelezni, hogy átnéztem az Apple iOS Human Interface Guidelines dokumentációját és ezzel kapcsolatosan konkrétan semmi információt nem találtam. Pedig ez szerintem egy teljesen tipikus hétköznapi kérdés bármelyik designer részéről. (Vagy mit néztem be, nem tudja valaki?)

A szimulátorban sajnos a 3x felbontás értelmezhetetlenül nagy, viszont nincs lehetőség 2x-re csökkenteni, a beépített kontrollok csak 75, vagy 50%-ra képesek. 3x-ről 2x-re menni pontosan 2/3-ra, vagyis 66,67%-ra kellene csökkenteni a méretet, ezért mit volt mit tenni, Photoshophoz nyúltam. A következő ábrán 1 másodperces késleltetéssel mutatom be, hogy az iPhone 4s / 5s / 6 és 6 Plus, manapság targetált iOS telefonméretek hogyan néznek ki pontosan egymásra téve:

Nagyon jól megfigyelhető, hogy az ikonok és szövegek maradnak ugyanolyan méretűek iPhone 6 Pluson is, csak az elhelyezkedésük változik a képernyőn, illetve ebben a példában a kis bélyegképek nőnek. Megnéztem egyébként rendesen és tökéletesen kiadják a méretek egymást.

Mindebből az következik, hogy nyugodtan tervezhetünk 2x-en (828×1472) ugyanakkora méretben, mint iPhone 4-5-6-ra, csak arra az artboardra kell szétdobálni az elemeket, végül pedig 3x-ben exportálni az asseteket.

Az iOS unlock animáció nyomában

Mindig is érdekelt, hogyan épül fel az unlock animáció effekt iOS lockscreenen. Egy epamos projektnél is előkerült a kérdés, itt vannak a megállapításaim.

Az effekt futásidőben számolt, hiszen a többnyelvűséget is kezeli. Azt is mindenki látja, hogy nem egyszerű fade-elés, mint a Facebook Shimmer effektje. Az az elképzelés is tévedés, hogy egy gyémánt maszkot húznak a betűkön. 60 kockánként másodpercenként persze olyasmi hatása van, de ha jobban megfigyeljük, látszik, hogy a betűk egyenként “olvadnak”:

Ha megnézzük részleteiben az animációnak egyes részleteit, látszik, hogy betűnként sem azonos az olvadás, hanem valami olyasmi, mintha folyékony, felhevített ércet öntenének valamilyen formába, még a betűk körvonalai között sem egyenletes az anyag eloszlása.

Azt látni lehet, hogy betűnként és betűnként más a kitöltés iránya, tehát nem egy maszk megy a betűkre, de ez alapján én nem tudom eldönteni, mi a fenti mechanizmus vagy hogyan lehetne reprodukálni a pontos effektet. Ha valakit érdekel, ide kiraktam az MP4 fájlt.

update: Jakab Kristóf készített egy egész jó implementációt. Nagyon ötletesen arra jutott, hogy két maszkot kell összekompozitálni, az egyiken maga a fade van, a másikon pedig turbulent noise.

Mac OS X Yosemite Under the Magnifying Glass

Ha tetszik ez:

Egészen biztosan tetszeni fog Min Ming Lo posztja a Yosemite-ről, ahol ehhez hasonló apróságokat, különbségeket mutat be a Mavericks/Yosemite között. Remek pixelbuzéria poszt úgy, ahogy van, tele hibátlan megfigyelésekkel, például a dropdown kék színezése:

My only complaint is that the drop down UI element has colored arrows. In every other instance besides this one, color is used to mean active or selected. Consistency would dictate that the drop down should not be colored either.

Yosemite legördülő szövegek elhelyezése

Bányai Zsolt tweetjében láttam az alábbi Yosemite screenshotot:

Nekem nagyon tetszik ez az új kinézet, ez az UI jól láthatóan az Apple flat az okosan megtalált inner- és drop shadow balanszolással elért, szerintem tökéletesnek mondható flat. Azt is érdekesnek találom, hogy folyamatában az Aqua-tól milyen útvonalon jutottak ide. OS-ről OS-re mindig csak elvettek és elvettek belőle. Ugyanakkor nem a végletekig, mert nem mondják azt, hogy a Yosemite flatban az UI elemek egyszínűek, hanem beállítják a megfelelő összhangot. Szerintem öröm lesz ezzel dolgozni.

Ugyanakkor csak engem zavar, hogy a legördülő menübe írt szövegek egy logikai pixellel lejjebb lógnak az ideálisnál? A képre ránézve az első gondolatom ez volt. Ha egy kicsit belenagyítunk és behúzunk egy vonalat egyből látható is:

Remélem javítani fogják a végleges kiadásig.

SVG logórajzolás

Nem mondom, remek szombati foglalatosság volt Chek eredeti logója alapján elkészíteni a Heti Meteor új website logóját SVG-ben. Én is most már abba a csoportba tartozom, akik, ha tehetik, SVG-ből építik a logókat, ikonográfiát és bizony CSS-ból színeznek, baromi klassz és szemantikus is az egész. A PNG-s élet már a múlté! Retinában 2x-et exportálni? Ikonfontok? MUHAHA!

A HM logófabrikálást leginkább XP gyűjtésnek fogtam fel, de az biztos, hogy rengeteget tanultam közben. Eleve két hete még fogalmam sem volt arról, hogy mi az az “Artboard”, meg arról sem, hogy azon belül hogyan van a koordinátarendszer és hogyan kell optikai pixelekre igazítani a dolgokat. Mindez már a múlté, kikóseroltam magamnak azt a workflow-t és tudást, amivel már neki tudok lendülni akár valamilyen éles projektnek is.

A legnagyobb szopás az volt, hogy egy névjegykártya (!) PDF-ből elkészítsem a pixel gridre igazított logót. Ez annyira apró és pepecs munka, hogy tényleg csak azért csináltam végig, mert ebből website-ot akarok kiélesíteni egy meg nem nevezett időpontban. Az összes rohadt anchor pontot kézzel igazítottam a gridre, vagy rajzoltam be (gyorsabb), de hazudnék, ha azt állítanám, hogy gyorsan ment, mert kb. háromszor kezdtem újra az egészet, mire kitaláltam, hogy kell hozzányúlni az anyaghoz.

A pixel gridre igazításnak más előnyei is vannak: mivel a koordinátáknak nincs tört részük, sokkal kompaktabb lesz az SVG állomány is végül. Arról nem is beszélve, hogy a teljeset újraépítve az ember sok felesleges dolgot tud összekombinálni, illetve kivágni, a layer csoportokat elnevezve pedig tényleg egy szemantikus objektum lesz a vége.

A végeredmény rétegei nálam így néztek ki:

A következő ábrán látszik, hogy miket csináltam. Felül az eredeti, alul az újrarajzolt árnyék:

Az “O” betű szélein az árnyékot, az “R” jobb alsó szárán az árnyékot és ugyanitt a hasán levő görbéket javítottam, illetve a betűben levő csíkot is kikövérítettem picit – no, nem nagyon, 6 optikai pixel egységesen. A felső ábrán látszik, hogy az “O” betű közepét nem négy anchorból rakja össze, hanem össze-vissza, mindenféle vegyes felvágottból keletkezik valami, ami nagyjából hasonlít az eredetire. Az alsó részen a tisztázott változat – minimális, pixel gridre igazított pontokból kirakva. A pixel gridből egy részlet:

A végeredmény logó mindösszesen egy 6 kilobyte-os szövegfájl az eredeti 20 kb-ossal szemben. A csillagok például ennyiből definiálhatók:

<g id="CSILLAGOK">
<polygon fill="#BD4A3E" points="824,171 832,144 811,129 837,127 847,103 857,127 883,129 860,144 870,171 847,156"/>
<polygon fill="#BD4A3E" points="570,171 578,144 557,129 583,127 593,103 603,127 629,129 606,144 616,171 593,156"/>
<polygon fill="#BD4A3E" points="318,171 326,144 305,129 331,127 341,103 351,127 377,129 354,144 364,171 341,156"/>
</g>

Ezek a számok nem mások, mint egész számú koordináták az 1140×560 logikai pixeles artboardon. Az SVG renderer nem csinál mást, mint berajzolja a pontokat, összeköti őket és kiszínezi a megadott színnel – hopp, csillag!

Akit érdekel, itt megtekintheti az eredeti, PDF-ből kibányászott szűz SVG logót, itt pedig a végeredmény, letisztázottat, amit majd fel fogunk használni a weblapon is. Az sem véletlen, hogy az egyik piciben jelenik meg, ott nincs rendesen beállítva az artboard, a másiknál viszont logikai pixelekre van pozícionálva minden. (Aki Illustratorben akarja megnyitni, jobban teszi, ha előbb egy üres dokumentumot erre az artboard méretre állít, különben nem lesz pixel griden az egész. Természetesen a Sketch-nek nincsenek ilyen problémái.)

Szemfülesek azt is érszrevehetik, hogy a “HETI” árnyéka más, mint az eredeti, hiába, azt is újraraktam layer effektekből, aztán kézzel behúztam magasabbra a türkiz rész szárait. Súlyos nördizmus volt az egész, viszont nem tudom, ti hogy vagytok ezzel, de én imádom tekergetni, forgatni a görbéket, míg összeáll egy koherens egységgé az egész.

Heti Meteor logó feldolgozás

A Heti Meteornak készül az új website-ja is. Modern megközelítésben már nem használok PNG-ket rajta, hanem SVG-ben lesznek a grafikák. A logó grafikáját ugyanakkor csak egy régi PDF-ből tudtam megfelelően source-olni. Chek ugyan kíváló munkát végzett, viszont a logó nincs letisztázva, láthatóan sok copy-paste réteg van benne, amiből nem lehet rendes SVG-t kihelyezni.

Eleve ott kezdődött a dolog, hogy a METEOR feliratra rakott drop shadow effekt nem megy át SVG exportkor, innen indult a teljes gondolkodási folyamat, expandoljuk ki az effekteket görbékké. Ez lesz az eredménye:

Sajnos ez értelmetlenül nagy méretű SVG deklarációt eredményezett, némi javulást értem el viszont a Pathfinder merge után:

Nem vagyok egy nagy Illustrator mágus, de a maradékot már nem tudtam automatizmussal megfixálni. Próbáltam több mindent, de olyan nincs, hogy ráeresztem és jó lesz. Sajnos kézzel kell az anchor pointokat javítgatni. Esetleg még annyit lehet, hogy a széleken levő pontokat könnyedén össze lehet rakni az “Average” funkcióval (tipp: Hosszú Zoltán, köszi), de ott is ésszel kell vele bánni.

Ugyanakkor, ha már így belementem a kézműves logó feldolgozásba, még pixel gridre is igazítottam az egészet a mellett természetesen, hogy a shape-eket megfixáltam. Például az “E” betű fehér részei külön shape-ek, viszont alatta a feketében is benne vannak a lyukak, mégpedig egy Compound maszkkal, ami nem lenne baj, csak ugye még egyszer ennyi információt eredményez az SVG-ben. Egyszóval felbontottam és kidobáltam az alsó maszkot, összeraktam az összetartozó dolgokat egy csoportba stb. – kézimunka.

Ez után jött a dolog érdemi része, a ganézás és a pixel gridre igazítás. Én erre nem tudok jobb módszert, mint az anchor pontonként egyesével igazítást. Még nem csináltam meg, de az “E” betűvel már készen vagyok. A következő ábrán az látszik, hogy Pixel Preview során mi a gridre igazított (jobbra) és a sima közti különbség (a jobb oldali betű is pixel grides értelemszerűen):

Az igazi különbség viszont a pontok számán látszik:

Végre eljutottunk a lényegi részhez, az SVG exporthoz. A fenti bal oldali, tehát a kezeletlen betűnek ugyanis így néz ki az exportált változata:

És itt jön a lényeg, az egésznek az bottom line-ja, az “E” betű pixel gridre igazított definíciója:

Nagyon fasza! És igen, én is látom, hogy az egyik pont az ábrán még nem tökéletes. 🙂 De majd az lesz. Annak is igaza van, aki szerint egyszerűbb lerakni ennyi anchor pontot kézzel. Lehet, hogy így fogok majd továbbhaladni, az egész élet egy nagy XP gyűjtő játék. A website holnapra nem készül el, szerintem 2015-ös indulás várható, ha ezzel a tempóval haladok.

Még egy badux: Instagram

Itt van ez a sokak által ismert Instagram nyitóképernyő (tekintsünk el a demonstrációs célzattal véletlen éppen elém került tartalomtól):

Ha valakinek, aki nem ismeri az appot, azt a kérdést tennénk fel, hogy az alsó ikonsoron mutasson rá arra az ikonra, ami azt jelöli, melyik képernyőn van, szerintem 10 emberből 10 a középső, világoskék ikont nevezné meg.

Ugyanakkor nézzük csak meg nagyobban:

A kis házikó alatt sötétebb lett a háttér (és az ikon is fehér)! Bizony, az az aktív elem, az Instagram app betöltésekor a kis házikón állunk. A középső gomb vélhetően csak azért világít, hogy az emberek megtalálják, hogy mivel kell új képet felrakni. Lehet érteni a gondolatokat? Lehet. Jó a megközelítés? Nem.

Skype UX kritika

Három nappal ezelőtt megjelent a Skype for Mac új változata. Az erről szóló blogposzt az alábbi mondattal indít:

Today we’ve released Skype for Mac, version 6.15. As with all our recent releases, we’ve focused on improving user experience and stability.

Igaz, hogy ez a Maces változat, ahol nincs általában egy elülső és hátsó kamera, viszont megszólítva érzem magam, és lenne is egy jó tippem a tisztelt Skype UX teamnek. iOS-en hívás közben az alábbi módon lehet kamerát váltani:

Nem tudom megérteni, miért így csinálják, ugyanis egyetlen gombbal kellene tudnunk forgatni a kamera képét, illetve, ha ki akarjuk kapcsolni a készüléket, akkor arra pedig kell egy külön gomb. És onnantól soha nem kell azon gondolkodni, hogy most az elülső, vagy a hátulsó kamera képét látom-e, és melyik menüpontot kell a kettő közül megnyomnom, hogy a másik kamerára váltsak.

BADUX.

Link crafting

A Google ugyan kidobta a találati listájából a link aláhúzásokat, viszont vannak még olyanok is a planétán, akik szeretik ezt a kimondatlan koncepciót is használni a link jelölésekhez. Marcin Wichary a Medium dizájnjában a link aláhúzásokat fogott neki megreformálni, hiszen mindenki tudja, hogy a Chrome durva vastag vonalakat alkalmaz a Safari szelídségével szemben. Sajnos a jelenlegi CSS-ben nincs lehetőségünk arra, hogy a link aláhúzásokat finomhangoljuk – bár megjelent már egy sor biztató kezdeményezés pontosan erre vonatkozóan.

Marcinnek egyébként ez lett volna a megfogalmazott benchmark célja:

Érdekes módon Macen a rendszer alapból ilyen linkeket készít, saját példám:

Ezt CSS-ben a text-decoration-skip property-vel (forrás) lehet egyébként elérni – csak sajnos semmilyen böngésző támogatás nincs még hozzá, így sajnos Safari 7.0.2-ben sem. A WebKit nightly buildekkel viszont úgy látom, hogy már megy a dolog, az ink típus használatával pontosan ezt tudjuk elérni, szintén saját példa a nightlyből:

De mi van akkor, ha már ma szeretnénk rendes, általunk szabályozott aláhúzott linkeket? Ezt a kérdést járja körül Marcin kezdve azzal a jól ismert technikával, hogy inline-block alsó borderét behúzzuk, de előjön egy csomó kérdés body-text kapcsán. Másik remek ötlet: a fontba rajzoljuk bele a frankó aláhúzásokat – de ez sem igazán jó. Aztán az overkill: canvas rajzolgatás némi JS element szélesség számolgatással karöltve. A megfejtést is elárulom: background gradient. Okosan lehet az elementre olyan gradientet rajzolni, amivel pontosan szabályozhatjuk, hogyan nézzen ki a vonalunk (ez ugye Marcinnek a fő problémája, nem a vonalak belógása), ráadásul a technika lekezeli a link töréseket is a paragrafusok végén.

A vonalak megtörésére Dustin Senos (szintén Medium) talált ki egy jó, de nem túl praktikus módszert: a text-shadow propertyvel ki tudjuk takarni a részeket, viszont ahhoz, hogy szépen is nézzen ki, több réteget is kell használnunk, ami meg oda vezet, hogy body textre teljesen alkalmatlan lesz, el is vetették a dolgot.

A Mediumon élesbe mentek az új linkek, de nem vezették be az aláhúzott link töréseket, csak a finomra hangolt vonalakat. CSS-ben mindez így néz ki, vagy élőben ugyanez:

background-image: linear-gradient(to bottom,#fff 50%,#666665 50%);
background-repeat: repeat-x;
background-size: 2px 2px;
background-position: 0 24px;

Erre jutottak végül a Mediumosok. Szerintem egyébként önmagában ez apróság, nem vezetném be. Sokkal jobb lenne, ha a megtört linkek működnének, de ez, ahogy látjuk, csak idő és böngészőtámogatás kérdése.

Végül ezt a gondolatot azért kiemelem még a Medium-os posztból:

Web design always seemed like this, too: finding convoluted, “dirty” solutions to often simple problems, using a very limited set of tools.