{"id":644,"date":"2016-08-10T20:11:13","date_gmt":"2016-08-10T18:11:13","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/framework\/"},"modified":"2016-08-10T20:11:13","modified_gmt":"2016-08-10T18:11:13","slug":"framework","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/framework\/","title":{"rendered":"Framework"},"content":{"rendered":"
\n

Note degli editori:<\/strong> Siamo lieti di condividere un estratto dal Capitolo 5 del nuovo libro di Ethan Marcotte Responsive Design: Patterns & Principles<\/cite>, disponibile ora su A Book Apart<\/a>.<\/p>\n<\/div>\n

\n

Nel corso degli ultimi anni, abbiamo imparato come adattare i nostri layout alle infinite tele del web. I nostri design possono essere visualizzati su schermi di ogni dimensione, in ogni momento e il responsive design \u00e8 un approccio che ci permette di gestire le forme variabili del web. Ma con tutte le sfide che stiamo affrontando e con quelle che verranno, dobbiamo cominciare a creare non solo dei pattern, ma dei principi<\/em> per il responsive design, principi che ci permetteranno di concentrarsi non solo sul layout, ma sulla qualit\u00e0 del nostro lavoro.<\/p>\n

Se ciascuna parte della nostra interfaccia responsive \u00e8 pi\u00f9 o meno autonoma, con le sue regole di layout, bisogni del contenuto e breakpoint, allora il codice dietro al design di ciascun elemento \u00e8 molto meno importante del pensare attentamente al come<\/em> e al perch\u00e9<\/em> si dovrebbe adattare un elemento. In altre parole, in che modo possiamo andare oltre il modo di ragionare in colonne e righe e cominciare a parlare della qualit\u00e0 dei nostri design responsive? E come dovrebbero essere i framework che supportano tutto questo?<\/p>\n<\/div>\n

\n

Trovare le parole<\/h2>\n

Onestamente, non c’\u00e8 una risposta perfetta a questa domanda, ma, recentemente, un certo numero di designer e aziende hanno cominciato a condividere il vocabolario che usano per decidere in che modo e quando debbano adattare i propri design responsive. Per esempio, Vox Media pensa che il proprio contenuto esista all’interno di un fiume e, portando avanti la metafora, lo scorrere di tale contenuto possa essere interrotto in alcuni punti. Ecco come descrivono la front page di Vox.com<\/a>:<\/p>\n

Il contenuto scorre attorno a delle \u201crocce\u201d in \u201condate\u201d, che sono moduli come potrebbe esserlo un elenco \u201cMost Commented\u201d o una riga di \u201cPopular Videos\u201d. Molti di questi comportamenti rimangono nel nuovo layout del sistema, ma la differenza principale \u00e8 il livello di contesto aggiunto. Gli elementi nel fiume sono disposti in maniera da sottolineare meglio la diversit\u00e0 di contenuti su Vox: articoli, features, video, app editoriali, card stacks, giusto per nominarne alcuni. Ciascuno di questi viene mostrato in maniera diversa a seconda del suo tipo e dei contributi vicini.<\/p><\/blockquote>\n

Notate come il linguaggio che usano per parlare della qualit\u00e0 dei loro layout non ruota attorno a colonne o righe. Non c’\u00e8 nemmeno una menzione alle griglie. Per Vox, il processo di design comincia con il dare priorit\u00e0 al contenuto ed evolve in un layout. Comprendendo il peso e l’importanza di ciascuna parte del contenuto che scorre nel fiume, il team di Vox pu\u00f2 generare algoritmicamente un layout responsive che riflette l’importanza dell’informazione al suo interno.<\/p>\n

Cominciare con un sistema astratto di colonne e righe sarebbe sbagliato per loro e, direi, per tutti i web designer. Dopo tutto, secondo Mark Boulton<\/a>, ci sono tre benefici fondamentali in un grid system:<\/p>\n