Definizioni

Secondo il Merriam-Webster una guideline è una regola o un'istruzione che indica come qualcosa debba essere fatta. Secondo Wiktionary è un principio o una regola non specifica che offre una direzione all'azione o al comportamento; un piano o una spiegazione che guida nello stabilire degli standard o determinare il corso di una azione.

Una guida di stile, secondo Wiktionary, è un insieme di standard per progettare e scrivere documenti, sia per uso generale che per delle pubblicazioni o organizzazioni specifiche, e può definire standard di tipografia, grammatica e sintassi.

Per semplificare, potremmo considerare le guide di stile come delle linee guida specifiche per il visual design e della scrittura dei contenuti.

Spesso i termini guideline e style guide sono usate in maniera intercambiabile. Questo è giustificato anche dal fatto che alcuni framework sono, contemporaneamente, delle linee guida e delle guide di stile. Basti pensare alle Material design - Google design guidelines. Google le chiama - giustamente - guideline, ma nel documento vengono stabiliti anche dei princìpi di stile. Inoltre, alcuni dei documenti che abbiamo citato nel benchmark sono definiti Human interface guideline.

Una possibile distinzione può basarsi sui livelli di Garrett:

• le guide di stile si riferiscono principalmente al quinto piano, la superfice, ovvero il visual design;
• le Human interface guideline si riferiscono principalmente al quarto piano di Garrett, lo scheletro: information design, interface design, navigation design;

Guide di stile e hig sono tipologie di linee guida.

Pattern

Le librerie di pattern si differenziano dalle guide in quanto sono

• meno prescrittive: identificano possibili soluzioni ad un problema in un contesto
• garantiscono principalmente la consistenza esterna: identificano dei pattern nelle soluzioni adottate da altri
• sono generalmente strutturate in base a delle regole di documentazione
  • nome e classificazione del pattern
  • intento: gli scopi e le ragioni per usarlo
  • lo scenario, il contesto dove generalmente si applica
  • l'applicabilità
  • l'implementazione del pattern
  • degli esempi di utilizzo
  • eventuali pattern collegati

Finalità

Le finalità di un documento di linee guida sono molteplici:

• costituisce uno dei documenti di riferimento nella progettazione e nelle iterazioni
• fornisce un linguaggio comune per designer, sviluppatori, project manager, product manager, marketing
• garantisce consistenza dell'interfaccia, del linguaggio, del look and feel all'interno di un ecosistema (cross-canalità)
• agevola lo sviluppo e l'adozione di buone pratiche
• riduce i tempi di progettazione e di sviluppo
• stabilisce uno stile, per migliorare la comunicazione
• dettaglia gli elementi, i moduli, i componenti
• costituisce la base per la valutazione euristica

Linee guida importanti

Di seguito verrà presentato un elenco di alcune linee guida particolarmente importanti, con alcuni esempi.

W3C

I documenti del W3C sono delle linee guida speciali, in quanto costituiscono gli standard del webdesign.
Sono, necessariamente, estremamente generali, e non potrebbe essere altrimenti, visto che la loro applicabilità dev'essere il più possibile universale.

Sebbene le specifiche del W3C siano molto di basso livello, nelle specifiche html5 vi sono degli elementi finalizzati a definire la macro-struttura delle pagine web, gli HTML structural elements - W3C Wiki.

Siti governativi statunitensi

Usability.gov è un sito, curato dal governo statunitense, che pubblica un esteso documento di linee guida (Guidelines | Usability.gov).
Nel documento vengono affrontati numerosi argomenti: il processo di design, l'accessibilità, il layout, la navigazione, gli aspetti grafici, i contenuti, i test di usabilità.
Uno dei punti di forza del documento, oltre alla sua estensione, è la presenza di un indice che stima la Strength of Evidence di ogni linea guida.

Recentemente, inoltre, lo U.S. Digital Service della Casa Bianca ha pubblicato un documento, gli U.S. Web Design Standards. Il documento, pubblicato anche su Github, copre i seguenti argomenti: Visual style, Grid, Buttons, Labels, Tables, Alerts, Accordions, Form controls, Form templates, Search bar, Side navigation, Footers.

Fra i punti di forza, il fatto che, per ogni sezione della guida, vengano citati sia gli aspetti legati all'accessibilità, sia a delle indicazioni per massimizzare l'usabilità.

Esempio

Buttons

Accessibility

• Buttons should display a visible focus state when users tab to them.
• Avoid using div or img tags to create buttons. Screen readers don't automatically know either is an usable button.
• When styling links to look like buttons, remember that screen readers handle links slightly differently than they do buttons. Pressing the Space key triggers a button, but pressing the Enter key triggers a link.

Usability

When to use

• Use buttons for the most important actions you want users to take on your site, such as "download," "sign up," or "log out."

When to consider something else

• If you want to lead users between pages of a website. Use links instead.
• Less popular or less important actions may be visually styled as links.

Guidance

