Iniziare con RESS

Contenuto

• 01. Web design reattivo
• 02. Cliente, incontra il server
• 03. Il setup
• 04. Rilevamento delle funzionalità e rilevamento dei dispositivi
• 05. Il sito demo
• 06. WURFL.php
• 07. RESS
• 08. Immagini
• 09. La giostra
• 10. Annunci
• 11. Inclusione condizionale del contenuto
• 12. Prestazioni
• 13.Conclusione
• 14. Ulteriore lettura
• Questo mi piaceva? Leggi questo!

• Conoscenza necessaria: PHP di base, web design reattivo di base
• Richiede: PHP, Twitter Bootstrap, Modernizr, Swipe.js, WURFL
• Tempo del progetto: 2-4 ore

So che il nostro settore non ha bisogno di un altro acronimo, ma eccone uno in più per te: RESS. RESS sta per "Responsive Design + Server Side components" ed è Luke Wroblewski il colpevole di averti fatto imparare un altro termine. Non ha inventato qualcosa di nuovo quando ha scritto un articolo a riguardo a settembre, ma ha dato un nome a qualcosa che molti chiamavano prima una soluzione "ibrida".

L'idea alla base è che combiniamo tecniche di responsive web design e tecniche lato server per offrire un'esperienza ottimale per ogni dispositivo. Ciò significa che serviremo richieste leggermente diverse ad alcuni dispositivi per un determinato URL, ma utilizziamo comunque tecniche reattive per qualsiasi cosa finisca su quei dispositivi. La tecnica presentata in questo tutorial è una semplice soluzione RESS che ha lo scopo di farti iniziare in un breve lasso di tempo. Costruiremo un'unica pagina responsive che includa alcuni elementi di base sorprendentemente complessi da utilizzare su siti responsive: immagini, annunci e widget dei social media.

01. Web design reattivo

Il responsive web design non ha bisogno di presentazioni, ma probabilmente avrai notato che la maggior parte delle tecniche reattive utilizza solo codice lato client. E per una buona ragione. Il codice si basa su standard web e se un nuovo dispositivo o browser è correlato a questi standard, il nostro sito web continuerà a funzionare come previsto. E questo significa anche che abbiamo una base di codice per tutti i dispositivi. E questa parte è allo stesso tempo fantastica e un po 'spaventosa.

Funziona davvero bene in molti casi, ma vediamo anche alcuni casi in cui i browser meno capaci (spesso mobili) soffrono di troppa logica e contenuto, scarsa usabilità e un'esperienza complessivamente lenta.

02. Cliente, incontra il server

È qui che il server può dare una mano. Il modo tradizionale di creare soluzioni per dispositivi mobili o per una piattaforma specifica consiste nel creare un sito per dispositivi mobili separato o un'app. Entrambi i metodi sono personalizzati per il dispositivo specifico ed è anche il motivo per cui funzionano così bene per i dispositivi mobili (almeno dal punto di vista degli utenti finali). Entrambe le soluzioni hanno anche degli svantaggi, come sono sicuro che tu sappia, ma hanno alcune cose che molti siti web reattivi non hanno: ottimizzazione per il dispositivo e velocità.

Non è raro che un sito web reattivo abbia 2, 3 e persino 4 megabyte e abbia centinaia di richieste HTTP, e posso dirti subito che è troppo. L'idea principale del responsive web design non è quella di adattarlo a un dispositivo specifico, ma in alcuni casi ha davvero senso ottimizzare il server.

03. Il setup

Creeremo una semplice pagina PHP (che assomiglia molto alla prima pagina di una rivista ...). Il sito avrà un carosello di immagini, alcune pubblicità e alcuni plug-in dei social media. Ci concentreremo sul rendere il sito facile da configurare e utilizzeremo Twitter Bootstrap come framework reattivo. Useremo sia la funzionalità che il rilevamento del dispositivo. Utilizzeremo anche Modernizer per aiutare con il rilevamento delle funzionalità e WURFL per il rilevamento dei dispositivi. Rileveremo le dimensioni dello schermo del dispositivo sia lato server che lato client e le utilizzeremo per prendere decisioni su quali immagini, annunci e contenuti offriremo all'utente.

04. Rilevamento delle funzionalità e rilevamento dei dispositivi

