A tervező eszközök elfogynak a pályán. Így javíthatjuk őket.

Ritkán fordul el egy nap, amikor nem töltelek legalább egy kis időt a tervező eszközökkel gondolkodva. Néhány évvel ezelőtt építettem egy tervezőeszközt, amelyet a Marvel vásárolt meg. Ez több mint két évvel ezelőtt volt, de azóta a táj nem változott sokat, és a szenvedélyem sem volt a javítás iránt.

Nemrégiben tweetelt a tervező eszközökről - egy olyan dologról, amelyről ismert, hogy időről időre megtörténik.

Nem én voltam az egyetlen, aki azon a napon beszélt a fejemben, mások is becsaptak.

2017. július 28-án nem volt jó nap a tervező eszközök számára.

Ezekben a Twitter szálakban sok nagyszerű betekintés van eltemetve, de hosszú ideje akartam megragadni az időt, hogy mélyebben belemerüljek bele, mi az, ami szerintem annyira alapvetően megtört a jelenlegi tervező eszköz modelljében is utalásként arra az irányra, amelyről azt gondolom, hogy el kell indulnunk.

Mindannyian csak képeket rajzolunk. Ez őrült.

Szinte az összes népszerű tervezőeszköz exportálódik a képekbe. Ez számos okból problémás:

  1. Nem lehet kölcsönhatásba lépni egy képpel. A prototípuskészítő eszközök lehetővé teszik a képernyő átmenetek és az egyszerű interakciók hozzáadását a képekhez. Mivel azonban termékeink továbbra is igényelnek fejlettebb képernyő-átmeneteket és mikrointerakciókat, a képek egyszerűen nem tudnak lépést tartani.
  2. A képek nem folyékonyak. A reagáló tervezési döntések képeken keresztüli kommunikálása általában nehéz feladat.
  3. A képek nem állapotalapúak. A felhasználói felület különféle állapotainak hatékony kommunikációjához gyakran sok kép szükséges.
  4. A bittérképes képek felbontása függ. A retinaeszközök megjelenésekor a képek néha rosszul képesek lesznek.
  5. A képfájlok általában nehézek, és gyakran nehézkes tárolni, kezelni vagy megosztani.

Mindaddig, amíg a tervező eszközök tovább exportálják a képeket, soha nem lesznek képesek pontos ábrázolást készíteni termékeinkről. Ez a pontosság hiánya akadályozza a tervezők és a fejlesztők közötti kommunikációt. Mindaddig, amíg a tervezők továbbra is sajnálatos módon nem megfelelő adathordozót használnak munkájuk kommunikálásához, addig a munka mindig félreérthető lesz.

Ez egy nagyon jelentős pont, mivel lényegükben szinte minden tervezőeszköz átalakítja a vektor alakzatokat képekké. A Photoshop, az Illustrator, a Marvel, az Adobe XD, a Sketch és a Figma ebben a tekintetben azonosak. A képek azonban csak részben kommunikálhatnak a tervezési szándékkal. Mivel termékeink továbbra is alkalmazzák és támogatják az összetett interakciókat, a hangbemenetet, a videobemenetet, a kibővített valóságot, a virtuális valóságot, a hőmérsékletérzékenységet stb., Az ezen eszközök által biztosított érték gyorsan csökken. A kép alapú kialakítás zsákutca.

Tervezőeszközeinknek a tényleges termékkel kell manipulálniuk, nem annak képeivel.

Termékeink interaktívak. Szerszámunk statikus.

Ezt megérintettem az előző pontban, de ez szuper kritikus, ezért gondoltam, hogy kissé kidolgozom.

Gondoljon az egyszerű interakciók mennyiségére, amelyek szinte minden termékünkben gyakoriak, de a tervezési eszközökkel nem kommunikálhatók. Íme egy rövid lista a fejem tetejéről:

  • Lépjen a gombra
  • Bemenet fókuszálása
  • Jelölőnégyzet bejelölése
  • Lapok tartalma
  • Görgetési területek
  • Tab-index a fókuszált állapotokhoz
  • Gyorsbillentyűket

