In questo articolo vi mostro come pianificare un sito per adatto alla navigazione su qualsiasi cellulare. Per lo meno in teoria, visto che ogni modello ha le sue piccole differenze e dovreste sempre aggiustare qualcosa, ma questo è proprio il punto: creare un mobile site che sia ottimo su ogni telefono e fantastico sull’iphone.

perchè un sito per la telefonia mobile?

Così come alcuni anni fà tutti si sono resi conto che avere una presenza sul web era importante per il proprio business, oggi sta diventando chiaro che rivolgersi all’audience telefonica è obbligatorio.
Ci sono più di 3 miliardi di cellulari nel mondo, 4 volte il numero dei PCs. Il numero sta crescendo, ma ancora più importante, i telefoni vecchi vengono periodicamente sostituiti con nuovi, il che significa sempre più dispositivi con l’accesso ad internet.
source:BuxUk
I normali siti web sono visualizzati decentemente sugli ultimi dispositivi che dispongono di web browsers simili alle versioni per desktop, ma diventano comunque un incubo in usabilità. Su telefoni più vecchi invece non sono proprio visualizzati.
Fidatevi, un sito specifico per i telefoni cellulari non è uno spreco di tempo.

con cosa abbiamo a che fare

Quando inizialmente i cellulari hanno integrato la tecnologia per accedere ad internet usavano un vecchio sistema di web standards chiamato WAP, che comprendeva il suo linguaggio WML e il protocollo per distribuirlo (WTL, WYPS). WML è basato su XML ed è largamente adottato e sebbene sia superato non è stato deprecato, quindi poteteconsidereare di creare una versione del vostro sito anche con questo markup come “safe mode” per i cellulari più vecchi. L’evoluzione del wap è WAP 2.0 che ha adottato XHTML-BASIC/MP e il famoso protocollo TXP/IP HTTP per la comunicazione. xhtml-mp è molto simile all’ xhtml e viene interpretato dai browser nello stosso modo, ha solamente alcune caratteristiche in più utili ai dispositivi cellulari.
La prima versione del Wap non aveva stili, ma Wap 2.0 ha introdotto i Wireless CSS (WCSS) che sono una versione di CSS 2.1 per integrare gli stili ad xhtml-mp. è simile alla cersione dei fogli di stile css 2.1 ma ha meno attributi e per essere sicuri che funzioni trasversalmente su tutti i browsers è meglio che vi manteniate su cose semplici. Non funzione col Wap 1.0
Oggi molti telefoni come l’iPhone, Android, etc. che hanno lo stesso browser che sui desktops accettano lo stesso mark-up che usate per i siti web. Eccovi un paio di link a una guida sull’xhtml-mp e una sui wcss.

come iniziare

Cosa abbiamo imparato da questo stralcio di storia?
Che non è difficile creare un sito che funzioni su tutti i telefoni con un po’ di tecniche simili al progressive enhancement. Il mio miglior suggerimento è di scrivere il sito in XTML-MP e poi usare diversi fogli di stile. Il WML è in più, dovreste controllare i dati della vostra audience per esserne certi, ,ma generalmente se le persone hanno un telefono talmente vecchio non lo usano per navigare ora che ci sono alternative.
Prima che vi mostri qualsiasi codice consideriamo un po’ di lavoro con carta e penna.

i. web strategy

Perchè vi serve un mobile site? Potete veramente offrire qualcosa di utile a chi usa il cellulare? Offrite un servizio specifico? Aiutate a compiere qualcosa?
Non fraintendetemi, non si basa tutto sull’utilità, non è necessario che creiate un’applicazione per l’iPhone per avere una presenza nel mobile web, internet è anche intrattenimento. Pensate a chi in un bar decide di navigare il vostro blog per passare il tempo. Quello che intendo dire è che dovreste sbarazzarvi di tutto quello che non è utile e specifico per questo mezzo. Molte grafiche e pagine di foto sono una brutta scelta.
Pensate agli obbiettivi del vostro business, perchè è importante per voi essere sui cellulari. Pensate agli obbiettivi dei visitatori, come beneficeranno dal vostro sito? Considerate la tecnologia disponibile e i suoi limiti.
Siccome questo è anche lo stadio in cui si pongono le basi per la pianificazione dell’interaction design, è un buon momento per fare ricerca e capire qual’è la vostra auddience. Vi aiuterà sapere in che circostanze useranno il sito e … molto importante, che tipo di telefono useranno.
Un ultima domanda: pensate di creare un sito apposito o volete semplicemente adattare quello esistente per la visualizzazione su mobile?

ii information architecture:

Semplicità! evitate lunghe catene di pagine, pensate ad “investimenti in click” perchè anche con connessione 3G serve sempre molto tempo per caricare una pagina quindi la pazienza dei visitatori da cellulare è piuttosto corta. Tagliate tutto quello che non è rilevante e usate categorie ben specificate: se il visitatore sa cosa sta aspettando è più probabile che attenda il caricamento. In pratica limitate le scelte e le categorie, non lasciate che il visitatore si perda in un labirinto. Mantenete il minor numero di livelli possibile. Potrebbe esservi d’aiuto creare un “click stream” per visualizzare come vengono navigati i contenuti.

