Il secondo problema da affrontare durante la costruzione di un blog (o di un sito web in generale) è la fruibilità dei contenuti. Tale concetto viene definito dalla legge 04/2004 (Legge Stanca) come “caratteristica dei servizi di rispondere a criteri di facilità e semplicità d’uso, di efficienza, di rispondenza alle esigenze dell’utente, di gradevolezza e di soddisfazione nell’uso del prodotto”.
Vengono introdotti dei termini chiari e insindacabili: rispondenza alle esigenze e gradevolezza.
Il discorso si traduce, tra le tante cose, nell’ottimizzazione delle pagine per far fronte alle possibilità d’accesso dell’utente.
Uno degli aspetti fondamentali era dunque l’individuazione degli strumenti utilizzati per accedere al mio blog. Cellulari? Palmari? NetBook? NoteBook? Display wide-screen? L’esperienza di una visita è decisamente correlata alla dimensione della pagina.
Fortunatamente i browser mobile di ultima generazione tendono a renderizzare divinamente (qui lo dico e qui lo nego) pagine grandi e interfacce come quella dell’iPhone permettono una navigazione più agevole. Questo però è vero finché si rimane in ambito mobile.
I browser dei moderni portatili, sempre più piccoli e con risoluzioni infime (ma su monitor da 7 pollici non si possono fare miracoli) non godono della stessa usabilità dei cugini mobile, così la scelta della risoluzione torna ad avere una certa importanza.
Fortunatamente non andavo alla cieca. Non dovevo realizzare un sito da zero, senza conoscere il target d’utenza e i relativi usi e costumi.
Google Analytics (o qualsiasi altro strumento di monitoraggio degno del nome) permette di conoscere la risoluzione del browser dei visitatori. Confrontando il risultato medio storico (dal 2007 ad oggi) con quello dell’ultimo periodo (gli ultimi 3 mesi), ho notato una costante diminuzione degli accessi attraverso monitor con risoluzioni pari ad 800×600 (tipica dei vecchi monitor CRT da 15 pollici). Ad oggi, tale risoluzione rappresenta appena il 4,03% degli accessi totali. La risoluzione più diffusa è quella 1024×768 (tipica dei monitor CRT da 17 pollici o degli LCD da 15 pollici) che viene utilizzata dal 39% dei visitatori. La restante porzione viene suddivisa da monitor a risoluzione maggiore.
Era dunque chiaro verso quale risoluzione dovessi concentrarmi. Scorrere orizzontalmente una pagina è qualcosa che trovo disgustoso.
Il vecchio tema (e i due precenti template) avevano una larghezza ottimizzata per risoluzioni 800×600. Personalmente non sopportavo più quella larghezza. La sentivo stretta.
Vedevo i miei post come in una camicia che fa resistenza quando viene indossata.
Nulla è ancora perso però. Non è detto che per ottimizzare una pagina ad una certa risoluzione vada necessariamente trascurata quella inferiore o viceversa. Esiste la possibilità di costruire layout fluidi in contrapposizione a quelli fissi.
La costruzione di un layout fluido prevede la possibilità di allargare o restringere le aree di testo in maniera proporzionale alle dimensioni dello schermo. Più tecnicamente, la differenza si ottiene utilizzando dimensioni in percentuale invece di fissare il numero dei pixel.
div.fisso {
height;200px;
width:50px;
}
div.fluido {
height:40%;
width:20%;
}
Le due classi fisso e fluido se associate ad un div produrranno un risultato completamente diverso. Il primo avrà un’area pari a 10.000 pixel, il secondo dipenderà (a sommi capi) dalla risoluzione del monitor (ripeto, a sommi capi, perché ci sono anche altri aspetti da considerare, primo tra tutti l’adesione o meno di un browser a certe indicazioni).
Un altro metodo è quello di sfruttare l’unità di misura em la cui base corrisponde all’altezza media di un dato carattere. Ma qui entrano in gioco i vincoli di parentela tra le varie dichiarazioni di un foglio di stile e così via.
Un terzo metodo, infine, è quello di creare dei fogli di stile ad hoc per risoluzioni/browser particolari. Questa soluzione, che può far storcere il naso ai puristi, consiste nello sfruttare delle funzioni (lato server o lato client) che individuano la risoluzione e indicano al browser quale foglio di stile utilizzare durante il rendering della pagina.
Insomma, tutto questo per dirvi che le dimensioni contano e non va progettato un sito web solamente in base alla risoluzione del proprio monitor (che magari è bello grande e ci da l’impressione di avere metri quadri di pagina da sfruttare…).
Ad esempio, a volerla dir tutta, la dimensione del box che scorre sotto l’immagine del blog mi sembra un tantino eccessiva. 🙂
Continuiamo lunedì prossimo…
Emanuele
Wow, questo post è sensazionale. Concordo sul fatto che… le dimensioni contano 😛 Ma scherzi a parte, non ho capito come questo sia stato tradotto nel tuo tema, che è a larghezza fissa. Io, per inciso, preferisco quest’ultima, perché ti da maggior controllo sull’impaginazione degli elementi, e molti mal di testa in meno quando si tratta di far funzionare tutto su tutti i browser. E’ risaputo che Internet Explorer ed i layout liquidi non sono buoni amici, anzi! Sulle statistiche d’accesso, confermo le percentuali anche sul mio blog, anche se 800×600 si attesta ancora a circa il 10% e solo da pochi mesi il 1024×768 è sceso sotto la soglia del 50% (momento in cui ho deciso di usare per default il mio layout LARGO). La soluzione che ho adottato io è un po’ più complicata (anche per l’utente che la deve attivare, probabilmente) e prevede due layout rigidi, uno adatto a chi ha lo schermo 800×600 e l’altro per i “grandi”. Un Javascript si preoccupa di verificare la tua risoluzione e suggerirti quale layout è più giusto per te, se quello attuale è troppo largo o troppo stretto. Concordo sulla dimensione del box che scorre, io farei qualcosa di meno invasivo, tipo http://www.stanford.edu (io sono un maniaco dei siti universitari eheh). Riguardo ai dispositivi mobili, con opportuni trucchi (server side), puoi tracciare anche quelli su Analytics. Comunque, ottimo intervento!
Dimenticavo, nella parte iniziali citi giustamente la Legge Stanca. Ma secondo me la bozza delle WCAG 2.0 è ancora più diretta e facile da capire, quando dice che un contenuto deve soddisfare “solo” 4 proprietà: Perceivable, Operable, Understandable, Robust. Io sono molto fissato con la seconda e la terza 🙂
Ehi, mi dispiace se rispondo solo adesso, ma questa giornata come dicevo nell’altro post è stata intensissima e il computer l’ho visto solo a pranzo per pochi attimi.
Comunque… grazie per la precisazione del WCAG 2.0, molto diretta in effetti la definizione.
Riguardo al mio tema, è a larghezza fissa, perché come te anch’io preferivo controllare l’impaginazione (sono fissato sui ritorni a capo del testo o sulla spaziatura corretta testo-immagini). Le percentuali le ho utilizzate per definire la larghezza dei vari campi della barra superiore (quella a scomparsa) perché doveva dipendere anche dal testo che inglobava.
La soluzione che hai adottato tu (javascript a parte, che avrei preferito in PHP direttamente: funziona per tutti essendo server side) mi piace ed è quella che col tempo vorrei realizzare anch’io. In realtà durante questi mesi avevo giocato con jquery e sidebar a scomparsa. Poi la soluzione non mi ha convinto anche perché l’header di quelle dimensioni obbligava ugualmente ad avere una pagina non ottimizzata per 800×600. Così ho pensato di togliere js, alleggerire tutto e magari prevedere (in futuro, con calma), l’introduzione di un CSS ad hoc.
Riguardo al box infine, il problema sono le informazioni che ho inserito. Ho tentato altre disposizioni per ottimizzare lo spazio ma non sono riuscito a trovare nulla di soddisfacente (mi piace l’equilibrio immagine a sinistra tagcloud a destra: due elementi particolari che non sbilanciano l’intero blocco verso un unico lato (nord, sud, est, ovest). Riesci a trovare la soluzione? In fondo questo mese me ne devi una! 😛
Ciao,
Emanuele
Dunque dunque, in effetti l’idea di avere un “call to action” (tanto amato negli ambienti SEO) per adattare la larghezza al proprio schermo, è stato un esperimento che mi è servito (e mi serve tutt’ora) per capire quanto la gente sia disposta a cliccare sull’avviso per leggere comodamente il blog. Al momento circa il 75% ci clicca (pensavo di più), gli altri mi sa che non ci fanno neppure caso. Comunque ad esperimento finito, passerò ad una soluzione più trasparente (ma mica si può fare solo in PHP, hai sempre bisogno di un javascript per scoprire la risoluzione del visitatore, o no?). Riguardo al box, anche io approvo l’equilibrio che gli hai dato. Forse toglierei linkblog e tagcloud, mettendoli nella sidebar. Questo accorcerebbe di molto l’altezza del box, rendendolo meno invasivo. Ricorda che l’occhio del visitatore guarda sempre a circa 1/3 dello schermo, se sposti i contenuti troppo giù, rischi di seppellirli. Just my 2 cents…
Ehm, in realtà il 75% secondo me è un risultato altissimo! Considera che cliccare comporta una scelta consapevole di ciò che si sta facendo e la frase non si trova in un popup in sovra-impressione o cose simili. Tre visitatori su quattro cliccano per navigare più comodamente!
Riguardo allo script, hai ragione. PHP lavora in server side e tutto ciò che viene a sapere del browser del visitatore è ciò che arriva tramite gli HTTP_Headers. Tra questi non c’è la risoluzione e così bisogna metter mano a Javascript. Fino a questo momento non avevo approfondito la cosa e avevo dato per scontato di poterlo prendere da li… argh, io non amo aggiungere javascript: aumenta il carico di CPU di chi riceve (infimo, lo so, ma una mollichina per volta…) con conseguente maggiore lentezza di renderizzazione. Preferisco un server veloce che fa tutto.
Riguardo alla proposta, non mi fa impazzire: ho paura che mettere quei due box nella sidebar significherebbe, come dici giustamente tu, seppellirli (non li voglio aperti di default). O credi che la gente clicchi più spesso tra i menu della sidebar che sul box superiore…?
Ciao e grazie,
Emanuele
Ciao
ho dato un po’ uno sguardo al tuo blog… davvero molto bello il template complimenti :joy: (del resto anche RX ha fatto il suo) 😛
Dovresti però correggere il feed discovery nell’head del template in quanto senza di esso il browser non può riconoscerlo automaticamente 😉
Poi una domanda: mi potresti dare il link al plugin usato per inserire il codice? Ne ho provati a decine ma non mi soddisfano molto mentre quello presente in questo post sarebbe perfetto
Ciao
Ciao omonimo, innanzitutto grazie per i complimenti! E’ vero, il lavoro di RX fa la sua porca figura… ed è proprio ciò che avevo in mente io! 🙂
Ho appena corretto l’autodiscovery, grazie per avermelo fatto notare… durante la costruzione del tema l’avevo dimenticato e non avevo notato l’assenza dell’iconcina nella barra del browser! Complimenti per l’occhio attento! 😉
Il plugin che uso io per formattare il codice è Wp-Syntax che lavora lato server (via PHP) invece di altri plugin che aggiungono del javascript alle pagine.
Ciao,
Emanuele
Eheh! … com’era? “estote semper parati” 😆 (ho un glorioso passato anche io 😛 )
Grazie per il link… mi sa che switcherò su questo perchè anche io non amo molto le soluzioni client-side via js
Saluti
Il moto degli esploratori è “estote parati”… non rimpiangi d’aver smesso? 🙂
Ehm… ma visto che hai un blog, che aspetti a farcelo conoscere?!? 🙂
Ciao,
Emanuele
[…] veloce resoconto, nelle “precedenti puntate” abbiamo parlato di layout, di scelta delle dimensioni e dei colori, abbiamo parlato del testo (dimensioni e lunghezza) e degli effetti speciali che […]