Persze, ezek közül néhányat utánozhatunk valamiféle hihetetlen mérnöki munkával, de csoda, hogy mi a lényeg a Földön? Miért nem tudnak a tervezők csak az eredeti terméket megtervezni ?! Végül az összes makett eldobható, a tervezők azonban hónapokig töltenek el, és tökéletesítésre készítik őket. Ez az idő sokkal jobb lenne a tényleges termék megjavításával.

Nem megyek túl messzire a „ha a tervezőket kódolnák” a nyúllyukon, de nem azt javaslom, hogy mindannyian írjunk kódot. Csak azt mondom, hogy nincs jó oka annak, hogy a mi tervezőeszközeink nem tudják támogatni az élő termékek közvetlen manipulálását.

A Framer jobb munkát végez, mint a legtöbb ebben az osztályban, támogatva a fejlett és részletes interakciókat. A csomag többi része nagyon messze van.

Eszközöknek támogatniuk kell a web elrendezési paradigmáját

Körülbelül egy évvel ezelőtt az elrendezések elkészítéséhez az interneten csak a képernyő: tábla és a függőleges igazítás CSS tulajdonságait lehetett felhasználni. Most megvan a Flexbox, és hamarosan CSS rács lesz. Ez a három elrendezésű motor nagyon hasonlóan működik, kihasználva a DOM áramlását. Szinte az összes weboldalt e három elrendezési rendszer egyikével készítik.

Tehát értelme van, hogy tervezőeszközeink ugyanazt az elrendezési modellt támogatják. Jobb?

Nos, szinte az összes tervező eszköz figyelmen kívül hagyja ezeket az elrendezési rendszereket, ehelyett úgy dönt, hogy az egyes rétegeket abszolút a rajztáblájába helyezi. Ez megnyit egy szakadékot a web működése és a tervezőeszközünk működése között, számos kérdést vezetve be:

  • A reagáló kialakítás nagyon nehézzé válik, mivel minden réteget manuálisan kell átrendezni minden törésponthoz. Alternatív megoldásként egy kényszer alapú elrendezési rendszer vezethető be, amely azonban összetettebbé teszi, meghosszabbítja a tanulási görbéket, és végső soron megakadályozza, hogy a fejlesztők az elrendezést közvetlenül a webről továbbítsák.
  • Mivel minden réteg kívül esik a dokumentum folyamatán, a tartalom kezelése bonyolult lesz. Például, ha egy elemet hozzá kíván adni egy listához, akkor manuálisan kell áthelyeznie a lista többi elemét. Természetesen a fájdalom enyhítésére be lehet vezetni az ismétlődő funkciókat és más képzeletbeli funkciókat, de ez ismét összetettebbé teszi és bonyolítja valamit, amelyet a DOM ingyenesen ad nekünk.
  • Az abszolút pozicionálás természetesen rögzített pixelkoordinátákhoz és méretekhez vezet. Ez rugalmatlanságot eredményez, és ismét óriási eltérés a web működésétől. A szövedék folyadék egységekre épül, például em, rem, vh, vw és%. Eszközünknek alapértelmezés szerint támogatnia kell ezeket az egységeket.

A tervezőeszközöknek nem kell, hogy hasonlítsanak vagy tükrözzék az internetet és annak árnyalatait - csak a webnek kell lenniük.

A monolit eszköz nem így van