• Generally, use primary buttons for actions that go to the next step and use secondary buttons for actions that happen on the current page.
• Style the button most users should click in a way that distinguishes from other buttons on the page. Try using the “large button” or the most visually distinct fill color.

Gov.uk

Da alcuni anni il Government Digital Service del Regno Unito sta lavorando ad un processo di standardizzazione dei propri servizi digitali. Fra le risorse disponibili citiamo i design principles, il Government Service Design Manual, i Design patterns,

GOV.UK elements è il documento di style guide di gov.uk.

Esempio

Labels

• all form fields should be given labels
• don't hide labels, unless the surrounding context makes them unnecessary
• labels should be aligned above their fields
• label text should be short, direct and in sentence case
• avoid colons at the end of labels
• labels should be associated with form fields using the for attribute

Anche questa style guide è su Github.

Confederazione Svizzera

Anche la Configurazione Svizzera ha pubblicato delle guide di stile, le Swiss Styleguide, direttamente su Github. Secondo la presentazione

The Confederation Web Guidelines define the design specifications for the presentation of the Swiss Federal Administration on the Internet and are binding for all websites within the domain admin.ch. These guidelines specify how the websites of the Federal authorities have to look and how they should behave. At the same time they give the government departments and public offices the necessary flexibility to be able to optimize their online communications to the requirements of their specific business purposes.

Interessante la lista di pagine di esempio, che definiscono una sorta di tassonomia delle tipologie di pagine, a mio avviso molto utili.

Le sezioni principali sono Design principles, Base layout, Navigation modules, Content modules, Example pages.

Esempio

Slideshow

The slideshow uses the jQuery plugin (Blueimp Bootstrap Image Gallery) to display images in fullscreen from the basic carousel. Be sure to add the correct layout before your body closing tag, as explained in the example below.

Accessibility issue

The slideshow component is not compliant with accessibility standards. If you need to be compliant, please consider other options for presenting your content.

Apple

Apple ha pubblicato delle Human Interface Guidelines (HIG) sia per OS X che per iOS.

Le OS X Human Interface Guidelines, definiscono le linee guida per progettare per Mac OS X. Le linee guida suggeriscono, fra l'altro: Interaction and Input, Branding, Wording Terminology and Wording.

Windows

Design Universal Windows Platform (UWP) app - Windows app development sono le linee guida per progettare applicazioni per Windows 10. La sezione design basics si divide in:

• UI basics: descrive l'anatomia dell'applicazione, e alcuni pattern
• Navigation design basics dedicate alla navigazione
• Command design basics: gli elementi che permettono all'utente di portare a termine delle azioni
• Content design basics: i contenuti dell'applicazione.
• Responsive design

<!--- There are three main content scenarios:

• Consumption: A primarily one-way experience where content is consumed. It includes tasks like reading, listening to music, watching videos, and photo and image viewing.
• Creation: A primarily one-way experience where the focus is creating new content. It can be broken down into making things from scratch, like shooting a photo or video, creating a new image in a painting app, or opening a fresh document.
• Interactive: A two-way content experience that includes consuming, creating, and revising content. -->

Le Guidelines for Universal Windows Platform invece elencano una serie di linee guida più specifiche. Fra gli argomenti trattati: Animations, App settings and data, Controls and patterns, Custom user interactions, Files, data, and connectivity, Globalization and localization, Help and instructions, Identity and security, Launch, suspend, and resume, Layout and scaling, Maps and location, Text and input, Tiles and notifications.

Esempio

Guidelines for filtering and sorting - Windows app development

Filter

A filter command hides content within a list based on some criteria. For example, you might want to view store apps based on "Best rated."

When to enable filters: Any list that contains more than few items can benefit from filtering. Lists that are large enough to require scrolling benefit the most.

Recommendations

• Be sure to inform the user whenever a filter is active. Otherwise, the user might not realize that there some items are being hidden.
• Always provide an easy way to clear the filter. Typical users will want to try a variety of filtering options; providing an easy mechanism for clearing the filter encourages the user to experiment.
• Make it obvious when filtering options are exclusive or additive, so that users know what behavior to expect.

Google Material Design

Material design sono delle design guidelines pubblicate da Google, che le intende come un linguaggio visivo che sintetizza i princìpi classici del buon design con l'innovazione e la tecnologia. Fra gli scopi del linguaggio, creare una esperienza coerente fra le diverse piattaforme.

Linee guida di design per i servizi web della Pubblica Amministrazione

Il gruppo di lavoro Designers Italia ha pubblicato le linee guida di design per i servizi web della Pubblica Amministrazione. Il materiale prodotto è davvero ottimo, costituisce la base di partenza per tutti i progetti digitali della pubblica amministrazione.

Lonely Planet

Lonely Planet ha pubblicato Rizzo; anche in questo caso il codice è su Github. Nel progettare Rizzo, i designer volevano creare una styleguide facile da mantenere.

La guidelyne distingue fra Design elememts (colori, tipografia, icone) e UI Components (una lunga lista di componenti: cards, alerts, badges, tiles e così via).

MailChimp

