Archivi tag: cms

Scegliere il CMS Open Source per le proprie esigenze

Pubblicato il da

I sistemi di gestione dei contenuti (CMS) Open Source sono migliaia. E’ una verra manna, ma è anche un bel problema capire quello che potrebbe fare al caso nostro.

Un documento di Seth Gottlieb organizzato in modo decisamente funzionale cerca di aiutare a far luce sulle caratteristiche di questi sistemi.

Sono per prima cosa identificate le principali tipologie di impiego dei CMS: sito informativo stile “brochure”, periodico online, spazio di lavoro collaborativo, wiki, comunità online.
Per ciascuna categoria l’autore identifica poi non più di quattro CMS candidati, di cui descrive le caratteristiche, ma soprattutto in cui cerca di valutare quante risorse sono disponibili a chi decidesse di provarne l’impiego. Con risorse si intendono libri sul sistema di CMS, documentazione e articoli online e anche lo stato di attività della comunità cresciuta intorno al prodotto (forum, mailing list, ecc.).

La lettura è sicuramente un buon inizio per scoprire prodotti decisamente validi ai propri scopi.

Il ciclo di vita dell’accessibilità web (prima parte)

Pubblicato il da

Presentiamo una versione rivista e ampliata dell’articolo “The Lifecycle of Web Accessibility” pubblicata dall’autore su evolt.org in inglese nel dicembre 2002

La costruzione di un sito web è un compito che richiede competenze molteplici e diversificate, ognuna con il proprio ciclo di vita. Lo sviluppo, come abbiamo avuto modo di imparare all’università, ha un ciclo di vita, e così l’usabilità, la progettazione e la creazione dell’informazione.

Discutendo di accessibilità web sembra però che questa disciplina entri in gioco solo quando realizziamo le pagine o scriviamo i contenuti, ma solo a prima vista è così. Quella dell’accessibilità è una vera a propria cultura che deve essere chiara fin da subito a chiunque lavori alla costruzione del sito web, pena risultati scadenti.

In questo articolo suddivideremo il ciclo di vita dell’accessibilità di un sito web in 5 fasi e vedremo come queste siano strettamente collegate ad altre discipline, come la progettazione grafica, lo sviluppo e la gestione dei contenuti.

Anche se la trattazione procede per punti è bene sottolineare che questo ciclo non va inteso come una sequenza lineare di passaggi. Ci soffermeremo inoltre ad analizzare le competenze professionali richieste piuttosto che il ruolo delle persone (perchè la stessa persona può aver maturato diverse competenze, soprattutto nel caso di progetti di piccola dimensione).

La prima fase, tema di questa parte, è l’analisi dei requisiti.

Strategia e analisi dei requisiti

Di cosa si tratta

L’analisi dei requisiti rappresenta il momento in cui sono ipotizzati e in seguito definiti gli utenti del sito, vengono espresse le motivazioni economiche ed evidenziati i limiti tecnologici nonché le aspettative dell’utente. Vi troverete a interagire con il cliente per capire qual è l’obiettivo del sito e per assegnare il giusto numero di risorse e di mezzi per costruirlo.

Solitamente, se state facendo un buon lavoro, ipotizzerete diversi scenari d’uso. Uno scenario è un’ipotetica rappresentazione di come una specifica (e immaginaria) persona interagirà con il sito, ed è composto da un profilo utente (chiamato per l’appunto persona), dal programma di una sua giornata tipo e dalle aspettative che ha nei confronti del sito, ma anche molto di più.

Come entra in gioco l’accessibilità web

Dovete definire i profili delle persone che useranno il vostro sito, cercando di essere il più dettagliati possible. Questo significa che dovete prendere in considerazione persone con diversi gradi di abilità, sia fisica, sia tecnologiaca. Potete trovare degli esempi eccellenti leggendo “Dive Into Accessibility” di Mark Pilgrim, una serie di lezioni composta da 4 scenari basata su persone disabili e scritte dall’autore per aiutare gli sviluppatori a realizzare weblog (ma anche siti) accessibili.

Che tipo di disabilità prendere in considerazione dipende dal pubblico del vostro sito, ma non dimenticate che in linea generale una persona disabile interagisce con qualunque tipologia di sito. Potreste pensare, ad esempio, che un cieco non userà mai un sito che vende libri, ma questo è lontano dall’essere vero. E se vuole regalare il libro ad un amico: potete permettervi di escluderlo dalla lista dei vostri clienti?

Non dimenticatevi poi che l’accessibilità significa anche accesso al contenuto da parte di piattaforme (browser, sistemi operativi) tra di loro molto diversi.

Gli scenari che andrete a creare possono influenzare diversi e importanti aspetti del vostro progetto.

Se state riprogettando un sito, ad esempio, dovete decidere se convertire o meno del contenuto scritto per la versione precedente (in quanto potrebbe essere scritto in formato totalmente o parzialmente inaccessibile), o di convertirlo in formato accessibile. Questo potrebbe avere un forte impatto sui costi: è fondamentale prendere la decisione in questa fase.

Se state valutando l’acquisto di un CMS, dovete inoltre verificare la sua aderenza agli standard web e la possibilità che questo crei contenuti accessibili. Un aiuto ve lo può dare CMS Matrix, un sito che presenta un elenco aggiornato di questo tipo di soluzioni.

