Archivio tag: architettura

I siti pigri sono i più veloci

Pubblicato il da
2

Ho messo da parte in questi anni un bel po’ di materiale e documentazione relativi alla performance e ottimizzazione dei siti web, sia per quanto riguarda il cosiddetto lato server, sia per quello che viene chiamato front end.

Verrà – spero presto – il momento di compilare un elenco ragionato di tutte queste risorse (potete farvene un’idea visitando la sezione optimization del mio delicious), ma ora mi limito a citare un articolo che propone in modo molto chiaro uno dei nodi fondamentali da affrontare. Si tratta di Lazy web sites run faster scritto da Gojko Adzic.

Per aumentare le performance dei siti potete investire sull’hardware, quindi più processori e sistemi più veloci, migliore connettività, infrastruttura moderna. Vi accorgerete però che anche così facendo il web server fatica, per architettura, a gestire un sito il cui codice non sia ottimizzato.

Potete allora dedicarvi alla riscrittura (o refactoring) del codice per renderlo più veloce. Anche qui però arriverete ben presto a un limite.

Il segreto, secondo Gojko, sta invece nella progettazione di un sistema che si preoccupi di

  • delegare le operazioni più complesse a processi che girano in background;
  • non comunicare con sistemi esterni in modo sincrono, non importa quanto velocemente;
  • essere pigro: meglio lasciare per dopo tutto quello che non ha necessità di essere eseguito al momento.

Aggiungerei anche di eliminare le elaborazioni inutili, come per esempio l’esecuzione a ogni richiesta di interrogazioni esose (come quelle verso i database) per contenuti che non cambiano quasi mai. In questo caso potrebbe essere interessante sperimentare qualche meccanismo di caching.

Se ripenso ai colli di bottiglia dei progetti che ho visto da vicino, la maggior parte poteva essere evitata rimandando operazioni non immediatamente essenziali, come per esempio:

  • l’invio di un messaggio di posta elettronica di conferma;
  • la trasformazione di file (soprattutto in formato XML);
  • la comunicazione con sistemi di gestione;
  • il calcolo di statistiche.

Capita di trovare anche online degli esempi che fanno riflettere. Ogni volta che utilizzo la funzione “all time” di Feedburner per analizzare il traffico complessivo dei miei feed mi trovo ad aspettare almeno una decina di secondi. Probabilmente il sistema sta elaborando il consuntivo in tempo reale, quando avrebbe potuto farlo a priori. Non c’è nulla di male ad aspettare anche se a volte, per carico del server, viene restituito un timeout. Forse non proprio il modo ideale per gestire questa funzionalità, anche se utilizzata da una minoranza.

L’accessibilità dei giochi olimpici

Pubblicato il da
Risposta

AbilityNet ha da poco pubblicato un’importante analisi relativa all’accessibilità del sito ufficiale dei giochi olimpici.

Il risultato ce lo potevamo probabilmente aspettare: il sito risulta solo parzialmente accessibile a indicare una scarsa conoscenza dei realizzatori in fatto di accessibilità web. Tutto questo dopo che 4 anni fa un non vedente vinse una causa contro la Commissione Olimpica per il sito dei giochi di Sidney, come racconta egregiamente Joe Clark (che ho avuto il piacere di intervistare qualche anno fa).

Al di là dei risultati, però, lo studio è interessante per le modalità con cui è stato condotto.

In AbilityNet non hanno infatti utilizzato alcuno strumento automatico di verifica dell’accessibilità.  Come scrivevo ormai 6 anni fa in Cos’è l’accessibilità web:

La verifica di un sito accessibile non avviene esclusivamente via software. Programmi con Bobby di Cast, A-Prompt di Trace aiutano ad evidenziare lacune e punti di miglioramento, ma questo non è che il primo passo.

I problemi di accessibilità nascono soprattutto da errori di architettura o di progettazione che è possibile risolvere solo applicando le linee guida nel contesto del sito in esame.

Si è preferito impegnare persone con diversi tipi di disabilità e indicare alcuni compiti da svolgere, come leggere il programma degli eventi, trovare i tempi di qualifica di una disciplina, comperare un biglietto.

Nulla di diverso da quello che normalmente si fa nei test di usabilità di un sito. Ed è corretto, dal momento che accessibilità e usabilità web si completano.

E’ davvero illuminante e allo stesso tempo sconcertante dare un’occhiata ai filmati in cui i 4 disabili incontrano difficoltà nel compiere anche le operazioni più semplici a causa della scarsa cura in termini di accessibilità web.

Ecco alcuni spunti tratti e commentati dal documento:

  • per il sito delle olimpiadi è stato utilizzato un approccio esclusivamente tecnico all’accessibilità, utilizzando le linee guida WAI come sterile lista di punti da seguire
  • uno dei principali problemi riscontati dall’utente cieco è che i video e gli audio presenti nella pagina iniziano l’esecuzione in automatico, senza la presenza di opportuni controlli di play/stop. Questo provoca delle sovrapposizioni vocali con gli screen reader, rendendo difficoltosa la comprensione del contenuto
  • le tabelle di contenuto in un sito devono essere pensate per poter essere interpretate da sinistra verso destra, e non dall’alto al basso, come invece avviene per la pagina del programma delle olimpiadi
  • nel corso delle olimpiadi i responsabili del sito hanno migliorato alcuni aspetti dell’interfaccia. Indice che il tema dell’accessibilità web è stato sottovalutato e solo a seguito di lamentele si è deciso di porre qualche parziale rimedio. Non quindi un limite dell’infrastruttura utilizzata (comunque non giustificabile), ma di pessima progettazione

