“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery

Folosesc Firefox si middle-click pentru deschiderea in taburi noi a linkurilor care ma intereseaza. Insa in ultima vreme ma lovesc din ce in ce mai des de o problema: eu pe care buton apas?

Sa va explic.

O data cu raspandirea “fenomenului AJAX“, tot mai multe site-uri folosesc javascript pentru afisarea unor informatii intr-un mod mai “prietenos”. Astfel, un link pe care scrie “Help”, din dreptul unui camp dintr-un formular, poate deschide o fereastra popup, poate afisa un fel de lightbox, poate deschide intr-un tab nou o pagina cu informatiile necesare, etc. Posibilitatile sunt multe.

Problema este ca acel buton este imprevizibil.
Vad butonul, cum procedez? Left click, sperand sa fie ceva javascript, dar riscand sa imi schimbe pagina (lucru pe care eu nu-l doresc, poate e un formular deja aproape completat), middle click “ca sa fiu sigur” dar apoi ma trezesc cu 10 taburi deschise, fiecare tab fiind gol deoarece acel link fusese “gandit” (mult spus) pentru javascript? E foarte neplacut sa se intample asta, iar mai grav este ca aceasta nesiguranta devine din ce in ce mai prezenta pe web.

Exemplu concret: forumul macuser.ro. Toate pozele atasate la un post au link de forma javascript:showimage('http://..', '640', '480');void(0);. Vrei sa deschizi toate pozele in taburi ca sa te uiti la ele pe rand? Sau poate un link direct catre una din ele? Tough luck… Ai cumva javascriptul dezactivat? Hah.

Avem nevoie de programare web “cu cap”, facuta de oameni care stiu cum stau lucrurile, si nu de amatori care cred ca daca folosesc din plin ultimele efecte script.aculo.us totul va fi ok. Nu e ok, site-urile trebuie sa fie accesibile, informatia trebuie sa se gaseasca in stare cat mai pura. De-aia avem XML, JSON, XHTML: pentru “curatarea” informatiei de toate artificiile grafice. Javascriptul ar trebui sa fie bonus, nu esential! Vorbim bineinteles de site-uri normale, nu de aplicatii full-javascript. Cum poti sa te numesti programator web, dar sa scrii un formular de cautare in care submitul se face doar prin javascript? Chiar nu iti dai seama ca i-ai terminat pe toti cei care intra de pe terminale non-standard? Sau e nevoie sa intri chiar tu intr-o zi de pe un telefon mobil, intr-un moment de urgenta, sa cauti ceva pe un site, si sa nu poti sa faci asta pentru ca respectivul programator nu a pus buton de submit. “Pentru ce? Nu poate sa dea enter?”. Nu.

Asadar, un site trebuie sa functioneze 100% chiar si cu javascript dezactivat. Iar atunci cand este activat, sa nu fie nevoie sa am grija unde dau click pentru a nu naviga de pe pagina curenta unde am informatii importante. Vreau sa am incredere ca acel click pe care il fac pe linkul din meniu nu imi va strica experienta navigarii pe site. Acest lucru se cheama “non obtrusive javascript”, iar directia spre care ar trebui sa tindem toti se cheama “accesibilitate”.

Un prieten m-a rugat sa pun pe blog un anunt de angajare la firma F5 Solutions din Bucuresti, pe postul de front end developer. Here it goes:

F5 Solutions cauta un Front-End Web Developer care sa raspunda afirmativ la cel putin 5 din urmatoarele 8 intrebari:

• Poti face o comparatie intre cel putin 2 framework-uri JavaScript?
• Codul XHTML scris de tine este corect din punct de vedere semantic?
• Preferi un editor de tip TEXT (cu sintax-highlighting) in detrimentul unui editor de tip WYSIWYG?
• Cunosti cel putin o solutie pentru realizarea unui transfer asincron de date cross-domain?
• Obisnuiesti sa validezi codul XHTML / CSS conform standardelor W3C?
• “Cross-Browser”, “fiabilitate” si “scalabilitate” se numara printre caracteristicile definitorii ale proiectelor tale?
• Esti familiar cu cel putin 4 dintre urmatorii termeni: “hasLayout”, “mostenire”, “DOM”, “elemente multi-class”, “polimorfism”?
• Ai folosit pana acum o tehnologie text-based de serializare / transmitere a datelor in afara de XML?

