Stwierdziłem, że tym razem zrobię coś nietypowego. A że ostatnio na grupach na FB mocno reklamowana była platforma INVO Academy, postanowiłem jej się przyjrzeć.
Wstęp
W założeniu INVO Academy (pozwolę sobie używać dalej skrótu IA) ma być miejscem, w którym początkujący frontendowiec ma szansę poćwiczyć swoje umiejętności w kodowaniu designów z Figmy do HTML-a. Jeśli chodzi o sam pomysł – jak najbardziej jestem za! Sam uważam, że najszybciej uczy się na podstawie praktyki – zwłaszcza na samym początku. A IA obiecuje jeszcze review do każdego zakodowanego projektu. Ba, w przyszłości ma być nawet możliwość dawania review samemu – co też jest bardzo potrzebną umiejętnością w codziennej pracy programisty.
Na pierwszy rzut oka zatem wszystko wydaje się w porządku. Pora więc zobaczyć, jak to wychodzi w praktyce!
Rekrutacja
Na razie IA jest we wczesnym dostępie, dzięki czemu całość dostępna jest za darmo. Założyłem więc konto i… zderzyłem się z czymś, o czym nie wspominały ani reklamy na grupach, ani strona domowa projektu. Otóż trafiłem do rekrutacji. Odbywała się w postaci gry przypominającej nieco połączenie gry logicznej typu Colobot z językiem programowania Scratch. Moim zadaniem było pomóc rakiecie przelecieć od początku planszy do końca oznaczonego gwiazdką. Żeby nie było za łatwo, gra nie posiadała żadnej instrukcji, a ja miałem tylko 45 minut, by dojść jak najdalej. Dodatkowo zostałem poinformowany, że wszystkie moje akcje są nagrywane i następnie autorski algorytm
zadecyduje, czy zostałem przyjęty do społeczności nowego pokolenia developerów
. To byłby spory plot twist, gdyby recenzja IA zakończyła się, zanim na dobre się rozpoczęła!
Dotarłem do poziomu 6. Zasady gry nie okazały się zbyt trudne. Największym przeciwnikiem okazał się mocno „drewniany” interfejs gry. Na domyślnym ustawieniu rakieta poruszała się zdecydowanie zbyt ślamazarnie, a scratchowate bloczki kodu były zbyt ograniczone. Można było je dodawać jedynie przez kliknięcie i nie było możliwości zmiany ich kolejności – można było jedynie usunąć ostatnio dodany bloczek.
Na szczęście dotarcie na poziom 6. okazało się wystarczające i otworzyły się przede mną podwoje do reszty platformy. Niemniej na tym etapie miałem bardzo mieszane uczucia. Tak po prawdzie do teraz nie rozumiem, jaki jest sens tej gry? Zwłaszcza, że w materiałach promujących platformę nic się o niej nie wspomina. Nie sprawdza też ona umiejętności potrzebnych do kodowania designów. Jedyne, co sprawdza, to umiejętność logicznego myślenia czy znajomość podstaw algorytmiki. Przyjemna gierka… ale no właśnie – to po prostu przyjemna gierka. Jeśli jej zadaniem jest budowanie poczucia ekskluzywności (Patrzcie, zostałem wybrany do bycia członkiem tej grupy!
), to myślę, że to nie jest dobre miejsce na takie rzeczy. Gdybym był początkującym, który po prostu chce sobie pokodzić designy, to po włączeniu się tej gry najprawdopodobniej nigdy bym już do IA nie wrócił. Bo zamiast tego, co mi zareklamowano na grupie, dostaję na start sprawdzian moich umiejętności – i to nawet nie w dziedzinie, którą miałem ćwiczyć na tej platformie.
Design
Ale dobrze, przejdźmy do mięska! Na stronie (w momencie pisania tej recenzji, czyli 6 marca 2023) znaleźć można 24 designy, podzielona na 5 poziomów, różniących się rosnącą trudnością. Na poziomy 1-4 przypada po 6 designów (chociaż część jest w 3 wersjach – dla Reacta, Vue i Angulara), na razie nie ma żadnego designu na poziomie 5. Stwierdziłem, że nie będę szaleć i wezmę sobie coś prostego. Mój wybór padł na formularz wprowadzania danych do płatności z poziomu 2.
Zapoznałem się więc z briefem projektu, a następnie ściągnąłem tzw. starter. W jego środku znajdował się design w formacie Figmy oraz katalog ze startowym kodem. Jeśli chodzi o sam design – trudno mieć tu jakieś zastrzeżenia. Jest podział na widok mobilny, tabletowy i desktopowy, jest nawet prosty styleguide, opisujący podstawowe kolory i stany elementów. Natomiast mam pewien problem z zaproponowanym kodem startowym. Jego struktura plików wyglądała tak:
├── index.html ├── package.json ├── package-lock.json ├── public │ ├── files │ ├── images │ │ └── javascript.svg │ └── json ├── README.md ├── src │ ├── global-scripts │ │ ├── main.js │ │ └── scripts │ │ └── counter │ │ └── counter.js │ ├── global-styles │ │ ├── styles │ │ │ ├── fonts.scss │ │ │ ├── normalize.scss │ │ │ └── root.scss │ │ └── style.scss │ └── pages │ └── home-page │ ├── scripts │ │ └── home-page.js │ └── styles │ └── home-page.scss └── vite.config.js
Sporo się tutaj dzieje.
- Mamy tutaj do czynienia z projektem przeznaczonym do uruchamiania przy pomocy Node’a/npm-a.
- Całość pochodzi też z jakiegoś repozytorium gita – na co wskazuje plik
.gitignore
. - Dodatkowo plik
vite.config.js
wskazuje na to, że jest to projekt wykorzystujący Vite. - Sam kod jest podzielony na skrypty i style globalne oraz na style dla poszczególnych podstron. W przypadku tego startera istnieje tylko jedna podstrona – główna (
home-page
).
Przyznam się szczerze, że zaskoczyła mnie aż tak skomplikowana struktura plików. Wydaje się zdecydowanie zbyt złożona jak na projekt dość prostego formularza płatności. Co więcej, mocno kontrastowała też z przykładowym projektem, który znajdował się w starterze – przyciskiem zliczającym kliknięcia w siebie (screenshot). Może jestem nadmiernym minimalistą, ale… to można było serio zmieścić w trzech plikach: 1 HTML, 1 (S)CSS i 1 JS. I tak, wspominam o SCSS-ie, ponieważ starter zakłada, że używać będziemy Sassa. I jeśli 2 lata temu, czy nawet rok temu byłbym skłonny przyznać temu rację, tak w 2023 natywny CSS jest na tyle potężny, że Sass na dobrą sprawę sprawdza się głównie jako system modułów, pozwalający pisać style z podziałem na pliki. Bo nawet takie killer ficzery jak zagnieżdżanie powoli docierają do CSS-a. I tym bardziej, że – jak już wspominałem – projekt formularza płatności nie jest jakoś szczególnie skomplikowany i jest możliwy do ogarnięcia spokojnie przy pomocy czystego CSS-a.
Z ciekawości sprawdziłem też, jak wygląda starter w przypadku projektu z 1. poziomu. Jest ten sam. Wydaje mi się, że dobrym rozwiązaniem byłoby przygotowanie starterów oddzielnie dla każdego poziomu. Bo dla osób, które chcą po prostu zakodować prosty design, żeby w ogóle wsiąknąć w temat, nagłe zderzenie z ekosystemem npm-a i Vite może odrzucić od webdevu. Zwłaszcza, że projekt takiej choćby karty na blogu naprawdę nie wymaga nic ponad 3 pliki. A zamiast Vite (które służyłoby tutaj wyłącznie do podglądu na żywo) można zasugerować odpowiednie dodatki do edytora kodu, np. Live Server.
Dodatkowo, w pliku README.md
znajduje się informacja, że więcej informacji o starterze znajduje się w bazie wiedzy. Postanowiłem zatem rzucić do niej okiem.
Baza wiedzy
Rozwieję od razu ten hitchcockowski suspens – nie znalazłem tam informacji o starterze. Obecnie w całej bazie wiedzy znajdują się tylko 3 artykuły. Dwa z nich traktują o importowaniu i eksportowaniu rzeczy z Figmy. Trzeci z kolei – o dobrych praktykach przy pisaniu SCSS-a.
Same opisane tam praktyki są jak najbardziej w porządku. Problemem jest raczej to, jak zdawkowo są opisane. Brakuje też większych przykładów. Jedną z zasad jest choćby to, że należy dzielić kod na komponenty. Jak najbardziej się zgadzam – komponenty to podstawa współczesnego webdevu! Problem polega na tym, że całą kwestię podziału strony na komponenty sprowadzono do prostego stwierdzenia:
Komponenty mogą być różne – może być to cała sekcja, bądź jej fragment. Jeden komponent może też zawierać w sobie inne komponenty. Nie ma tutaj reguły – to ty decydujesz, jaka część widoku stanie się komponentem.
I tak, ten fragment jest jak najbardziej prawdziwy. Problem polega na tym, że początkujący jest, well, początkujący. Podziału na komponenty też trzeba się nauczyć i trudno samemu od razu „poczuć”, jak to należy robić. Baza wiedzy wspomina wcześniej o BEM. Aż się prosi, żeby przygotować jakikolwiek prosty przykład podziału strony na komponenty z wykorzystaniem tej metodyki. Zwłaszcza, że o komponentyzacji i modularności napisano już – dosłownie – książki.
Wśród dobrych praktyk SCSS-owych jest też jedna, która mnie zastanawia: używaj zmiennych CSSowych (sic!)
. Ta praktyka nasuwa mi na myśl jedno: że faktycznie SCSS ma służyć głównie jako system modułów dla CSS-a. Problem w tym, że obecnie mamy lepsze narzędzia od tego. A wysnuwam taki wniosek, ponieważ SCSS ma też swoje zmienne. I różnica między nimi a zmiennymi w CSS-ie jest zasadnicza. Zmienne w SCSS-ie zostają zamienione w trakcie transpilacji SCSS-a do CSS-a na statyczne wartości. Z kolei zmienne w CSS-ie są dynamiczne, ich wartość zależy od obecnego środowiska, w którym uruchamiana jest strona. Dobrym przykładem SCSS-owej zmiennej może być kolor fonta. Nie jest to coś, co zmienia się w trakcie działania strony, więc nie zyskujemy za bardzo, robiąc z tego CSS-ową zmienną. Z kolei dobrymi kandydatami na zmienne w CSS-ie mogą być np. obliczanie odstępów między elementami przy pomocy jednostek zależnych od viewportu albo zmienne środowiskowe. Dlatego uważam, że obydwa typy zmiennych mogą koegzystować w radosnej hipisowskiej komunie i prawdziwą sztuką jest nie wykluczyć z użycia jakiś, a umieć uzasadnić, czemu w danej sytuacji wykorzystało się akurat ten.
Warto też zwrócić uwagę na aspekt dostępności bazy wiedzy. Fragmenty kodu prezentowane są w niej jako screenshoty. To oznacza, że nie da się ich skopiować, nie da się ich łatwo odpalić na choćby Codepenie, ani nie da się w prosty sposób poprawić ich kontrastu (np. przeklejając je do swojego edytora albo stosując tryb wysokiego kontrastu w przeglądarce). Co więcej, atrybuty [alt]
dla tych fragmentów kodu duplikują informacje z podpisów pod screenshotami. Dobrze, że nie ma sekcji o dobrych praktykach dostępności, bo nadmiar ironii byłby zbyt duży.
Review
Pozostała zatem ostatnia rzecz do sprawdzenia: review zakodowanego designu. Co oznaczało, że muszę go zakodować. Tak też zrobiłem. Z oczywistych względów nie przykładałem się zbytnio, próbując sprawdzić, jakie błędy zostaną wykryte. A było ich trochę, m.in.:
- niewłaściwa struktura nagłówków w HTML-u,
- niepoprawne użycie elementu
section
, - ominięcie elementu
main
, - niewłaściwe wartości atrybutów
[alt]
, - niepoprawne użycie elementów
label
, - brak zastosowania BEM,
- błędy w logice kodu JS (walidacja formularza przepuszczała część niepoprawnych danych),
- stosowanie
let
ivar
, - stylowanie po
[id]
, - brak sensownego podziału kodu SCSS,
- niedokładne odwzorowanie designu (chociaż tutaj od razu przyznaję, że to był ten element, na którym mi zależało najmniej).
Słowem: nasi starzy, dobrzy znajomi z WebKrytyka! Byłem ciekawy, ile z nich zostanie wyłapanych. Skończyłem projekt w piątek późnym wieczorem i postanowiłem go wysłać. I tutaj zaciekawiła mnie jedna rzecz: nie jest wymagane używanie gita. W kontekście całego starteru (z plikiem .gitignore
!) brak tego wymogu nieco mnie zdziwił, ale nie przywiązywałem do tego większej wagi. Zwłaszcza, że w formularzu do wysłania skończonego zadania należało załączyć zipa z kodem gotowej strony. Problem w tym, że tuż poniżej należało podać adres wersji demonstracyjnej projektu. I była tutaj lista proponowanych usług: Vercel, GitHub Pages oraz Netlify. Każda z nich najlepiej działa z gitem lub wręcz nie działa bez niego. Nie wiem, czy nie lepiej byłoby wymagać używania gita i zamiast paczki przesyłać po prostu link do repozytorium. W każdym razie postawiłem stronę.
Posłałem projekt i review przyszło w poniedziałek. Szybko. Kliknąłem w link prowadzący do review i znalazłem się w dokumentach Google’a. Zaskoczyło mnie to, ponieważ – jakby nie patrzeć – review jest jednym z głównych ficzerów IA. Spodziewałem się istnienia jakiejś zintegrowanej formy review wewnątrz samej platformy. Na dobrą sprawę uważam, że lepiej działałoby już nawet przesyłanie i reviewowanie projektów wewnątrz jakiejś organizacji na GitHubie czy np. prywatnej instancji Gitei.
Niemniej najważniejsza jest kwestia samego review. Zastanowił mnie już sam tytuł – Kopia Najczęstsze błędy – Formularz wprowadzania danych do platnosci. Wskazuje bowiem na fakt, że całe review zostało stworzone na podstawie jakiegoś szablonu. I to, niestety, widać. Niektóre punkty nie odnoszą się do projektu, który przesłałem, np. Stan inputów przed wprowdzeniem danych jest niezgodny ze Styleguidem – nazwa pola powinna byc na caly input i przeskakiwac dopiero przy wprowadzaniu danych.
. W mojej wersji jak najbardziej nazwa pola jest na cały input i zmniejsza się dopiero przy wpisywaniu danych. Co więcej, niektóre z uwag stwierdzają, że wykonałem coś niezgodnie z briefem, podczas gdy w briefie tego po prostu nie ma. Jednym z tego typu punktów było wskazanie, że elementy interaktywne powinny mieć animację przy pomocy transition
. Brief o tym nie wspomina, mówi jedynie o odpowiedniej obsłudze elementów interaktywnych. Część punktów z review jest też mocno zdawkowa i tak naprawdę nie wskazuje, na czym polega błąd. Weźmy dwa przykłady:
Błędne RWD – nie chodzi o to, żeby od razu poniżej 834px pokazywać wersję na mobile. Content powinien się skalować, a dopiero od jakiegos momentu przyjmowac wersję przygotowaną przez design
Co to znaczy od jakiegoś momentu
? Na jakiej podstawie mam zdecydować i na jakiej podstawie reviewer stwierdzi, że jest to „ten moment”?
Niepoprawnie shermetyzowany kod
Co to tak naprawdę znaczy? Ten punkt co prawda jest wyjaśniony (do pewnego stopnia) w dobrych praktykach, ale mimo wszystko przydałby się przykład bezpośrednio tutaj, w review, odnoszący się do tego konkretnego kodu. Rzucanie samymi hasłami w review dla mnie osobiście mija się z celem. Zawsze staram się uargumentować swoją opinię, pokazując przykłady błędów oraz proponowane możliwości poprawy. Co prawda na końcu review jest wspomniane, że można dopytać o szczegóły na forum dyskusyjnym IA, ale… po co? Gdyby zamiast bardzo ogólnego, generycznego review, zrobić je dogłębnie, nie istniałaby (albo przynajmniej zostałaby mocno zminimalizowana) potrzeba późniejszego dopytywania się. No i – jakby mimo wszystko trzeba było dopytać, to forma pracy z wykorzystaniem wspomnianych GitHuba lub Gitei bardzo by to ułatwiała.
Co mnie jednak najbardziej uderzyło, to fakt, że większość review sprowadzała się do porównywania zakodowanego przeze mnie designu ze screenem projektu. Sensowność pixel perfect to temat na osobny wpis i nie chcę tego tutaj poruszać – zwłaszcza, że faktycznie, nie przykładałem się jakoś szczególnie do samego wyglądu. Bardziej zależało mi na review kodu. Ale tego akurat nie otrzymałem. W całym review nie ma ani słowa o kodzie HTML czy kodzie JS. Wspomina się jedynie o kodzie SCSS i to w kontekście dobrych praktyk z bazy wiedzy. Wszystkie problemy z semantyką, dostępnością czy wykorzystaniem przestarzałych mechanizmów w JS-ie zostały całkowicie pominięte.
Opcji dawania review, niestety, nie sprawdziłem, bo wciąż nie działa.
Społeczność
Jest jeszcze jedna część IA: forum dyskusyjne/komunikator zbudowany na circle.so. Trochę mnie to zaskoczyło, ponieważ strona główna IA wspomina o grupie na FB. Ale to akurat mało istotne. Chciałem jedynie sprawdzić, jak żywa jest społeczność. I, prawdę mówiąc, mam mieszane odczucia. Rozumiem, czemu takie miejsce do wymiany doświadczeń powstało, ale w moim odczuciu duplikuje istniejące grupy na FB, Discordy oraz fora dyskusyjne. Jedynie dyskusje wokół review, moim zdaniem, miałyby sens wewnątrz takiego forum, ale znów – czy platforma typu Gitea nie byłaby lepsza? Co jednak dziwne, akurat kanał przeznaczony do rozmowy o otrzymanych review jest jednym z najcichszych.
Na innym kanale z kolei znalazłem taki kwiatek:
Tak, jak w pracy – jest zadanie do wykonania, a jak je zrobic to juz umiejetnosci i googlowanie 😀
I znów: mam mieszane uczucia. Z jednej strony się zgadzam, bo umiejętność szukania informacji jest jedną z najważniejszych w zawodzie webdevelopera. Z drugiej: najpierw trzeba wiedzieć, czego szukać. No i skoro się jest już platformą dla początkujących i ma się bazę wiedzy, to byłoby fajnie, gdyby w tej bazie wiedzy można było znaleźć nieco więcej, niż kilka praktyk pisania kodu SCSS.
Podsumowanie
IA ma bardzo fajny pomysł, ale – na razie – wykonanie pozostawia naprawdę sporo do życzenia. Osobiście raczej szedłbym w bardziej zintegrowane rozwiązania, choćby oparte na wspomnianej Gitei. No i warto rozbudować bazę wiedzy, dać tam więcej przykładów, może nawet jakieś interaktywne tutoriale z dzielenia strony na komponenty. To by też pośrednio rozwiązywało problem z ogólnikowymi review – bo istniałyby materiały, do których można odsyłać.
Osobiście odnoszę wrażenie, że IA jest w naprawdę wczesnym dostępie i musi jeszcze sporo dojrzeć, by być dobrym narzędziem do nauki.
Aktualizacja #1 (06.04.2023)
Zauważyłem, że na IA pojawiły się tzw. ścieżki nauki. Pokazują one, jak stworzyć projekty przypominające istniejące już serwisy, takie jak Spotify, Twitter czy YouTube. Każdy ekran/komponent do zakodowania stanowi oddzielny etap takiej ścieżki i jest dodatkowo podzielony na lekcje.
Co ciekawe, równocześnie zniknęła całkowicie polska wersja platformy czy linki do bazy wiedzy. Teraz całość jest po angielsku i większość informacji została przeniesiona do poszczególnych lekcji w ścieżkach. Chociaż, prawdę mówiąc, nie zauważyłem, żeby zawierały one jakoś zdecydowanie więcej informacji. Ich jest mniej więcej tyle samo, po prostu zostały inaczej podzielone i przedstawione. Jedyny dodatek to dodatkowe przykłady dotyczące konkretnego etapu. To zdecydowanie krok w dobrą stronę, ale poszczególne lekcje są często bardzo krótkie (np. jedną z nich można streścić do „obecnie designy robi się w Figmie”), a i zaproponowane w nich rozwiązania pozostawiają wiele do życzenia.
Przyjrzałem się ścieżce dotyczącej tworzenia klona Spotify i pierwszy etap polega na zakodowaniu karty podglądu utworu. Jej miniaturkę można zobaczyć na stronie opisującej kurs, ale gdyby ta była za mała, przytaczam opis: górna część komponentu to obrazek promujący piosenkę, poniżej znajduje się jej tytuł wraz z czasem trwania oznaczonym dodatkowo ikonką zegara. Poniżej tych informacji znajduje się miniaturka okładki płyty, z której pochodzi piosenka, wraz z jej nazwą, rokiem wydania, liczbą piosenek i łącznym czasem trwania. W jednej z lekcji zaproponowana została przykładowa struktura HTML:
<div class="song-preview-card">
<div class="song-preview-card__image-container">
<img src="/images/song-cover.jpg" class="song-preview-card__image" alt="song cover" />
</div>
<div class="song-preview-card__content">
<div class="song-preview-card__title">RiRi</div>
<div class="song-preview-card__artist-and-time">
<div class="song-preview-card__artist">Young Thug</div>
<div class="song-preview-card__time">
<div class="song-preview-card__time-icon-container">
<img src="/icons/clock.svg" alt="clock" />
</div>
<div class="song-preview-card__time-text">4:04</div>
</div>
</div>
<div class="song-preview-card__album-cover-and-info">
<div class="song-preview-card__album-cover-container">
<img src="/images/album-cover.jpg" alt="album cover" />
</div>
<div class="song-preview-card__album-info-container">
<div class="song-preview-card__album-info-text">Jeffery</div>
<div class="song-preview-card__album-info-dot-spacer">•</div>
<div class="song-preview-card__album-info-text">2016</div>
<div class="song-preview-card__album-info-dot-spacer">•</div>
<div class="song-preview-card__album-info-text">10 songs, 42 min</div>
</div>
</div>
</div>
</div>
Przyznaję, że dawno nie widziałem tak mocnego divitisu. Kod jest ewidentnie pisany wyłącznie po to, by uzyskać konkretny efekt wizualny, bez przykładania jakiekolwiek wagi do semantyki czy dostępności. Jedyne elementy, które nie są div
ami, to obrazki – które mają do tego niepoprawnie dobrane atrybuty [alt]
. Także nazewnictwo oparte na konwencji nazewniczej BEM jest, moim zdaniem, mocno naciagane. Element o klasie .song-preview-card__album-info-text
wskazuje na to, że można spokojnie podzielić to na dwa osobne bloki i zastosować tutaj mix. Całość mogłaby wyglądać np. tak:
<article class="song-preview-card">
<img src="/images/song-cover.jpg" class="song-preview-card__image" alt="">
<h2 class="song-preview-card__title">RiRi</h2>
<dl class="song-preview-card__artist-and-time description-list">
<dt class="description-list__key visually-hidden">Artist</dt>
<dd class="description-list__value">Young Thug</dd>
<dt class="description-list__key">
<img src="/icons/clock.svg" alt="Duration">
</dt>
<dd class="description-list__value">
<time datetime="PT4M4S">4:04</time>
</dd>
</dl>
<div class="song-preview-card__album-info album-info">
<img src="/images/album-cover.jpg" class="album-info__cover" alt="">
<dl class="album-info__details description-list">
<dt class="description-list__key visually-hidden">Album name</dt>
<dd class="description-list__value">Jeffery</dd>
<dt class="description-list__key visually-hidden">Released</dt>
<dd class="description-list__value">2016</dd>
<dt class="description-list__key visually-hidden">Duration</dt>
<dd class="description-list__value">10 songs, 42 min</dd>
</dl>
</div>
</article>
Całość jest otoczona w article
, bo zgodnie ze specyfikacją służy on do oznaczania niezależnych od reszty strony widgetów – czyli m.in. tego typu kart. Każdy artykuł powinien mieć nagłówek, ale tak się składa, że mamy idealnego kandydata – tytuł piosenki! Stosuję tutaj h2
, bo zakładam, że nie będzie to główny nagłówek na stronie, ale jego poziom najlepiej będzie ustalić w szerszym kontekście całej strony. Pozbyłem się też kontenerów wokół obrazków, bo równie dobrze można ostylować same obrazki. Dla obrazków piosenki i albumów dałem puste [alt]
, bo nie dodają żadnej istotnej informacji dla użytkowników czytników ekranowych, więc można je uznać za ozdobniki. Gdyby jednak obrazki te były niezbędne do zrozumienia samej piosenki, to wówczas te atrybuty powinny zawierać dokładne opisy tego, co się znajduje na obrazkach, nie zaś – generyczną informację, że to okładki. Z kolei zegarek oznaczający długość piosenki dostał tekst alternatywny o treści „Duration” – bo to reprezentuje, a nie zegar, na co wskazywała pierwotna wartość atrybutu [alt]
. Dla samego czasu trwania użyłem także elementu time
ze składnią do oznaczania czasu trwania. Całkowicie zbędne, ale jak już szaleć, to szaleć! Natomiast zarówno informacje o piosence, jak i albumie, wsadziłem do listy dl
, a więc do elementu stworzonego specjalnie dla list, w których można wyróżnić jakąś wartość i opis dla niej (jej definicję). W niektórych przypadkach dla definicji dodałem klasę .visually-hidden
, dzięki czemu użytkownicy m.in. czytników ekranowych dostaną dodatkowy kontekst, który w innym wypadku wynika z designu samego komponentu. Można się też zastanowić, czy dla informacji o albumie nie dodać osobnej sekcji z nagłówkiem h3
:
<section class="song-preview-card__album-info album-info">
<h3 class="album-info__title visually-hidden">Album info</h3>
<img src="/images/album-cover.jpg" class="album-info__cover" alt="">
<dl class="album-info__details description-list">
<dt class="description-list__key visually-hidden">Album name</dt>
<dd class="description-list__value">Jeffery</dd>
<dt class="description-list__key visually-hidden">Released</dt>
<dd class="description-list__value">2016</dd>
<dt class="description-list__key visually-hidden">Duration</dt>
<dd class="description-list__value">10 songs, 42 min</dd>
</dl>
</section>
Przy okazji usunąłem ukośniki z elementów img
, bo nawet walidator informuje, że to bez sensu.
Jak widać na powyższym przykładzie, z HTML-a można wycisnąć zdecydowanie więcej, niż zrobiono to w oryginalnej propozycji. Po zmianach w kodzie został tylko jeden div
(lub wręcz żaden, w wersji z dodatkową sekcją). Szkoda, że w kursie pokazywana jest wersja zrobiona po linii najmniejszego oporu. To trochę nasuwa mi podejrzenie, że w tym kursie wystąpi ten sam problem, co w wielu innych opisywanych na WebKrytyku – skupienie się wyłącznie na wizualnym aspekcie tworzenia stron WWW, bez zwracania najmniejszej uwagi na dostępność czy choćby semantykę.
Dzieki za wpis. Nie podoba mi sie forma reklamowania Invo swojej platformy za co maja u mnie mocną czerwoną flagę. Oglosili np. Ogloszenie o prace na justjoin.it i uwaga juz po 4 h od wyslania CV dostalam zwrotnego emaila, ze moje portfolio jest niewystarczajace, ale zapraszaja mnie do swojej platformy. Oferta jest tak sformulowana, zeby pasowala do wiekszosci potencjalnych juniorow. Ich projekty na platformie na ten moment (marzec 2023) sa mniej rozbudowane od moich (brakuje najwyzszego poziomu) i mam powazne przypuszczenia, ze to ogloszenie bylo tylko forma reklamy nowej platformy (kolezanka dostala takiego samego emaila). Pozmysl fajny, ale podejscie slabe.
Też dostałem taką odpowiedź, a podałem tylko email do kontaktu 😀 To już nie jest agresywny marketing tylko pospolite k….two… Autorowi artykułu dziękuję za poświęcenie swojego czasu bo zaoszczędził dużo mojego 🙂
Aktualnie strona główna projektu jest… zhackowana. Wyświetla się pusta strona, ale w Google widać chińskie znaczki ^^
Faktycznie. Co jednak ciekawsze, część przeznaczona dla użytkowników (https://platform.invo.academy/ ) wydaje się działać normalnie.