Attenzione però: CMS accessibile non vuol dire che deve essere semplicemente in grado di aggiungere gli attributi alt alle immagini o produrre codice valido. Se il vostro obiettivo è quello di servire periferiche diverse (telefonini, PDA) quello di cui avete bisogno è uno strumento che permetta di inviare contenuti diversi (ad esempio completi per il web, parziali per dispositivi con monitor limitati) a dispositivi diversi.

Non dimenticate poi che il CMS può aiutarvi a creare un contenuto accessibile, ma non può farlo al vostro posto (su questo argomento ritorneremo più avanti).

Se non riuscite a trovare un prodotto che rispetti le vostre richieste, potreste addirittura voler decidere di costruirlo voi stessi o di commissionarne uno.

In questa fase si tratta infine di individuare i redattori e in generale le figure professionali che prepareranno il contenuto del sito e si preoccuperanno di aggiornarlo. Hanno specifiche competenze in fatto di accessibilità web o devono essere opportunamente formati? Non fate passare troppo tempo prima di svolgere queste verifiche, anche perché prima siete pronti con il caricamento dei contenuti, prima potete inziarlo. Non è quasi mai obbligatorio attendere lo sviluppo di tutto il sito per cominciare a popolarlo di contenuti.

Finisce qui la prima fase del ciclo di vita. Nella prossimo interventi analizzeremo la progettazione contettuale, ovvero la struttura e funzionalità del sito.

Versione di sito alternativa e accessibile

Pubblicato il da

Chi si occupa di accessibilità e la deve applicare a un sito prima o poi arriva a chiedersi se può valere la pena crearne una o più versioni alternative, per soddisfare esigenze diverse.

In linea generale la risposta è no, perché impiegando opportunamente le tecnologie web (markup sensato e fogli di stile tra tutti) è possibile creare un sito graficamente attraente a accessibile.

Se però consideriamo l’accessibilità nella sua accezione più ampia e corretta (non solo disabili con problemi fisici e psichici, ma anche dispositivi e ambienti di fruizione diversi), ci scontriamo con categorie che hanno delle esigenze a volte in contrasto.

Un browser della vecchia generazione, ad esempio, non è in grado di interpretare la pagina allo stesso modo delle ultime versioni. Certo, è possibile adattare il codice perché il risultato sia almeno mediocre, ma così facendo non stiamo trattando l’utente di quel browser come una persona di seconda classe?

Va anche considerato che non sempre il problema è di presentazione, ma a volte anche di organizzazione e trasformazione.

Basti pensare alla paginazione degli articoli, che rende sicuramente la pagina ordinata per i più, ma costringe chi sta utilizzando uno screen reader a dover caricare più pagine prima di rendersi conto della struttura del contenuto, quando magari sarebbe bastato saltare tra le diverse intestazioni presenti in un’unica pagina. Anche la versione di stampa dovrebbe essere composta di un’unica pagina.

Pensiamo poi alla fruizione di contenuto in un telefonino. Il foglio di stile magari consentirebbe anche di visualizzarlo, ma un articolo di 100 righe su un piccolo display non è la soluzione ideale. In questo caso andrebbe presentato solo il sommario ed eventualmente il contenuto suddiviso in parti molto piccole, con la possibilità di passare agevolmente da una pagina alla successiva.

Stesso discorso con i moduli da compilare. Su un telefonino è forse più semplice utilizzare dei combobox per i campi giorno, mese, anno di nascita, ma forse per chi utilizza una tastiera è più veloce scrivere direttamente il dato piuttosto che selezionarlo da una lista.

Per queste esigenze (e per molte altre) non è sufficiente applicare uno stile di presentazione diverso, è necessario costruire una versione ad hoc della pagina. Il che però non vuol per forza dire moltiplicare il lavoro per il numero di versioni da creare, a meno che non si tratti di un sito statico.

Nel caso il sito sia completamente statico è infatti impensabile costruirne versioni alternative, perché troppo oneroso. Esiste però una situazione in cui chiedersi se realizzare versioni alternative potrebbe essere una buona idea:

  • se il sito è dinamico (cioè se il contenuto della pagina viene costruito utilizzando uno o più template predefiniti)
  • se il sito è di discrete dimensioni
  • se il sito ospita principalmente contenuti in forma di testo e multimedia

Situazione questa solo a prima vista rara, i quanto vi cadono praticamente tutti i siti della pubblica amministrazione.

In questo caso vale la pena verificare se il sistema di gestione dei contenuti (CMS) ha la possibilità di associare al contenuto una serie di regole che stabiliscano come deve essere trasformato per i diversi fruitori. Si tratta molte volte di semplici regole che associano un template ad uno o più documenti.

Sarà poi l’utente del sito a scegliere quale configurazione meglio si adatta alle sue esigenze o a quelle del dispositivo che sta utilizzando, oppure sarà direttamente il codice del sito ad adattare il proprio aspetto riconoscendo il richiedente.

Quanto detto ha ancora più senso se inquadrato nella visione del web chiamata Web 2.0, ovvero del web come piattaforma. Lo strato di presentazione avrà sempre meno importanza o – meglio – sarà sempre meno importante che lo stesso sito sia in grado di soddisfare le aspettative di tutti gli utenti. Sarà invece sempre più probabile che i siti realizzino interfacce specifiche con l’informazione di altri, integrando più fonti.

In questo senso l’utente di uno screen reader potrebbe accedere ad una versione del sito specificatamente pensata per la sua periferica di utilizzo, versione che potrebbe essere ospitata dallo stesso sito, oppure da tutt’altra parte.