Tag: user experience

Esportare immagini, questo sconosciuto!

Autore articolo Di Walter
Data dell'articolo Dicembre 20, 2016

Esportare immagini per le diverse piattaforme e densità degli schermi, è una pratica articolata ed ancora poco chiara ai designer.

Anche in questo caso una cattiva gestione delle immagini influisce sulla user experience. In che modo? Semplice, vedere un pulsante su uno schermo grande, in modo totalmente sgranato è poco ergonomico. Sembra qualcosa di poco professionale.

Nel mondo di chi sviluppa app Android ed iOs esistono vari formati che sono LDPI, MDPI, HDPI, XDPI, XXDPI, XXXDPI, @1x, @2x, @3x, Retina… Una sorta di minestrone di lettere e numeri.

Giustamente lo sviluppatore iOs ci chiederà: “Voglio le immagini @1x, @2x e @3x (che si legge 1 per ecc…) e le voglio in PNG”. Da designer (si sono anche un designer) potrei rispondere: “Beh ti passo un SVG vettoriale e hai tutte le dimensioni che vuoi”. Ma questa non sarebbe una soluzione ottimale perchè sia Android che iOs impongono certe restrizioni di formato file. Per essere quindi amati dagli sviluppatori bisogna passargli le immagini delle interfacce nel modo più corretto e scalabile (scalabile significa che abbiamo immagini in ottima risoluzione ottimizzate per tutte le dimensioni di schermo dei dispositivi).

Per avere immagini scalabili, bisogna disegnare obbligatoriamente in vettoriale con file SVG (cosa che molti grafici, derivati dalla grafica editoriale o dalla carta stampata, non riescono ancora a comprendere). Questo tipo di progettazione grafica significa disegnare elementi con curve matematiche. Cosa comporta però questo tipo di scelta? Semplice, molte bes**+** da parte degli sviluppatori, ogni qual volta debbano usare un’immagine vettoriale, perchè devono scrivere righe di codice per gestire immagini vettoriali. Questo processo non rende le immagini performanti, anche perchè un’immagine vettoriale è difficile da gestire da parte di dispositivi con Hardware non potenti.

Quindi la Perfomance è quel che importa!

Schema delle risoluzioni degli schermi e display

Perchè abbiamo ancora bisogno di immagini bitmap?

In primis, perchè come detto, i dispositivi (e quindi i software di sviluppo app) non gestiscono i file vettoriali nativamente. Sono file che eseguono equazioni matematiche per essere rappresentati su uno schermo. Difatti sono matematica allo stato puro che viene visualizzata su un display e anche se Android ha una suite di librerie native per gestire questi file, non è così semplice lavorarli.

Le risoluzioni degli schermi

In base alla tecnologia di schermo montata su un dispositivo, le immagini vengono rappresentate in un certo modo. E’ ovvio che su un display retina di apple (che ha il doppio dei pixel luminosi per pollice quadrato, di altri schermi) non possiamo passare un’immagine se pure in alta definizione progettata per un display meno evoluto. Pertanto vanno esportate dai software di disegno (qualsiasi esso sia: Photoshop, Illustrator, Gimp ecc…) nel modo più opportuno in base alla risoluzione dello schermo.

La regoletta

Come diceva la mia professoressa di matematica: <<Ecco la regoletta!>>. Per converitre le misure tra Pixel e Punti si può usare questo calcolo:

iOS pixels= (Points* DPI)/163
Android pixels= ( DP * DPI)/160

In questo modo il designer può calcolare le dimensioni di un elemento (pulsante, immagine ecc…) per i vari display android o apple che hanno delle densità di pixel (numero di pixel per pollice quadrato) differenti a seconda del display montato sullo smartphone o il tablet.

Il concetto finale è progettare un design che sia flessibile in base ai dispositivi, e che sia performante a differenza di densità e misura del display. Pertanto è prassi lavorare in versione bitmap con un impianto grafico studiato per la risoluzione più alta, ed avvalersi poi di script (ne trovate di gratuiti in giro) per esportare le immagini nelle varie risoluzioni in modo tale da automatizzare il flusso di lavoro.

Script che esportano in automatico varie dimensioni di file

Ho reperito questo script che è facilmente installabile con questa procedura (esiste anche questo script alternativo):

Scarica lo script qui

sposta il file .jsx nella tua cartella script di Photoshop:

Mac: /Applications/Adobe Photoshop…/Presets/Scripts/

PC 64bit: *C:Program FilesAdobeAdobe Photoshop… (64 Bit)PresetsScripts*

PC 32bit: *C:Program FilesAdobeAdobe Photoshop…PresetsScripts*

Una volta installato, selezionate l’elemento da esportare nelle varie risoluzioni e lanciate lo script da File>Scripts>Browse>Nome dello script.

A questo punto vi ritroverete in una cartella le immagini suddivise in sottocartelle per ogni risoluzione così come rappresentato in figura 1

Potete usare queste immagini anche per iOs, qui i riferimenti delle misure

MDPI = (@1x)

XHDPI = (@2x)

