10 Most Common Misconceptions About User Experience Design

Permalink: Greseli de utilizabilitate frecvente si enervante

Sa incepem cu markup-ul HTML. Vrem ca in final sa obtinem cod care sa fie utilizabil atat in absenta JavaScript, cat si chiar in absenta CSS (asa cum am vorbit in articolul trecut, acesta este modul in care ar trebui programate marea majoritate a interfetelor web, cu mica exceptie a paginilor RIA), asadar am ales urmatorul mark-up:

<ul class="rating">
    <li class="now">Current rating: 2.4 stars</li>
    <li class="star star-5"><a href="rate.php?id=1&amp;stars=5">Give 5 stars</a></li>
    <li class="star star-4"><a href="rate.php?id=1&amp;stars=4">Give 4 stars</a></li>
    <li class="star star-3"><a href="rate.php?id=1&amp;stars=3">Give 3 stars</a></li>
    <li class="star star-2"><a href="rate.php?id=1&amp;stars=2">Give 2 stars</a></li>
    <li class="star star-1"><a href="rate.php?id=1&amp;stars=1">Give 1 star</a></li>
</ul>
<p class="message"></p>

Este vorba asadar de o lista neordonata, al carei prim element este rating-ul curent, apoi in ordine descrescatoare valorile posibile ale voturilor. Rezultatul este disponibil aici.

Sa trecem mai departe si sa stilizam acest markup cu ajutorul CSS. Nu o sa listez in articol intreg codul CSS, insa o sa fac un scurt rezumat al acestuia (fisierul este disponibil aici, rezultatul obtinut – aici). Daca va uitati atent pe pagina rezultata, sunt doua modificari:

• in primul rand, fiecarui element cu clasa now i-am adaugat, cu ajutorul atributului style (iar acesta este unul dintre putinele cazuri in care este preferat CSS inline), un width
• apoi, am adaugat fisierul extern stars.css

In fisier am adaugat imaginile efective de stele – ca background-uri:

• background-ul elementelor ul este format din stele goale
• background-ul elementelor cu clasa now este format din stele pline
• background-ul elementelor cu clasa star este format din stele pline, insa este pozitionat in asa fel incat nu se vede cand mouse-ul nu este deasupra listei de stele
• am folosit pseudo-clasa :hover ca sa:
  • ascundem rating-ul curent cand mouse-ul intra deasupra listei de stele (astfel ca daca vrem sa votam un numar mai mic de stele decat rating-ul curent, sa avem vizual imaginea numarului de stele – altfel, daca vrem sa acordam un numar mai mare de stele, acesta n-ar prezenta nicio problema)
  • sa afisam background-ul pentru fiecare link care duce catre rating-uri

O sa observati ca toate li-urile sunt pozitionate absolut – pentru ca stelele sa aiba acelasi punct de plecare. Restul codului CSS reseteaza margini si padding-uri, sau sunt clase ajutatoare care ne vor folosi cand implementam partea de JavaScript.

Important! Internet Explorer 6 (ce surpriza!) nu suporta pseudo-clasa :hover decat pentru elemente de tip ancora. Astfel ca, desi restul incompatibilitatilor le-am eliminat prin mici trucuri, pentru acesta nu exista nicio solutie care sa nu foloseasca JavaScript – ori, scopul nostru declarat era ca pagina noastra sa fie utilizabila si in absenta JS, asadar nu a avut sens sa ne complicam cu rezolvarea acestei probleme. (Ca o nota, probabil ca pana la sfarsitul lui 2009 nu va mai trebui sa ne punem problema compatibilitatii site-urilor si cu IE6 pentru ca se pare ca in acest an va cobori sub cota de 10%)

Sa incercam acum sa adaugam si partea de JavaScript: vrem sa facem votul efectiv cu ajutorul unei cereri AJAX si sa afisam informatii utilizatorului despre rezultatul votului (de exemplu, votul nu a reusit din diverse motive – poate utilizatorul a votat deja – sau, dimpotriva, s-a realizat cu succes, caz in care afisam un mesaj de succes). Sa incercam intai sa implementam functionalitatea dorita pentru cazul nostru particular, iar dupa sa incercam sa transformam acest cod intr-o clasa care sa poate fi folosita cat mai generic.

