3.1 milioni di pixel pesano

Di Josh Clark

articolo orginale:

3.1 Million Pixels Are Heavy

8 marzo 2012

Come nel mondo, ormai tutti sanno, Apple portato di colpo lo schermo dell’iPad alla densità del display Retina, quadruplicandone il numero di pixel, che adesso raggiunge la cifra gigantesca di 3,1 milioni. Questa è una notizia fantastica per i proprietari di iPad (il display sarà strepitoso), ma significa anche qualche mal di testa in più per i progettisti e potenziali problemi sulla bolletta, larghezza di banda e velocità di download.

In termini di larghezza di banda, i pixel sono pesanti, e quattro volte più pixel significa dimensioni dell’immagine quattro volte più grandi, le per le immagini bitmap. Prendere o lasciare. Se volete approfittare di quello splendido schermo, ogni immagine che manderete sul canale, peserà una tonnellata. Questo ha impatti su molti aspetti.

Problemi per gli editori di riviste online

Per ragioni di business e organizzazione del processo produttivo, del tutto comprensibili, un gran numero di editori hanno adottato piattaforme come Woodwing e Adobe Digital Publishing Suite (vedi nota in fondo). Il problema è che questi strumenti pubblicano le immagini delle pagine, non i veri layout fatti di testi e immagini. Sono delle bitmap gigantesche.

Questi grandi pacchi di pixel producono file di dimensioni gigantesche per ogni singolo numero della rivista ed il loro download può richiedere molto tempo. La Newsstand di Apple (l’edicola da cui si scaricano giornali e riviste) fa del suo meglio per rendervi questo fenomeno invisibile, scaricando i numeri in background. Per quegli editori che vogliono sfruttare i vantaggi del nuovo display dell’iPad (cioè tutti): vedrete quadruplicare le dimensioni di questi file che già sono gigantesche. Come David Sleight ha scritto questa mattina:

Ora predente in considerazione l’aumento volumetrico in termini di pixel, a cui ci stiamo approssimando ed è facile capire perché la dimensione di un numero di una rivista media per iPad, stia per diventare un problema esplosivo. Grosso modo, una singola pagina di testo realizzata in questo modo e salvata utilizzando una leggera compressione JPG, pesa circa 150-350kB. Alle nuove dimensioni di Retina, queste stesse nuove piattaforme per app generano pagine dell’ordine di 2MB. Intendo, per ogni pagina.

Non è solo questione della larghezza di banda che queste applicazioni divoreranno durante il download di una copia della rivista, è anche da considerare se un utente può effettivamente memorizzare o no questi oggetti da qualche parte. Il volume dello scherma può anche essere quadruplicato, ma il nuovo iPad è ancora fornito delle stesse tre opzioni di memoria: 16, 32 e 64GB. Come ho puntualizzato su Twitter, il tasso di crescita della dimensione potenziale del payload supera il tasso di crescita della capacità di memorizzazione del dispositivo, in modo esponenziale.

Ciò è ovviamente insostenibile e gli editori o cominciano a pensare (e rapidamente) a nuovi strumenti e nuovi processi produttivi, oppure i produttori di strumenti cominciano a pensare di generare queste riviste per app, in formati più snelli. Un intervento recente di Condé Nast ha suggerito che Adobe sta iniziando a passare a layout in HTML5 per i suoi tool. Sarebbe una buona notizia per le dimensioni dei file e quasi certamente ne beneficerebbe anche l’esperienza di lettura. I lettori sarebbero finalmente in grado di selezionare il testo, copiarlo, ridimensionarlo, e così via.

Ma questo ancora non ci porterà completamente fuori dalla foresta. Anche tecnologie web come l’HTML5 avranno problemi a gestire il display retina dell’iPad.

Problemi per i progettisti ‘responsive’

Realizzare un solo sito per tutti i dispositivi e piattaforme dovrebbe essere l’obiettivo ideale di ogni Web designer, il punto di partenza di ogni progetto. Chiedetevi: possiamo creare un solo HTML di base e poi utilizzare il responsive design e il progressive enhancement, facendo sì che quell’HTML
si adatti armoniosamente su qualsiasi schermo? Questo approccio one-web non è sempre pratico e come sempre, dipende dal progetto.

Come industria, stiamo ancora studiando il modo migliore di fare il responsive design ed uno dei grandi punti da risolvere è come affrontare il problema delle immagini. Mentre è abbastanza facile fare in modo che il browser ridimensioni una immagine grande, per adattarla ad un piccolo schermo, considerazioni di banda del canale, suggeriscono di non inviare file di grandi dimensioni a dispositivi che non possono utilizzare i pixel in eccesso e il nuovo iPad non fa altro che aggravare il problema. Spedendo un’immagine a tutto schermo dimensionata per un iPad (1536×2048), ad un browser per iPod Touch (320×480), si ha un eccesso di informazione trasmessa, di qualcosa come 25 volte la dimensione del file; su una connessione wireless, è una cosa che brucia parecchio.

