LoteriaParagonowa.gov.pl

8 listopada 2015 przez Comandeer | Opublikowany w Strony WWW

Tagi: ,

14

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&nbsp;służy do&nbsp;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…

Komentarze 14 komentarzy

Nie powinno się w stosować okreslenia „czcionka” w stosunku do wyświetlania liter na ekranie.

„Krój pisma” jest bardziej tym co tutaj chodzi.

True, chociaż i tak raczej nigdy tego nawyku nie zmienię. Inna rzecz, że tego typu rozróżnienie jest IMO bardzo nieefektywne z językowego punktu widzenia – zwłaszcza, że, zgodnie ze słownikiem PWN, czcionka oznacza krój pisma w druku.

w druku nie na ekranie

poza tym czcionka to takie małe elementy z literkami które układał kiedyś drukarz

No właśnie – i stąd jest to nieefektywne językowo. Utrzymywanie dwóch określeń na dwa podobne zjawiska jest bezsensowne i w końcu wykształci się jedna, uniwersalna forma. I prawdopodobnie będzie to wyraz „czcionka”, na co wskazuje częstość użycia w korpusie: http://sjp.pwn.pl/szukaj/czcionka.html
Warto też odnotować, że Wikisłownik już zawiera wyraz „czcionka” jako krój pisma w tekście komputerowym → https://pl.wiktionary.org/wiki/czcionka – bo takie użycie tego słowa jest obecnie najpopularniejsze.

Akurat w przypadku języka to, co powinno się a to, czego faktycznie się używa, to dwie różne sprawy. Definicja czcionki jako liter do składu druku jest anachroniczna. Język dąży do jak największego uproszczenia i w końcu „czcionka” będzie także oznaczać to, o co wszyscy się wykłócają. Ot, normalny proces językowy.

Każdy projektant i designer powie Tobie że to jest krój pisma albo font /tez dopuszczalne w sjp/… Ach Ci porogramiści…

Ale język jest dla wszystkich, a nie dla „elit” wywodzących się z konkretnych środowisk. No i mówię to jako polonista, nie programista. Nie widzę sensu w utrzymywaniu de facto sztucznych tworów językowych, podczas gdy istnieją już w języku takie, które można zaadaptować do nowego zastosowania. I takie tendencje język przejawia, na co dowody przedstawiłem wyżej.

Jeżeli się odnosisz profesjonalnie do kwestii projektu i wyglądu pisz tak jak każdy profesjonalista – a nie jak człowiek który nie wie o czym mówi /to też świadczy o poziomie oceny=krytyki ;)/

Używam słowa zgodnie z jego znaczeniem w języku potocznym – a w takim języku wszystkie krytyki są pisane. Nie widzę tutaj niczego, co wykracza poza przyjętą konwencję.

Poza tym: nie odnosiłem się do kwestii wyglądu, a kwestii interfejsu i UX. Przyczepienie się słowa całkowicie zrozumiałego, które występuje tylko raz w tekście w ściśle określonym kontekście i utworzenie z tego de facto argumentu ad personam jest IMO dziwnym sposobem na „dyskusję” 😉

Odniosłeś się do kwestii projektu czyli kompetencji projektanta.

„jaki jest sens takich przycisków dzisiaj, gdy każda przeglądarka ma wbudowany zoom?” – za takie myślenie projektanci zabijają…

A czy programista tworzy UX, czy zajmuje się interfejsem? Nie. Programista tylko odtwarza pomysły i wygląd.

Dla projektanta/designera/UX-owca „czcionka” to nie font.

> za takie myślenie projektanci zabijają…
Ale co jest zdrożnego w takim myśleniu? Te przyciski i tak nie pełnią swojej funkcji, bo są źle zaimplementowane, co prowadzi do kolejnego punktu…

> Programista tylko odtwarza pomysły i wygląd.
Przez tego typu myślenie obecne strony nie są ani użyteczne, ani dostępne. Programista, który jedynie odtwarza to, co dostał w PSD, to nie programista. To klepacz kodu. Jeśli frontend dev obecnie nie ma szerokiej wiedzy na temat a11y i UX, to nie ma prawa nazywać się pełnoprawnym frontend devem – taka jest prawda.
Webdev ma zadbać o to, by pomysł projektanta był zaimplementowany w sposób najlepszy dla usera. A jeśli widzi, że tego się zrobić nie da lub jest to po prostu zbędne, to powinien o tym powiedzieć projektantowi. Nie rozumiem, czemu między tymi dwoma działami komunikacja de facto nie istnieje… co znowu wpływa niekorzystnie na końcową jakość produktu.

> Dla projektanta/designera/UX-owca „czcionka” to nie font.
Ale dla wszystkich innych tak. Próba wykrzewienia tego typu nawyków językowych jest po prostu z góry skazana na porażkę. Poza tym: komunikat jest i tak w pełni zrozumiały, bo się o niego wykłócamy już dobre pół godziny 😉

Za wikipedią: „Czcionka rodzaj nośnika pojedynczych znaków pisma drukarskiego, podstawowy materiał zecerski używany w technice druku wypukłego. Współcześnie czcionka drukarska została wyparta przez czcionkę komputerową, która jest obrazem pojedynczego znaku (glifu) zakodowanym w postaci bitmapowej lub wektorowej.”

Wszystko jedno co nie napiszecie i jak się nie będziecie kłócić, ale dysk twardy, płyta CD itp. są NOŚNIKAMI informacji, a także NOŚNIKAMI ZNAKÓW PISMA. To co wyświetla się na ekranie jest zatem czcionką. Dopiero drukarka sprawia, że możemy odbić „czcionkę” na papierze. Oczywiście na ekranie widzimy różnice pomiędzy poszczególnymi czcionkami i myśle, że można to również nazwać „krojem pisma”. Uważam, że obie nazwy są poprawne.

Nazwa „Czcionka” jest bardziej popularna, gdyż posiada tylko jeden wyraz, a język używany w Internecie staje się bardziej skrótowy.

Pan ABC zapomina również o tym, że znaczenie słów ulega zmianie i dzisiaj słowo „czcionka” jest zamiennie używane ze słowem „krój pisma”.
Co też pisze w wikipedii, że znaczenie definicji słowa „czcionka” jest rozumiane w 3cim znaczeniu jako „Pojęcie dotyczące produktu – krój pisma.” https://pl.wikipedia.org/wiki/Czcionka#Znaczenia_poj.C4.99cia

Boże. Przysrał się jak elekrtyk to kabla i przewodu. Każdy wie o co chodzi.
Za to nie odniósł się do niczego, co jest w tekście, dodatkowo generalizuje mówiąc „każdy projektant” myśląc wyłącznie o sobie.

Abc pisze „projektant i designer” nie wiedząc, że są to synonimy – tyle, że jeden wyraz to tłumaczenie drugiego.

Comandeer prawdopodobnie trafił tu autor strony, i próbuje podskoczyć Ci na jedynym poziomie na którym myśli że może być lepszy – nie znając Twojego wykształcenia 😉 Szkoda nerwów 🙂

dlaczego dev nie powiedzial o czyms projektanktowi? bo projektanta wyp* z pracy marketoid ktory uwaza ze sam przekaze koderowi wymagania a kasa bedzie cala dla niego, po co co placic projektantowi

Napisz komentarz

Uwaga! Uprasza się komentujących, którzy chcą obrazić autora, aby najpierw dokonali niezbędnego researchu jego osoby. Z góry dziękujemy za poświęcony czas.