Non molto tempo fa, ho avuto l’onore ed il piacere di collaborare con un grande professionista, Massimo Caselli, IT manager di CarAffinity. Il progetto a cui ho personalmente lavorato ( per la versione desktop ) è la realizzazione “from scratch” del sito web della startup del settore automotive. Si tratta, semplificando, di un social network con un focus specifico nel settore delle auto, che citavo nel precedente articolo: Il responsive design è sbagliato ( se non sai come farlo ).

Dopo che Massimo ha letto l’articolo, subito è nata l’idea di parlare più concretamente di che cosa è questa tecnologia Smith. Questo mi permette di spiegare in questa sede perchè è potente e dovresti utilizzarla anche tu per avere un vero vantaggio in termini di performance, rispetto ai tuoi concorrenti. Penso possa esserti utile

Come funziona la tecnologia Smith

Cominciamo col chiarire una cosa: la tecnologia Smith ufficialmente “non esiste”. Ancora non è utilizzata, anche se abbiamo gli strumenti per applicarla. Non viene utilizzata perchè, molto semplicemente, gli opinion leader del frontend non ci sono ancora arrivati.

In poche parole: le persone influenti che parlano di frontend developement a livello internazionale non hanno la conoscenza/voglia/quello che vuoi di applicare questa tecnologia ( e in Italia ancora di più.. anche se mi sorge una domanda: esistono persone davvero autorevoli nel mondo frontend, per di più su magento? Mi piacerebbe conoscerle ).

La tecnologia Smith è una variante dell’attuale tecnologia responsive e promette di migliorare le performance della pagina in modo potente ed efficace.

L’attuale tecnologia responsive, semplificando e banalizzando ( ma per farti capire ) funziona così:

  • le stesse risorse vengono scaricate dall’utente per i contenuti ( stesse immagini e immagini sfondo via css per desktop, smartphone e tablet  )
  • le stesse risorse vengono scaricate dall’utente per l’interazione e lo stile ( stessi javascript e css caricati per desktop, smartphone e tablet )
  • lo stesso DOM viene caricato uguale per desktop, smartphone e tablet e, se vogliamo mostrare contenuti diversi in base al dispositivo, questi vanno nascosti via css e mostrati all’occorrenza

Per scendere ancora di più nel dettaglio tecnico, ho creato uno schema che mostra come funzionano, paragonando il vecchio responsive con Smith, partendo da quando il browser effettua la richiesta al server fino ad arrivare al momento in cui la pagina viene scaricata ed eseguita.

Schema: vecchio responsive VS Smith ( nuovo responsive )

Responsive schema. vecchio vs Smith ( nuovo )

Come ho usato Smith su CarAffinity

Non molto tempo prima di iniziare lo sviluppo frontend, quando eravamo ancora in fase di analisi, ho parlato con Massimo di questa tecnologia. Da tecnico interessato alle performance, è stato entusiasta di questa possibilità. La sua vasta esperienza nello sviluppo backend, gli ha permesso di potermi dire “al volo” che esisteva la possibilità di applicare questa tecnologia anche a .NET, linguaggio di casa Microsoft con cui è stato sviluppato il social network.

La cosa che ho fatto subito dopo è stato verificare la disponibilità di un compilatore per SASS, che mi avrebbe permesso di risparmiare tempo e scrivere buon codice.
Abbiamo creato prima di tutto dei file bundle per le risorse CSS. La definizione di bundle CSS è: un file css costruito da vari pezzi di altri css. Oggi, nel 2015, questa pratica dovrebbe essere lo standard d’eccellenza quando si sviluppa, ma non vedo ancora raggiunta una massa critica di designer e sviluppatori frontend che la utilizzano, anzi. Vedo spesso grossi file css dove dentro c’è tutto lo stile del sito. Pessimo, davvero pessimo. Mi sento quindi in dovere di affrontare più nel dettaglio questo argomento.
Sono partito iniziando a pensare la struttura di files necessaria per includere solo quello che davvero serve lato CSS.
Abbiamo creato prima di tutto dei file bundle per le risorse CSS. Ad esempio, il file css della homepage è composta da:

  • gli elementi in comune presenti in tutto il sito ( ad esempio: header, footer )
  • gli elementi specifici presenti solo nella homepage

Il risultato è un file css di soli 20Kb!

Lo stesso procedimento è stato fatto per i file javascript, ho creato dei bundle per:

  • il file javascript da includere in tutte le pagine, contenenti script per elementi sempre presenti
  • il file javascript per la singola pagina ( ad esempio: home )
  • la libreria modernizr

Bundle CSS

Se volessimo fare un esempio, potremmo prendere di nuovo CarAffinity. Lavorando con Sass, ho creato una struttura davvero molto basic, ma che fa il suo “sporco” lavoro.
La struttura dei file css è così composta:

  1. header.sass
  2. footer.sass
  3. home.sass
  4. common.sass

Sono sicuro che agli sviluppatori Ruby questo tipo di approccio non è per nulla nuovo, anzi. Si tratta dello standard, su Ruby, che integra perfettamente un compilatore Sass/Scss.
Se ci pensi, è chiaro quanto questo modo di creare i partial sia ottimizzato. In sostanza, il file css finale della home, è costituito dai file elencati. Header
e footer si capiscono senza bisogno di spiegazioni. Common è il file sass ( e quindi CSS ) che definisce lo stile per tutti quegli elementi che si possono trovare in tutte le pagine e che vengono ripetutamente utilizzati, mentre home.sass è un file che descrive le specificità della homepage.

