LoteriaParagonowa.gov.pl

Miesiąc temu w naszym wspaniałym kraju nad Wisłą ruszyła loteria paragonowa – cudowny sposób na nieuczciwych VAT-owców! Oczywiście jak w przypadku wszystkich nowych przedsięwzięć tego typu, zgłoszenie swego udziału odbywa się przy pomocy strony internetowej. Postanowiłem ją zatem odwiedzić.

• Połączenie odbywa się przez HTTPS, czyli jest bezpieczne. Co więcej, serwer obsługuje SPDY. Niestety obecnie jest to przestarzały protokół i powinien zostać zastąpiony po prostu przez HTTP/2.
• Oczywiście wita nas nadmiernie wyeksponowany komunikat o cookies. Naprawdę, mały pasek w zupełności wystarczy.
• Strona bez JS wygląda dość dobrze. Jedyne uchybienie wizualne (brak slidera u góry) jest jednakże bardzo proste do wyeliminowania przy pomocy techniki z .no-js (zwłaszcza, że na html są już inne klasy).
• Logo wygląda… ciut biednie. Rozumiem zamysł, który nawet jest dobry, tylko mam wrażenie, że na wykonanie zabrakło czasu albo chęci.
• Obrazki serwowane są z odrębnej domeny, przeznaczonej dla statycznych zasobów – static.loteriaparagonowa.gov.pl. Szkoda tylko, że niepotrzebnie przesyła ciasteczka. Dodatkowo niektóre zasoby (np. obrazki w sekcji Edukacja) zaciągane są wprost z chmury Amazona. A szkoda. Skoro się już zrobiło własny CDN, to warto wszystkie zasoby słać z niego.
• Jest jeszcze inna wada tego CDN-a: zasoby mają krótki czas cache’u. Logo jest raptem trzymane w pamięci przeglądarki 4 dni. Czyżby co 4 dni się zmieniało?
• A jeśli już przy obrazkach jesteśmy: w sekcji Edukacja znajdujemy infografikę, która informuje nas na co dokładnie idzie nasz VAT. Zastanawia mnie w jej jedna rzecz: czemu żołnierz i policjant mają ewidentną wadę zgryzu?
• Strona z wynikami losowania jest niezbyt informatywna. Dotąd nie odbyło się żadne losowanie, ale takiego komunikatu tam nie zastaniemy. Zamiast tego straszy nas puste miejsce, które nie wiadomo czy oznacza błąd, czy po prostu… brak wyników.
• Na samej górze widać kontrolki do zmiany wielkości czcionki. Skorzystałem z nich i… praktycznie nie zauważyłem różnicy. Czcionka została powiększona o tak śmieszną wielkość, że te przyciski jedynie zabierają miejsce. Poza tym: jaki jest sens takich przycisków dzisiaj, gdy każda przeglądarka ma wbudowany zoom?

• Oczywiście głównym elementem strony jest formularz pozwalający nam na wprowadzenie nowego paragonu. Zastosowano w nim dość ciekawy system walidacji. Otóż po stronie serwera jest całkowicie niejawna – użytkownik nie dostanie żadnego sensownego komunikatu o błędzie. Oczywiście, żeby zobaczyć ten komunikat należy nie mieć działającego JS, ale to nie problem.

  Natomiast po stronie klienta niepoprawnie wypełnione pola… podświetlają się na żółto. Szkoda tylko, że praktycznie identycznego koloru używa mechanizm autouzupełniania pól w Chrome. Tym samym byłem ciut zdezorientowany widząc tak oznaczone pole. Dowiedziałem się, że to błąd we wprowadzonych danych dopiero wtedy, gdy najechałem myszką na to pole – pojawił się wówczas lakoniczny tooltip tłumaczący mój błąd. Problem polega na tym, że komunikat ten pojawia się tylko po najechaniu myszką, przez co ludzie nieużywający myszki lub wypełniający formularz z urządzenia dotykowego żadnego komunikatu nie zobaczą.

  Żeby było śmieszniej, po włączeniu trybu wysokiego kontrastu – mającego ułatwić osobom z wadami wzroku posługiwanie się stroną – błędy stają się niewidoczne…

  Podsumowując: to jeden z najgorszych systemów informowania użytkowników o błędach, jaki widziałem w formularzach – zwłaszcza tak rozbudowanych jak ten.