Cunostintele si conditiile obligatorii sunt urmatoarele:

* XHTML, CSS;
* XML, XSLT, JSON;
* JavaScript (OOP, minim 4 luni experienta in utilizarea unui framework);
* Un portofoliu care sa cuprinda cel putin 3 proiecte / experimente / aplicatii relevante;
* Seriozitate, responsabilitate, etica profesionala;
* Simtul umorului (nu glumim).

Esti avantajat daca:

* Ai experienta in utilizarea Smarty;
* Ai experienta in utilizarea Fireworks si/sau Photoshop (slicing / export);
* Esti familiar cu modul de functionare al tehnologiilor server-side (cel putin la nivel de concept);
* Te implici, esti activ si stii sa-ti exprimi / argumentezi propriile idei si convingeri;
* Esti intr-un proces continuu de autodepasire.

Beneficii:

* Proiecte complexe si incitante;
* Pachet salarial si bonusuri atractive;
* Programul (flexibil) incepe undeva in jurul orei 11:00 (somn++, trafic–);
* Atmosfera placuta si degajata (cu mici exceptii: luni dimineata si vineri seara);
* Echipa tanara (pe bune) si statica (la 8 ore pe zi in fata monitorului numai dinamica nu e);
* Sansa de a te “razbuna” zilnic pe colegii tai utilizand “armele din dotare” (X-BOX / PC gaming sessions)
* Restul le descoperim impreuna pe parcurs.

Locatie: Bucuresti (Cartierul Primaverii)

Program: Full-Time

Dupa cum probabil ti-ai dat seama, NU cautam script-kiddies si in nici un caz NU suntem adeptii conceptului “struto-camila” / “one man show”.

Acestea fiind spuse, asteptam CV-ul tau insotit de 3 link-uri catre cele mai reprezentative proiecte realizate de tine (in cazul in care un proiect nu a fost realizat integral de tine te rugam sa specifici care au fost contributiile tale) pe adresa jobs [at] f5solutions [dot] ro (vor fi contactati numai cei care vor fi selectati pentru interviu). Studentii sunt bine-veniti.

Stim cu totii cata bataie de cap ne dau bugurile lui Internet Explorer. Versiunea 6 e un dezastru pentru cei ce scriu CSS. Versiunea 7 e putin mai buna, dar are in continuare probleme. Asa ca, pentru a asigura un site cross-browser, e nevoie de testare pe amandoua.
Din pacate, daca instalezi IE7 direct pe XP, iti suprascrie versiunea 6 si nu mai ai acces la ea.

M-am interesat si am gasit o solutie destul de buna zic eu. Mie mi-a mers :).

1. Se instaleaza IE7 pentru XP SP2 de aici: IE7-WindowsXP-x86-enu.exe.

2. Se downloadeaza installerul Multiple IE. Link direct.
Acesta copiaza versiuni stand-alone pentru IE 3, 4.01, 5, 5.5, 6.

That’s it :).

Layouturile bazate in intregime pe CSS nu mai sunt de mult un lux in webul romanesc. Avantajele lor asupra layouturilor bazate pe tabele se cunosc, nu e cazul sa le mai enumar aici. Din pacate, in goana dupa “xhtml css valid”, unele lucruri au fost prost (sau deloc) intelese, printre care si semantica.

Sa luam ca exemplu tabelele. Desi singura lor vina este ca pana acum au fost folosite incorect de web designeri, ele nu mai sunt dorite in nici o parte a unui site, pentru ca toata lumea stie acum de “tableless layouts”.

Acesta este un tabel simplu. Informatiile sunt dispuse clar, usor de inteles.

Acum, ce parere aveti de urmatoarele doua bucati de cod?:

<table>
	<tr>
		<th>Nume</th>
		<th>Prenume</th>
		<th>Varsta</th>
	</tr>
	<tr>
		<td>de Hunedoara</td>
		<td>Iancu</td>
		<td>620 ani</td>
	</tr>
	<tr>
		<td>Tepes</td>
		<td>Vlad</td>
		<td>576 ani</td>
	</tr>
