Ajax - the best possible user experience ...

Cred ca fiecare dintre noi, care folosesc Google Suggestions sau au intrat cel putin o data pe Google Maps si au scrollat timp de cateva secunde au observat ca totul se intampla extrem de rapid: cuvintele sugerate apar aproape instantaneu pe masura ce tastezi (intocmai ca la o aplicatie desktop), iar hartile se updateaza imediat,fara a mai astepta ca o intreaga pagina sa se incarce... Google Suggestions si Google Maps sunt doar cateva exemple de aplicatii online ce folosesc o tehnica speciala de dezvoltare a paginilor web denumita Ajax.


Ca definitie, Ajax, sau "Asynchronous JavaScript and XML" nu este o tehnologie in sine ci un grup de tehnologii folosite la crearea de pagini web interactive, in care datele de la server sunt preluate asincron si salvate intr-un buffer local, fara a mai afecta displayul si functionalitatea paginii curente. Intr-un cuvant, intregul proces este "invizibil" end-userului si creaza impresia ca totul se produce instantaneu ceea ce face aceasta metoda atat de interesanta!!


Totusi, ea nu este una recenta : tehnici de incarcare asincrona a datelor erau folosite inca din anul 1996 cand Internet Explorerul a introdus elementul IFrame. Jesse James Garrett a fost cel care i-a dat un nume - destul de "catchy" - in urma cu 3 ani (2005) iar Ajax-ul a devenit extrem de popular o data cu aparitia Gmail si a altor aplicatii "Ajax based" de la Google iar toata lumea si-a pus fireasca intrebare "how did they do it??".


Raspunsul este unul destul de simplu: o aplicatie "Ajax based" functioneaza prin crearea unui layer intermediar (un motor Ajax) intre user si server. La o prima vedere aceasta abordare pare defectuoasa : adaugarea unui layer suplimentar in aplicatie poate face ca aceasta sa devina mai lenta, mai putin prietenoasa. Dar lucrurile stau cu totul diferit, efectul este chiar invers! Si asta deoarece, la inceputul unei sesiunii, in locul incarcarii unei noi pagini web, se va incarca un engine Ajax (realizat in JavaScript) care va fi responsabil cu redarea paginii si comunicarea cu serverul in numele utilizatorului (nu va mai exista o relatie directa intre end-user si server).Engine-ul va permite ca interactiunea utilizator - aplicatie sa se produca independent de comunicarea cu serverul. Prin urmare nu vom mai avea situatii de genul "start-stop-start-stop" de fiecare data cand utilizatorul ii cere serverului sa-i furnizeze sau sa valideze niste date ;).


Ganditi-va, spre exemplu, la o pagina web in care utilizatorul trebuie sa completeze un formular de inscriere si in care trebuie sa astepte incarcarea unei noi pagini pentru a vedea rezultatul. Procesul este lent si neprietenos ("nobody likes to stare at a blank page, does he??"). Acum ganditi-va la alte aplicatii precum Youtube sau Flickr in care datele voastre sunt trimise si updatate fara ca voi sa "parasiti" pagina curenta! Toate acestea constituie "the magic of Ajax"...


Si acum, intrebarea care s-ar putea pune este : de ce avem nevoie pentru a realiza o astfel de aplicatie?Jesse James Garrett mentioneaza, intr-un articol din 2005, intreaga stiva de tehnologii care stau la baza Ajax:

• XHTML si CSS pentru partea de prezentare

• Document Object Model pentru display dinamic si interactiunea cu datele

• XML si XSLT pentru manipularea datelor

• XMLHttpRequest pentru o comunicare asincrona

• si JavaScript "to bind everything together" :).