A jó tervezés szakaszosan történik. A jól felépített tervezési rendszernek néhány különálló rétege van:

  1. Stíluspaletta Színek, árnyékok, távolság, szegély sugarak, betűtípusok, betűméret, animációk és egyéb stílusok gyűjteménye, amelyek a márka identitását alkotják. Jelenleg a legtöbb tervezőeszköz csak a színes palettákat támogatja. Mindaddig, amíg nem támogatják a többi stílus tulajdonságát, rendkívül munkaigényes lesz a szisztematikus tervezés.
  2. Eszközök Ez olyan elemeket foglal magában, mint ikonok, illusztrációk és képek. Van néhány fenomenális képszerkesztő, és a Figma vektor eszköze kiváló, de amikor SVG támogatást nyújtunk, a tervezőeszközünk nagyon sok kívánnivalót hagy.
  3. Alkatrész könyvtár Az összetevő stílusok és eszközök gyűjteménye, amely egyetlen elemre osztja az adatokat különféle variációkban. Ilyenek például a gombok, a bemenetek, a kitűzők stb. Mint már említettem, a Figma és a Sketch a közelmúltban kivonja ezt a folyamatot a fő rajzáramlástól - sajnálom, hogy csak alkatrészek képei, nem pedig tényleges alkatrészek.
  4. Modulok A modul / összetétel olyan összetevők gyűjteménye, amelyek adatokat szolgáltatnak az UI beágyazott darabjaihoz, különféle állapotokban. Példaként említheti a fejlécet, a fülmenüket, a bejelentkezési űrlapokat, a táblákat stb. Mivel a modulok csak összetett összetevők, azt hiszem, a Figma és a Sketch ezeket is kezelni tudja. Bár lehet, hogy érdemes megkülönböztetni a kettőt.
  5. Képernyők A képernyő modulok, összetevők és adatok gyűjteménye, amely egy teljes felhasználói felületet képez, amellyel a felhasználó interakcióba léphet.

A legtöbb tervezőeszköz olyan funkciókat kínál, amelyek legalább bizonyos mértékben támogatják a tervezési szakaszokat. A probléma az, hogy az összes szakasz egymással párhuzamos. Szinte az összes tervező eszköz csak egy módot kínál - a rajz módot. Készít egy rajztáblát, és csak elkezdi képeket rajzolni. Csak a közelmúltban vannak olyan eszközök, mint a Sketch és a Figma, kivont alkatrészek / szimbólumok, a fő rajzmódtól távol - ami furcsa, mert a front-end fejlesztés során az alkatrészeket már évek óta kivonják.

A stíluspaletta tervezése közben nem kell látnom rajztáblákat vagy vektor eszközöket. Szeretnék látni eszközöket a harmonikus színek megválasztására. Előre beállítást akarok olyan dolgokhoz, mint egy 8dp távolságmérő skála vagy a kiválasztott típusú skálák.

Ikon tervezéséhez egy teljesen más gondolkodási módra van szükség, mint a felhasználói folyamat tervezéséhez. Ideális lenne egy egyszerű SVG-szerkesztő, amely lehetővé tette számomra a natív SVG-téglalapok, körök, vonalak és útvonalak rajzolását, majd optimalizált SVG-kód exportálását.

Egy alkotóelem tervezése közben nem kellene többé az egyes stílusokra gondolkodnom - egyszerűen a stílusokat az előre meghatározott stíluspalettámból kellett választanom. Nem kezdhetek egyszerűen a stílusok finomítását egy komponensre, mert ez következetlenségeket vezetne be, és rontja a tervezőrendszer hatékonyságát. Amint a stíluspaletta a helyén van, csak a forrásnál lehet szerkeszteni.

Hasonlóképpen, egy modul összeállításakor csak az előre meghatározott összetevő könyvtárnak kell kitenni. Az oldalsávon nem lehet stílustulajdonságok. Nincs vektor eszköz. Csak egy újrafelhasználható komponensek könyvtára, amelyet átmozgathatom a modulok összeállításához.

Ugyanez vonatkozik a képernyők készítésére. Ezen a ponton csak az összetevőket és modulokat újrafelhasználjuk felhasználói felület létrehozásához. Nem a stílusokra vagy formákra, vagy más kreatív törekvésekre gondolunk. Elsősorban a tartalom és a felhasználói folyamatok tervezésére összpontosítunk.

A tervezési szakaszok mindegyike külön szerszámokban történhet, vagy csak ugyanazon szerszámon belül, különféle módokban. Nem hiszem, hogy nagyon fontos. Egy dolog biztos, bár a legtöbb jelenlegi tervezőeszköz nem ismeri el a folyamatot.

Szerszámainknak ösztönözniük kell a jó tervezést