Pentru realizarea votului, ar fi sa adaugam ascultatori la click pe stele, iar in codul care trateaza aceste evenimente transmitem cererea JavaScript. Deoarece avem deja adresele la care se face votul in atributele href, va fi suficient sa facem cererea la acea adresa, insa va trebui sa transmitem o informatie suplimentara pentru ca scriptul din spate sa stie ca cererea a fost AJAX si nu un simplu click pe link (ca in cazul in care JS e dezactivat). Pentru cazul nostru, sa presupunem ca primim raspunsul in format JSON: un boolean success care va fi true daca votul s-a realizat cu succes, un mesaj care sa descrie rezultatul votului, si, daca cererea a fost un succes, noul rating si noua latime pentru elementul cu clasa now, care sa reflecte acest nou rating. La final, cand votul s-a incheiat, va trebui si sa eliminam toate elementele cu clasa star – nu mai are sens inca un vot (altfel rating-urile nu prea ar reflecta realitatea din moment ce un utilizator ar putea vota de o infinitate de ori). Atentie, scriptul PHP folosit pentru procesarea cererilor AJAX intoarce aceleasi rezultate de fiecare data – este doar un script dummy.

Iata si codul corespunzator (cu comentariile necesare; rezultatul e disponibil aici):

$$('.rating').each(function(container) {
    container.getElements('.star a').each(function(star) {
        // toate ancorele din li-uri cu clasa star, din container
        // sunt elementele cu ajutorul carora se fac voturile
        star.addEvent('click', function(event) {
            event.stop();
            // indica utilizatorului ca se petrece ceva
            container.addClass('busy');
            // votul se transmite printr-o cerere AJAX care va primi ca raspuns un JSON
            var req = new Request.JSON({
                // adaugam un parametru suplimentar pentru ca serverul sa stie ca cererea e AJAX
                url: this.get('href') + '&ajax=true',
                onComplete: function(response) {
                    var messageContainer = container.getNext();
                    // elimin din container stelele - nu se mai pot face voturi
                    container.getElements('.star a').destroy();
                    // cererea s-a incheiat - nu mai e nevoie de indicatorul vizual
                    container.removeClass('busy');
                    // afisez utilizatorului rasounsul
                    messageContainer.set('html', response.message);
                    if (!response.success)
                        messageContainer.addClass('error');
                    else
                        container.getElement('.now').setStyle('width', response.width);
                    container.getElement('.now').addClass('voted');
                }
            });
            req.send();
        });
    });
});

Ce observam din codul de mai sus este ca avem nevoie de urmatoarele:

• containerul in care sunt toate stelele,
• un selector care sa gaseasca toate elementele dintr-un container care declanseaza un vot (i. e. .star a)
• vrem sa facem totul cat mai generic, deci o functie care sa intoarca un Request (sau o subclasa a acestuia – sau, de fapt, orice obiect care sa aiba o metoda send() si caruia sa-i poate fi atasat un eveniment complete, care sa se ocupe de transmiterea catre server a votului) ar fi grozava
• cele doua evenimente importante care se petrec in procesul votarii sunt votarea efectiva si finalizarea votului (finalizarea cererii AJAX si intoarcerea raspunsului), deci ar fi util sa putem sa atasam ascultatori acestor evenimente la fel de usor cum atasam ascultatori evenimentelor clasice (click, mouseover, etc.)
• ca sa facem clasa cat mai usor de folosit, am putea oferi niste optiuni implicite decente, dar care sa poata fi modificate cu usurinta la instantierea clasei

Vom crea o clasa MooTools (deci ar fi util sa revedeti articolul Clase in MooTools si sa aveti la indemana documentatia oficiala), si ne vor fi extrem de utile clasele din Class.Extras (vom implementa pentru clasa noastra, cele doua clase Options si Events), deci haideti sa vorbim pe scurt despre cele doua (documentatia fiind disponibila pentru orice alte nelamuriri).

