TomStardust.com » web design

Responsive Web Design, la recensione

Tom — Mon, 29 Aug 2011 06:40:46 +0000

Responsive Web Design è l’ultimo libro pubblicato da A Book Apart, la società gestita dall’onnipresente Jeffrey Zeldman. Nei mesi scorsi ho avuto modo di leggere le pubblicazioni dedicate a HTML5 e CSS3, ma questo è stato il primo testo che mi ha convinto veramente a scrivere una recensione.

Le pubblicazioni precedenti sono un pratico riassunto per chi vuole iniziare a lavorare con le ultime tecnologie nell’ambito del web design, ma questo testo offre qualcosa di più.

Qual è l’argomento del libro?

La spiegazione di tutte le tecniche necessarie alla realizzazione di siti web multipiattaforma, dal desktop al mobile passando per i tablet, senza per forza ricorrere a pagine con markup differente. Se in passato un sito web poteva essere inteso come un’entità tutto sommato ben definita e relativa ad un unico contesto (lo schermo del pc), adesso questo concetto non esiste più: i contenuti vengono visualizzati sui dispositivi più vari, dall’iPad agli smartphone di ultima generazione, che hanno risoluzioni variabili e caratteristiche diverse tra loro. I siti a larghezza fissa iniziano a diventare obsoleti, e a seconda del contesto e del proprio target potrebbe valere la pena progettare siti web che si adattano all’utente, mantenendo il pieno supporto ai browser più datati.

La prima cosa che si nota leggendo questo libro è un approccio molto pratico alla soluzione dei problemi da parte dell’autore, Ethan Marcotte. Se questo può non piacere ad alcuni, per tutti coloro che amano sperimentare e sporcarsi le mani con il codice Responsive Web Design è il testo perfetto. Solo la teoria essenziale, pochi concetti espressi in maniera molto chiara, e molti esempi con il codice in evidenza pronto per essere testato.

Contenuti

Responsive Web Design è suddiviso nei seguenti capitoli:

Our Responsive Web
The Flexible Grid
Flexible Images (estratto in inglese – estratto in italiano)
Media Queries
Becoming Responsive

Potete leggere un estratto dal terzo capitolo su A List Apart o su Italian A List Apart.

Il libro è in vendita sia in versione cartacea che digitale sul sito di A Book Apart. Se siete interessati all’argomento, volete sapere come utilizzare al meglio le media queries dei CSS3 e vi piacerebbe sapere cosa si intende quando si parla di approccio mobile first, Responsive Web Design fa al caso vostro.

Leggerlo mi ha dato molte idee, e probabilmente nei miei prossimi lavori e nella futura versione di tomstardust.com metterò in pratica molti dei suggerimenti letti.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: Responsive Web Design, la recensione

Guida all’uso di HTML5

Tom — Mon, 10 Jan 2011 07:50:19 +0000

Le sperimentazioni con HTML5 sono già iniziate da tempo, e nonostante serviranno ancora degli anni prima che la specifica diventi uno standard del W3C, si possono già trovare in rete molti esempi del suo utilizzo.

Dopo avere introdotto l’argomento su questo blog, ho approfittato di un piccolo progetto basato su Sweetcron per prepararmi e testare con mano lo stato attuale di HTML5. E’ così che è nata la nuova versione di 1la.it, lavoro che mi ha aiutato a mettere in ordine le idee per scrivere questa guida.

Doctype

La doctype di HTML5 è semplicissima:

I nuovi elementi presenti in questa specifica sono comunque numerosi, e l’argomento va esaminato con più attenzione.

Semantica e nuovi elementi

La cosa più importante da notare è che oltre ai classici div, è possibile utilizzare una serie di elementi con uno specifico significato, molto più utili per capire la struttura di una pagina:

header
footer
section
article
aside
nav

Header e footer non hanno bisogno di presentazioni, ma la cosa interessante è che possono essere utilizzati più di una volta all’interno di una pagina. L’header infatti può identificare sia la testata del sito ma anche la parte introduttiva di un articolo; stesso discorso vale per il footer, che può contenere delle note sia relative al sito che ad una specifica sezione della pagina.

