mozilla

Revision 364307 of Separate sites for mobile and desktop

  • Revision slug: Web_Development/Mobile/Separate_sites
  • Revision title: Separate sites for mobile and desktop
  • Revision id: 364307
  • Created:
  • Creator: caos30
  • Is current revision? No
  • Comment

Revision Content

La solucio de "webs diferents" per a la construcció de webs accesibles des del mòbil implica crear realment dos webs diferents (de contingut i forma) per als usuaris mòbils i pels que ens visiten des de l'escriptori de l'ordinador/portàtil. Aquesta solució -com les altres- té els seus avantatges però també els seus inconvenients.

Avantatges

La primera opció és de lluny la més popular i habitual: emprar des del teu codi al servidor la detecció del user-agent del visitant de la web per a redirigir o mostrar una web específicament dissenyada pels mòbils, típicament ubicada a una URL del tipus m.example.com. Així, aquesta tècnica que empra una lògica construida del costat del servidor resol d'un sol cop els tres objectius del desenvolupament web — si sembla que el navegador de l'usuari està corrent en un telèfon llavors la nostra aplicació li proporcionarà un contingut adaptat en tots el sentits per al mòbil i per tant optimitzat en rendiment, en tots els sentits.

Conceptualment  senzill, aquesta és la opció més fàcil per a afegir a una web existent, especialment si estàs emprant un CMS o una aplicació web que suporta plantilles pel disseny de manera més o menys flexible. Donat que a l'usuari se li envien només continguts, estils i scripts especifics pel mòbil, aquest métode també proporciona el millor rendiment per sobre de qualsevol dels altres que aquí presentem. Per acabar, també permet donar als usuaris dos experiències completament diferents quan visiten una web o una altra, perqué realment són dos webs diferents.

Inconvenients

Per desgràcia, no falten els inconvenients. Per començar, hauràs de mantenir per duplicat totes les planes de la teva web que vulguis mostrar als usuaris mòbils. Si estàs emprant un CMS, és posible reorganitzar les plantilles de la web per a minimitzar aquesta feina de duplicació. Però sempre que hi hagi una diferència entre les plantilles mòbil i d'escriptori, hi haurà una potencial font de complicacions en el teu codi. Igualment, aquesta situació incrementa el temps necesari per a afegir noves característiques o continguts a la web, perqué has d'implementar el teu codi en dos lògiques de frontend diferents.

Més important que això, hi ha el fet de que la detecció del user-agent és una tasca inherentment defectuosa i amb una alta probabilitat de que amb el pas del temps funcioni malament quan vagin sortint nous dispositius i configuracions de navegador. Cada cop que aparegui un nou navegador hauràs d'ajustar el teu algorisme de detecció per a identificar-lo. I els falsos positius (quan es detecta algo que no és) són particularment inconvenients: podria ser vergonyòs servir la versiò mòbil de la web a un usuari d'escriptori.

[NT: cal dir que hi ha llibreries i webservices  que t'ajuden en aquesta detecció del user-agent amb prou fiabilitat, perqué hi ha un equip a darrera que s'encarrega de la seva continua actualització. Això garantiria bastant el que la teva aplicació de servidor sempre interpretés correctament el user-agent del visitant i et permet no només saber el tamany de la pantalla sinó també altres característiques com si és touch. Un bon exemple és el webservice Tera-WURFL.]

Quan és adient escollir aquesta solució

sumo_screenshot.pngPrimerament, si el teu públic potencial inclou usuaris amb telèfons vells o de capacitat limitada, val la pena assenyalar que necesitaries implementar aquesta solució en algun grau sí o sí encara que no sigui completament. Això és perqué el navegador que porten alguns telèfons no solen ser compatibles amb cert codi que tú empraries normalment en una web per a l'escriptori, però en canvi s'entenen força bé amb formats com XHTML-MP o el vell WML.

Fora d'això, hi ha un cas en el que aquesta estratègia realment destaca per sobre de qualsevol altre. Si la funcionalitat que tú vols fer arribar als teus usuaris mòbils és bastant diferent de la que normalment ofereixes a la web d'escriptori, llavors usar dos webs diferents per a cada escenari és simplement la millor opció. Perqué així tens la opció d'enviar HTML, Javascript i CSS completament diferents als mòbils i als PCs.

Un altre cas on tú estaries forçat a prendre una solució com aquesta és si, per qualsevol raó, no poguessis modificar la web d'escriptori tal com està, llavors necesitaries una web 100% diferent pel mòbil.

Exemples