• Tuż obok formularza znajduje się malutki obrazek paragonu z dokładnie opisanymi wszystkimi częściami, żeby nikt nie miał problemów z przepisaniem danych do formularza. Problem polega na tym, że… obrazek jest malutki i jest trudno cokolwiek z niego rozczytać. Osobiście wydaje mi się, że mniej kłopotliwym systemem wprowadzania danych o paragonie byłoby przygotowanie formularza w jego kształcie. Wówczas pola znajdowałyby się w odpowiednich miejscach i zlokalizowanie danych na rzeczywistym paragonie stałoby się banalnie proste.

  Z tym „paragonem-demo” jest jeszcze jeden, subtelny problem: istnieją różne wzory paragonów. Niektóre są bardzo podobne do tego zaprezentowanego, ale inne są całkowicie inne. Być może dobrym pomysłem byłoby przygotowanie kilku najpopularniejszych wzorów, zamiast jednego, „uniwersalnego”?

• Myślę także, że pole do wpisywania NIP-u sprzedawcy można ulepszyć. Przecież NIP-y największych sklepów znajdują się w KRS, CEIDG lub innych tego typu rejestrach. Można ten fakt wykorzystać do stworzenia listy najpopularniejszych przedsiębiorstw, dzięki czemu zamiast żmudnie przepisywać NIP, użytkownik może po prostu wpisać nazwę firmy. Taką listę przedsiębiorstw można następnie poszerzać (albo zmniejszać) na podstawie statystyk wpisów dokonywanych przez użytkowników.
• Zastanawiam się czy pole „Wybór branży” nie należałoby zmienić na 2 pola checkbox. Zacznijmy od tego, że to nie jest wybór branży, a raczej pytanie, czy nasz paragon pochodzi z aktualnie premiowanej gałęzi gospodarki. Z tego też powodu 2 pola checkbox byłyby przejrzystsze od obecnego pola wyboru.
• Śmieszy mnie „zabezpieczenie” formularza przed robotami. Jest tak bardzo źle zrobione, że nawet działanie w kodzie jest oznaczone odrębnym elementem z [id]. Tym samym napisanie bota masowo generującego fałszywe paragony jest banalnie prosta – zwłaszcza, że reguły walidacji niektórych pól są niezgodne z ich przewidywaną zawartością. Jeśli się już chce zabezpieczać, to niech to zostanie zrobione dobrze, czyli np. wykorzystując ReCAPTCHA-ę.

• Strona pozwala także na założenie konta, a raczej zakłada je automatycznie, wraz z rejestracją pierwszego paragonu. Hasłem do niego jest unikalny identyfikator pierwszego zgłoszenia paragonu. Problem w tym, że ani maila, ani hasła nie da się w żaden sposób zmienić. Nie da się także zmienić podanego przy pierwszym zgłoszeniu numeru telefonu. Dość dziwne, zważając na fakt, że jednak telefony obecnie się zmienia.

  A brak możliwości zmiany hasła można uznać za błąd bezpieczeństwa. Tym bardziej, że hasło nie jest całkowicie losowym ciągiem znaków, ale jest całkowicie jawnie zapisane w bazie. Ba, wyświetlane na ekranie komputera – zarówno tuż po wysłaniu zgłoszenia, jak i na liście naszych zgłoszonych paragonów. Jasne, ktoś powie: a na co mi czyjaś lista paragonów? i możliwe, że będzie miał rację. Problem w tym, że lista ta pokazuje do jakich sklepów chodzi dana osoba i pozwala sprofilować ją pod kątem odpowiednich reklam. Facebook pragnie takich rzeczy – a jeśli on ich chce, to prawdopodobnie inni też. Stąd mimo wszystko należy dbać o ich bezpieczeństwo.

