Archivi categoria: Design

Prototipazione (molto) rapida

Qualche tempo fa mi è venuta voglia di fare un corso sulla prototipazione rapida di applicazioni che ho trovato su Udacity, ma negli ultimi tempi non mi è servito fare alcun prototipo… finché al lavoro – meno di un mese fa – non abbiamo dovuto cominciare da zero lo sviluppo di una nuova applicazione per Android.

Corso Udacity sulla prototipazione rapida

Corso Udacity sulla prototipazione rapida

Ci poteva stare lavorare inizialmente a prototipi per definire l’interfaccia utente, ma per evitare frizioni con i colleghi designer e per “risparmiare tempo” ho preferito evitare. Finché un bel giorno mi arriva la notizia di un tirocinante del quarto superiore in cerca di qualcosa da fare per una settimana, al che gli affido il corso web, l’analisi funzionale dell’applicazione da sviluppare e un blocco note.
Ebbene un ragazzo del quarto superiore totalmente nuovo al mondo della UX design dopo tre giorni mi ritorna con un prototipo di applicazione interattiva disegnata con la matita, e negli ultimi due giorni di test e raffinamenti progressivi ci siamo ritrovati con una bozza da cui prendere spunto fatta da un ragazzo inesperto e apparentemente “inutile”.

Per carità, se non si ha bisogno di progettare un’interfaccia utente innovativa e l’applicazione in oggetto sarà uno strumento di lavoro probabilmente può bastare seguire le linee quida del material design e utilizzare solo componenti standard per ottenere un buon risultato. Ciò non toglie però che per definire l’ordine delle voci di menù, la posizione di campi e pulsanti, l’interattività tra le varie componenti, fa comodo capire come ragionano gli utenti tipo dando loro in mano qualcosa da provare, possibilmente prima di mettersi a sviluppare.

Mockup, wireframe, sketch

Di strumenti per disegnare bozze delle proprie maschere ce ne sono tanti. Tra quelli gratuiti e open-source il migliore che conosco è Pencil, ma per la mia (poca) esperienza all’inizio conviene lavorare di carta e penna, o di tavoletta grafica quando se ne ha una.
Gli strumenti consigliati nel corso

InVision

Secondo me i prototipi sono belli se interattivi. Va bene che tutto fa brodo, e anche delle maschere disegnate su un blocco note e mostrate a un potenziale utente sono ottime per raccogliere informazioni, ma non c’è niente come osservare quell’utente mentre cerca di capire i meccanismi dell’applicazione e come raggiungere i suoi obiettivi. Per fare questo il miglior mezzo che ho trovato finora è InVision, e non a caso lo consigliano sul corso.

I tipi di prototipi disponibili

I tipi di prototipi disponibili

Aggiunta di hotspot alle proprie bozze

Aggiunta di hotspot alle proprie bozze

Aggiunta di commenti

Aggiunta di commenti

Chat di gruppo

Chat di gruppo

Condivisione del prototipo

Condivisione del prototipo

In questa breve carrellata ho elencato le funzionalità più interessanti secondo me, dalla scelta del tipo di dispositivo alla condivisione del risultato. InVision si può usare partendo da disegni a matita ma anche da prototipi più fedeli fatti con Pencil o altri strumenti simili, e il suo funzionamento è molto intuitivo. Per chi fa il corso su Udacity dovrebbe esserci anche una licenza gratuita di alcuni mesi, ma anche senza di questa i prototipi si possono fare (in numero limitato) e condividere.
Volendo c’è anche un’applicazione in stile Dropbox che aiuta a mantenere sincronizzate le immagini caricate sul prototipo con quelle sul proprio computer, così da poterle modificare più facilmente.

Per smartphone c’è un’applicazione simile chiamata POP che però secondo me è meno comoda e intuitiva. Un’applicazione web si utilizza più facilmente e InVision è difficilmente migliorabile.

Set di icone monocromatiche? Praticamente un font…

inkscape-icon

Purtroppo è da parecchio che non sto più tanto dietro allo sviluppo web, e quindi alcune “novità” tendono ad arrivarmi tardi (leggero eufemismo). La tendenza di usare icone monocromatiche su applicazioni web non è cosa recente, e la somiglianza tra la lettera di un font e un’icona monocromatica è stata notata da tempo, tanto che almeno dal 2010 c’è chi ha avuto l’idea di realizzare “font di icone” per utilizzarle come “icone vettoriali” sul web.
A me questa cosa è arrivata soltanto cinque o sei mesi fa quando mi è stato mostrato Font-Awesome. Mea culpa.

