ELA — portal losów absolwentów
Jedna baza kodu, trzy platformy, jedna stała pozycja w budżecie mniej.
- 1 → 3
- baza kodu na platformy
- 2
- opublikowane aplikacje mobilne
- public sector
- obowiązki dostępnościowe
Kontekst
Frontend ELA — krajowego systemu monitorowania zatrudnienia i zarobków absolwentów polskich uczelni — budowanego w OPI-PIB na zlecenie Ministerstwa Nauki. Obok samego portalu zaproponowałem i zbudowałem strategię wieloplatformową, która wykorzystała to samo repozytorium Angulara zamiast finansować dwie aplikacje natywne.
Produkt
- Co robi
- Pokazuje, jak absolwentom polskich uczelni faktycznie wiedzie się na rynku pracy — zarobki i zatrudnienie od ukończenia studiów do pięciu lat później, w podziale na kierunki i uczelnie.
- Kto korzysta
- Kandydaci wybierający kierunek oraz badacze i analitycy pracujący na danych i raportach źródłowych.
- Skąd dane
- Rejestry ZUS zestawione z systemem szkolnictwa wyższego POL-on.
- Kto prowadzi
- Zbudowane i utrzymywane przez OPI-PIB, państwowy instytut badawczy, na zlecenie Ministerstwa Nauki i Szkolnictwa Wyższego.
Problem
Instytucja potrzebowała bardzo responsywnego, dostępnego portalu publicznego zbudowanego ze szczegółowych prototypów graficznych — i, osobno, obecności mobilnej. Domyślną odpowiedzią było zamówienie natywnych aplikacji na iOS i Androida, czyli trzy bazy kodu i trzy umowy utrzymaniowe na jeden produkt.
Architektura
Przewiń w bok, aby zobaczyć cały schemat
Jedno repozytorium Angulara, trzy cele wdrożenia. Nie ma równoległej bazy kodu mobilnej ani forka pod platformę — ta sama aplikacja jest opakowana dla iOS i Androida, więc każda poprawka i każda funkcja powstaje raz i trafia na wszystkie trzy.
Specyfikacja techniczna
- Frontend
- Angular, zbudowany z prototypów Adobe XD, responsywny na zakresie urządzeń, jaki musi obsłużyć portal publiczny.
- Mobile
- CapacitorJS opakowujący tę samą aplikację Angulara, opublikowany jako aplikacje na iOS i Androida.
- Zespół
- Dwóch frontendowców, dwóch projektantów UX i tester; prowadziłem wdrożenie frontendu.
- Dostępność
- Zbudowane zgodnie z obowiązkami dostępnościowymi polskiego sektora publicznego — nawigacja klawiaturą, semantyka i kontrast jako kryteria odbioru.
- Zakres
- Portal publiczny plus strategia mobilna; dane analityczne i raporty są dostępne przez ten sam interfejs.
Jak to zbudowałem
Prowadziłem wdrożenie frontendu w dwuosobowym zespole frontendowym, pracując obok dwóch projektantów UX i testera — prototypy były ich, a moim zadaniem było sprawić, żeby stały się realne, responsywne i szybkie.
Przełożyłem złożone prototypy z Adobe XD na interfejs w Angularze, wierny projektowi i jednocześnie faktycznie responsywny na całym zakresie urządzeń, jaki musi obsłużyć portal publiczny.
Dostępność potraktowałem jako wymaganie, a nie punkt audytu — zasięg sektora publicznego w Polsce sprawia, że nawigacja klawiaturą, semantyka i kontrast są częścią definicji ukończenia.
Zaproponowałem i zbudowałem strategię wieloplatformową w CapacitorJS, opakowując istniejącą aplikację Angulara w natywne powłoki i publikując ją w obu sklepach.
Zostawiłem to jako jedną aplikację, a nie build webowy plus mobilny fork — nie ma drugiej bazy kodu i to właśnie z tego bierze się stała oszczędność.
Rezultat
- Jedna baza kodu obsługująca web, iOS i Androida zamiast trzech równoległych wdrożeń.
- Usunięta stała roczna pozycja z budżetu instytucji na rozwój i utrzymanie — konkretną kwotę może ujawnić instytucja, nie ja.
- Dwie opublikowane aplikacje mobilne z repozytorium, które nigdy nie miało ich produkować.
- Dostępny, responsywny portal publiczny, wiernie odwzorowujący oryginalny system projektowy.