• Jeszcze większy problem polega na tym, że potrzeba istnienia tego konta jest dość dyskusyjna. W przypadku formularza na stronie głównej fakt zalogowania nie zmienia nawet komunikatu o możliwości logowania. Jedyna „wartość dodana” to… wypełnione pole na e-mail i telefon, których nie da się zmienić. I nie jest to żadne osiągnięcie, bo dla użytkowników niezalogowanych ostatnio wpisany e-mail i telefon są zapamiętywane i formularz jest autouzupełniany. No i można te wartości zmienić, co czasami jest bardzo przydatne. Zalogowany użytkownik musi także za każdym zgłoszeniem akceptować na nowo regulamin. Zatem moje pytanie brzmi: jeśli zalogowany użytkownik nie może nic ponad to, co niezalogowany (a wręcz może mniej!), to po co mu umożliwiać to logowanie?
• Jedyną funkcją tylko dla zalogowanych jest lista zgłoszonych paragonów. Można je nawet edytować i wydrukować. Chyba nie muszę zaznaczać, że zgłoszenie zawierające e-mail i hasło do konta również można wydrukować.
• Ponarzekam też trochę na możliwość nawigowania przy pomocy klawiatury. Co prawda outline linków jest widoczny, ale jego czytelność na pewno zwiększyłoby zaaplikowanie stylów z :hover dla :focus. Co więcej, niektóre elementy interaktywne (np. kontrolki górnego slidera) są całkowicie niedostępne z poziomu klawiatury. Inne z kolei nie mają outline’u (jak np. przycisk otwierający kalendarz w polu daty formularza).
• Przejdźmy do kwestii technicznych. Walidator tradycyjnie nie jest zadowolony – zwłaszcza, że mamy do czynienia z błędami dostępności. Również wynik w PageSpeed nie zachwyca. Pozwoliłem sobie także przepuścić stronę przez narzędzie sprawdzające problemy z dostępnością i kolorowo nie było.
• Mamy na html klasy dla wszystkich wersji IE – nawet całkowicie martwych. Niestety, zabrakło już widać miejsca na ważniejszą informację, jaką jest język strony oraz na wspomnianą już klasę .no-js.
• Załączony plik CSS jest niezminifikowany. Rozumiem, że SPDY radzi sobie lepiej w kompresji danych niż HTTP/1, ale to nie oznacza, że można przesyłać niepotrzebne informacje – zwłaszcza jeśli są nimi komentarze z normalize.css
• Skrypt Google Analytics jest poprawnie umieszczony w head, niemniej w złym jego miejscu. Zgodnie z opinią eksperta, skrypty umieszczone po arkuszach stylów blokują rendering. Z tego też powodu skrypt powinien zostać przesunięty przed CSS.

• <h1 class="logo">
  	<a href="https://loteriaparagonowa.gov.pl"><img src='https://static.loteriaparagonowa.gov.pl/public/images/logo.png' alt="Logo Loterii Paragonowej przedstawiające kod kreskowy. Powrót do strony głównej." data-contrast="image"></a>
  </h1>

  Wzorowy przykład złego atrybutu [alt]. Jeśli obrazek znajduje się wewnątrz linku, to jego tekst alternatywny powinien opisywać jego funkcję, nie zaś to, czym jest. No bo w sumie po co ktoś miałby klikać logo? Druga część tego atrybutu – Powrót do strony głównej – jest już bardziej przyzwoita, lecz brakuje jeszcze informacji czego to strona główna. A najlepiej po prostu dać tutaj nazwę strony, zwłaszcza, że [alt] jest w tym wypadku równocześnie nagłówkiem strony.

• Jak wyglądają przyciski do zmiany wielkości strony i wersji kontrastowej? Tak:

  <a href="#" id="smallSize" title="Mały rozmiar tekstu"><img src="https://static.loteriaparagonowa.gov.pl/public/images/small_a.png" alt="Mały rozmiar tekstu" data-contrast="image"></a>

  Zatem dostajemy martwe linki zamiast prawdziwych przycisków. A szkoda – button naprawdę nie gryzie, a obecnie można go także sensownie ostylować.