XXHDPI = (@3x)

Il Barbatrucco

Un “barbatrucco” per vedere se abbiamo disegnato con le giuste proporzioni una UI è quello di utilizzare il sito material.

Scegliete un’icona qualsiasi
Selezionate in basso la risoluzione che volete
Scaricate i PNG

Vi verrà inviato un file zip contenente le icone per i vari dispositivi e risoluzioni, comparateli con quelle che avete realizzato voi ed il gioco è fatto!

Spero che l’articolo vi sia stato utile e per feedback scrivetemi qui.

Walter Fantauzzi

Tag articles, articolo, blog, ui, user experience, user interface, ux

Ux Blog

The Power of Color

Autore articolo Di Walter
Data dell'articolo Ottobre 28, 2016

La potenza del colore nella progettazione di applicazioni mobile è il secondo aspetto importante nella realizzazione di un app. Le interazioni Human-Computer sono fortemente basate sulla interazione con gli elementi grafici della UI (User Interface), dove i colori ricoprono un ruolo critico. Essi aiutano a interpretare i contenuti dell’applicazione, e permettono di far interagire lo user con i giusti elementi. Nella progettazione di un app, definisco uno schema colore primario per le aree principali, utilizzando le logiche della teoria del colore.

Definire una giusta palette colori (o schema colore) è un’operazione molto delicata. I fattori in gioco possono essere il colore del brand o del logo, il contrasto visivo, il mood ecc…

Solitamente non supero mai una palette colori di 3 / 5 soluzioni cromatiche, questo per non rendere l’interfaccia UI di difficile lettura. Partendo dalla ruota colore classica, definisco il mio colore principale dal quale declinerò i restanti 2 o 4 colori.

Ruota a 12 colori, molto utile nella definizione del colore base.

Progettare con colori monocromatici

Lo schema più semplice è quello della scelta di una palette monocromatica, con sfumature che partono dal colore principale. Come potete vedere dall’immagine che segue, partendo dal colore blu della ruota colore, definisco una scala di 6 cromie di blu.

colorapp — I colori monocromatici sono derivazioni del tono colore principale.

Un esempio che può rappresentare una interfaccia UI con questo schema colore è mostrato nella prossima immagine. Difatti ogni elemento non ha tinte o colori al di fuori di questo schema.

I colori analoghi

Con i colori prossimi a quello principale, possiamo definire uno schema colore di tonalità analoghe al principale. Nella seguente immagine, potete capire come individuare i colori vicini a quello principale.

Un’interfaccia UI basata su questo schema colori è la soluzione riportata nella immagine seguente, in cui con una mappa di calore definita con i colori, viene descritto il peso di ogni informazione.

Complementari

I colori complementari sono i colori opposti a quello principale. Il grande contrasto che ne deriva, attrae l’attenzione visiva dello user. La scelta dei colori, deve essere ponderata sulla fisica della luce e su come essa interagisce sul nostro cervello. Essendo noi umani molto più sensibili al verde, possiamo sfruttare queste caratteristiche visive per accentuare l’importanza di un elemento e magari focalizzare l’attenzione ad un particolare(Verde), usando un colore di contrasto (Rosso). E’ il caso dell’icona di iMessage che vedete in figura.

L’impatto del contrasto nei colori

Tipicamente i colori degli oggetti, dei testi e delle aree nelle UI non sono isolati ma bensì mescolati o sovrapposti tra loro. E’ quindi necessario un giusto contrasto per enfatizzare o meno, l’attenzione all’elemento di interfaccia. Pensiamo ad un pulsante che si attivi solo dopo aver inserito nel campo username e password i dati, il pulsante si attiverà solo dopo aver popolato i text field (i campi) con nome e password.

Progettare per il daltonismo

Personalmente non mi era mai capitato di progettare un app o un sito web per user che soffrissero di daltonismo, fin quando non ho avuto nel mio team di sviluppo un programmatore affetto da daltonismo. Da quel momento in poi, nella mia mente c’è sempre una forma di attenzione a chi ha problematiche cognitive di qualsiasi genere. Nel caso del daltonismo, si parla della incapacità da parte del cervello di percepire alcuni colori. Il rosso e il verde sono combinazioni di colori che danno maggiori problemi, difatti il daltonico è “cieco” davanti a queste situazioni.

colorapp-4 — In questa immagine, la simulazione di due possibili ruote colore percepite dai daltonici

E’ importante, quindi, definire nella nostra app visuali multiple per comunicare degli status importanti dell’app. Mai fare affidamento su un colore solo per indicare qualche status importante di sistema, ma sfruttare anche animazioni e contrasti così come nella grafica seguente.

Grazie a Photoshop, possiamo disporre di strumenti per simulare cosa visiona una persona affetta da daltonismo, ne è un caso l’immagine seguente.

In conclusione, abbiamo affrontato i principali fondamenti della teoria del colore applicata alla progettazione di UI e di UX. Affinare le abilità all’uso dei colori deve essere uno sforzo continuo!

Walter Fantauzzi

Tag color, ui, user experience, user interface, ux

