Il bon ton del web 2.0

Web 2.0, come ho detto in altra sede, è più di un nuovo modo di fare siti: è una filosofia, un nuovo atteggiamento nei confronti del lettore/autore/utente del sito.

In quest’ottica anche la gestione degli inevitabili errori applicativi dovrebbe essere migliorata, soprattutto perché con le nuove architetture (leggi Ajax), cambia anche il modo di utilizzare l’interfaccia del browser.

Chi fa le cose per bene, in questa fase tutto sommato ancora embrionale per questo tipo di soluzioni, viene subito notato. E lo nota ad esempio Cesare Lamanna in un suo intervento su html.it. Cesare apprezza la cortesia di Backpack di 37Signals che non lo incolpa dei propri errori quando, per un problema al sistema, una email non viene recapitata come ci si aspetterebbe.

Anche Federico Oliveira di WeBreakStuff nota come al posto del preoccupante e onnipresente “server error”, Flick adotti una strategia decisamente più rilassante (Flickr is having a massage). Magari chissà che disastro sta succedendo dietro le quinte, ma l’importante è tranquillizzare gli autori sullo stato della loro produzione fotografica.

Esempi come questi si contano sulle dita di una mano. Speriamo sia solo questione di tempo.

Ajax e l’usabilità, seconda parte

Torniamo a occuparci (dopo averne approfonditamente discusso in un precedente intervento) di sviluppo di applicazioni Ajax e di come questa architettura ponga il progettista di interfacce davanti a nuove sfide.

L’occasione per riparlarne è un consolatorio articolo Donna Maurer per Digital Web; consolatorio perché va nella stessa direzione del precedente articolo di Fucinaweb.

“La sfida chiave nel progettare questo tipo di applicazioni e che gli utenti si accorgano degli aggiornamenti di parti di pagine”.

E la mia lamentala a proposito di Google Reader parte proprio dal fatto che, sotto carico, è impossibile per un utente del servizio capire se e dove c’è un problema.

L’articolo di Donna Maurer prende in realtà in considerazione non solo le applicazioni ajax, ma in generale quelle che vengono definite RIA, comprendendo con questo anche Applet Java e applicazioni basate su Macromedia Flash (maggiori informazioni su RIA possono essere trovate su wikipedia).

Quali sono sfide da affrontare secondo Maurer?

Decidere quanta interattività aggiungere

Vero, il rischio è di tornare ai tempi immediatamente successivi all’avvento della gif in movimento, che tutti usavano come fosse la soluzione a tutti i mali.

Gestire gli elementi interattivi

Creare applicazioni internet complesse significa avere a disposizioni nuovi elementi e possibilità per facilitare l’uso l’interfaccia. Ma questi elementi devono essere familiari agli utenti del sito, e il loro uso non ambiguo. A questo scopo possono senz’altro aiutare i pattern definiti da Yahoo! (come ad esempio quelli relativi al drag&drop o agli slider, che i lettori di Fucinaweb hanno già avuto modo di apprezzare).

Ricaricare parti di una pagina

Poiché il fuoco d’attenzione di una persona può concentrarsi solo su una cosa alla volta, è molto importante che l’interfaccia segnali proprio nel punto in cui c’è attenzione eventuali cambiamenti o richieste di intervento. Questa pratica è in realtà comune a tutte le interfacce, ma la novità per gli utenti nel trovarsi di fronte a nuovi comportamenti del browser fa sì che sia ancora più importante comunicare con lui in modo preciso e non ambiguo.

Superare il modello tutto-in-una-pagina

Avere la possibilità di ricaricare parti di una pagina non vuol dire che questa sia sempre la strategia corretta o che questa debba perfino essere portata all’estremo, così da usare una sola pagina per l’intera applicazione.

Nell’articolo di Donna Maurer viene citato The Design of Everyday Things di Don Norman, ma a mio avviso è bene rispolverare un altro grande testo (se siete stati così scortesi dall’averlo messo in soffitta): The Human Interface di Jef Raskin.

Cosa vuol dire portale nel 2006

Un articolo di James Robertson di StepTwo prende in considerazione i portali e spiega come questo tipo di siti web non sia morto, ma venga tuttora utilizzato all’interno dalle aziende e si rivolga ai dipendenti.

Ben fatta la parte che elenca alcuni tra i pregi e difetti dei portali.

Pregi

  • Semplificano l’integrazione di diverse componenti
  • Rendono possibile il login centralizzato (single sign-on)
  • Offrono un alto grado di personalizzazione

Limiti

  • Molte volte l’interfaccia non è usabile e i template poco modificabili
  • Agli utenti non piace personalizzare il prodotto
  • I portali non sono pensati per gestire il contenuto, ma sono dei trampolini di lancio per altre applicazioni

Quest’ultimo punto, in particolare, indica come i portali per le aziende non possano rimpiazzare le intranet, ma le completino.