Set di font come se piovesse

Non è mai facile stabilire se sia nato prima l’uovo o la gallina, di certo c’è che le icone sono sempre più monocromatiche, e di set di font con icone di ogni genere ce ne sono ormai una marea. Purtroppo regala’ è morto, e l’utilizzo della maggior parte di questi pacchetti impone il pagamento di licenze o l’inserimento degli autori nei credits/ringraziamenti, a meno di non utilizzare quei set rilasciati con licenza Creative commons che sono originali come l’acqua calda.

Font custom, Inkscape e Icomoon

Tra gli strumenti per realizzare immagini vettoriali uno dei più usati è Inkscape (gratuito e open-source), ma non tutti sanno che in Inkscape è presente anche un editor di font con cui è possibile “raggruppare” dei glifi assegnando a ciascuno un “carattere”, realizzando di fatto un font.
Qui una bella guida sul tema, mentre qui si può trovare un progetto Github con risorse utili per crearsi i propri font.
inkscape-font-editor

Ricapitolando: con Inkscape – partendo da immagini vettoriali – si può arrivare a creare un “font svg” convertibile poi in TrueType (ttf) tramite strumenti esterni. E se non si ha voglia di fare tutti questi passaggi? Come è logico aspettarsi ci sono delle alternative.
Una strada è quella di installarsi un editor di font come FontForge, importarsi i propri glifi svg (opportunamente modificati), e crearsi il font a mano.
Strada più semplice è quella di rivolgersi a un servizio online. Ne ho provati alcuni (tra cui Fontastic), e alla fine l’unico che mi ha sempre importato gli svg e esportato i font correttamente senza distorsioni o ridimensionamenti strani è stato IcoMoon.
icomoon
IcoMoon è di una semplicità disarmante: si selezionano delle icone prese da librerie gratuite/a pagamento messe a disposizione dal sito o tra quelle importate da noi stessi e le si esportano in un pacchetto contenente il font in vari formati più tutte le risorse utili, con possibilità di configurarne anche i codici/nomi delle classi css e adattarne le dimensioni.

“Icone vettoriali” in Titanium

Veniamo alle origini di quest’articolo, visto che come dicevo all’inizio lo sviluppo web purtroppo l’ho abbandonato da un po’ di tempo.
Nel mondo dello sviluppo mobile un problema piuttosto sentito è quello della preparazione di icone e immagini alle varie risoluzioni per una buona resa su tutti i dispositivi che si ha intenzione di gestire. Il problema è ancora più marcato nello sviluppo multipiattaforma perché android e ios (per dirne due) seguono convenzioni dei nomi che non c’entrano niente l’una con l’altra, oltre a girare su dispositivi che gestiscono risoluzioni diverse.
Da un’esigenza nasce (quasi) sempre una soluzione, e in Titanium una parziale soluzione l’ha proposta uno degli sviluppatori di riferimento per questa piattaforma – Fokke Zandbergen – che ha dato alla luce TiCons.
Con TiCons si possono generare le icone dell’app e gli splash screens per tutti i dispositivi, ma la gestione delle immagini usate “all’interno” dell’app resta responsabilità nostra. Per far questo bisogna solitamente ingegnarsi con ImageMagick, che permette di fare velocemente elaborazioni anche complesse a grosse quantità di immagini tramite scripts. Questa cosa però è noiosa e così spesso si finisce per usare immagini con risoluzioni non adatte.

In una delle applicazioni di esempio corporate-directory si vede come sia possibile utilizzare “icone vettoriali” al posto di quelle raster semplicemente aggiungendo il nostro “font contenente le icone” all’interno della directory app/assets/fonts, impostando la proprietà font.fontFamily uguale al nome del font che abbiamo aggiunto e settando la proprietà testuale (es: “text” per le Label o “value” per i TextField) uguale al codice del carattere che rappresenta la nostra icona… più difficile a dirsi che a farsi, basta guardare l’esempio.

Un "esempio riepilogativo" con tutti i pezzi

Un “esempio riepilogativo” con tutti i pezzi

