---
title: Design Sensibile
slug: Web/Progressive_web_apps
translation_of: Web/Progressive_web_apps
translation_of_original: Web/Guide/Responsive_design
original_slug: Web_Development/Mobile/Design_sensibile
---
<p>Come risposta ai problemi associati all'approccio per <a href="/en-US/docs/Web_Development/Mobile/Separate_sites">siti separati</a> nel campo del Web design per mobile e desktop, un'idea relativamente nuova (che è <a href="http://www.alistapart.com/articles/dao/">abbastanza datata</a>) sta aumentando la sua popolarità: evitare il rilevamento user-agent, e creare invece una pagina che risponda client-side alle capacità del browser. Questo approccio, introdotto da Ethan Marcotte nel suo articolo dal titolo <a href="http://alistapart.com">A List Apart</a>, è oggi conosciuto come <a href="http://www.alistapart.com/articles/responsive-web-design/">Web Design Sensibile</a>. Come l'approccio a siti separati, il Web Design sensibile possiede aspetti positivi e negativi.</p>
<h2 id="Aspetti_Positivi">Aspetti Positivi</h2>
<p>Sebbene non fosse inizialmente pensato come un metodo per creare siti per dispositivi mobili, il design sensibile ha recentemente ricevuto un sacco di attenzione come metodo per muovere i primi passi verso la mobile-friendliness al posto di creare siti separati.</p>
<ol style="font-size: medium;">
 <li>Fa risparmiare tempo e denaro dato che non vi è la necessità di mantenere più siti separati per diversi dispositivi.</li>
 <li>Il Design Sensibile fornisce ogni pagina con un singolo e unico URL.</li>
 <li>Le statistiche di condivisione Social (Mi piace di Facebook, Tweets, +1 su Google plus) non sono divise, dato che le versioni mobile e desktop delle vostre pagine web utilizzano un singolo e unico URL.</li>
 <li>Il Design Sensibile non si cura degli user agent.</li>
</ol>
<p>Ci sono degli aspetti decisamente buoni in questo approccio. Dato che non si appoggia al rilevamento degli user-agent, è più affidabile e a prova di aggiornamenti dell'approccio a siti separati. Per siti semplici, può essere significativamente più facile da realizzare e mantenere di altre opzioni.</p>
<h2 id="Aspetti_Negativi">Aspetti Negativi</h2>
<p>Questo approccio non è privo di limitazioni. Dato che il contenuto può venire alterato client-side con JavaScript, solo cambiamenti minimali in esso sono consigliati. In genere, le cose possono diventare molto complicate molto in fretta se state provando a codificare due set separati di JavaScript per lavorare sullo stesso DOM. Questa è la ragione principale per la quale le applicazioni Web tendono a non adottare questa soluzione.</p>
<p>Dando al vostro sito un design sensibile implica anche il riscrivere gli stili se non avete realizzato già un <a href="http://www.smashingmagazine.com/2008/06/26/flexible-layouts-challenge-for-the-future/">layout flessibile</a>. Questo potrebbe essere anche un vantaggio mascherato: creare un design sensibile per il vostro sito potrebbe essere una buona opportunità per modernizzarne e pulirne i fogli di stile.</p>
<p>Infine, dato che state aggiungendo codice ai vostri script e fogli di stile, le performance potrebbero peggiorare molto di più che con l'approccio a Siti Separati. Non c'è nessun modo per evitare ciò, anche se una riproduzione meditata dei vostri script e fogli di stile potrebbe salvare qualche byte nel lungo periodo.</p>
<h2 id="Quando_è_bene_scegliere_questa_opzione">Quando è bene scegliere questa opzione</h2>
<p><a href="/@api/deki/files/5894/=teixido_responsive-300x177.png" title="teixido_responsive-300x177.png"><img align="right" alt="teixido_responsive-300x177.png" class="internal rwrap" height="177" src="/@api/deki/files/5894/=teixido_responsive-300x177.png?size=webview" width="300"></a>Come già detto, dato il cambiamento dei contenuti potrebbe essere difficile, utilizzando questo approccio, far vivere agli utenti un'esperienza significativamente diversa agli utenti mobili senza rendere il codice più complesso. Detto ciò, se le versioni desktop e mobile del vostro sito sono molto simili, allora questo approccio è una buona scelta. Va bene per siti il cui nucleo è formato da documenti la cui prima funzione è consistente attraverso i dispositivi, come le pagine di prodotto. Come potete notare gli esempi sottostanti sono tutti blog e portfolio!</p>
<h2 id="Examples" name="Examples" style="overflow: hidden;">Esempi</h2>
<p>Anche se non è popolare come l'approccio a siti separati, ci sono sempre più siti web che utilizzano questa tecnica ogni giorno. Fortunatamente, dato che il codice è tutto client-side, se volete vedere come funziona tecnicamente un sito che utilizza questo approccio, vi basterà visitarne uno e cliccare su "Visualizza il Sorgente Pagina". Quì di seguito riportiamo alcuni esempi:</p>
<ul>
 <li><a href="http://teixido.co/">http://teixido.co/</a> – uno dei miei design sensibili preferiti, inserito anche in alcune immagini sottostanti!</li>
 <li><a href="http://adactio.com/journal/1696">http://adactio.com/journal/1696</a> – contiene anche un buon articolo da leggere, con i propri esempi.</li>
 <li><a href="http://thinkvitamin.com/">http://thinkvitamin.com/</a></li>
 <li><a href="http://stephencaver.com/">http://stephencaver.com/</a></li>
 <li><a href="http://hicksdesign.co.uk/">http://hicksdesign.co.uk/</a></li>