Non è raro infatti trovare pagine di esempio strutturate in questa maniera:

...
   ...
   
      
         ...
         ...
         ...
      
      
         ...
         ...
         ...
      
      ...
   
...

Per quanto riguarda gli altri elementi dell’esempio, section fa da contenitore per qualsiasi sezione all’interno di un documento. Non è comunque un contenitore generico, quando c’è bisogno di aggiungere un elemento per soli scopi decorativi è sempre meglio usare il classico div.

Il tag nav deve essere utilizzato per identificare la parte della pagina contenente la navigazione: il classico menu, ma anche altri elementi che a seconda del contesto possono servire a spostarsi all’interno del sito.

Article invece è da utilizzare al posto del tag section per delle parti che possono essere astratte dal contesto e lette indipendentemente, come i post di un blog, degli articoli o un widget.

L’elemento aside invece potrebbe spesso essere utilizzato per identificare una sidebar, ma non solo. Dalle specifiche del W3C:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

Una cosa da tenere presente è che non esiste una struttura univoca per i siti in HTML5. Questi nuovi elementi vanno usati con criterio a seconda del contesto, e la struttura di un blog sarà molto probabilmente differente da quella di un classico sito o di un portfolio. Il vantaggio è che la grande varietà di tag consente di creare pagine significative dal punto di vista semantico che potranno essere consultate più facilmente anche dai visitatori: basti pensare agli utenti di screen reader per cui è essenziale la buona organizzazione del codice.

L’elemento time

Un elemento presente in HTML5 che vi troverete sicuramente ad utilizzare all’interno di temi per blog e siti di news è time. Come fa intuire il nome, può essere usato per indicare la data di un elemento article (ad esempio un post), o dell’intero documento.

La data può essere specificata in maniera esplicita o implicita:

Pubblicato il 2011-01-10

Pubblicato il 10 Gennaio 2011

Pubblicato oggi

Come potrete intuire, il problema di questo elemento è che la data va comunque espressa in modo che sia leggibile da software esterni, nel formato aaaa-mm-ggThh:mm:ss+hh:mm (potete vedere come ho strutturato le date su 1la.it).

Compatibilità cross-browser

Il motivo per cui HTML5 deve ancora iniziare ad essere utilizzato è soprattutto la sua scarsa compatibilità con i browser esistenti, soprattutto Internet Explorer (tutte le versioni precedenti alla 9). Esiste però una soluzione basata su JavaScript che consente tutt’oggi di utilizzare questa specifica senza grandi problemi: html5.js.

Questo script in pochi kb consente ad IE di riconoscere i nuovi tag senza problemi: inserendolo nella sezione head del documento con un commento condizionale risolverete tutti i problemi.

CSS Reset

Lavorando con HTML5 è fondamentale riconoscere la necessità di un CSS Reset su misura. Alcuni vecchi elementi sono deprecati (acronym, center, big…) e ce ne sono di nuovi che hanno bisogno di uno stile di base. I vari section, article, aside, sono riconosciuti dai browser più moderni ma non vengono trattati nemmeno come elementi di tipo block.

Per risolvere il problema io ho utilizzato il CSS Reset di HTML5 Doctor, derivato dal CSS Reset di Eric Meyer. Includetelo nel vostro foglio di stile e non avrete problemi.

Tag Video

Una delle novità più interessanti di HTML5 è la possibilità di usare il tag video nelle proprie pagine. Se però il browser non supporta il nuovo tag, i filmati non saranno visibili.

Video.js è la soluzione ideale per essere sicuri che tutto funzioni alla perfezione su qualsiasi browser, con un fallback in flash nel caso l’utente non sia in grado di visualizzare gli altri contenuti. Io l’ho usato per mostrare dei video provenienti da YouTube.

Possibilità di utilizzo di HTML5

Questa guida vuole essere un’introduzione al mondo di HTML5, non pretendo che sia completa. Gli argomenti da trattare sono molti, e se volete approfondire potete fare riferimento a queste risorse:

Sono tutte risorse che mi sono servite a capire meglio questo linguaggio imparandone le basi.

Anche se HTML5 è appena agli inizi e la specifica potrebbe subire dei cambiamenti nel tempo, niente vi impedirà di utilizzarlo già adesso. Se lavorate sul web vi invito a farlo prima possibile, almeno a titolo sperimentale.

Ci sono già ottimi esempi online come Nike Better World o il sito di Urustar: iniziate a guardarvi intorno alla ricerca di HTML5, i tempi sono maturi per documentarsi.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: Guida all’uso di HTML5

Raccolta di font open-source per @font-face

Tom — Wed, 15 Dec 2010 07:50:42 +0000

Utilizzare font personalizzati sui propri siti web ormai non è più un’utopia: con il supporto ormai diffuso della proprietà @font-face è possibile in pochi passi personalizzare un progetto senza dover ricorrere ai classici Arial e Georgia.

Ricordando che è comunque fondamentale preservare la leggibilità, uno dei punti critici è l’utilizzo di font protetti da copyright: non è infatti possibile pubblicarli su una pagina web se sono tutelati dal diritto d’autore. Per questo motivo le soluzioni possibili sono utilizzare servizi esterni come Typekit, oppure scegliere font open-source che non presentano alcun problema legale.

Se optate per la seconda ipotesi, questa raccolta di web font liberamente utilizzabili potrebbe tornarvi utile:

The league of Moveable Type: una collezione appena nata di font open-source disegnati in maniera specifica per l’utilizzo su web con @font-face.
Font Squirrel: una delle migliori raccolte attualmente disponibili. Sul sito sono presenti anche diversi strumenti utili per includere font nei propri progetti.
Google Font Directory: Google mette a disposizione una buona raccolta di font, che è possibile includere sui propri siti direttamente dai server di Mountain View. Sono presenti comunque anche i link per il download.
Webfonts Wiki: offre un elenco abbastanza dettagliato di font utilizzabili con vari tipi di licenze come OpenFont, GNU, CC oppure open-source.
Fonthead: una discreta collezione di font gratuiti ed a pagamento.
Ten by twenty: tutti i font gratuiti di questo sito sono espressamente utilizzabili con @font-face; quelli a pagamento no.
Dafont: una delle più ampie collezioni di font gratuiti. Potete utilizzarli con @font-face, ma fate sempre attenzione ad eventuali clausole prima del download

Come utilizzare @font-face?

Avete trovato il font che fa per voi ma non sapete come includerlo sul vostro sito? Se la semplice guida che ho pubblicato vi risulta ancora troppo complessa, troverete fantastico il @font-face generator di Font Squirrel: dovrete solo caricare il font desiderato ed avrete immediatamente un kit pronto all’uso con tutti i file necessari.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: Raccolta di font open-source per @font-face

CSS design e standard di lavoro

Tom — Wed, 17 Nov 2010 07:54:08 +0000

Uno dei siti corporate che presta più attenzione ai dettagli è quello della BBC: all’apparenza semplice ed ordinato nonostante i numerosi contenuti, si basa su molte pagine di specifiche tecniche e linee guida che devono essere rispettate dai suoi sviluppatori.

CSS – Le linee guida

Analizzando soprattutto gli standard relativi alla scrittura dei CSS, ho trovato vari spunti interessanti che potrebbero essere presi in considerazione su molti progetti:

Principi generali

Le pagine devono essere usabili e leggibili anche senza CSS
I CSS devono essere validi secondo gli standard del W3C, a meno che non sia necessario soprassedere per rispettare le linee guida interne
Se un browser non supporta determinate proprietà, deve essere messa in atto la graceful degradation (il sito continua a essere leggibile anche utilizzando software e browser obsoleti)
L’uso di !important è proibito

Uso dei file CSS

I file devono avere estensione .css ed essere tutti nella stessa directory
Le dimensioni dei CSS devono essere ridotte al minimo indispensabile
I CSS vanno inseriti usando nella sezione del documento, e @import non può essere usato
Niente stili inline

Tipografia

