Fonte Originale
Cosa e' una Rich Internet Application? James Ward dice che e' difficile dare una esatta definizione di cosa sia una applicazione RIA. Un po' come dire cosa e' un albero. Forse e' più facile identificare una applicazione RIA quando se ne ha una davanti, come un albero quando lo si ha davanti a se.
Forse e' più semplice dire quali caratteristiche si vuole che abbia una applicazione di questo genere, rispetto a quello che ci si aspetta abbia una semplice pagina web.
Di sicuro entrambe sono applicazioni web. Non c'e' dubbio. Occorre allora definire il termine "Rich", ovvero "Ricca". Ma ricca di cosa?
Ricca di esperienze fornite all'utente finale che usufruisce di una tale applicazione. Una ricchezza non tanto di contenuti - una normalissima pagina web può essere molto ricca di contenuti, magari con audio, video, animazioni flash ed altro. Ma probabilmente non fornisce molta interattività all'utente, ne' velocita' di risposta, di reazione alle operazioni dell'utente.
Non sono d'accordo con James Ward quando parla del fatto che una RIA deve essere "Alive", ovvero viva. Secondo lui deve essere una modellizzazione del movimento e della bellezza che possiamo trovare nel mondo reale. Effetti di zoom, di transizioni dolci sugli elementi grafici, ombre degradanti, angoli arrotondati sarebbero elementi delle RIA che aiuterebbero a rendere il software più simile al mondo reale.
Questi elementi secondo me non hanno nulla di distintivo rispetto ad una pagina web tradizionale, se fini a se stessi. Non credo che un utente guardi più di tanto all'impatto emozionale come modo per raggiungere una soddisfazione complessiva nell'uso del software. Un altro conto invece se tali elementi servono a migliorare altri aspetti come l'interattivita' con l'utente.
Se stiamo salvando dei dati utilizzando la nostra applicazione rimaniamo abbastanza perplessi se non abbiamo nessun mezzo per essere consapevoli di ciò che avviene e semplicemente l'interfaccia grafica si blocca fino a quando compare un messaggio che ci avvisa che il salvataggio dei dati e' terminato correttamente nel modo desiderato. Quindi in quel caso ben vengano effetti di transizione come una finestra di dialogo che ci avvisi del progresso della nostra operazione di salvataggio dei dati e magari ci faccia capire se sta andando tutto bene e quanto può mancare alla sua terminazione.
Non mi preoccuperei tanto poi dell'interazione multimediale invocata nel suo articolo. Già e' difficile trovare forme più elementari di interazione, che forse e' meglio concentrarsi per migliorare quello, prima di esplorare forme di interazione più complesse.
Ad esempio ultimamente era comparso un articolo che parlava di quello che idealmente ci si aspetta da un widget che implementa un menu ad albero da utilizzare nelle nostre applicazioni. Ovvero le specifiche che l'oggetto TreeMenu dovrebbe soddisfare. E sinceramente, benché si possa usufruire all'interno dei nostri framework di molti buoni widget TreeMenu fatti in molti modi, nessuno ancora e' aderente a tali specifiche.
Sulla responsività, ovvero sulla reattività di risposta della nostra applicazione web, sono concorde. Il grosso problema e' che per fare RIA complesse occorre utilizzare pesantemente Javascript. Già il fatto di non ricaricare completamente tutta una pagina web, paradigma fondamentale dell'approccio Ajax, migliora moltissimo la reattività della nostra applicazione. Pero' ci sono aspetti poco o per niente controllabili, quali aspetti riguardanti la connettività di rete, le limitazioni di processamento, che ci obbligano ad attendere che la nostra applicazione finisca di compiere una operazione pesante quale può essere il caricamento di una tabella con molti dati da mostrare, oppure il riordinamento alfabetico dei dati mostrati nella tabella per una determinata colonna.
Javascript e' un linguaggio interpretato in tempo reale, perdipiu' dentro una macchina virtuale non efficientissima, fornita dal nostro browser. Perdipiu' Javascript non supporta il multithreading. Non si riesce a parallelizzare l'esecuzione delle operazioni.
Benché le ultime versioni degli interpreti Javascript abbiano avuto significativi miglioramenti nelle performance, può facilmente capitare di avere punti critici all'interno del nostro codice, con operazioni che richiedono anche dieci secondi od oltre per essere eseguite.
Se i tempi di attesa di una operazione superano qualche secondo di sicuro l'utente non percepisce la nostra applicazione come "ricca".
Per questo motivo in alcune classi di applicazioni RIA hanno assunto sempre più importanza macchine virtuali disponibili sul client diverse dal browser oppure alcuni meccanismi di caching locale, perché sicuramente questi meccanismi riducono i tempi di latenza, ed aumentano la responsivita' della nostra applicazione.
Esempi di ciò sono dati dalla piattaforma Adobe AIR (Ex Flex), di cui vi parlerò in un prossimo post.
Di sicuro le applicazioni RIA stanno assumendo sempre più rilevanza perché sono più connesse, vive, e reattive rispetto alle semplici pagine web tradizionali, e ci si aspetta che a mano a mano tutto sia fatto come una RIA.
Come dire che, una volta che l'utente ha provato una RIA, ci si aspetta che tutte le altre applicazioni abbiano le stesse caratteristiche.