MailChimp ha pubblicato una Pattern Library. L'approccio sottostante lo sviluppo della libreria è descritto in un post in cui si introduce il concetto di Systemic Design.

Nella libreria vengono definiti Grid System, Typography, Form Elements, Navigation, Tables, Lists, Slats, Stats/Data, Feedback, Dialogs

Altri esempi

• Ubuntu Design
• Lightning Design System è un framework di Salesforce. Nelle loro linee guida, distinguono fra design, components e voice and tone.
• Code for America Style Guide
• Yelp Styleguide
• Pattern Library | DoSomething.org

Risorse utili

• Website Style Guide Resources è un elenco di risorse sulle style guide
• Atomic Design | Brad Frost introduce il concetto di Atomic Design.
• How to create beautiful style guides online | DesignHooks
• 29 Well-Designed Online Style Guides - Web Design Ledger
• UI Style Guides | Experience Dynamics
• 50 Meticulous Style Guides Every Startup Should See Before Launching – Design School

Strutturare un documento di linee guida

Come dovrebbe essere strutturato un documento di linee guida? Il documento dovrebbe essere strutturato in base ad una gerarchia di livelli di astrazione: dai princìpi più astratti (princìpi generali, di design, ucd, accessibilità) alle funzioni delle interfacce, alle tipologie di schermata, fino al dettaglio (rappresentare le date, le label) e, se opportuno, ai dettagli implementativi.

Una possibile struttura è dunque questa.

• i princìpi generali; ad esempio essere centrati sull'utente, essere inclusivi, essere finalizzati alla semplificazione e alla facilità d'uso, essere aperti (open source, open standard, open data) e così via;
• i princìpi di design: citando ancora GOV.UK: focalizzarsi sui bisogni e gli scopi, con un approccio che si basa sui dati, possibilmente snello (do less), orientato ai servizi (digital services);
• i princìpi cognitivi dell'ucd (sulla falsariga delle euristiche di Nielsen o di Gerhardt-Powals); ad esempio: minimizzare il carico cognitivo, minimizzare l'incertezza, essere consistenti, usare rappresentazioni adeguate all'infomazione, al contesto, al compito, usare una terminologia appropriata, prevenire e minimizzare gli errori, permettere l'esplorazione, dare all'utente il controllo, rappresentare lo stato del sistema, facilitare l'apprendimento, usare l’aspetto grafico e visivo al servizio dell’usabilità;
• i princìpi dell'accessibilità, - riferendosi alle linee guida ufficiali, ad esempio le linee guida per l'accessibilità dei contenuti Web (WCAG) 2.1;
• la mappa delle più importanti funzioni e servizi online dell'ambito che viene coperto; ad esempio, per le linee guida di una pubblica amministrazione: registrarsi e creare un profilo, autenticarsi, procedure per fare una domanda, chiedere un documento o un certificato, contattare un referente o un ufficio, inviare una certificazione, richiedere e usare la firma digitale, e così via;
• la definizione dell'anatomia della pagina: intestazione, navigazione principale, navigazione contestuale, area principale, footer, e la definizione dei requisiti di ogni area;
• definizione delle tipologie di pagine previste: home, pagine indice, pagine di funzione, pagine degli oggetti; un buon esempio sono le Page Types della Swiss Styleguide;
• la definizione del layout, con la specifica di layout diversi per i diversi canali: tipicamente i layout large, medium e small di desktop, tablet e smartphone;
• la definizione degli elementi dell'interfaccia, in base ad un approccio modulare e gerarchico, sulla falsariga dell'atomic Design;
• i princìpi di implementazione: che strumenti usare; framework css (es. bootstrap), librerie javascript; quali vincoli (es. quali versioni di browser supportare);
• una linea guida per il codice css, html e javascript (le Styleguide di Github possono essere un buon punto di partenza); Un'ottima lista è CSS Style Guides di CSS-Tricks;
• dei princìpi di stile grafico (colori, tipografia), e brand guidelines; ad esempio il Guardian, Twitter, Facebook, Uber;
• princìpi di stile di scrittura: ad esempio The Economist;
• una implementazione di riferimento delle guide.

Alcuni esempi dei princìpi generali sono stati elencati nella sezione sui princìpi di design, le euristiche verranno citate nel capitolo sull'usabilità.

Design language

Il fine del design language è quello di massimizzare il rapporto fra informazione e complessità percettiva e cognitiva. Minimizzare la complessità visiva e cognitiva è fondamentale per aumentare l'usabilità e la percezione estetica dell'interfaccia, e per garantirne una buona fluenza.

Per minimizzare la complessità percettiva e cognitiva è opportuno adottare alcuni princìpi:

• corrispondenza fra la gerarchia logica e semantica dei contenuti e la gerarchia della rappresentazione visiva
• corrispondenza fra la vicinanza logica e semantica dei contenuti ed il layout grafico
• corrispondenza fra l'importanza delle informazioni e l'ordine di presentazione
• corrispondenza fra l'importanza focale delle informazioni e azioni e la loro salienza percettiva
• riduzione del carico informativo:
  • riduzione della quantità di elementi informativi o potenziali distrattori
  • riduzione della complessità e della lunghezza degli elementi testuali