Deve essere sempre specificata una font-family generica come fallback (es. serif, sans-serif, monospace)
Le dimensioni del testo non devono essere specificate in px o pt, unità di misura non ridimensionabili su Internet Explorer (anche nelle ultime versioni)

Varie

Gli stili sui link vanno assegnati secondo il metodo LVHA (nell’ordine :link, :visited, :hover, :active)
Deve sempre essere specificato un colore di sfondo del body, anche se bianco
Quando viene specificato un colore per il testo, deve sempre essere indicato un colore opportuno per lo sfondo

A cosa servono le linee guida?

Sulle motivazioni tecniche dietro queste raccomandazioni c’è un’ampia spiegazione nel documento relativo, ma la questione per me è un’altra: serve davvero a qualcosa stabilire un set di regole così rigorose? Considerate che queste sono le linee guida più importanti sulla scrittura dei CSS, ma ne esistono altrettante per HTML, JavaScript, elementi audio-video, uso di cookie, design dei database, ecc.

Potrebbe sembrare una mole enorme di informazioni inutili, ma per un sito così strutturato e su cui lavorano più persone contemporaneamente non è possibile pensare a soluzioni diverse. La novità interessante, se vogliamo definirla così, è che le linee guida sono pubbliche e liberamente consultabili.

Vi è mai capitato di lavorare in progetti di grandi dimensioni? Non avere delle linee guida porta in breve tempo ad avere un codice impossibile da mantenere. Pensando in particolare ai fogli di stile diventa facilissimo scrivere regole duplicate ed aggiungere proprietà inutili.

C’è però una difficoltà da considerare: far rispettare le linee guida.

Molto spesso capita di avere documentazioni dettagliate che nessuno legge, e qui la responsabilità va suddivisa tra i singoli sviluppatori ed i loro superiori. E’ impensabile comunque che in questi casi ci sia sempre un controllore: la vera svolta si ha solamente quando tutti riescono a comprendere l’utilità di lavorare seguendo degli standard. Se per fare una minima correzione serve mezza giornata di lavoro per capire dove intervenire, significa che qualcosa non funziona.

Avete esperienze con progetti caotici da raccontare? I commenti sono a vostra disposizione.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: CSS design e standard di lavoro

User Experience: diagrammi e grafici

Tom — Thu, 16 Sep 2010 22:10:35 +0000

In passato era già capitato di discutere di User Experience: in Italia se ne parla ancora poco, ma è un aspetto fondamentale per la realizzazione di un buon progetto web.

Se siete interessati ad approfondire l’argomento, ho raccolto una serie di grafici e diagrammi da applicare soprattutto all’ambito web, tra cui la fantastica UX Wheel di Magnus Revang.

Tutti descrivono in maniera più o meno dettagliata le competenze necessarie per realizzare un sito web completo, illustrando la strada da percorrere. Non è sempre facile tenere presenti gli obiettivi finali: questi diagrammi possono essere d’aiuto anche per capire l’utilità di certe attività durante lo sviluppo.

Studi di usabilità, attenzione per l’accessibilità e per l’architettura dell’informazione: sono tutte parti fondamentali della creazione di un sito se si vuole offrire un’esperienza positiva all’utente finale.

I diagrammi

UX Wheel

Praticamente d’obbligo stamparla e tenerla sempre presente. Descrive le varie fasi creative associando i risultati a dei processi produttivi, per arrivare ad ottenere un valore finale.

UX Honeycomb

Al contrario del diagramma precedente qui non viene identificato un processo produttivo, ma un insieme di fattori che contribuiscono al raggiungimento di una user experience positiva. Non esiste infatti solo l’usabilità.

UX Treasure Map

Peter Morville ha raccolto in un unico schema molti fattori, rappresentando il tutto come un percorso da seguire per raggiungere l’obiettivo.

The Fundamentals of Experience Design

Un modello di grande impatto visivo dove vengono riunite le persone, le loro attività, ed il contesto di queste attività. Sotto le annotazioni superficiali esistono poi livelli più approfonditi: basta voler scavare.