Gli effetti positivi di questa soluzione sono evidenti:

  • miglior renderizzazione delle immagini
  • minor dimensione delle applicazioni
  • possibilità di modificare dimensioni e colori delle icone velocemente e anche a runtime
  • nessun problema in caso di installazione su dispositivi non previsti inizialmente
  • possibilità di cambiare tutto il set di icone anche a runtime semplicemente modificando il nome del font in una classe tss
  • probabilmente ce ne saranno altri che non mi vengono

Un limite è che questa cosa si può fare solo su quel tipo di componenti dove il font (e quindi il font-family) è modificabile, questo significa che per i Tab e forse anche altrove purtroppo bisogna continuare a usare delle immagini raster.

Imparata questa tecnica mi è venuta voglia di usarla dappertutto… non appena sbatterò il muso da qualche parte aggiornerò quest’articolo, per il momento mi godo tutti i punti di cui sopra.

UX, ATM e vestizione di bug

Qualche tempo fa ho avuto la fortuna di poter assistere a un talk di @rainwiz che mi ha un po’ liberato di alcuni pregiudizi che avevo riguardo ai miei colleghi designer, i quali si occupano solitamente di migliorare la forma dei prodotti software lasciandone pressoché immutata la sostanza. Io da parte mia l’ho sempre pensata alla Don Camillo, ovvero “una cosa è bella quando è di buona qualità e serve bene al suo scopo”, e ho sempre messo font/colori/immagini in secondo piano rispetto alla “ciccia”. Ebbene in quella lunga e interessante serata di novembre ho scoperto che gente molto in gamba, spesso ferrata in psicologia (o nel caso dello speaker antropologia), si occupa quasi interamente di raccogliere informazioni attraverso interviste e questionari cercando di alterare il meno possibile i loro oggetti di osservazione (di solito i futuri utenti dei nostri software).
Esistono UX engineers (UX sta per User eXperience) che più di abbellire la UI si preoccupano di capire come ragionano gli utenti, di sfruttare scorciatoie psicologiche per facilitarne il lavoro, di evitare tranelli mentali che potrebbero causare spiacevoli inconvenienti.

ATM, goal e dimenticanze

Vi era un tempo, nemmeno troppo lontano, in cui andando a prelevare contante la gente dimenticava la propria carta/bancomat nell’ATM. In molti si saranno chiesti il perché, visto che il processo di prelievo era perfettamente simmetrico – carta => pin => soldi => carta – finché probabilmente si sarà richiesto il parere di qualche esperto psicologo (o studente in psicologia, tanto basta), e l’arcano è stato svelato.

Sopra la sequenza originaria, sotto quella attuale

Sopra la sequenza originaria, sotto quella attuale


Il problema non era tanto nella smemoratezza degli utenti, quanto in una delle funzioni esecutive della nostra mente, e nel caso specifico in quella del mantenimento del gol/meta/obiettivo in memoria.
Il concetto è semplice: si va all’ATM con un compito (task) chiaro, il prelievo di contante, e la nostra mente focalizza l’attenzione su questo obiettivo; una volta che lo si è raggiunto l’operazione è terminata, e tutto il resto rischia di cadere nell’oblio. Guardando questo flusso dalla giusta angolazione, il ricordarsi di prendere la carta prima di andarsene sembra più un’eccezione alla regola che non il contrario. Vero che se si ha tempo e si è concentrati nello svolgimento del compito generalmente ci si ricorda, ma è proprio quando si è sovrappensiero che la mente lavora in automatico, e in queste occasioni un processo modellato non tenendo conto di questi aspetti di psicologia basilare può creare grossi problemi agli utenti, anche economici.

Restando in materia di goal un esempio diverso ma non troppo è secondo me quello dell’aperitivo al bar. Si va al bar per stare in compagnia, fare due chiacchiere e bere qualcosa, e prima o poi si paga. Gli obiettivi sono chiaramente due – lo stare in compagnia e il bere qualcosa – il pagare è soltanto un mezzo, ma dal momento che in ogni bar le regole un po’ cambiano (in alcuni si paga prima e in altri dopo, nel “nostro” capita di “segnare” e spesso il barista sa già cosa vogliamo), nella nostra mente lo schema non è ben definito, quindi questa se costretta a lavorare in automatico pensa solo a fare goal. Il tempo passa, si fa tardi e salutiamo, ecco che ci siamo dimenticati di pagare. Io da parte mia raramente mi dimentico di qualcosa, e a dispetto del detto “a pagare e a morire c’è sempre tempo” cerco sempre di pagare il prima possibile, eppure mi è capitato di essermene andato senza aver pagato, e l’ho fatto anche in posti diversi dal bar.

