Ottimizzazione dei siti per smartphone e tablet tramite CSS3

[Redazione di Hardware Upg]

Link all'Articolo: http://www.hwfiles.it/articoli/3605/...ss3_index.html

Lo sviluppo di siti web è cambiato radicalmente con la forte diffusione di tablet e smartphone. Ecco alcune problematiche osservate dal punto di vista degli sviluppatori

Click sul link per visualizzare l'articolo.

[magicken]

So che non c'entra tanto con l'articolo, ma giro con i debug javascript attivi ed ormai i siti, come questo, sono pieni di errori!!! Anche i siti dove ti insegnano javascript e tutto il resto sono stracarichi di errori!!!
Vi prego date un'occhiata al vostro sito! Fatelo per i poveri programmatori web che ogni giorno visitano il vostro sito. Grazie

[Fire-Dragon-DoL]

Credo ci sia un errore quando viene menzionato "controlli lato server, con javascript, [...]", ammenochè non si usi nodejs, javascript è lato server =D

Dopodichè, lo standard "de facto" per media query lato javascript è modernizr:

Modernizr.mq('only all'); // true if supported
Modernizr.mq('only screen and (max-width: 768px)')  // true

Esempio, con la prima controlliamo se la media query è supportata, con la seconda testiamo direttamente la media query.

In questo modo non è troppo difficile creare un sistema di query javascript.

Dopodichè, da web developer, volontariamente non faccio questi controlli perché è giusto che l'utenza migliori la propria situazione browser ^^

[Il_Baffo]

Originariamente inviato da Fire-Dragon-DoL

Credo ci sia un errore quando viene menzionato "controlli lato server, con javascript, [...]", ammenochè non si usi nodejs, javascript è lato server =D

non è un errore, c'è la virgola.

escludendo i siti semi-statici, una web application con singolo frontend resposive è probabilmente più facile da gestire in 2 tier separati.
Dico ciò, in quanto si rischia di caricare il dom con elementi e script non visualizzati anche perché le stesse funzionalità di JS cambiano e non sempre jquery è sufficiente.
Poi possono cambiare i comportamenti applicativi o i path di navigazione, si pensi all'hover che con il touch screen non c'è o all'upload di file che non è possibile da mobile nella maggior parte dei casi.
Tra l'altro le media query possono portare ad un utilizzo del processore più elevato consumando inutilmente batteria.
Credo che al momento ci sia ancora da lavorare molto prima di avere una soluzione universale.

[Fire-Dragon-DoL]

Originariamente inviato da Il_Baffo

non è un errore, c'è la virgola.

escludendo i siti semi-statici, una web application con singolo frontend resposive è probabilmente più facile da gestire in 2 tier separati.
Dico ciò, in quanto si rischia di caricare il dom con elementi e script non visualizzati anche perché le stesse funzionalità di JS cambiano e non sempre jquery è sufficiente.
Poi possono cambiare i comportamenti applicativi o i path di navigazione, si pensi all'hover che con il touch screen non c'è o all'upload di file che non è possibile da mobile nella maggior parte dei casi.
Tra l'altro le media query possono portare ad un utilizzo del processore più elevato consumando inutilmente batteria.
Credo che al momento ci sia ancora da lavorare molto prima di avere una soluzione universale.

No secondo me stai andando contro il principio per il quale è nato il responsive design: gestire l'applicazione in 2 tier separati E' costoso, il responsive design nasce per ridurre questi cosi. Altrimenti avremmo continuato ad avere un sito versione "mobile" e un sito versione "desktop".

Per quanto riguarda l'ottimizzazione, è molto più importante avere un singolo grosso file javascript e un singolo grosso css che averli separati. Facendo una manciata di calcoli a livello di consumi, per "scusare" l'utilizzo di fogli css separati, si dovrebbero avere dei pesi intorno ai 300KB (calcoli molto approssimativi).
Considerando quanto cicli della cpu vengono consumanti per effettuare una nuova richiesta al server e riceverla, conviene molto di piu fare un unico CSS.