iii. mobile web design:

Ci sono molte cose da tenere in mente realizzando un sito per mobile. Prima di tutto la dimensione degli schermi varia molto ma quello che più c’interessa è la larghezza, quindi il mio consiglio è i creare un layout fluido. Usate percentuali invece dei pixels per le dimensioni. Potete saperne di più su AListApart.Un layout liquido vi aiuta anche sull’iPhone e altri dispositivi con lo schermo orientabile. Comunque, per i cellulari della vecchia generazione che hanno solo l’opzione del layout “portait” è importante cercare di strutturare i contenuti a dovere, per esempio come distribuire le informazioni e tagliare il testo in blocchi più piccoli per aiutarne la leggibilità.

La Navigazione è un altro aspetto che andrebbe riconsiderato.
Anche nei telefoni multi-touch è un po’ impacciata, figuratevi in quelli più vecchi dove si usa il pad.
Una buona idea è usare liste, sempre, e limitare i link ad un massimo di 10, magari aggiungendogli anche degli accesskey (questi ultimi non vi serviranno sui telefoni multi-touch).
Evitate menu a più livelli perchè su piccoli schermi non sarebbero mostrati correttamente.
Mettete Links d’uscita per la home, la sezione precedente e successiva, alla fine di ogni pagina in modi che il visitatore non debba scrollare fino in cima.

Risorse e banda di connessione sono 2 dei maggiori limiti dei telefoni cellulari. Evitate object e javascript quando possibile perchè non sono supportati sui primi telefoni, ma anche ora che lo sono prosciugano la batteria.

Limitate anche l’uso di immagini perchè aggiungono peso alla pagina, inoltre dovete considerare quale sarebbe la dimesione ideale. Se volete andare sul sicuro mantenetevi sulla grandezza minima di 120px in larghezza. Un’altra opzione è usare la grandezza dello schermo più grande che vi aspettate visiterà il sito (diciamo un iPhone orientato a landscape di 480px?) e poi applicate questa tecnica per adattarle allo schermo come il vostro layout liquido. Ovviamente non è la “miglior pratica” siccome al browser toccherebbe comunque scaricare la versione più grande. Il modo corretto di ridimensionare le immagini è farlo su lato server e specificarne la grandezza.
Quando potete usate sempre sprites images (se non sapete a cosa mi riferisco leggete questo articolo su ALA). Come al solito non dimenticate “alt text” nel caso l’immagine non carichi.

Ho nominato il peso della pagina, il mio consiglio è di restare tra i 10kb e i 25kb. Mi riferisco ai telefoni di base, per gli smartphones va bene anche 50kb e per i touch-phones anche 100kb, ma è meglio andare sul sicuro visto che oltretutto dipende sempre dalla qualità della connessione.

Caching è un altro fattore che vi aiuta con la velocità di caricamento, cercate di evitare che le risorse comuni siano sempre scaricate e inserite una stringa per controllare la cache.

Interessante: Safari sull’iPhone registra nella cach solo file di dimensioni minori di 25kb, quindi zippate i vostri fogli esterni come i css e cercate dirimanere in quel limite con le vostre immagini sprites.

Quando applicate gli stili ai font è meglio non specificare la grandezza in pixels, casomai in em o percentuali, ma l’ideale è usare “small/normal/large” perchè ogni dispositivo sa cos’è adatto per sè.

Parliamo dei links: sui telefoni cellulari non c’è il mouse, quindi niente hovering, dimenticate l’attributo hover. Una cosa divertente invece è che se usate “tel:” e “sms:” nei link potete attivare quelle funzioni nel telefono, quindi è utile nella pagina dei contatti aggiungere link che se cliccati lanciano direttamente la chiamata o la messaggistica. Ecco un esempio:

call us
Send SMS to 1(212)555-1212


Entrando un po’ più nel tecnico la prima regola perchè il vostro sito venga visualizzato correttamente sui telefoni è aggiungere il giust Doctype (xhtml-mp), codice di caratteri (utf-8), e il MIME Type (application/html+xml).


"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">



Per quello che concerne la struttura del body cercate di costruire semanticamente (nell’ordine in cui le cose appaiono) ed evitate tabelle e frames. é sempre meglio validare il vostro codice, limitare l’uso di risorse esterne e per favore, non usate popups.

rilevare e rivolgersi a telefoni specifici

Ok, quello che vi ho detto fino ad ora era applicabile ad ogni telefono, ma forse volete aggiungere qualcosa di speciale o concentrarvi su alcuni modelli specifici.
Come potete riconoscere un modello e adattare i contenuti appositamente? Innanzi tutto vi ricordate cosa vi ho chiesto durante la pianificazione: voleter costruire un sito per mobile o adattare il sito web ad essere visualizzato sui cellulari? Se avete deciso di fare tutto quello che vi ho suggerito nel tutorial ne deduco che vogliate creare un sito da zero (bravi ragazzi) ma se per qualsiasi ragione volete solo adattarne uno, il modo migliore è tramite i CSS. Aggiungete un foglio di stile separato per i cellulari.

potete anche aggiungere stili specifici all’interno di un unico foglio css:

@media handheld {#image1 {display: none}}



@media only screen and (max-device-width: 480px) {}


Nel caso vogliate essere più specifici nella personalizzazione avrete bisogno di spare ch modelli di cellulari visitano il vostro sito. Potete identificarli tramite le informazioni che ogni dispositivo include nel proprio http header, lo “user agent. Online ci sono alcuni databases che contengono tutte le informazioni relative ad ogni modello. Per esempio potete usare il WURFL database, oltre ad essere un progetto opensource condivide un API che potete usare nel vostro codice server-side per adattare i contenuti del sito e la loro presentazione a specifici user agents. Un altro database è quello di DeviceAtlas che oltre all’API offre vari tutorials, come questo per includerlo nel vostro codice php.

iphone

Sì, so che c’è molta agitazione attorno all’iPhone e non l’ho dimenticato. Ecco alcuni consigli specifici per questo telefono.
Una buona pratica è mantenere la user experience simile a quella generale dell’iPhone anche attraverso il sito. Questo non significa sacrificare l’originalità. Quello che intendo è piuttosto usare liste per i menu e bottoni molto grandi per poter essere premuti comodamente, questo è un touch-phone. Visto che usa Safari 4 potete usare xhtml e css. La parte divertente è proprio la potenzialità di sfruttare le nuove regole CSS3 che non potete usare sugli altri telefoni. La più comoda e usata ovviamente sono i bordi arrotondati:

div {
color: #bcbcbc;
padding: .5em;
-webkit-border-radius: 6px;
-moz-border-radius: 6px;
-khtml-border-radius: 6px;
border-radius: 6px;
}


Iniziate aggiungendo il viewport all’interno dell’ in modo che la pagina si adatti perfettamente allo schermo:




Il secondo passo è nascondere la barra degli indirizzi visto che abbiamo già così poco spazio. Ci basta una riga di javascript:

window.scrollTo(0, 1);


Create una icona springboard, una specie di enorme favicon per rendere riconoscibile il vostro sito se viene aggiunto ai segnalibri dell’homescreen. Dev’essere di 57×57 px e dovete inserire nell’

Qualcosa che penso potrebbe esservi molto utile è una funzione che una volta rilevato che un iPhone sta visitando il vostro sito web apre una finestrella per chiedere se si preferisce passare alla versione mobile del sito. su iphonemicrosites.com un breve tutorial
Come alternativa, se pensate che questo metodo sia troppo invasivo, potete semplicemente aggiungere dinamicamente sulla pagina un messaggio che avvisa il visitatore della possibilità di passare al sito per iPhone. Un altro tutorial sempre allo stesso indirizzo.

Visti questi primi passi direi che il resto lo lascio alla vostra creatività. Ricordatevi di usare grandi “target areas” nei vostri link e buttons per aiutare i pollicioni, bisogna riuscire a cliccare una cosa alla volta comodamente. Usate liste per menu e links, usate colonne per il testo e dividetelo in paragrafi corti.
A dir il vero tutto quanto detto nella prima parte del tutorial si applica anche su questo telefono, con la differenza che qui potete spingere le prestazioni oltre. Leggete la guida ufficiale di Safari per il web per imparare le tecniche migliori ed i limiti relativi all’iPhone. è breve ed aiuta molto.

Se vi serve un po’ d’aiuto nella creazione delle interfacce potete usare frameworks e strumenti di sviluppo apposta per questo handset. Date un’occhiata a queste risorse:Dashcode
iUI
Yahoo stencils

testing

Per testare il vostro sito la cosa ideale è provarlo sui telefoni veri e propri, ma nel caso non possiate ci sono alcuni strumenti per questo. Per l’iPhone è meglio lavorare sull’SDK offerta dalla Apple se siete su Mac. Se invece lavorate su Windows potete provare il sito con MobiOne, un emulatore molto carino che io stesso uso.
Per altri telefoni dovreste controllare se sono disponibili gli emulatori appositi. Altrimenti dotMobi offre Mobiready un validatore molto comodo che vi mostra come viene visualizzato il sito su alcune classi di dispositivi e che risultati ha in termini di tempi di caricamento, peso, costi, etc.
Però il sito dev’essere online.
Se avete Firefox potete installare l’add-on User Agent Switcher per simulare all’interno del browser come il sito viene visualizzato da altri user agents.

wordpress

Nel caso abbiate un blog costruito su wordpress e vogliate che appaia decentemente sui cellulari ho trovato un paio di plugins interessanti:
iWphone è pensato per l’iphone e praticamente aggiunge un theme che si adatta al dispositivo;
il dotMobi Wordpress Mobile Pack invece è più complesso e completo, converte completamente il sito validandolo per il linguaggio xhtml-mp, aggiungendo temi specifici, integrandolo col database di DeviceAtlas, e così via.

risorse

C’è il solito elenco delle mie fonti nel menu dopo l’articolo, ma ritenevo importante sottolineare alcune risorse in particolare che ho trovato più indispensabili che utili:
la web developers guide di MobiForge che contiene tutto quello che vi serve sapere;
un’altra guida per creare mobile sites, più sintetica e con tanti bei disegnini;
L’intero sito MobiForge, il miglior posto per iniziare;
su iphonemicrosites.com potete trovare alcuni tutorials molto utili per i siti da visualizzare sull’iphone;
Restando sull’oggettino Apple, leggete su Nettuts i 10 consigli di Paolo Ranoso o l’articolo approfondito su Webdesignerdepot

content strategy

Internet è contenuti. davvero.
La gente si connette per trovare informazioni, per fare qualcosa, per risolvere un problema. Comunque la metti stanno cercando dei contenuti. Sembra ovvio quindi che sia l’elemento più importante di un sito, eppure di solito, durante il processo creativo è l’ultima cosa di cui ci preoccupiamo. perchè? beh, spesso pensiamo che sia il lavoro di qualcun’altro o che useremo quello che ha preparato l’ufficio marketing o che bene o male sappiamo cosa dovremo scrivere. Non c’è problema.
Sbagliato.
Vi spiegherò tra un attimo perchè è così importante, ma prima cerchiamo di capire cosa significa esattamente content strategy. Cercate anche di ricordare che quando parlo di contenuti non mi riferisco solo ai testi, ma anche a video, audio, immagini, etc.

cosa comprende la content strategy?

Citando Kristina Halvorson, un vero guru di questa disciplina, “content strategy pianifica per la creazione, pubblicazione e gestione di contenuti utili ed usabili.
Content strategy ti aiuta a capire non solo cosa bisogna creare, ma anche perchè.”

Comprende diversi aspetti:

Ok, non molto dettagliato, ma dovrebbe darvi un idea generale di quali sono le funzioni e le competenze di un content strategist.

ok, ma perchè?

Sì vabbè, ma ancora non ho capito perchè è così importante e dovrei ammazzarmi di lavoro per questo.
Ecco alcune buone ragioni:

- SEO: non negarlo, è una parola inflazionata ma ti interessa. Non ho trucchetti magici, ma puoi aggiustare e organizzare i tuoi contenuti in modo che siano più efficaci per i motori di ricerca. Devi ad esempio inserire alcune parole chiave senza compromettere la qualità del testo. è molto utile per attirare un’audience specifica sul proprio sito, che significa aumentare le conversioni nel caso abbiate pubblicità per un certo target e riuscite ad attirarlo.

- Design: ti sei mai chiesto perchè le belle template che si presentano ai clienti non sono poi mai identiche alla versione finale in produzione? Probabilmente perchè si usano place-holders e Lorem Ipsum con un’idea solo generale di quello che sarà sul sito. Se hai già dall’inizio i veri contenuti a disposizione non rischi di rompere all’ultimo momento la perfetta user experience che avevi pianificato. Un’altra ragione per preparare i contenuti prima di iniziare è che il design serve a comunicare qualcosa proprio in base ai contenuti e al Brand. Se non sai per cosa stai creando, non potrai realizzare qualcosa che aiuti i contenuti e lo spirito del brand. (e non nominare mai Lorem Ipsum ai content strategists, perdono letteralmente la ragione. Se per sbaglio ti capita..corri.)

- Usablity: sì, amo questa parola. E i contenuti hanno un ruolo importante. Cerco di dire che è fondamentale avere un’interfaccia chiara con una navigazione semplice e così via, ma alla fin fine, se i contenuti falliscono nel tentativo di essere utili e leggibili avete solo sprecato le vostre forze.

- Persuasione: ammettiamolo, oggi tutti sono editori e tu devi riuscire a cogliere l’attenzione del lettore. Vuoi comunicare qualcosa e se fai anche breccia non è male.

- Brand: “buoni contenuti aggiungono lustro al brand”, dice Colleen Jones.

Bene, ora abbiamo un’idea di cosa sono i contenuti e perchè ci serve della strategia.

teach me, baby

Cominciamo a parlare dei fatti: come posso mettere in pratica questi concetti? Karen McGrane è una specie di divinità nello spiegarlo, quindi assicuratevi di leggere le slide alla fine del capitolo. Io cercher di riassumere i passi più importanti.

Lei usa un modello molto efficace per visualizzare il processo necessario alla pianificazione di un sito dal punto di vista del content strategist.

Prima ho detto che dovresti fare, e tenere aggiornato, un inventario dei contenuti. è proprio quello che sembra, un elenco di tutti i contenuti presenti sul sito. Di solito un foglio d’Excel. Sarah Rice ha condiviso un suo modello qui altrimenti Jeffrey Veen ha un altro esempio qui. All’inizio di un progetto è utile sapere con cosa si lavorerà. Elenca i contenuti e cerca di categorizzarli per tono, accuratezza, coerenza, rilevanza, e così via. Aiuta gli information architects che in questo modo sanno cosa effettivamente è possibile oppure no nelle loro pianificazioni. E ovviamente aiuta chi hai assunto per scrivere che non può fare le cose a caso ma deve sapere dove c’è bisogno del suo aiuto.
Per una guida più pratica controllate il link di Veen che vi ho dato sopra, entra nei dettagli del processo ottimale.

quality content

Il processo per una content strategy che abbiamo visto fino ad ora è ottimo, ma possiamo anche approfondirlo da un’altra prospettiva: come creo dei contenuti di qualità?
Colleen Jones ha scritto un articolo su UXmatter su questo argomento, vediamo se riesco a stringerlo un po’ qui per voi.
Per assicurare la qualità dei contenuti una style guide non è abbastanza perchè di solito si preoccupa solo della scelta delle parole e del tono del brand. Dobbiamo invece usare alcune euristiche.

Queste sono alcune delle guide linea, ma ciò non toglie che dovreste sentire l’opinione di un esperto, dovreste fare i soliti usability test e controllare il feedback degli utenti. Inoltre usate sempre un inventario dei contenuti e fate un’analisi.

analisi dei contenuti

Considerando che adesso abbiate un’idea generale del processo per una content strategy e che magari abbiate già fatto il vostro inventario dei contenuti, dovreste controllare se ci sono problemi significativi tramite queste euristiche d’analisi che Fred Leise ha elencato in un articolo su BoxesAndArrows.

C’è così tanto da dire su quest’argomento, ma non ne ho lo spazio. Controllate le fonti che ho elencato sotto nella solita sezione “fonti”, ma vi consiglio anche di partire dal blog di BrainTraffic, gestito da Kristina Halvorson, che ha tonnellate di consigli pratici sulla content strategy. Karen McGrane, Margot Bloomstein, e Jeffrey MacIntyre che gestisce Predicate,LLC sono gli altri nomi da seguire in questo campo se volete impararne di più. Kristina Halvorson ha appena pubblicatoWeb Content Strategy, ovviamente una lettura fondamentale. Io vedrò di procurarmi presto la mia copia.
Per finire, il Knol sulla Content Strategy è un ottimo punto di partenza per trovare tutto quello legato all’argomento su internet.

Spero abbiate apprezzato l’articolo e nel caso condividetelo così diffondiamo un po’ la parola Se avete delle domande cercherò di rispondere nei commenti, altrimenti potete raggiungermi su twitter.

foto: © Lars Williem Veldkampf (photostream)

Introduzione ai webfonts:

Quando riguarda il web design la tipografia è sempre un argomento difficile. Da sempre i designers sono stati costretti ad usare i cosidetti web-safe fonts.
Quando specifichiamo i typefaces nella proprietà font-family del nostro foglio di stile stiamo dicendo al browser di usare quel font per tradurre l’aspetto del testo html a cui si rifersce la proprietà. Siccome i vari sistemi operativi hanno font installati di base diversi, noi, come designers, eravamo obbligati ad usare quelli più comuni che erano installati sulla maggior parte dei computer (ricordatevi che il browser cerca il font sulla macchina del visitatore).
Questo è anche il motivo per cui definiamo “stack” (gruppi) di fonts in font-family e non solo il nostro preferito: cerchiamo di assicurarci che se il primo font non è disponibile sul computer del visitatore venga allora caricato il prossimo.

Questo articolo di David Rodriguez spiega in dettaglio i web-safe fonts e come usarli. Se volete migliorare i vostri stacks e provare nuove soluzioni sempre nei limiti dei web-safe fonts vi consiglio di scaricare il file pdf da Unit Interactive, è diventato il mio riferimento da quando l’ho letto.

Ovviamente potete obbiettare che avete visto su molti siti fonts diversi dai soliti Verdana o Georgia (per citarne un paio). Questo perchè esistono altre tecniche come sIFR3, cufòn e la sostituzione con immagini, per non usare i font comuni, ma implicano l’uso di flash, javascript o immagini con conseguenti svantaggi. Perciò di solito sono usati solo per i titoli.

i. alternative

Oggi qualcosa sembra stia cambiando e tutti gli amanti della tipografia del mondo si stanno eccitando (ho esagerato?).
Sto parlando di @font-face, la nuova regola CSS che permette di includere (”embed” se il termine vi ricorda qualcosa) font nel vostro sito.
Vi darò un piccolo tutorial su come usarlo efficacemente a breve, ma prima vediamo com’è la situazione odierna rispetto alla disponibilità dei font.

ii. webfonts proposals

ILoveTypography ha un bell’articolo completo sulla questione che cercherò di riassumere ora.
Microsoft nel 1997 ha sviluppato il suo formato Embeddable Open Type (.eot) di font che era poi supportato da IE4. Inviarono la proposta di ammissione al W3C, ma fu rifiutata prevalentemente per ragioni di sicurezza.

Ora Tal Leming e Erik Van Blokland propongono un nuovo formato, .webfont, che consisterebbe in 2 file: uno sarebbe il font grezzo (es. TTF o OTF) e uno un info.xml che conterrebbe i permessi per usare quel font. Il browser leggerebbe il file .xml e deciderebbe se caricare o meno il font.
Potete leggere meglio come funziona su ChezPorchez.

David Berlow di Font Bureau propone invece “permission teble of Opentype”, un sistema per inserire i permessi d’utilizzo direttamente nel font (rimandendo dunque con un solo file) e usando un file già pronto ad essere incluso perchè .otf
Una critica mossa a questi metodi è che sarebbe facile modificare i file xml per aggiungere i propri dati ai permessi d’utilizzo anche senza avere una licenza.
Nel frattempo Ascender ha lavorato per evolvere il formato EOT di Microsoft in uno di uso più facile: EOT Lite.

Tra le notizie dell’ultimo momento, gli sforzi di Leming e Blokland si sono uniti a quelli di Jonathan Kew (Microsoft Corporation) per dar vita al formato WOFF , un unicofont file compresso contente anche meta-datas e private-use data. Ecco un estratto dal testo della bozza originale:

The WOFF format is directly based on the table-based sfnt structure used in TrueType[1], OpenType[2] and Open Font Format[3] fonts, which are collectively referred to as sfnt-based fonts. A WOFF font file is simply a repackaged version of a sfnt-based font in compressed form. The format also allows font metadata and private-use data to be included separately from the font data. WOFF encoding tools convert an existing sfnt-based font into a WOFF formatted file, and user agents restore the original sfnt-based font data for use with a webpage.

A quanto pare non ci sono ancora programmi per convertire i file, ma è comunque un passo avanti verso una soluzione. Il documento ufficiale è qui.

Ad ogni modo il problema di tutte queste soluzioni è che devono essere accettate dal W3C per poter essere adottate in futuro, ma il W3C inizierà a lavorare su una proposta solo sapendo che è supportata dalla maggioranza delle typefoundries e non c’è una vera e propria industria “type industry” — almeno rappresentata ufficialmente — quindi le decisioni sono piusstosto individuali e rallentano le cose. Inoltre poi il formato dovrebbe essere supportato dai browsers.

iii. soluzioni dei distributori

Qualcuno sta già supportando @font-face vendendo font con licenze che permettono l’inclusione nei siti.
Uno è Typekit che affittano i font invece di vendere completamente la licenza.
Scegli su che dominio la userai e paghi mensilmente. In cambio ottieni un codice javascript che include il font ospitato su un server.
Typotheque sta facendo una cosa molto simile, vendendo licenze (per dominio e non mensilmente sembrerebbe) e ospitando il font su un cloud server. Invece del javascript mandano un codice css da aggiungere al proprio sito. Spiegano che quando si scegli un font bisogna specificare la lingua così da aiutarli ad elimenare i caratteri inutili e riducendo il peso del file per assicurare caricamenti più veloci.

Andy Clark su For a Beautiful Web si lamenta del fatto che Typekit offre un’ottima soluzione ma lascia un problema ai designers: se abbiamo un licenza solo per includere i font online, come facciamo ad usarli per i progetti offline da mostrare ai clienti?

Ovviamente esistono anche openfonts Su Webfont.info e Font Squirrel potete trovare lunghe liste di font disponibili per l’embedding. In particolare su questo blog uso un paio di fonts forniti da The League Of Moveable Type e Cape Arcona, potete vedere quali nella mia “about page”.
Anche Jos Buivenga offre una bella selezione di fonts.

Posso usare qualsiasi font? No, siete ovviamente limitati dalla End User Licensing Agreement (EULA), ovvero i termini della licenza, quindi scegliete attentamente quali font usate.
Ad esempio non potete caricare online un font tra quelli che avete nel vostro sistema operativo perchè solitamente hanno una licenza che ne regola l’uso solo su applicazioni per desktop. Caricandoli violereste la licenza esponendo il font alla possibilità di essere scaricato da chiunque perchè è su un server pubblico. Sciegliete sempre font che sapete avere una licenza apposta per l’inclusione. Leggete sempre attentamente l’EULA anche se avete acquistato il font perchè in realtà pagate per un permesso d’utilizzo, ma non lo possiedete realmente. Su Font Feed spiegano molto bene come leggere l’EULA con l’esempio della nuova versione pubblicata da Fontfont.
Se trovate un font gratuito e non siete sicuri riguardo alla licenza, ma volete includerlo probabilmente è una buona idea aggiungere nel foglio di stile un commento dove chiedere il permesso vicino alla regola @font-face. Almeno questo è quello che suggerisconono su Hack.Mozilla.

@FONT-FACE: COME USARLO

Se avete letto la prima parte dell’articolo potreste pensare che la situazione è ancora piuttosto confusa e non useremo questo metodo a breve.
No, in realtà tutto è pronto e potete finalmente usare la regola @font-face per il vostro testo.
Ci sono alcune limitazioni sulla disponibilità dei font, ma ne abbiamo già una grande varietà a nostra disposizione, e molti browser di ultima generazione la supportano (Opera 10, Firefox 3.5, IE dal 4, Webkit-based/Safari 3.1). Potete trovare una lista dettagliata su webfont.info.

Dunque ecco come @font-face funziona: è una regola per il vostro foglio di stile che vi permette di mettere un link ad un font (un file .ttf .otf .eot) nello stesso modo in cui ora includete codici o immagini. Il file del font è ospitato su un serve e @font-face da le indicazioni per caricarlo e tradurre il testo html dove specificato.

/* Graublau Sans Web (www.fonts.info) */

@font-face {
  font-family: Graublau Sans Web;
  src: url(GraublauWeb.otf) format("opentype");
}

body {
  font-family: Graublau Sans Web, Lucida Grande, sans-serif;
}

Ha 3 declarations:
font-family: che diventa il riferimento da usare poi nei vostri stacks. è arbitrario, potete scegliere qualsiasi nome vogliate a patto di usare lo stesso nella proprietà font-family dell’elemento html.
src: qui è dove inserite il percorso al file. Se pensate che il visitatore possa già avere quel font sul proprio computer allora potete usare local(nomedelfont) e poi aggiungere magari un percorso alternativo per sicurezza.
format: Serve a specificare che estensione di file state usando ( TrueType; OpenType;).
font-style: il valore standard è “normal” ma potete scegliere tra “italic” e “bold”. In realtà se il font lo permette potete specificare fino a 9 pesi diversi.

Se avete bisogno di sapere il nome esatto del file per scrivere il percorso corretto potete, su MacOSX e Linux cliccare su “font info” tra le opzioni del file, mentre su Windows vi servirà la font proprietary extention Comunque generalmente il nome del font si ottiene unendo la familia allo stile (es: “Helvetica Bold”).

Ricapitolando: guardate questo esempio preso da HackMozilla

@font-face {
  font-family: MyHelvetica;
  src: local("Helvetica Neue Bold"),
       local("HelveticaNeue-Bold"),
       url(MgOpenModernaBold.ttf);
  font-weight: bold;
}

body { font-family: MyHelvetica, sans-serif; }

Vedete che ogni @font-face ha le tre declarations. Con font-family si assegna il nome al font, con src si garantisce più di un percorso per trovare il file prima provando sul computer del visitatore e poi sul webserver; con format si specifica se è un file TruType o Opentype.
Subito dopo vedete un esempio di un elemento, in questo caso body, a cui viene applicato il font nel modo solito che conosciamo, basta aggiungere il nome che avevamo scelto nello stack di font-family.

ii. aiutare IE

Internet Explorer, come al solito, ha le proprie regole. Questa volta ad onor del vero dobbiamo ammettere che Microsoft era arrivata per prima con il proprio formato Embeddable Open Type (.eot) per l’inclusione e supportano @font-face già dalla versione 4 di IE.
Sfortunatamente da allora la situazione non s’è evoluta di molto e sono gli unici ad usare quel formato. In più IE non riconosce il descriptor format e ignora qualsiasi regola @font-face che lo contiene.

Questo significa che per assicurarsi una compatibilità su tutti i browsers dovrete sempre aggiungere un @font-face apporta per IE prima degli altri, con un link ad un file .eot evitando format.

/* Font definition for Internet Explorer */
/*         (*must* be first)             */

@font-face {
  font-family: chunkie;
  src: url(type/Chunk/CHUNKFI0.eot) /* can't use format() */;
}

E dove pensate di trovare i font con estensione .eot? Da nessuna parte, sorridete! Dovete convertire i vostri .ttf con il Microsoft WEFT tool (vi spiego come tra poco): Questo programma è disponibile solo per Windows, ma qui potete trovare una versione opensource per altri sistemi operativi.
Comunque queste due applicazioni vi aiutano solo a convertire i file TrueType (.ttf), ma per quanto riguarda i gli OpenType (.otf) ? Dovrete seguire le istruzioni di J.Malcolm in questo commento.

Come avevo detto poco fa, ecco come usare il WEFT per convertire i .ttf in .eot .Jon Tangerine qui spiega benissimo il suo metodo, probabilmente il migliore.

iii. ottimizzando per IE

Bene, avreste tutti gli elementi per usare @font-face, ma dovreste sempre usare due selettori per supportare IE a non è la soluzione più bella del mondo. Inoltre, anche se non siete preoccupati dell’estetica del codice, magari lo siete delle prestazioni del sito.
Andrea Giammarchi Questa settimana ha scritto un articolo dove faceva notare che IE quando legge il vostro selettore @font-face cerca di caricare anche il file.ttf sebbene non lo legga e semplicemente conclude l’operazione con un errore 404. Non vene accorgereste senza andare a controllare il log del server ma è comunque lavoro inutile per il vostro server.
Paul Irish arriva sul suo cavallo bianco per salvarci con una semplice soluzione: nella regola @font-face potete scrivere un descriptor src col percorso al file .eot per IE e poi una fonte local che costringe il browser di Microsoft ad ignorare i seguenti src ad un file .ttf, quelli per tutti gli altri browsers.Semplice, liscio, bellissimo.
Potete leggere tutto il processo di testing sul blog di Scott Kilmer Qui invece un esempio del codice preso dalla pagina di Giammarchi per capire meglio:

@font-face {
    // define the font name to use later as font-family
    font-family: "uni05_53";
    // define the font for IE which totally ignores local() directive
    src: url(../font/uni05/uni05_53.eot);
    // use local to let IE jump this line and
    // redefine the src for this font in order to let
    // other clever browser download *only* this font rather than 2
    src: local("uni05_53"), url(../font/uni05/uni05_53.ttf) format("truetype");
}

Conclusione:

Questo è tutto, abbiamo visto qual’era la situazione della tipografia nel web design fino a ieri, quali sono le proposte per domani e come usare @font-face oggi.
Avete tutti gli strumenti che vi servono e anche se sembra complicato leggendo un articolo così lungo, vi assicuro che è molto semplice dopo aver provato.
Quindi è il momento per voi di contribuire a creare un Web migliore con bellissimi typefaces!

Se qualcosa non è chiaro chiedetemi pure qualsiasi cosa nei commenti o date un’occhiata alle fonti che ho elencato più sotto.

Quando si pianifica un sito è sufficiente partire con carta e penna prima ancora di accendere il computer. è importante capire cosa vogliamo creare. Capire qual’è il suo scopo, il tipo di contenuti che ospiterà e disegnarne la struttura sarà il nostro primo passo.

Che cosa mi serve?

Dovrebbe essere la nostra prima preoccupazione, ma stranamente è probabile che ne avremo la risposta solo alla fine dell’articolo.
Per spiegarmi meglio, in base alla quantità e qualità dei contenuti, la nostra conoscenza degli strumenti, di ciò che abbiamo in mente,
avremo bisogno di creare un tipo specifico di sito che ha tutto un suo processo per essere raggiunto. Non tutti i siti sono uguali.

Ad esempio:

potreste volere una vetrina per il vostro nuovo business e solitamente un sito statico è sufficiente;
Potreste voler tenere aggiornati clienti o amici sulle vostre attività e una buona soluzione sarebbe un blog o persino Twitter se siete concisi;
magari volete creare un social network visto che in questo periodo stanno avendo successo ed in tal caso vi servirà qualcosa di molto più ampio e potente oltre a dovervi sporcare le mani col php per offrire contenuti dinamici;
un’altra possibilità è che vogliate mostrare dei vostri lavori e vi serve dunque un semplice portfolio.

Ci sono molte possibilità e dovete filtrarle anche in base alle vostre capacità se decidete di fare le cose da soli: siete dei mostri col CSS o preferite scegliere una template già pronta per il vostro blog? Avete familiarità con PHP o preferite usare un CMS per semplificarvi le cose?
Tutte scelte da considerare prima di iniziare, ma diventerà tutto semplice nei prossimi paragrafi.

Elenca i tuoi contenuti

Scrivere su un foglio tutto quello che si ha in mente di inserire su un sito è una cosa molto semplice, ma aiuta moltissimo ad organizzare il lavoro.

Facciamo un esempio, diciamo che siate un fotografo e vogliate creare un portfolio dei vostri lavori.
Bene, sapete dall’inizio che metterete molte foto sul sito e probabilmente delle galleries per raccogliere ed aiutare la navigazione. In più potreste dividerle per categorie o periodi, quindi già potremmo avere alcune pagine.
Sicuramente dovete aggiungere i vostri contatti nel caso qualcuno voglia assumervi o saperne di più e nello stesso spirito io aggiungerei anche una breve biografia o presentazione di voi stessi.

Adesso che avete fatto una lista e avete tutto davanti agli occhi potete cominciare a dividerlo per pagine così da organizzare il sito.
Seguendo l’esempio avremmo già alcune pagine di foto, ognuna con la sua gallery in base alla categoria, una pagina per i contatti, una per la biografia e una homepage dove accogliere i visitatori e spiegare cos’è il sito.
In pratica ora abbiamo una piccola flowchart, uno schemino, con le pagine del sito e che contenuti avranno. Iniziamo a farci un’idea concreta delle dimensioni che avrà.

Disegnate i Wireframes

I Wireframes sono disegni schematici della pagina e dei suoi elementi.
In poche parole si tratta di disegnare la struttura e l’aspetto della pagina.
Generalmente potete disegnare una sezione in alto per l’header ed una in basso per il footer. La navigazione potete metterla nell’header o in una sidebar, una colonna laterale come fanno molti blog.
Scegliete anche dove inserire il vostro testo, i titoli ed in questo caso le vostre immagini.
Insomma, disponete tutto come l’avevate immaginato.

Io generalmente parto con qualcosa molto schematico e pian piano che ho l idee più chiare aggiungo dettagli.
Date un’occhiata a questi esempi presi da designers e usability experts, alcuni sono già simili alla versione finale del sito e altri sono solo scarabocchi delle idee iniziali.

Wireframe #1 on flickr

Wireframe #2 on flickr

Wireframe #3 on flickr

Wireframe #4 on flickr

Questo è anche il momento per costruire le fondamenta dell’ information architecture del vostro sito. In realtà avete già iniziato suddividendo i contenuti per pagine, ma dovete anche considerare quali connettere tra loro e organizzare una gerarchia dei contenuti.
Questo vi aiuterà a creare la navigazione che &ègrave; alla base sia dell’IA che della usability del vostro sito.
Due aspetti incredibilmente importanti di cui tener conto
durante tutto il processo del vostro lavoro.

Direi che a questo giro è tutto.
Aggiungo che potete disegrìnare i vostri wireframes a mano libera (come amo fare io con risultati orribili) o sono anche disponibili alcuni software apposta per il compito, generalmente usati dai professionisti che devono poi mostrare i progetti al cliente o lavorano con altre persone.
Il prossimo passo è quello di scrivere la versione finale dei contenuti da inserire (i vari testi, titoli, etc.) e creare la veste grafica. Ne parleremo più avanti (psst, subscribe per sapere quando).

Se avete delle domande, volete approfondire qualcosa o sapere come
trattare altri tipi di siti che non erano nell’esempio potete usare i commenti, li tengo d’occhio.
Se v’è piaciuto l’articolo e pensate possa interessare a qualcun’altro condividetelo così spargiamo un po’ la voce.