Sempre UX e psicologia, ma applicate alle casse automatiche invece che ai bancomat

Ieri sono andato a fare la spesa e per una volta, avendo tempo, ho provato a usare la cassa automatica. Tutto molto bello, con la doppia bilancia per evitare che la gente si “dimentichi” di passare qualcosa sullo scanner, il lettore di codici a barre fisso e manuale, il controllo umano in caso di acquisti di alcolici… riguardo a questo soggetto è doveroso aprire una parentesi, quell’uomo sembrava ad un passo dal tagliarsi le vene, credo che uno dei pochi lavori più brutti di quello di cassiera sia quello di addetto alla cassa automatica, chiusa parentesi.
Finito di passare gli articoli c’è da pagare, si preme l’apposito pulsante mentre si prende il portafogli e, guidati dalla voce che chiede l’inserimento di contanti o carta si procede con il dare in pasto i soldi alla macchina. Da un verso non li prende, dall’altro neppure, il lettore chissà perché sembra non funzionare. Eppure la voce continua a richiedere l’inserimento dei soldi…

Cassa automatica al momento del pagamento

Cassa automatica al momento del pagamento


Dopo un minuto circa passato a girare e rigirare la banconota incitato dalla solita impassibile voce decido di guardare di nuovo il monitor, distante quasi mezzo metro dal mangia soldi, e vedo che c’è scritto di selezionare il metodo di pagamento.
Lasciamo stare per un momento la mia distrazione a causa della quale ho perso di vista il monitor e non ho letto cosa dovevo fare, ignoriamo anche la voce registrata che mi richiedeva una cosa mentre il monitor me ne chiedeva un’altra, e torniamo alle funzioni esecutive. L’utilizzo della cassa automatica era per me un’operazione nuova, e l’ho svolta quindi seguendo le istruzioni e comportandomi all’incirca come fossi stato d’avanti a una cassiera (allo stesso modo ho tirato fuori la carta fedeltà a metà spesa giusto perché mi sono ricordato, forse quella vocina avrebbe dovuto dirmelo all’inizio, o forse me lo avrebbe detto alla fine, chissà…). Arrivato il momento di pagare ho tirato fuori i soldi e per la mia testa questo doveva bastare, forse sarebbe stato il caso di abilitare direttamente i vari lettori aspettando uno qualunque degli input e richiedendo istruzioni soltanto in caso di ambiguità (ad esempio sul tipo di carta). La cassiera a volte me lo domanda se voglio pagare con la carta, ma di solito il tenere in mano i contanti per lei è un messaggio abbastanza chiaro, ma non lo è stato per il software il tentativo di inserirli prima di avergli detto che lo stavo per fare. La user experience pensata dai designer è ottimale? Forse si può fare di meglio?

Di sicuro c’è che questa concezione di supermercato ai giorni nostri non ha più alcuna ragione d’essere, in futuro secondo me ci saranno supermercati molto più piccoli affiancati a grossi magazzini, le persone selezioneranno la merce da un monitor e se la ritroveranno in delle buste già pronta per essere ritirata. Oppure si prenderà all’ingresso soltanto un lettore di codici a barre e ci si muoverà per dei negozi pieni di monitor scegliendo la merce a colpi di scanner, per ritrovarsela alla fine già pronta. Forse la merce ce la consegneranno direttamente a casa. O forse non esisteranno più nemmeno i supermercati e si acquisterà tutto sul web con la possibilità di pagare un po’ di più per merce con scadenze più lontane e di meno per quelle a scadenza prossima. In questo modo si pagheranno meno stipendi per lavori avvilenti e inutili, si ridurrà il rischio di taccheggi, e soprattutto molti meno alimenti saranno buttati perché scaduti. Vedremo.
Per il momento diciamo che il lavoro di cassiera al supermercato non può e non deve sopravvivere, è disumano.

Trasformare potenziali bug in features lavorando di esperienza e fantasia

