Case history: come rendere mobile-friendly uno sito che non prevedeva il responsive design

Case history: come rendere mobile-friendly uno sito che non prevedeva il responsive design

Da Google lo avevano promesso e si è puntalmente verificato: le pagine che presentano incompatibilità con i dispositivi mobile a partire dal 21 di Aprile nelle ricerche effetuate in mobilità vengono penalizzate rispetto a quelle che invece sono compatibili.
Occorre quindi correre ai ripari, mettendo in piedi una strategia che tenga presente i dettami del responsive web design e renda visualizzabile correttamente il sito anche sugli schermi diversi dal classico desktop.

Normalmente la strada più semplice è costruire da zero un nuovo layout, supportato da uno dei tanti framework css ora disponibili (Twitter Bootstrap, ZURB Foundation, Skeleton per citarne alcuni) e aggiungendo poi le regole custom, con un po’ di criterio, preferibilmente con una delle metodologie BEM, che per mezzo delle media queries adatti il contenuto al dispositivo con cui viene visualizzato.

Un’altra soluzione potrebbe essere, se il sito su cui dobbiamo apportare la compatibilità è un CMS popolare come WordPress o Drupal, installare un theme mobile-friendly e mostrare quello specifico layout solo alle utenze mobile.
In WordPress ci viene in aiuto il plugin Any Mobile Theme Switcher mentre in Drupal ci sono due soluzioni fornite da moduli contrib: context_mobile_detect oppure mobile_detect. Entrambe sono valide, il loro uso è condizionato solo dal tipo di approccio attivo sul nostro progetto, Context o ThemeKey appunto.

E se il sito non fosse un CMS ma possedesse comunque un sistema di templating?

E’ proprio questo il caso di cui vi voglio raccontare l’evoluzione.
Il sito è un portale di e-commerce, realizzato con un framework PHP e pubblicato verso la fine del 2011. Il completo refactoring e restyling sono previsti per la fine del 2016. Cosa era possibile fare quindi per non regalare ai competitor tutta l’utenza mobile per un periodo di non meno di 18 mesi?
Ragionando in termini MVC, dal momento che il sito sarebbe stato completamente rifatto di li a poco, era importante fare un intevento in economia, che quindi non prevedesse modifiche ai Model e ai Controller.
Fortunatamente il front end del sito in questione era stato sviluppato con il sistema di griglie molto in voga in quegli anni 960.gs (l’altro framework molto usato era Blueprint) costituendo una solida base di partenza. Questo aspetto di fatto ha ridotto al minimo le modifiche necessarie ai file template responsabili delle View.

  • Primo passo: emulare le media queries. 960gs pur difettando di tutte le utilità responsive a cui ci ha abituato Bootstrap, ha reso disponibile adapt, una libreria javascript che in base al viewport del dispositivo carica il file css dedicato al range in uso.
  • Secondo passo: sfruttare la potenza del processore LESS. Ho preso il vecchio codice legacy e con un tool online l’ho trasformato da CSS a LESS. Niente di trascendentale, eh! Molte regole le ho dovute rivedere manualmente perchè la compilazione in LESS del tool in alcune circostanze era poco significativa. Poco male: ne ho approfittato per rivedere il vecchio codice, togliendo regole obsole e mettendo in pratica la metodologia SMACSS per organizzare il lavoro.
  • Terzo passo: rimpiazzare le regole in cui venivano definite altezze e larghezze fisse. Il punto più ostico è stato adeguare uno slider di immagini presente in home page in modo che fosse anch’esso responsive.
  • Quarto passo: box da 4 colonne nel desktop ma allo stesso tempo da 8 nel mobile. In alcuni punti del sito, come la pagina di dettaglio del prodotto, era indispensabile prevedere che la griglia del layout si comportasse diversamente nelle varie visualizzazioni, con molta più granularità di quello che mette a disposizione 960gs. Ho trovato molto utile il progetto fluidable.com che ho inglobato e personalizzato nel theme.
  • Quinto passo:  non chiudiamo fuori dalla porta le vecchie versioni di IE. Questo si risolve molto agilmente includendo delle librerie specifiche per i HTML5 Shiv e il supporto CSS3 con Selectivizr.

A conti fatti: con 5 giorni di lavoro abbiamo bonificato un aspetto penalizzante lato SEO. Rifare completamente il layout in termini di effort avrebbe comportato tempi superiori di almeno 6 volte.

Rispondi