Archivi tag: ajax

Ha senso imparare Ajax?

Pubblicato il da

Che in futuro la percentuale di applicazioni web di tipo Ajax (e Ria in generale) aumenti sempre più è un dato di fatto. Ma non è ancora chiaro chi, all’interno del team di sviluppo di un progetto web, debba imparare a masticare questa nuova architettura. Tutti? Solo chi si preoccupa della programmazione? Chi sviluppa i template? Il designer?

Chi progetta l’interfaccia

Uso qui impropriamente il termine “progettare l’interfaccia” intendendo in realtà molte specifiche professionalità, illustrate sapientemente da Jesse James Garrett nel diagramma “The Elements of User Experience“.

Chi rientra in questa categoria farebbe bene a capire come per l’utente cambia il modo di usare un sito che utilizzi Ajax. Perché le possibilità aumentano e l’interattività si avvicina a quella di un normale programma per computer. Per capire cosa intendo potete dare un’occhiata a quanto messo a disposizione da Yahoo!. Ma tutto questo pone anche dei problemi per quanto riguarda l’accessibilità e l’usabilità di Ajax.

Chi declina il template

La cosa più importante che deve fare chi si occupa del lavoro sporco, ovvero di convertire i template in codice Html e fogli di stile, è fare in modo che questi aderiscano il più possibile agli standard web. Non solo sulla carta, ma per davvero, come dico da due anni e passa.

Il fatto che Ajax impieghi massicciamente Javascript, realizzato solitamente da chi si occupa di produrre l’Html della pagina, potrebbe trarre in inganno. Si tratta infatti di un uso avanzato di Javascript, da lasciare a chi lavora lato server.

Chi scrive il codice lato server

Ecco, direte, quali sono i veri utilizzatori di Ajax, le persone che si infangano le mani tra codice Javascript e programmazione lato server…o no?

Certo, per capire come funziona Ajax suggerisco di creare da zero un piccolo esempio, ma è imprensabile sviluppare applicazioni complesse in questo modo.

Molto meglio votarsi a un framework che sollevi da questa responsabilità. Ma se possibile non un framework lato client, come ad esempio Prototype.

In futuro (neanche tanto lontano, basti pensare a quello che sta facendo, tra gli altri, Microsoft con Atlas), il supporto per Ajax sarà integrato direttamente all’interno dei framework di sviluppo lato server, tanto da renderne “invisibile” il funzionamento.

Attenzione però, perché trasparente fa rima con pericoloso. Dovrete prestare comunque attenzione a quello che fate; non dimenticatevi che siete sempre alle prese con un browser e – la maggior parte delle volte – con il protocollo Http.

Graceful Degradation o Progressive Enancement? Graded Browser Support

Pubblicato il da

Nel sito di Yahoo! rivolto agli sviluppatori è possibile trovare un illuminante articolo, quasi un manifesto, che mi ha permesso di capire qual è la strategia di Yahoo! per quanto riguarda il supporto ai diversi tipi di browser, elemento importante specie in un periodo in cui un sito non sembra degno del nome se non include qualche effetto Ajax.

Yahoo! preferisce quello che definisce progressive enancement rispetto al graceful degradation. Con graceful degradation, secondo Yahoo!, si intende il processo di creazione della pagina che favorisce la presentazione al contenuto. In questo scenario si sviluppa il sito per i browser di ultima generazione, controllando che comunque i browser più obsoleti siano in qualche modo in grado di visualizzare la pagina. Progessive enancement è invece una metodologia che dà priorità al contenuto, così che come prima cosa si realizza il sito in modo che il contenuto sia accessibile alle diverse combinazioni di browser, per poi includere alcune funzionalità per i browser di ultima generazione.

Per fare questo Yahoo! suddivide i browser in 3 categorie (o “gradi” da qui graded browser support): nella prima include browser che sono in grado di interpretare solo Html (circa il 3% dei visitatori); nel verificare le pagine vengono presi in considerazione errori prodotti con questi browser. Nella seconda categoria troviamo invece i browser moderni, con pieno supporto agli standard (circa il 96% dei visitatori); anche in questo caso eventuali errori vengono subito verificati e corretti. Di un’ultima categoria fanno invece parte i browser “rari” o che manifestano problemi nel supporto agli standard; eventuali errori in questo caso non sono presi in considerazione. Qui troviamo anche i browser appena usciti sulla piazza, fermo restando che prima o poi finiranno con tutta probabilità nella lista dei browser moderni.

Indipendemente dal fatto che siate d’accordo o meno con le teorie di Yahoo! (io ancora un’idea precisa non ce l’ho), tornerà sicuramente comodo dare un’occhiata alle categorie di browser. Se siete sensibili al problema sono senza dubbio da visitare anche i link presenti in fondo all’articolo

.

Ajax e l’usabilità, seconda parte

Pubblicato il da

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.