Viewport irritanti

“Il Web è un accordo.” Questa eloquente dichiarazione di Jeremy Keith riassume brillantemente l’equilibro che fa si che noi possiamo creare cose meravigliose. Ogni settimana, fanno la loro comparsa dei nuovi device che si differenziano tra loro per dimensione dello schermo e densità di pixel, per metodi di input e molto altro ancora. Noi developer e designer siamo d’accordo sull’utilizzo di standard per il markup, per lo stile e per i programmi che creiamo. I produttori di browser, a loro volta, accettano di supportare quegli standard e impostano i comportamenti di default in maniera appropriata, così che noi possiamo rispettare la nostra parte dell’accordo.

Questo accordo non è mai stato così importante.

Questo è il motivo per cui fa sempre male quando un produttore di device o di browser fa qualcosa che va contro il nostro accordo, in particolar modo quando si tratta di un chiaro e fidato amico del web, come Apple.

Sapete, il tablet più recente di Apple, l’iPad Mini, crea una situazione irritante: il suo viewport tag device-width ha come default gli stessi valori dell’iPad originale di Apple (768×1024 pixel), nonostante lo schermo del Mini sia fisicamente più piccolo del 40%. Questo significa che ogni pulsante, grafica, link e riga di testo di una pagina web sull’iPad Mini appare piccola, anche quando cerchiamo di fare la cosa giusta creando delle esperienze flessibili e multi-device.

Due iPad: uno è troppo piccolo.

Ma Cupertino non è l’unico colpevole là fuori: questo problema si è presentato fin da quando abbiamo cominciato ad usare la viewport e ha a che fare non solo con i pixel, ma anche con le nostre pratiche. Facciamo un passo indietro e cerchiamo di capire cosa causa realmente le sofferenze di oggi e cosa dobbiamo fare noi tutti.

Il problema dei pixel#section1

I problemi del momento con la viewport possono essere ricondotti ai pixel. Sì, quei piccoli elementi con cui lavoriamo ogni giorno.

La prima sfida che pongono i pixel è la quantità: più pixel ci sono nel display, più informazione si può mostrare. Ma oltre alla quantità di pixel fisici, il cui numero non può essere alterato, c’è un altro fattore da tenere in considerazione: la dimensione fisica dello schermo.

Immaginatevi un display largo due pollici (più o meno la larghezza dell’iPhone), come mostrato qui sotto.

Due dispositivi, ciascuno con un display largo due pollici. Quello sulla destra, (640×960), può contenere quattro volte la quantità di pixel che il dispositivo sulla sinistra può contenere nello stesso spazio (320×480).

Il primo dispositivo è di 320×480 pixel, il secondo di 640×960. Questo dà al secondo display quattro volte il numero di pixel del primo, ma li fa stare tutti nello stesso spazio fisico. La dimensione più piccola del pixel risulta nel contenuto, che è anche più piccolo, rendendolo più nitido ma anche più difficile da leggere.

Questo è esattamente quello che è successo sul Nokia E60. Nel 2005, la maggior parte dei display dei cellulari era larga circa un pollice e un quarto, con una media di 176 pixel per tale larghezza. Tuttavia, l’E60, che aveva un “enorme” display da 352×416 pixel, stipava il doppio dei pixel in una quantità di spazio simile. Il risultato: un display bellissimo, nitido, ma molto spesso difficile da leggere.

L’E60 introdusse anche un problema che ci è ora familiare: come gli utenti gestiscano la navigazione in “grandi” siti su un piccolo device. La soluzione di Nokia fu un nuovo browser: il Mini Map. Questo browser si comportava in maniera simile agli odierni browser degli smartphone, rendendo prima la pagina a dimensione completa, per poi scalarla fino a farla entrare nella dimensione di schermo disponibile. Sovrapposto a questo rendering c’era un riquadro rosso trasparente che poteva essere riposizionato usando il joystick del device. Cliccando sul joystick si zoomava nel contenuto indicato dal riquadro.

Facciano il loro ingresso le viewport#section2

Probabilmente uno dei primi usi commerciali di una viewport dinamica (una creazione progettata per cambiare dinamicamente la dimensione o per scalare l’area di schermo visibile per migliorare la user experience) fu Mini Map. Ma era ben lungi dall’essere l’ultima.

Nel 2007, Apple realizzò l’iPhone, un device ben più grande dell’E60, ma con un problema simile: anche su un display “enorme” da due pollici, navigare il “web reale” con un iPhone voleva dire caricare grandi pagine in un piccolo device. Apple scelse di risolvere questo problema attraverso una serie di miglioramenti attentamente orchestrati.

Il primo fu la creazione di una viewport virtuale simile a quella che Nokia aveva realizzato per Mini Map. Quando si imbatteva in siti desktop, il browser li avrebbe resi alla loro dimensione completa (basandosi su un canvas di defaulti di 960 pixel), per poi scalarli fino a riempire il display da due pollici. Gli utenti potevano quindi interagire con la pagina facendo scroll o zoom nelle aree di loro scelta.

Apple non si fermo qui. Sviluppò anche un nuovo meta tag viewport. I siti che non usano questo tag vengono resi utilizzando la viewport di default, ereditata dal web, di 980 pixel. Ma gli sviluppatori che optarono per l’uso del tag potevano dichiarare la viewport dei loro siti, inclusa l’impostazione della larghezza del valore device-width importante per tutti. Questo valore dice al browser: “Per favore, scegli una larghezza che si adatti meglio allo schermo di questo specifico device”.