Questo non è un problema nuovo. Chi è in prima linea nel mobile design è stato alle prese con questo problema di responsive-image nel corso di tutto l’anno passato. Come si fa a indurre il server di inviare un’immagine di dimensioni adeguate, invece di inviare un file gigante, mono-taglia?

Ancora non abbiamo una buona risposta a questa domanda. Jason Grigsby ha suggerito un gran numero di tecniche (e poi altre ed altre ancora), nessuna di loro è perfetta e Matt “Wilto” Marquis suggerisce un modo di procedere estendendo l’HTML. In ogni caso, qualunque sia la soluzione definitiva, significa che gli editori di immagini dovranno iniziare ad aggiungere sempre più taglie della stessa immagine al loro arsenale di contenuti sul server. E sì, questo che significa:

Problemi per i creatori di contenuti

Recentemente ho lavorato un po’ per il sito web di una rivista online. Nel corso degli anni, i contesti in cui le loro immagini venivano utilizzate, erano così proliferati che producevano fino a dieci diversi tagli e dimensioni per ciascuna foto. Immagini in miniatura, immagini da galleria, le immagini primarie e secondarie articolo… insomma, avete capito. Un sacco di formati della stessa immagine per adattarsi a vari layout. Tutto questo si era evoluto in una sola piattaforma in ambiente desktop e non avevano neppure cominciato a contemplare le varie risoluzioni dello schermo dei dispositivi desknot (non desktop) degli ultimi anni.

Qui sta l’inghippo: in quel mucchio di immagini di varie dimensioni, quasi tutte erano troppo piccole per i cellulari. Avete capito bene: un’immagine di dimensione massima 600×600, fino a poco tempo fa, era molto grande per un sito web. Queste, sul desktop, risultano piacevolmente grandi, anche per una visione ingrandita, ma non riempiranno completamente lo schermo di un display Retina dell’iPhone. Le dimensioni fisiche dei più recenti telefoni possono essere piccole, ma la risoluzione dello schermo di alcuni desknots sono molto più elevate rispetto ai desktop. Le misure devono adattarsi per soddisfare tali risoluzioni.

Per adattarsi all’iPhone e l’iPad, la rivista ha creato una nuova dimensione di base, fino a 768×1024. Ma ora dovrà considerare l’aggiunta di almeno un altra dimensione, forse di più dimensioni. Alcuni di questi lavori può essere automatizzata, certo, ma in molti casi, l’aggiunta di nuovi formati significa aggiungere nuovi tagli e questo è un lavoro editoriale necessariamente manuale. Così la crescente varietà e dimensioni delle risoluzioni di schermo significano più lavoro, più spazio su disco, più gestione di database.

Problemi per i designer su iOS

E infine, naturalmente, abbiamo più lavoro per i designer su iOS. Così come hanno fatto per iPhone 4 e 4S, i progettisti dovranno generare ancora più dimensioni di immagini per le icone, per gli elementi grafici dell’app, e così via. L’elenco già grande delle varie dimensioni delle icone per un app universale, è appena cresciuta. Louie Mantia ha gentilmente condiviso un modello di rifermento rapido in Photoshop come guida, per il vostro lavoro sulle icone.

guida

Non siate tristi: tutto questo è straordinario

E’ un lavoro duro, abbiamo miriadi di dispositivi da supportare e dobbiamo creare design e risorse che non solo si adattino ai nuovi schermi, ma devono anche adattarsi ai nuovi modelli di interazione di ciascuno di essi. Il nostro lavoro è sempre più difficile e questo è solo l’inizio.

Ma signori, tutto questo è al servizio di qualcosa di veramente incredibile. La proliferazione di dispositivi è la premessa per la creazione di tecnologie che si adattino ai nostri contesti particolari. Splendidi schermi per i tablet, interfacce vocali, interazioni gestuali: tutte queste cose stanno andando a gravare su di noi come progettisti e creatori di contenuti. Ma accidenti, che opportunità creative! Come utente e designer, io per primo, do il benvenuto al mio nuovo sovrano da 3,1 milioni di pixel.

Nota

Gli strumenti Woodwing e Digital Publishing Suite sono essenzialmente plugin per Adobe InDesign. Essi consentono di convertire copie di periodici, prodotte per la stampa, in edizioni iPad ragionevolmente interattive. Questo permette agli editori di utilizzare gli stessi design essenziali, lo stesso processo produttivo e stesso personale per lanciare il contenuto per la stampa sulla piattaforma iPad. Il processo ha un sacco di svantaggi dal punto di vista della user experience, ma comprendo bene la decisione di utilizzarlo. Questi strumenti rappresentano una fase transitoria che ha consentito agli editori, di agganciare il mondo iPad in modo (relativamente) rapido e (relativamente) a buon mercato. La fase successiva è capire come creare esperienze che vengano avvertite come più naturali sui tablet, o su qualsiasi altra piattaforma gli editori scelgano come obiettivo. La prima generazione di strumenti come Woodwing e Digital Publishing Suite sono un male necessario.

josh clarkjosh clark

Traduzione di

Stampa articolo Scarica il file in formato PDF

Elenco Articoli di josh clark

Preview del libro su O'REILLY

Post A Comment

Il tuo indirizzo email non sarà pubblicato.