Per quanto riguarda elementi del dom non visualizzati, il responsive design si avvale appositamente di questa tecnica per ottimizzare il tutto: un elemento del DOM non visualizzato consuma nulla a livello di rendering e molto poco per essere aggiunto all'html. Supponendo che tu voglia, per questo motivo, rimuovere dei pezzi di DOM obsoleti, ti troveresti lo stesso discorso di prima, ti servono 300KB di DOM (senza considerare immagini), o comunque intorno i 100 (peso fisico dell'html) per "compensare" questa cosa, per questo risulta irrilevante.

Le media query hanno un impatto infimo sulla batteria e sul processore, visto che sono paragonabili a delle if. Ottenere lo stesso risultato col javascript è equivalente se non piu oneroso, è solo sui PC desktop che puoi ridimensionare il browser, sul mobile non esiste questa cosa, la media query viene eseguita al primo caricamento e in caso di rendering aggiuntivi della pagina web (ovvero in caso di animazioni), il tutto può essere "aggirato" con le nuove animazioni dei CSS3 tipo transform3D che garntiscono di non renderizzare nuovamente l'intera pagina.

Per quanto riguarda la presenza/mancanza del touch, il responsive design si propone come un modo di "mixare" i due design (quello mobile e quello normale), quindi per forza di cose si giunge a dei compromessi, ma comunque non sono difficili da raggiungere: non utilizzare "hover" per eventuali menu a tendina, assicurarsi che non siano necessari "tooltip" o simili per agire sul sito e cose simili. Per questo abbiamo i siti web "mobile first", che sono appunto pensati prima per il mobile.

Dopodichè, per i CSS4 è previsto un draft (che potrebbe essere spostato nei css3) delle media query che propongono appunto un modo per capire se il dispositivo è provvisto di puntatore o meno.

Detto questo concludo con:

Il meccanismo prevede che l’utente, raggiungendo il sito principale, venga redirezionato sul sito mobile se si verificano certe condizioni (User Agent / Risoluzione schermo), e il meccanismo può essere implementato lato server, tramite JavaScript, oppure con una combinazione dei due

Avevo letto la frase come "implementato lato server, tramite javascript, oppure..." come fosse una precisazione della frase precedente (appunto tra due virgole), non come "questo, o quello, o quell'altro", ecco perchè non capivo bene :P

[Il_Baffo]

Originariamente inviato da Fire-Dragon-DoL

No secondo me stai andando contro il principio per il quale è nato il responsive design: gestire l'applicazione in 2 tier separati E' costoso, il responsive design nasce per ridurre questi cosi. Altrimenti avremmo continuato ad avere un sito versione "mobile" e un sito versione "desktop".

Non è un problema di pincipio ma di praticabilità.
Sulla base delle esperienze che ho avuto posso dire che fare 2 siti è meno costoso in temini di ore uomo e sbattimenti vari che fare un sito responsive (molto dinamico e cross-browser).
Lo stesso facebook o altri giganti usano dei siti paralleli per motivi prestazionali e di funzionalità diverse.

Originariamente inviato da Fire-Dragon-DoL

Per quanto riguarda l'ottimizzazione, è molto più importante avere un singolo grosso file javascript e un singolo grosso css che averli separati. Facendo una manciata di calcoli a livello di consumi, per "scusare" l'utilizzo di fogli css separati, si dovrebbero avere dei pesi intorno ai 300KB (calcoli molto approssimativi).
Considerando quanto cicli della cpu vengono consumanti per effettuare una nuova richiesta al server e riceverla, conviene molto di piu fare un unico CSS.

Pienamente d'accordo, infatti non ho mai parlato di includere più file.

Originariamente inviato da Fire-Dragon-DoL

Per quanto riguarda elementi del dom non visualizzati, il responsive design si avvale appositamente di questa tecnica per ottimizzare il tutto: un elemento del DOM non visualizzato consuma nulla a livello di rendering e molto poco per essere aggiunto all'html. Supponendo che tu voglia, per questo motivo, rimuovere dei pezzi di DOM obsoleti, ti troveresti lo stesso discorso di prima, ti servono 300KB di DOM (senza considerare immagini), o comunque intorno i 100 (peso fisico dell'html) per "compensare" questa cosa, per questo risulta irrilevante.

