Web Design - Pagina 4 di 13

Italia.it è tornato

Un’analisi approfondita della nuova versione del portale del turismo italiano.

Ho trattato più volte su questo sito l’argomento italia.it, il portale del turismo italiano che da anni cerca di decollare senza riuscirci. Non potevo così trattenermi dall’analizzare la nuova versione, presentata al grande pubblico il 17 Luglio scorso.

Premetto che questo articolo non vuole essere una critica fine a se stessa, ma un modo per analizzare lo stato attuale del portale e suggerire possibili miglioramenti. Ho intenzione di segnalarlo anche tramite la pagina “Collabora” di italia.it, soprattutto se vorrete aggiungere i vostri commenti.

Un sito accessibile?

Le pubbliche amministrazioni come noto sono sottoposte alla legge Stanca, che definisce i requisiti obbligatori per l’accessibilità dei siti realizzati. Nel footer di italia.it viene linkata una pagina con una dichiarazione di accessibilità che afferma:

La home page e le altre pagine del sito promozionale turistico sono state realizzate cercando di rispettare tutti i 22 requisiti tecnici contenuti nel Decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005, approvato conformemente a quanto previsto nella Legge n. 4 del 9 gennaio 2004 recante “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici” (Legge Stanca) [..]

Quel “cercando di rispettare” non promette niente di buono, ma una verifica è comunque d’obbligo. Tralasciando tour virtuali e mappe, che vengono a priori segnalati come non accessibili, mi sono limitato ad esaminare l’homepage del sito.

Il problema principale è l’organizzazione dei titoli: c’è un tag H1, ma è usato per la frase “Benvenuti in Italia” e non per il titolo del sito. Manca poi totalmente il tag H2, e si salta all’H3 delle sottosezioni.

Confonde non poco la presenza di link nel menu principale che si aprono in nuove tab del browser. Non è stato usato l’attributo deprecato target=”_blank”, ma una soluzione JavaScript: stratagemma valido dal punto di vista formale, ma poco logico se si considera che nello stesso menu ci sono pagine che si aprono normalmente ed altre che portano su siti esterni.

Disabilitando JavaScript, vengono visualizzati comunque nella pagina elementi come le frecce di scorrimento dei vari carousel. Problema comune a molti siti: JavaScript è stato utilizzato in maniera intrusiva, senza usare il progressive enhancement.

Con le immagini disabilitate il sito mostra tutte le sue debolezze: la home risulta praticamente vuota.

Validazione del codice

Per quanto riguarda la validità dell’HTML ad una prima occhiata i risultati potrebbero sembrare buoni: almeno in homepage manca solo l’attributo alt sull’immagine di testa. Il problema è che la validazione non dovrebbe fermarsi solo alla home, che molto spesso (e soprattutto qui) è una semplice vetrina. Molti contenuti sono nelle pagine interne e sul fantomatico dominio visual-italy.it: i problemi sono tutti lì.

Sul sito “parallelo”, raggiungibile dal menu principale, non mancano infatti le sorprese:

tag non chiusi
doctype che passa misteriosamente da XHTML 1.0 Strict a HTML 4.01 a seconda della pagina visitata
ID ripetuti
attributi inesistenti per la doctype dichiarata

Risultato quindi apparentemente buono per italia.it, ma è una validità solo di facciata, che crolla non appena si naviga qualche pagina in più.

SEO – Search Engine Optimization

Alcuni degli aspetti che ho analizzato influiscono pesantemente anche sull’ottimizzazione dei motori di ricerca, a cominciare dall’uso dei titoli.

A questo si aggiungono:

La totale assenza di title su misura per le varie pagine del sito
La mancanza di meta keywords e description
La scarsità di contenuti testuali, spesso inutili quando presenti

Un sito come questo non ha problemi ad essere indicizzato per via del clamore che solleva, ma le pagine interne se resteranno così rimarranno in un inutile limbo, proprio perchè carenti di contenuti. Se poi anche le regioni vengono scambiate tra loro, il quadro diventa ridicolo.