</table>

<div class="table">
	<div class="table-row">
		<span class="table-headcell">Nume</span>
		<span class="table-headcell">Prenume</span>
		<span class="table-headcell">Varsta</span>
	</div>
	<div class="table-row">
		<span class="table-cell">de Hunedoara</span>
		<span class="table-cell">Iancu</span>
		<span class="table-cell">620 ani</span>
	</div>
	<div class="table-row">
		<span class="table-cell">Tepes</span>
		<span class="table-cell">Vlad</span>
		<span class="table-cell">576 ani</span>
	</div>
</div>

Interesant, nu? Mai e nevoie sa scriu si codul CSS necesar pentru ca a doua varianta sa arate ca prima? Pare absurd, dar multi sunt convinsi ca a doua varianta e cea mai buna (indiferent de circumstante), pentru ca “e din css”. Tabelele nu sunt rele! Ele trebuie folosite pentru informatii tabulare. E normal si semantic corect sa fie folosite astfel si este anormal sa se foloseasca o alta structura doar de dragul de a nu folosi tabele.

A scrie un site corect dpdv semantic inseamna a folosi fiecare tag html cu scopul pentru care a fost creat. Lista tagurilor suportate in XHTML 1.0 este aici. Daca o portiune de text vrei sa fie rosie, iti pui intrebarea “de ce?”. Iar daca raspunsul este “vreau sa scot acea portiune de text in evidenta”, atunci in loc sa folosesti <span class="red">, vei folosi <strong class="important">.

O regula de bun simt: daca, dupa dezactivarea stylesheet-ului CSS, nu poti identifica rapid elementele structurale ale site-ului (titluri, blocuri de text separate, formulare, meniu), atunci ceva e in neregula, iar structura HTML trebuie regandita putin. De asemenea, imaginile n-ar trebui sa existe in codul HTML decat daca sunt cu adevarat relevante pentru continut (ex: screenshoturi la o aplicatie). In rest, orice imagine (titluri mai speciale, colturi rotunjite, butoane colorate) trebuie adusa din CSS, de obicei folosind background-image. Asadar, o lista de comentarii la un articol va fi creata folosind o lista numerotata, titlurile vor folosi tagurile <hN> iar meniurile vor fi liste neordonate.

De ce este important sa scriem HTML semantic? Din multe motive. Unul ar fi SEO, deoarece se stie ca Google extrage informatiile dintr-un site in functie de structura HTML-ului, deci e bine sa-i indicam exact ce informatii sunt utile.
Un alt motiv este “backwards compatibility”: acest lucru inseamna ca daca site-ul va fi accesat de un dispozitiv mai putin inzestrat decat un calculator (ex: telefoane, screen readere, browsere mai vechi), structura lui va ramane in picioare iar informatiile vor putea fi accesate cu usurinta.
De asemenea, daca intr-o zi site-ul va fi preluat de un alt developer, ii va fi mult mai usor sa inteleaga cum functioneaza lucrurile in codul HTML.
Nu in ultimul rand pentru ca este primul pas catre semantic web.

Este bine de stiut ca nici un tag HTML nu e special in vreun fel (cu putine exceptii, cum ar fi tagul <a>). Felul cum arata un <h3> (de exemplu) depinde de setarile default ale fiecarui browser. Poti crea un intreg site doar din taguri <span>, fapt dovedit aici, insa in acest fel anulezi complet ideea de semantica asociata cu tagurile.

Resurse utile

• Semantics, HTML, XHTML, and Structure
• Standards don’t necessarily have anything to do with being semantically correct
• The Semantic Web: An Introduction

Completare
Ionut a scris acum cateva zile un articol foarte bun despre stilizarea formularelor fara a folosi tabele, ci folosind definition lists. Enjoy :)

Am dat peste un articol excelent despre designul formularelor pe web, probleme de accesibilitate si uzabilitate. O sa incerc sa fac un rezumat:

• Diferentierea vizuala (dimensiune, culoare) dintre butoanele ce reprezinta actiunile principale (save/submit/continue..) si cele secundare (go back/reset/cancel) ale unui formular reduce riscul unor greseli si conduce inconstient utilizatorul pe drumul bun
• Alinierea butoanelor finale (Submit/Cancel) in partea stanga a formularului, in rand cu inputurile de dinainte, ajuta utilizatorul sa inteleaga mai usor scopul butoanelor si sa il aleaga pe cel pe care vor sa apese, deoarece ochii sai vor avea o distanta mai mica de parcurs pe suprafata formularului
• Alinierea butoanelor in partea dreapta a fost cea mai nefericita varianta, candidatii necesitand cel mai mult timp pana cand sa proceseze scopul fiecaruia
• Ideala este crearea unei axe verticale puternice prin alinierea tuturor inputurilor in partea stanga, in rand cu butoanele.

In articol veti gasi explicatii amanuntite, precum si o analiza pe mai multe layouturi ale aceluiasi formular.

Cateva articole asemanatoare:

• Sensible Forms: A Form Usability Checklist
• Web Usability – Accessible Forms
• Evaluating the Usability of Search Forms Using Eyetracking

Introducere

Aplicatiile web se bazeaza din ce in ce mai mult pe javascript pentru transferul de informatii intre serverul web si browserul vizitatorului. Aceste informatii pot fi trimise fie plain-text, fie serializate intr-un obiect JSON, fie intr-o structura XML. Pentru ca datele trimise de server sa poata fi utilizate in cadrul javascript-ului, ele trebuie extrase cumva din string-ul responseText. Aceasta operatie de extragere a informatiilor dintr-un text care respecta o anumita sintaxa (bine definita) se cheama parsare.

Cum ii spune si numele, JSON este o notatie, o sintaxa care descrie felul in care sunt incapsulate obiecte (array-uri, stringuri, numere, etc) intr-un anumit format, dupa reguli bine stabilite.

XML-ul nu este un format nativ javascript, sintaxa lui nu are sens intr-un cod sursa .js, de aceea este nevoie de un set de functii in plus pentru extragerea datelor venite in acest format, ceea ce mareste timpul de procesare.
Sintaxa JSON insa, este perfect compatibila cu javascript. Stringul primit de la server nu trebuie decat evaluat (cu functia eval()) si este automat transformat in variabila. Nu este necesara folosirea niciunei librarii externe. Functia eval() executa stringul dat ca parametru ca si cum ar fi cod javascript.

Un exemplu de string cu sintaxa JSON:

{
	"numeMagazin" : "SC Gigel impex SRL",
	"produse" : [
		{ "nume" : "Tricou", "cantitate" : 2, "pret" : 120 },
		{ "nume" : "Telefon", "cantitate" : 6, "pret" : 500 },
		{ "nume" : "Creion", "cantitate" : 10, "pret" : 20 }
	],
	"adresa" : "Strada Primaverii nr. 3"
}

O structura echivalenta in XML ar fi:

<?xml version='1.0' encoding='UTF-8'?>
	<numeMagazin>SC Gigel impex SRL</numeMagazin>
	<produse>
		<produs>
			<nume>Tricou</nume>
			<cantitate>2</cantitate>
			<pret>120</pret>
		</produs>
		<produs>
			<nume>Telefon</nume>
			<cantitate>6</cantitate>
			<pret>500</pret>
		</produs>
		<produs>
			<nume>Creion</nume>
			<cantitate>10</cantitate>
			<pret>20</pret>
		</produs>
	</produse>
	<adresa>Strada Primaverii nr. 3</adresa>
</xml>

Utilizare

Dinspre PHP, un string valid JSON se poate genera manual, dar cel mai usor este sa folosim o clasa care stie sa transforme orice variabila PHP (simpla, array, etc) direct in sintaxa JSON, gata sa fie trimisa browserului. Incepand cu versiunea 5.2.0, PHP vine cu o extensie care se ocupa atat de codarea cat si de decodarea obiectelor JSON. Pentru versiunile mai vechi de PHP se poate folosi o clasa din multele disponibile.