Questi sono alcuni dei diagrammi più interessanti pubblicati anche su UX Booth qualche giorno fa. Se volete approfondire il discorso fate riferimento al post completo, dove troverete altro materiale. In aggiunta, voglio condividere anche le risorse che seguono.

The Disciplines of User Experience

Un diagramma che vuole rappresentare tutte le discipline coinvolte nel raggiungimento di una user experience positiva. Interessante la domanda che si pone l’autore nel post: cosa può essere indentificato come UX Design, escludendo le varie attività da cui è costituito (visual design, interaction design, ecc.)? E’ difficile identificare infatti l’UX Design come un’attività separata ed autonoma, a meno che ci si limiti a considerarlo come semplice coordinamento.

User Experience Diagram Rationalization

Luke Wroblewski ha riunito in un unico schema il lavoro fatto da altri esperti del settore per rappresentare gli obiettivi, i processi e le discipline coinvolte nella realizzazione di un prodotto. Tutto in una sola immagine.

Se conoscete altre risorse simili segnalatele nei commenti, sono a vostra disposizione.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: User Experience: diagrammi e grafici

Flickr redesign: la nuova pagina foto

Tom — Wed, 30 Jun 2010 06:30:13 +0000

Gli utenti abituali di Flickr se ne saranno già accorti: da qualche giorno è stata resa pubblica la nuova versione della pagina foto.

Come consuetudine la novità è stata pubblicata come preview per gli utenti, che possono decidere se mantenere la vecchia versione per qualche tempo o utilizzare la nuova: questa pratica è ormai consolidata e concede ad una buona fetta di utenti di abituarsi al cambiamento, senza imposizioni da un giorno all’altro. Le critiche non mancheranno comunque, ma sarebbe un’utopia pensare di fare felici tutti con un redesign di un’interfaccia.

Per l’elenco delle novità in dettaglio vi rimando al post ufficiale sul blog di Flickr: io preferisco soffermarmi solo su alcuni aspetti del cambiamento, e su come certi dettagli siano stati molto apprezzati dagli utenti abituali. E’ stata una sorpresa infatti leggere molti pareri positivi, cosa che non era successa con altri redesign (vedi il caso di Facebook).

I dettagli più interessanti

Foto più grandi

In un sito che ha nelle immagini la sua ragione di esistere, aumentare la dimensione di default delle stesse è una mossa vincente. Le foto iniziavano infatti ad essere troppo piccole per le risoluzioni sempre più elevate dei nuovi monitor: adesso arrivano ad una larghezza di 640 pixel, sicuramente più accettabile.

Ingrandimento con un clic

Questa è una delle novità più interessanti: molti utenti infatti inserivano nella descrizione delle foto un link alla stessa immagine più grande su sfondo nero. Sono nati anche servizi esterni per questo, e Yahoo! ha deciso di assecondare gli utenti offrendo la feature direttamente su Flickr. Adesso con un clic sull’immagine questa viene visualizzata a schermo intero su sfondo nero, e la resa è ottima:

Geotagging in evidenza

Mettere in evidenza le informazioni geografiche collegate ad una foto qualche anno fa sarebbe stata una follia. Adesso non lo è più. Con smartphone e fotocamere dotate di GPS, geolocalizzare le foto è automatico, e comunque è sempre possibile farlo anche manualmente dopo aver importato gli scatti.

Inserire questa feature al primo posto sulla sidebar destra fa capire la sua importanza. In questo modo diventa ancora più facile ritrovare tutti gli scatti di una certa località e scoprire le foto più popolari di un luogo.

I difetti

Nonostante il redesign sia positivo, alcune cose potrebbero essere ulteriormente migliorate.

Avrei apprezzato molto uno spazio dedicato ai dati EXIF delle immagini: Flickr è una community ricca di fotografi, e certe feature sarebbero sicuramente apprezzate. In questo redesign invece i metadati rimangono su una pagina separata: sarebbe stato interessante vedere almeno apertura, tempo di esposizione ed ISO.