La majoria de les aplicacions webs que has vist de les grans empreses a internet han optat per aquesta via, incloent Facebook, YouTube, Digg, i Flickr. De fet, Mozilla emprà aquesta solució per a les versions mòbils de addons.mozilla.org (AMO) i support.mozilla.org (SUMO). Si volguessis veure el codi font d'aquests exemples en acció, pren-te la llibertat de consultar el repositori a github per a AMO o SUMO.

Altres enfocs pel desenvolupament web mòbil

Fes una ullada als següents articles sobre el desenvolupament de la web mòbil.

Informació del document original

Aquest article va ser publicat originalment el 13 de Maig de 2011, al bloc Mozilla Webdev com "Approaches to Mobile Web Development Part 2 – Separate Sites", per Jason Grlicky.

 

Revision Source

<p>La solucio de "webs diferents" per a la construcció de webs accesibles des del mòbil implica crear realment dos webs diferents (de contingut i forma) per als usuaris mòbils i pels que ens visiten des de l'escriptori de l'ordinador/portàtil. Aquesta solució -com les altres- té els seus avantatges però també els seus inconvenients.</p>
<h2 id="The_good">Avantatges</h2>
<p>La primera opció és de lluny la més popular i habitual: emprar des del teu codi al servidor la&nbsp;<a class="external" href="http://en.wikipedia.org/wiki/User_agent#User_agent_sniffing" title="User Agent Sniffing">detecció del <em>user-agent</em> del visitant</a> de la web per a redirigir o mostrar una web específicament dissenyada pels mòbils, típicament ubicada a una URL del tipus <em>m.example.com</em>. Així, aquesta tècnica que empra una lògica construida del costat del servidor resol d'un sol cop <a class="external" href="http://blog.mozilla.com/webdev/2011/05/04/approaches-to-mobile-web-development-part-1-what-is-mobile-friendliness/" title="Approaches to Mobile Web Development Part 1 – What is Mobile Friendliness?">els tres objectius del desenvolupament web</a> — si sembla que el navegador de l'usuari està corrent en un telèfon llavors la nostra aplicació li proporcionarà un contingut adaptat en tots el sentits per al mòbil i per tant optimitzat en rendiment, en tots els sentits.</p>
<p>Conceptualment&nbsp; senzill, aquesta és la opció més fàcil per a afegir a una web existent, especialment si estàs emprant un CMS o una aplicació web que suporta plantilles pel disseny de manera més o menys flexible. Donat que a l'usuari se li envien només continguts, estils i scripts especifics pel mòbil, aquest métode també proporciona el millor rendiment per sobre de qualsevol dels altres que aquí presentem. Per acabar, també permet donar als usuaris dos experiències completament diferents quan visiten una web o una altra, perqué realment són dos webs diferents.</p>
<h2 id="The_bad">Inconvenients</h2>
<p>Per desgràcia, no falten els inconvenients. Per començar, hauràs de mantenir per duplicat totes les planes de la teva web que vulguis mostrar als usuaris mòbils. Si estàs emprant un CMS, és posible reorganitzar les plantilles de la web per a minimitzar aquesta feina de duplicació. Però sempre que hi hagi una diferència entre les plantilles mòbil i d'escriptori, hi haurà una potencial font de complicacions en el teu codi. Igualment, aquesta situació incrementa el temps necesari per a afegir noves característiques o continguts a la web, perqué has d'implementar el teu codi en dos lògiques de <em>frontend</em> diferents.</p>
<p>Més important que això, hi ha el fet de que la detecció del <em>user-agent</em> és una tasca <a class="external" href="http://css-tricks.com/browser-detection-is-bad/" title="Browser Detection is Bad">inherentment defectuosa</a> i amb una alta probabilitat de que amb el pas del temps funcioni malament quan vagin sortint nous dispositius i configuracions de navegador. Cada cop que aparegui un nou navegador hauràs d'ajustar el teu algorisme de detecció per a identificar-lo. I els <em>falsos positius</em> (quan es detecta algo que no és) són particularment inconvenients: podria ser vergonyòs servir la versiò mòbil de la web a un usuari d'escriptori.</p>
<p>[NT: cal dir que hi ha llibreries i webservices&nbsp; que t'ajuden en aquesta detecció del user-agent amb prou fiabilitat, perqué hi ha un equip a darrera que s'encarrega de la seva continua actualització. Això garantiria bastant el que la teva aplicació de servidor sempre interpretés correctament el <em>user-agent </em>del visitant i et permet no només saber el tamany de la pantalla sinó també altres característiques com si és touch. Un bon exemple és el webservice <a href="http://wurfl.thesedays.com/" title="http://wurfl.thesedays.com/">Tera-WURFL</a>.]</p>
<h2 id="When_it_is_right_to_choose_this_option">Quan és adient escollir aquesta solució</h2>
<p><img align="right" alt="sumo_screenshot.png" class="internal rwrap" src="/@api/deki/files/5893/=sumo_screenshot.png" />Primerament, si el teu públic potencial inclou usuaris amb&nbsp;<a class="external" href="http://www.cnet.com/8301-17918_1-10461614-85.html" title="Feature Phones Definition">telèfons vells o de capacitat limitada</a>, val la pena assenyalar que necesitaries implementar aquesta solució en algun grau sí o sí encara que no sigui completament. Això és perqué el navegador que porten alguns telèfons no solen ser compatibles amb cert codi que tú empraries normalment en una web per a l'escriptori, però en canvi s'entenen força bé amb formats com <a class="external" href="http://en.wikipedia.org/wiki/XHTML_Mobile_Profile" title="XHTML-MP">XHTML-MP</a> o el vell <a class="external" href="http://en.wikipedia.org/wiki/Wireless_Markup_Language">WML</a>.</p>
<p>Fora d'això, hi ha un cas en el que aquesta estratègia realment destaca per sobre de qualsevol altre. Si la funcionalitat que tú vols fer arribar als teus usuaris mòbils és bastant diferent de la que normalment ofereixes a la web d'escriptori, llavors usar dos webs diferents per a cada escenari és simplement <a class="external" href="http://tripleodeon.com/2010/10/not-a-mobile-web-merely-a-320px-wide-one">la millor opció</a>. Perqué així tens la opció d'enviar HTML, Javascript i CSS completament diferents als mòbils i als PCs.</p>
<p>Un altre cas on tú estaries forçat a prendre una solució com aquesta és si, per qualsevol raó, no poguessis modificar la web d'escriptori tal com està, llavors necesitaries una web 100% diferent pel mòbil.</p>
<h2 id="Examples">Exemples</h2>
<p>La majoria de les aplicacions webs que has vist de les grans empreses a internet han optat per aquesta via, incloent <a class="external" href="http://m.facebook.com/">Facebook</a>, <a class="external" href="http://m.youtube.com/">YouTube</a>, <a class="external" href="http://m.digg.com/" title="Mobile Digg">Digg</a>, i <a class="external" href="http://m.flickr.com/" title="Mobile Flickr">Flickr</a>. De fet, Mozilla emprà aquesta solució per a les versions mòbils de <a class="link-https" href="https://addons.mozilla.org/">addons.mozilla.org</a> (AMO) i <a class="external" href="http://support.mozilla.com/">support.mozilla.org</a> (SUMO). Si volguessis veure el codi font d'aquests exemples en acció, pren-te la llibertat de consultar el <a class="link-https" href="https://github.com/jbalogh/zamboni/">repositori a github per a AMO</a> o <a class="link-https" href="https://github.com/jsocol/kitsune">SUMO</a>.</p>
<h2 id="Approaches_to_mobile_Web_development">Altres enfocs pel desenvolupament web mòbil</h2>
<p>Fes una ullada als següents articles sobre el desenvolupament de la web mòbil.</p>
<ul>
  <li><a href="/ca/Web_development/Mobile/Mobile-friendliness" title="Wat is CSS">Què és una web amigable amb el mòbil?</a></li>
  <li><a href="/ca/docs/Web_Development/Mobile/Responsive_design" title="/en-US/docs/Web_Development/Mobile/Responsive_design">Disseny web sensible (un únic disseny que s'adapta al navegador)</a></li>
  <li><a href="/ca/docs/Web_Development/Mobile/A_hybrid_approach" title="/en-US/docs/Web_Development/Mobile/A_hybrid_approach">Una solució híbrida</a></li>
</ul>
<div class="originaldocinfo">
  <h3 id="Original_document_information">Informació del document original</h3>
  <p>Aquest article va ser publicat originalment el 13 de Maig de 2011, al bloc Mozilla Webdev com "<a class="external" href="http://blog.mozilla.com/webdev/2011/05/13/approaches-to-mobile-web-development-part-2-separate-sites/" title="http://blog.mozilla.com/webdev/2011/05/13/approaches-to-mobile-web-development-part-2-separate-sites/">Approaches to Mobile Web Development Part 2 – Separate Sites</a>", per Jason Grlicky.</p>
</div>
<p>&nbsp;</p>
Revert to this revision