Exemplu de utilizare din PHP, folosind functia json_encode(), disponibila in PHP 5.2.0:

$array = array(
	"persoana" => array (
		"nume" => "Andrei",
		"varsta" => 20,
		"email" => "andrei@idevelop.ro"
	)
);

echo json_encode($array);

{"persoana":{"nume":"Andrei","varsta":20,"email":"andrei@idevelop.ro"}}

In javascript, dupa cum am spus, ne ajuta foarte mult suportul nativ. Deoarece acel string este, in esenta, o instructiune javascript, el nu trebuie decat evaluat si devine automat o variabila.

var rezultat = eval('(' + ajax.responseText + ')');
// in acest moment, "rezultat" este un obiect javascript
alert(rezultat.persoana.nume); // va afisa "Andrei"

Obiectul astfel obtinut poate fi parcurs exact ca orice array, elementele sale putand fi la randul lor array-uri, etc. Pentru primul exemplu, cel cu magazinul, afisarea tuturor produselor se poate face in felul urmator:

var magazin = eval('(' + ajax.responseText + ')');
for (var k=0; k<magazin.produse.length; k++) {
	alert(magazin.produse[k].nume);
}

Pentru a vedea pe viu ce si cum se intampla, am creat o pagina demonstrativa:

Exemplu de utilizare JSON: un exemplu de prelucrare a unui string JSON

JSON versus XML

Cum am vazut, atat JSON cat si XML nu sunt decat sintaxe in care sunt invelite, intr-un mod structurat, informatiile. De ce am folosi unul si nu celalalt? Ca de obicei, parerile sunt impartite si exista avantaje si dezavantaje in ambele cazuri.

Avantajele JSON

• Parsarea unui obiect JSON in javascript este mult mai rapida decat parsarea acelorasi informatii impachetate intr-o structura XML, datorita suportului nativ.
• Parcurgerea informatiilor obtinute este de asemenea mult mai usoara decat folosind functii XML gen childNodes() sau nextChild().
• Datorita sintaxei simple, dimensiunea unui raspuns AJAX in forma JSON va fi mult mai mica in comparatie cu un XML stufos, cum puteti vedea si in exemplul de mai sus.

Avantajele XML

• Este mult mai raspandit, exista multe implementari de parsere si generatoare pentru majoritatea limbajelor de programare existente
• XPath, XSLT

Securitate

Atata timp cat sunteti siguri ca serverul care trimite datele in format JSON este de incredere, totul este ok (desi, teoretic, este posibil ca pachetele sa fie interceptate intr-un punct intermediar si inlocuite cu altele, deoarece informatiile sunt trimise plain-text, fara criptare).

Daca insa trebuie sa parsati cod venit de la un alt site (cum trimite, de exemplu, jobber pentru widgetul sau) asupra caruia nu aveti control, pot aparea probleme de securitate. Daca cineva compromite serverul jobber si introduce in codul javascript trimis spre widget instructiuni malitioase, acestea vor fi executate de catre functia eval() in browserul vizitatorului. In acest caz, pentru intarirea securitatii, este bine sa folosim un JSON Parser, o functie care parseaza doar codul JSON din textul primit, ignorand instructiunile javascript.

O alta problema de securitate este javascript hijacking, dar mai multe despre asta intr-un articol viitor :).

Linkuri utile

• JSON.org
• The AJAX response: XML, HTML, or JSON?
• JSON for the masses
• Wikipedia: JSON

Ieri mi-am facut cateva ore libere si am adaptat o idee mai veche de-a mea, rezultand Harta Jobber.

Dezvoltarea a fost destul de simpla: codul de baza pentru afisarea unei harti Google in pagina, orasele extrase direct in fisierul js (fara AJAX), putin CSS pentru afisarea bulinelor, iar in final integrarea lor cu search-ul deja existent in site. Mai mult a durat strangerea tuturor coordonatelor pentru orasele disponibile :).

Codul javascript e scris acum ceva vreme, sunt cateva chestii pe acolo de care nu sunt tocmai mandru, dar functioneaza. Inca e in perioada de teste, daca gasiti bug-uri let me know.