• System zmiany rozmiaru czcionki mnie mocno zdziwił. Jego główna częśc bowiem wygląda tak:

  function setSize(prop) {
  	for (i = 0; i < window.fonts.length; i++) {
  		var object = window.fonts[i];
  		if (object.object.attr('data-font-semi') !== undefined) {
  			object.object.css('font-size', object.object.attr('data-font-semi') + 'px');
  		}
  		else if (object.object.attr('data-font-high') !== undefined) {
  			object.object.css('font-size', object.object.attr('data-font-high') + 'px');
  		}
  		else {
  		setFont(object.object, object.size, prop);
  		}
  	}
  }

  Czym jest owe tajemnicze window.fonts? Okazuje się, że to… tablica wszystkich elementów, w których CSS-ie znajduje sie deklaracja font-size. Szczyt absurdu. Całą sprawę można załatwić zmieniając klasę html. Pomijam już bzdurność trzymania takiego info w globalnej przestrzeni (mamy 2015 rok, modularność jest podstawą dzisiejszego JS!), a tym bardziej pod taką nazwą.

• Mechanizm zmiany kontrastu również wykonuje jakieś chore operacje na elementach z [data-contrast], podczas gdy znów wystarczy zmienić klasę na html. Co więcej, funkcje go obsługujące łamią tradycyjną konwencję nazewniczą, wg której jedynie konstruktory pisane są dużą literą (zatem toggleContrast, a nie ToggleContrast).

• <div class="menu-mobile hidden-on-960" onclick="showMenu()"></div>

  Kolejny przycisk, który nie jest przyciskiem. Ba, ten element nawet nie ma treści, stąd jest niedostępny. Jeśli nie doczyta się grafika przycisku, użytkownik nic nie zobaczy. Co więcej ten „przycisk” nie jest dostępny z klawiatury. Przycisk ma być przyciskiem – i tyle. Nie wywala się koła tylko po to, by zastąpić je kwadratem.

• <a class="login" data-contrast="button-yellow" onclick="showLoginPopup('https://loteriaparagonowa.gov.pl/auth/login')"><span>Zaloguj się    </span><span class="size_bigger">»</span></a>

  A tutaj link, który nie jest linkiem. A wystarczyłoby zrobić choćby coś takiego:

  <a href="https://loteriaparagonowa.gov.pl/auth/login" class="login" data-contrast="button-yellow" onclick="showLoginPopup(this.href)"><span>Zaloguj się</span><span class="size_bigger">»</span></a>

  A najlepiej wywalić obsługę kliku do JS.

  Inną sprawą jest złe użycie niełamliwej spacji, która nie służy do robienia odstępów.

•  <li><a href="https://loteriaparagonowa.gov.pl/kalendarium"><img src="https://static.loteriaparagonowa.gov.pl/public/images/calendar_ico.png" alt="Kalendarz">Kalendarium Losowań</a></li>

  Tu z kolei mamy do czynienia z redundantnym atrybutem [alt], który duplikuje informacje z otoczenia. Ikonki-ozdobniki powinny mieć pusty [alt].

• <img class="mobileImgLogo" src="https://static.loteriaparagonowa.gov.pl/public/images/slider/ogolny-obraz.png" alt="Nie znaleziono">

  Kolejny nietrafiony [alt].

• <img alt="Nf" src="https://static.loteriaparagonowa.gov.pl/public/images/rule_1.png" />

  I jeszcze jeden…

• Mogę już z czystym sumieniem stwierdzić: strona cierpi na poważny divitis! Nawet tekst, zamiast w akapity, upchnięty jest w divy.
• Konwencje nazewnicze też leżą. Mamy .slide-second, .notShowMobile, ale i #normal_contrast. Do tego dochodzą kwiatki typu .red czy .text-yellow, czyli klasy całkowicie zależne od wyglądu, a nie semantyki kodu.

• <a href="https://loteriaparagonowa.gov.pl/zasady"><p>Dowiedz się więcej o zasadach <img src="https://static.loteriaparagonowa.gov.pl/public/images/caret-right.png" alt="link do regulaminu"></p></a>

  Kolejny obrazek z kwestionalnym [alt] – tutaj znów bardziej nada się pusty.

• Wciąż uparcie zero akapitów. Zamiast tego można zobaczyć takie dziwactwo, jak span z br w środku (w dodatku użytym wyłącznie z powodów estetycznych!).

• <img class="imgElem" src="https://static.loteriaparagonowa.gov.pl/public/images/slider/specjalna.png" />

  A teraz obrazki nie mają już [alt] w ogóle…