Qui mi sono spiegato male, il problema prestazionale in questo caso non è nel rendering ma nelle dimensioni del download e nei selettori jquery (per classe o per attributo) che devono comunque parsare gli elementi nascosti a meno di applicare degli scope ben precisi ai selettori.

Ho trovato un post che è molto più esplicativo di me
http://sixrevisions.com/mobile/respo...ot-the-future/

[Fire-Dragon-DoL]

Originariamente inviato da Il_Baffo

Non è un problema di pincipio ma di praticabilità.
Sulla base delle esperienze che ho avuto posso dire che fare 2 siti è meno costoso in temini di ore uomo e sbattimenti vari che fare un sito responsive (molto dinamico e cross-browser).
Lo stesso facebook o altri giganti usano dei siti paralleli per motivi prestazionali e di funzionalità diverse.


Pienamente d'accordo, infatti non ho mai parlato di includere più file.


Qui mi sono spiegato male, il problema prestazionale in questo caso non è nel rendering ma nelle dimensioni del download e nei selettori jquery (per classe o per attributo) che devono comunque parsare gli elementi nascosti a meno di applicare degli scope ben precisi ai selettori.

Ho trovato un post che è molto più esplicativo di me
http://sixrevisions.com/mobile/respo...ot-the-future/

Ma lo stesso articolo ti dice quello che ti sto dicendo io:

Certainly, for types of websites with limited user interaction — such as informational sites, blogs and news sites — responsive web design is a good, and often very practical, solution.

A livello di costi abbiamo questa sequenza (dal più economico al più costoso):

1. Design Classico
2. Design Responsive
3. 2 Layout

Non è possibile differentemente, proprio perchè due layout differenti vanno scritti entrambi da 0, mentre il responsive ti permette di riusare il codice del precedente.

Facebook non è un buon esempio che mi porti, hanno parecchi soldi da spendere, ovviamente possono permettersi di mantenere due layout. Il design responsive è un compromesso tra i due layout e il layout solo desktop.

Io pure ci ho messo di più la prima volta che ho fatto un layout responsive, ma poi ho iniziato ad avvalermi di librerie tipo Susy (anche se nel campo è piu famoso bootstrap, quello fa molte più cose ed è il motivo per il quale NON lo uso), che mi hanno semplificato l'approccio di moltissimo.
In aggiunta ai preprocessori tipo SCSS, diventa comodo scrivere le media query senza veramente nessuna difficoltà.

Dopodichè, grazie ai CSS framework che girano, il workflow è cambiato parecchio: la gente si lamenta di photoshop, molti lo hanno lasciato in favore di "sketch" (una app per Mac solamente, per ora), altri ancora semplicemente scrivono direttamente un prototipo, perchè sono diventati sufficientemente veloci (ovviamente il prototipo poi viene revisionato e ottimizzato).

Concludo per il problema dei selettori jquery, se usi una classe tipo quelle di bootstrap: http://twitter.github.io/bootstrap/s...tml#responsive (vai in fondo a "Responsive utility classes") puoi facilmente scrivere del codice javascript "selettivo" tipo:

$('.photobox:not(.hidden-phone)').photobox();

Questo per abilitare un semplice plugin javascript piuttosto carino, ovviamente è solo un esempio.

