Zawód programisty od kilku lat owiewają liczne legendy, mity i plotki. Wśród nich są tematy zarobków, zakresu zadań, używanych technologii, czasu potrzebnego na przygotowanie do zawodu czy sposobów nauki programowania.
Postanowiliśmy odczarować tę profesję i wspólnie z serwisem Antyweb zorganizowaliśmy akcję „Miesiąc Programowania”. Przez cały miesiąc będziemy publikować wysokiej jakości materiały skierowanie do programistów oraz wszystkich osób, które chciałyby rozpocząć swoją przygodę z programowaniem.
Fot. unsplash.com
Doświadczenie
W ciągu wielu lat pracy z programistami zaobserwowałem powtarzającą się regułę wybiórczego przykładania wagi do implementacji warstwy wizualnej aplikacji. Może to wynikać z kilku powodów. Pierwszym z nich są ograniczenia czasowe projektu. Powstają wtedy wymówki typu “to tylko MVP, poprawi się później”, chociaż tego “później” często już nie ma. Niestety jest to mocno nadużywany argument, nawet przy mało czasochłonnych zmianach.
Drugim powodem jest trudność w wyjaśnieniu działania finalnego produktu na podstawie statycznych ekranów. Brak interakcji tworzy wiele nowych pytań. Jaka akcja zostaje wykonana po wybraniu danego przycisku? Jak zmienia się przycisk przy nakierowaniu kursorem? Jak zachowuję się nawigacja przy przewinięciu strony w dól. Niestety, przygotowanie i aktualizowanie klikalnych prototypów w złożonych projektach jest ciągle bardzo czasochłonne.
Innym czynnikiem jest ignorowanie detali, które wpływają na końcowy odbiór projektu. To natomiast może być spowodowane brakiem podstawowej edukacji w projektowaniu, która z pewnością przydałaby się każdej osobie zajmującej się tworzeniem produktów cyfrowych.
Lista niespójności po Design Review
Komunikacja
Kluczowym elementem tworzenia produktów wysokiej jakości jest dobra komunikacja.
Aby usprawnić cały ten proces, programista powinien uczestniczyć już we wczesnym etapie projektowania produktu, a projektant utrzymywać ciągły dialog z programistą i konsultować każde wykorzystanie niestandardowego rozwiązania. Developerzy często korzystają z gotowych bibliotek z podobnym rozwiązaniem, które w prosty sposób można dostosować wizualnie do reszty projektu i zaoszczędzić dużo czasu.
Inną ciekawą metodą jest przeprowadzanie regularnego ‘design review’, czyli wspólnej analizy zaimplementowanych ekranów. Tutaj bardzo ważną rolę odgrywa wymiana wiedzy i jasne przedstawienie przyczyn zastosowania danych rozwiązań.
Narzędzia
Przydatnym rozwiązaniem przy rozbudowywaniu produktu jest trzymanie wszystkich zasad stylów takich jak paleta kolorów, typografia, ikony, ilustracje oraz komponenty UI w jednym pliku zwanym ‘style guides’. Pomaga to przy tworzeniu nowych sekcji i utrzymaniu spójnego stylu w całym projekcie.
Opierając się o uprzednio ustanowiony system wizualny, programiści mogą przechowywać wszystkie ustawienia stylów w jednym miejscu oraz budować obiekty uprzednio wykorzystywane w wielu innych częściach projektu. Wbrew powszechnej opinii, przygotowanie systemu wizualnego nie zajmuje dużo czasu. Ważnym jest, aby pamiętać o budowaniu go od samego początku procesu projektowania i jego sukcesywnym aktualizowaniu wraz z dodawaniem do niego nowych części.
Przy ciągle rozwijanych projektach przygotowujmy również bibliotekę komponentów. Repozytorium Adele posiada wiele przykładów użycia struktury CSS (‘design system’) do tego celu.
Innym nieocenionym narzędziem jest aplikacja konwertująca robocze pliki graficzne na takie, które są bardziej przystępne dla developerów. Umożliwia to sprawdzanie wartości kolorów, fontów, marginesów oraz eksportowanie plików graficznych bez znajomości specjalistycznego oprogramowania, takiego jak Sketch czy Photoshop.
Jak bardzo ułatwia to pracę można zobaczyć na tej prezentacji: Inspect by InVision
Najpopularniejszymi narzędziami tego typu są:
Wytyczne styli w Zeplin
Przy większych projektach, gdy mamy bardzo dużą liczbę ekranów, warto posłużyć się mapami ‘user flow’. Pomagają one sprawnie wyłapać niedokończone ścieżki, brakujące ekrany oraz skrajne przypadki. Dodatkowo programista posiada łatwy wgląd w działanie aplikacji i zyskuje czas na przemyślane zaplanowanie struktury kodu.
Mapa User Flows
Detale
Aby bardziej zobrazować, jak ważne jest dbanie o detale wizualne, posłużę się przykładem jakości kodu, z jakim zdarza nam się pracować w ekstremalnych przypadkach.
Semantic HTML5 vs Table HTML
Jeśli jesteś programistą, twoja reakcja prawdopodobnie wygląda tak:
Podobne emocje wywołuje u projektanta zakodowana wersja jego projektu z tak lekkimi różnicami, jak przesunięty tekst o kilka pikseli, odrobinę węższy przycisk czy użycie typografii z bazowymi ustawieniami.
Użyteczność
Regularnie testujmy produkt z punktu widzenia końcowego użytkownika. Wszelkie niepewności lub niepotrzebnie skomplikowane funkcjonalności lepiej wykryć we wczesnym etapie, niż pozostawić to na sam koniec produkcji. Zwracajmy szczególną uwagę na ścieżki głównych funkcji projektu np. proces rejestracji, proces zakupowy, wypełnienie formularza. Błyskawicznie reagujmy gdy interakcja wydaje się wybiegać poza ogólnie przybrane lub akceptowane wzorce platformy.
Layout i siatka
Zachowujmy spójny system miar – opierajmy odległości i wielkości elementów o zestaw zasad zastosowanych w całym projekcie (np. 8-pt Grid). Budujmy aplikacje webowe zgodnie z responsywną siatką (np. Bootstrap Grid, CSS Grid, lub CSS Felxbox). Ustalajmy marginesy każdego elementu. Unikajmy sytuacji, w których tekst, ikona lub przycisk przylegają do krawędzi jakiejś przestrzeni.
Material Design Grid
Kolorystyka
Aby uniknąć problemu z utrzymaniem dobrych odcieni kolorów, ważne jest zbudowanie jednolitej i prostej palety kolorów, która będzie globalnie połączona do wszystkich elementów w aplikacji.
Paleta kolorów w aplikacji
Typografia
Głównym celem typografii jest jasne przekazywanie treści użytkownikowi. Aby fragment tekstu był wyświetlany czytelnie, pamiętajmy, że ważne jest dopracowanie nawet najmniejszych szczegółów. Poniżej zamieściłem listę cech stylów CSS, na które warto zwrócić uwagę podczas pracy z tekstem:
[font-family] Maksymalnie dwa kroje pisma w projekcie. Najlepiej jeden.
[font-size] Minimalny rozmiar tekstu to 11pt. W tekście głównym (paragraph) zalecane 15-25pt.
[font-weight] Ustawienie odpowiedniej grubości fonta pozwala na utrzymanie hierarchii treści oraz lepszej czytelności przy mniejszych nagłówkach.
[line-height] Interlinia powinna być na poziomie 120-145% rozmiaru tekstu.
[width] Szerokość bloku tekstu głównego powinna zawierać się w długości 45-90 znaków.
[letter-spacing] Przy mniejszych rozmiarach tekstu warto lekko zwiększyć odstęp między literami.
[color] Ważne, by trzymać się dostępności zgodnie z wytycznymi WCAG. W tym wypadku odnosi się to głównie do użycia wystarczająco kontrastującego koloru tekstu w stosunku do tła, na którym się znajduje. Z pomocą przyjdą nam różne narzędzia webowe, takie jak Contrast Checker.
Dodatkowo ograniczmy liczbę stylów tekstu do minimum. Wszystkie style tekstu ustawiajmy globalnie. Umożliwi to sprawniejsze zarządzanie zarówno projektem graficznym, jak i kodem. Ułatwi to też aktualizacje w przypadku zmian na późniejszym etapie projektu.
Przydatne materiały związane z typografią:
Style tekstów w Zeplin
Ikonografia i ilustracje
Przed rozpoczęciem projektowania warto zastanowić się, czy nie skorzystać z gotowego zestawu ikon, który znacznie przyspieszy proces projektowania i kodowania (np. Material Icons). Na wczesnym etapie tworzenia bardzo ważne jest spójne nazewnictwo zasobów. Warto grupować je po typie, sekcji w której ikona występuje i rozmiarze, używając prefiksów i sufiksów np. ic_, img_, navbar_, tabbar_, list_, placeholder_, _sm, _lg.
Ważna jest również decyzja w jakim formacie ikony będą implementowane. Projektant będzie mógł dostosować je do eksportu w zależności od tego, czy będą to pliki SVG, icon font, czy może zwykłe PNG w paru wersjach dla różnych gęstości pikseli. Pilnujmy, aby ikony były 'pixel perfect’. Robi to znaczną różnicę, szczególnie w przypadku używania aplikacji na ekranach Retina. Zdjęcia zawsze powinny być eksportowane do formatu JPEG z odpowiednią kompresją, by zaoszczędzić czas ładowania zasobów. Radzę również unikać kiczowatych stockowych zdjęć, które niszczą zamierzony projekt i jego finalny odbiór.
Lista ikon podzielona na kategorie
Graficy zawsze wymyślają!
Każdy projektant specjalizujący się w tworzeniu interfejsów powinien znać podstawy i ograniczenia HTML, CSS i JavaScript oraz dobrze orientować się we wzorcach danej platformy. Aby uniknąć nieporozumień z osobami bardziej zorientowanymi technicznie, warto utworzyć słownik wykorzystywanych komponentów. Przydatnymi materiałami będą tutaj:
- Wytyczne Apple (iOS)
- Wytyczne Material Designhttps://material.io/guidelines/# (Android)
- Rozbudowany framework CSS np. Bootstrap lub Foundation (Web)
Znajomość ograniczeń technicznych nie tylko pozwoli pohamować fantazję nadgorliwych i przyspieszy proces projektowania, ale również zaoszczędzi czas całego zespołu.
Wytyczne platformy iOS
Przydatne materiały z regułami projektowania:
- https://developer.apple.com/design/tips/
- http://goodui.org/
- Częste przeglądanie https://dribbble.com/ pozwoli rozeznać się w aktualnych trendach, wyszukać ciekawe rozwiązania i rozwinąć podstawowe poczucie estetyki.
Podsumowanie
Finalny produkt jest wspólnym dziełem projektanta i developera. Jesteśmy w jednej drużynie i pracujemy razem, więc nie ograniczajmy się tylko do własnych zadań. Pamiętajmy, że codzienna komunikacja i wymienianie swoich spostrzeżeń, ciągłe udoskonalanie procesu, a także wzajemna edukacja w swoich dziedzinach to rozwiązanie, które sprawi, że będziemy znacznie bardziej zadowoleni z efektów naszej pracy.
—
Adam Kalinowski
Frontendowiec na emeryturze. Aktualnie zajmuje się projektowaniem użytecznych rozwiązań w inFullMobile. Specjalizuje się w projektowaniu aplikacji mobilnych i webowch. Swoje potyczki ze sketchem publikuje na Dribbble.