Ux Blog

Modus Operandi UX

Autore articolo Di Walter
Data dell'articolo Agosto 1, 2016

Nel seguente articolo, la descrizione del mio approccio al mondo della User Experience. Le fasi ed il workflow utilizzati nelle mie progettazioni di UX e UI.

Fase 1: Il Workflow
Prototipizzare, misurare e ascoltare.
Sono le tre fasi essenziali per la realizzazione di un buon prodotto.

Le distinguo in questi tre tempi:

1. Realizzare un prototipo
2. Misurare i risultati Analizzare i feedback
3. Progettare

L’immagine seguente mostra l’andamento della fase progettuale. Partendo dal basso della piramide trovate i punti cardine alla base del mio processo lavorativo.

Fase 2: Paper Prototype
Il “Modus operandi” che utilizzo nella realizzazioni delle UX è di tipo piramidale.
Dopo l’intervista con il cliente e la definizione dei “goal” da raggiungere, il primo step che vado ad affrontare è quello del “Paper Prototype” ovvero uno schizzo su carta. Sarà pertanto il Paper Prototype la guida per definire al meglio, con il cliente, le funzionalità e la navigazione dell’applicazione (o sito web). Parto dall’unità di misura che si definisce in MVP (Minimum Viable Product = Minimo Prodotto Fattibile), ovvero realizzo l’applicazione volta per volta, partendo da una versione iniziale che racchiude un set minimo di funzionalità. Quest’ultime sono le caratteristiche indispensabili che soddisfano le richieste del cliente.

Fase 3: Wireframe
Definito il processo di navigazione e la collocazione dei contenuti procedo alla realizzazione di un wireframe digitale con il software “Sketch”. L’utilizzo delle librerie o design pattern mi permette, in tempi brevi, di realizzare un wireframe o un diagramma di flusso ottimale. In questo modo avremo un timone da seguire, senza possibilità di perdersi durante la fase di realizzazione dell’app. Utilizzando invision app, rendo disponibile la “definition on done” (ovvero il progress lavori) a tutto il team di sviluppo.
Mediante questa applicazione posso condividere con i developer ed il cliente, lo status di ogni vista secondo degli step (in fase di review, fermo, fatto ecc…).

Fase 4: Lo studio di fattibilità
Lo step successivo sarà realizzare uno studio di fattibilità con gli sviluppatori, per valutare tempi di realizzazione e processi scrum. Quest’ultima fase permetterà di avere un preventivo di tempi e costi per la realizzazione del prodotto commissionato. Una volta raggiunti gli accordi tra lo strato “developer” e quello delle “funzionalità” da realizzare procedo con la realizzazione visual.

Fase 5: Visual Design
In questa fase realizzo l’interfaccia grafica (o meglio la UI) dell’applicazione. Definisco quindi i placeholder dei contenuti, i pulsanti, le immagini ecc… da posizionare sullo schermo. La progettazione del linguaggio grafico a volte estende quello già esistente dell’azienda. Utilizzo quindi colori, loghi e simbologie tipiche del cliente. Non raramente c’è la necessità di rivalutare la palette colori, definire nuovi simbolismi o addirittura un restyling del linguaggio grafico del brand. Il tutto per rendere l’applicazione ergonomica nel migliore dei modi.

Fase 6: Prototipazione 2.0
Principal per la prototipazione animata è uno dei software più rapidi e realistici. Utilizzo questo ambiente per rendere tangibile l’esperienza d’uso ( o UX) da mostrare al cliente. Posso quindi analizzare se la mia UX è user oriented (ovvero incentrata sull’utilizzatore) o meno, così da valutarne eventuali modifiche o migliorie. Valuto se il raggiungimento dei goal sia soddisfacente, e ne monitoro i feedback o eventuali problematiche da migliorare.

Fase 7: Asset
Una volta definita la veste grafica, lo studio di fattibilità con i developer e gli obbiettivi richiesti dall’utente, creo gli asset da passare allo sviluppatore. Lavorando in ambiente Creative Cloud, la funzione “collabora” da Photoshop CC mi permette di condividere tutti gli elementi grafici agli sviluppatori. Dai colori in esadecimale utilizzati, alle immagini o elementi grafici dell’interfaccia.
Bellissima ed utilissima è l’applicazione Slack, una sorta di chat collaborativa, con la quale posso condividere dettagliatamente un elemento grafico o non con il team di sviluppo. A volte propongo tramite reference visivi e porzioni di codice, animazioni dinamiche COCOA da poter applicare a gesture o eventi.

Fase 8: Dead Line o No?
Sinceramente non credo esista una dead line per un’applicazione mobile o web. O meglio esiste uno step nel quale l’app deve andare online ma di certo non può morire così.

Il mondo dell’informatica è in costante evoluzione pertanto anche le app ed i siti web, così come gli esseri viventi, devono avere un mutamento. Possiamo valutare molti case study da facebook a flipboard ed altri ancora.
Non credo che si possa definire un’applicazione “finita”, posso dire che è in constate mutamento.