UX non è solo fare in modo che l’utente esegua il proprio compito nel modo più semplice e appagante possibile, ma anche il cercare di fornirgli a basso costo funzionalità realmente utili e ridurre il rischio di errori.
Sono buoni tutti a investire tempo e denaro per sviluppare funzionalità di un software, ma non tutti sanno riconoscere l’opportunità di sfruttare potenziali bug per arricchiere il proprio programma. Nel libro I 36 stratagemmi il quattordicesimo stratagemma consiglia di “prendere a prestito un cadavere per rifondervi lo spirito”.

Stratagemma 14 della strategia cinese: "that's a feature!"

Stratagemma 14 della strategia cinese: “that’s a feature!”


Niente meglio di un buon aneddoto per fissare il concetto, raccontato da un esperto sviluppatore di mia conoscenza. Costui doveva aggiungere un sistema di messaggistica istantanea al proprio software e, trovatosi di fronte alla possibilità di inviare messaggi a se stessi, era prossimo a togliere questa possibilità perché poteva essere interpretata come un bug. Ebbene non lo fece, ma piuttosto mascherò questo “effetto collaterale non voluto” in modo da farlo sembrare una scelta, una possibilità di dialogare con se stessi come scrivendo su un blocco note. E ai clienti l’idea piacque. Per inciso questa cosa è possibile anche sull’applicazione Messenger di Facebook, ma non su Hangout di Google.

Buoni propositi pasquali

Non solo modellando processi da automatizzare al computer bisogna tenere conto di come funziona la mente, anche nella vita di tutti i giorni conoscere qualche fondamento di psicologia non guasta e può aiutare a evitare colossali figuri di me..a. Faccio quindi voto solenne, e questo articolo ne è testimone, che quanto prima cercherò di leggere almeno un libro sull’argomento e di riflettere un po’ di più sugli aspetti psicologici del mio lavoro ma anche del mio agire. Sperando di non dimenticarmene (il goal oggi è pur sempre lo scrivere quest’articolo).

Fondamenti di tipografia

Il mese scorso – approfittando di un abbonamento a prezzo di favore – mi sono fatto una scorpacciata di corsi sul veramente ben fatto CodeSchool, recente piattaforma di apprendimento online orientata alle tecnologie per lo sviluppo web. Quel Code sul nome del sito dovrebbe chiarire le finalità principali del sito, ma i fondatori non hanno mancato di offrire anche qualche nozione di design, perché è noto che la stragrande maggioranza di noi programmatori non è molto sensibile a queste tematiche (per usare un eufemismo).
Ecco quindi che – consapevole della mia carenza nella capacità di abbellimento del prodotto – ho completato anche il corso Fundamentals of design. Il primo livello, che può essere svolto anche senza abbonamento, parla di tipografia. Se avete un’oretta vi consiglio di registrarvi e completarlo, e poi magari date anche una guardata al resto dell’offerta perché è veramente di alta qualità.

Grazie o non grazie

Lasciando da parte i font di tipo Script, che simulano la scrittura in corsivo e dovrebbero essere usati con parsimonia (o meglio mai… odio il corsivo), il principale carattere distintivo di un font è la presenza o meno delle “grazie”.
La differenza tra caratteri serif e sans-serif è o dovrebbe essere nota a tutti: i serif (“grazie” in italiano) sono quegli abbellimenti stilistici che alcuni caratteri (quelli appartenenti alla famiglia dei font serif) hanno nelle parti terminali delle lettere, mentre i sans-serif ne sono sprovvisti.

Font “serif”, le grazie sono evidenziate in rosso


Font “sans-serif”

Classificazioni

Qui il discorso si fa più complicato, ma conviene comunque fare un po’ di chiarezza perché per avere “armonia tipografica” è importante scegliere e combinare i font in base alle loro caratteristiche.
CodeSchool, Wikipedia e I Love Typography raggruppano i font con criteri simili ma non proprio uguali, quindi cercherò di fare una breve sintesi, di spiegare un po’ la terminologia, e poi sarà compito di ciascuno approfondire.
La fonte più interessante e completa che ho trovato in rete è questa serie di articoli:
History of typography: Humanist
History of typography: Old Style
History of typography: Transitional
A brief history of type: Modern/Didone
A brief history of type: Slab Serif/Egyptian

