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.
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.