#8 Czego designerzy nie wiedzą o frontendzie? Mariusz Heyda i Michał Mazur
W ósmym odcinku ITeracji Mariusz Heyda (Senior Frontend Developer) i Michał Mazur (Design Team Lead) poruszają temat współpracy designu i frontendu. Co Designer powinien wiedzieć o pracy developera, i vice versa? Jak zmieniała się ich praca na przestrzeni lat? Dlaczego tak ważne jest, by współpracowac ze sobą już na etapie projektowania? O tym, i więcej, posłuchasz w ITeracji. Sprawdź nasze otwarte pozycje: bit.ly/ELP-Careers Zapisz się do newslettera i nie przegap świeżych newsów ze świata IT: bit.ly/El-Digest Oglądaj nas na Youtube: https://youtu.be/OWhT4CvVe7M
Więc mimo, że potrzeby nie były wysokie, to roboty takiej ręcznej było sporo. No i gdybyśmy chcieli tamten stack narzędziowy przenieść do dzisiejszych czasów, do dzisiejszych potrzeb, gdzie mamy skomplikowane strony, pełno interakcji, gdzie mamy już skomplikowane produkty, czasami jakieś dashboardy biznesowe robimy, no to już tamte narzędzia by się teraz nie sprawdziły. Myślę, że bardzo by się nie sprawdziły. Szczególnie, że one nam pozwalały projektować Może uproszczę, ale raczej to się sprowadzało do jakichś prostych landingów, gdzie rzeczywiście nie było trzeba mieć, że tak powiem, tak jak teraz figmy mamy, oczywiście mamy jakiś design system, można sobie to przeklikać i to wszystko jest fajnie spójne. Kiedyś, jak tego oczywiście nie było, to wydaje mi się, oczywiście byłem designerem przez rok, ale nie nazywam się designerem, bo to były takie tam oczywiście zabawy, więc nie wyobrażam sobie, żeby w ogóle...
Tu jest 10 pikseli, tu jest 20, tu jest 30. Przecież pamiętam, że dało się wyklikać rzeczywiście w dany tekst i jak on jest zaznaczony, tam gdzieś odnaleźć rzeczywiście jaki to jest font. Tylko gorzej był problem, kiedy designer użył custom fontu, my go nie mieliśmy i nie mogliśmy tak łatwo kliknąć, nie? Więc to też była pewnego rodzaju Inaczej, mi się wydaje, że handoff designerski wtedy był jeszcze bardziej skomplikowany i utrudniony przez to właśnie, przez brak narzędzi, chociażby tak jak mówimy teraz Figma, czy inne rzeczy, gdzie jesteśmy w stanie to podejrzeć po prostu najeżdżając, klikając, no to jest dużo szybsze, tak, niż wchodzenie, przeklikanie warstw, jeszcze pamiętajmy, że Photoshop działa na warstwach. Więc czasem na jakieś warstwy były krycia. Maski jeszcze. Tak, i jak frontend chodził, musiał te przyklikać, te krycia, znaleźć coś, albo wyeksportować grafikę, która składała się z trzech jakichś grafik na overlay'u, to musiał sam to połączyć.
I też co ciekawe, w sumie tutaj można też wspomnieć elementy, bo po całe Google 2.0 jeszcze wracając, że sama praca nasza między nami designer-developer też stała się bardziej dynamiczna, bo też mamy takie rzeczy teraz w narzędziach jak Figma Tokens chociażby, gdzie rzeczywiście możemy Te wartości, spacingi czy kolory rzeczywiście możemy sobie między sobą wymieniać i jeżeli designer coś zmieni, to to się automatycznie odwzoruje też u nas, nie? Więc to są też fajne rzeczy, którymi się warto zainteresować, bo jakby nie patrzeć, tam dużo usprawnia samą pracę i samo chociażby trzymanie change logo, tak? Bo nie oczekujmy, że designer będzie nam co tydzień mówił, ej, zmieniłem kolor taki i taki, nie? No to też jest jakby nie patrzeć, zajmowanie czasu. A kiedy mamy takie narzędzia, to my musimy się o tym informować, bo my tak naprawdę widzimy to w systemie.
Loguję się, widzę, okej, coś się zmieniło, zaciągam zmiany, mam nowe kolejki, już mnie nic nie interesuje, wszystko się dzieje, nie? A to, że coś wygląda gorzej, no to taki był, że tak powiem, wizja designera, tak? Mi się może nie podobać, ale może dla kogoś to wyglądać lepiej, tak? Czyli nie tęsknisz za czasami, gdzie musiałeś wejść na współdzielony serwer? Gdzieś w sieci, znaleźć tam plik Photoshop, homepage Final Final Version 3 i potem czekać aż nowy plik się pojawi, wersja czwarta Final Final. Tak, gdzieś przez Google Drive przerzucane wersje, potem w ogóle, właśnie tak jak mówisz, Final Final V2, Final V3, takie nazywnictwo to też było, bo w sumie To co też ciekawe właśnie a propos tego Final Final, to też jakby nie patrzeć, my w dewelopmencie używamy systemu wersjonowania, więc design też na takie coś może sobie pozwolić, chyba z Figma, prawda?
Ale są aplikacje, które wiemy, że będą wielojęzyczne i Tutaj trzeba sobie nie tyle, nie jesteśmy w stanie tego dobrze zaprojektować, bo myśmy musieli zaprojektować każdy język, pokazać jak to się stawia, ale projektując, mamy narzędzia, chociażby w Figma czy coś, jak właśnie textbox, gdzie rzeczywiście możemy go zaznaczyć, pisać w nim, tak się nam będzie automatycznie mało, tak jak na stronie, a możemy sobie ten textbox rozciągnąć na pół strony i sobie wpisać, ustawić kursorem tak jak chcemy, tylko że potem jak deweloper ma to wdrażać, to on jakoś tak ładnie nie płamię, więc warto też właśnie pamiętać, żeby zostawiać sobie Tą strefę takiego bezpieczeństwa na multilanguage, może właśnie na to, że tak jak mówiliśmy, Web 2.0 content stał się dynamiczny, jest coraz więcej tego dynamicznego, ludzie wrzucają różne rzeczy, więc też warto właśnie, żeby te rzeczy, chociażby długości tytułów. Mamy bloga, piszemy bloga, na designie mamy jedną linijkę, dwie linijki, wygląda ładnie, ale klient...
Ok, to żeby też nie płynąć tutaj, nie wymieniać każdego propertisa CSS, to bardzo to upraszczając, myślę, że na pewno to, co mówiliśmy, floaty bym już w ogóle zerknął do lamusa, czyli wydaje mi się, że designer pewnie powinien się zainteresować flexboxem i gridem, zrobić sobie jakieś może ćwiczonko właśnie, żeby poznać, jak to działa. Myślę, że też a propos samych fontów, to też jest poniekąd CSS i to, jak się zachowuje font, tak jak mówiliśmy, ten ex-charakter, gdzie rzeczywiście line-hejty na webie będą troszkę inne, więc wydaje mi się, że też warto poznać to, jak się to zachowuje, jak się łamie, czym jest w ogóle na webie ten vertical rytm i jak to działa trochę inaczej jednak niż w Figma. I w sumie bym powiedział nawet, że to tyle z CSS-ów. Szczerze, nie wymagałbym wcale więcej niż to, jak się zachowuje layout, Ale na pewno bym zwrócił uwagę, jak designerzy robią, żeby zwracali szczególną uwagę na SVG, bo SVG lubią się mścić, szczególnie na Safari, lubią się mścić, jeżeli mają sobie clip-off niepotrzebny czy maski, więc to jest coś, co designerzy powinni na pewno zwrócić uwagę, jak taki SVG powinien wyglądać prawidłowy i starać się właśnie robić SVG
W miarę prosto, żeby nie zawierały tych niepotrzebnych mask, bo mi się wydaje, że większość da się zrobić, żeby nie zawierały te maski, tylko po prostu trzeba troszkę więcej się nakombinować, nie? Więc to raczej by było to. I co bym powiedział jeszcze już nawet nie sam CSS, to to, co mówiliśmy w sumie wcześniej, czyli żeby designer też jednak trochę się interesował tym, jakie mamy biblioteki dostępne właśnie, jakieś kalendarze czy coś, tak samo jak uważam, że front też powinien się interesować tym, Jakie są trendy w designie, żeby też chociażby coś wiedzieć, mieć jakiś chociażby minimum z miasta estetyki, żeby nie tworzyć Frankensteinów, tak? No i żeby też po prostu wiedział, jak się dane narzędzia używa, że wejdzie w Figma i wyklika w 5 second properties, a nie będzie tam klikał i szukał, co tam się w ogóle dzieje, nie? Ale no, mam nadzieję, że takich przypadków nie ma. Ale to bym na pewno spójrzył na takiego minimum.
I miałem taki case, gdzie właśnie klient bardzo, bardzo uparł się na to na stronie, żeby mieć zdjęcia na całą szerokość. I to nie były zdjęcia typu góry, tylko to były zdjęcia typu zdjęcia ludzi, które nie mogły być przykryte tekstem czy innymi tam elementami. No i tutaj rzeczywiście się musiałem nasiłować, żeby zrozumieć, w jakiej formie ten background tego elementu powinien być. Czy on powinien mieć wartość tam contain, cover... To też bym w sumie dodał. Objectivity na obrazkach, jak to się zachowuje. Chociaż wydaje mi się, że szczerze, designerzy używający Figma Się tego uczą, bo Figma działa. Figma ma też te ustawienia. Więc realnie wy jak projektujecie, to te ustawienia klikacie, tylko po prostu nie widzicie dokładnie tego kodu, bo on jest w tej innej zakładce Inspect, nie?
Ale mi się wydaje, że nawet używanie Figma i manipulowanie tymi wartościami już ci powoli naprowadza na to, jak rzeczywiście CSS działa, nie? I to jest taki dobry w ogóle... Uważam, że Figma, że jest idealny program do tego, żeby rzeczywiście pracować z drainerami i deweloperami, bo to jednak się zachowuje bardzo jak web, nie? To jest takie projektowanie... Grafiki w webie, nie? Takie klikanie. Tak, tak, tak. I coraz bardziej idzie w tą stronę. Może upraszczam bardzo, ale jak ja odbieram tą figmę, nie pracuję z nią na to, to dla mnie to jest takie coś, że klikam sobie w webie. Jeśli korzystasz rzeczywiście ze styli, z autolayoutów. Tak, autolayout przede wszystkim. Tak, to jest wtedy bardzo ważne. Ok, czyli to mamy tą część powiedzmy techniczną, na szybko powiedzmy w skrócie, natomiast ze strony procesowej jeszcze podsumujmy, co taki designer powinien też wiedzieć, szanować, robić ze strony procesowej i współpracy?
Opisane na górze, że to się tyczy Jira, to jest część tego user flow i patrząc na to, już z tego można było wywnioskować, że to po prostu jest zrozumiałe. Trzeba się domyślać, trzeba tylko wypytać, oprócz tego były jakieś karteczki na boku, więc jeżeli pytania by się pojawiły, to zostały od razu odpowiedziane, więc takie coś mi się wydaje, że też ten porządek, taka kultura odprowadzenia tego pliku jest istotna. I też bym szczerze powiedział w Figma, szczególnie, że Figma działa w browserze, a Chrome lubi sobie pożyć cały nasz RAM, to żeby rzeczywiście usuwać stare obrazki, stare pliki, bo to się potrafi też zemścić. Kiedy ja odpalam środowisko deweloperskie, odpalam Figma na jakimś gorszym kompie, no to potrafi się odpalić tam po prostu traktor. Tak, tak, może odlecieć laptop do sąsiada. Więc to też trzeba na pewno dbać o to, żeby nie zostawiać pozostałości, no bo to potem wpływa na to, jak ten plik nam się wczytuje, nie?
Pokazano wszystkie 10 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Mariusz Heyda i Michał Mazur przedstawiają się i opisują temat rozmowy, który dotyczy tego, co designerzy powinni wiedzieć o frontendzie.
Rozkłady prac nad projektami frontenda w przeszłości, zaczerpnięte z doświadczeń Mariusza Heydy.
Zmiany w narzędziach projektowania i technologiach frontenda, od Photoshopa do Figma, oraz wpływy technologii Web 2.0.
Opis technologii Flexbox i Grid oraz ich wpływu na projektowanie frontenda.
Problematyka współpracy między projektantami a deweloperami, w tym opis stanów i error handlingu.
Wspomnienie o problemach związanych z przekazywaniem wartości i kolory w projektach.
Rozmowa o znaczeniu projektowania user flow i multilanguage w projektach, a także o dokumentowaniu rozmiarów tekstu i typografii.
Porady dotyczące porządkowania projektów w Figma, dokumentacji i używania wewnętrznych narzędzi do dokumentacji.
Mariusz Heyda opowiada o swoim zboczeniu zawodowym i codziennych praktykach, takich jak optymalizacja czasu i robienie kilku rzeczy naraz.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
W ósmym odcinku ITeracji Mariusz Heyda (Senior Frontend Developer) i Michał Mazur (Design Team Lead) poruszają temat współpracy designu i frontendu.
Co Designer powinien wiedzieć o pracy developera, i vice versa? Jak zmieniała się ich praca na przestrzeni lat? Dlaczego tak ważne jest, by współpracowac ze sobą już na etapie projektowania? O tym, i więcej, posłuchasz w ITeracji.
Sprawdź nasze otwarte pozycje: bit.ly/ELP-Careers
Zapisz się do newslettera i nie przegap świeżych newsów ze świata IT: bit.ly/El-Digest
Oglądaj nas na Youtube: https://youtu.be/OWhT4CvVe7M