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?
Si terrà Venerdì 22 e Sabato 23 Maggio a Milano il secondo BarCamp su Wordpress.
Questo post è per segnalare che la prossima settimana ci sarà a Milano il secondo WordCamp italiano: un appuntamento da non perdere per tutti gli appassionati di WordPress.
L’anno scorso ero presente (potete leggere il resoconto in questo post), ed è stata una bella occasione per conoscere molte persone con i miei stessi interessi. Anche quest’anno non mancherò, ma ci sarò solamente nella giornata di Sabato. Qualcuno di voi ha in programma di venire?
Se volete partecipare potete registrarvi sul sito ufficiale: confermate la vostra presenza e ricordatevi di stampare il vostro badge, sarà più facile riconoscersi.
Chi invece resterà a casa potrà sicuramente leggere ampi resoconti nei giorni successivi all’evento, anche su questo blog. Per gli aggiornamenti in tempo reale invece Twitter rimane lo strumento migliore: potete seguire il mio account, e probabilmente riuscirete anche a trovare dei risultati di ricerca aggiornati con l’hashtag #wordcamp.
Una riflessione sul nuovo lettore di e-book di Amazon: Apple potrebbe entrare in questo mercato.
Aggiornamento: cerchi informazioni sull’iPad Apple? Trovi tutte le informazioni ed una prova approfondita in questo articolo: iPad, la recensione.
Il settore degli e-book reader si sta facendo strada, soprattutto in America dove regna incontrastato Kindle di Amazon. Notizia di questi giorni è il lancio del nuovo Kindle DX, lettore di e-book dal grande schermo (9,7″), che mantiene l’ottima leggibilità ed autonomia del suo predecessore per un prezzo più alto: 490$ (circa 370€, più le solite tasse).
Un prezzo del genere è ancora troppo elevato, ma è lecito riconoscere come questi supporti si stiano avviando verso la strada giusta. Ovviamente ci sono ancora dei difetti di gioventù, ma è il prezzo da pagare per uno strumento totalmente nuovo, che deve ancora trovare la sua giusta collocazione.
Trovo che un e-book reader possa essere comodissimo in alcune circostanze, come nella consultazione dei manuali di D&D in .pdf durante una partita. Parlo per esperienza personale: invece di doversi districare tra almeno 2-3 tomi di centinaia di pagine dal peso non indifferente, sarebbe fantastico avere tutto in 10 pollici. Lo stesso discorso vale per la didattica. Sono invece ancora scettico per la lettura di interi romanzi, che costano ancora troppo in formato digitale, e soprattutto non potrei fare a meno della sensazione della carta e del profumo di un libro appena acquistato.
In questo contesto, riconoscendo l’impresa di Amazon che sta aprendo la strada, la mancanza più grave del Kindle DX è il display touchscreen. Il gesto più intuitivo che possa esistere su un e-book reader è lo sfogliare pagina, e non posso pensare modo migliore di implementarlo di una gesture stile iPhone, scorrendo le dita da destra a sinistra dello schermo. Mi stavo già rassegnando a considerarla come una fantasia, quando ho trovato diverse voci a supporto di una nuova idea: un lettore di e-book made in Apple.
Il possibile rivale: Apple Media Pad
I primi indizi risalgono a Marzo 2009: da Gizmodo ad Appleinsider, molti hanno riportato una notizia della Reuters che parlava di un ordine Apple per numerosi display da 10 pollici. Tutti hanno iniziato a pensare ad un futuro netbook, la moda del momento.
Ma se un display del genere, curiosamente delle stesse dimensioni del Kindle DX, servisse per un e-book reader, magari con touchscreen?
Ed ecco la novità: pochi giorni fa qualcuno ha iniziato a parlare di un fantomatico Apple Media Pad per entrare nel settore di mercato dominato da Kindle. Tralasciando l’ipotetico nome di fantasia, è una teoria più valida di quello che potrebbe sembrare a prima vista. La Apple ha a disposizione la tecnologia per un ottimo touchscreen (vedi iPhone e iPod Touch): implementata su uno strumento con finalità diverse dall’iPhone potrebbe fare realmente la differenza.
Questo giustificherebbe anche le continue smentite di un futuro Netbook made in Apple: non è quello il mercato che interessa all’azienda di Cupertino.
La questione però non è così semplice, perchè c’è un’intervista di Steve Jobs al New York Times di qualche mese fa, dove viene messa in discussione l’utilità di Kindle:
It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore. Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.
E’ possibile quindi immaginare un prodotto Apple con più funzioni, schermo a colori ed obiettivi diversi rispetto al Kindle, come il gaming. In questo modo si avrebbero oggetti differenti per mercati diversi: solo quello di Amazon sarebbe un e-book reader, mentre la Apple andrebbe ad occupare altri settori, dando comunque agli utenti la possibilità di leggere documenti su un supporto portatile dal grande display.
Resta da attendere l’evoluzione della vicenda: oggetti di questo genere avranno comunque bisogno di tempo per affermarsi e migliorare le loro caratteristiche. Considerando che stiamo parlando di un mercato nato da poco, anche il prezzo iniziale sarà elevato. Il futuro si rivela comunque interessante, anche se i fan dei romanzi cartacei possono stare tranquilli: sicuramente non spariranno in fretta.
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:
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.
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.
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.
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:
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.
Terzo compleanno per questo sito, occasione giusta per dare uno sguardo ai traguardi raggiunti.
Oggi questo sito raggiunge i tre anni di vita, sicuramente un bel traguardo per un progetto partito dal nulla. Ormai è diventata una consuetudine fare il punto della situazione, e guardando i numeri degli anni scorsi non posso che essere contento dei risultati raggiunti.
Rileggendo alcuni vecchi articoli mi sono reso conto di come siano cambiate molte cose: basta fare un confronto con i numeri del primo e del secondo anno per essere soddisfatto:
Solo lo spam in questo terzo anno è andato in controtendenza: strano ma vero, i commenti bloccati da Akismet sono stati “solo” 10.000, l’anno scorso erano 22.000.
Inoltre siete diventati veramente tanti a leggere il feed RSS; i commenti continuano ad essere una delle parti fondamentali di questo blog: la forza di TomStardust.com è anche nei vostri interventi e nelle conversazioni che nascono. Una delle cose che dà più soddisfazione è essere seguito anche se i post non sono così frequenti come in altri blog: sono sempre convinto che sia la qualità a fare la differenza, e continuerò a fare del mio meglio per fornire contenuti interessanti ed approfondimenti.
Non posso poi fare a meno di citare la pubblicazione del nuovo tema WordPress, Exciter, che per il momento è stato scaricato un centinaio di volte nella versione italiana, e 780 in quella inglese. Non sono i numeri di Stardust, che continuano a sorprendermi, ma è un discreto risultato.
Gli articoli più letti del terzo anno
Per chi avesse voglia di scoprire gli articoli più letti di questo terzo anno, ecco una selezione:
Guida Boot Camp: installazione di Windows su Mac OS X – in assoluto il post più letto e commentato di TomStardust.com. Da Maggio 2008 ha superato i 200 commenti e le 36.000 visualizzazioni: ma non vi preoccupate, non mi metterò a scrivere guide simili così spesso :)
L’accessibilità per i daltonici – dal daltonismo agli altri disturbi della percezione dei colori: consigli e link utili per realizzare un sito accessibile
In questi giorni avrete notato alcuni cambiamenti al layout: continuerò a lavorare sul template anche in futuro. Il mio obiettivo è sopratutto migliorare l’usabilità e l’accessibilità del sito: il primo passo è stato riordinare il codice delle pagine logicamente, con i contenuti prima di tutto il resto. Ogni consiglio è benvenuto, contattatemi senza problemi se avete dei suggerimenti!
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.
Questo post è per segnalare che la prossima settimana ci sarà a Milano 
Vi segnalo l’uscita del numero di Aprile di