La lingua e le traduzioni

Una nota finale è d’obbligo sulla lingua. Siamo sicuri che il target principale di un sito del genere siano gli italiani? Come mai molti siti esteri equivalenti presentano di default la versione inglese? Lo stesso dubbio viene sollevato anche da Massimo Mantellini nel suo Contrappunti, su Punto Informatico.

A questo si aggiungono delle strane scelte, come quella di utilizzare per tutte le lingue un titolo di sezione come “Italia Much More”. Perchè?

Conclusioni

Per considerando lo stato di beta dichiarato dal ministro Brambilla per l’attuale versione di italia.it, ci sono poche speranze che le cose possano cambiare con il rilascio definitivo previsto in autunno. Il problema è l’idea alla base: un sito del genere non serve a nessuno, nè ai turisti stranieri, nè tantomeno agli italiani, che non possono trovare alcuna utilità in un portale vetrina.

Un turista deve poter conoscere le indicazioni dei visitatori che sono stati in un posto prima di lui, oltre a vedere i prezzi degli alberghi e programmare ogni spostamento. Sapere che i principali aereoporti italiani sono Malpensa e Fiumicino e che l’offerta di voli “è ampia e copre un vasto numero di destinazioni” non serve a nessuno.

Sono tutti soldi pubblici spesi inutilmente per un sito che non offre alcun motivo per ritornare dopo la prima visita. I 45 milioni di euro stanziati per il primo progetto sembrano ormai un lontano ricordo (ma quanti ne furono comunque spesi?), ma l’investimento su questo secondo tentativo sarà inutile se non cambierà l’idea alla base. E’ incomprensibile una spesa di 10 milioni, anche considerando gli sviluppi futuri e le attività promozionali in programma.

Il mio suggerimento? Coinvolgere sviluppatori realmente competenti e web designer interessati all’usabilità dei propri lavori, ricordando di garantire a tutti l’accesso alle risorse della rete. La collaborazione è la chiave, non solo dietro le quinte: coinvolgere gli utenti è il modo migliore per ottenere dei risultati, rendendoli parte attiva del progetto.

Classi HTML: buone pratiche ed errori comuni

Google pubblica l’analisi di un miliardo di pagine web: le classi HTML più usate mostrano dati interessanti ed errori da evitare.

Esistono numerosi studi sulle pratiche più diffuse nel web design, ma spesso queste analisi vengono effettuate su un campione ristretto, non attendibile. Google ha pubblicato uno studio che fa luce su alcuni aspetti: pur non essendo troppo approfondito, può contare su un campione di più di un miliardo di pagine web. Abbastanza per fermarsi ad osservare i dati provando a trarne qualche conclusione.

Tra gli argomenti dello studio voglio considerare soprattutto le classi HTML, per capire anche quante speranze esistano di avvicinarsi alla nascita di un web semantico.

I risultati dello studio di Google sulle classi HTML

Prima di tutto, è necessario analizzare un aspetto: la maggior parte delle pagine web non utilizza alcuna classe. E’ un dato che potrebbe sorprendere, ma ricordate che stiamo parlando di una rete dove regnano ancora incontrastate le pagine con codice non valido, generate da software inefficaci, dove le tabelle vengono usate ancora per il layout.

La classifica delle classi più utilizzate è la seguente:

footer
menu
title
small
text
content
header
nav
copyright
button
main
search
msonormal
date
smalltext
body
style1
top
white
link

Alcune sono comuni, come header e footer, l’utilizzo di altre invece è totalmente errato.

Gli errori più comuni

Tra le classi di questa top 20, sono senza dubbio da evitare tutte quelle con un nome senza significato come msonormal o style1. Tra l’altro MsoNormal è una classe generata da Office esportando un documento come pagina web. Il fatto che sia presente tra le più utilizzate è indicativo della qualità media della rete e di come vengano realizzati molti siti: che sia un problema irrisolvibile?

