Una ricerca di Web 2.0 su del.icio.us restituisce una serie di articoli e discussioni di quella che è una (non troppo nuova) visione del web.
Chi lavora pesantemente con il web sta infatti maturando una consapevolezza segnata da un lato dalla diffusione inarrestabile dei contenuti, dall’altro dalla solidità dei servizi che rendono disponibili interfacce per facilitarne l’integrazione da parte del mondo esterno. Questa consapevolezza è che il sito web tradizionale non è più il centro del web e, cosa ancora più importante, non più una scatola a tenuta stagna dei contenuti che ospita.
Diventerà sempre più importante (e per alcuni lo è già) favorire lo scambio di dati tra diverse realtà che siano in grado di trasformare, integrare, presentare e riproporre il contenuto (l’informazione e i dati) nei modi più diversi agli utenti più disparati.
Pensate ad esempio agli sforzi fatti da Amazon e Google per rendere disponibile una serie di interfacce applicative (API) così da facilitare il lavoro di quanti, utilizzando i loro servizi, vogliano costruire delle interfacce assolutamente personalizzate. Rss, Api, Xml, Soap, Web Services sono alcuni degli standard e delle architetture che già consentono di realizzare tutto questo e il cui successo è dovuto principalmente dall’incremento esponenziale dei dati da gestire e integrare e dall’impossibilità per un unico attore di farlo.
Questa nuova strada ha delle ripercussioni non solo sul lavoro di chi sviluppa l’architettura hardware e software di un sito, ma anche di chi si occupa della costruzione dell’interfaccia di presentazione.
Lo dice bene Richard MacManus in un suo articolo per Digital Web Magazine dello scorso Maggio:
In the early days, designers used tricks like aninated GIF’s and table hacks in cliever, interesting an horrible ways. In the last few years, CSS came into fashion to help separate style from structure.[…] Even so, the focus was still on visual design.[…] Designers need to become more like programmers.
Non possiamo che essere d’accordo con MacManus anche perché è da qualche anno che, attraverso questo sito, diciamo la stessa cosa. Lo abbiamo fatto in “Chi ha paura di Xhtml8?“, un articolo in risposta a chi (troppo legato all’aspetto visuale di un sito) si preoccupava dell’obsolescenza di un sito solo per la variazione delle specifiche Html:
Perché preferire Xhtml a Html? Tra tutti i pregi, sicuramente il fatto che un documento Xhtml è anche un particolare tipo di documento Xml.
E qual è il vantaggio di Xml? Perché preoccuparsi di questo standard a prima vista esoterico? Con Xml potete definire accuratamente i dati e la struttura delle informazioni della realtà in esame (un libro, un listino prodotti, ecc.). Non solo: avete la possibilità di trasformare agevolmente un documento Xml per ottenere risultati molto diversi (una pagina web, un file di testo, un documento Pdf, un altro documento Xml). Per farlo si utilizzano le trasformazioni Xsl (Xslt), un linguaggio decisamente potente che è possibile imparare e addomesticare in poco tempo.
Ma lo abbiamo fatto in modo ancora più marcato (suscitando anche qui qualche malumore da parte di chi si preoccupa solo dell’aspetto grafico di una pagina) in “Gli standard web sono inutili da soli“. Ecco cosa abbiamo detto a proposito di un sito complesso, con audience diversificato:
Certo è vero, con i Css è teoricamente possibile servire un maggior numero di dispositivi. Tutto bene fin che si tratta di browser, ma provate ad immaginarvi mentre leggete la pagina di un sito in un monitor grande come il display di un cellulare. Non basta presentare l’informazione in modi alternativi, ma essere in grado di trasformarla (anche ridurla). Nel nostro caso, al browser verrà inviato l’intero articolo, mentre al cellulare solo il titolo, il sommario e un abstract.
Nessun problema comunque: abbiamo infatti scelto di adottare lo standard Xsl e quindi, con semplicissime trasformazioni riusciamo a rendere disponibili diverse interfacce di fruizione. Non solo, mentre con i Css possiamo variare la presentazione, ma il contenuto rimane lo stesso (possiamo al limite cercare di nasconderlo), con opportune trasformazioni l’utente può decidere quali informazioni ricevere, e in che ordine. Riusciamo quindi non solo a presentare in modi diversi le informazioni con documenti Xslt diversi, ma anche a filtrarle in modo da presentare ad un palmare solo la versione essenziale, al posto di quella completa.
Insomma, l’aspetto visivo di un sito è certamente importante, e deve essere realizzato con la massima cura e aderenza agli standard, così da essere accessibile al maggior numero di dispositivi.
Ma in futuro la probabilità che per ottenere questo risultato sia sufficiente cambiare solo l’aspetto dell’informazione sarà sempre minore, perché sempre più spesso è necessario integrare diverse fonti e trasformare lo stesso dato. Cercare di risolvere tutti questi problemi focalizzandosi solo sulla costruzione di uno o più fogli di stile, come se questi rappresentassero la risposta a tutti i mali, è puramente utopistico.
Questo vuol dire che un browser di vecchia generazione, uno screen reader, un palmare o un browser potrebbero ricevere lo stesso contenuto base da siti diversi, ma trasformato e adattato secondo le esigenze, a dei costi irrisori. Il costo infatti non è certamente dato dalla costruzione di qualche foglio di stile o dalla definizione di regole di traformazione, ma dalla produzione dei dati e del contenuto. Per questo lo sforzo principale dev’essere quello di rendere semplice ed efficace la diffusione e il consumo dell’informazione.
Il nostro suggerimento (per la verità già espresso più volte) verso chi si occupa di design di siti e non l’ha già fatto, è quello di affrontare lo studio delle architetture di siti governate dai Cms e di cominciare a realizzare qualche semplice esempio di trasformazione con Xml e Xsl, così da rendersi conto delle potenzialità di queste soluzioni.
