Uneori, când folosim internetul, întâmpinăm obstacole. Aproximativ acum un an discutam despre cele mai recente metodologii web pentru probleme de conectivitate la internet, tatonând în același timp ideea unei aplicații web ce depășește conturul unui browser de internet. De data aceasta, vom explora alte provocări comune în domeniul aplicațiilor web, pentru a ne concentra asupra cauzelor mai puțin evidente din spatele acestora.
Acest articol are scopul de a arăta că atunci când o aplicație web nu funcționează în parametri optimi, de multe ori nu e din cauza browserului de internet pe care îl folosim, nici din cauza telefonului sau laptopului; nici măcar din cauza javascriptului ce rulează în acea aplicație (și care e de multe ori primul suspect).
Uneori, e pur și simplu simplul HTML, sau mai exact lipsa unui HTML care să nu fie doar valid, ci și semantic.
HTML5, grupul de standarde HTML noi ce a apărut acum câțiva ani, a adus noi noțiuni limbajului și în același timp o concentrare asupra aspectului semantic al acestuia.
După publicarea acestor noi standarde, diverse variații ale pozei de mai jos au circulat mai mult timp prin publicațiile și forumurile din domeniu.
Din nefericire, încă din acea perioadă, o mare parte din dezvoltatorii de aplicații web își epuizau aproape total resursele concentrându-se pe multitudinea de tehnologii javascript, și încercând să îmblânzească cantitățile crescânde de cod CSS.
Astfel, acel aspect semantic al limbajului HTML a rămas în general fie o noțiune explorată superficial sau parțial în cel mai bun caz, fie un punct complet ignorat sau de prioritate foarte redusă în cel mai nefericit caz.
Pentru mult timp, părerea generală legată de HTML-ul semantic a fost că joacă un rol important în accesibilitatea web de bază (disciplina de Accessibility), și că ajută motoarele de căutare să ne găsească aplicația web mai ușor (disciplina de SEO sau Search Engine Optimization).
Cu scopul final de a face web-ul mai accesibil, noțiunea de Accessibility este definită în detaliu într-o colecție de specificații ce însumează instrucțiuni sau reguli după care se pot construi, respectiv evalua aplicațiile web, ținând cont de cât de ușor se pot înțelege și folosi acestea într-un set amplu de scenarii. Pentru mult timp, părerea generală legată de Accessibility s-a rezumat la compatibilitatea paginilor și aplicațiilor web cu dispozitive și tehnologii ajutătoare de tip screen-reader, și uneori și la compatibilitatea aplicațiilor de a fi utilizate și cu ajutorul tastaturii.
Însă o dimensiune din Accessibility ce rămâne deseori necunoscută, este faptul că aceasta nu presupune doar utilizabilitate esențială pentru persoane cu dizabilități și un surplus de ușurință generală prin compatibilitatea cu tastaturi.
De fapt, înseamnă și utilizabilitate esențială și surplus de ușurință pentru o mare parte din scenariile când aplicațiile web sunt folosite pe telefoane sau tablete. Datorită popularității acestor dispozitive din ultimii ani, această dimensiune a căpătat chiar mai multe laturi, la rădăcina cărora se află HTML-ul semantic. Iar pentru a înțelege aceste aspecte și motivele din spatele lor, vom contura mai întâi contextul în care s-au format.
HTML, CSS și Javascript, triunghiul fundamental al webului.Ordinea în care am enumerat aceste limbaje este de obicei cea pe care o găsim atunci când citim despre ele în tutoriale sau în cărți, fiind probabil sortate cronologic. În schimb dacă le sortăm după popularitate, această listă devine JS, CSS și HTML.
Pentru a înțelege diferența dintre cei doi termeni, putem lua ca exemple de aplicații web Gmail, Facbook, Twitter; iar când spunem site web, ne gândim la o pagină de prezentare de complexitate scăzută, cu un număr redus de ecrane, și în care interacțiunea cu utilizatorul se rezumă de cele mai multe ori la o navigație și un formular de contact.
Acesta nu se bucură nicidecum de aceeași popularitate în ceea ce privește tooling, articole, metodologii, dezbateri și subiecte de conferințe, comparat cu primele două limbaje.
La prima vedere, HTML este doar un simplu (plain) text pasat dintr-o parte în alta, de la un server web la un client și invers.
Dacă explorăm mai mult, înțelegem că acel simplu text este rezultatul adesea puternic procesat și personalizat al datelor, în forma finală pentru consum printr-un browser web. Iar dacă focalizăm cu adevărat, realizăm că primele două puncte nu sunt în totalitate valide.
HTML este - sau în mod ideal ar trebui să fie, în aplicațiile web - limbajul ce ne permite nu doar să servim informația într-un browser de internet, ci și să o structuram (de data aceasta nu vizual, ci în funcție de sens), să îi organizăm conținutul într-o ierarhie, și să-i marcăm sensul folosind tagurile (etichetele de conținut) limbajului.
Sensul informației… Pentru cine? Utilizatorii deduc sensul conținutului pe măsură ce îl citesc. De ce ar mai fi nevoie să îl interpretăm și să îl adnotăm în HTML?
Problema este că, mulțumită sabiei cu două tăișuri pe care o reprezintă natura webului de a fi atât de deschis, vast și permisiv, vom vedea în curând că în multe scenarii, dacă dispozitivele ce ne servesc acel conținut nu reușesc să "înțeleagă" și ele acel conținut înaintea noastră, atunci noi, oamenii, riscăm: a) în cel mai bun caz, să trebuiască să ne gândim mai mult pentru a o înțelege sau folosi, sau b) în cel mai rău caz, fie să ratăm complet acel conținut, fie să nu îl putem utiliza deloc.
De mai mult timp a existat o tendință tăcută de a scrie cea mai mare parte a codului HTML în doar două din cele aproximativ o sută de taguri disponibile: div și span.
Cu timpul, pentru primul tag a apărut bineînțeles și o expresie nostimă pentru această practică: div soup sau supă de divuri. Așadar ne vom permite să adăugăm, tot în glumă, o nouă expresie pentru aplicațiile ce sunt scrise folosind excesiv tagul span: span fest, sau festival de spanuri. Deși HTML este un limbaj de markup, de dragul acestei practici putem face o analogie cu limbajele de programare. Atunci când lucrăm în limbaje precum Java, nu obișnuim să scriem întregul cod al unei aplicații folosind tipul any pentru toate tipurile de date, proprietăți și variabile folosite.
În prezent, atunci când scriem HTML, frameworkurile și IDE-urile cele mai populare ne avertizează dacă codul scris nu este valid, dar nu și dacă este semantic. Și aparent, nu există consecințe pentru aceasta, sau cel puțin nu consecințe imediate.
Întrucât webul este în mod intenționat foarte permisiv privind HTML-ul, nu există erori stridente pentru acesta precum în javascript sau în (alte) limbaje de programare.
Nu va crăpa niciun compilator de cod și niciun avertisment nu va fi redat atunci când scriem acest HTML "gri", al cărui conținut este lipsit de înțeles, ocolind practic scopul propriu-zis al limbajului, de a marca/eticheta bucățile de conținut al unui document, în funcție de sensul acestora.
Cu toate acestea, există totuși consecințe ce sunt mai puțin aparente și mai puțin imediate, pe care le vom explora în următoarele șapte secțiuni:
Primul efect negativ - și, paradoxal, deși cel mai evident, cred că de multe ori cel mai omis - este conținutul (ce rezultă din acel HTML non-semantic) din punct de vedere al sensului.
Vă invităm la un mic exercițiu. Pentru un moment, ne propunem să ne gândim cine ar putea fi strămoșul documentului HTML. Unul dintre răspunsuri ar putea fi cartea, iar ca să fim și mai în temă, să ne gândim chiar la revistă.
Imaginați-vă cum ar fi dacă revista pe care o citiți chiar acum, nu ar avea copertă, titlu, autor și cuprins. Probabil că am obține o hârtie foarte întinsă.
O hârtie fără capitole, titluri și numere de pagini, unde textul nu este secționat în paragrafe în funcție de ideile exprimate, ci în secțiuni, poate în funcție de aspect. Pozele ar lipsi, sau dacă ar exista, cu siguranță nu ar fi etichetate. Fără citate, prescurtări, note de subsol sau tabele. Doar nesfârșite blocuri de text.
Închizând paranteza acestui exercițiu, practic exact aceasta obținem atunci când folosim HTML non-semantic, doar ca un context de redare de text manipulat de javascript și CSS.
Orientându-ne către al doilea efect negativ, avem penalizările în SEO, ce sunt cauzate direct de primul efect. Întrucât motoarele de căutare ierarhizează cuvintele cheie găsite în paginile web în funcție de ierarhia tagurilor HTML în interiorul cărora acestea se află, riscăm ca paginile web să fie omise complet de către motoarele de căutare. Prin urmare, dacă conținutul nostru nu poate fi găsit, atunci nu va fi utilizat.
Al treilea efect este accesibilitatea pentru dispozitivele și tehnologiile de tip screen reader.
Atunci când conținutul nostru este găsit, însă în mare parte indescifrabil, acesta nu va putea fi utilizat de către un segment din utilizatori. Dacă, de exemplu folosim tagul button în loc de tagul a (anchor) pentru a afișa butoane, dar care de fapt, redirecționează utilizatorul către alt document HTML (în loc să execute o acțiune în cadrul aceluiași document), atunci e foarte probabil ca acel conținut să devină ascuns, încât screen readerele nu îl vor identifica ca pe o poartă către alte resurse.
Alt exemplu este atunci când folosim tagul div (combinat cu atributul de click handler) în loc de tagul button, pentru a defini acțiuni ce pot fi săvârșite de către utilizator. Și în această situație, conținutul ar putea deveni complet neutilizabil, întrucât screen readerele nu vor identifica deloc acele elemente din pagină ce arată ca și niște butoane, dar sunt de fapt secțiuni de conținut.
Următorul efect constă în accesibilitatea pe dispozitive mobile pentru elemente de tip input.
Să considerăm următoarea situație: conținutul nostru este găsit de către utilizatori, este descifrabil, și permite acestora să introducă date manual. Dacă cea din urmă nu este implementată folosind HTML ce este și semantic și nu doar valid - folosind de exemplu, elemente de tip input ce nu folosesc atributul type corespunzător informației asociate - atunci conținutul poate încuraja utilizatorul să greșească.
Vom explora câteva din scenariile ce se mulează pe aceste condiții, în care cauza principală este tendința de a realiza întreaga implementare în javascript, iar în HTML, de a folosi doar inputuri generice de tip text, ce declanșează tastatura generică a unui dispozitiv mobil (cea care afișează simultan toate literele, cifrele și câteva simboluri).
O problemă de User Experience "îndrăgită" de utilizatori vine cu disconfortul de a tasta pe ecranul unui telefon cele 16 cifre ale unui card bancar, unde rezultatul unei greșeli de tastare duce la o tranzacție eșuată, iar de multe ori trebuie să completeze din nou și restul datelor. Practic în acest scenariu avem un input ce pare a fi numeric, dar a cărui valoare nu reprezintă un număr, ci o secvență de numere - numărul unui card bancar.
Soluția recomandată este să folosim inputul de tip text, dar împreună cu atributele pattern și inputmode, pentru a înștiința dispozitivul să afișeze tastatura cea mai potrivită:
Deși urmările sunt mai puțin grave ca în scenariul anterior, dacă folosim elemente input generice și pentru aceste situații, vom forța utilizatorul să efectueze mai mulți pași pentru a căuta în tastatura virtuală diverse simboluri. Dacă însă folosim input de tipul telephone, email, url respectiv number, putem declanșa tastatura corespunzătoare fiecărui tip de date:
În browserul de internet, modul reader este acea opțiune care redă doar conținutul text al unei pagini web, eliminând temporar meniuri, elemente de advertising, precum și alte elemente secundare conținutului propriu-zis.
În mod similar există și aplicații separate, al căror scop este exact consumul de articole cu ușurință, în cea mai simplă și mai aerisită formă (exemple: Pocket, Instapaper, și desființata Readability).
Pentru aceste scenarii de utilizare, atunci când nu se folosește HTML semantic, detalii esențiale din conținut - precum titlul, subtitlul, autorul, data publicării - pot fi omise complet de pe ecranul utilizatorului, indiferent dacă acesta folosește un laptop, telefon, sau chiar și un ceas inteligent.
Cu timpul, cantitățile mari de cod HTML ce nu este semantic devin tot mai dificil de înțeles, găsit, extins și modificat pentru dezvoltatori. Rețelele neuronale și asistenții virtuali precum Google Assistant, Siri (Apple), Alexa (Amazon) și Cortana (Microsoft) au devenit foarte populare în a ne procura răspunsuri (și mai nou în a efectua acțiuni în numele nostru), răspunsuri bazate pe documente web scrise în HTML. Deși la baza acestor procesări stau și multe alte tehnologii, lipsa HTML-ului semantic poate fi considerată un pas înapoi în a ajuta aceste servicii să funcționeze cât mai eficient pentru noi.
La fel ca în alte segmente ale industriei, în ultimii ani ne-am putut bucura de o evoluție impresionantă în disciplina de UI sau front-end web development, în special pentru limbajele javascript și CSS - două limbaje care acum 10-15 ani aveau un renume mult mai mic.
Ne-am concentrat atât de mult pe acestea încât am ajuns să avem librării și framework-uri mature și deosebit de populare ce ne propulsează înainte - această disciplină s-a maturizat astfel încât să nu trebuiască să reinventăm roata cu fiecare aplicație web nouă pe care o construim.
Dacă sentimentul general este că peisajul hiper dinamic pictat de javascript și CSS a început în sfârșit să se stabilizeze, poate că acum e o perioadă foarte potrivită în care să ne reamintim și de fundația acestor doua limbaje - HTML - și să ne ocupăm și de calitatea acestuia în aplicațiile noastre web.
Poate că proiectul pe care lucrăm în prezent nu este unul public, ci este destinat unui segment privat de utilizatori. Poate că am identificat deja acei utilizatori și știm că nu necesită utilizarea screen readerelor, tastaturilor, a telefoanelor mobile sau a tabletelor.
Dar sunt șanse mari ca în următorul proiect să avem nevoie să acoperim cel puțin una din aceste cerințe.
Pe lângă faptul că learning curbe-ul este mult mai mic comparat cu majoritatea librăriilor de javascript în care ne petrecem majoritatea timpului, și viteza în care lucrurile se schimbă în HTML este mai mică (cu câteva ordine de magnitudine) față de cea în care se schimbă aceste librării.
Mai mult, o aplicație SPA privată, menită să funcționeze doar pe platforma laptop/desktop nu va avea niciun detriment dacă va fi scrisă în HTML semantic.
Invitație la recapitularea elementelor HTML esențiale:
h1-h6, p ;
input, (cu tipurile și atributele posibile) împreună cu un label asociat ;
img, atunci când imaginea este parte integrală din conținut și nu are doar rol decorativ ;
div și span pentru secționarea conținutului de tip block sau text ;
elementele populare ce au sosit o dată cu HTML5: header, main, section, article, footer și aside ;
fig și fig caption pentru a oferi și context imaginilor ;
code, sub, sup pentru a marca diverse tipuri specifice de text ;
button, în loc de divuri cu click handlere ;
a în loc de butoane, atunci când butonul nu execută doar o acțiune, ci redirecționează utilizatorul către altă resursă ;
b, i și em pentru a diferenția între conținutul important și schimbările de ton ;
dl, dt și dd, pentru o listă de definiții sau o structură de tip key-value similară celei label-input, însă pentru text read-only ;
bonus: încercați și elementele introduse mai recent: dialog și menu ;
Cu toate că în ultimii ani brandurile mai mari au început deja să corecteze din scenariile enumerate mai devreme, dacă încă găsiți astfel de situații pe site-urile si aplicațiile pe care le folosiți în mod frecvent, vă încurajăm să anunțați firmele respective.
Puține lucruri ajută la prioritizarea rezolvării problemelor și a îmbunătățirii codului precum feedbackul direct de la utilizatori.
Pe data viitoare!