• chiara definizione del contesto o dello scenario
• familiarità del layout e dello stile grafico
• consistenza grafica
• chiarezza nella segmentazione negli elementi e nei gruppi di elementi, nel rispetto della gerarchia semantica e logica dei contenuti
• utilizzo di linguaggio chiaro ed appropriato
• riduzione della complessità visiva attraverso l'adozione dei princìpi della gestalt
  • struttura gerarchica della rappresentazione
  • princìpio di prossimità
  • allineamento
  • ripetizione
  • contrasto

<!--

TODO integra:

The Stopping Power of Advertising: Measures and Effects ofVisual Complexity

Feature Complexity Advertisements that contain more detail and variation in their basic visual features, color, luminance, and edges are more complex

The Cognitive Science of Visual-Spatial Displays: Implications for Design questo mi pare molto, molto buono, anche se si riferisce alle rappresentazioni grafiche. Si potrà adattare?

Visualizing Thought molto molto buono anche questo, e non solo grafico Tversky: Visualizing thought - Google Scholar

Kimball: Visual design principles: An empirical study... - Google Scholar untitled download 55fa618708aec948c4a6559c.pdf Microsoft Word - ViewPoint_KaV.v4.doc untitled Microsoft Word - 3FBA4D82-578C-187EA9.doc Layout 1 icad2014_submission_12
Rosenholtz: Measuring visual clutter - Google Scholar Hegarty: The cognitive science of visual‐spatial... - Google Scholar Hegarty: The cognitive science of visual‐spatial... - Google Scholar Tversky: Visualizing thought - Google Scholar Visualizing Thought Measuring visual clutter | JOV | ARVO Journals The Cognitive Science of Visual‐Spatial Displays: Implications for Design

-->

Le funzioni dell'interfaccia

Proviamo ad elencare le funzionalità che un'interfaccia deve garantire, per permettere all'utente di interagire in maniera soddisfacente. Mi riferirò principalmente ad applicazioni web responsive, ma in linea generale il discorso vale anche per le applicazioni native.

Orientarsi

L'utente deve potersi orientare, capire cosa c'è intorno

• identificare l'identità dell'applicazione o del sito (attraverso logo ed eventualmente nome del dominio)
• identificare dove l'utente si trova, in quale parte dell'albero o del grafo in cui è strutturata la macro-architettura dell'applicazione;
• identificare la risorsa che sta visualizzando: il titolo della pagina o della vista;
• visualizzare gli elementi più salienti di quella pagina

Navigare

L'utente deve potersi muovere: navigare nei vari nodi della macro-architettura, attraverso un sistema di navigazione. Vanno dunque progettate:

• la navigazione globale, adattata per desktop (layout large) e per mobile (layout medium, small);
• la navigazione locale, contestuale, supplementare, di cortesia.

Cercare, trovare

In un sistema informativo ricco, non è affatto scontato che l'utente arrivi direttamente alla risorsa che gli interessa (magari arrivando da Google).
La navigazione offre all'utente la possibilità di muoversi, ma è indispensabile che egli possa trovare quello che sta cercando. Il motore di ricerca, seppur necessario, è solo uno degli strumenti che vanno messi a disposizione degli utenti. L'information design deve garantire un buon livello di information scent, per permettere di arrivare ai contenuti più importanti anche senza ricorrere al motore di ricerca.
In ogni caso, possono essere necessarie le seguenti funzionalità:

• motore di ricerca interno (e relativa interfaccia)
• quando opportuno (lista di elementi relativamente lunga) filtri di ricerca, navigazione a faccette

Visualizzare lo stato del sistema o di un oggetto

All'interno di un sistema informativo vi sono informazioni più statiche ed altre più dinamiche (il saldo del conto, le notifiche su Facebook, il ritardo del treno).

Se le informazioni dinamiche sono di rilevanza per l'utente, non solo devono essere facili da vedere ed attirare - in maniera appropriata - l'attenzione; se opportuno, è utile che siano le informazioni che vanno all'utente, ad esempio per mezzo di notifiche.

Pertanto, una delle funzioni dell'interfaccia è quella di:

• visualizzare lo stato del sistema o di un componente;
• rappresentare gli attributi dinamici più salienti del sistema o di un elemento;
• prevedere un servizio di notifiche per gli eventi più salienti per l'utente.

Prendere decisioni

Nelle numerose circostanze in cui l'esperienza d'uso implica un processo decisionale, è necessario che il sistema metta a disposizione quelle funzioni e quei servizi che possono facilitare il processo di scelta e di decisione:

• valutazioni e commenti di altri utenti;
• meccanismi che implementino e facilitino il processo decisionale, applicando automaticamente le principali euristiche: #choosability [^euroia11]

[^euroia11]: Si vedaDesigning Interactions that Help Customers in Decision Making.

Identificare un oggetto

