Ragionando sulle Web App 2.0
Sabato, 4 Febbraio 2006In 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.