Sono poi usate in maniera sbagliata le classi con un nome collegato all’aspetto presentazionale, come white.

Una guida da seguire

Se avete dubbi su come scrivere il codice HTML, utilizzando ID e classi nel modo corretto, trovate alcune indicazioni utili in un articolo che ho pubblicato qualche mese fa: “Guida all’utilizzo di ID e classi nel codice HTML”. L’argomento è sempre valido, per questo ci tengo a segnalarlo.

Il codice dovrebbe essere scritto sempre in maniera comprensibile, trovando il giusto equilibrio tra sintesi e leggibilità, senza dimenticare di usare nomi legati alla funzione di un elemento e non al suo aspetto.

Nel caso aveste delle aggiunte da segnalare o qualche suggerimento da farmi, lasciateli come sempre nei commenti e provvederò ad integrare la guida: il vostro contributo è sempre prezioso.

WordCamp 2009: il resoconto

La cronaca del secondo BarCamp italiano dedicato a Wordpress.

Sono appena rientrato dal secondo WordCamp italiano, che anche quest’anno si è rivelato un bell’evento. Un ospite importante, alcuni bei talk, ma soprattutto in questi incontri il vero valore aggiunto è rappresentato dalle conoscenze che si fanno: essere a contatto diretto con altri blogger e lavoratori del settore è un ottimo modo per approfondire i rapporti, e socializzare molto più facilmente che da dietro ad uno schermo.

Parlando di WordPress, la presenza più importante di questo BarCamp era senza dubbio quella di Andy Peatling, l’autore di BuddyPress. Si tratta di una vera e propria suite di plugin e temi che permettono di trasformare una qualsiasi installazione di WordPress MU in una community, con tutte le sue funzioni più importanti. Profili estesi degli utenti, messaggi diretti, amicizie, gruppi, forum: tutto ciò può essere implementato senza troppe difficoltà, con molta più libertà di gestione rispetto ad altri sistemi (ad esempio appoggiandosi a piattaforme esterne come Ning).

Vista la natura del progetto, è logico che sia una suite dedicata a WordPress MU piuttosto che ad una singola installazione di WordPress, ma lo stesso Wolly (che ringrazio ancora per aver organizzato il WordCamp) mi ha confermato che con qualche hack non è impossibile adattare BuddyPress anche ad un ambito più ristretto.

Per il resto, devo riconoscere che tra i talk in programma nella giornata di Sabato (il Venerdì non ero presente), avrei apprezzato qualche approfondimento tecnico in più su WordPress. Da questo punto di vista mi era piaciuto di più il WordCamp 2008: erano numerose le presentazioni sull’ottimizzazione della piattaforma e su come sfruttarla al meglio. Si è parlato di OpenOffice e della sua integrazione con WordPress, dell’esperienza della Fiat su internet, del manifesto di Marco Massarotto per le aziende che vogliono affacciarsi in rete, ma ho sentito comunque la mancanza di qualcosa.

Trovate alcune foto dell’evento sul mio account Flickr, nel set dedicato. Mi ha fatto molto piacere rivedere Tambu e conoscere Francesco Gavello, che ha confermato tutte le buone impressioni che avevo avuto su di lui e sono sicuro continuerà a far parlare di sè con il suo blog. Interessanti anche i discorsi fatti con Julius su BlogMagazine, che partito da zero sta avendo sempre più riconoscimenti: io stesso ero scettico sulle possibilità dell’iniziativa, ma vi consiglio di tenere d’occhio quello che succederà nei prossimi mesi, potreste rimanere sorpresi. Un applauso anche a Luca Sartoni per la bella presentazione (“WFT? Non funziona!”).

