
A differenza del predecessore, in B3 l'orientamento è verso il mobile first*. Significa che l'aspetto responsivo ( visuale e a livello di prestazioni ) non è un opzione ma la base del framework. In pratica, la griglia offre un esteso margine di personalizzazione a seconda che il device sia extra small, grazie all'utilizzo delle classi specifiche seguite dalla dimensione ( col-xs- ), small ( col-sm- ), medium (col-md), large ( col-lg- ).
Extra small devices Phones (<768px) | Small devices Tablets (≥768px) | Medium devices Desktops (≥992px) | Large devices Desktops (≥1200px) | |
---|---|---|---|---|
Grid behavior | Horizontal at all times | Collapsed to start, horizontal above breakpoints | ||
Container width | None (auto) | 750px | 970px | 1170px |
Class prefix | .col-xs- | .col-sm- | .col-md- | .col-lg- |
# of columns | 12 | |||
Column width | Auto | ~62px | ~81px | ~97px |
Gutter width | 30px (15px on each side of a column) | |||
Nestable | Yes | |||
Offsets | Yes | |||
Column ordering | Yes |
Altre differenze rispetto al b2, sono rappresentate da:
- Icone, adesso realizzate grazie a un font ( vettoriale, il che le rende scalabili, colorabili e a cui possono essere applicati tutti gli effetti css3 )
- La componente menu, chiamata navbar, in precedenza non proprio ottimizzata su dispositivi mobili :
un aspetto che è stato eliminato per esempio è la possibilità di avere sub-menu di terzo livello, in quanto sui dispositivi mobili non è molto usabile. E' preferibile utilizzare un menu secondario, ad esempio.
- L'estetica è stata ripulita da ombre e angoli eccessivamente presenti
- Un altro aspetto che viene preso in considerazione è la costruzione dinamica dei css con LESS ( o SASS ) :
in soldoni, il css che fino a poco tempo fa era rimasto un elemtno statico nel mare dinamico del web, viene arricchito nel file .less da variabili e funzioni ed ereditarietà delle proprietà quasi come un linguaggio di programmazione: il file viene poi compilato in .css per essere interpretato da tutti i browser.
B3 è supportato dai browser moderni, e per Internet Explorer 8 è necessario lo script Respond.js in grado di aggiungere a quel browser la capacità di gestire le media query. Addirittura alcune funzionalità minori del framework non sono supportate su IE9, che comunque rimane un browser di sei anni fa, più o meno il pleistocene.
Per ospitare i contenuti del sito abbiamo a disposizione due classi (non nestabili):
- .container per un contenitore larghezza fissa reattivo.
- .container-fluid per un contenitore di grande ampiezza, che copre l'intera larghezza della window.
Questo strumento ci aiuta a raggiungere il risultato di una buona usabilità dell'interfaccia.
Un prodotto è accessibile quando tutti - indipendentemente dalla capacità - possono navigarlo, capirlo , e usarlo per raggiungere i loro obiettivi.
- Anteporre a tutto il contenuto: il contenuto è il Re. Ombre, angoli, colori ecc, devono essere asserviti alla presentazione del contenuto e non solo all'estetica
- Rendere adatto il layout a prescindere dal dispositivo utilizzato per accedere all'applicazione: prevedere che aspetto dovrà avere l'applicazione per i principali device quali smartphone, tablet, schermi piccoli e larghi.
- Evidenziare cambiamenti di stato importanti ( hover, bradcrumb, messaggi di errore, stato degli input, caricamento della pagina, dei dati o delle immagini ecc - ovvero sia 'linear progress bar' o 'loaders'.quando è presente l'informazione, indicare il tempo previsto per il completamento dell'azione in percentuale o in secondi ), e indicare se l'azione richiesta è andata a buon fine o meno con un messaggio chiaro.Insomma: visual feedback. In questo caso, un framework come AngularJs può aiutare a rendere reattiva l'applicazione, con cambi di stato immediati ma rappresentati chiaramente ( con cambi di colore, messaggi, animazioni ecc...) e avere un unica pagina in cui caricare le informazioni e i dati ( single page application ) comporta più velocità e più omogeneità di layout.
- Visualizzare le informazioni ( in particolar modo i messaggi d'errore ) in modo che attirino l'attenzione e non possano sfuggire.
- Non avere "stati" ambigui ( in cui l'utente non sa cosa fare: tipo i tasti CANCEL e DELETE ad esempio o la pagina che carica senza nessun feedback visivo ad indicarlo)
- Evitare form troppo lunghi ( piuttosto separarli in form a "step" )
- Gli input devono essere proporzionati al contenuto, devono poter ospitare solo il tipo di input previsto dal tipo di campo ( lettere per i nomi, numeri o mail con controllo lato javascript ecc.) e il loro contenuto và controllato sia lato server che lato client ( javascript )
- Evitare le immagini banali o 'stock'
- Avere un punto di messa a fuoco: assicurarsi che un concetto sia chiaro e venga convogliato all'utente in modo non ambiguo.
- Attenzione al fatto che elementi e testo siano correttamente contrastati, leggibili o che non siano nascosti
- Per la Typographia e gli stili di base, troppi formati di tipo e stili in una sola volta può inficiare qualsiasi layout e comunicare confusione. Una giusta scelta tipografica ha un insieme limitato di formati che funzionano bene insieme con la griglia di layout .
- I formati delle informazioni, non solo le stringhe, devono essere adattati ai vari "locale", ad esempio le date, o i numeri di telefono in inglese o italiano hanno una rappresentazione diversa.
- I pulsanti devono essere omogenei in tutta l'applicazione e distinti per funzionalità e stato grazie a label e colore ( cancellazione, annullamento, invio, link, salvataggio ecc) Cercare, ad esempio di tenere separati i pulsanti con azioni distruttive da quelli invece di conferma.

- L'azione deve essere chiara possibilmente senza necessità di ulteriori conferme.
- I testi non devono essere troppo lunghi. Per testi lunghi, che è fondamentale separare in paragrafi, approssimativamente bisognerebbe stare sotto i 60 caratteri per riga, mentre per le frasi corte, tra i 15 e i 40.
- Gli spazi sono fondamentali: in fatto di User Interface e Usability, padding, margini e spazi vuoti sia orizzontali che verticali sono fondamentali. Un esempio che mi viene in mente, è quello della galleria d'arte, con i quadri disposti alla giusta distanza ( troppo lontani = dispersivo mentre troppo vicini = caotico ) piuttosto che ammassati troppo vicini o con elementi estranei che complicano la percezione del quadro.
- Per le Dialog in genere sono costituito da testo e / o di controllo UI, come bottoni ecc., e sono focalizzate su un compito o un processo specifico , come ad esempio la conferma di una cancellazione o la scelta di un elemento.Evitare di aprire finestre di dialogo aggiuntive all'interno di una finestra di dialogo . Evitare di creare finestre di dialogo con scroll dei contenuti ,in particolare per quanto riguarda gli avvisi.
- Le modali invece sono avvisi ( il fatto di apparire in primo piano , scurendo il fondo, fa capire che sono avvisi da tenere in considerazione ) che possono o meno avere dei button. Di certo devono avere il bottone 'chiudi' rappresentato da una X posizionata in alto a destra. Le tooltip infine, sono una sorta di 'label' che appare all'mouse in e scompare al mouse over.
- Se è richiesto un titolo , ad esempio per situazioni ad alto rischio , come la potenziale perdita di dati,utilizzare una domanda chiara o dichiarazione con qualche spiegazione aggiuntiva nell'area del contenuto .Essere il più chiari possibile presentando queste situazioni, in modo da evitare il più possibile scuse e dichiarazioni ambigue o domande .Ad esempio , "Attenzione ! " O "Sei sicuro ?"
- I record cancellati devono essere chiaramente indicati con una linea barrata e il colore rosso. In caso di campo cancellato.
- I record devono avere delle etichette che indichino il loro numero, di quanti campi, e la paginazione.
- Per garantire la fruibilità per i disabili , assicurarsi che i tasti abbiano una altezza minima di 35px. Assicurarsi sempre il colore del testo azione utilizzi un rapporto di contrasto sufficienti a soddisfare le linee guida di accessibilità.
- I testi e le icone devono essere allineati verticalmete. I campi di input non devono avere spazi eccessivi a fine o inizio di pagina o colonna (dette, rispettivamente, orfani e vedove) e deve essere presente l'informazione se il campo è 'obbligatorio'.
- Usare quanto possibile delle guide per la compilazione: maschere per gli input, tendine con i dati già compilati, autocomplete (da utilizzare nei campi di testo per presentare suggerimenti in tempo reale o completamenti nel menù a discesa in modo che gli utenti possano inserire informazioni più accurato ed efficiente.
- Se possibile, evitare eccessivi scroll verticali. Prevedere un pulsante 'To Top' per ritornare in cima.Quello orizzontale non è previsto in nessun caso.
- Fornire testo alternativo per le immagini e il video.
- Dare un senso ai link ( Mettete lo scopo del collegamento nel testo del link stesso):"clicca qui " non serve a questo scopo, meglio ad esempio "Cambia le Impostazioni".