Concluco con quel che riguarda i caricamenti di immagini e cose simili, con una sintassi come i breakpoint di susy (molto carina devo dire), puoi facilmente far caricare delle immagini differenti (applicandole come sfondo) e effettivamente risparmiando in banda ( http://timkadlec.com/2012/04/media-q...ading-results/ )

[Tuvok-LuR-]

mi avete fatto venire in mente questo articolo che lessi tempo fà, al tempo delle elezioni americane metteva a confronto i siti di Obama (Responsive) e Romney (siti separati).
http://mobile.smashingmagazine.com/2...ial-smackdown/

La vittoria di Obama potrebbe suggerire che il primo approccio è il migliore

[Fire-Dragon-DoL]

Originariamente inviato da Tuvok-LuR-

mi avete fatto venire in mente questo articolo che lessi tempo fà, al tempo delle elezioni americane metteva a confronto i siti di Obama (Responsive) e Romney (siti separati).
http://mobile.smashingmagazine.com/2...ial-smackdown/

La vittoria di Obama potrebbe suggerire che il primo approccio è il migliore

Ma non ce ne è uno "migliore" direttamente, è una questione di budget.
Lo sai quanta gente ancora mi dice "no fallo solo desktop che risparmio" e io devo portargli il marketshare dei browser per spiegargli la differenza?

Certo che col sito di romney è abbastanza "triste", nel senso che la differenza tra i due layout è talmente infima da essere ridicolo l'averne usato due differenti.

[Tuvok-LuR-]

si vabbè era una battuta quella su Obama

Per quanto mi riguarda preferisco le tecniche responsive, a meno che il layout mobile debba avere un design o funzionalità completamente diverse...poi se il budget è poco bastano pochi accorgimenti per far diventare l'esperienza mobile non ottima ma quantomeno decente (spostare sidebar in alto etc...).

Poi anche all'interno del responsive stesso ci sono diverse scuole di pensiero, c'è chi sceglie il mobile-first e lavora aggiungendo e chi parte dalla versione desktop...due framework molto popolari, Foundation 4 e Bootstrap 3 stanno andando entrambi verso il primo approccio.

Poi se il mercato è quello italiani molte considerazioni vanno rivalutate perchè siamo sicuramente indietro sul mobile

[Fire-Dragon-DoL]

Originariamente inviato da Tuvok-LuR-

si vabbè era una battuta quella su Obama

Per quanto mi riguarda preferisco le tecniche responsive, a meno che il layout mobile debba avere un design o funzionalità completamente diverse...poi se il budget è poco bastano pochi accorgimenti per far diventare l'esperienza mobile non ottima ma quantomeno decente (spostare sidebar in alto etc...).

Poi anche all'interno del responsive stesso ci sono diverse scuole di pensiero, c'è chi sceglie il mobile-first e lavora aggiungendo e chi parte dalla versione desktop...due framework molto popolari, Foundation 4 e Bootstrap 3 stanno andando entrambi verso il primo approccio.

Poi se il mercato è quello italiani molte considerazioni vanno rivalutate perchè siamo sicuramente indietro sul mobile

Sono d'accordo con te.
In realtà in Italia siamo indietro su tutto il development web (quanta gente conosci che usa css preprocessor?), ed è stupida come cosa perchè la maggior parte di chi naviga in Italia lo fa su smartphone

[Il_Baffo]

Originariamente inviato da Fire-Dragon-DoL

Ma lo stesso articolo ti dice quello che ti sto dicendo io:

Certainly, for types of websites with limited user interaction — such as informational sites, blogs and news sites — responsive web design is a good, and often very practical, solution.

A livello di costi abbiamo questa sequenza (dal più economico al più costoso):

1. Design Classico
2. Design Responsive
3. 2 Layout

Non è possibile differentemente, proprio perchè due layout differenti vanno scritti entrambi da 0, mentre il responsive ti permette di riusare il codice del precedente.

ho scritto 2 volte che stavo parlando di web applications quando intendevo che il responsive è più costoso.
per i normali sitarelli va più che bene.

[Fire-Dragon-DoL]

Originariamente inviato da Il_Baffo

ho scritto 2 volte che stavo parlando di web applications quando intendevo che il responsive è più costoso.
per i normali sitarelli va più che bene.

La cosa è valida anche per le web application, se scrivi una web app "mobile first", non risulta affatto difficile aggiungere funzionalità desktop ammenoche non sono radicalmente differenti.

E' sempre una questione di design, semplicemente il responsive design è una valida alternativa, fino a che non hai un budget abbastanza vasto da coprire due layout interi (e il successivo mantenimento)