Atunci cand o clasa MooTools implementeaza Options, acea clasa va capata un membru options (implicit un obiect gol), si o metoda setOptions. Optiunile implicite pot fi specificate intr-un membru options al clasei noastre ca un hash de optiuni, iar apeland setOptions cu un hash de noi optiuni ca parametru, vor fi suprascrise in membrul options doar acei membri care sunt prezenti in acel parametru. Pentru clasa noastra, vom primi in constructor un singur parametru, optional: un hash de optiuni, si vom specifica un set implicit de optiuni care sa fie cat mai generic.

Daca o clasa MooTools implementeaza Events, acelei clase ii devin disponibile o serie de metode – addEvent, addEvents, removeEvent, removeEvents, fireEvent – care sunt extrem de asemanatoare cu metodele cu acelasi nume de la evenimentele DOM. Chiar mai mult, daca clasa implementeaza si Options, orice optiune care incepe cu on (de exemplu, onVote), va fi atasata ca ascultator la un eveniment de tipul acelei optiuni mai putin on (in cazul nostru, un eveniment vote).

Asadar, iata listarea codului clasei; am folosit un namespace IW pentru a nu crea conflicte – exista destul de multe alte scripturi pentru ratinguri cu MooTools:

if (!$defined(window.IW)) {
    IW = {};
}
IW.Ratings = new Class({
    Implements: [Options, Events],
    options: {
        selector: '.rating',
        stars: '.star',
        getRequest: function(url, onComplete) {
            /* url este link-ul catre care ar trebui facuta cererea AJAX, fara parametrii suplimentari
            onComplete este functia care ar trebui atasata ca ascultator atunci cand cererea AJAX s-a terminat */
            return new Request.JSON({url: url + '&ajax=true', onComplete: onComplete})
        }
    },
    bind: function() {
        $$(this.options.selector).each(function(container) {
            container.getElements(this.options.stars).each(function(star){
                var self = this;
                star.addEvent('click', function(event) {
                    event.stop();
                    self.fireEvent('vote', star);
                });
            }.bind(this));
        }.bind(this));
    },
    initialize: function(options) {
        this.addEvent('vote', function(star) {
            var req = this.options.getRequest(
                star.getProperty("href"),
                function(r) {
                    this.self.fireEvent('complete',[r, this.star]);
                }.bind({star: star, self: this})
            );
            req.send();
        }, true);
        this.setOptions(options).bind();
    }
});

Codul nu prea are nevoie de explicatii suplimentare daca ati urmarit prima implementare de mai sus (cea fara clase), ce ar fi de adaugat ar fi ca instantelor acestei clase ii pot fi atasate doua tipuri de ascultatori:

• vote, care va fi declansat atunci cand se executa votul (in mod tipic, cand se face click pe un link), ai carei ascultatori primesc ca parametru elementul care a declansat evenimentul si al carei context este instanta clasei
• complete, care va fi declansat atunci cand cererea AJAX prin care s-a transmis votul catre server s-a incheiat. Primeste doi parametri: primul, raspunsul de la server, iar al doilea, elementul care declansase evenimentul. Contextul acestei functii va fi tot instanta clasei

Ar trebui ca intotdeauna sa ii fie atasat clasei un ascultator la complete (pentru ca nu exista unul implicit).

Ca sa demonstram cum se comporta in practica clasa noastra, am lasat intentionat din vedere un lucru care tine de utilizabilitatea site-ului si de experienta utilizatorului: nicaieri in codul clasei, nu se anunta vizual utilizatorului ca se petrece ceva dupa ce a facut click pe o stea. Sa rezolvam asta adaugand ascultatori la vote, respectiv complete. Astfel, cand utilizatorul voteaza, vom anunta vizual acest lucru in doua moduri: containerul stelelor (in cazul nostru, listele cu clasa rating) va avea clasa busy in timp ce se efectueaza cererea (astfel, cursorul utilizatorului va indica “busy”), iar in campul in care afisam mesaje vom pune deja celebrul spinner AJAX. Cererea AJAX va dura cel putin doua secunde pentru ca scriptul din spatele acesteia asteapta doua secunde inainte sa intoarca raspunsul. Cand se termina cererea, eliminam clasa busy de la container (spinnerul va fi automat inlocuit cu mesajul primit ca raspuns de la server). Acesta ar fi codul:

var ratings = new IW.Ratings({
    stars: '.star a',
    // adaugam o optiune care incepe cu on, deci va fi automat adaugata ca ascultator
    onComplete: function(response, element) {
        var parent = element.getParent(this.options.selector);
        var messageContainer = parent.getNext();
        parent.removeClass('busy');
        parent.getElements(this.options.stars).destroy();
        parent.getElement('.now').addClass("voted");
        if (!response.success)
            messageContainer.addClass('error');
        else
            parent.getElement('.now').setStyle('width', response.width);
        messageContainer.set("html",response.message);
    }
});
// putem adauga si explicit ascultatorul
ratings.addEvent('vote', function(star) {
    star.getParent(this.options.selector).getNext().set('html','<img src="/images/loading.gif" alt="Asteptati..." />');
    star.getParent(this.options.selector).addClass('busy');
});

Rezultatul este disponibil aici.

Data viitoare vom implementa ratinguri ca plugin pentru jQuery.

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

In cazul cel mai generic, se foloseste metoda ajax din namespace-ul jQuery/$: $.ajax, care primeste ca parametru un hash de optiuni (cele mai multe asemanatoare cu cele de la MooTools) si intoarce instanta de XHR folosita pentru cererea creata (dar care in mod normal nu va fi folosita decat daca se vrea revocarea manuala a cererii – de exemplu la interactiunea cu utilizatorul). Aceste optiuni (vezi si documentatia) sunt:

• url reprezinta URL-ul catre care se face cererea
• type reprezinta tipul de cerere care se va face catre server (in mod uzual, GET sau POST). Implicit are valoarea 'GET'
• data sunt datele ce vor fi trimise in cererea AJAX. Poate fi un query string, sau un hash care va fi transformat in query string
• async, un boolean setat la true daca cererea va fi facuta asincron sau false altfel; implicit este true
• dataType este un string care spune ce tip de raspuns asteptam de la server. Valorile pentru aceasta optiune ar trebui sa fie dintre urmatoarele: 'xml' (daca raspunsul asteptat este un XML), 'html' (daca raspunsul asteptat este un fragment de cod HTML; orice taguri script din raspuns sunt evaluate daca acest fragment este inserat in DOM), 'script' (daca asteptam cod JavaScript), 'json' (daca asteptam date in formatul JSON), 'jsonp' (daca cererile se fac catre un server altul decat al site-ului nostru si se foloseste JSONP) sau 'text' (daca raspunsul asteptat este pur si simplu text, fara sa aiba un format anume)
• cache este un boolean care spune daca datele primite vor fi cache-uite sau nu. Implicit este true (deci vor fi cache-uite) pentru orice dataType diferit de 'script' si false daca dataType este 'script'
• timeout reprezinta intervalul de timp, in milisecunde, cat se asteapta raspunsul de la server. Daca serverul nu raspunde dupa acest interval de timp, cererea este anulata si se apeleaza functiile error si complete
• jsonp este un string care da numele parametrului din query string pentru functia de callback, in cazul in care se face o cerere JSONP (nu este nevoie de numele functiei pentru ca obiectul intors de raspuns este transmis ca parametru functiei success – in schimb se foloseste ? pe post de nume al functiei si jQuery completeaza automat acest parametru; de exemplu daca vrem sa transmitem un parametru nume si numele parametrului pentru functia de callback este callback, optiunea data ar putea avea valoarea 'http://www.exemplu.com/script.php?nume=Test&callback=?')
• contentType este un string care seteaza header-ul Content-Type al cererii. Implicit este 'application/x-www-form-urlencoded' (ceea ce ar trebui sa fie ok pentru majoritatea cererilor)
• scriptCharset este un string care spune care este setul de caractere al raspunsului pentru cererile de tip script/jsonp, si este necesar daca setul de caractere din raspuns este diferit de cel al documentului curent
• dataFilter este o functie care va procesa raspunsul primit de la server si va intoarce raspunsul procesat. Acesta va fi raspunsul folosit in toate celelalte functii care folosesc raspunsul de la server. Functiei ii sunt transmisi ca parametri datele primite de la server si tipul datelor (optiunea dataType de care am vorbit mai sus).
• global, un boolean care spune daca vor fi generate evenimentele globale (vom vorbi de acestea mai jos). Implicit este true si evenimentele vor fi generate
• ifModified, un boolean care, daca e setat la true (iar implicit e false), spune ca cererea ar trebui sa se incheie cu eroare daca raspunsul nu a fost modificat de la ultima cerere, prin verificarea headerului Last-Modified.
• username, password sunt doi parametri folositi pe post de username si parola, daca URL-ul la care se face cererea are nevoie de autentificare HTTP
• processData este un boolean (implicit true) care spune daca, atunci cand optiunea data nu este un string ci un obiect, acesta ar trebui sau nu convertit intr-un query string
• beforeSend, o functie care este apelata inainte ca cererea sa fie trimisa catre server. Acesteia ii este transmis un singur parametru, instanta de XHR care va fi folosita pentru a face cererea AJAX. Daca vrem sa setam headere pentru cererea noastra, aici ar trebui setate. De asemenea, poate dorim sa anulam cererea – pentru aceasta este suficient sa returnam false din aceasta functie. Contextul functiei este hash-ul de optiuni ale cererii AJAX.
• complete este o functie care este apelata daca cererea s-a terminat. Ii sunt trimisi 2 parametri: instanta de XHR cu care a fost facuta cererea, si un string ce descrie status-ul cererii. Contextul functiei este hash-ul de optiuni ale cererii AJAX. Aceasta functie este apelata dupa ce au fost apelate functiile pentru cerere efectuata sau nu cu succes (adica optiunile success si error)
• error este o functie care va fi apelata daca cererea s-a terminat cu esec. Contextul functiei este hash-ul de optiuni al cererii AJAX. Parametrii transmisi sunt instanta XHR, textul care descriere status-ul cererii (si care poate fi "timeout" – daca cererea a depasit timpul setat ca timeout -, "error" – daca a fost vorba de o eroare de la server -, "notmodified" – daca raspunsul primit a fost not modified (deci s-a folosit optiunea ifModified) – sau "parsererror" – daca a aparut o eroare la procesarea datelor primite) si, optional, exceptia care a fost aruncata la eroare (daca a existat o astfel de exceptie)
• success este o functie care este apelata atunci cand cererea a fost efectuata cu succes. Ii sunt trimisi 2 parametri: datele primite de la server, procesate (deci daca am primit date in format JSON, parametrul va fi un obiect; daca am primit xml, va fi un document xml, daca am primit text va fi un string etc.), si un string care descrie statusul cererii (si care va fi intotdeauna success)
• xhr reprezinta o functie care va fi apelata pentru a obtine instanta de XHR cu care se face cererea.

Este posibil sa setam valori implicite pentru toate cererile AJAX prin intermediul metodei ajaxSetup ($.ajaxSetup) care primeste acelasi hash ca si $.ajax, insa de aceasta data optiunile transmise ca parametri vor fi cele implicite, pentru orice cerere AJAX care va fi facuta dupa apelul acestei metode.

Cat despre evenimentele globale de care vorbeam mai sus, ar trebui spuse urmatoarele: in jQuery exista doua tipuri de evenimente care pot fi declansate atunci cand se fac cereri AJAX: evenimente locale (atasate cererii) si evenimente globale (pe care le vor primi toate elementele din DOM care au atasati ascultatori la astfel de evenimente). Evenimentele locale sunt cele de care am vorbit mai sus: functiile care sunt apelate inainte sau dupa ce s-a facut cererea AJAX: beforeSend, complete, success, error. Evenimentele globale se ataseaza elementelor din dom la fel ca orice alt tip de eveniment, si sunt:

• ajaxStart, care este declansat atunci cand nu este in curs nicio alta cerere AJAX si inainte ca cererea care a generat evenimentul sa fie transmisa
• ajaxSend, care este declansat inainte sa fie transmisa o noua cerere AJAX (deosebirea fata de tipul anterior este ca acest eveniment se va declansa chiar daca erau alte cereri in curs)
• ajaxComplete, care este declansat cand o cerere AJAX s-a incheiat (cu succes sau nu)
• ajaxSuccess, care este declansat cand o cerere AJAX s-a incheiat cu succes
• ajaxError, care este declansat cand o cerere AJAX s-a incheiat fara succes
• ajaxStop, care este declansat atunci cand nu mai exista nicio cerere AJAX in curs de procesare

Cat despre ajutorul pe care il ofera jQuery pentru cazuri comune de utilizare, avem la dispozitie urmatoarele:

• $().load trimite o cerere la server, iar raspunsul primit il injecteaza in fiecare element din setul jQuery. Primeste 3 parametri: primul, URL-ul la care se face cererea – acesta este un string care poate contine si un selector CSS dupa care va fi filtrat HTML-ul din raspuns (selectorul CSS ar trebui sa fie separat de URL printr-un spatiu); al doilea, optional, un hash care va fi transformat in query string si va fi trimis serverului; al treilea, tot optional, este o functie care va fi apelata cand cererea s-a terminat (cu succes sau nu) si care va primi ca parametri raspunsul de la server, un string care descrie statusul cererii, si instanta de XHR cu care s-a facut cererea (contextul acestei functii va fi elementul curent din set)
• $.get, $.post sunt niste scurtaturi pentru a face cereri cu GET/POST fara a avea nevoie de optiuni avansate ca la $.ajax. Primeste ca parametri: URL-ul la care se face cererea (singurul parametru obligatoriu), un hash de date care va fi transformat intr-un query string, o functie care va fi apelata daca cererea s-a terminat cu succes (si care primeste ca parametri raspunsul serverului si un string care descrie statusul cererii – dar care va fi intotdeauna 'success'; datele sunt in functie de tipul de raspuns asteptat, la fel ca la $.ajax) si un string care reprezinta tipul de date asteptat de la server (vezi optiunea dataType de la $.ajax)
• $.getJSON face o cerere catre un URL si asteapta sa primeasca date in format JSON (este posibil sa se faca cereri catre un alt server decat cel curent, cu JSONP). Metoda primeste 3 parametri, dintre care doar primul este obligatoriu: URL-ul la care se face cererea (si care spuneam ca poate fi extern; daca serverul la care suporta cererea suporta JSONP, numele functiei de callback ar trebui sa fie ? – astfel va fi apelata functia de succes), un hash cu date ce va fi convertit la query string si o functie ce va fi apelata daca cererea s-a terminat cu succes, care va primi ca parametri obiectul intors de cerere si un string care descrie statusul cererii (dar care va fi intotdeauna 'success').
• $.getScript face o cerere catre server si asteapta ca raspuns cod JavaScript (cererea poate fi facuta si catre un server extern), pe care il executa. Primeste 2 parametri: URL-ul la care se va face cererea, si, optional, o functie care va fi apelata daca cererea s-a efectuat cu succes (si care primeste ca parametri un string – codul JS intors de server – si un string care descrie status-ul, dar care va fi intotdeauna 'success')

Ultimele doua metode care ajuta la cereri AJAX, sunt:

• $().serialize(), care intoarce un query string bazat pe valorile tuturor elementelor de tip form input (input, textarea, select) care au un atribut name
• $().serializeArray() lucreaza la fel ca $().serialize dar nu intoarce un query string, ci un vector de obiecte – folositor pentru lucrul cu date in format JSON

Articolul de azi a fost lipsit de exemple (desi sunt destule pe paginile de documentatie), insa urmatoarele cateva articole vor fi punerea in practica a tot ce am invatat pana acum despre MooTools si jQuery.