Stabilire l'identità di un oggetto: il nome di una persona, il titolo di un libro, e così via. Se opportuno, presentare l'immagine dell'oggetto

Visualizzare le informazioni di un oggetto

Visualizzare le informazioni, sia le più importanti che, eventualmente, i dettagli:

• il prezzo di un prodotto
• la geo-localizzazione di un luogo
• le date di un evento

Agire: fare delle azioni

Nella progettazione di un servizio online vanno identificati i verbi della user experience, ed implementata l'interazione ad essi associata.

Le funzioni dispositive vanno rappresentate attraverso delle opportune call to action. Dev'essere pertanto chiaro all'utente se un link fa parte della navigazione o innesca una azione.
Queste funzioni, inoltre, generalmente richiedono all'utente di immettere dei dati. Oltre agli aspetti legati all'usabilità, e al rispetto delle linee guida, è opportuno attenersi al principio di chiedere all'utente solo le informazioni strettamente necessarie (oppure di permettere di inserire le informazioni facoltative in un secondo momento).

Fruire dei contenuti

Le persone vanno su internet per consumare di contenuti: testi, foto, video, film, musica, documenti, slide, ebook e quant'altro. Sono questi gli oggetti della user experience.

Ecco alcune regole che è bene seguire nella presentazione dei contenuti.

• se si adotta l'approccio ooux, ogni contenuto va concettualizzato come un oggetto: la foto, il video, il post e così via;
• se i contenuti dell'oggetto sono limitati, l'oggetto può essere rappresentato come un elemento in una lista; ad esempio i commenti brevi;
• generalmente però gli oggetti tendono ad essere ricchi di contenuti, di attributi, di relazioni; in questo caso, è necessario prevedere una pagina per ogni oggetto;

Nella rappresentazione degli oggetti è necessario permettere all'utente di

• identificare l'oggetto, l'eventuale tassonomia, gli attributi principali
• monitorare lo stato dell'oggetto, ed eventuali eventi ad esso associati
• presentare le funzioni e le azioni principali legati a quell'oggetto, attraverso le opportune affordance

Fornire delle informazioni

Spesso alcune funzioni delle applicazioni richiedono (o permettono) l'inserimento di informazioni.

In questo caso vanno stabilite le linee guida per le form e per l'input di dati in genere.

Produrre dei contenuti

Alcune applicazioni permettono di produrre dei contenuti: ad esempio i software per la gestione e creazione di blog.

Conclusioni

Le persone usano le applicazioni web e mobile per fare delle cose. Alcune di queste funzioni sono di supporto: navigare, orientarsi sono funzionali a fare qualcos'altro. Altre, sono funzioni primarie: fruire di contenuti, fare delle azioni.

L'importanza delle diverse funzioni

Il peso delle varie funzionalità varia a seconda dell'applicazione: per un sito di e-commerce le funzioni dispositive sono centrali; per un sito di informazione è prioritaria la fruizione dei contenuti. L'anatomia e le componenti dell'applicazione devono tener conto di queste peculiarità.

<!---

Il sito Bradfrost elenca diverse tipologie di linee guida:

• Brand Identity:
• Design Language
• Voce e tono
• Scrittura -->

La grammatica dell'applicazione

Nella grammatica cognitiva, i sostantivi corrispondono agli oggetti, gli aggettivi agli attributi degli oggetti, e i verbi alle attività (le funzioni). Sia gli oggetti che le funzioni sono divisi in base all'ontologia, e all'interno dell'ontologia sono sistematizzati in tassonomie.
Le linee guida devono prevedere un template per ogni classe dell'ontologia, sia degli oggetti, che delle funzioni. Inoltre, devono prevedere un template per i rami della tassonomia.

Dunque, per ogni classe dell'ontologia, è necessario prevedere un template per le istanze della classe (gli oggetti, le funzioni) ed un template index per i rami della tassonomia.
Inoltre, va previsto un template per la home page.

Le tipologie di pagine

Nella sezione dedicata alle ontologie, abbiamo definito i sostantivi del sistema informativo: gli oggetti dell'applicazione. I verbi del sistema corrispondono alle attività/funzioni; è necessario creare dei template anche per le funzioni, e per le azioni che si possono compiere sugli oggetti. Vanno poi creati dei template per le pagine indice, ovvero i rami dell'alberatura, della gerarchia tassonomica del sistema informativo. La home page è un caso particolare di pagina indice, e dunque merita un template a sé.

Tutti questi template si devono riferire ad una pagina generica, che può servire da base anche per quelle tipologie di schermate che non rientrano nei casi elencati.

Pagina oggetto

I template delle pagine oggetto corrispondono alle ontologie del sistema informativo.
In un sistema di e-commerce vi sono pagine oggetto per ogni prodotto. In un social network ci sono pagine oggetto per ogni persona. In un blog, le pagine oggetto per i post.