A questo punto il prossimo anno non avete scuse: se questo resoconto vi ha incuriosito, vi sarebbe sicuramente piaciuto essere presenti. Per il futuro sarà interessante vedere se si riusciranno ad organizzare WordCamp locali nelle varie città italiane, come auspicato anche dagli organizzatori. Sarebbe una bella occasione per coinvolgere tutte coloro che non hanno voglia di spostarsi, ma che possono dare il loro contributo alla causa di WordPress.

Selettori adiacenti con i CSS

E’ il momento di sperimentare nuove proprietà dei fogli di stile.

I selettori adiacenti sono una funzionalità dei CSS spesso ignorata, ma dalle grandi potenzialità. Con una semplice dichiarazione infatti è possibile identificare l’elemento immediatamente vicino (quindi adiacente) ad un altro. Ad esempio con

div + p { color: #a00; }

è possibile assegnare delle proprietà al primo paragrafo contenuto in un div, paragrafo che in questo caso diventerà rosso.

Niente classi o id, è possibile gestire tutto tramite CSS senza bisogno di appesantire il codice HTML. L’altra buona notizia è che questo tipo di selettore funziona su tutti i principali browser, escluso ovviamente Internet Explorer 6. Firefox, Explorer 7, Safari, Opera e Chrome la supportano senza problemi.

E’ tempo quindi di sperimentare ed iniziare ad utilizzarli, anche come progressive enhancement, per offrire ai visitatori con un browser recente una migliore esperienza di navigazione.

Se volete vedere un esempio pratico, ho fatto il mio primo esperimento con i selettori adiacenti nel footer di TomStardust Diary:

Questo post è nato da una discussione su Friendfeed: una chiara dimostrazione dell’utilità dei social networks. C’è ancora qualcuno che ne dubita?

Nascondere un elemento con i CSS in modo accessibile

I problemi nell’utilizzo del display:none e le alternative possibili.

Nella realizzazione di un sito è ricorrente la necessità di nascondere elementi presenti nel codice HTML: basti pensare agli skip link o alle tecniche di image replacement. Ci sono diversi modi per farlo con i CSS, ma non tutti sono corretti.

Evitare il display:none

Un metodo diffuso, che però è sbagliato, è utilizzare display: none per nascondere totalmente la parte di codice desiderata. Questa tecnica è inaccessibile, perchè elimina l’elemento dalla pagina come se non esistesse. La maggior parte degli screen reader trovando un elemento con display: none lo salterà senza leggerlo.

Pensate all’intestazione di un sito ed ai link per facilitare la navigazione nascosti in questo modo: non facendoli leggere agli screen reader l’accessibilità della pagina viene compromessa.

Trovate anche un approfondimento sul comportamento degli screen reader in questo articolo di Roger Johansson.

La soluzione con position:absolute

La soluzione più semplice è utilizzare position: absolute invece di display: none:

.skip { position: absolute; left: -9999px; }

In questo modo gli screen reader continueranno a leggere l’elemento nascosto. Per migliorare ulteriormente l’accessibilità della pagina con un occhio di riguardo alla navigazione da tastiera, è utile un’aggiunta del tipo:

.skip a:active, .skip a:focus { position: absolute; left: 1em; }

Così usando il tasto tab per spostarsi tra i collegamenti della pagina, gli elementi nascosti appariranno quando selezionati.

L’alternativa: text-indent

Una soluzione alternativa per nascondere un elemento della pagina può essere la proprietà text-indent, con un valore negativo:

.skip { text-indent: -9999px; }

Questo metodo a volte viene usato per mantenere l’elemento contenitore nella pagina, facendo sparire solo il suo contenuto testuale. E’ da verificare nei vari casi il supporto dei browser, ma tutti quelli più importanti non dovrebbero avere problemi.

Testo nascosto con JavaScript

Un ultimo aspetto da considerare è la gestione di elementi della pagina che appaiono solo dopo un’azione dell’utente, usando JavaScript. E’ sbagliato nasconderli con i CSS: se questi elementi (ad esempio un menu a tendina) appaiono grazie a JavaScript, devono essere nascosti al caricamento della pagina secondo lo stesso principio.

La tecnica più semplice è usare JavaScript per assegnare una classe all’elemento desiderato e quindi nasconderlo (senza usare display: none!) tramite CSS.

E’ importante comprendere i problemi relativi al display: none descritti in questo articolo. Usandolo con cognizione di causa eviterete dei problemi ai vostri utenti: se conoscete altre soluzioni valide i commenti sono a vostra disposizione.

Checklist per un sito usabile

Nove punti da seguire per migliorare il proprio sito.

Navigando in rete ho spesso la sensazione che l’usabilità sia spesso trascurata. E’ davvero inutile prestare attenzione all’esperienza dei propri visitatori? Ovviamente no.

Quelle che seguono sono indicazioni il più possibile generiche per migliorare l’usabilità del vostro sito. Non diventerà usabile semplicemente seguendo questi 9 punti, ma penso siano un buon punto di partenza.

1. Nome del sito

Il titolo del sito deve essere chiaro e visibile in ogni pagina, così come il logo (se esiste). E’ consuetudine inoltre che l’area occupata da questi elementi abbia un link alla homepage: è frustrante tentare di cliccare un elemento e scoprire che non porta da nessuna parte.

2. Tagline / Sottotitolo

La tagline è una breve frase che comunica velocemente lo scopo del sito che si sta visitando. Difficile farne a meno: che si tratti di un portfolio, di un blog o di un sito aziendale, è bene che il visitatore capisca subito l’argomento trattato.

3. Titolo della pagina

E’ essenziale che ogni pagina sia identificata in maniera univoca. Il titolo della pagina dovrebbe essere presente anche tra i tag <title></title>: questo permetterà di riconoscere un sito anche se sono aperte più finestre (o più tab) del browser.

4. Breadcrumb / Path / Briciole di pane

E’ il modo migliore per far capire ad un visitatore dove si trova. In italiano il breadcrumb viene chiamato anche “briciole di pane”, e la sua funzione è evidente. Se avete un sito su più livelli non potete farne a meno.

5. Navigazione principale

La navigazione deve essere chiara e coerente tra tutte le sezioni. Non cambiate mai posizione ad un menu, è bene che ogni visitatore sia in grado di orientarsi. Un’eccezione a questa regola è rappresentata dai menu secondari, che possono apparire o meno a seconda della pagina e della presenza di sottosezioni.

Nella navigazione è importante anche contrassegnare la pagina corrente, se presente nei menu, magari rendendola anche non cliccabile.

6. Box di Ricerca

Anche la ricerca è un metodo di navigazione. In certi casi è il modo più veloce per raggiungere informazioni presenti sul vostro sito, magari non più recenti. Se decidete di implementare la ricerca, fate in modo che il box sia visibile e presente in ogni pagina.

7. Link testuali

Uno dei problemi più fastidiosi è trovare in un sito dei link di testo che non appaiono come tali. Se i collegamenti si confondono con il testo normale, è il caso di modificarne l’aspetto. Trovate maggiori informazioni in un articolo sui link che ho scritto qualche settimana fa.

8. Colori e grafica

Così come per la navigazione, anche la grafica deve mantenere una sua coerenza tra le varie sezioni di un sito. E’ bene che i colori utilizzati non cambino tra le varie pagine per non confondere le idee. E’ possibile distinguere sezioni diverse con colori differenti, ma è una soluzione rischiosa se applicata male, spesso è meglio non rischiare.

9. Avvisi

Se sul sito compaiono degli avvisi, è bene che la loro funzione sia chiara. Possono essere contrassegnati da un’icona e da colori differenti, tenendo presenti alcune consuetudini:

il rosso indica un errore o un avviso importante
il verde una conferma
il giallo un avviso generico

E’ bene utilizzare delle notifiche di questo tipo quando vengono eseguite azioni importanti, come una procedura di acquisto. L’utente deve capire senza problemi quello che sta facendo e quali azioni può compiere.

In conclusione

Non è possibile imparare in poco tempo a realizzare un sito usabile, ma avere una checklist da controllare spero possa esservi utile. Tenete comunque presente che queste raccomandazioni non sono universali, potrebbero esserci delle eccezioni a seconda del sito.

Abbandonare XHTML?

E’ logico abbandonare XHTML in attesa di HTML 5? Un approfondimento sulle recenti discussioni in rete.

Tutto è iniziato con un post di Dave Shea su Mezzoblue, che sollevando non poco stupore ha dichiarato:

Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Un salto indietro di svariati anni, per tornare a realizzare pagine in semplice HTML, abbandonando una specifica ben più rigorosa come l’XHTML.

Questo cambiamento è da interpretare in proiezione futura, per via del supporto di alcuni browser (Opera soprattutto) e dell’attuale stato delle specifiche. Non è un mistero che XHTML 2 sia ancora indietro, mentre con HTML 5 sia già possibile ottenere dei risultati: ne avevo parlato anche in un articolo sui form.

La discussione per quanto riguarda l’Italia è proseguita su Edit, dove nei commenti del post Bye Bye XHTML si scontrano le due posizioni. Chi difende il web semantico e XHTML ha le sue ragioni, ma non è così incomprensibile appoggiare la semplicità di HTML 5.

E’ veramente ora di abbandonare XHTML?

La risposta a questa domanda va in controtendenza con quanto affermato da Dave Shea.

La specifica XHTML infatti è attualmente la scelta migliore.

Che senso avrebbe tornare a HTML 4? Dal mio punto di vista sarebbe un passo indietro, non giustificabile guardando al futuro. E’ lecito prepararsi a HTML 5, diversi siti lo stanno già facendo, ma il suo supporto è appena agli inizi: qualsiasi cambiamento è ancora prematuro. Ovviamente è un’opinione personale, se la pensate diversamente mi farebbe piacere discuterne nei commenti.

Come realizzare un menu a tendina

Le regole da seguire nella creazione di un dropdown menu usabile.

I menu a tendina sono un’ottima soluzione per rendere accessibili più pagine ai visitatori del sito. Possono essere realizzati usando solo i CSS o anche JavaScript, ma è comunque necessario rispettare alcune regole:

Le voci devono avere un’area estesa, comodamente selezionabile, per consentire una navigazione facile. Sono sconsigliate le etichette di testo troppo lunghe.
E’ utile un ritardo di qualche frazione di secondo su apertura e chiusura del menu, per evitare attivazioni involontarie spostando il mouse
Il menu deve potersi riposizionare a seconda delle dimensioni della finestra del browser, spostandosi in un’area visibile quando si trova vicino ai margini della stessa. Un classico errore è mostrato nell’immagine:
All’apertura della tendina, l’utente deve vedere tutte le voci insieme, senza necessità di effettuare scroll della pagina
I link di primo livello devono avere una destinazione, che sarà utilizzata anche se il menu non è accessibile (ad esempio JavaScript disabilitato)
Un menu a tendina non è una mappa del sito, è inutile e dannoso elencare tutte le pagine
Le voci selezionate dall’utente all’interno del menu dovrebbero rimanere evidenti
Il menu dovrebbe essere perfettamente navigabile anche da tastiera
I menu realizzati esclusivamente con i CSS spesso sono poco usabili: a volte è meglio evitarli. Senza JavaScript infatti non è possibile gestire alcuni aspetti come il ritardo sull’apertura e sulla chiusura.
Con JavaScript disabilitato il sito deve essere comunque navigabile
Le voci dei sottomenu è bene che siano accessibili agli screen reader senza nasconderle con display: none (ma con position: absolute)

Queste regole andrebbero rispettate in ogni occasione: per alcune potrebbe essere concessa qualche eccezione a seconda delle circostanze, ma alcuni requisiti come l’usabilità sono fondamentali. Un menu a tendina deve essere facile da utilizzare, perchè è il mezzo principale per far navigare gli utenti nel vostro sito. In certi casi conviene mantenere un menu classico, se l’alternativa deve essere poco usabile.

Esempi di menu a tendina

Esistono diverse risorse disponibili per realizzare un menu a tendina senza troppi problemi. Non tutte però seguono i principi elencati: ve ne segnalo un paio. Potete usarle come un ottimo punto di partenza per i vostri siti:

Free CSS DropDown menu Framework: una soluzione modulare, con diversi temi grafici già pronti
MenuMatic: un plugin per la libreria Mootools che trasforma una lista di link HTML in un menu a tendina

Se conoscete altre risorse interessanti segnalatele pure nei commenti, le aggiungerò a questa lista.

Articolo su BlogMagazine

Nel numero di Aprile di BlogMagazine un mio articolo sui passi necessari per la creazione di un sito.

Vi segnalo l’uscita del numero di Aprile di BlogMagazine, la rivista dei blogger, per la quale ho avuto il piacere di scrivere un articolo sul mondo del web design.

Il mio è un intervento generalista, visto il target molto vario: avevo la necessità di essere comprensibile soprattutto a chi è alle prime armi con la realizzazione di un sito internet. Dal progetto su carta alla scrittura del codice, ho voluto sfruttare lo spazio a mia disposizione per illustrare i passi necessari, fornendo una base da cui partire.

L’argomento ovviamente era troppo vasto per essere affrontato in maniera approfondita, il mio obiettivo era fornire un quadro d’insieme senza entrare troppo nei dettagli. Vi invito a leggere l’articolo e farmi sapere che ne pensate, ogni critica costruttiva è ben accetta.

Sarebbe interessante discutere anche su un altro argomento, che riguarda direttamente l’idea alla base di BlogMagazine: è meglio un insieme di interventi generalisti o una serie di articoli più specializzati? Meglio cercare di accontentare tutti o approfondire determinati argomenti, sapendo che saranno evitati da alcuni lettori? Leggendo alcuni pareri su questo numero di BlogMagazine, qualcuno lamenta la mancanza di interventi più specializzati. In ogni caso Giuliano sta facendo un buon lavoro, non è cosa da poco preparare un prodotto del genere.

Il nuovo sito del W3C

Un importante redesign per il sito del W3C, attualmente in beta.

Aggiornamento: il 13 Ottobre 2009 è stata pubblicata definitivamente la nuova versione del sito del W3C, non più in beta.

Il W3C ha da poco presentato la nuova versione del proprio sito, ancora in fase di sviluppo. Si tratta di un aggiornamento importante e doveroso, che va ben oltre il semplice restyling grafico. Potete vedere il nuovo sito all’indirizzo beta.w3.org.

La prima cosa che ho notato è il layout fluido, che continua a supportare elegantemente risoluzioni fino a 800×600. Il menu di navigazione inserito nella colonna sinistra è a larghezza fissa, mentre il resto del sito si adatta alla finestra del browser.

C’è uno slider JavaScript per le notizie in homepage e nel complesso il risultato è molto più ordinato rispetto a prima: è stato fatto anche un notevole lavoro di riorganizzazione dei contenuti. Sono cambiate inoltre le pagine della documentazione, come potete vedere nel caso delle specifiche XHTML 1.0.

Essendo una beta non mancano problemi, ma la direzione mi sembra quella giusta. Volendo cercare un difetto non sono molto convinto dell’ordine degli elementi nella pagina: il menu di sinistra appare prima del contenuto principale.

Se volete dare il vostro contributo, trovate maggiori informazioni su questa pagina. Ci sono anche alcune indicazioni per dei task da svolgere all’interno del sito, come cercare un tutorial HTML o la pagina dell’archivio news. Qualsiasi feedback inviato al W3C sarà ben accolto.