{"id":614,"date":"2016-05-11T11:09:20","date_gmt":"2016-05-11T09:09:20","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/pensare-in-maniera-responsive-framework-per-apprendimento-futuro\/"},"modified":"2016-05-11T11:09:20","modified_gmt":"2016-05-11T09:09:20","slug":"pensare-in-maniera-responsive-framework-per-apprendimento-futuro","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/pensare-in-maniera-responsive-framework-per-apprendimento-futuro\/","title":{"rendered":"Pensare in maniera responsive: un framework per l&#8217;apprendimento futuro"},"content":{"rendered":"<div class=\"paragrafo\">\n<p>Prima dell&#8217;arrivo degli smartphone e dei tablet, molti di noi avevano assunto una posizione di beata ignoranza. Credendo di poter domare l&#8217;imprevedibilit\u00e0 intrinseca del web, abbiamo fatto delle assunzioni sui requisiti per il suo accesso, dando priorit\u00e0 ai nostri bisogni prima che a quelli dell&#8217;utente.<\/p>\n<p>Proprio quando le nostre supposizioni diventavano pi\u00f9 dettagliate, il responsive web design ha mostrato una via d&#8217;uscita. Oltre ad offrire i mezzi per creare layout indipendenti dai device, RWD ha dato il via a un periodo di riconsiderazioni: era dall&#8217;adozione degli standard web che il nostro settore non vedeva un riallineamento cos\u00ec radicale di teoria e pratica.<\/p>\n<p>Nei cinque anni da quando l&#8217;<a href=\"http:\/\/alistapart.com\/article\/responsive-web-design\">articolo di Ethan Marcotte<\/a> \u00e8 apparso la prima volta su queste pagine, migliaia di siti web sono stati lanciati con un layout responsive come loro centro. Durante questo periodo, abbiamo sperimentato con nuovi modi di lavorare e abbiamo ridefinito la nostra pratica di design e sviluppo cos\u00ec che sia pi\u00f9 adatta ad un medium fluido e disordinato.<\/p>\n<p>Mentre emergiamo da questo periodo illuminato, abbiamo bisogno di consolidare la nostra cultura e di considerare come andare avanti costruendo su questa base.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Un framework responsive<\/h2>\n<p>Quando pensiamo ai framework, spesso immaginiamo librerie di software e altre astrazioni riguardanti l&#8217;esecuzione e il codice. Ma questo tipo di framework ci allontana dalle difficolt\u00e0 che ci troviamo di fronte quando progettiamo per il medium. L&#8217;anno scorso, quando <a href=\"https:\/\/vimeo.com\/106869929\">Ethan ha parlato della necessit\u00e0 di un framework<\/a>, ne ha proposto uno focalizzato sul nostro approccio: un framework per aiutarci a modellare la discussione in corso e per misurare la qualit\u00e0 e l&#8217;adeguatezza del nostro lavoro.<\/p>\n<p>Credo che possiamo ideare questo framework mettendoci prima d&#8217;accordo su un insieme di principi di design sottostanti. Il concetto potrebbe esservi familiare. Organizzazioni come <a href=\"https:\/\/www.gov.uk\/design-principles\">GOV.UK<\/a> e <a href=\"http:\/\/www.google.com\/about\/company\/philosophy\/\">Google<\/a> li usano per definire le caratteristiche dei loro prodotti e perfino delle loro organizzazioni. <a href=\"http:\/\/web.archive.org\/web\/20100318024044\/http:\/\/www.adaptivepath.com\/ideas\/essays\/archives\/001123.php\">Kate Rutter descrive i principi di design<\/a> come:<\/p>\n<blockquote><p>\u2026brevi frasi intelligenti che fungono da luci guida e supportano lo sviluppo di grandi esperienze di prodotto. I principi di design vi permettono di essere fedeli ai vostri utenti e leali verso la vostra <b>strategia a lungo termine<\/b> (l&#8217;enfasi \u00e8 mia).<\/p><\/blockquote>\n<p><a href=\"https:\/\/adactio.com\/journal\/1716\">La strategia a lungo termine del web \u00e8 di permettere l&#8217;accesso universale<\/a> alle informazioni e ai servizi. Questo nobile obiettivo \u00e8 fondamentale per l&#8217;importanza continua del web. I nostri principi di design devono operare a servizio di questa visione, gestendo:<\/p>\n<ul>\n<li><b>i nostri utenti:<\/b> possiamo raggiungere una portata pi\u00f9 ampia creando dei team inclusivi che ascoltano gli utenti e ci lavorano perfino assieme.<\/li>\n<li><b>il nostro medium:<\/b> possiamo creare prodotti pi\u00f9 adattabili facendo meno assunzioni sul contesto e sull&#8217;interfaccia, concentrandoci di pi\u00f9 sui task e sugli obiettivi degli utenti.<\/li>\n<li><b>Noi stessi:<\/b> possiamo ottenere una maggior collaborazione all&#8217;interno dei team scegliendo strumenti che siano accessibili, semplici da usare e aperti al cambiamento.<\/li>\n<\/ul>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Rispecchiare la diversit\u00e0 nella pratica<\/h2>\n<p>Pu\u00f2 essere avventato tentare di categorizzare le caratteristiche comuni dei device con accesso al web mentre se ne esamina il panorama. Sebbene a volte questa ampiezza e fluidit\u00e0 possano risultare frustranti, la frammentazione dei device \u00e8 solo un riflesso della diversit\u00e0 umana e dei clienti che esercitano il proprio diritto a scegliere.<\/p>\n<p>Fino a poco tempo fa, l&#8217;empatia verso i consumatori era largamente dominio dei designer e dei ricercatori di user experience. Tuttavia, sebbene un&#8217;interfaccia utente mal progettata possa influenzare negativamente l&#8217;usabilit\u00e0 di un sito, allo stesso modo possono farlo le scelte tecnologiche sbagliate. Dobbiamo tutti tenere presente le nostre responsabilit\u00e0 sul nostro lavoro, perch\u00e9 possono influenzare l&#8217;esperienza risultante.<\/p>\n<h3>Il design per tutti<\/h3>\n<p>Il <a href=\"http:\/\/www.ncsu.edu\/ncsu\/design\/cud\/about_ud\/udprinciplestext.htm\">design universale<\/a> promuove la creazione di prodotti utilizzabili da tutti indipendentemente dall&#8217;et\u00e0, abilit\u00e0 o status. Mentre queste idee godono di un riconoscimento maggiore tra gli architetti e i product designer, sono altrettanto rilevanti nella nostra professione.<\/p>\n<p>Considerate gli utensili da cucina OXO Good Grips. Nel 1989, Sam Farber, ispirato dall&#8217;artrite di sua moglie, <a href=\"http:\/\/smartdesignworldwide.com\/work\/oxo-good-grips\/\">riprogett\u00f2 il convenzionale pela-verdure<\/a>, sostituendo i manici di metallo con impugnature pi\u00f9 morbide. Ora tutti, indipendentemente dalle abilit\u00e0 manuali e dalla forza, possono usare questo strumento e la considerazione di Farber per l&#8217;estetica ha assicurato anche un maggior appeal per tutti. Il suo approccio \u00e8 stato applicato a un range di prodotti: Good Grips \u00e8 diventato un marchio premiato e internazionalmente riconosciuto, mentre l&#8217;azienda di Farber, OXO, ha continuato a generare vendite significative.<\/p>\n<p>Questo lavoro ha reso molto popolare il concetto design inclusivo. <a href=\"http:\/\/www.oxo.com\/UniversalDesign.aspx\">OXO rimane un sostenitore<\/a> del design di prodotti intrinsecamente accessibili, sottolineando che:<\/p>\n<blockquote>\n<p>Quando tutti i bisogni degli utenti sono stati presi in considerazione nel processo iniziale di design, il risultato \u00e8 un prodotto che pu\u00f2 essere usato dallo spettro pi\u00f9 ampio di utenti. Nel caso di OXO, significa progettare prodotti per giovani e vecchi, maschi e femmine, mancini e destrorsi e per molti con bisogni speciali.<\/p>\n<\/blockquote>\n<p>Molte delle tecnologie e specifiche che usiamo hanno gi\u00e0 adottato degli aspetti del design universale. Oltre alle specifiche come WAI-ARIA, che aumenta l&#8217;accessibilit\u00e0 delle interfacce dinamiche, HTML include da tempo delle feature di accessibilit\u00e0 di base: l&#8217;attributo <code>alt<\/code> permette agli autori di aggiungere un testo alternativo alle immagini, mentre l&#8217;elemento <code>object<\/code> permette di fornire del contenuto di feedback se non \u00e8 disponibile un particolare media plug-in o codec.<\/p>\n<p>Si possono trovare altri esempi anche all&#8217;interno del W3C e del WHATWG. Un principio chiave utilizzato nel design di HTML5 riguarda il modo in cui gli autori dovrebbero valutare aggiunte o cambiamenti alla specifica. Detto <a href=\"http:\/\/dev.w3.org\/html5\/html-design-principles\/#priority-of-constituencies\">priority of constituencies<\/a>, dichiara che:<\/p>\n<blockquote>\n<p>In caso di conflitto, considerate gli utenti poi gli autori poi gli implementatori poi gli specifiers poi la purezza teorica.<\/p>\n<\/blockquote>\n<p>Possiamo usare questa assegnazione delle priorit\u00e0 quando prendiamo le decisioni nei nostri progetti. Sebbene un framework MVC client-side potrebbe fornire una certa comodit\u00e0 allo sviluppatore, se questo implica che gli utenti debbano scaricare un grosso file JavaScript prima di poter accedere all&#8217;applicazione, allora dovremmo cercare un approccio alternativo.<\/p>\n<h3>Trovare un compromesso<\/h3>\n<p>Pu\u00f2 essere difficile per i makers, attaccati a display ad alta risoluzione e con connessioni broadband super veloci, visualizzare l&#8217;esperienza vissuta dagli utenti usando il prodotto finale su un mobile device con poca batteria e una rete cellulare inaffidabile. Pi\u00f9 \u00e8 largo il divario tra coloro i quali creano un prodotto e quelli che lo usano, pi\u00f9 sar\u00e0 probabile che i primi facciano scelte sbagliate. Dobbiamo assegnare delle priorit\u00e0 pi\u00f9 vicine ai nostri utenti.<\/p>\n<p>La user research e i test di usabilit\u00e0 ci aiutano a vedere in che modo gli utenti interagiscono con i nostri prodotti. Far partecipare diverse discipline (developer, interface e content designer, product manager) pu\u00f2 assicurare che questo insegnamento sia ampiamente condiviso, ma possiamo sempre fare di meglio. <a href=\"http:\/\/alistapart.com\/blog\/post\/developing-empathy\">Susan Robertson recentemente ha scritto<\/a> su come passare una settimana a rispondere alle email di supporto le abbia dato una nuova conoscenza del modo in cui i clienti stavano usando l&#8217;applicazione che stava creando:<\/p>\n<blockquote><p>Gli utenti diventano persone con un nome, piuttosto che persone senza identit\u00e0 che scrivono su una tastiera, e vogliono usare quello che state contribuendo a creare.<\/p><\/blockquote>\n<p>Rendere l&#8217;intero team responsabile collettivamente dell&#8217;esperienza finale significa che le considerazioni di usabilit\u00e0 e accessibilit\u00e0 rimarranno attributi chiave del prodotto finale, ma cosa succede se il team \u00e8 anche pi\u00f9 inclusivo? Nel suo articolo \u201c<a href=\"http:\/\/alistapart.com\/article\/universal-design-irl\">Universal Design IRL<\/a>\u201d, Sara Wachter-Boettcher fa notare che:<\/p>\n<blockquote>\n<p>Il modo migliore per comprendere il pubblico per cui progettiamo \u00e8 di conoscere tale pubblico. E il miglior modo per conoscere le persone \u00e8 di averle proprio accanto a noi, con tutte le loro differenze di prospettive e background e, ovviamente, anche  di et\u00e0, genere, razza e lingua.<\/p>\n<\/blockquote>\n<p>Forse non \u00e8 una coincidenza che da quando stiamo imparando della diversit\u00e0 dei nostri clienti, abbiamo cominciato a riconoscere la mancanza di diversit\u00e0 all&#8217;interno del nostro settore. Battendoci per fare in modo di rispecchiare il mondo reale, possiamo creare team pi\u00f9 empatici ed efficaci e, di conseguenza, prodotti migliori.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Costruire su fondamenta flessibili<\/h2>\n<p>Empatizzando con gli utenti, possiamo fare scelte migliori. Tuttavia, le decisioni risultanti dovranno viaggiare su reti inaffidabili prima di essere utilizzate da vari device dalle caratteristiche sconosciute. \u00c8 difficile prendere decisioni se non si \u00e8 in grado di prevedere i risultati.<\/p>\n<p>Osservando i siti web con lenti diverse, possiamo scoprire aree limite che offrono un maggior grado di possibilit\u00e0 e adattabilit\u00e0. Se un&#8217;interfaccia funziona su un device mobile, funzioner\u00e0 anche su un display pi\u00f9 grande. Se si possono consultare i dati quando non c&#8217;\u00e8 rete, una connessione non affidabile sar\u00e0 un piccolo intralcio. Se il contenuto forma la base del nostro design, l&#8217;informazione sar\u00e0 disponibile indipendentemente dagli stili. Le ottimizzazioni basate su assunzioni pi\u00f9 incerte possono essere aggiunte dopo, sicuri del fatto che abbiamo fornito dei fallback.<\/p>\n<h3>Interface first<\/h3>\n<p>Nel 2009, Luke Wroblewski ci ha chiesto di considerare in che modo le interfacce potrebbero trarre vantaggio dalle capacit\u00e0 dei device mobile <em>prima<\/em> di pensare alla loro manifestazione nei browser desktop. Il <a href=\"http:\/\/www.lukew.com\/ff\/entry.asp?933\">mobile-first thinking<\/a> ci invita a concentrare: gli schermi dei telefoni hanno poco spazio per interfacce e contenuti non pertinenti, quindi dobbiamo sapere cosa ha pi\u00f9 importanza. Facendo domande su quali parti di un&#8217;interfaccia siano critiche e quali non lo siano, possiamo decidere se queste parti non-critiche sono caricate in maniera condizionale o \u201clazily\u201d o addirittura non caricate del tutto.<\/p>\n<h3>Network first<\/h3>\n<p>Nel 2013, considerando le realt\u00e0 dell&#8217;affidabilit\u00e0 della rete, Alex Feyerke propose un approccio <a href=\"http:\/\/alistapart.com\/article\/offline-first\">offline-first<\/a>. Piuttosto che trattare l&#8217;accesso offline come un caso limite, possiamo creare esperienze senza soluzione di continuit\u00e0 che funzionano indipendentemente dalla connettivit\u00e0, scaricando preventivamente gli asset e sincronizzando i dati quando si \u00e8 online, e usando l&#8217;aggressive caching e la computazione lato cliente quando non si \u00e8 online. Altri hanno suggerito di cominciare con gli URL o con un approccio <a href=\"http:\/\/www.api-first.com\/\">API-first<\/a>, usando queste lenti per pensare a dove vive il contenuto all&#8217;interno di un sistema. Ogni approccio adotta la struttura sottostante del web per aiutarci a creare prodotti pi\u00f9 robusti e flessibili.<\/p>\n<h3>Content first<\/h3>\n<p>Nel 2011, <a href=\"http:\/\/www.markboulton.co.uk\/journal\/a-richer-canvas\">Mark Boulton ha segnalato<\/a> uno spostamento dal nostro approccio <em>canvas in<\/em> verso uno in cui i layout vengono progettati a <em>partire dal contenuto<\/em>. Definendo relazioni visuali basate sugli elementi della pagina ed usando proporzioni invece di valori fissati, possiamo permeare una pagina di relazioni, indipendente dalle sue dimensioni.<\/p>\n<p>Riconoscendo che avere il contenuto a disposizione prima di progettare una pagina possa essere una richiesta assurda, Mark ha in seguito suggerito di considerare <a href=\"http:\/\/www.markboulton.co.uk\/journal\/structure-first-content-always\">la struttura per prima e il contenuto sempre (structure first content always)<\/a>. Questo va d&#8217;accordo con il <a href=\"http:\/\/www.slideshare.net\/aregh\/corepaths-a-design-framework-for-findability-prioritization-and-value\">Core Model<\/a>, un&#8217;idea introdotta la prima volta da Are Halland nell&#8217;IA Summit del 2007. Facendo domande sul contenuto principale di un sito, quali task servono per funzionare, quali informazioni dovrebbe inviare, possiamo aiutare i clienti a pensare pi\u00f9 criticamente ai loro obiettivi strategici, agli obiettivi di business e ai bisogni dell&#8217;utente. <a href=\"http:\/\/alistapart.com\/article\/the-core-model-designing-inside-out-for-better-results\">Recentemente, Ida Aalen notava che<\/a>:<\/p>\n<blockquote>\n<p>Il core model \u00e8 innanzitutto uno strumento per pensare. Aiuta il content strategist a identificare le pagine pi\u00f9 importanti sul sito. Aiuta lo UX designer a identificare quali moduli servano su una pagina. Aiuta il graphic designer a sapere quali sono gli elementi pi\u00f9 importanti da enfatizzare nel design. Aiuta a includere i clienti o gli stakeholder che sono meno web-savvy nella vostra strategia di progetto. Aiuta i copywriter e gli editori a lasciarsi alle spalle il pensiero racchiuso nei silo e a creare contenuti migliori.<\/p>\n<\/blockquote>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Condividere la scatola degli attrezzi<\/h2>\n<p>Provando empatia con i nostri utenti e navigando un medium imprevedibili, abbiamo bisogno di essere sicuri che le nostre decisioni e scoperte vengano condivise tra i team.<\/p>\n<p>Man mano che il responsive design diventa sempre pi\u00f9 integrato all&#8217;interno delle organizzazioni, questi team sono sempre pi\u00f9 collaborativi e cross-functional. I ruoli prima ben definiti adesso si stanno fondendo e i confini tra questi svaniscono. I job title e le opportunit\u00e0 di carriera stanno cominciando anch&#8217;essi a riflettere questo cambiamento: si vede \u201cfull-stack developer\u201d o \u201cproduct designer\u201d. I tool che una volta erano di dominio esclusivo di specifiche discipline, vengono ora presi in prestito, condivisi e gli viene dato un nuovo scopo: fare il prototipo di un&#8217;animazione potrebbe richiedere di scrivere in JavaScript, mentre creare una libreria modulare di componenti potrebbe richiedere la comprensione del linguaggio visuale e delle teorie di design.<\/p>\n<p>Se i tool usati sono troppo oscuri, i processi difficili da adottare, allora le opportunit\u00e0 di collaborazione diminuiscono. Rendete troppo complesso un sistema e l&#8217;onboarding di nuovi membri di un team diventer\u00e0 difficile e time-consuming. Abbiamo bisogno di essere costantemente sicuri che il nostro lavoro sia accessibile agli altri.<\/p>\n<h3>Codice attento<\/h3>\n<p>L&#8217;uso crescente delle <a href=\"http:\/\/styleguides.io\/\">front-end style guides<\/a> \u00e8 un esempio di una relazione che matura tra le discipline. Piuttosto che produrre layout statici e su misura, i designer stanno impiegando approcci pi\u00f9 sistematici al design. I front-end developer li prendono e costruiscono delle pattern libraries e dei componenti modulari, un modo di delivery che rientra meglio negli approcci allo sviluppo backend.<\/p>\n<p>Lo sviluppo component-driven ha visto l&#8217;introduzione di una successione di tool per venire incontro a questo bisogno. Tool come <a href=\"http:\/\/lesscss.org\/\">Less<\/a> e <a href=\"http:\/\/sass-lang.com\/\">Sass<\/a> ci permettono di modularizzare, concatenare e minimizzare i fogli di stile, ma possono anche introdurre delle funzionalit\u00e0 procedurali in CSS, un linguaggio progettato intenzionalmente per essere dichiarativo e pi\u00f9 facile da comprendere. Tuttavia, se prendiamo in considerazione gli altri membri del team, questa nuova funzionalit\u00e0 pu\u00f2 essere usata per <em>estendere<\/em> l&#8217;insieme di feature dichiarative esistenti di CSS. Usando i mixin e le funzioni, possiamo <a href=\"https:\/\/www.youtube.com\/watch?v=ciG-A_1FyVg\">inglobare un linguaggio di design all&#8217;interno del codice<\/a>, e propagare le convenzioni di naming che sono comprese dall&#8217;intero team.<\/p>\n<h3>Convenzioni comuni<\/h3>\n<p>Molto spesso, i problemi di processo non sono un limite impostato dalla tecnologia, ma una mancanza di volont\u00e0 di applicare pensiero critico. Cercare di risolvere i problemi tecnologici adottando pi\u00f9 tecnologia ignora il fatto che stabilire delle convenzioni pu\u00f2 essere altrettanto utile e pi\u00f9 semplice da adottare per gli altri.<\/p>\n<p>La <a href=\"http:\/\/getbem.com\/naming\/\">metodologia di naming BEM<\/a> aiuta gli stili CSS a rimanere all&#8217;interno dello scope, incapsulati e pi\u00f9 semplici da mantenere, tuttavia questo approccio non dipende da una particolare tecnologia: \u00e8 semplicemente un insieme di convenzioni documentate. Se ne avessimo previsto il bisogno, avremmo usato BEM nel 2005. Una convenzione simile \u00e8 quella dei <a href=\"http:\/\/csswizardry.com\/2015\/03\/more-transparent-ui-code-with-namespaces\/\">namespace CSS<\/a>, raccomandata da Harry Roberts. Usando prefissi codificati con una sola lettera implica che tutti quelli che lavorano a un progetto possono capire lo scopo di classi diverse e sapere in che modo dovrebbero essere usate.<\/p>\n<p>Una lamentela comune per quelli che sperano di usare software come i preprocessori e i task runner \u00e8 che spesso richiedono la conoscenza della riga di comando. I tool stuzzicano le nuove reclute con istruzioni di installazione di una riga, ma la realt\u00e0 spesso implica molti grattacapi e giri inutili. Per controbattere a questo, GitHub ha creato <a href=\"https:\/\/boxen.github.com\/\">Boxen<\/a>, un tool che implica che chiunque nella propria azienda pu\u00f2 far girare in locale un&#8217;istanza di GitHub.com sul proprio computer usando un solo comando. <a href=\"http:\/\/githubengineering.com\/scripts-to-rule-them-all\/\">GitHub<\/a> e altre aziende come <a href=\"https:\/\/bocoup.com\/weblog\/a-facade-for-tooling-with-npm-scripts\/\">Bocoup<\/a> e <a href=\"http:\/\/financial-times.github.io\/next\/docs\/developer-guide\/#make\">il <cite>Financial Times<\/cite><\/a> sono sostenitori dell&#8217;utilizzo di comandi standard per installare, testare e far girare nuovi progetti.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Principi responsive, reattivi al cambiamento<\/h2>\n<p>Dal momento che il responsive web design ci ha invitato a creare interfacce che vengono meglio incontro ai bisogno degli utenti, non sorprende che una discussione correlata si sia concentrata sempre di pi\u00f9 sull&#8217;avere una maggior considerazione per gli utenti, il medium e gli uni per gli altri.<\/p>\n<p>Se vogliamo costruire un web che sia veramente universale, poi dobbiamo abbracciare la sua natura imprevedibile. Dobbiamo ascoltare pi\u00f9 da vicino l&#8217;intero spettro del nostro pubblico. Dobbiamo vedere opportunit\u00e0 per l&#8217;ottimizzazione dove prima vedevamo barriere in ingresso. E dobbiamo considerare i nostri colleghi maker in questo processo creando tool che ci aiuteranno a navigare insieme in queste sfide.<\/p>\n<p>Questi principi dovrebbero dare forma al nostro approccio al responsive design e, a loro volta, potrebbero doversi adattare anche loro. Questo framework pu\u00f2 guidarci, ma dovrebbe anche essere aperto al cambiamento man mano che continuiamo a costruire, sperimentare e imparare.<\/p>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Il responsive web design ha cambiato tutto del modo in cui pensiamo e lavoriamo sul web e, da cinque anni a questa parte, stiamo ancora esplorando i modi migliori per avvicinarci alla nostra professione. Se vogliamo un web che sia davvero universale, dobbiamo considerare i nostri utenti, il nostro medium e i nostri team in modi nuovi e flessibili. Osservando da dove siamo venuti e verso cosa ci stiamo muovendo, Paul Robert Lloyd propone un framework filosofico per il nostro lavoro sul responsive web.<\/p>\n","protected":false},"author":818,"featured_media":7000793,"comment_status":"open","ping_status":"open","template":"","categories":[144,274,278],"tags":[],"coauthors":[377],"class_list":["post-614","article","type-article","status-publish","has-post-thumbnail","hentry","category-numero-127-10-maggio-2016","category-responsive-design","category-workflow-tools"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=614"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000793"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=614"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}