Creative Stid Blog

Nella tabella che segue riporto una serie di validazioni eseguite su alcuni dei siti di riferimento Web 2.0.

Le validazioni sono state eseguite con:

• http://validator.w3.org/ per l’HTML
• http://jigsaw.w3.org/css-validator/ per il CSS
• http://feedvalidator.org/ per RSS 2 e ATOM feed

Alcuni di questi siti utilizzano AJAX/Javascript pesantemente, in questi casi il validatore fallisce quasi sempre sul codice. Fin qui in un’ottica di sprimentazione 2.0 dichiarata, la cosa potrebbe anche essere comprensibile. In realtà molti degli errori sono frutto di un’errata codifica del codice HTML, tag non chiusi, tag utilizzati al di fuori dei contesti consentiti, sintassi obsoleta, dimenticanze facilmente riparabili senza che questo incida in alcun modo sul rendering della pagina.

Per quanto riguarda il CSS il discorso è diverso, il test fallisce lì dove la struttura XHTML non è ben codificata, diventa quindi invalidabile. Inoltre è risaputo che l’utilizzo di alcune tecniche CSS vitali per la cross-compatibilità tra browser non standard, includono l’utilizzo di codice “sporco” che qualunque validatore CSS prende come non valido.

Non voglio dilungarmi in questo post citando le motivazioni che hanno evidenziato l’importanza di una corretta applicazione delgi standard definiti dal W3C, ci sono ampie discussioni a riguardo sulla rete. Prendo semplicemente atto di un fatto e lo riporto.

Questo stesso Blog, da quando ho incluso lo “swicki search” nella sidebar, non è più validabile. Il codice generato da quest’ultimo infatti non è standard, come molti dei codici simili (copy&paste) forniti sul web.

Per chiudere… forse qualcuno dovrebbe informare la Microsoft della cosa, gli eviteremmo parecchio lavoro su IE7, a quanto pare infatti, gli standard nella nuova forma del web non sono più un problema.

ajax, atom, css, Feed, html, rss, standard, validator, w3c, Web 2.0, XHTML

In questi giorni sto cercando di farmi un’idea più precisa su quelli che saranno i problemi da affrontare nella realizzazione di un’interfaccia applicata ad una Web App 2.0.

Quelli che seguono sono alcuni dei macro ragionamenti e relative assunzioni (in versione beta) che mi sono ritrovato a fare a riguardo, per quanto questo sia possibile in un ambito che nei fatti è tutto meno che definito… “beta” per l’appunto.

Develop for Developers
Quello che proprio non vorrei vedere nel Web 2.0 è il ritorno di quel tipo di fenomeno che molti di noi hanno conosciuto degli anni passati di internet definito come “Design for Designers”, una specie di fase edonistica in cui l’utilizzo di applicazioni rich media come Flash erano più usate per stupire o compiacere la comunità di noi creativi web che non come un mezzo per realizzare interfacce e/o passare messaggi utili al target finale.

Gli utenti non utilizzeranno le Web Application perché queste sono “Web”, sono sviluppate in RubyOnRails o solo perché “ieri su web non si poteva fare”, non faranno distinzione tra una Desktop Application e una Web Application ma utilizzeranno ciò che con maggior efficacia gli farà raggiungere un determinato obiettivo.

Marketing… Be clear!
Se dichiariamo al mondo che abbiamo realizzato una Web Application che si comporta come una Desktop Application, poi non ci stupiamo se l’utente rimane confuso o peggio deluso davanti a dinamiche che per limiti tecnici non saranno riproducibili su Web. Una Web Application non è = ad una Desktop Application. Non ancora per lo meno (qui parlo del presente).

Non sarà infatti la trasposizione dell’interfaccia Desktop -> Web a decretare il successo di una Web App ma l’efficacia delle modalità uniche del web che essa è preposta a servire. Se perdiamo il fuoco su questo, perdiamo il valore vero di questa trasformazione.

Keep it light
Teniamo presente che uno degli elementi che rendono un’interfaccia usabile e accessibile è la sua reattività. Inutile realizzare un’applicazione che ci stupisce con effetti speciali, Drag & Drop, bottoni super dettagliati e funzioni strabilianti se poi questa viaggia come un MacOSX fatto girare su un commodore 64. Esistono inoltre tutta una serie di limitazioni di cui tenere conto nell’interazione Client/Server asincrona tipica di AJAX, il click su un bottone non significa necessariamente l’esecuzione immediata e relativo ritorno di una determinata funzione. Va posta molta attenzione ai feedback da dare all’utente in questi casi.

Paradigmi acquisiti
Ricordiamoci che gli utenti hanno fatto propri dei paradigmi ormai consolidati nel loro quotidiano utilizzo dei software. Se la nostra applicazione web non ci permette di riprodurli per via di limiti tecnici, meglio rivederne le funzioni e provare altre strade che costringere l’utente ad imparare una nuova modalità di interazione ed un nuovo paradigma. Questo perlomeno se ci troviamo a trattare funzioni già consolidate nelle applicazioni tradizionali.
Facciamo in modo che sia la nostra applicazione ad adattarsi all’utente e non viceversa.

ajax, Interfacce, Interface Design, Web 2.0, Web Application