{"id":338,"date":"2013-01-04T08:45:40","date_gmt":"2013-01-04T07:45:40","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/viewport-irritanti\/"},"modified":"2013-01-04T08:45:40","modified_gmt":"2013-01-04T07:45:40","slug":"viewport-irritanti","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/viewport-irritanti\/","title":{"rendered":"Viewport irritanti"},"content":{"rendered":"
\n

\u201cIl Web \u00e8 un accordo.\u201d Questa eloquente dichiarazione<\/a> 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\u00e0 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\u00ec che noi possiamo rispettare la nostra parte dell’accordo.<\/p>\n

Questo accordo non \u00e8 mai stato cos\u00ec importante.<\/p>\n

Questo \u00e8 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.<\/p>\n

Sapete, il tablet pi\u00f9 recente di Apple, l’iPad Mini, crea una situazione irritante: il suo viewport tag device-width<\/code> ha come default gli stessi valori dell’iPad originale di Apple (768×1024 pixel), nonostante lo schermo del Mini sia fisicamente pi\u00f9 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.<\/p>\n

<\/a><\/p>\n

Due iPad: uno \u00e8 troppo piccolo.<\/p>\n<\/div>\n

Ma Cupertino non \u00e8 l’unico colpevole l\u00e0 fuori: questo problema si \u00e8 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.<\/p>\n<\/div>\n

\n

Il problema dei pixel<\/h2>\n

I problemi del momento con la viewport possono essere ricondotti ai pixel. S\u00ec, quei piccoli elementi con cui lavoriamo ogni giorno.<\/p>\n

La prima sfida che pongono i pixel \u00e8 la quantit\u00e0: pi\u00f9 pixel ci sono nel display, pi\u00f9 informazione si pu\u00f2 mostrare. Ma oltre alla quantit\u00e0 di pixel fisici, il cui numero non pu\u00f2 essere alterato, c’\u00e8 un altro fattore da tenere in considerazione: la dimensione fisica dello schermo.<\/p>\n

Immaginatevi un display largo due pollici (pi\u00f9 o meno la larghezza dell’iPhone), come mostrato qui sotto.<\/p>\n

<\/a><\/p>\n

Due dispositivi, ciascuno con un display largo due pollici. Quello sulla destra, (640×960), pu\u00f2 contenere quattro volte la quantit\u00e0 di pixel che il dispositivo sulla sinistra pu\u00f2 contenere nello stesso spazio (320×480).<\/p>\n<\/div>\n

Il primo dispositivo \u00e8 di 320×480 pixel, il secondo di 640×960. Questo d\u00e0 al secondo display quattro volte il numero di pixel del primo, ma li fa stare tutti nello stesso spazio fisico. La dimensione pi\u00f9 piccola del pixel risulta nel contenuto, che \u00e8 anche pi\u00f9 piccolo, rendendolo pi\u00f9 nitido ma anche pi\u00f9 difficile da leggere.<\/p>\n

Questo \u00e8 esattamente quello che \u00e8 successo sul Nokia E60<\/a>. 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\u00e0 di spazio simile. Il risultato: un display bellissimo, nitido, ma molto spesso difficile da leggere.<\/p>\n

L’E60 introdusse anche un problema che ci \u00e8 ora familiare: come gli utenti gestiscano la navigazione in \u201cgrandi\u201d 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.<\/p>\n<\/div>\n

\n

Facciano il loro ingresso le viewport<\/h2>\n

Probabilmente uno dei primi usi commerciali di una viewport dinamica<\/a> (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.<\/p>\n

Nel 2007, Apple realizz\u00f2 l’iPhone, un device ben pi\u00f9 grande dell’E60, ma con un problema simile: anche su un display \u201cenorme\u201d da due pollici, navigare il \u201cweb reale\u201d 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.<\/p>\n

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.<\/p>\n

Apple non si fermo qui. Svilupp\u00f2 anche un nuovo meta tag viewport<\/code>. 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<\/code> importante per tutti. Questo valore dice al browser: “Per favore, scegli una larghezza che si adatti meglio allo schermo di questo specifico device”.<\/p>\n

Altri produttori di browser mobile seguirono rapidamente la guida di Apple. Ad oggi, praticamente tutti i browser mobile supportano il meta tag viewport<\/code>, incluso il valore device-width<\/code>. 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 \u201csufficientemente buona\u201d.<\/p>\n<\/div>\n

\n

Mini problemi<\/h2>\n

Il valore che viene assegnato a device-width<\/code> dai produttori di device e di browser \u00e8 collegato direttamente alle dimensioni fisiche del device. I device pi\u00f9 piccoli hanno bisogno di un valore device-width<\/code> pi\u00f9 piccolo (che risulta in un contenuto pi\u00f9 grande). Impostate un valore troppo grande e la maggior parte del contenuto sar\u00e0 troppo piccola per essere letta in maniera confortevole.<\/p>\n

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

A causa di questa device-width, le pagine web appaiono pi\u00f9 piccole del 27% sull’iPad Mini rispetto al Google Nexus 7 (calcolato<\/a> basandosi sulla dimensione relativa dei pixel dei device), solo perch\u00e9 Apple ha deciso di descrivere la viewport del device con 768 pixel.<\/p>\n<\/div>\n

\n

Risolvere il problema per la dimensione del contenuto<\/h2>\n

Uno dei primi posti in cui questo causa problemi \u00e8 il testo: pi\u00f9 pixel in uno spazio pi\u00f9 piccolo implicano che i font la cui dimensione \u00e8 espressa in pixel appariranno minuscoli.<\/p>\n

Ovviamente, molti di noi non danno pi\u00f9 le dimensioni in pixel ai font: utilizziamo ora elementi di dimensioni relative come gli em<\/code>, giusto? Solo che nemmeno cos\u00ec si risolve il problema questa volta…<\/p>\n

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

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

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

Questo potrebbe ancora non sistemare i problemi legati alla viewport dell’iPad Mini, ma almeno il contenuto dovrebbe essere leggibile.<\/p>\n

<\/a><\/p>\n

Tre tablet da sette pollici: notate la differenza nella resa.<\/p>\n<\/div>\n<\/div>\n

\n

Ma perch\u00e9 Apple ha agito cos\u00ec?<\/h2>\n

Per capire il motivo per cui Apple ha rilasciato un prodotto con una viewport cos\u00ec fastidiosa, non dobbiamo andare oltre le nostre abitudini.<\/p>\n

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\u00e9 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.<\/p>\n

Se Apple avesse diminuito il valore di device-width<\/code> per l’iPad Mini sulla base della sua dimensione fisica pi\u00f9 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.<\/p>\n

In questo caso, la responsabilit\u00e0 va in due direzioni: i produttori di browser devono s\u00ec 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 \u201ccontrollo\u201d \u00e8 un’illusione, comunque).<\/p>\n<\/div>\n

\n

Una strada da seguire<\/h2>\n

L’unico modo per noi per andare avanti \u00e8 unirci. In qualit\u00e0 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\u00ec 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.<\/p>\n

Gli standard e la coerenza sono ora pi\u00f9 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\u00e0 delle decisioni che riguardano le viewport di default e il loro zoom. Vogliamo tener fede alla nostra met\u00e0 del contratto e abbiamo bisogno che loro onorino l’altra met\u00e0 del contratto con noi.<\/p>\n

Muoviamoci verso il futuro<\/a>, insieme.<\/p>\n

Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Ogni settimana, fanno la loro comparsa dei nuovi device che si differenziano tra loro per dimensione dello schermo e densit\u00e0 di pixel, per metodi di input e molto altro ancora. Noi developer e designer concordiamo 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\u00ec che noi possiamo rispettare la nostra parte dell’accordo. Questo accordo non ha mai avuto cos\u00ec tanta importanza: questo \u00e8 il motivo per cui fa male quando un device o un browser fa qualcosa che va contro il nostro accordo, specialmente quando si tratta di noti e fidati amici del web, come Apple. Peter-Paul Koch, Lyza Danger Gardner, Luke Wroblewski e Stephanie Rieger spiegano perch\u00e9 l’ultimo tablet di casa Apple, l’iPad Mini, crea una situazione esasperante per le persone che cercano di fare la cosa giusta creando delle esperienze flessibili e multi-device.<\/p>\n","protected":false},"author":229,"featured_media":7000685,"comment_status":"open","ping_status":"open","template":"","categories":[273,82,257],"tags":[],"coauthors":[318,311,357,385],"class_list":["post-338","article","type-article","status-publish","has-post-thumbnail","hentry","category-mobile-multidevice","category-numero-67-4-gennaio-2013","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/338","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/229"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=338"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000685"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=338"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=338"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}