Altri produttori di browser mobile seguirono rapidamente la guida di Apple. Ad oggi, praticamente tutti i browser mobile supportano il meta tag viewport, incluso il valore device-width. Questo allarga ulteriormente il campo di gioco: rispetta gli sforzi di quelli che si prendono il tempo di adattare i siti al web multi-device, mentre quelli che non hanno ancora fatto questa transizione ricevono ancora una esperienza di default “sufficientemente buona”.

Mini problemi#section3

Il valore che viene assegnato a device-width dai produttori di device e di browser è collegato direttamente alle dimensioni fisiche del device. I device più piccoli hanno bisogno di un valore device-width più piccolo (che risulta in un contenuto più grande). Impostate un valore troppo grande e la maggior parte del contenuto sarà troppo piccola per essere letta in maniera confortevole.

E questo è il motivo per cui l’iPad Mini di Apple ha una viewport irritante: usa la stessa device-width di 768 pixel dell’iPad normale, anche se la sua dimensione fisica è molto più piccola. Uno si aspetterebbe di vedere una device-width più in linea con quelle di tablet di dimensioni simili, come il BlackBerry PlayBook o la seconda generazione del Samsung Galaxy 7 (tra 500 e 600 pixel, come mostrato in questo grafico.

A causa di questa device-width, le pagine web appaiono più piccole del 27% sull’iPad Mini rispetto al Google Nexus 7 (calcolato basandosi sulla dimensione relativa dei pixel dei device), solo perché Apple ha deciso di descrivere la viewport del device con 768 pixel.

Risolvere il problema per la dimensione del contenuto#section4

Uno dei primi posti in cui questo causa problemi è il testo: più pixel in uno spazio più piccolo implicano che i font la cui dimensione è espressa in pixel appariranno minuscoli.

Ovviamente, molti di noi non danno più le dimensioni in pixel ai font: utilizziamo ora elementi di dimensioni relative come gli em, giusto? Solo che nemmeno così si risolve il problema questa volta…

Quando usiamo gli em, implicitamente ci fidiamo in una certa misura che la dimensione di base del font nel browser allo zoom di default, equivalente a 1em o al 100% in termini di unità, sia sufficientemente leggibile. Ma questo non è sempre il caso: il valore di font-size di base del browser (1em) equivale più o meno a 16 pixel. Questo rapporto funge da legame tra le unità assolute e relative, ma può variare da browser a browser.

Sull’iPad Mini, la font-size di base è esattamente 16 pixel. Questo valore avrebbe funzionato bene quando c’erano meno pixel nei nostri schermi, ma su un display ad alta densità, con una viewport definita in maniera impropria, risulta scomodamente piccola.

Tuttavia, non tutti i browser usano il rapporto 1:16 em-a-pixel. Il browser del Kindle Touch, ad esempio, ha una viewport ad alta densità, ma si adatta usando un rapporto 1:20, aumentando la dimensione del font di default di qualche pixel per favorire la leggibilità.

Questo potrebbe ancora non sistemare i problemi legati alla viewport dell’iPad Mini, ma almeno il contenuto dovrebbe essere leggibile.

Tre tablet da sette pollici: notate la differenza nella resa.

Ma perché Apple ha agito così?#section5

Per capire il motivo per cui Apple ha rilasciato un prodotto con una viewport così fastidiosa, non dobbiamo andare oltre le nostre abitudini.

Durante le fasi iniziali della prima release dell’iPad, i lavoratori del web in tutto il mondo si diedero da fare per adattare i siti affinché si vedessero bene sui loro nuovi tablet. Da qualche parte lungo il cammino molti di noi si sono adagiati insieme su nozioni basate sui pixel di design senza tabelle e tali nozioni sono risultate spesso in layout da 1024×768 pixel che avevano come preciso obiettivo questi device.

Se Apple avesse diminuito il valore di device-width per l’iPad Mini sulla base della sua dimensione fisica più piccola, avrebbe sicuramente generato una seconda corsa all’adattamento dei siti per tablet esistenti, assumendo che una viewport da 1024×768 sarebbe risultata inaspettatamente miserabile sul nuovo device.

In questo caso, la responsabilità va in due direzioni: i produttori di browser devono sì fornire delle dimensioni di base affidabili per la viewport e per il testo, ma noi sviluppatori dobbiamo anche smettere di cercare il controllo preciso fino al pixel sui nostri layout (il “controllo” è un’illusione, comunque).

Una strada da seguire#section6

L’unico modo per noi per andare avanti è unirci. In qualità di developers e designer, dobbiamo tenere fede alla nostra parte del patto ed essere consapevoli di come facciamo il nostro lavoro, ossia dobbiamo lasciar perdere una volta per tutte la nozione di precisione al pixel. Dobbiamo guadagnarci la fiducia dei produttori di browser, così che possano darci ascolto quando le cose sono francamente sbagliate. Speriamo che questo articolo spieghi in maniera sufficiente che noi stiamo cercando di fare la cosa giusta. Speriamo che i produttori di browser ce lo riconoscano e che agiscano di conseguenza.

Gli standard e la coerenza sono ora più che mai importanti. Per favore, fate in modo che i produttori di browser e i costruttori di device, come Apple, sappiano che noi facciamo affidamento sulla consistenza e sull’affidabilità delle decisioni che riguardano le viewport di default e il loro zoom. Vogliamo tener fede alla nostra metà del contratto e abbiamo bisogno che loro onorino l’altra metà del contratto con noi.

Muoviamoci verso il futuro, insieme.

Illustrazioni: {carlok}