Trebuie remarcat ca toate acestea se intamplau prin 2005. De atunci stiva s-a imbogatit considerabil, gasindu-se alternative pentru JavaScript -> VBScrip iar JavaScript Object Notation poate fi folosit pentru a inlocui formatul de reprezentare XML.
Ajax-ul a devenit destul de matur si este folosit de mai toate aplicatiile web populare azi. Sistemul de rating de la Amazon in care selectezi numarul de stele ca punctaj acordat unui cd sau unei carti este doar unul dintre ele.
Popularitatea Ajax-ului este demonstrata si de numarul mare de tutoriale puse la dispozitia celor care vor sa "experimenteze". Implementata corespunzator, o pagina web poate deveni o RIA (Rich Internet application) cu functionalitatea si avantajele unei aplicatii desktop. Scopul este, pana la urma, de a crea "the best possible user experience"...

Ce ar trebui evitat la dezvoltarea unei intefete web "beton"?

Cel mai bine se invata din greseli, asa ca o sa incerc sa evidentiez o parte din greselile care se intalnesc adesea in dezvoltarea interfetelor web, poate va ajuta pe cineva sa le evite :D.

Sa incep cu inceputul: atunci cand vrem sa realizam o pagina web, trebuie sa ne gandim la scopul ei, si cel mai adesea(daca nu intotdeauna) urmarim multumirea end-userului, a celui care acceseaza pagina, pentru ca altfel va cauta un alt furnizor al aceluiasi serviciu, dar care stie sa isi vanda mai bine marfa ( fie ca este vorba de un bilet la teatru, o melodie sau de o informatie).

Una dintre problemele cu care se confrunta aceia dintre noi care au renuntat la Windows in favoarea Linux-ului este aceea ca exista site-uri ( si nu sunt putine la numar, o lista cu o parte din acestea putand fi accesata la link-ul urmator ) care nu pot fi vizualizate decat folosind browser-ul Internet Explorer. Si asta nu este o situatie tocmai roz, in conditiile in care statisticile arata doar 48,6% dintre cei ce folosesc un browser au apelat la Internet Explorer in luna septembrie ( 2008). Nu ca ar fi o cifra insignifianta, dar asta ca inseamna ca mai bine de 50% dintre utilizatorii internetului sunt defavorizati de aceasta "politica de implementare", desi daca ne gandim mai bine cei care sunt in pierdere pana la urma sunt tocmai beneficiarii site-urilor ( statisticile pot fi vizualizate aici).

Unul dintre testele pe care trebuie sa le treaca o pagina pentru a nu te "alunga" este asa numitul "The Four seconds Test": o data ce ai accesat o pagina, ar trebui sa iti poti da seama intr-un timp foarte scurt( estimat undeva la 4 secunde) la ce anume se refera, daca are vreo legatura cu ceea ce te intereseaza pe tine. Iar daca home page-ul este foarte incarcat sau se incarca mult prea greu, multi dintre noi nu mai dam nici o sansa paginii si renuntam inainte ca acesta sa se incarce( example here ).

O alta problema cu care se confrunta unii dintre dezvoltatorii de interfete web este aceea ca, din dorinta de a realiza un design cat mai reusit , uita care este scopul textului sau cum sa il evidentieze: fie folosesc o culoare pentru text care nu contrasteaza cu fundalul, fie il inlocuiesc cu imagini sau animatii in flash.De ce ar fi aceasta a doua practica ineficienta? Mareste dimensiunea paginii in mod nejustificat, cel mai adesea elementele grafice sunt de calitate slaba si erorile sunt mult mai greu de corectat, iar "textul" astfel reprezentat nu este "search-engine friendly".
Pentru a testa daca ai ales bine culorile pentru text/fundalul paginii web, poti accesa link-ul acesta.

Un exemplu de don't este site-ul http://www.arngren.net: prea multa informatie adunata pe o singura pagina, incat este extrem de dificil sa te poti concentra pe ceva anume.

Uneori inainte de a intra intr-un site apare o animatie de intro(realizata adesea in flash), care poate fi simpatica prima data cand accesezi pagina sau daca ai tot timpul din lume, dar intotdeauna este de preferat sa existe optiunea de "skip", la fel cum pentru site-urile care au drept continut multimedia melodii ar trebui sa existe intotdeauna optiunea de "turn off".

Evident exemplele de don't pot continua, dar o sa ma opresc aici, cel putin pentru moment:)