O sa vorbesc in acest articol despre cum influenteaza folosirea JavaScript utilizabilitatea, accesibilitatea si experienta utilizatorilor pentru interfete web, greseli facute atunci cand se foloseste JavaScript si cum pot fi ele evitate.
1. Utilizabilitate
In general, atunci cand vorbim de utilizabilitate si JavaScript, se poate spune ca atunci cand este folosit cum ar trebui, JavaScript sporeste foarte mult utilizabilitatea unei interfete. Totusi, odata cu aparitia framework-urilor JavaScript, si, astfel, usurinta cu care se pot folosi diverse animatii JavaScript (in general, mai toate librariile au un “motor” de animatii – care fie vine odata cu libraria, fie este disponibil ca un plugin separat), s-a ajuns la o abuzare a acestor efecte si, in loc ca ele sa usureze folosirea interfetei, mai degraba o ingreuneaza. Imi vine aici in minte exemplul unui site mare de torrente romanesc, care are implicit activata o optiune care duce la o tranzitie a culorii link-urilor atunci cand mouse-ul trece peste link-uri. Ca sa faca lucrurile sa stea si mai prost, durata acestei animatii este si destul de mare iar cele doua culori intre care se face tranzitia au nuante atat de diferite incat, pe langa faptul ca nu aduce absolut niciun beneficiu dpdv al utilizabilitatii, devine mai degraba deranjant si distrage atentia. Ca sa va faceti o idee, am pus aici un exemplu de astfel de efect.
Totusi, asta nu inseamna ca animatiile sunt rele si nu ar trebui folosite, doar ca acesta e un exemplu prost de folosire. Un mod de folosire util al animatiilor poate fi vazut pe prima pagina a blogului nostru (si pe prima pagina a fiecarui articol). Astfel, de multe ori, la urmarirea legaturilor catre ancore din acelasi document, uneori utilizatorii au impresia ca au ajuns pe o cu totul alta pagina. Insa o derulare a paginii pana in locul unde este ancora, il ajuta pe utilizator ca nu a intrat pe o pagina noua, ci ca a ramas pe aceeasi pagina.
Si daca tot vorbim de utilizabilitate, un site interesant este Bad Usability Calendar – niste exemple de folosire a unor concepte in speranta ca sporesc utilizabilitatea unei interfete (este folosit ca exemplu un calendar), dar care insa produc un efect opus.
2. Accesibilitate
Daca la utilizabilitate lucrurile stateau destul de ok – in general folosirea corecta a JS creste utilizabilitatea unei interfete -, la accesibilitate lucrurile stau destul de prost. Cea mai mare greseala pe care o fac designerii/programatorii de interfete web este faptul ca nu iau in vedere faptul ca exista utilizatori care nu au JS activat. Poate va intrebati cum se poate ca in ziua de azi sa existe persoane care sa nu aiba un browser care suporta JavaScript. Pe langa faptul ca sigur exista si astfel de persoane, nu trebuie ca browser-ul sa nu suporte JavaScript: exista utilizatori care dezactiveaza de buna voie JavaScript. Luati ca exemplu populara extensie Firefox NoScript, care in acest moment are mai mult de 36 de milioane de instalari descarcari in total si peste un milion de descarcari saptamanale.
In plus, chiar si Gmail – unul dintre cele mai populare exemple de aplicatii 2.0, care foloseste intensiv JS, ofera o varianta pur HTML pentru utilizatorii care nu au JS activat. Desigur, exista site-uri care chiar nu pot functiona fara JS – de exemplu, editoarele de documente online – dar pentru orice aplicatie care nu se defineste ca fiind RIA, ar trebui ca functionalitatea de baza sa fie disponibila fara JS.
Oricum, faptul ca sunt ignorati acesti utilizatori vine ca urmare a faptului ca nu este urmarita adaugarea progresiva de functionalitate (eng. progressive enhancement) interfetei: ar trebui inceput cu markup-ul html care ar trebui sa fie semantic, apoi acest markup sa fie sporit cu ajutorul CSS, si abia apoi adaugate functionalitati cu ajutorul JS. Exemple proaste de site-uri care nu sunt accesibile in lipsa de JavaScript ar fi (tineti minte ca NU vorbim despre cat de utile sau nu sunt site-urile, ne legam strict de accesarea lor cu JavaScript dezactivat):
- site-ul de stocare de fotografii Ipernity nu permite nici macar logarea utilizatorilor in absenta JavaScript, sau inregistrarea de conturi folosind OpenID
- site-ul Orange Romania (mai exact, aceasta pagina) – contine div-uri ascunse cu detaliile beneficiilor, care erau afisate doar cu JS.
Cum putem evita astfel de greseli? Mai intai, problema de la Ipernity (dar care poate fi intalnita pe o multime de site-uri) poate fi evitata setand legaturile ancorelor catre adrese reale – este posibil sa folosim, pe partea de server-side, un acelasi script si doua view-uri diferite pentru a implementa functionalitatea dorita, iar framework-urile de tip MVC pentru limbaje ca PHP, Python, Ruby, fac acest lucru aproape trivial – in loc de celebrele # si javascript:void(0);. Dar daca vrem sa implementam o functionalitate care are neaparat nevoie de JavaScript, putem macar sa nu afisam elementele respective de interfata atunci cand JS nu e activat. Avem aici cel putin doua posibilitati: le ascundem cu CSS (un simplu display: none ar trebui sa fie suficient) sau injectam elementele respective in DOM dinamic – deci numai daca JS este activ.
Cat despre a doua problema – continutul ascuns, care devine vizibil numai la declansarea unui eveniment – cu toate ca este folosit des si nu degeaba – se conserva foarte mult spatiu pe ecran daca nu afisam informatiile neesentiale decat atunci cand utilizatorul are nevoie de ele – solutia este tot simpla si am mai precizat-o mai sus: lasam elementul vizibil si il facem invizibil prin CSS. Ca sa fim clari, CSS-ul care face elementele invizibile ar trebui introdus in pagina tot cu JavaScript. Si pentru aceasta solutie avem doua posibilitati:
- putem crea un fisier separat CSS, pe care il inseram in pagina cu JavaScript – fie folosind document.write, fie manipuland DOM-ul:
//intr-un tag script, in sectiunea head
document.write('<link rel="stylesheet" type="text/css" href="numai.daca.js.e.activ.css">');
//sau oriunde in pagina, dar de preferat tot in head
var style = document.createElement('link');
style.type='text/css';
style.rel='stylesheet';
style.href='numai.daca.js.e.activ.css';
document.getElementsByTagName('head')[0].appendChild(style);
- sau, punem tot CSS-ul intr-un singur loc si adaugam o clasa elementului HTML, cu ajutorul JS:
/* in stylesheet */
div.ascuns {
/* daca nu avem JS, elementul e vizibil */
}
.js div.ascuns {
/* numai daca avem JS, elementul va fi ascuns */
display: none;
}
// intr-un tag script, in head-ul paginii
document.getElementsByTagName('html')[0].className='js';
O alta problema legata de utilizabilitatea interfetelor cand se foloseste JS este faptul ca se presupune ca utilizatorul are la dispozitie atat mouse (sau touchscreen, sau un alt dispozitiv cu ajutorul caruia se pot declansa evenimentele de tip click) cat si tastatura. Pentru situatii cand nu este disponibil decat unul dintre acestea nu exista intotdeauna solutii, insa in general – pentru formulare, in loc sa se adauge ascultatori la click pe butoanele de submit ar trebui sa se adauge ascultatori la submit pe form, iar pentru elementele care suporta evenimente de tip change, ar trebui folosit mai degraba onChange decat onKeyUp/onKeyDown. Exemple mai amanuntite in link-urile de la sfarsitul articolului
3. Experienta utilizatorului
In sfarsit, daca toate problemele legate de utilizabilitate si accesibilitate sunt rezolvate, exista in general un factor care poate afecta negativ experienta unui utilizator: viteza cu care se incarca o pagina in browser (un articol recent spune ca o incarcare a unei pagini mai lunga cu jumatate de secunda duce la pierderea a 20% din trafic). Cum influenteaza JS asta? Toate browserele descarca in paralel elementele externe paginii, mai putin fisierele CSS si fisierele JS. Astfel, daca folositi prea multe fisiere JS diferite, si mai ales din alte domenii, timpii de incarcare ai paginii vor avea de suferit (si astfel, si numarul de utilizatori). Ca dovada aveti doua exemple (primul, al doilea) din care reiese ca fisierele JS nu sunt descarcate in paralele. In primul exemplu, durata de descarcare a fiecarui script va fi minim o secunda (este vorba de un script PHP care doarme o secunda dupa care intoarce cotinutul), iar in al doilea caz durata ar trebui sa fie mult mai mica (ca dovada ca in primul exemplu durata mare de incarcare nu este de la continutul/dimensiunea fisierului JS, ci din cauza ca la intalnirea unui fisier JS extern incarcarea paginii este oprita pana cand acesta este descarcat).
Solutia? Daca o pagina nu se bazeaza extensiv pe JS sau nu este RIA, ar trebui ca toate tag-urile script care duc catre fisiere externe sa fie puse in fisierul HTML cat mai jos in document (de preferat, inainte de </body>).
Acestea fiind spuse, de data viitoare o sa trecem la crearea de plugin-uri MooTools si jQuery.
Link-uri utile:
- JavaScript libraries vs. Usability
- Creating Accessible JavaScript
- Accessibility of AJAX Applications
- AJAX, JavaScript and accessibility
- Why Front End Performance Matters to Everyone, Not Just the High Traffic Giants
The Cele mai bune practici JavaScript by Interfeţe Web, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 Romania License.
