I 15 princìpi web della BBC

Tom Loosemore della BBC ha pubblicato nel suo weblog un elenco di 15 punti che i dipendenti del network inglese sono tenuti a rispettare nel progettare e aggiornare i propri siti.

Li ho trovati degli ottimi comandamenti che andrebbero stampati e appesi vicino al monitor, e li traduco qui con qualche libertà:

  1. Realizza prodotti che incontrino le necessità del tuo pubblico
  2. I migliori siti web fanno una sola cosa, e la fanno molto bene
  3. Non cercare di fare tutto da solo, inserisci collegamenti ad altri siti di qualità
  4. Sperimenta e verifica velocemente, itera
  5. Tratta tutto il web come una tela creativa: non restringere la creatività al tuo solo sito
  6. Il web è una conversazione. Partecipa. Adotta un tono rilassato, ammetti i tuoi errori
  7. La qualità dell’intero sito è data dalla qualità della sua pagina peggiore. Verifica che le linee guida editoriali siano adottate e seguite
  8. Assicurati che sia possibile aggiungere collegamenti verso le tue pagine. Per sempre
  9. Ricordati che tua nonna non userà mai “Second Life”. Potrebbe utilizzare internet, ma con esigenze molto diverse da quelle dei precursori
  10. Crea diversi percorsi per raggiungere il contenuto: sviluppa aggregazioni per persone, luoghi, argomenti, canali, ecc. Ottimizza il sito per l’indicizzazione nei motori di ricerca
  11. Design e percorsi di navigazione consistenti coerenti non significa che una soluzione vada bene per tutti: gli utenti devono sempre sapere che si trovano su uno dei tuoi siti, ma questi possono essere anche molto diversi tra loro
  12. L’accessibilità non è un optional
  13. Fa’ in modo che i tuoi utenti possano copiare e incollare i tuo contenuti sulle pareti delle loro case virtuali: incoraggia gli utenti a prendere estratti di contenuto dalla tue pagine, e a inserire link verso il tuo sito
  14. Inserisci link alla discussioni che nascono nel web, non limitarti a ospitarle
  15. La personalizzazione dev’essere non intrusiva, elegante e trasparente. Dopo tutto si tratta dei dati dei tuoi utenti, che vanno rispettati

Del punto 12, relativo all’accessibilità, ho avuto modo di parlare molto. Anche l’ultimo, che parla di personalizzazione, è stato oggetto di qualche considerazione su Fucinaweb, a proposito delle interfacce che si adattano.

Feedburner e Google: c’è modo e modo

Davvero brutta la precisazione che compare al login di FeedBurner da qualche giorno, dopo l’acquisizione di Google.

Eccola tradotta in italiano con qualche libertà:

Gli account di FeedBurner non saranno cancellati come risultato dell’acquisizione di Google. Avete 14 giorni di tempo, fino al 15 Giugno 2007, per decidere di non consentire il trasferimento del vostro account verso Google. Se non lo fate esplicitamente, i diritti di gestione dei vostri dati passeranno da FeedBurner a Google. Il mancato trasferimento terminerà invece il vostro accordo con FeedBurner, porterà alla cancellazione del vostro account FeedBurner, dei feed, di tutte le statistiche con relativo archivio, e non trasferirà i vostri dati a Google.

Accidenti, come stride questa scritta nelle pagine di FeedBurner, solitamente piene di ironia e con un copywriting studiato ad arte.

Non si poteva scrivere qualcosa del tipo:

Ehi, c’è un importante aspetto che riguarda il tuo login e l’acquisizione di FeedBurner da parte di Google. Hai 14 giorni di tempo per decidere. Clicca qua per i dettagli.

Ma anche se avesse dovuto rimanere tutto in una pagina, si sarebbe sicuramente potuto studiare qualcosa di meno arrogante, indipendentemente dall’importanza dell’informazione.

L’accessibilità nello sviluppo di un sito

Qualche anno fa ho scritto per evolt.org un articolo, “The lifecycle of wb accessibility“, in cui sottolineo l’importanza di considerare l’accessibilità web non come un singolo passaggio di un progetto, ma come una necessità che ne influenza l’intero ciclo, dalla fase di analisi dei requisiti fino alla manutenzione.

Hi ritrovato una simulitudine tra questo articolo e l’intervento che Peter Krantz ha scritto per Standards Schmandards, “Bringing Accessibility into the Development Process“.

Krantz si chiede in particolare se possa essere impiegato qualche software di validazione che sia in grado di fornire un primo livello di allerta in tempi brevi ai componenti del team di progetto web. Propone l’uso di Raakt (The Ruby Accessibility Analysis Kit), un “gem” di Ruby on Rails per l’inclusione negli unit test Html.

Nella carta questo kit si rivolge a chi ha poca conoscenza di accessibilità web e potete vederne un impiego in azione così da saggiarne le caratteristiche.

Come al solito, serve un po’ di cautela e coscenza critica: l’accessibilità web fa a botte con i tool automatici.

Qualcuno di voi ha avuto modo di provarne le funzionalità?