A tervezőknek ez a ritka luxus, hogy végtelen számú egyedi stílust adnak a projekthez észrevehető következmények nélkül. Kell valamivel nagyobb betűméret? Csak döntsd fel. Nem nagy ügy. Szüksége van valamivel világosabb színre? Csak csípje be. Ez jó. Még több rajztáblát is létrehozhat ugyanabban a projektben, amelyek mindegyike kissé eltérő értékeket használ a hasonló stílusokhoz, és valószínűleg észrevétlenül marad.

A tervező eszköz soha nem fogja mondani, hogy nem tudsz csinálni valamit. Soha nem fog felhívni téged egy márkán kívüli szín használatára. Soha nem fogja megakadályozni, hogy olyan szóközt használjon, amely nem tartozik a térköz skálájába. Soha nem figyelmezteti Önt, hogy a népesség 20% ​​-a szó szerint nem látja azt a világosszürke szöveget, amelyet éppen készített.

És miért nem…? Mivel a tervező eszközöket nem érdekli.

A tervezőeszközök annyira lelkesedéssel látják el a korlátlan kreativitást, hogy elfelejtették, mit jelent az értelmes tervezés, a befogadóan történő tervezés, a szisztematikus tervezés.

Egyszerűen fogalmazva: a tervezőeszközök lehetővé teszik, hogy bármit meg is csináljunk, amit akarunk. Bizonyos mértékben hasznos ez a határtalan kreativitás szintje, különösen az ötletek szakaszában. UI tervezőkként azonban a munkafolyamatunk nagy része nem igényel nagy kreativitást. Ehelyett a munkafolyamat újrafelhasználást, ismétlést, ismereteket és szabványosítást igényel; arra van szükség, hogy szerszámaink kevés kielégítést nyújtsanak.

Ez a korlátlan szabadság ellentétes a webfejlesztés valóságával. Mivel a fejlesztők az aktuális termékkel dolgoznak, mind ugyanazzal a kóddal kell működniük. A fejlesztők nem egyszerűen hozzáadhatnak elszigetelt betűméretet vagy véletlenszerű színértékeket a kódbázishoz. Először: egy bélés (figyelmeztető üzenet, amely figyelmezteti a rosszul írt kódot) valószínűleg azonnal sikoltozni kezd. Ha nem, akkor valószínűleg feltartóztatják rossz ügyintézésüket a kód áttekintése során. Ha valahogy sikerült átcsúsznia a repedések között, akkor észrevehető teljesítményhatás hallani fogja a riasztást.

Az egyik leginkább zavaró probléma, amelyet a termékcsapatoknál látok, a tervezési és fejlesztési csapatok közötti kapcsolat. A fejlesztők évek óta szigorú iránymutatásokkal és korlátozásokkal dolgoznak. Hacsak a tervezőszerszámok nem fogadják el ezeket a korlátozásokat, a rés soha nem fog csökkenni.

Élő adatokkal kell terveznünk

Az élő adatokat bizonyos eszközökbe beépítették bizonyos mértékig, ami nagyszerű látni. Az Adobe XD rendelkezik néhány igazán ügyes funkcióval a hamis adatok előállításához, amelyek hasonlóak a jellemző élő adatokhoz. Az Invision Craft néhány remek élő adat szolgáltatást kínál a Sketch számára.

Az élő adatoknak azonban nem szabad megállniuk a szöveggel. Más elemek, például képek és videók, óriási hatással lehetnek a felhasználói élményre, ha jelentősen megnövelik a betöltési időket. Ha az interneten dolgozik, a böngésző fejlesztőeszközei lehetővé teszik a kapcsolat fojtását, hogy a különféle internetes sebességekre hasonlítson. Ezután láthatja első kézből, hogy egy új tartalom hogyan befolyásolhatja a felhasználói élményt.

Tervező eszközöink biztosítják-e ezeket a luxusokat?

Egyszóval: nem.

Minél közelebb kerülünk a tényleges termék megtervezéséhez, annál hasznosabb és hatásosabb lehet a tervezési munkánk.

