Jak zbudowaliśmy nowy portal PZU? Perspektywa Front-End Developera
Nowy serwis internetowy PZU to największy portalowy projekt e-point, realizowany na naszym autorskim e-point CMS. Przez 12 miesięcy pracował nad nim zespół złożony z programistów, testerów, UX designerów, project managerów, architektów i content managerów.
Chciałabym opowiedzieć o nim z perspektywy wyzwań i dobrych praktyk Front-End developera. Jak zbudowaliśmy spójny i przejrzysty dla użytkowników serwis, który redaktorzy z PZU mogą wygodnie edytować?
Dlaczego e-point CMS?
Portal PZU SA to żyjący organizm o dużej złożoności. Składa się z ponad 700 stron, gdzie treści są dodawane codziennie. Dlatego ważne, by redaktorzy mogli samodzielnie wprowadzać aktualności, uzupełniać ofertę czy przedstawiać nowe akcje promocyjne i produkty, bez udziału programistów czy Front-End developerów, zachowując spójną linię kreatywną.
e-point CMS jest oparty o komponenty, czyli elementy wyświetlające content w odpowiedniej formie graficznej. Dzięki nim redaktor jedynie wprowadza treści w odpowiednich polach CMS-a lub są one pobierane za pomocą integracji z systemami zewnętrznymi. W efekcie zostają zaprezentowane w miły dla oka i spójny z całym portalem sposób, dostosowany do urządzeń o różnej rozdzielczości.
Komponenty osadzane są w kontenerach, które ograniczają szerokość strony i odpowiadają za jej podział na kolumny. W e-point CMS można podzielić stronę na różną liczbę kolumn. Redaktor nie jest więc ograniczany do stałego układu strony, może go dowolnie dzielić. Daje to dużo swobody przy decydowaniu o sposobie prezentacji contentu, a jednocześnie gwarantuje, że wprowadzana treść będzie zgodna z look&feel całego portalu.
Portal PZU zbudowaliśmy na podstawie 70 komponentów, w tym 53 nowych, stworzonych specjalnie na potrzeby projektu.
Spójność
Kolejnym krokiem ku zapewnieniu spójności portalu jest wypracowanie podstawowych stylów, na których bazuje cały portal. Polega to na przeniesieniu do kodu takich wartości jak m.in.:
- Podstawowe kolory
- Czcionki
- Wielkość fontów
- Powtarzalne elementy (np. przyciski, stylowanie tekstów, ramki)
Dzięki temu szybciej tworzy się kolejne elementy, a jednocześnie łatwiej będzie utrzymać integralność wizualną portalu. Pomoże to również później redaktorom, którzy będą dodawać nowe treści z wykorzystaniem już zdefiniowanych elementów.
Ustalamy również podstawową szerokość strony. Najpierw analizujemy, z jakich urządzeń korzystają użytkownicy końcowi, a następnie wybieramy odpowiednie przedziały szerokości, dla których wygląd portalu będzie się zmieniał, dostosowywał do wielkości ekranu. To znacznie podnosi jakość odczuć użytkownika.
Responsywność
Portal pzu.pl został zbudowany w technice RWD (Responsive Web Design), co oznacza, że treść dostosowuje się do szerokości urządzenia, na którym ją wyświetlamy. e-point CMS wspiera portale budowane w tej technologii. Przede wszystkim budowane strony są osadzone na kanwie siatki 12-kolumnowej, opartej na bibliotece Bootstrap w wersji 4. 12 kolumn umożliwia proste dzielenie strony na 2, 3, 4 kolumny różnej szerokości - w zależności od potrzeby. Podziału można w łatwy sposób dokonać w panelu CMS. Kolumny są tak zdefiniowane, aby treść w nich zawarta była czytelna i przystępna w każdej szerokości ekranu.
Oprócz układu strony, responsywne są również same komponenty. Ich wygląd i zachowanie na różnych urządzeniach może być różny. Treść, która w wersji desktopowej wyświetlana jest w formie boksów, jeden obok drugiego, w wersji mobile staje się karuzelą, łatwą do obsługi na urządzeniach dotykowych i zajmującą mniej miejsca niż boksy ułożone jeden pod drugim. Wszelkie różnice w wyglądzie strony, które wynikają z rozdzielczości ekranu powinny być zidentyfikowane możliwie jak najwcześniej na etapie projektowania, aby ułatwić prace developerskie.
Responsywność komponentów zapewniana jest przez Front-End developera przy tworzeniu stylów i kodu JavaScript. Redaktor wprowadzając treść nie musi przejmować się jak będzie ona prezentowana. Wypełnia on jedynie odpowiednie pola konfiguracji, zwracając uwagę na podpowiedzi dotyczące np. rozmiarów grafik czy preferowanej długości tekstów, a komponent odpowiednio zaprezentuje się na wszystkich urządzeniach, skalując zdjęcia czy zmieniając rozmiar czcionki, kiedy zajdzie potrzeba.
Front-End developer styluje szablon komponentu, który potem jest uzupełniany treścią przez redaktora. Często te prace mogą być prowadzone niemalże równocześnie. Zadaniem Front-End developera jest przewidywanie, jakie treści i jakiej długości mogą zostać wpisane przez redaktora i ostylowanie komponentów w taki sposób, aby treści zawsze były czytelne.
Prosto, jasno, do celu!
Nowy portal dla klientów PZU
Wykorzystane technologie
Zespół Front-End-developerski tworzący portal PZU składał się z pięciu Front-End developerów, przy czym dwóch pracowało przy projekcie na cały etat, trzech pozostałych wspierało projekt w ograniczonym zakresie. Taki podział pracy był możliwy dzięki odpowiednim narzędziom. Jeden Front-End developer, jako leader w projekcie, był odpowiedzialny za omawianie proponowanych rozwiązań z UX Designerami, wybór użytych technologii i pluginów, implementację podstawowych elementów graficznych, a także rozdzielenie pracy pośród Front-End developerów i jej nadzór.
Przy stylowaniu komponentów wykorzystany został preprocesor SASS, który pozwala m.in. na zapisanie powtarzających się elementów wyglądu, kolorów czy czcionek w jednym osobnym pliku i odwoływanie się do nich za pomocą nazw.
Każdy komponent posiada również własne pliki ze stylami i skryptami, zatytułowane zgodnie z nazwą komponentu. Powyższe techniki pozwalają na szybsze wprowadzenie nowego developera do projektu. Kolejną zastosowaną w projekcie techniką była metodologia BEM (Block Element Modifier) opierająca się na tworzeniu modularnego kodu CSS. Główną zaletą jej zastosowania, oprócz płaskiej struktury zapisu kodu, jest enkapsulacja stylów w ramach komponentu. W przypadku jej zastosowania, style pisane dla różnych komponentów nie nadpiszą się wzajemnie.
Aby uzyskać większą spójność i czytelność kodu, użyte zostało również narzędzie sprawdzające je podczas pisania. Narzędzia typu CSS Linter pomagają nie tylko zidentyfikować pomyłki w składni pisanego kodu, ale również narzucają odpowiednie formatowanie, zagnieżdżanie i dbają o jego spójność. Powyższe technologie nie tylko wsparły prace przed wdrożeniem, ale ułatwią również prace nad rozwojami oraz przyspieszą wdrożenie w projekt nowego developera w razie potrzeby.
Poza użyciem odpowiednich technologii, duży wkład w sprawną współpracę między developerami wniosła analiza zadań i odpowiedni ich podział. Zidentyfikowaliśmy kilka obszarów na tyle niezależnych, aby mogły się nimi zająć osoby spoza głównego zespołu. Przykładem takich obszarów są: personalizacja komponentów, wypracowanie i implementacja stylów dla formularzy czy ostylowanie i implementacja działania map i wyszukiwarek placówek i agentów.
Zanim zaczęliśmy
Warto zaznaczyć, że praca Front-End-developerska zaczyna się jeszcze przed napisaniem pierwszego kawałka kodu. Najważniejsze jest zapoznanie się ze specyfiką branży tworzonego portalu oraz z wypracowanymi elementami graficznymi, często jeszcze w postaci makiet. To owocuje w kolejnych etapach pracy: łatwiej wtedy m.in. zauważyć odstępstwa od wybranej linii kreatywnej czy wskazać elementy problematyczne pod względem implementacji.
Każdy kolejny projekt przynosi nowe wyzwania i pozwala na wdrażanie nowych rozwiązań. Wszelkie narzędzia i techniki używane przy pracy nad portalem zapewniają jego spójność, modularność i obniżają próg wejścia nowych developerów w projekt, a praktyki, które się sprawdzają, są przenoszone do nowych projektów.