•  

    Dlaczego programiści traktują wyniki pracy projektantów jak sugestie? Mam wrażenie, że pracują z projektem na oko: niedokładne odwzorowanie kolorów, niezgadzające się odległości, ikony skądś, a nie z projektu itd. A nuż klient nie zauważy. Potem są oburzeni czepianiem się o takie szczegóły.

    #programowanie #frontend #praca #it #zalesie #projektowanie #ux #ui

    GIF

    źródło: cdn-images-1.medium.com (1.03MB)

    •  

      @Vitz: o ile niezgadzające się odległości, to czasami coś trudnego do przeskoczenia, szczególnie jak masz przygotować projekt i pod iPhone SE i pod iPhone XS Max. To są bardzo małe szanse aby tutaj i tutaj wyglądało 100% zgodnie z projektem :)
      Ale reszta, to pewnie z powodu lenistwa

    •  

      @Vitz: Bo program to kurwa narzędzie i wszelkie wodotryski są absolutnie kurwa zbędne. I inne rzeczy tego typu.

    •  

      @Vitz: jeśli programujesz korzystając z gotowych (lub głupio napisanych) bibliotek to często okazuje się, że zrobienie drobnych poprawek typu 3px szerokości zamiast 4px zamuje od cholery czasu a efekt jest żaden. Po 8 godzinach walki przychodzi PM a ty mu mówisz że zmieniłeś margines w trzech miejscach i poprawiłeś wycentrowanie jakiegoś przycisku - trochę przykre... Rozumiem, że godzi w psychikę grafika/ux'a, ale dla deva zwykle logika jest ważniejsza od wyglądu.

    •  

      @Vitz: bo jak im nie powiesz, że odległość ma być 2 piksele, a nie 3, to nie przyjdzie im do głowy mierzyć pod lupą, że jest 2 piksele a nie domyślne w środowisku 3.

      Takich drobiazgów które mogą być zmienione a nie muszą z wartości domyślnych jest mnóstwo, i programiści nie mają czasu ani ochoty bawić się w "znajdź 25 różnic między tymi obrazkami". Dlatego lepiej po prostu napisać "tam ma być 2 piksele" i "ten kolor to nie #ff0000 tylko #ff1122", jeśli to nie jest oczywiste.

      W końcu designer wie, co zmienił, czemu programista ma się domyślać i sprawdzać?

    •  

      @Vitz: skoro można zrobić coś łatwiej, spędzić nad tym mniej czas i jeszcze ktoś to klepnie, szkoda tylko że to mylne myślenie.

    •  

      @Vitz:
      Bo to nudne, nierozwijające, żmudne i upierdliwe. A klient i tak pięc razy zmieni swoje zdanie i będzie przesuwał tam i z powrotem. ( ͡° ͜ʖ ͡°)

    •  

      @Vitz: Bo UX'owcy bardzo często żyją w wyimaginowanym świecie gdzie ludzie wyświetlają strony w rodzielczości 3000px na 1800px ( ͡° ͜ʖ ͡°) I nie rozumieją że nie da się zachować sztywnych odstępów dla wszystkich rozmiarów ekranów

    •  

      @Vitz: u mnie czesto te rzeczy wynikaly z tego ze designerzy nie wiedza jak dzialaja strony i jak sa budowane.

      Nie moze byc np ten sam element, zalozmy jakis carousel slider na 3 roznych stronach, raz ma 7px marginesu, raz 12px a potem 13px, a calosc ma jeszcze byc kontrolowana przez CMS, po prostu sie nie da, a jak sie bedzie dalo, to sie takie hacki narobia ze potem nikt sie w tym nie polapie.

      Z Ikonami jest czesto tak, ze uzywa sie gotowych paczek z ikonami, np font-awesome i jak jedna czy dwie ikony nie pochodza od tej paczki to chuj, wezmie sie podobna, a jak designer chce jednak taka jak zadesignowal to powinien ja wyexportowac jako .svg czy tam .png i dostarczyc zipa (np exportowane svg w photoshopie sie psuja, trzeba uzywac innych narzedzi adobe, nie pamietam juz nazwy).

      Jezeli kolory maja sie zgadzac, to tez designer powinien dolaczyc palete kolorow, jak sa 2 kolory niemal identyczne to uznaje ze designer byl leniwy i chodzilo mu o ten sam kolor tylko sie pomylil.

      Ja sam nie mam problemow z projektami pixel-perfect i kilka takich wykonalem, z drobnymi zmianami, np font sie inaczej renderowal w photoshopie a inaczej na stronie wiec minimalne roznice byly, ale trzeba bylo porobic rowne marginesy np co 5px co 8px co 15px, a nie wartosci z dupy i w koncu znajdywalo sie kompromil, ze to dzialalo i wygladalo.

    •  

      @Vitz: a swoją drogą często jest tak, że część szczegółów na obrazku jest zamierzona i istotna, a część nie. I np. dostajesz obrazek z etykietką na buttonie lekko przesuniętą w lewo zamiast wycentrowaną. I zgaduj - czy tak ma być, czy to się ręka omskła designerowi. A może to nieistotne i ma być zachowanie systemowe, a ten button to tylko ma pokazywać, że mają być 3 buttony z takimi tekstami?

      Po samym obrazku się nie domyślisz - możesz zasypywać designera pytaniami, zgadywać, albo odbić piłęczkę i dostać zwrotkę. Różnica jest tylko taka - na kim wisi task.

      Popraw opisy tasków to będzie znacznie mniej takich problemów.

    •  

      @Vitz: to by była zajebista gierka na VR, taki pimpong gdzie po 2 stronie stoi "żywy" przeciwnik (czyli jakiś kinect czy coś byłby do tego potrzebny) i grałoby się przez neta
      #przemysleniazdupy

    •  

      @Vitz: To ja też dodam mądrość od siebie: Bo jak sobie nie ułożysz relacji z developerami to potem tak masz ¯\_(ツ)_/¯
      @laki1: UX powinien myśleć samemu, ale jak czegoś nie wie, albo nie pomyślał o jakimś przypadku - to trzeba wytłumaczyć. Taka to praca! Ja super współpracuję z developerami!! ( ͡° ͜ʖ ͡°) @tell_me_more: Dokładnie - trzeba wszystko ładnie opisać, a najlepiej dodatkowo się spotkać i omówić. U mnie każda makieta jest 100% przegadana z devem FE, często także BE - zanim cokolwiek pójdzie do biznesu! Jak czegoś nie wiem, to mi developerzy tłumaczą i na przyszłość już wiem i odwrotnie (⌐ ͡■ ͜ʖ ͡■)

    •  

      @to_znowu_ja: Nie mówię że wszyscy, ale po prostu pracowałem z ludźmi którzy traktowali zrobienie projektu strony jak namalowanie obrazka ;D

    •  

      @Vitz: Dlaczego projektanci traktują developerów jako prywatne środowisko testowe? Dlaczego ja mam odpalać photoshopa, żeby sprawdzić sobie odległość jednego przycisku od drugiego? Dlaczego ja mam pilnować, czy ten button na 100% ma wyglądać tak i mieć 2px wyższy font od innych? Wybacz, ale jeżeli projektanci mają w piździe jakąkolwiek dokumentacje swoje pracy i nie potrafią poprawnie używać takich narzędzi jak invision to niech giną.

    •  

      @Vitz: Jeżeli chodzi o #webdev to dlatego, że:
      - w dobie responsywności nikt nie robi już stron pixel-perfect,
      - czcionka, którą widzisz na projekcie nigdy nie wygląda tak samo wyrenderowana w przeglądarce...
      - ...poza tym w każdej wygląda inaczej,
      - graficy nie wiedzą, że to, że na projekcie każdy nagłówek mieści się w jednej linijce, a każdy element menu ma 5 znaków, nie ma przełożenia na świat rzeczywisty (ale klient dostaje projekt z jednolinijkowcami, bo ładna symetria więc większa szansa, że klepnie),
      - prądem jebać grafików, którzy korzystają z opcji mieszania warstw tam gdzie element ma być wycięty jako png z przezroczystością...

    •  

      @rimyi:<this

      Żeby jeszcze dawali tam admina, a nie że colorpickerem ciśniesz kolorki po pani ux wielce wkurzona ( ͡° ͜ʖ ͡°)

    •  

      @MientkiPajonk wystarczy ze projekt rzeczywiscie jest stworzony w tym invision a nie jest wyeksportowanym jpegiem z PSa, wtedy masz wszystkie kolory i odleglosci podane na tacy

    •  

      @Prism2772: już chrzanić te odległości, ale np. widzi jak powstaje projekt, ogląda go przez tygodnie - a potem mówi, że tego się nie da zrobić
      @inquis1t0r: tu nie chodzi o wodotryski, tylko o uszanowanie wyniku wielotygodniowej pracy projektanta i klienta. Potem klient płaci za coś czego tak naprawdę nie zaakceptował.
      @chotkos: rozumiem tę perspektywę
      @tell_me_more: od tego jest zeplin/inspect aby sobie to sprawdzili, inaczej projektant musi szukać tych 25 różnic
      @golia: to brak szacunku do pieniędzy klienta
      @Ragnarokk: i po to jest projektant, zeby klient potem nie przestawial w zakodowanej wersji
      @laki1: niby tak, ale projekt musi dobrze wyglądać na tablecie jak i na imacu
      @Melcma: zgoda, tu juz mowimy o braku konsekwencji projektanta, co do ikon - oczywistość, mówie tutaj o sytuacji gdy programista uzywa innej ikony bo taka akurat ma na pulpicie i nie widzi roznicy, a zmieniac nie chce bo wg niego jest okej
      @tell_me_more: ale wiesz, że programista może się zapytać jak ma wątpliwości
      @to_znowu_ja: jakis protip jak sobie te relacje ulozyc?
      @rimyi: wlasnie od tego jest zeplin/inspect - tam jest wszystko, co jesli programista się tego nie trzyma?
      @WaveCreator: zgadzam się, nie czepiam się, że font inaczej wygląda na safari, a inaczej w chrome - chodzi o uzycie np. regulara zamiast bolda, innego rozmiaru, innego koloru. Jak najbardziej trzeba przewidywać skrajne opcje, a nie tylko te ładnie wyglądajace na dribbble.

      +: chotkos
    •  

      @Vitz: u mnie mój były szef zespołu jak mówił, że czegoś nie da się zrobić, to głównie dlatego, że mu się nie chciało do tego siadać, mimo że to było jak najbardziej możliwe i to nie z jakimś niesamowicie wielkim wkładem pracy ;)

    •  

      i po to jest projektant, zeby klient potem nie przestawial w zakodowanej wersji

      @Vitz:
      W teorii tak. W praktyce - klient sam nie wie czego chce i zmienia wersję po paru tygodniach, miesiącach itd. Gdyby projekty działały jak w teorii że ustalonych rzeczy się nie zmienia to miałbyś zapewne słuszne pretensje. A tak to jeden rabin powie tak, drugi inaczej.

    •  

      @Ragnarokk: oczywiście, po oddaniu realizacji klient może to nawet skasować w pizdu, ale takie założenie sprawia, że ta praca w ogóle nie ma sensu ;)
      @Prism2772: generalnie to wszystko da się zrobić, kwestia czasu i budżetu ;)

    •  

      chodzi o uzycie np. regulara zamiast bolda, innego rozmiaru, innego koloru.
      @Vitz: A tego akurat się zawsze trzymam wg projektu - i to dosłownie, czyli jeśli w wytycznych H1 ma mieć zawsze kolor #333, ale grafik na jednym z projektów pierdolnął #000 to będzie tam #000 ( ͡° ͜ʖ ͡°) Zakładam, że profesjonalista wiedział co robi i nie zmienił koloru dla danego projektu bez powodu ( ͡° ͜ʖ ͡°)

    •  

      @WaveCreator: to się chwali ( ͡° ͜ʖ ͡°)

    •  

      @Vitz:
      Praca ma sens. Niezachwiane i konserwatywne pilnowanie detali już wg mnie mniej, choć oczywiście zależy od skali.

      Użytkownik końcowy i tak ma często w dupie takie rzeczy, jeśli jest treść której potrzebuje. Czyż siedzielibyśmy na tym rogalowym portalu w innym przypadku? Przecież niedoróbek czy niedorzeczności tu są setki, masz kurde 2FA omijane na mobilnych apkach, a jednak wciąż toczymy tu dyskusje i te merytoryczne i te o dupach maryny :)

    •  

      Bo program to kurwa narzędzie i wszelkie wodotryski są absolutnie kurwa zbędne. I inne rzeczy tego typu.

      @inquis1t0r:

      Line-spacing to nie wodotryski. Typografia bardzo mocno wpływa na odbiór strony/aplikacji/tesktu. Niestety bardzo często jest pomijana. Typografia to nie tylko ładne literki. Typografia to jedna z ważniejszych rzeczy w designie. To nie są bzdury wymyślone przez designerów, którzy mają za dużo wolnego czasu. Zasady typografii wynikają z matematyki (patrz: złoty podział), wynikają z tego jak ludzki mózg postrzega świat.

      Przykład z życia: https://www.gridlover.net/try
      Wejdź na tę stronę i wyłącz grida - tekst wygląda po prostu ładnie, chociaż nie ma tam żadnego designu - tylko literki i dobrze dobrana interlinia (wg złotego podziału). A teraz pobaw się suwakami i wklep jakąś losową wartość w line-height i scale-factor - zobaczysz, że wszystko zaczyna się psuć.

    •  

      @tell_me_more: od tego jest zeplin/inspect aby sobie to sprawdzili, inaczej projektant musi szukać tych 25 różnic

      @Vitz: projektant od tego jest, żeby zdecydować co ma się zmienić i jak dokładnie. To jego praca. Jeśli pisze taska tak, że nie ma pewności, co trzeba zrobić - to robota przeradza się w ping-ponga.

      ale wiesz, że programista może się zapytać jak ma wątpliwości

      Może i powinien. Ale wszystko w granicach rozsądku. Jeśli task jest tak napisany, że trzeba się pytać 20 razy, to to jest niedorobiony task i przerzucasz w nim swoją robotę na dewelopera, i w takiej sytuacji ping pong statusami w JIRA jest zrozumiały. Alternatywa jest taka, że ty wklejasz obrazek w 1h i masz zadanie "zrobione", a deweloper spędza cały dzień łażąc do Ciebie po szczegóły, i w JIRA widać, że spędził 8h na jakimś zadaniu kosmetycznym.

      Oczywiście, może być też tak, że deweloper bumeluje a task był napisany w porządku. Ale to raczej da się łatwo stwierdzić patrząc na tego taska.

      @tylkostrimi: odpowiadasz na copypastę :)

    •  

      jeśli programujesz korzystając z gotowych (lub głupio napisanych) bibliotek to często okazuje się, że zrobienie drobnych poprawek typu 3px szerokości zamiast 4px zamuje od cholery czasu a efekt jest żaden.

      @chotkos: O tak, dokładnie. Teraz poprawiam takiego ulepa w Silverlighcie (yup, dobrze widzicie, trup z szafy), gdzie padł zarzut, że pewna lista się nie odświeża automatycznie i kwii kwii bug. Stwierdziłem, że no dobra - może faktycznie powinna się odświeżać co te kilkanaście sekund, żeby zawsze była up to date. Ustawiłem event na odświeżanie i widziałem jak co jakiś czas lista się czyści do zera na jakąś sekundę (tyle trwało samo renderowanie niestety) i dopiero przerysowuje od nowa, bo tak jest krzywo zrobiony ten komponent jakoś. Nie da się tego używać, bo ktoś zaznaczy jakiś wiersz, będzie chciał z nim coś zrobić a po chwili mu się wyczyści, pomiga, cofnie zaznaczenie i ogólnie ugh.

      Zajrzałem do tego jak jest zrobiony ten komponent, bo to jakiś typ ręcznie rzeźbił, przeżegnałem się i poszedłem do testerów powiedzieć, że dotkniemy tego gówna tylko wtedy, gdy klient będzie BARDZO, BARDZO chciał aby to się odświeżało inaczej niż ręcznie (ta lista nie jest mocno strategiczna, ja osobiście nie odczułem niewygody z tym związanej) - bo musiałbym pogrzebać tam we flakach aby zmienić zachowanie odświeżania a to może po dotknięciu się tej stajni Augiasza zająć tydzień - i co gorsza może się w ogóle nie udać, bo się okaże, że rendering jakiegoś wewnętrznego komponentu z samego frameworka tak działa i chuj.

    •  

      ta lista nie jest mocno strategiczna, ja osobiście nie odczułem niewygody z tym związanej

      @Khaine: Pomijając ogólny przekaz tego co napisałeś, takie podejście dość nagminne wśród programistów. Jemu działa, jemu by nie przeszkadzało, jemu to nie potrzebne. Może dla użytkownika było to kluczowe, kto wie.

    •  

      @Vitz: Z tego co wiem, toto nie jest kluczowe właśnie. Dlatego zrzuciłem na dalszy plan, bo grzebanie w takim gównie może zająć dużo więcej niż to warte. Może się okazać, że powiemy "ta lista z przyczyn technicznych nie odświeża się sama, proszę sobie tutaj kliknąć jakby co" a klient odpowie "aha, ok" - i tyle będzie z tej historii.

      +: Vitz
    •  

      @Vitz: Z perspektywy Androida, żeby było idealnie zrobione to:

      - Proszę o projekt na urządzenia o różnych DPI (co najmniej 3 rozdzielczości) + tablet (landscape + portrait).
      - Assety SVG kompatybilne z VectorDrawable (m.in. brak gradientów itp., trzeba posiedzieć z developerem i pokeksperymentować co da się dobrze zaimportować).
      - Jak przygotowujesz ikonki, to kwadratowe, o takim samym rozmiarze. Jak dostaję zestaw ikon, które są prostokątami i potem muszę każdą centrować w apce to dostaje kurwicy. Nigdy nie wyjdzie idealnie.
      - Fonty z poprawnym baselinem, przetestowane na urządzeniach (często graficy dostarczają fonty, które na Androidzie totalnie się rozwalają).
      - Na mobile do określania wielkości/marginesów/paddingów nie używa się pikseli, tylko abstrakcyjnej jednostki dp - poczytaj czym to się rózni. Czasami nie da się czegoś zrobić idealnie jak w projekcie.
      - Design system czyli jakaś, specyfikacja, standard. Przykładowo identyczne marginesy na każdym ekranie, kilka typów przycisków (a nie pierdyliard), kilka styli fontów (header, title, body1, body2 etc.).

    •  

      - czcionka, którą widzisz na projekcie nigdy nie wygląda tak samo wyrenderowana w przeglądarce...

      @WaveCreator: Dlatego w projektach korzystam z odpowiednich czcionek. Np. Montserrat czy Lato to czcionki bezszeryfowe które się szybko wczytują, a przy tym ich rendering dość dobrze oddaje ich wygląd z projektu.

      A teraz takie inne pytanie do was, programistów - dla was to problem gdy korzysta się z więcej niż 1 rodziny fontów? Sam z reguły jak robię projekt to ograniczam się do 1 rodziny i stosowania ew. różnych krojów. Zastanawiam się, czy w sensie programistycznym to dla was udogodnienie, czy to koło chuja wam lata.

    •  

      @Vitz czasem grafik zaprojektuje np jakis polprzezroczysty dymek pod kręcący się progres bar który jest widoczny tylko podczas rejestracji konta. Załóżmy że jest wyjątkowo upierdliwy do implementacji. Użytkownik zobaczy go tylko raz, więc czasem idzie się na skróty i robi kontrolke która nie jest idealnym odzwierciedleniem grafik ))¯_(ツ)_/¯

    •  

      Komentarz usunięty przez autora

    •  

      @chotkos: Gdzie taki oboz, ze ktos przychodzi po 8 godzinach i pyta sie co zrobiles? Uciekaj stamtad.

      +: Matell
    •  

      @nn1upl: Im mniej tym lepiej, szczególnie jeśli strona ma być docelowo w językach wymagających rozszerzonych fontów (cyrylica itp.) - dobrym zwyczajem jest by grafik pytał klienta w jakich językach w najbliższej przyszłości może działać strona i żeby uświadamiał go, że języki wschodnioeuropejskie czy azjatyckie znacznie zawężają zakres czcionek, które można zastosować.

      Standardowo uważam, że dobrym kompromisem są dwa fonty:
      - jeden - o stałej wadze - na potrzeby nagłówków itp. (może być mniej standardowy)
      - drugi - najlepiej o 3 wagach: regular, bold i light - na potrzeby całej reszty tekstów (jak najbardziej standardowy, Lato zawsze spoko; co by to nie było - najważniejsze, żeby był dostęp do plików, które można wrzucić na serwer (w przypadku np. systemowego Ariala to nie takie proste bo licencje itp.)).

      No i im mniej czcionek tym mniej plików do ładowania i lepszy wynik w PageSpeedzie ( ͡° ͜ʖ ͡°)

      +: nn1upl
    •  

      @Vitz: w idealnym świecie:
      – projektant zna podstawy i możliwości technologii, pod którą projektuje,
      – front nie jest pisany przez back-endowców (którzy albo mają ui/ux gdzieś albo nie ogarniają na tyle front-endu, żeby pewne rzeczy wdrożyć albo nie chce im się zajrzeć do dokumentacji/style-guide).

      W praktyce też, dużo częściej trafiają się projekty robione na szybko, niż fajne, przemyślane i spójne designy, z których da się wyodrębnić komponenty i powtarzające się wzorce. Poza tym, często jakiś pozornie mały szczegół, może bardzo skomplikować kod lub popsuć jego semantykę. Mimo wszystko, czysty i uporządkowany kod opłaci się na dłuższą metę bardziej.

      No, ale akurat niezgadzające marginesy, style fontów i kolorki to zwykłe lenistwo :v Można to zminimalizować dostarczając developerom linka do opublikowanego projektu (np. Adobe XD) z assetami ładnie pozaznaczanymi do eksportu ^^

      +: Vitz
    •  

      u do pieniędzy klienta

      @Vitz: Masz pomysł co można zmienić w myśleniu takich ludzi?

    •  

      Komentarz usunięty przez autora

    •  

      @chotkos: Gdzie taki oboz, ze ktos przychodzi po 8 godzinach i pyta sie co zrobiles? Uciekaj stamtad.

      @lekkonieobecny: Juz ucieklem. Podkop łyżką i kusza z papieru toaletowego.