• <h2>Najbliższe losowanie już</h2>
  <h2 class="cst">16 listopada 2015!</h2>
  <h3>Do wygrania Opel Astra oraz<br> 2x iPad Air 2!</h3>

  Jeśli jeszcze pierwszy z tych nagłówków da się uzasadnić, tak dwa kolejne to raczej marny wybieg SEO.

• Slider odsyła do różnych stron, ale… nie ma w nim linków. Zamiast tego zastąpiono je całkowicie debilnym pomysłem: atrybutami [data-href] i [data-popup] przyczepionymi do diva. Kolejne linki niedostępne z klawiatury.

• <div class="slider-navigation" data-contrast="slider"> </div>

  A tak wyglądają kontrolki slidera. Po wygenerowaniu nie wyglądają dużo lepiej:

  <div class="slider-nav disabled" title="1 - slajd" data-position="1"><span>1</span></div>

  Kolejne marne atrapy przycisków.

• Później zaczyna się formularz, a w nim kwiatki typu:

  Prawidłowy numer kasy rejestrującej tworzy:<br>
  1) trzyliterowy prefiks oraz ciąg 10 cyfr,<br>
  2) trzyliterowy prefiks oraz ciąg 8 cyfr,<br>
  3) dwuliterowy prefiks oraz ciąg 8 cyfr.<br>
  Numer należy wpisywać bez spacji

  Czyli klasyczna lista bez listy.

• <input data-contrast="placeholder"  id="nr_kasy_1" name="nr_kasy_1" class="input" maxlength="13" onkeyup="this.value = this.value.replace(/\W+/g, '')">

  Jak widać, filtr pola jest zrobiony na zdarzeniu keyup, co oznacza, że wklejenie czegoś przy pomocy menu kontekstowego ominie filtr. Poprawne zdarzenie to input. A jeszcze poprawniej użyć [pattern] z HTML5. I dorzucić do tego [required].

• <!--Komentarze konieczne do usunięcia spacji między polami (skutek użycia inline-block
  -->

  Pomijając fakt, że są inne metody radzenia sobie z tym (np. trick z font-size), to dodatkowo ten komentarz ma skopane kodowanie.

• Szkoda, że większość pól nie ma odpowiedniej etykiety. Można tutaj zastosować sztuczkę z .visuallyhidden albo [aria-label].

• <img class="popup_trojkat_branza" style='z-index: 3' src="https://static.loteriaparagonowa.gov.pl/public/images/triangle_popup.png" alt="\/" data-contrast="image">

  Kolejny nietrafiony [alt].

• <div id="valid-popup">
  	<div class="popup-overlay"></div>
  	<div class="wrap-popup">
  		<div class="popup-body">
  			<span class="popup-exit">x</span>
  			<h1></h1>
  		</div>
  	</div>
  </div>

  Tego typu element warto dodatkowo oznaczyć przez atrybut [hidden] lub [aria-hidden=true]. A idealnie jest wstawić to przy pomocy skryptu JS albo znów wykorzystać klasę .no-js.

• <!--[if !IE]><!-->
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
  <!--<![endif]-->
  
  <!--[if lte IE 8]>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
  <![endif]-->
  
  <!--[if gt IE 8]>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
  <![endif]-->

  Dość ciekawa rzecz: warunkowe wczytywanie JS. Szkoda tylko, że ostatni warunek powinien być połączony z pierwszym (co ciekawe, jest to zrobione w przypadku klasy na html). Inna rzecz: nie bawiłbym się w to, tylko załączył wersję z gałęzi 1.11.

• /*# sourceMappingURL=all.css.map */

  Ciekawostka z CSS: sourcemap… w niezminifikowanym pliku. Absurd.

• Natomiast w JS widać stary skrypt od customowych formularzy. Szkoda tylko, że od lat istnieją lepsze sposoby. A w przypadku starszych IE po prostu zaserwuje się normalny formularz.

• //# sourceMappingURL=all.js.map

  W JS mamy taką samą sytuację, jak w CSS: sourcemap dla niezminifikowanego JS-a. Ktoś nie umie ich używać.

Prawdę powiedziawszy nie wiem co mam powiedzieć. Na tej stronie wszystko nie działa do końca tak, jak powinno. Przez te problemy cierpi zarówno dostępność, jak i użyteczność. Aż chce się rzec: kolejna typowa strona na WK…