</ul>
<p>Malgrado sia un approccio relativamente giovane, stanno già emergendo delle pratiche migliori. Per esempio, se state progettando un sito da una bozza con questa opzione in mente, è solitamente utile <a href="http://www.lukew.com/ff/entry.asp?1117">creare un design per piccoli schermi </a>prima, in maniera da avere chiari i vincoli del mobile fin dall'inizio. Altresì valido è l'utilizzo del miglioramento progressivo per i vostri fogli di stile invece di nascondere elementi del vostro sito esistente con delle media query. In questo modo, i vecchi browser che non supportano le media query potranno comunque visualizzare il layout corretto. Una presentazione eccellente sui meriti di questo metodo è disponibile <a href="http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu">qui</a>.</p>
<h2 id="Approcci_per_lo_sviluppo_Web_per_il_mobile">Approcci per lo sviluppo Web per il mobile</h2>
<p>Date un'occhiata agli articoli seguenti per un background e altri approcci per sviluppare piattaforme mobili.</p>
<ul>
 <li><a href="/en-US/docs/Web_Development/Mobile/Mobile-friendliness" title="XML Web Services">What is mobile-friendliness?</a></li>
 <li><a href="/en-US/docs/Web_Development/Mobile/Separate_sites" title="Web development/Mobile/Separate sites">Separate sites</a></li>
 <li><a href="/en-US/docs/Web_development/Mobile/A_hybrid_approach" title="Web development/Mobile/Hybrid approach">A hybrid approach</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Web/Apps/app_layout/Responsive_design_versus_adaptive_design?search=responsive%20design">Responsive versus adaptive design</a></li>
</ul>
<h2 id="Vedi_anche">Vedi anche</h2>
<ul>
 <li><a href="/en-US/docs/Web_Development/Responsive_Web_design" title="Responsive Web design">Responsive Web design</a> per risorse aggiuntive</li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Web/Apps/app_layout/Responsive_design_versus_adaptive_design?search=responsive%20design">Responsive versus adaptive design</a></li>
</ul>
<div class="originaldocinfo">
 <h3 id="Informazioni_originali_sul_documento">Informazioni originali sul documento</h3>
 <p>Questo documento è stato originariamente pubblicato il 27 Maggio 2011 sul blog Mozilla Webdev come "<a href="http://blog.mozilla.com/webdev/2011/05/27/approaches-to-mobile-web-development-part-3-responsive-design/" title="http://blog.mozilla.com/webdev/2011/05/27/approaches-to-mobile-web-development-part-3-responsive-design/">Approaches to Mobile Web Development Part 3 - Responsive Design</a>", da Jason Grlicky.</p>
</div>
<p> </p>