Per quanto invece riguarda il codice e l’accessibilità delle pagine, non mi è mai piaciuta (e continua a non piacermi) l’eccessiva dipendenza da JavaScript di alcune funzioni. E’ comprensibile che certe azioni siano impossibili senza appoggiarsi a degli script, ma si potrebbe fare di meglio anche solo per quanto riguarda i menu di navigazione: con JavaScript disabilitato infatti la maggior parte dei link non funzionano ed i menu non possono essere aperti (cosa che sarebbe facile da implementare con qualche riga di CSS).

Sono invece funzionanti i nuovi link di zoom e di navigazione (foto successiva / precedente): è possibile che per alcuni nuovi elementi dell’interfaccia sia stata prestata più attenzione, ed altre parti del sito come il menu generale siano rimaste invece con i vecchi difetti. Questo redesign infatti riguarda solo la pagina foto di Flickr, tutto il resto è rimasto inalterato.

In conclusione

Il nuovo design è piacevole e più funzionale: il parere complessivo è decisamente positivo. Ci sono alcuni elementi che potrebbero essere ulteriormente migliorati, ma riguardano più la piattaforma intera di Flickr che la pagina delle singole foto. Per il momento fa piacere vedere qualcosa di nuovo in un sito che era rimasto fermo da anni: le modifiche faranno contenti i molti utenti pro che decidono ogni anno di rinnovare il proprio abbonamento.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: Flickr redesign: la nuova pagina foto

CSS @import ed i tempi di caricamento

Tom — Wed, 05 May 2010 06:40:17 +0000

I fogli di stile possono essere inclusi in una pagina web usando principalmente due metodi: link e @import. L’obiettivo di questo post è analizzare le conseguenze dell’utilizzo delle due tecniche. Il risultato in sintesi? Non usare @import per migliorare la velocità delle pagine ed evitare problemi con Internet Explorer.

Nonostante infatti possano sembrare differenti solo semanticamente, in realtà usare link o @import cambia considerevolmente i tempi di caricamento di una pagina. La scoperta è stata pubblicata qualche tempo fa sul blog di Steve Souders, un dipendente Google che si occupa di web performance e open source.

Metodi di inclusione

Link multipli

Il metodo più diffuso, che non crea problemi, è il seguente:

Guardando i tempi di caricamento, è possibile notare come i CSS vengano letti in parallelo su tutti i browser:

La prima breve barra dall’alto corrisponde al documento HTML, le altre due sono i CSS che vengono caricati simultaneamente.

Link e @import

I problemi arrivano quando insieme ad un CSS incluso con link, viene usato @import:

In questo caso, su Internet Explorer (tutte le versioni, IE8 compreso), il CSS incluso con @import viene caricato solo dopo aver completato il primo file. Questo allunga considerevolmente i tempi di caricamento della pagina:

Lo stesso succede quando il secondo foglio di stile viene importato all’interno del primo:

e all’interno di style1.css:

@import url("style2.css");

In questo caso però il caricamento in sequenza succede su tutti i browser.

@import multipli

Gli esempi mostrati dovrebbero già bastare per preferire l’inclusione dei CSS utilizzando solo link, ma c’è un altro caso interessante: quello con @import multipli.

Su tutti i browser diversi da IE, questa tecnica non presenta problemi, e funziona in maniera analoga alla prima mostrata (link multipli). I guai arrivano proprio su Explorer, dove gli elementi vengono caricati in maniera del tutto casuale, senza rispettare l’ordine dichiarato.

Prendendo infatti un esempio con i seguenti file, tra cui un JavaScript:

Il grafico risultante è questo, dove la seconda barra corrisponde al file .js:

Il file script.js viene caricato senza rispettare l’ordine dichiarato, e questo potrebbe portare a problemi di rendering della pagina. Il problema in questione si verifica su tutte le versione di Internet Explorer.

E’ bene che casi come quelli elencati siano noti, perché potrebbe essere veramente difficile indagare sui problemi di una pagina web dove gli elementi vengono caricati senza rispettare le precedenze.