Con questa configurazione abbiamo due fonti di informazioni sul browser. Modernizr è un framework di rilevamento delle funzionalità che semplifica il rilevamento delle funzionalità del browser. Esegue semplicemente un test nel browser per ottenere una risposta booleana come output: "X funziona?" e la risposta è per lo più "vero" o "falso". Il bello di questo è che funziona su tutti i browser, anche quelli che non sono ancora stati rilasciati. Ma non ha molta granularità e le funzionalità disponibili sono limitate a ciò che è possibile per testare le funzionalità. Esempi di funzionalità che è possibile testare includono boxshadow, csstransitions, touch, rgba, geolocalizzazione e così via.

Il rilevamento del dispositivo, d'altra parte, è qualcosa di diverso. Succede tutto sul server ed è un framework che analizza l'intestazione HTTP del dispositivo. Quindi cerca in un database di dispositivi noti e restituisce una serie di funzionalità per quel dispositivo. La bellezza di questo è che si tratta di un database di informazioni che vengono raccolte e gestite da esseri umani e può contenere informazioni incredibilmente dettagliate sulle capacità che è attualmente impossibile testare. Gli esempi includono il tipo di dispositivo (desktop, TV, cellulare, tablet), il nome commerciale del dispositivo, il supporto del codec video e così via.

Lo svantaggio è che l'analisi dello User Agent può andare storta alcune volte e molti dispositivi tendono ad avere una stringa UA non univoca oa falsificare la stringa UA, ma l'utilizzo di un framework ridurrà al minimo il rischio di falsi rilevamenti. Il rilevamento del dispositivo e il rilevamento delle funzionalità non possono essere realmente impostati l'uno contro l'altro in quanto non sono due facce della stessa medaglia.

05. Il sito demo

Cominciamo a scrivere codice! Ti mostrerò come utilizzare RESS per risolvere tre problemi comuni: annunci, immagini e plug-in dei social media. Il sito demo che costruiremo è su andmag.se/ress/ e tutto il codice è disponibile in un repository Github.

Inizieremo scaricando e configurando gli strumenti che utilizzeremo. Non ci concentreremo troppo sul codice reattivo in questo tutorial e useremo Twitter Bootstrap per aiutarci là fuori.

Devi scaricare i file Bootstrap e decomprimere il pacchetto. Bootstrap contiene una cartella JS, CSS e IMG e la metteremo in una cartella "bootstrap" nel nostro progetto vuoto.

Successivamente, dobbiamo attivare e avviare il rilevamento del dispositivo. Per questo utilizzeremo l'offerta ScientiaMobile WURFL Cloud. WURFL è l'acronimo di Wireless Universal Resource File e WURFL è uno dei sistemi di rilevamento dei dispositivi più utilizzati in circolazione. Devi registrarti con ScientiaMobile per ottenere una chiave API e quindi puoi scaricare il client cloud. Esistono diverse versioni a seconda del traffico del sito e del numero di funzionalità desiderate. Sto usando la versione standard, ma c'è anche una versione gratuita che puoi usare. Dopo esserti registrato, vai alle impostazioni del tuo account e scarica il codice client PHP e metti il ​​codice in una cartella chiamata "WURFL".

Al termine, siamo pronti per iniziare ad aggiungere il codice. Ci concentreremo sul mantenere le cose semplici e creeremo una semplice struttura di file. Creeremo anche le nostre cartelle CSS, JavaScript e di immagini. Creeremo solo una pagina iniziale in questo esempio e tutto il codice va in index.php. Useremo il metodo "include" di PHP per includere altri file per evitare di avere tutto il codice nello stesso file. index.php include header.php e footer.php insieme ai frammenti della pagina. header.php include anche WURFL.php e RESS.php. Presto vedremo cosa faranno questi file.

06. WURFL.php

WURFL.php include il codice per inizializzare il client WURFL e memorizzerà le funzionalità a cui hai accesso in un array PHP.

? php
// Include il client cloud WURFL
require_once ’WURFL / Client / Client.php’;

// Crea un oggetto di configurazione
$ config = nuovo WurflCloud_Client_Config ();

// Imposta la tua chiave API WURFL Cloud - Cambia questa chiave con la tua chiave
$ config-> api_key = ’12345: abcDEFabcDEFabcDEFabcDEF’;

// Crea il client cloud WURFL
$ client = nuovo WurflCloud_Client_Client ($ config);

// Rileva il tuo dispositivo
$ client-> detectDevice ();
?> var13 ->

Dopo che il client è stato inizializzato, possiamo iniziare a ottenere informazioni sul dispositivo che sta attualmente utilizzando il sito in qualsiasi punto del codice:

? php
$ client-> getDeviceCapability (’brand_name’);
?> var13 ->

07. RESS

