epuap.gov.pl

Witajcie,
po długiej i nieplanowanej przerwie postanowiłem przejrzeć sieć w poszukiwaniu nowych, interesujących w kontekście tego serwisu domen *.gov.pl Wynikiem tego researchu będzie recenzja strony ePUAP czyli elektronicznej platformy usług administracji publicznej, która (według stopki na stronie) należy do Ministerstwa Administracji i Cyfryzacji.

1. Od razu po wejściu na adres http://epuap.gov.pl jesteśmy przekierowywani na adres http://epuap.gov.pl/wps/portal/. Już to podsunęło mi na myśl małą zabawę z adresami URL. Na pierwszy ogień poszła subdomena www. z którą nie jeden polski serwis rządowy miał problem. Rozpoczęcie od adresu www.epuap.gov.pl również kończy się na wyżej wskazanej ścieżce, można by więc założyć, że serwis poprawnie współpracuje z subdomeną www.
   Co jednak stanie się jeśli prefiks www. dopiszemy do adresu dowolnego innego zasobu (czyli po prostu nie do adresu głównego)? Zobaczymy niezbyt przyjazny komunikat proxy o treści mówiący o błędzie z kodem HTTP 400. Polecam też zajrzenie do źródła wspomnianej podstrony. Przywodzi mi ono na myśl kod źródłowy stron błędów z dawnych wersji Apache.
2. Ciąg dalszy kombinacji z adresami URL. Wywołanie błędnego adresu w obrębie /wps/portal/ skutkuje pokazaniem strony głównej, bez żadnego czytelnego komunikatu.
   Mamy też drugą sytuację. Wpisanie błędnego URL na poziomie epuap.gov.pl/wps/ pokaże nam taki oto komunikat 404.
   Natomiast podanie błędnego adresu poniżej wskazanej ścieżki zaowocuje kolejnym komunikatem z proxy, dla odmiany błędem 403. Bo nie ma to jak konsekwencja, prawda?