Az internet nyitva van. Eszközünknek is meg kell lennie.

Az egyik igazán szép dolog az interneten a nyílt hozzáférhetőség. A webhely bármilyen böngészőben megtekinthető, szinte bármilyen eszközön.

Hogyan lehet összehasonlítani a tervező eszközökkel? Nos, néhány nappal ezelőtt David testvérem kért tőlem egy épülő alkalmazás tervezési áttekintését. Küldött nekem vázlat fájlt. Amikor kinyitottam, ez történt…

A legtöbb tervezési eszköz fallal körülvett kert. Ha egy kolléga a Photoshopban dolgozik, egy másik kolléga nem tudja megnyitni a projektet a Sketchben. Nem elég, ha az egész csapat ugyanazt az eszközt használja - nekik is ugyanazon eszköz verzióját kell használniuk.

A Marvel és a Figma itt jó munkát végeznek, ingyenes terveket és innovatív együttműködési funkciókat kínálva.

Szóval, mi a jövője a tervező eszközöknek?

Az innováció a formatervezési szerszámok területén rendkívül értékes, és a közelmúltban sok volt erről. Az Airbnb tervezőeszközeinél Jon Gold és Benjamin Wilkins a React-Sketchapp-on dolgoztak, amely elkészíti a React összetevőit, és ezeket Sketch-ben viszi tovább. Jon és Ben egy új, gondolkodásmódosító eszközön is dolgoznak, amely szalvétavázlatokat vesz fel, és ezeket valahogy React alkotóelemekké alakítja.

Adam Morse, Brent Jackson és John Otander egy sor eszközön dolgozik a Compositornál, amelyek alapvetően megoldják a cikk és az egész világ problémáit.

A Modulz-on dolgozom, egy új tervező eszközön és nyílt forráskódú tervező rendszeren, amelynek célja a cikkben említett problémák megoldása is. Ha érdekli, kövesse a Twitteren a frissítéseket.

Noha a szerszámkészítésben az innováció fontos, az igazi kihívás az oktatás. A tervező közösség egyszerűen nem áll készen a szisztematikus tervezési eszközre. Sok tervezőnek alig vagy egyáltalán nincs érdeke az épületrendszerek iránt. Egyeseknek a JPG a végcél - a Dribbble kedveli.

Valahogy ösztönöznünk kell az elszámoltathatóság kultúráját. A fejlesztők évek óta viselik az elszámoltathatóság kultúráját. Eszközük van a kód ellenőrzéséhez. Ha egy fejlesztő többször eltér a szigorú kódszabályoktól, akkor biztos lehet benne, hogy a problémát meg fogják oldani.

Időközben a tervezők gyakran teljesen összezavarják a rétegek hegyeit, kevés figyelmet fordítva a rétegek elnevezésére, csoportosítására és rendezésére. Nagyon sok a saját maguk számára. Mivel a bemenetet (vektorrétegek) a kimenetet (raszteres képet) nem befolyásolja, a tervezőknek nem lenne valódi terhe a megszervezés. A tervezők ezt a szerveződés hiányát gyakran azzal indokolják, hogy a tervezés művészetét romantikussá teszik, és bűvészekké festenek magukat, akiket a műsorukra bízni kell a fellépés érdekében.

Ösztönöznünk kell a befogadás kultúráját is. Aktívan el kell gátolnunk a visszaéléseket, például az ultra könnyű szöveges színeket, amelyek sok ember számára megnehezítik a szöveg olvashatóságát, vagy a szuper jó minőségű betűkészleteket, amelyek megkönnyítik a weboldalak betöltését, vagy mintázat nélküli felhasználói felület elemeket, amelyek megnehezítik a dolgokat a színvakok számára. Jelenleg az ilyen típusú jogellenes gyakorlatok a dizájn közösség körében tapsoltak. Ha üdvözöljük az intelligens tervezőeszközt, meg kell fordítanunk ezt a kultúrát.

Ha egy szisztematikus tervezési eszköz nyeri meg a szívünket, először oktatnia kell.