{"id":643,"date":"2016-08-10T20:06:58","date_gmt":"2016-08-10T18:06:58","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/passare-al-responsive\/"},"modified":"2016-08-10T20:06:58","modified_gmt":"2016-08-10T18:06:58","slug":"passare-al-responsive","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/passare-al-responsive\/","title":{"rendered":"Passare al responsive"},"content":{"rendered":"<div class=\"main-content pre-article\">\n<p class=\"editors-note\"><b>Nota degli editori:<\/b> Siamo lieti di condividere un estratto dal Capitolo 2 del nuovo libro di Karen McGrane <cite>Going Responsive<\/cite>, disponibile presso <a href=\"http:\/\/abookapart.com\/products\/going-responsive\">A Book Apart<\/a>.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<p>Vorrei proprio potervi dire che c&#8217;\u00e8 un vero percorso per rilasciare con successo un redesign responsive, ma dopo aver parlato con dozzine di organizzazioni, \u00e8 chiaro che il processo mediante cui le grandi organizzazioni si convertono al responsive varia molto. Ci sono vari approcci diversi tra loro che potrebbero funzionare, ma dovete capire i benefici e rischi di ciascun di essi.<\/p>\n<p>Potete fare il redesign dell&#8217;intero sito tutto in una volta o dovete fare lo staging del rollout nel tempo? Farete un retrofit del sito desktop esistente o comincerete da capo? Rilascerete una beta version del sito o farete una \u201crivelazione in grande\u201d? Per trovare l&#8217;opzione adatta alla vostra organizzazione, ponetevi le seguenti domande:<\/p>\n<ul>\n<li><b>Quanto siete preoccupati per i clienti attuali sul sito desktop?<\/b> Ora, nessuno risponder\u00e0 \u201cNon sono minimamente preoccupato\u201d, ma alcune organizzazioni (ad esempio, le case editrici) fanno dei redesign piuttosto frequenti senza lanciare una beta version: semplicemente premono l&#8217;interruttore. Altre organizzazioni (per esempio, le banche) sanno di non poter rischiare di creare frustrazione nei clienti esistenti introducendo dei cambiamenti drastici senza un periodo di adattamento.<\/li>\n<li><b>State facendo il redesign di una applicazione web?<\/b> Non permettete a nessuno di dirvi che le web app non possono essere rese responsive. Possono esserlo, ma ci vuole tempo e impegno. Se presentate molti dati in forma tabellare, se avete flussi di transazione basati su form complesse o delicate integrazioni con sistemi di backend legacy, assicuratevi di aggiungere del tempo nel vostro processo.<\/li>\n<li><b>Pianificate di fare cambiamenti al vostro contenuto?<\/b> Un redesign responsive \u00e8 un&#8217;opportunit\u00e0 fantastica per pulire e snellire il contenuto esistente: potreste non avere pi\u00f9 un&#8217;occasione migliore di questa per sistemare contenuti cresciuti a dismisura che non fanno il loro dovere. Detto ci\u00f2, molte organizzazioni pensano di non poter fare tutto in una volta, quindi svelano la pulizia del contenuto a fasi.<\/li>\n<li><b>Pianificate di implementare un nuovo CMS o delle API?<\/b> Molte organizzazioni riferiscono che il lavoro che \u00e8 stato fatto da loro negli ultimi anni per cambiare piattaforma dei sistemi di pubblicazione ha reso pi\u00f9 semplice la conversione al responsive. Ma dovrete decidere se fare prima il passaggio di CMS o il redesign. \u00c8 pi\u00f9 rischioso e pi\u00f9 \u201ctime-consuming\u201d farli entrambe allo stesso tempo.<\/li>\n<li><b>I vostri stakeholder sono preparati per il processo di revisione?<\/b> Alcune organizzazioni utilizzano il redesign responsive per coinvolgere l&#8217;intera organizzazione nell&#8217;apprendimento di un nuovo processo. Altri usano un approccio \u201cmeglio chiedere perdono che permesso\u201d, svelando prima il redesign e sistemando in seguito gli inevitabili pezzi rotti.<\/li>\n<\/ul>\n<p>Una volta che conoscerete le risposte a queste domande, prendete in considerazione le opzioni per passare al responsive.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Retrofit<\/h2>\n<p>Fare un retrofit responsive significa riscrivere il codice del front-end del sito web con qualche o nessun cambiamento al contenuto e al design esistenti.<\/p>\n<p>Devo fare una confessione: prima di cominciare a parlare ad aziende che avevano lanciato un retrofit responsive di successo, ero sicura che questa fosse la peggiore di tutte le possibili opzioni, destinata a realizzare un&#8217;esperienza al di sotto delle aspettative per chiunque ne fosse coinvolto. I miei credo filosofici sul \u201cmodo giusto\u201d per gestire i processi web non sopravvivono sempre negli scontri con il mondo reale: ammetto che un retrofit funziona bene in alcuni scenari.<\/p>\n<p>In generale, i retrofit funzionano al meglio quando almeno una delle seguenti affermazioni \u00e8 vera:<\/p>\n<ol>\n<li>Il contenuto non cambier\u00e0 (molto).<\/li>\n<li>Alle applicazioni web complesse non serve un redesign.<\/li>\n<li>C&#8217;\u00e8 gi\u00e0 un framework a componenti.<\/li>\n<\/ol>\n<p>Aziende quali Capital One, Marriott e Nationwide Insurance hanno implementato dei retrofit responsive con successo. Fare un retrofit li ha costretti a concentrarsi sugli aspetti responsive del progetto senza essere distratti da questioni pi\u00f9 grandi sul redesign del sito, dall&#8217;editing del contenuto o dal cambiamento di piattaforma CMS. Per molti siti web, un retrofit aiuta anche a mitigare i dubbi politici attorno al cambiamento o al danneggiamento dell&#8217;esperienza desktop, dal momento che non cambia molto.<\/p>\n<p>Ecco come fare un retrofit nel modo giusto:<\/p>\n<ul>\n<li><b>\u201cNon toccare il desktop\u201d<\/b> \u00e8 un ordine dato spesso al team responsive, ma questa linea guida \u00e8 troppo limitante. Obbliga il team a lavorare verso una parit\u00e0 di design non necessaria a scapito di prendere decisioni di design migliori per schermi pi\u00f9 piccoli.<\/li>\n<li><b>\u201cNon danneggiate il desktop\u201d<\/b> \u00e8 un&#8217;ambizione pi\u00f9 realistica e raggiungibile. Questo d\u00e0 ai team la flessibilit\u00e0 di cui hanno bisogno per fare aggiustamenti al layout, al design, alla navigazione o al contenuto.<\/li>\n<li><b>Impostate aspettative realistiche<\/b> con il vostro team e sviluppate un piano per fare dei cambiamenti sul lungo termine. Gli stakeholder potrebbero essere sorpresi quando vedranno in che modo il contenuto e le funzionalit\u00e0 esistenti si muovono sui vari schermi.<\/li>\n<li><b>Prendete in considerazione di scegliere una sezione<\/b> per una ristrutturazione responsive completa. Una sezione completamente editata e riprogettata pu\u00f2 fungere da utile metro di confronto con il retrofit. Scegliere una sezione per un redesign completo dar\u00e0 al team un&#8217;esperienza con il processo, mostrer\u00e0 agli stakeholder cosa \u00e8 possibile, fornir\u00e0 un insight nel livello di sforzo che pu\u00f2 informare la portata di processi futuri e offrire dati reali su come funzioner\u00e0 un&#8217;esperienza completamente ripensata rispetto ad un retrofit.<\/li>\n<\/ul>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Beta release<\/h2>\n<p>Negli ultimi anni, applicazioni web popolari come Gmail, Flickr e Delicious sono state lanciate in beta e <a href=\"http:\/\/bkaprt.com\/gr\/02-06\/\">sono rimaste in beta<\/a>. Questo approccio, definito \u201cbeta perpetua\u201d, \u00e8 stato il precursore delle pratiche di deploy continuo usate oggi da molte applicazioni per supportare lo sviluppo e i test continui.<\/p>\n<p>Oggi, quando i team dicono che stanno lanciando in beta, spesso intendono che gli utenti possono fare \u201copt out\u201d dal sito in qualunque momento e ritornare alla versione \u201cclassica\u201d del sito web. Questo approccio \u201cbeta parallela\u201d richiede una quantit\u00e0 significativa di tempo e sforzi aggiuntivi per sviluppare e rivedere, ma in cambio d\u00e0 la possibilit\u00e0 di fare roll out del design lentamente, raccogliendo i feedback degli utenti e i dati statistici lungo il percorso.<\/p>\n<p>Aziende come Fidelity, Heatport e il <cite>Guardian<\/cite> hanno investito in versioni beta parallele, che hanno dato loro un modo per testare ed imparare nel tempo da un responsive design. Stephen Turbek, SVP, User Experience Design in Fidelity, <a href=\"http:\/\/bkaprt.com\/gr\/01-16\/\">ha detto che la loro decisione di lanciare in beta<\/a> \u00e8 stata fondamentale per il loro successo:<\/p>\n<figure id=\"figure1\" class=\"quote\">\n<blockquote><p>Uno dei primi passi \u00e8 stato quello di costruire un sito beta che le persone potevano decidere di usare per un certo periodo per poi ritornare al sito solito. Il sito beta ha comportato una quantit\u00e0 di lavoro aggiuntivo significativa, ma iterare live su un sito con milioni di clienti appassionati non sarebbe stato l&#8217;approccio corretto. In questo modo, abbiamo potuto fare dei cambiamenti in maniera pi\u00f9 rapida e ottenere un&#8217;enorme quantit\u00e0 di feedback dagli utenti.<\/p><\/blockquote>\n<\/figure>\n<p>Ecco cosa deve succedere per lanciare una beta con successo:<\/p>\n<ul>\n<li><b>una cultura \u201ctesta-e-impara\u201d<\/b> dovrebbe gi\u00e0 esistere nella vostra organizzazione. I team devono sentirsi a proprio agio a lavorare con cicli brevi di iterazione e test, la maggior parte dei team dovr\u00e0 fare test ogni sei settimane e addirittura con una frequenza settimanale o ogni quindici giorni. Se non state gi\u00e0 lavorando cos\u00ec, costruire una cultura di apprendimento con la ricerca prender\u00e0 del tempo e aggiunger\u00e0 complessit\u00e0.<\/li>\n<li><b>Architettura tecnica<\/b> e infrastruttura di pubblicazione devono esserci cos\u00ec che gli utenti possano fare opt in e out, il che pu\u00f2 essere costoso.<\/li>\n<li>\u00c8 cruciale l&#8217;<b>executive buy-in<\/b> da parte degli stakeholder che possono vedere il valore del processo di beta e vogliono investire nella manutenzione di due versioni del sito, per non parlare del gestire il traffico su due URL diversi.<\/li>\n<li>Il <b>quality assurance testing<\/b> (QA) diventa esponenzialmente pi\u00f9 complesso quando si testa su pi\u00f9 form factors. Non sottostimate il tempo o lo staff di cui avrete bisogno per fare QA di due versioni del sito.<\/li>\n<li><b>Fare roll out della beta in vari stage<\/b> aiuter\u00e0 a controllare chi vi pu\u00f2 accedere. Alex Breuer, Creative Director al <cite>Guardian<\/cite>, <a href=\"http:\/\/bkaprt.com\/gr\/02-07\/\">ha detto che hanno scoperto che mostrare il sito in beta<\/a> agli utenti che venivano da una ricerca o dai social \u201c\u00e8 stato un modo gentile per introdurre la nuova esperienza del <cite>Guardian<\/cite>.\u201d<\/li>\n<li><b>Date per assunto che i primi feedback saranno negativi<\/b> se il vostro sito beta esclude il contenuto o le funzionalit\u00e0 del vecchio sito. Aiutate gli stakeholder a capire che il feedback negativo non \u00e8 un segno di fallimento: in realt\u00e0, ottenere subito questi commenti \u00e8 proprio lo scopo della beta.<\/li>\n<\/ul>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Responsive mobile-only<\/h2>\n<p>Un&#8217;altra strategia di rollout, spesso, ma non sempre, implementata nel contesto di una beta release, \u00e8 di sviluppare un sito web responsive che copra tutte le dimensioni di smartphone e tablet, preservando il sito attuale a larghezza fissa solo per gli utenti desktop. In un certo senso, questo approccio \u00e8 un \u201csito responsive m.\u201d ma questa parola fa incartare il mio cervello, quindi non chiamiamolo cos\u00ec e basta. Lo chiameremo <i>sito responsive mobile-only<\/i>.<\/p>\n<p>Un sito responsive mobile-only fa si che l&#8217;azienda occupi il suo tempo concentrandosi su questioni pi\u00f9 grandi e complesse. Le aziende sanno di aver bisogno di un sito che sia utile per gli utenti mobile, ma temono di danneggiare il traffico desktop esistente. Tuttavia, sanno anche che il sito necessita di un redesign completo o di miglioramenti importanti all&#8217;infrastruttura del backend, quindi non vogliono fare un retrofit. In questo senso, un design responsive mobile-only offre il meglio di entrambe i mondi. I team possono concentrarsi sull&#8217;ottenere il responsive design nella maniera corretta, senza avere a che fare con le politiche degli stakeholder e con i rischi operativi inerenti al cambiamento del desktop.<\/p>\n<p>Ma questo approccio \u00e8 anche il peggiore di entrambe i mondi: permette agli stakeholder di continuare a credere che il sito desktop sia il sito web \u201creale\u201d, sminuendo la grande popolazione in continua crescita degli utenti mobile. Significa anche che, cos\u00ec come con tutti i siti m-punto, gli utenti smartphone e desktop soffriranno degli stessi problemi di performance dovuti ai redirect del server.<\/p>\n<p>Ecco cosa potete fare per lanciare un sito responsive mobile-only di successo:<\/p>\n<ul>\n<li><b>Trattatelo come una beta<\/b> anche se non lo state proponendo in stage. Dovete avere un piano raccogliere i dati, testare e rivedere il sito responsive. Nel tempo, pianificate un rollout a stage per gli utenti desktop.<\/li>\n<li><b>Prendete scelte difficili<\/b> sul contenuto e le funzionalit\u00e0. Questa strategia di rollout ha pi\u00f9 successo quando viene usata per pulire e snellire un sito che col tempo \u00e8 andato fuori controllo. Se non siete preparati per prendere delle decisioni difficili, fare un retrofit.<\/li>\n<li><b>Istruite il vostro team<\/b> su cosa rende di successo un sito web responsive.<\/li>\n<li>Il rischio con un approccio \u201c<a href=\"http:\/\/it.urbandictionary.com\/define.php?term=Skunkworks\">skunkwork<\/a>\u201d \u00e8 che il team \u201cmobile\u201d proseguir\u00e0 per conto suo e il resto dell&#8217;azienda non imparer\u00e0 nulla dall&#8217;esperienza.<\/li>\n<li><b>Rendetelo il sito web <em>vero<\/em>.<\/b> Impostate delle aspettative riguardo al fatto che questo processo non \u00e8 per costruire un sito web \u201cmobile\u201d, ma \u00e8 la creazione di un sito web che alla fine sostituir\u00e0 quello desktop.<\/li>\n<li><b>Dovete sapere quando smettere di investire nel sito desktop<\/b> e spostare le risorse al sito responsive. <a href=\"http:\/\/bkaprt.com\/gr\/02-08\/\">BBC News ha detto<\/a> che continuare a lavorare sul loro sito desktop \u201cstava succhiando risorse e morale e questo ci \u00e8 costato caro, ritardano la nostra mossa strategica a \u2018Responsive News\u2019.\u201d<\/li>\n<\/ul>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Sezione per sezione<\/h2>\n<p>Altre organizzazioni scelgono di cominciare con una sezione specifica, anche solo una pagina particolare o un tipo di template. Piuttosto che fare tutto il sito in una volta, scelgono di mettere in sandbox i propri sforzi e di dare ai team del tempo per fare pratica.<\/p>\n<p>Con che sezione dovremmo cominciare? La risposta a questa domanda varia da un approccio di rollout all&#8217;altro. Alcune aziende riportano di aver scelto una sezione che sapevano di voler riprogettare. <a href=\"http:\/\/bkaprt.com\/gr\/01-21\/\">Celebrity Cruises ha cominciato dalla propria sezione Destinations<\/a>, rendendola responsive come parte di uno sforzo pi\u00f9 grande per riscrivere il contenuto e cambiare la piattaforma CMS. Altre aziende hanno cominciato con una sezione meno popolare, una sezione gestita dagli stakeholder che sono esaltati dal processo o una che ha una quantit\u00e0 di traffico mobile sproporzionata rispetto al resto.<\/p>\n<p>E poi c&#8217;\u00e8 Microsoft, che ha cominciato dalla homepage. Questo approccio alla <a href=\"https:\/\/it.wikipedia.org\/wiki\/Villaggio_Pot%C3%ABmkin\">villaggio Potemkin<\/a> a un redesign responsive pu\u00f2 frustrare gli utenti, promettendo loro un sito web che funziona bene sui device mobile, solo per tradire quelle aspettative al primo \u201ctap\u201d. Ma Chris Balt, Senior Web Product Manager in Microsoft, <a href=\"http:\/\/bkaprt.com\/gr\/01-14\/\">ha sostenuto che li ha aiutati ad ottenere il buy-in aziendale<\/a> per passare al responsive:<\/p>\n<figure id=\"figure2\" class=\"quote\">\n<blockquote><p>Altri siti hanno usato approcci diversi, cominciando dal basso o da un angolo semi-nascosto del sito. Il nostro tentativo di farlo partendo dalla homepage &#8211; e di farlo in una maniera davvero bella, se mi \u00e8 concesso affermarlo io stessa &#8211; \u00e8 stata una buona scelta. Ha portato a una visibilit\u00e0 significativa che non penso avremmo ottenuto se fossimo partiti da un qualche sito di supporto di secondo livello o da cose simili. Quindi, anche se l&#8217;esperienza dal punto di vista dell&#8217;utente ne ha sofferto &#8211; perch\u00e9 sono ad un click da un&#8217;esperienza non responsive &#8211; la visibilit\u00e0 che ci ha reso in termini di politica, organizzazione, sia interna che esterna alla compagnia, l&#8217;ha resa un&#8217;ottima scelta. Sono molto lieto di averlo fatto in questo modo.<\/p><\/blockquote>\n<\/figure>\n<p>Ecco come potreste metter mano al roll out di un redesign responsive a sezioni:<\/p>\n<ul>\n<li><b>Scegliete una sezione<\/b> che rifletta i tipi di problemi o i design pattern che troverete altrove sul sito. Alcune sezioni, come \u201cInvestor Relations\u201d o \u201cAbout Us\u201d potrebbero essere pi\u00f9 semplici da implementare perch\u00e9 hanno dei contenuti e dei layout relativamente semplici, ma non forniranno altrettanti insight su come gestire problemi pi\u00f9 complessi.<\/li>\n<li><b>Concentratevi sul vostro \u201ccore\u201d.<\/b> Come con il Pilates, il vostro core fa tutto il lavoro. Osservate il vostro traffico e i dati d&#8217;uso per identificare le pagine e le sezioni del sito che importano di pi\u00f9 agli utenti. Dirigete l\u00ec la vostra energia.<\/li>\n<li><b>Assicuratevi che i vostri stakeholder first-round siano d&#8217;accordo<\/b> con lo sforzo extra richiesto per supportare il redesign. Verr\u00e0 chiesto loro di prendere decisioni con cui non hanno familiarit\u00e0 e avranno bisogno di condividere e difendere il loro rationale con il resto dell&#8217;azienda.<\/li>\n<li><b>Tracciate e documentate lo \u201cscope\u201d<\/b> per prendere decisioni informate in futuro. Sapere quanto tempo prendono alcuni processi, dove i team di design e sviluppo hanno incontrato difficolt\u00e0 e quali decisioni sono state difficili per gli stakeholder vi aiuter\u00e0 a pianificare la fase successiva del lavoro.<\/li>\n<li><b>Prendete decisioni globali tenendo a mente tutti.<\/b> Alcune scelte ricadono davvero su tutti. Gestire le immagini responsive, progettare i menu di navigazione, identificare i tipi di contenuto principali, sviluppare moduli riutilizzabili come parte di un sistema di design &#8211; questi argomenti richiedono il buy-in da parte di pi\u00f9 persone che non semplicemente quelle che gestiscono una pagina o una sezione particolare.<\/li>\n<\/ul>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Ogni organizzazione \u00e8 diversa, con i propri processi interni, i bisogni degli stakeholder e le aspettative degli utenti, perci\u00f2 non c&#8217;\u00e8 un modo giusto per affrontare un progetto di redesign responsive. Quello giusto \u00e8 quello che va bene per la vostra azienda, come spiega Karen McGrane nel suo nuovo libro Going Responsive. Questo estratto esamina i pro e i contro di diversi approcci a progetti responsive, dalla beta release al grande lancio, passando per tutto quello che sta in mezzo, cos\u00ec che possiate capire quale si adatti meglio al vostro team.<\/p>\n","protected":false},"author":818,"featured_media":7000805,"comment_status":"open","ping_status":"open","template":"","categories":[151,274],"tags":[],"coauthors":[380],"class_list":["post-643","article","type-article","status-publish","has-post-thumbnail","hentry","category-numero-134-10-agosto-2016","category-responsive-design"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/643","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=643"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000805"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=643"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=643"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=643"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=643"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}