3. Zanim przejdziemy do oceniania strony, z naciskiem na kod, chcę zwrócić uwagę na pewną deklarację składaną przez portal (jakby URL był niedostępny: screen. Autorzy twierdzą, że
   

   Wszystkie strony platformy ePUAP są zgodne z XHTML 1.0 Transitional. Dla przykładu sprawdź stronę główną pod względem poprawności XHTML przy pomocy narzędzia do sprawdzania poprawności kodu organizacji W3C.

   zgodnie z sugestią sprawdziłem stronę główną (dając tym niejako pewną szansę, bo wielokrotnie jedynie strona główna serwisu się waliduje, a reszta już nie) i zobaczyłem 8 błędów i 6 ostrzeżeń. Czytajmy dalej:

   Jeżeli masz jakieś uwagi do oświadczenia albo komentarze skontaktuj się z nami.

   Nie ma problemu 🙂 Link do tego materiału zostanie wysłany poprzez dostępną drogę kontaktu.

4. Kwestią kolejną jest przyjazność odnośników. Wiele serwisów stosuje tak zwane przyjazne URL-e. Przyjazne zarówno użytkownikowi jak i wyszukiwarkom internetowym. Nie bardzo wiem do której z tych grup zaliczyć ten serwis 😛 Odnośnik do cytowanej wyżej deklaracji o dostępności to http://epuap.gov.pl/wps/portal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os3g3Z4-gYG93QwMLRydXA89go2CXYENnA3djU_1wkA48Kswg8gY4gKOBvp9Hfm6qfkF2dpqjo6IiANSkrH4!/dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfRkNIUlNLRzEwOEFCRTBJUzJTRFMxQzA4RzY!/, a reszta wygląda podobnie. Co ciekawe ze strony głównej do formularza kontaktowego prowadzą dwa odnośniki i każdy z innym adresem URL:
   http://epuap.gov.pl/wps/portal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os3gTcy8fU09LYwP_YHNHA08jE2N3C38TIwNPY6B8JG75YHNidLs5ewQFe7sbGlg4OrkaeAYbBbsEGzobuBubEdAdDnItfttB8vjMB8kb4ACOBvp-Hvm5qfoFuaERBpkB6QDbbF-h/dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfRkNIUlNLRzEwOEFCRTBJUzJTRFMxQzA4OTc!/ versus http://epuap.gov.pl/wps/portal/E2_Kontakt – jak widać można zrobić już coś lepszego (choć można by i prościej, bo dlaczego nie?). Jednym z problemów jest to, że mamy identyczny zasób pod dwoma różnymi adresami (niekorzystne choćby z punktu SEO, po prostu duplicated content).
5. Wygląda na to, że dziś nie odczepię się w żaden sposób od odnośników URL na tej witrynie. Nie spodziewałem się, że w tym temacie będzie trzeba tak wiele napisać. Spójrzmy na jeden z odnośników ze strony głównej, z katalogu spraw możliwych do załatwienia. Oto budowa przykładowego z nich: http://epuap.gov.pl/wps/portal/E2_ZdarzeniaZyciowe/leId=280&<strong>forAdm=false</strong>. Nie trudno zauważyć ostatni parametr w adresie. Aż kusi, aby ustawić jego wartość na true. Wprawdzie nie zauważyłem, abym uzyskał dostęp do jakichś szczególnych danych, ale różnica niewątpliwie jest. Możecie tutaj porównać wygląd strony wynikowej z parametrem ustawionym na false i true.
6. Kończąc przegląd warstwy treści chcę zwrócić uwagę na jedno zdanie:
   

   Już mamy 129248 profili zaufanych

   Do szyku używanego przez Yodę jeszcze trochę brakuje, ale i tak wali po oczach.

7. Czas na kod źródłowy: o ile tym razem nie można doczepić się do białych znaków przed DTD, to zdecydowanie można zwrócić uwagę na duże ilości pustych linii między znacznikami. Nie jest to łamanie standardów – to raczej marnowanie miejsca (a co za tym idzie transferu i prawdopodobne zwiększanie kosztów utrzymania strony :P).
8. xHTML w wersji 1.0 Transitional – oczywiście wolelibyśmy Strict, a najlepiej 1.1
9. Przyjmuje się taką zasadę, że deklaracja kodowania powinna występować przed pojawieniem się pierwszych znaków spoza ASCII, a więc najlepiej na samym początku sekcji head.
10. Umieszczanie skryptów JavaScript w sekcji head nie jest mądrym posunięciem. Mogą one spowolnić, a nawet całkowicie zablokować (w przypadku błędnie napisanych) wczytywanie strony. Dlatego pamiętajcie: najbezpieczniejsze miejsce na umieszczanie skryptów JS to tuż przed </body>!

11. <div class="portal1"></div>

    pierwszy zbędny (bo pusty!) DIV spotykamy zaraz za otwarciem sekcji body – nie wróży najlepiej.

12. Chwilę później spotykamy:

    <h1 class="EP_displayNone">ePUAP - Strona główna</h1>

    Tutaj odwołam się do cytowanej już wyżej deklaracji dostępności umieszczonej na stronie:

    Wszystkie strony używają znaczników semantycznych. Tagi <h1> są użyte dla zaznaczenia głównych tytułów, <h2> dla wprowadzeń.

    Dobrze, że jest tag h1, niestety nie jest on tak dostępny jak myślą autorzy, bo ukrycie poprzez display: none; niewidomym też może sprawić problemy. Przede wszystkim jednak został on użyty w złym miejscu. Nagłówkiem pierwszego poziomu w tym wypadku powinien być po prostu nagłówek witryny (a h2, to nagłówek konkretnej podstrony).

13. Zobaczmy jednak jak w kodzie zostało zapisane logo:

    <a href="/wps/portal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os3g3Z4-gYG93QwMLRydXA89go2CXYENnA3djU_1wkA48Kswg8gY4gKOBvp9Hfm6qfkF2dpqjo6IiANSkrH4!/dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfRkNIUlNLRzEwOEFCRTBJUzJTRFMxQzBHMzU!/" class="EP_headerLeft" title="Strona główna ePUAP" accesskey="1"></a> 

    Jest to pusty link z nadanym tłem obrazkowym. Aż się prosi o image replacement.

14. Należy się pochwała za poprawne użycie label w formularzu wyszukiwania. Ponadto placeholder, mimo iż wykonany w JavaScript, to przynajmniej nie czyści pola z wpisanej przez nas treści po ponownym kliknięciu jak niektóre fuszerki.
15. Jednak już na początkowym etapie strony widać jak straszny divits wytworzyli autorzy strony.

16. <div>
    <a href="/wps/portal/E2_OePUAP" title="O ePUAP" accesskey="3"></a>
    </div>

    Kolejny pusty link i bezcelowy div.

17. Aby „dokopać” się do właściwego kodu musimy przebić się przez kilkukrotnie zagnieżdżone divy, potem potrójnie zagnieżdżoną tabelkę, aby na końcu otrzymać… iframe. Doskonale obrazuje to ten screen z FireBuga.
18. Skrypty JS wewnątrz dokumentu. Takie rzeczy powinny być wydzielone do zewnętrznych plików (celem umożliwienia skeszowania) oraz najlepiej zminifikowane na już działającej stronie.
19. Analogicznie do powyższego w kwestii CSS. Style wewnętrzne/inline nie są konieczne, jeśli nie zachodzą zmiany zależne od wywołania podstrony lub np. dotyczą tak wielu elementów, że tworzenie osobnych klas/ID było by niewydajne.
20. Nagminnie widać niepotrzebne powtarzanie i tworzenie klas w sytuacjach gdzie można by skorzystać z dziedziczenia w CSS. Taki plik wczyta się tylko raz, a więc nic nie stanie się jeśli będzie troszkę większy, a w zamian otrzymamy mniejszą ilość kodu HTML.
21. Po raz kolejny jestem zmuszony odwołać się do deklaracji dostępności, bo autorzy rozminęli się ze stanem faktycznym:
    

    Układ graficzny tej strony jest w całości opisany przez arkusze stylów kaskadowych (CSS).

    versus na przykład

    <font size="2">Od dnia 2 kwietnia 2013 roku (...)

22. Po dotarciu do stopki możemy jeszcze spotkać stosowanie encji zamiast polskich znaków mimo, że dokument korzysta z UTF8.
23. Nie ma możliwości korzystania ze strony przy wyłączonym JS. Powita nas jedynie komunikat:
    

    Javascript is blocked. ICEfaces cannot run.

Podsumowując: coś co najbardziej rzuca się w oczy to całkowicie nieprzyjazne adresy stron, strona całkowicie zależna od JS i ogromne ilości zbędnego kodu HTML i JS (kod CSS został przynajmniej zminifikowany). Jestem przekonany, że zwyczajnie racjonalizując użyty kod HTML można by zmniejszyć jego ilość o ponad 60% przy zachowaniu czytelnego układu.
Wykonanie mocno przekombinowane i generujące zawyżone koszty. Dostaje tag „Gniot”.