Nella pagina oggetto, il titolo corrisponde al nome dell'oggetto (il nome del prodotto, il nome della persona, il titolo del post).
Se appropriato, nella pagina oggetto viene mostrata l'immagine dell'oggetto (ad esempio, la fotografia del profilo, o del prodotto, o la copertina del libro, o dell'album).
Nella pagina oggetto sono rappresentate:

• le caratteristiche (gli attributi) dell'oggetto
• le componenti dell'oggetto (che possono essere, a loro volta, degli oggetti a se stanti)
• le relazioni con altri oggetti
• eventuali metodi dell'oggetto, ovvero funzioni ad esso associate.

Attributi, tassonomia, componenti, relazioni e metodi derivano dal processo di concettualizzazione e dalla creazione delle ontologie. Questi elementi vengono raggruppati in cluster, in base alla loro natura. Se molto numerosi, possono essere paginati, ad esempio con l'utilizzo di tab.
La rappresentazione di questi elementi dev'essere appropriata alla loro tipologia.

Pagina di profilo

La pagina di profilo è finalizzata a visualizzare ed eventualmente modificare le informazioni dell'utente loggato nell'applicazione

Pagine indice

Le pagine indice vengono utilizzate principalmente per rappresentare i rami delle tassonomie.
Nelle pagine indice vengono elencati, in base ad opportuni criteri, gli oggetti e le funzioni principali della sezione.

La home page è un caso particolare di pagina indice che, per la sua importanza, viene progettata specificamente.

Rappresentazione delle attività

Le attività rappresentano la concettualizzazione di quelle funzionalità che permettono all'utente di agire. Nella definizione di una attività vanno considerati:

• gli attori coinvolti
• le motivazioni (gli scopi, i bisogni)
• il contesto
• le circostanze che innescano l'attività e la rendono possibile
• le regole e le norme a cui l'attività è vincolata
• le risorse necessarie
• il processo secondo cui l'attività si svolge.

Attività: progettare il processo

Più in particolare, nel processo vanno stabiliti:

• i vari passaggi: i compiti / task necessari per portare a termine l'attività;
• i sottopassaggi, in una rappresentazione ad albero
• i vincoli logici
• la sequenza, guidata dall'albero dei task, dai vincoli logici, dalla consuetudine
• la possibilità di parallelizzare alcuni task, o di permettere agli attori di scegliere sequenze diverse, nel rispetto dei vincoli logici

La rappresentazione delle attività/azioni più semplici (task elementari) può avvenire attraverso delle micro-interazioni;

• nei task più complessi la rappresentazione dei passaggi principali può avvenire attraverso il pattern wizard, dove ad ogni passaggio corrisponde una schermata / pagina;
• i compiti a complessità intermedia possono essere rappresentati nel contesto di un'unica pagina.

La rappresentazione deve implementare - e rendere espliciti - i vincoli logici, attraverso opportuni vincoli di interazione: non puoi iniziare il passaggio b finché non hai completato il passaggio a; deve inoltre rendere esplicite le circostanze in cui questi vincoli non ci sono, permettendo all'utente - per quanto possibile - di personalizzare la sequenza.

Attività: linee guida

Nella rappresentazione delle attività è utile che l'utente:

• possa avere una visione di insieme della attività e del processo (ad esempio rendendo espliciti i passaggi)
• abbia chiare le circostanze, le risorse richieste, le regole
• sia chiara l'eventuale divisione dei compiti con altri attori
• possa essere guidato nelle attività più complesse
• al termine dell'attività, abbia la possibilità di verificare il processo, le azioni intraprese, le scelte e le informazioni fornite, e di confermare o correggere
• quando possibile, possa interrompere una attività e riprenderla in seguito

Nelle circostanze in cui è importante mantenere esplicito il contesto in cui l'attività si innesca, può essere opportuno gestire il processo all'interno di una finestra modale sopra alla schermata del contesto iniziale. Questa soluzione è però sconsigliata se l'attività ed il processo sottostante risultano piuttosto complessi.

<!-- TODO eliminare?

Template di funzione (multipagina)

I template di funzione costituiscono l'interfaccia finalizzata a permettere all'utente di portare a termine un compito. Se il compito è complesso, o se è necessario fornire all'utente dei passaggi di verifica e di conferma, la funzione evolve su più pagine.

Spesso una funzione si sviluppa in tre passaggi:

• nel primo vengono richiesti i dati all'utente
• nel secondo i dati raccolti vengono presentati all'utente, e si chiede conferma
• nel terzo l'azione è stata compiuta, e si da conferma all'utente, guidandolo verso eventuali passaggi successivi.

Vanno previste delle varianti a questo schema, in base a particolari condizioni:

• se non è previsto nessun input, si può saltare il passaggio 1, e chiedere direttamente conferma
• se l'operazione è reversibile, o se l'azione ha effetti limitati, può essere ragionevole saltare il passaggio due
• se i dati da immettere sono molti, è possibile scomporre il primo passaggio in più sottopassaggi

-->

Anatomia della pagina

Come abbiamo detto, interfaccia deve permettere all'utente di orientarsi, di navigare, di cercare, di scegliere, di identificare un oggetto (o una funzione), di visualizzarne le informazioni, di visualizzare lo stato del sistema, di fruire o creare dei contenuti, di inserire delle informazioni, di fare delle azioni.

L'anatomia della pagina (o della schermata) deve permettere tutte queste cose. Per questo motivo è utile la presenza di diverse componenti:

• l'intestazione generale permette di orientarsi
• la navigazione permette di muoversi
• l'intestazione contestuale di identificare un oggetto (o una attività) e visualizzarne lo stato
• l'area dei contenuti permette di consumare o produrre contenuti.

Nei paragrafi seguenti esporrò una traccia di linee guida per le varie sezioni, con le mie proposte in merito ai contenuti. Natuarlmente, è possibile fare delle scelte diverse.

iOS Human Interface Guidelines: iOS App Anatomy

Intestazione globale

È l'intestazione che rimane invariata per tutta l'applicazione. Contiene

• il logo ed eventualmente il titolo dell'applicazione o del sito (generalmente a sinistra)
• se l'applicazione prevede registrazione o login:
  • i bottoni di registrazione e login se utente non loggato;
  • nome e cognome, eventualmente preceduto da avatar, dell'utente; se previsto, avatar+nome+cognome linkano al profilo
• se previsto, l'input per il motore di ricerca
• eventuali link / icone a sezioni cross-applicazione
• se prevista una sezione di personalizzazione distinta dal profilo, l'icona di personalizzazione delle opzioni
• se previsto, l'eventuale bottone di logout (generalmente a destra)

Navigazione

Menu

Nella versione large, si consiglia il menu è orizzontale, con non più di 5 voci. Il menu è nella forma megadropdown, ed ogni sezione ha non più di 5 colonne. Il menu può contenere delle immagini

Nella versione medium-small, il menu è in forma off-canvas. Di default, le voci del menu non hanno sottomenu, ma al click l'utente viene portato nella pagina indice di sezione

Intestazione contestuale

L'intestazione contestuale si riferisce alla specifica schermata, e dunque non è comune all'intera applicazione.

In questa sezione vanno definite

• briciole di pane (nella versione small possono essere omesse)
• Titolo della pagina, con, eventualmente, icona di help
• Eventuale sottotitolo
• Eventuale messaggio di errore, warning o comunicazione
• Eventuale sommario
• Nelle pagine funzione, i passaggi (es sei allo step 1 di 3: inserisci)

Contenuti

L'area per i contenuti veri e propri della schermata. Generalmente quest'area è divisa in sezioni. I contenuti di questa pagina variano a seconda della tipologia:

• nella pagina oggetto, contiene i dettagli dell'oggetto o i contenuti;
• nelle pagine funzione, i contenuti dei vari passaggi: il data entry, il testo di verifica, il testo di conferma;
• nelle pagine indice, la lista di oggetti (o funzioni) elencati.

Footer

Nel footer vengono generalmente inseriti i seguenti elementi:

• legalese (copyright, privacy policy, termini e condizioni)
• navigazione (sitemap)
• contatti (link a pagina, e-mail, telefono, indirizzo fisico)
• link e icone social
• logo e elementi di branding
• mission, valori

fonte: Website Footer Design Best Practices: 27 Things to Put at the Bottom - Orbit Media Studios

Le sezioni

Nelle pagine ricche di contenuti, è opportuno raggruppare questi contenuti in sezioni. Nel codice html5 può essere opportuno usare il tag section, oppure utilizzare i tab.

Insiemi di oggetti

Nel sistema informativo è spesso necessario rappresentare degli insiemi di oggetti: tipicamente nelle pagine indice, che sono esplicitamente degli insiemi di oggetti, ma anche nelle quando i componenti di un oggetto sono innumerevoli (ovvero, il loro numero non può essere stabilito a priori). In questo caso, vanno previsti degli elenchi. Possiamo immaginare:

• elenchi in forma tabellare
• elenchi in forma di liste
• wall di elementi in formato card, utilizzando pattern di layout come masonry/ metro.

Nel caso di tabelle, ogni elemento è rappresentato come riga della tabella. Nel caso delle liste, gli elementi sono i tiles, ovvero brevi unità informative fra loro omogenee all'interno della lista. Il wall è formato da cards.

<!-- A card is a piece of paper with unique related data that serves as an entry point to more detailed information. For example, a card could contain a photo, text, and a link about a single subject. Cards have a constant width and variable height. See also Why cards are the future of the web

La forma tabellare è particolarmente indicata se le righe possono essere ordinate o filtrate su differenti colonne, o se l'utente deve poter confrontare i vari elementi su differenti colonne.

see also semantic zoom

Cards

(andrà spostato sotto?) Esempio particolare di cards: sitepoint. Ha anche un articolo su Card Tricks: Using Cards in Web Design Layouts

-->

Elementi dell'interfaccia

iOS Human Interface Guidelines: Bars

Controlli dell'interazione

UX guidelines for controls and patterns - Windows app development

Testo

Elementi testuali. Vanno rappresentati con il tag <p>. Se il testo è particolarmente lungo, può essere troncato, e viene aggiunto un link. Il link può fungere da accordion, per ampliare il testo nella pagina, o linkare ad una pagina a se, con il testo completo.

Esempi tipici: commenti o recensioni, descrizione di prodotti, corpo del testo di un post.

Oggetti componenti

Spesso, gli elementi delle pagine sono essi stessi degli oggetti.
Talvolta, sono micro-oggetti la cui esistenza ha senso soltanto all'interno della pagina in cui sono rappresentati.
In altre circostanze, sono oggetti veri e propri. In questo caso viene rappresentata una sintesi dell'oggetto (titolo/nome, poche info), ed un link alla pagina dell'oggetto specifico.

Esempi tipici: avatar dei commenti o dei like, prodotti correlati, thumbnail di immagini, video.

Form

Nelle pagine di funzione, generalmente, è necessario il data-entry degli utenti.

Euristiche generali

• minimizzare la quantità di dati richiesti all'utente
• distinguere chiaramente i campi obbligatori da quelli facoltativi;
• se il numero di campi è superiore a 5, 6, valutare la possibilità di raggruppare i campi in insiemi significativi usando strumenti come <fieldest> ed etichettando i gruppi con il tag <legend>.

Va prevista la possibilità di aggiungere un alert all'inizio della form per notificare eventuali errori non specifici dei singoli campi, o per elencare gli errori nei campi.

Campi

Ad ogni campo di input va associata una etichetta (<label>), posizionata immediatamente sopra al campo.
Va prevista la possibilità di aggiungere un alert sotto al campo per notificare eventuali errori relativi a quel campo. In caso di modifica di valori già esistenti, o qualora possa essere ragionevolmente previsto un valore di default, quel valore può essere precompilato (attributo value). Se non è presente il valore di default, può essere inserito un placeholder (attributo placeholder) per dare ulteriori, brevi informazioni sul campo.

Nei campi in cui si prevede la scelta fra una di numerose opzioni, se le opzioni sono meno di 4 è consigliato l'uso dei radiobutton. Fra 4 e 10 opzioni, è consigliato l'uso del dropdown. Se le opzioni sono più di dieci (esempio: elenco delle province d'Italia, o comuni in una provincia), è consigliato l'uso di un dropdown con filtro di ricerca. Qualora la lista delle opzioni non sia predeterminata a priori (ad esempio indirizzi e-mail, tag) è consigliato l'uso del live search.

Bottoni

I bottoni vengono messi alla fine della form, a destra. Se vi sono più bottoni (tipicamente avanti/continua/conferma, indietro/correggi e annulla) il bottone principale va collocato a destra, con un colore che lo distingua dagli altri. Tipicamente l'ordine è annulla, indietro/correggi, avanti/continua/conferma.

I bottoni vengono utilizzati esclusivamente nelle form, e non come link a pagine o sezioni dell'applicazione.

Input di date

Per le date è opportuno usare l'attributo date del campo di input. Eventualmente, utilizzare un widget javascript per personalizzare il data entry.

Filtri

I filtri vengono utilizzati con le tabelle o, eventualmente, con le liste.
I filtri possono essere multipli, ovvero filtrare l'elenco su più faccette.
È vivamente raccomandato che le dimensioni filtrabili siano rappresentate in tabella come colonna. Ad esempio, se filtro per data, dev'essere presente almeno una (e possibilmente soltanto una) colonna data. La corrispondenza fra il filtro e la colonna dev'essere semanticamente esplicita. È vivamente raccomandato l'uso di filtri a selezione singola. I filtri a selezione multipla vanno utilizzati solo se non è ragionevolmente possibile farne a meno. Generalmente, il valore di default è la selezione non filtrata. È però possibile impostare di default una opzione del filtro.
Il filtro può essere un range di valori da - a (ad esempio un range di date, o di importi).
Se si sta progettando un sito responsive, i filtri vanno posizionati, in orizzontale, sopra la tabella filtrata.
L'etichetta del filtro corrisponde alla selezione impostata. In questo modo l'utente ha la possibilità di ricordare/vedere cosa sta filtrando.

Qualora le opzioni del filtro non siano determinabili a priori, viene utilizzato un campo di input testuale con una icona lente, cliccabile; il campo deve prevedere la funzione di live search: a seguito dell'immissione di almeno 3 caratteri, vengono presentati fino a 5 risultati, cliccabili. Il filtro viene attivato al click di uno dei risultati, o al click dell'icona lente, o alla pressione del tasto invio.
Una volta selezionato il filtro, scompare il campo di input e appare il valore del filtro, ed una icona x, cliccabile, per cancellare il filtro.

Risorse utili

Website Style Guide Resources è un elenco di risorse sulle style guide

Atomic Design | Brad Frost introduce il concetto di Atomic Design.

How to create beautiful style guides online | DesignHooks

29 Well-Designed Online Style Guides - Web Design Ledger

UI Style Guides | Experience Dynamics

50 Meticulous Style Guides Every Startup Should See Before Launching – Design School