Ad esempio, nella home di CarAffinity ci sono dei contenuti ( come il box di ricerca ) che non compaiono in nessun altra pagina del sito e che hanno uno stile unico. In questo caso, il buon senso ci dice che quel file css servirà solo in homepage e, se lo includessimo in altre pagine, sarebbe letteralmente uno spreco di risorse e di banda.

Riconoscimento del device

La parte successiva riguarda il riconoscimento dei vari dispositivi. Tutti sappiamo cosa è lo User Agent? Cito Wikipedia:

Quando gli utenti di Internet visitano un sito web, una stringa di testo è solitamente inviata per fare identificare al server lo user agent. Questo fa parte della richiesta HTTP, con prefisso “User-agent:” o “User-Agent:” e tipicamente include informazioni come il nome dell’applicazione client, la versione, il sistema operativo e la lingua. I bot spesso includono anche l’indirizzo web e la mail del proprietario, in modo tale che l’amministratore del sito possa contattarlo.

Veniamo quindi al succo tecnico della parte un po’ più backend e relativa a .NET.

Riconoscimento dispositivo in .NET MVC 5

di Massimo Caselli

L’aspetto più complesso dell’implementazione della tecnologia Smith è rappresentato, di fatto, dal riconoscimento del dispositivo che sta accedendo al sito web e, in funzione della tipologia, visualizzare il layout corretto.
Lo stack di default di MVC 5 (in realtà già dal 4 in poi) consente di servire i files di layout “standard” e “mobile”.
Prendiamo ad esempio la home page. In un contesto semplificato è composta da:

  • /Views/Shared/_Layout.cshtml (layout del sito web)
  • /Views/Home/Index.cshtml (contenuto effettivo della home page)

Nel caso di carAffinity.it si è deciso di utilizzare due differenti layout, uno specifico per smartphone, ed uno per desktop e tablet (con alcuni adattamenti responsive in contesto di tablet in verticale).
Banalmente, creando i files:

  • /Views/Shared/_Layout.Mobile.cshtml
  • /Views/Home/Index.Mobile.cshtml

Apparentemente si otteneva il risultato desiderato, tuttavia il meccanismo di riconoscimento di MVC 5 è piuttosto inaffidabile, infatti se si accedeva alla home page del sito web con un ipad, veniva erroneamente mostrato il layout mobile.
A questo punto si è reso necessario introdurre un componente in più, ovvero un database di riconoscimento dispositivi affidabile e supportato da MVC di Microsoft.
WURL ( http://wurfl.sourceforge.net/ )
WURL è un database opensource di devices che consente di riconoscere il dispositivo e le sue caratteristiche in base allo USER AGENT del chiamante.
Per integrarlo all’interno di MVC 5 sono necessari pochissimi passaggi che andiamo a vedere di seguito.

Installazione del package tramite NUGET

Dalla console di nuget in visual studio, sulla nostra webapplication:
Install-Package WURFL_Official_API

Una volta installato il package all’interno della soluzione va indicato a MVC come utilizzarlo.
Per l’implementazione vi rimando alla guida ufficiale: http://wurfl.sourceforge.net/dotnet_index.php

Tuttavia in www.caraffinity.it avevamo la necessità di alterare il comportamento standard WURFL per limitare la versione mobile ai soli dispositivi smartphone.
Abbiamo pertanto modificato lo snippet di codice che WURFL fa aggiungere nel Global.asax in Application_Start:

[syntax type=”html”]
…. codice standard WURL ….

// Rimuoviamo la configurazione di default che prevede oltre al DisplayMode standard, anche quello per Mobile:
var mobileModel = DisplayModeProvider.Instance.Modes.FirstOrDefault(a => a.DisplayModeId == “Mobile”);
if (mobileModel != null)
{
DisplayModeProvider.Instance.Modes.Remove(mobileModel);
}
// Aggiungiamo il DisplayMode “Mobile” solo nel contesto in cui per WURFL il dispositivo è di tipo “is_smartphone” == “true”
DisplayModeProvider.Instance.Modes.Insert(0, new DefaultDisplayMode(“Mobile”)
{
ContextCondition = Context => WURFLManagerBuilder.Instance.GetDeviceForRequest(Context.Request.UserAgent).GetCapability(“is_smartphone”) == “true”
});
// Analogamente, forziamo MVC ad usare il layout di default (quello per i desktop, per intenderci), qualora per WURFL il dispositivo abbia la caratteristica di “is_tablet” == “true”
DisplayModeProvider.Instance.Modes.Insert(1, new DefaultDisplayMode(string.Empty)
{
ContextCondition = Context => WURFLManagerBuilder.Instance.GetDeviceForRequest(Context.Request.UserAgent).GetCapability(“is_tablet”) == “true”
});
[/syntax]

AGGIORNAMENTO DB USER AGENT
Per aggiornare il database di WURL è necessario mantenere aggiornato il package NUGET.
Ad ogni aggiornamento, se previsto dal pacchetto stesso, sarà aggiornato il file inserito di default in “App_Data/wurfl-latest.zip”, ovvero il file XML con la descrizione di ogni dispositivo in funzione dello USER AGENT.

Questa è la tecnologia Smith applicata a .NET e al progetto CarAffinity.

Devi sapere che esattamente la stessa tecnologia ( implementata in modo diverso in PHP ) è disponibile in Magento.

Se vuoi imparare ad applicarla, ti consiglio di iscriverti alla newsletter, per rimanere sempre aggiornato e ricevere contenuti utili e guide su Magento Frontend.