Creeremo ora un modo per combinare il rilevamento di client e server. Useremo un cookie per condividere le informazioni dal client al server. La capacità più importante per questo test è la larghezza dello schermo, quindi creiamo un file RESS.php con un po 'di JavaScript che rileva la dimensione dello schermo per noi. Creiamo anche uno spazio dei nomi RESS e un file writeCookie () metodo di supporto. Possiamo quindi ottenere la larghezza e scrivere il cookie al client:

tipo di script = "text / javascript">

RESS = {};

RESS.writeCookie = funzione (nome, valore) {// codice cookie}

// Memorizza la larghezza in un cookie
RESS.storeSizes = function () {
// Ottieni la larghezza dello schermo
var width = window.innerWidth;

// Imposta un cookie con le funzionalità lato client.
RESS.writeCookie ("RESS", "width." + Width);
}

RESS.storeSizes ();
/ script>

Registriamo anche un evento onresize, in modo da poter scrivere il cookie quando la finestra ha cambiato dimensione o il dispositivo ha cambiato orientamento, non solo al caricamento di una nuova pagina. L'evento onresize tende ad essere molto felice, quindi aspettiamo un secondo prima di scrivere il nuovo valore.

RESS.isResizeActive = false;

window.onresize = function (event) {
if (! RESS.isResizeActive) {
RESS.isResizeActive = true;

// assicurati di non farlo troppo spesso, aspetta 1 secondo ...
window.setTimeout (function () {
RESS.storeSizes ();
RESS.isResizeActive = false;
}, 1000);
}
}

Successivamente, abbiamo bisogno del codice PHP per leggere il cookie, in modo da poter rendere disponibile anche la larghezza dello schermo lato client.

$ RESSCookie = $ _COOKIE [’RESS’];
if ($ RESSCookie) {
$ RESSValues ​​= explode (’|’, $ RESSCookie);
$ featureCapabilities;
foreach ($ RESSValues ​​as $ RESSValue) {
$ capacità = esplosione (’.’, $ RESSValue);
$ funzionalitàCapabilities [$ capacità [0]] = $ capacità [1];
}
}

Otterremo anche la larghezza del lato server come riserva. Questo è importante in quanto verrà utilizzato quando non abbiamo accesso al cookie al primo caricamento della pagina o se i cookie o JavaScript sono disabilitati.

$ WURFLWidth = $ client-> getDeviceCapability (’max_image_width’);
if ($ client-> getDeviceCapability (’ux_full_desktop’)) {
$ WURFLWidth = 1440;
}

La larghezza dello schermo predefinita di WURFL per "desktop" è 600, quindi ci assicuriamo di impostare per impostazione predefinita una dimensione grande e lasciare che il codice reattivo gestisca le dimensioni dello schermo se è più piccola. E in base a questo ora possiamo ottenere la larghezza dello schermo lato server e con un fallback alla larghezza WURFL:

$ defaultWidth = ($ featureCapabilities ["larghezza"]? $ featureCapabilities ["larghezza"]: $ WURFLWidth);

08. Immagini

Stanco di sentire ancora "immagini reattive"? Pensavo così. La discussione su come gestire le immagini per diverse risoluzioni dello schermo è in corso da un po 'di tempo. Mat Marquis riassume tutto bene nel suo articolo Lo stato delle immagini reattive.

Utilizzeremo la nostra larghezza dello schermo RESS per offrire immagini diverse a schermi di dimensioni diverse. Stiamo utilizzando immagini Flickr per il nostro carosello e scegliamo tre delle loro dimensioni predefinite: 320, 500, 640 e creiamo una nuova dimensione: 770, che è il massimo del nostro carosello. Ci sono alcune differenze nella larghezza del carosello in diversi breakpoint e cerchiamo di considerarlo nell'algoritmo. Nota anche che serviremo un'immagine leggermente più grande di quella che useremo. Questo perché vogliamo che l'immagine funzioni bene anche in modalità orizzontale. Se abbiamo una larghezza dello schermo di 320 pixel, l'altezza o la larghezza verticale è 480, quindi l'immagine 500 è la migliore corrispondenza per un dispositivo del genere (in base ai formati Flickr). C'è spazio per l'ottimizzazione qui e puoi cambiare il codice e pubblicare immagini più piccole se lo desideri. Ecco il codice:

// seleziona la versione corretta dell'immagine
if ($ defaultWidth 320) {
// schermi piccoli ottengono 320 immagini
$ imageVersion = "320";
} altrimenti if ($ defaultWidth 500) {
// 320-499 schermate ottengono 500
$ imageVersion = "500";
} altrimenti if ($ defaultWidth = 1024) {
// gli schermi tra 500 e 1024 ottengono 640
$ imageVersion = "640";
} altro {
// qualsiasi cosa> = 1024 ottieni 770
$ imageVersion = "770";
}

Esporremo ora i nostri calcoli in una variabile RESS globale:

$ RESS globale;
$ RESS = array (
"width" => $ defaultWidth,
"imageVersion" => $ imageVersion);

E ora possiamo facilmente ottenere i valori lato server e usarli nel nostro codice.

? php echo $ RESS ["larghezza"]?> var13 ->
? php echo $ RESS ["imageVersion"]?> var13 ->

09. La giostra

Ok, ora abbiamo tutto configurato e siamo pronti per iniziare a usarlo. Per mettere un carosello sul sito useremo swipe.js e abbiamo anche bisogno di Modernizr per sapere se dobbiamo abilitare o meno le transizioni CSS. Inoltre, proveremo a scegliere la versione dell'immagine corretta per il dispositivo. Usiamo la versione a quattro immagini che abbiamo deciso e le memorizziamo nella nostra cartella img:

img1_320.webp
img1_500.webp
img1_640.webp
img1_770.webp

Sulla base di ciò, ora possiamo utilizzare la nostra variabile RESS per scegliere la versione corretta:

img src = "img / img1_? php echo $ RESS [" imageVersion "]?>. jpg" alt = "Prima immagine">

Dopo aver applicato alcuni stili, ora abbiamo un carosello funzionante con dimensioni dell'immagine variabili! Puoi anche avere un diverso ritaglio dell'immagine per diverse dimensioni dello schermo, se lo desideri. Vedi il codice completo per il carosello qui.

10. Annunci

Uno dei problemi con le reti pubblicitarie è che la maggior parte di esse fornisce solo annunci di dimensioni fisse. Includeremo quegli annunci di dimensioni fisse nel nostro sito reattivo, ma utilizziamo RESS per includere dimensioni diverse a seconda delle dimensioni dello schermo con cui abbiamo a che fare. Utilizzeremo Google AdSense e inseriremo un annuncio nell'intestazione della pagina accanto al logo. Usiamo la stessa tecnica di quando servivamo diverse versioni di immagini. Avremo un annuncio di 320px sopra il logo su schermi piccoli, un annuncio più grande di 468px sul lato destro del logo su schermi medi e infine un annuncio grande di 728px sul lato destro del logo per schermi di grandi dimensioni. Ecco il codice:

? php
if ($ RESS ["larghezza"]> = 320 && $ RESS ["larghezza"] = 640) {
?> var13 ->
div>
? php include "fragments / ads / 320.php"?>
/ div>
? php
}?>

div id = "site-logo">
a href = "/ ress /"> RESS / a>
/ div>

div>
? php
if ($ RESS ["larghezza"]> = 980) {
?> var13 ->
div>
? php include "fragments / ads / 728.php"?>
/ div>
? php
} altrimenti se ($ RESS ["larghezza"]> = 768) {
?> var13 ->
div>
? php include "fragments / ads / 468.php"?>
/ div>
? php
}
?> var13 ->
/ div>

Tieni presente che abbiamo una media query che nasconderà l'annuncio se l'annuncio scende al di sotto della larghezza specificata. L'annuncio è visibile per impostazione predefinita e lo nascondiamo per schermi di dimensioni inferiori a 980 px, in altre parole, max 979 pixel. L'annuncio viene nascosto se la larghezza del dispositivo diminuisce senza ricaricare, ma se ricarichi la pagina otterrai una dimensione dell'annuncio diversa.

@media screen e (larghezza massima: 979 px) {
.max-980 {
display: nessuno! importante;
}
}

Nascondere i contenuti senza visualizzare nessuno è normalmente un grande "no-no", ma ricorda che è nascosto solo se le dimensioni dello schermo cambiano drasticamente e sono solo gli sviluppatori di web design reattivi che cambiano la finestra del browser su ogni sito web che vedono comunque ...

11. Inclusione condizionale del contenuto

Come ormai inizi a capire, possiamo facilmente scrivere codice condizionale sul server e possiamo fare molte cose sporche ... Una cosa è rimuovere il contenuto per schermi più piccoli. Alcuni tipi di contenuti semplicemente non valgono il costo sui dispositivi mobili, come i widget dei social media in questo caso. Possiamo discutere sulla rimozione di tutti insieme dal nostro sito (probabilmente dovremmo). Ecco il codice per la colonna di destra della nostra pagina:

? php include "fragments / archive.php"?>
? php if ($ RESS ["width"]> = 768) {?> var13 ->
div>
h2> Sociale / h2>
? php include "fragments / twitter-search.php"?>
? php include "fragments / facebook.php"?>
/ div>
? php}?>

Quindi includiamo questi frammenti solo se lo schermo è di 768 pixel o superiore. Avere la logica impostata su una regola del genere significa che facciamo un passo fuori dal mondo completamente reattivo per ottenere un miglioramento delle prestazioni sui dispositivi mobili. Dispositivi come il Kindle Fire che ha uno schermo da 600x1024px non caricheranno i frammenti di Twitter e Facebook in verticale, ma li caricherà in orizzontale. Accadranno cose strane come questa, ma questo è il prezzo che dobbiamo pagare. Fortunatamente esiste una soluzione e si chiama miglioramento progressivo. Dovrebbe essere facile caricare il contenuto mancante una volta che lo schermo sarà nuovamente ingrandito. Di nuovo, dovresti pensarci due volte su queste cose poiché probabilmente confonderà il tuo utente, ma continua a leggere e dai un'occhiata al guadagno in termini di prestazioni di questa tecnica.

Attualmente stiamo utilizzando la larghezza dello schermo per tutte le nostre decisioni, ma potremmo anche utilizzare altre funzionalità come la nuova API Network Information.

12. Prestazioni

In che modo il nostro approccio influisce sulle prestazioni del sito? Di seguito sono riportati alcuni test da tre diversi punti di interruzione, chiamiamoli Grande, Medio e Piccolo. (Si noti che il codice sul sito demo non è minimizzato per facilitarne la lettura e il debug):

• Grande: 84 richieste, 696 KB trasferiti | 2-6s (onload: 1-3s, DOMContentLoaded: 600ms-3s).
• Medio: 84 richieste, 685 KB trasferiti | 2-6s (onload: 1-3s, DOMContentLoaded: 600ms-3s).
• Piccolo: 25 richieste, 221KB trasferiti | 560 ms (caricamento: 580 ms, DOMContentLoaded: 320 ms).

Quindi il sito grande è tre volte più grande del sito piccolo, sia in termini di dimensioni che di numero di richieste! La differenza nella dimensione dell'immagine dalle tre immagini da 500 px all'immagine più grande da 770 px è di 60 KB. Quindi sono i widget sociali che stanno effettivamente rendendo grande il sito, non le immagini. Ma le dimensioni in sé non sono l'unico problema qui, anche la quantità di connessioni è fastidiosa e provengono solo dai widget sociali. Le immagini sono anche fortemente ottimizzate dalla versione originale utilizzando Photoshop e ImageOptim.

13.Conclusione

Ora abbiamo una configurazione RESS di base e dovrebbe essere facile includerla nel tuo sito corrente o anche in un CMS PHP come Wordpress o Drupal. La tecnica può andare contro alcune delle cose che hai imparato nella tua classe RWD, ma in molti casi è molto più efficiente (sia per te che per il browser) mettere la logica sul server. Ho anche scoperto che questo offre una maggiore flessibilità poiché puoi aggiungere o rimuovere contenuti per dispositivi specifici e puoi utilizzare soluzioni di terze parti che non sono ottimizzate per i dispositivi mobili offrendo soluzioni alternative su schermi di piccole dimensioni.

Il miglioramento progressivo è una parte centrale del responsive web design e può anche essere utilizzato insieme a RESS e un'estensione naturale alla nostra demo di inclusione di contenuto consiste nell'includere contenuto con JavaScript quando le dimensioni dello schermo aumentano. È inoltre necessario essere consapevoli del fatto che ora stiamo servendo contenuti leggermente diversi sullo stesso URL e che ciò può influire sulla cache. Esistono soluzioni su come affrontare questo problema, ma ciò non rientra nell'ambito di questo tutorial.

14. Ulteriore lettura

Potresti anche dare un'occhiata ad altri lavori su RESS: Detector di Dave Olssen e la presentazione Adaptation: Why responsive design inizia effettivamente sul server da Yiibu così come l'articolo RESS originale di Luke Wroblewski.

Anders M Andersen - andmag.se - vive, lavora e suona a Stoccolma, in Svezia. Si occupa di sviluppo mobile sin da WML e attualmente sta cercando di far funzionare meglio quella "cosa reattiva" per i dispositivi mobili. Resta al passo con Anders su Twitter come @andmag.

Questo mi piaceva? Leggi questo!

• Brillante selezione di tutorial su Wordpress
• I nostri caratteri web preferiti e non costano un centesimo
• Scopri le prospettive per la realtà aumentata