In molti casi le pagine web hanno elementi più pesanti dei CSS (immagini, framework JavaScript), ma se volete ottimizzare il vostro sito tenete presente anche queste indicazioni. Non è un mistero che Google abbia iniziato a considerare anche la velocità di caricamento tra i parametri del suo algoritmo: anche il modo in cui vengono inclusi i fogli di stile è un fattore da valutare.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: CSS @import ed i tempi di caricamento

State of Web Development 2010

Tom — Wed, 28 Apr 2010 08:00:30 +0000

Sono stati pubblicati i risultati del secondo sondaggio di Web Directions, rivolto a chi lavora e sviluppa sul web. Le risposte di più di 1000 partecipanti delineano in maniera sufficientemente chiara un quadro aggiornato sulla situazione.

Tenendo presente che a rispondere non sono utenti comuni, ma superutenti, questi sono i dati più rilevanti:

Mozilla Firefox è ancora il browser più utilizzato per sviluppare, mentre Google Chrome sale al terzo posto subito dopo Safari
Internet Explorer 8 è la versione di Explorer più diffusa per la navigazione di tutti i giorni
La percentuale di sviluppatori che controllano i propri lavori su IE6 è calata dal 2008 al 2010 (da 78.44% a 59.7%)
Più della metà degli intervistati utilizza Mac OS X
JQuery è il framework JavaScript in assoluto più utilizzato, e la sua diffusione è in continuo aumento
I CSS 3 sono utilizzati anche solo sperimentalmente dal 45% degli intervistati
Mobile Safari è in assoluto il browser mobile più usato, e quello su cui vengono fatti più test in ambito mobile

Trovate i risultati del sondaggio, anche in versione pdf, sul sito ufficiale: The State of Web Development 2010.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: State of Web Development 2010

Personalizzare i font con Typekit

Tom — Fri, 16 Apr 2010 06:40:56 +0000

Da diverso tempo sto sperimentando l’uso di Typekit, un servizio che permette di utilizzare font diversi dai soliti noti (Arial, Verdana, Georgia…) in modo compatibile con tutti i principali browser. Il funzionamento è semplice e si basa su font-face e JavaScript, eliminando il problema relativo ai copyright dei font che sono interamente ospitati sui server di Typekit.

I risultati del test

Sono molto soddisfatto dei risultati ottenuti sul mio blog personale, dove sto effettuando le prove. La configurazione è semplice, e l’account trial gratuito permette di fare test senza problemi, mettendo a disposizione più di un centinaio di font (sono oltre 400 negli account a pagamento). La libreria disponibile tra l’altro cresce nel tempo, perché ne vengono progressivamente aggiunti sempre di nuovi.

Quali sono i possibili svantaggi da considerare? Sicuramente il peso della pagina, che a seconda del font scelto cambia notevolmente. Utilizzando il font Droid Serif, nelle sue forme Regular e Italic, ho una pagina che pesa ben 79kb in più del normale. Le cose potrebbero cambiare senza usare il corsivo, ma è necessario comunque fare attenzione a dettagli come questo. Il peso dei font aggiuntivi è comunque sempre visibile nel pannello di amministrazione di Typekit, non è quindi un dettaglio nascosto, da calcolare autonomamente.

Prima di scegliere un font inoltre è bene verificarne l’aspetto sui vari browser: non sempre il rendering è ottimale, soprattutto su Internet Explorer.

Questi però non sono problemi relativi a Typekit, ma fattori da considerare quando si usano font alternativi. L’unico limite del servizio, con l’account trial, è l’inserimento di un piccolo badge in basso a destra sul sito, e la banda mensile di 5Gb per i font.

Scegliere Typekit o usare i CSS?

L’alternativa CSS-only è sempre praticabile: ne avevo parlato nel 2008 quando solo Safari supportava certe proprietà e adesso potrebbe essere la soluzione ideale. Il problema però è l’esistenza di un copyright su quasi tutti i font, spesso anche quelli gratuiti, che non sempre possono essere utilizzati liberamente.

Un altro limite della soluzione autonoma è dato dalle solite differenze tra browser. Firefox supporta Web Open Font Format e TrueType, Safari e Chrome supportano solo TrueType, Explorer supporta EOT, mentre Safari Mobile (iPhone e iPad) usano SVG. Un grande caos, che obbliga lo sviluppatore a includere un font in tutti questi formati per avere risultati coerenti.

