{"id":638,"date":"2016-07-11T15:00:43","date_gmt":"2016-07-11T13:00:43","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/dalle-pagine-ai-pattern-un-esercizio-per-tutti\/"},"modified":"2016-07-11T15:00:43","modified_gmt":"2016-07-11T13:00:43","slug":"dalle-pagine-ai-pattern-un-esercizio-per-tutti","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/dalle-pagine-ai-pattern-un-esercizio-per-tutti\/","title":{"rendered":"Dalle pagine ai pattern: un esercizio per tutti"},"content":{"rendered":"
\n

Il linguaggio definisce la vita dei componenti. Un \u201cpulsante blu\u201d funzioner\u00e0 finch\u00e9 il pulsante non sar\u00e0 pi\u00f9 blu e quindi il nome non avr\u00e0 pi\u00f9 senso. Il pattern non avr\u00e0 ragione di esistere se non si usano pi\u00f9 i pulsanti blu. Un componente con il nome \u201cpulsante\u201d, tuttavia, vivr\u00e0 una vita pi\u00f9 lunga e proficua, anche se le sue propriet\u00e0 cambieranno. Perch\u00e9? Per il suo nome descrive la sua funzione<\/em>, non il suo aspetto.<\/p>\n

Come molti di noi sanno fin troppo bene, assegnare nomi \u00e8 difficile, ma \u00e8 la chiave per creare un sistema robusto e implica il lasciarsi indietro alcuni modi di pensare molto radicati.<\/p>\n<\/div>\n

\n

Pensare in pagine (ancora)<\/h2>\n

Anche quando il deliverable finale \u00e8 una pattern library, i clienti si aspettano ancora di dare il consenso su design di pagina. Al loro passaggio tra i vari team e manager per l’approvazione, le pagine vengono ovviamente discusse: prima che ve ne rendiate conto, diventano Home page, Listing page, Product page e cos\u00ec via. Tutti pensano in termini di pagine, quindi pu\u00f2 sembrare naturale che il design dei componenti e il design della pagina viaggino in tandem, ma, creare componenti dai design della pagina \u00e8 come partire dall’esterno e lavorare verso l’interno – pu\u00f2 diventare complicato.<\/p>\n

In Clearleft<\/a>, la sfida di sviluppare simultaneamente pagine e componenti \u00e8 diventata particolarmente evidente in alcuni nostri progetti recenti, dove, invece di fornire ai nostri clienti delle pattern library complete, ci \u00e8 stato chiesto di collaborare con un team di designer e developer in-house per aiutarli a crearne e mantenerne una loro. In un’occasione, come esercizio, abbiamo passato alcune settimane a concentrarci sulla UX e UI con un team prima di chiedere loro di assegnare un nome e di programmare i componenti a partire dai design. Stavamo lavorando con il design di una pagina prodotto con del contenuto relativo al prodotto in ogni componente. Il primo componente che abbiamo costruito aveva l’aspetto di una card, quindi tutti l’abbiamo chiamato \u201cproduct card\u201d. Abbiamo continuato l’esercizio per diversi componenti con risultati simili.<\/p>\n

Ora, \u00e8 fantastico che le persone se ne escano con suggerimenti unanimi, ma riuscite a vedere il problema di questa struttura di naming? Cosa succede se il componente viene spostato in un’altra pagina o viene popolato con del contenuto diverso? Potreste anche pensare alla product card come a una \u201cprofile card\u201d o a una \u201clocation card\u201d. Potrebbe essere riutilizzata per una variet\u00e0 di scopi diversi. Il nome \u201ccard\u201d potrebbe essere pi\u00f9 semplice e molto pi\u00f9 versatile.<\/p>\n<\/div>\n

\n

Dalle pagine ai pattern<\/h2>\n

Per aiutare gli altri ad adottare il pattern thinking, abbiamo creato un esercizio per chiunque sia coinvolto nella pattern library. Non \u00e8 solo per i developer e i designer: dovrebbe parteciparvi chiunque debba prendere una decisione nella creazione della pattern library. Lo scopo \u00e8 di far s\u00ec che tutti pensino ai pattern a livello granulare, rimuovendo qualunque contesto attorno a ciascun componente. Inoltre, incoraggia ad avere un vocabolario condiviso.<\/p>\n

Tutto quello che vi serve sono dei visual design di pagine e componenti (possono essere una qualunque cosa dalla prima bozza fino ai design finali) e i seguenti oggetti:<\/p>\n