Sempre in tema di accessibilità del sito delle olimpiadi, vi suggerisco la lettura di questa dettagliata analisi di Rnib, seguita da una seconda parte, che già più di un anno fa aveva lanciato un grido di allarme, rimasto purtroppo in gran parte inascoltato.

Ha senso imparare Ajax?

Pubblicato il da
3

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.

Ajax e l’accessibilità dei siti web

Pubblicato il da
4

(Vedi anche Ajax e l’usabilità)

Di Ajax si parla ogni giorno e sono ormai decine i framework per sviluppare applicazioni basate su questo tipo di architettura.

Occupandomi da anni di sviluppo web non posso che esserne contento: finalmente i limiti di interfaccia di una pagina possono essere superati! Subito dopo mi sono però chiesto se sono tutte rose e fiori, se con Ajax ci sono solo risvolti positivi.

Pensiamo a un argomento delicato come quello dell’accessibilità web. Già è difficile riuscire a realizzare una semplice pagina Html accessibile, per non parlare di una pagina con immagini, video e audio. Cosa succede se cominciamo a impiegare massicciamente Javascript e Dhtml?

Ho pensato allora di farmi dare una mano da Nicola, visto che utilizza quotidianamente uno screen reader, sottoponendogli due esempi.

Il primo, più semplice, è Google Suggest. L’aspetto è quello della classica ricerca di Google, ma non appena si comincia a digitare qualcosa, appaiono dei suggerimenti pescati direttamente dal server. Ho espresso a Nicola il dubbio che il suo screen reader non fosse in grado di segnalargli la presenza di questi suggerimenti, dubbio che mi ha subito confermato.

Come era largamente prevedibile, Jaws non dà alcun riscontro della presenza di un’eventuale lista di suggerimenti nella pagina di ricerca di Google.

A questo punto sono passato all’opposto e ho scelto un sito che si basa interamente sull’architettura Ajax: il nuovo client web di Yahoo! Mail, in versione beta e utilizzabile quasi esclusivamente oltreoceano.

Graficamente e a livello di funzionalità si tratta di un prodotto stupefacente: sembra quasi impossibile utilizzare questo tipo di applicazione in un browser, tanto è simile a un vero client di posta. Ma, anche in questo caso, Nicola ha evidenziato dei seri problemi di accessibilità.

Per quanto riguarda la mail di Yahoo!, riesco a leggere la tabella contenente il sommario dei messaggi, ma nessuna voce viene vista da Jaws come un link. Mi pare di aver capito che, per leggere un messaggio, bisogna cliccare sull’oggetto. Questo con una manovra si può anche fare. Poi però rimane il problema di riuscire a leggere il messaggio. Mi sembra di aver capito che il testo del messaggio appare sotto alla tabella contenente l’elenco dei messaggi. Tuttavia Jaws legge solo il nome del mittente e quello del destinatario, poi per lui la pagina web finisce lì. Ancora una volta, ricorrendo all’emulazione del mouse, cioè al cosiddetto cursore Jaws, si riesce a raggiungere la zona sottostante e a cliccare. A questo punto si apre una nuova finestra, che Jaws legge normalmente. Conclusione: non accessibile.

Tutt’altro che un successo, quindi. In effetti quella di aver realizzato un vero client di posta dentro un browser è una mossa azzeccata a livello di immagine. Ma la soluzione migliore sarebbe stata probabilmente un’altra, come ad esempio costruire un’applet Java, sempre da presentare dentro un browser. Certo, un po’ pesante da scaricare la prima volta (comunque qualche tonnella di Javascript dovete pur digerirla con Ajax), ma se non altro, se ben sviluppata, completamente accessibile.

E non venitemi a dire che comunque Google può essere usato anche senza suggerimenti, e che la mail di Yahoo! può essere letta anche in semplice formato Html, perché è un problema che ho già affrontato a proposito delle versioni di sito accessibile. A parità di funzionalità anche in questo caso una versione alternativa accessibile può andare bene, l’importante è che chi la realizza non se ne dimentichi dopo qualche mese senza riportare i relativi aggiornamenti (argomento delicato, visto il perenne stato di beta di molti applicativi web).

(Vedi anche Ajax e l’usabilità)

Web design estremo

Pubblicato il da
Risposta

I motivi per cui la navigazione di un visitatore può inciampare in qualche condizione imprevista sono molti: problemi al server, moduli non compilati correttamente (campi obbligatori mancanti, tipi di dato non previsti), link errati provenienti da motori di ricerca, ecc.

Chi sviluppa il sito deve rendersi conto che per quanta cura è stata posta nel design e nello sviluppo di un sito, prima o poi una di queste condizioni si verificherà.

I ragazzi di 37signals hanno scritto un manuale che presenta 40 linee guida da seguire nello sviluppo di un sito perché sia possibile prevedere e gestire correttamente alcuni punti di crisi, come ad esempio:

E’ importante aiutare l’utente che si trova in queste situazioni anomale perché possa efficacemente uscirne, senza ambiguità e con un linguaggio comprensibile, ma anche presentando le sole informazioni necessarie allo scopo.

L’approccio degli autori è fortunatamente molto pratico: viene brevemente presentata la linea guida e seguono immediatamente alcuni esempi negativi e positivi tratti da siti reali. Non aspettatevi però suggerimenti su come intervenire direttamente sul codice, perché non è una guida di Html o di sviluppo web.

Defensive Design for the Web – How to improve Error Messages, Help, Forms and Other Crisis Point * 37 Signals * New Riders * $24.99

Traduzione italiana:
Defensive Design per il web – Come migliorare messaggi di errore, help, form e altri punti critici di un sito * 37 Signals * Tecniche Nuove * euro 19.90