Per questo motivo soluzioni come Typekit sono l’ideale: certo, c’è da considerare una minima spesa aggiuntiva se non si vuole usare l’account gratuito con i relativi limiti, ma i vantaggi esistono.

Ci sono anche altre soluzioni alternative, come Typotheque (che concede licenze anche per la stampa) e Kernest, ma non le ho provate personalmente. Ve le segnalo se siete interessati a sperimentare, in attesa di altri servizi come Fontdeck.

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: Personalizzare i font con Typekit

A List Apart in italiano

Tom — Mon, 29 Mar 2010 06:45:42 +0000

Ho scoperto la notizia per caso, notando l’account Twitter: è appena nata la versione italiana di A List Apart, una delle voci più autorevoli sul web per i professionisti del web design. Il sito italiano ripropone da Febbraio 2010 tutti gli articoli del sito originali, traducendoli.

E’ un’ottima notizia per chi ha problemi di lingua (anche se l’inglese è ormai un must per chi vuole lavorare sul web) e per la diffusione di questo magazine, che da anni si distingue dalla massa pubblicando due lunghi articoli a settimana.

Il progetto è gestito da Valeria e Carlo Brigatti, a cui ho rivolto qualche domanda.

Ecco le risposte di Valeria:

Come è nata l’idea di Italian ALA? E’ stato complicato realizzarla?

Ho conosciuto A List Apart quando ho cominciato ad occuparmi di web design. Ho da subito trovato gli articoli pubblicati molto interessanti ed istruttivi. Circa un anno e mezzo fa, mi è venuta l’idea di creare una versione italiana del sito, che traducesse sistematicamente tutti gli articoli pubblicati da A List Apart, per offrire alle persone che si occupano di web, ma non padroneggiano l’inglese a sufficienza, la possibilità di tenersi aggiornati agevolmente. Così ho contattato Jeffrey Zeldman e ho proposto la mia idea, che è stata subito accolta con favore, ma ci è voluto più di un anno perché il team di A List Apart avesse chiara in mente la direzione che il mio progetto avrebbe dovuto prendere. Così, a gennaio sono stata ricontattata per dare il via all’operazione.

Chi siete? Cercate collaboratori?

l team di Italian A List Apart è costituito da me e da Carlo Brigatti. Carlo si occupa della gestione tecnica del sito e del suo sviluppo. Inoltre, è l’autore delle bellissime illustrazioni che accompagnano ogni articolo. Io collaboro con Carlo per la parte tecnica (più che altro fornisco direttive che vengono da lui trasformate in realtà :) ) ed eseguo le traduzioni.

Per il momento riusciamo a gestire il carico di lavoro piuttosto bene. Non percepiamo nessun compenso per il lavoro che svolgiamo, quindi preferiamo gestircelo noi fintanto che saremo in grado.

Potete comunque aiutare Italian A List Apart facendolo conoscere nel web italiano e partecipando alle discussioni degli articoli sul nostro sito. Inoltre, a breve saranno disponibili degli spazi pubblicitari che potranno essere acquistati da chi fosse interessato (Happy Cog – creatrice di A List Apart – ci autorizza a tenere i compensi derivanti dalla pubblicità sul sito).

Come mai il sito è basato su Joomla! e non su ExpressionEngine come l’originale?

Come ho già accennato, non abbiamo un budget per Italian A List Apart e per abitudine Carlo ed io lavoriamo con CMS open source e free, pertanto ci siamo orientati fin da subito verso questa scelta. Nello specifico, Carlo conosce molto bene Joomla! e pertanto si è deciso di utilizzarlo come sistema di gestione dei contenuti.

Trovate la versione italiana di A List Apart su italianalistapart.com

Vuoi fino a 15Gb gratis per il backup e la condivisione dei tuoi file? Registrati su Dropbox, usando questo link ottieni 250Mb in più!

Leggi il post originale: A List Apart in italiano