I love typography segue un percorso “storico” della tipografia e suggerisce una classificazione basata sul tempo: l’antico e illeggibile Blackletter, i più leggeri Humanist, e da qui il passaggio ai più recenti e “squadrati” Modern e Slab Serif passando per gli Old Style e Transitional. Tutte queste classificazioni ricadono però nella tipologia dei Serif, e a lettere il primo articolo della serie sembrerebbe che i Sans-Serif vengano dopo e facciano classificazione a parte. In realtà ciascuna di queste classificazioni è definita da particolari caratteristiche, caratteristiche che possono essere traslate anche nella “macro-classificazione” dei Sans-Serif. Ecco quindi che forse è più corretto classificare i font in modo un po’ più gerarchico:

  • Serif
    • Humanist
    • Old Style
    • Transitional
    • Modern
    • Slab Serif
  • Sans-Serif

    • Humanist
    • Transitional
    • Geometric
  • Script

Humanist e Old Style

I font Humanist sono caratterizzati dalla lettere “o” ed “e” minuscole molto inclinate, dal corpo dei caratteri minuscoli piuttosto basso, dalla poca differenza tra i tratti più sottili e quelli più spessi (caratteristica ben visibile sulle “A” maiuscole), da serif piuttosto inclinati.

Eleganza un po' retrò

Eleganza un po’ retrò


Gli Humanist di tipo serif sono i più “classici” tra i font, e sembrerebbero maggiormente indicati nei settori accademici e legali. Quelli Sans-Serif sono consigliati invece in ambiti educativi e governativi.

Transitional

Con i Transitional si fa un bel balzo in avanti rispetto agli Humanist, e in questa famiglia si possono facilmente notare il generale “raddrizzamento” dei caratteri e delle linee (vedi la “o” minuscola), il grande contrasto tra linee sottili e spesse (vedi la “M” maiuscola) e un “livellamento” dei serif.

Tratti distintivi dei font Transitional

Tratti distintivi dei font Transitional


I Transitional rappresentano un mondo moderno, e sono consigliati nel giornalismo (Serif) e nel mondo della tecnologia (Sans-Serif).

Geometric

I Geometric hanno senso soltanto nel mondo dei Sans-Serif, perché estremamente “severi” e minimali. Come si può vedere ogni qualvolta la lettera (minuscola o maiuscola) può essere approssimata a una forma geometrica (cerchio, triangolo, quadrato) questa caratteristica viene enfatizzata.

La "geometricità" dei font geometrici

La “geometricità” dei font geometrici


Consigliati nel mondo delle scienze.

Modern

Naturali successori dei (serif)font Transitional sono i Modern, caratteri in cui le linee orizzontali e verticali sono portate all’estremo, sia nelle lettere che nelle grazie, e i caratteri tendono ad essere “stirati” in verticale.

Ortogonalità portata all'estremo

Ortogonalità portata all’estremo


Sono considerati i più eleganti tra i font, e di solito utilizzati nel mondo dell’arte e della moda.

Slab Serif

Figli della rivoluzione industriale questa è la classe di font più “grassa”: i tratti eleganti e sottili dei Modern e dei Transitional lasciano il posto a linee spesse sempre e comunque, con grazie non più così “aggraziate”.

Il font dell'abbondanza

Il font dell’abbondanza


Sono considerati adatti al mondo del marketing, forse per la loro opulenza.

Come sceglierli

A dispetto del detto “Non è bello ciò che è bello ma è bello ciò che piace” da sempre gli esperti del bello ci dicono cosa va con cosa, e nel mondo della tipografia non si fa eccezione.

Bello o non bello

Bello o non bello


Gli esperti forniscono quindi delle linee guida che è meglio seguire per evitare che le diverse sezioni del nostro sito o della nostra applicazione si lascino dopo qualche mese e per scongiurare spiacevoli risatine alle spalle:

  • se non si è designer esperti meglio evitare di mescolare diverse classi di font, perché un solo font usato bene è più che sufficiente per ottenere un bel risultato in ogni prodotto
  • per diversificare lo stile dei font, se ne possono usare diversi per diversi scopi (testata, corpo, menù, …) evitare miscugli all’interno della stessa sezione
  • mai usare due font con lo stesso stile (ad esempio due diversi Humanist Serif)
  • evitare di accostare due font della stessa classe (due font Serif per esempio), meglio dei contrasti più netti
  • utilizzare due font con stile simile ma diversa classe può dare un bell’effetto (ad esempio un Humanist Serif e un Humanist Sans-Serif)

Regola aurea: armonia totale o forte contrasto, meglio evitare spiacevoli casi intermedi.