{"id":316,"date":"2012-10-16T10:44:03","date_gmt":"2012-10-16T08:44:03","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/estetica-del-web\/"},"modified":"2012-10-16T10:44:03","modified_gmt":"2012-10-16T08:44:03","slug":"estetica-del-web","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/estetica-del-web\/","title":{"rendered":"L’estetica del Web"},"content":{"rendered":"
\n
\n

\u00c8 nella natura del web essere flessibile e dovrebbe essere nostro compito come designer e sviluppatori adottare questa flessibilit\u00e0 e produrre pagine che, essendo flessibili, siano accessibili a tutti.<\/p>\n

\u2014 John Allsopp<\/cite>, The Dao of Web Design<\/a><\/p>\n<\/blockquote>\n

Dodici anni fa, John Allsopp ci chiese di adottare la natura flessibile del web. Non l’abbiamo ascoltato.<\/p>\n

Sebbene il movimento degli standard web che ne \u00e8 seguito abbia sostenuto la separazione tra presentazione e contenuto, un requisito essenziale per l’adaptive design, questo si \u00e8 manifestato solamente nel codice. I div<\/code> con propriet\u00e0 float hanno sostituito le celle delle tabelle, ma i layout sono rimasti governati dalle convenzioni inflessibili della stampa.<\/p>\n

Oggi, con tutti i device che possono connettersi a internet, \u00e8 diventato pi\u00f9 facile, praticamente necessario, accettare la natura flessibile del web. Il responsive web design<\/a> \u00e8 una best practice emergente e i nostri layout cominciano ad essere pi\u00f9 flessibili, ma, ancora una volta, l’innovazione \u00e8 focalizzata nelle implementazioni tecniche, mentre si ignora l’estetica visuale.<\/p>\n

Per dirla in un altro modo, stiamo adottando il “responsive” ma trascurando la seconda parte, il “design”. Stiamo sostituendo i div<\/code> a larghezza fissa con quelli fluidi. Sfruttiamo questo periodo di assestamento in termini di tool e di procedure per cercare un’estetica che sia pi\u00f9 adatta al web in s\u00e9 e per s\u00e9.<\/p>\n<\/div>\n

\n

Il materiale del web<\/h2>\n

Per progettare in maniera corretta per un mezzo di comunicazione, dobbiamo prima capirlo. Mi piace pensare al web come ad una specie di materiale, con caratteristiche uniche da cui possiamo trarre vantaggio e con dei limiti che possiamo raggiungere prima che si rompa. Il web potrebbe quasi essere considerato come un composto, costituito da HTTP (il “come”), dagli URL (il “dove”) e dall’HTML (il “cosa”). Tralasciate uno di questi tre ingredienti e non state pi\u00f9 creando il web.<\/p>\n

\u00c8 questa combinazione di protocolli e convenzioni che aiuta il web a raggiungere quello che Sir Tim Berners-Lee definisce<\/a> come il suo “principio di design primario”: l’universalit\u00e0.<\/p>\n

\n

Dovrebbe essere accessibile da qualunque tipo di hardware che si pu\u00f2 connettere a internet: fermo o mobile, con un piccolo schermo o con uno grande.<\/p>\n<\/blockquote>\n

L’universalit\u00e0 \u00e8 cos\u00ec propria di questo mezzo di comunicazione che si potrebbe affermare che il web \u00e8 responsive di default<\/a>. Il “responsive” non \u00e8 tanto una tecnica o un procedimento, quanto una caratteristica fondamentale della piattaforma che noi minacciamo con ogni riga di CSS e JavaScript che gli sovrapponiamo. Inoltre, l’universalit\u00e0 trascende il design visuale: i siti web devono essere semplici da usare sia quando vengono visualizzati come solo testo sia quando vengono letti ad alta voce.<\/p>\n

Questa natura e queste caratteristiche dovrebbero permeare ogni aspetto del nostro design. Quindi, come dovrebbe cambiare l’estetica prevalente del web se progettassimo con la sua natura universale in mente?<\/p>\n<\/div>\n

\n

Il mezzo \u00e8 il messaggio<\/h2>\n

Come il web, la televisione \u00e8 il mezzo in cui i device che vi accedono differiscono tra loro in dimensione, risoluzione, rapporto di aspetto (aspect ratio) e frequenza di refresh.<\/p>\n

Questa cosa era particolarmente evidente negli anni ’70 e ’80. Sebbene i programmi venissero registrati a colori, le emittenti dovevano ancora considerare il gran numero di persone che possedevano delle tv in bianco e nero. La grafica sugli schermi doveva funzionare su entrambe i tipi di monitor, quindi i designer utilizzavano delle forme e dei colori con grande contrasto. Ad esempio, il logo della BBC1 utilizzava un globo giallo (in seguito verde brillante) che ruotava su un campo blu scuro. Il design risultante era appariscente, ma funzionava.<\/p>\n

\"Logo\"Logo<\/p>\n

I loghi di BBC1 del 1974 e del 1981<\/p>\n<\/div>\n

La televisione sta affrontando un altro periodo di transizione, questa volta verso un formato “widescreen” ad alta definizione. Dal momento che molti spettatori possiedono ancora delle televisioni 4:3 a definizione standard, i designer devono ancora scendere a compromessi e lavorare all’interno della “zona sicura” per essere sicuri che la grafica non venga tagliata troppo sulle TV pi\u00f9 vecchie. Come risultato, la grafica sulle televisioni widescreen tende a stare nel mezzo dello schermo, impossibilitata ad usare l’intera larghezza.<\/p>\n

L’estetica prevalente della televisione continuer\u00e0 a cambiare, ma rimarr\u00e0 governata dai progressi delle tecnologie e della comprensione dei designer dei suoi limiti.<\/p>\n<\/div>\n

\n

Tutto ci\u00f2 che \u00e8 vecchio \u00e8 ancora nuovo<\/h2>\n

Prima dei “killer websites” e del desiderio di produrre layout simili alla stampa, quando l’ampiezza di banda era limitata e i piccoli monitor potevano mostrare solo 256 colori, la grafica a pixel era considerata de rigueur<\/em>, un obbligo: i layout erano semplici e mirati.<\/p>\n

Nel 1995, Hotwired<\/a> utilizz\u00f2 solo sedici colori. La navigazione sulla homepage era composta da poco pi\u00f9 di sei GIF a quattro colori, da 1kb, ciascuna rappresentante un argomento. Il layout era composto solo da quelle immagini, centrate:<\/p>\n

<\/p>\n

Hotwired, nel 1995 circa.<\/p>\n<\/div>\n

Circondati da display ad alta risoluzione e da banda illimitata, \u00e8 facile dimenticare che esistono ancora vincoli simili. Sebbene i device stiano diventando sempre pi\u00f9 potenti e con numerose feature, si continuano a produrre dispositivi meno capaci: ad esempio, il Kindle di Amazon \u00e8 un dispositivo molto diffuso, tuttavia, la maggior parte degli e-reader della linea Kindle ha la connessione cellulare e un display monocromatico E Ink.<\/p>\n<\/div>\n

\n

Comprendere i limiti<\/h2>\n

Muovendoci verso gli adaptive layout, abbiamo incontrato dei nuovi limiti: le immagini bitmap non si adeguano n\u00e9 alla dimensione della viewport n\u00e9 alla banda disponibile.<\/p>\n

Questa non \u00e8 una mancanza del web: il fatto di poter inserire diversi tipi di media in una pagina web \u00e8 una feature utile, ma non tutti i formati condividono le caratteristiche del web. C’\u00e8 l’enorme opportunit\u00e0 di sviluppare un formato bitmap responsive e dubito che le immagini faranno veramente parte del web finch\u00e9 non esister\u00e0 una tale cosa. Nel frattempo, la domanda rimane: come possiamo fare in modo che le immagini fotografiche estremamente dettagliate funzionino in un mezzo cos\u00ec flessibile?<\/p>\n

Molte persone hanno cercato di rispondere a questa domanda con varie soluzioni tecniche. Poich\u00e9 si \u00e8 scoperto che gli hack complessi erano anche fragili, abbiamo concentrato i nostri sforzi nella direzione della definizione dei nuovi standard<\/a>, dando maggiori consensi a quelli che individuano quando dovrebbero essere scaricate e mostrate immagini diverse a seconda dalle dimensione pi\u00f9 adatta.<\/p>\n

\u00c8 nel regno dei vincoli che si alimenta la creativit\u00e0. I designer devono ancora raggiungere i limiti di quello che \u00e8 possibile. Nel cercare delle soluzioni di design a questo problema, potremmo creare un’estetica che sia pi\u00f9 appropriata al mezzo e, forse, realizzare che il problema delle immagini responsive esiste solo perch\u00e9 le nostre convenzioni riguardanti il design affondano ancora le radici nella stampa.
Senza un periodo di sperimentazione e riflessione, temo che potremmo addirittura introdurre degli standard che vanno contro l’universalit\u00e0 del mezzo: praticamente gli elementi <font><\/code> del giorno d’oggi.<\/p>\n<\/div>\n

\n

Progettare attorno al problema<\/h2>\n

Fortunatamente, gli sviluppatori e i designer cominciano a fare questi esperimenti e trovano soluzioni che negano il bisogno di nuovi standard.<\/p>\n

1. Ottimizzazione<\/h3>\n

Piuttosto che generare immagini di dimensioni differenti e determinare quale mostrare, un’altra opzione \u00e8 quella di mandare invece un’unica immagine altamente ottimizzata.<\/p>\n

Il dConstruct Archive<\/a> \u00e8 un piccolo sito in cui le persone ascoltano gli interventi degli speaker delle precedenti edizioni della conferenza dConstruct. Qui, i dettagli di sfondo attorno al volto di ciascuno speaker sono stati sfuocati, generando immagini con minori artefatti di compressione e pertanto file di dimensioni ridotte. Questa tecnica funziona particolarmente bene con i ritratti, dal momento che gli esseri umani tendono a concentrarsi maggiormente sulle caratteristiche dei visi.<\/p>\n

\"esempio\"esempio<\/p>\n

Immagine originale: 9kb. Immagine ottimizzata: 4kb<\/p>\n<\/div>\n

Sono stati presi in considerazione i display pi\u00f9 piccolo e pi\u00f9 grande per trovare quale dimensione usare. Possiamo gi\u00e0 vedere un problema nelle attuali proposte per le immagini responsive. Se visitate questo sito, noterete che le viewport pi\u00f9 grandi a volte mostrano le immagini pi\u00f9 piccole, perch\u00e9 la dimensione dell’immagine richiesta \u00e8 spesso dipendente dalla dimensione del blocco che la contiene, non<\/em> della dimensione della viewport. Tuttavia la viewport \u00e8 il valore che gli standard proposti vorrebbero farci sottoporre a query.<\/p>\n

2. Alterare l’estetica<\/h3>\n

Se le immagini con minori colori e maggiori livelli di compressione danno file di dimensioni minori, allora forse i nostri design dovrebbero rispecchiare questa cosa.<\/p>\n

Con il tema “giocare con il futuro”, il sito della conferenza dConstruct 2012<\/a> ha usato un design altamente tipografico con immagini monocromatiche e aree di colore piatto. Questa decisione di design ha fatto s\u00ec che le immagini potessero essere davvero piccole, alcune addirittura usano appena otto colori:<\/p>\n

\"esempio\"esempio<\/p>\n

Immagine originale: 14kb. Immagine ottimizzata: 11kb<\/p>\n<\/div>\n

Come abbiamo visto nell’esempio della televisione, i vincoli di un mezzo di comunicazione hanno impatto sui risultati estetici. In questo caso, le immagini con meno colori o con lo sfondo sfuocato (magari anche con artefatti di compressione evidenti) possono diventare una norma accettata sul web? Sicuramente la popolarit\u00e0 di servizi come Instagram (un prodotto nato esso stesso da vincoli) ha provato che la fotografia viene giudicata per il suo contenuto<\/a>, non per la sua risoluzione.<\/p>\n

3. Progressive enhancement<\/h3>\n

Alterare l’estetica visuale per adattarsi ai bisogni del mezzo \u00e8 il fine ideale, ma \u00e8 improbabile che venga accettato da alcuni clienti. E, diciamocelo: non \u00e8 sempre appropriato. Infatti, sembra che raramente ci poniamo la domanda di cosa sia appropriato. Valutando il nostro contenuto, possiamo decidere quante immagini sono davvero necessarie per convogliare un messaggio.<\/p>\n

Piuttosto che aumentare la risoluzione<\/em> delle immagini all’aumentare della dimensione di un sito, possiamo pensare invece di aumentarne il numero<\/em>. Questo si collega molto bene con le idee del progressive enhancement: fornire un’esperienza di base che possa arricchirsi all’aumentare delle capacit\u00e0 del device.<\/p>\n

Il sito mobile di BBC News<\/a> \u00e8 un ottimo esempio di progressive enhancement. Il codice sorgente HTML contiene solo due immagini: il logo della BBC e un’immagine per la storia principale. Tutti i dispositivi ricevono questo codice HTML e le pagine hanno un peso minimo di 28kb: quasi un’impresa in un mondo di siti web da 5Mb.<\/p>\n

Quando vi si accede da dispositivi pi\u00f9 potenti come gli smartphone pi\u00f9 nuovi, i tablet e i computer desktop (quelli che possono “superare le aspettative<\/a>“), viene visualizzata un’immagine per ogni storia. Queste immagini sono state giudicate come miglioramenti che sarebbe bello avere rispetto all’esperienza base e vengono richiesti condizionatamente dopo che la pagina base \u00e8 stata caricata.<\/p>\n

\"L'esperienzaL’esperienza del sito mobile di BBC News<\/div>\n

Il progressive enhancement fa parte della cassetta degli attrezzi degli sviluppatori da molto tempo, ma adesso dovrebbe apparire in tutto il processo di design. Pensando ai siti web meno in termini binari (desktop vs. mobile, IE6 vs. browser “moderni”), possiamo creare delle esperienze che si adattano ai diversi panorami del web.<\/p>\n<\/div>\n

\n

Adattiamo le nostre assunzioni (non solo i nostri layout)<\/h2>\n

Immaginate il design di un nuovo sito web. Vedete il layout contenuto tra header e footer, con la navigazione in alto e un’area di contenuto principale con accanto una sidebar?<\/p>\n

Dobbiamo resettare queste assunzioni.<\/p>\n

Piuttosto che cercare ispirazione dalla stampa, forse dovremmo guardare di pi\u00f9 al software design. Le applicazioni desktop sono state spesso imitate sul web, particolarmente nel caso delle applicazioni di produttivit\u00e0 e spesso i risultati sono intollerabili<\/a>. Le interfacce di maggior successo combinano gli aspetti migliori delle applicazioni desktop con le interfacce native del web, pensiamo a Gmail piuttosto che a Yahoo! Mail.<\/p>\n

Un ragionamento simile viene ora impiegato nelle applicazioni centrate sul contenuto, in gran parte grazie all’introduzione del Chrome Web Store nel 2010. Questa feature ha dato un marketplace in cui gli sviluppatori possono vendere e promuovere le app create utilizzando gli standard web e molti hanno creato delle applicazioni che danno un nuovo scopo al contenuto disponibile sul web.<\/p>\n

Il fatto che queste app possano essere usate solo con Chrome \u00e8 un requisito snervante e uno per cui valga la pena protestare. Ma, se guardiamo a queste app semplicemente da una prospettiva puramente visuale e le confrontiamo con le loro controparti costituite da siti web tradizionali, vedremo che una tela bianca senza assunzioni pu\u00f2 fornire esperienze pi\u00f9 applicabili al web.<\/p>\n

Solo la notizia \u00e8 adatta per la stampa<\/h3>\n

Quando pensiamo a siti web ispirati dalla stampa, ci vengono subito in mente quelli dei giornali. Il sito del The New York Times<\/em><\/a> era costruito su una griglia multi-colonna fissa, strapiena. Come molti siti contemporanei, il contenuto \u00e8 soffocato dalla pubblicit\u00e0, dalle widget per la condivisione e dai link correlati:<\/p>\n

\"L'interfaccia<\/div>\n

L’inadeguatezza di questo design diventa pi\u00f9 lampante quando lo si confronta con la sua Chrome App<\/a> (che grazie al cielo \u00e8 accessibile in altri browser). Il contenuto ha un ruolo centrale, con un’interfaccia meno affollata e pi\u00f9 focalizzata ed \u00e8 perfino responsive, fino a un certo punto. Notate che ci sono anche meno immagini fotografiche, ad avvalorare l’idea che le immagini responsive potrebbero solo essere un problema quando i web designer cercano di replicare la stampa.<\/p>\n

\"L'interfaccia<\/div>\n

Siti Task-oriented<\/h3>\n

Un altro sito che soffre di un layout altrettanto affollato \u00e8 BBC Good Food:<\/a><\/p>\n

\"L'interfaccia<\/div>\n

Tuttavia, quando si visualizza la pagina di una ricetta nella sua Chrome app<\/a>, vediamo di nuovo un design molto pi\u00f9 ragionato e concentrato sull’utente: \u00e8 molto pi\u00f9 facile seguire una ricetta quando non si deve far scorrere la pagina.<\/p>\n

\"L'interfaccia<\/div>\n

Contenuto, non chrome<\/h3>\n

Un esempio finale di questo trend lo si ha con Rdio<\/a>. Con l’evolversi del servizio di musica in streaming, i suoi designer hanno cercate di mantenere consistenza tra il sito web e l’applicazione desktop. Queste interfacce una volta condividevano solo pochi componenti, adesso sono praticamente identiche. Questo approccio ha prodotto un design che si inserisce tra i due: non proprio un sito web ma nemmeno una applicazione desktop.<\/p>\n

\"Rdio<\/div>\n

Come l’app Chrome del New York Times<\/em> e di BBC Good Food, questo spostamento verso un’interfaccia pi\u00f9 simile a una app \u00e8 risultata in una concentrazione maggiore sul contenuto (in questo caso, sulle copertine degli album), su un layout pi\u00f9 fluido e su una navigazione meno intrusiva.<\/p>\n

Per alcuni versi, la nuova interfaccia condivide delle qualit\u00e0 con il nuovo linguaggio di design “Metro” di Microsoft, che possiamo trovare sui Windows Phone e in Windows 8. Quando considererete che i principi di design dietro Metro<\/a> includono “Pulito, Leggero, Aperto e Veloce”, “Contenuto, non chrome” e “Essere genuinamente digitali”, sar\u00e0 difficile argomentare che questi valori non dovrebbero applicarsi allo stesso modo alle interfacce web.<\/p>\n

Ovviamente, uno dei motivi per cui queste app possono essere trattate in maniera diversa rispetto ai tradizionali siti web \u00e8 l’assenza di pubblicit\u00e0, un vincolo non proprio del web, ma dei modelli di business che vi si sono creati. La pubblicit\u00e0 online sta lentamente andando verso una lunga e dolorosa morte: le pubblicit\u00e0 diventano sempre pi\u00f9 grandi e pi\u00f9 fastidiose, mentre i servizi che le rimuovono, come AdBlock, Instapaper e Readability stanno guadagnando sempre pi\u00f9 popolarit\u00e0. Tuttavia, senza dei modelli di business sicuri che possano rimpiazzarla, la pubblicit\u00e0 sar\u00e0 con noi ancora per qualche anno.<\/p>\n

Tuttavia, questo non dovrebbe fermarci dall’imparare dai design ispirati da queste app. Se non altro, sottolineano delle possibilit\u00e0 di layout alternativi e come possono essere i servizi auspicabili quando viene data maggior importanza al contenuto.<\/p>\n<\/div>\n

\n

Il viaggio continua<\/h2>\n

Mentre ci affacciamo alla terza decade dell’esistenza del web, dovremmo avere un’idea di quello che funziona e di quello che non funziona. Dovremmo avere sufficiente fiducia nel scegliere da quali aspetti degli altri media e delle altre piattaforme possiamo trarre ispirazione e quali invece ignorare. Dovremmo essere ispirati dalle convenzioni degli altri media ma smettere di esserne governati.<\/p>\n

Con l’universalit\u00e0 come principio guida, possiamo impiantare approcci come il progressive enhancement per tutto il nostro processo di design. In fin dei conti, tutto sul web deve poter “degradare” a semplice testo (le immagini richiedono il testo alternativo, i video richiedono le trascrizioni), pertanto l’editor di testo potrebbe diventare l’app pi\u00f9 potente nella cassetta degli attrezzi del designer.<\/p>\n

Man mano che il web matura, dovremmo riconoscere ed adattare i suoi vincoli e l’estetica che ne pu\u00f2 derivare. Quando lo faremo, potremmo scoprire che la vera estetica del web potrebbe non essere affatto visuale.<\/p>\n

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

Oggi, con tutti i dispositivi che riescono a connettersi a internet, \u00e8 diventato pi\u00f9 semplice, praticamente necessario, accettare la natura flessibile del web. Il responsive web design \u00e8 una best practice emergente e i nostri layout stanno cominciando a diventare pi\u00f9 flessibili, ma, spesso, l’innovazione si concentra sulle implementazioni tecniche mentre sembra che si ignori l’estetica visiva. Mettiamola in un altro modo: stiamo adottando il responsive ma dimenticandoci del design. Adesso \u00e8 il momento per cercare un’estetica propria di questo medium.<\/p>\n","protected":false},"author":818,"featured_media":7000676,"comment_status":"open","ping_status":"open","template":"","categories":[272,273,77,257],"tags":[],"coauthors":[377],"class_list":["post-316","article","type-article","status-publish","has-post-thumbnail","hentry","category-layout-and-grids","category-mobile-multidevice","category-numero-62-16-ottobre-2012","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/316","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\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=316"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000676"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=316"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}