Alcuni consigli pratici per incentivare l’aggiornamento di IE6.
Su questo blog ci sono state numerose discussioni su Internet Explorer 6 e su quanto renda complicata la vita degli sviluppatori. E’ possibile rimanere passivi e aspettare la sua lenta morte, ma non è detto che questo sia l’atteggiamento migliore. Ogni web designer infatti può dare un contributo alla sparizione di questo browser, che esiste dal 2001.
Le soluzioni possibili
Il modo migliore per far capire ad un utente che il suo browser è obsoleto, è presentargli una versione del sito alternativa. Sfruttando i commenti condizionali è possibile fornire ad IE6 un CSS su misura:
In questo modo tutte le versioni di Explorer precedenti alla 7 vedranno il sito in maniera diversa: potrete divertirvi come volete con questo foglio di stile. Un eccellente esempio di personalizzazione è offerto da questo sito, che con IE6 appare interamente in bianco e nero.
Anche su TomStardust.com ho voluto fare qualcosa: adesso navigando con il browser Microsoft l’header appare diverso, e compare anche un avviso che invita il visitatore ad aggiornare. Tutto è collegato ad una nuova pagina creata per l’occasione, con i link per il download dei migliori browser. Come avrete capito non sono comunque a favore delle soluzioni drastiche: è bene che i contenuti siano accessibili in ogni caso.
La soluzione definitiva?
Ovviamente questi interventi non potranno portare in tempi brevi alla sparizione di IE6. Molti utenti continueranno ad utilizzarlo perchè non possono fare altrimenti, magari per obblighi aziendali.
E’ comunque importante dare un segnale: esistono già diverse campagne di sensibilizzazione e siti come Facebook da tempo presentano avvisi agli utenti di Explorer 6. Il 2009 probabilmente non vedrà sparire questo browser, ma potrebbe essere l’anno della svolta.
Con i CSS sarà possibile trasformare ed animare gli elementi di una pagina web. Cosa succederà a JavaScript?
Qualche tempo fa la Apple ha presentato al CSS Working Group del W3C una proposta riguardante transizioni ed animazioni con i CSS. Il tutto è stato preso in considerazione ed inserito nel documento che mostra i progressi del gruppo.
Ma di cosa stiamo parlando? Sono novità interessanti e prioritarie o l’introduzione di queste proposte potrebbe aumentare la confusione?
Le novità
Trasformazioni CSS
Pur non essendo incluse nell’ultima proposta, le trasformazioni CSS sono comunque correlate. La proprietà transform consente infatti di spostare, ruotare o ridimensionare un elemento della pagina.
Transizioni CSS
Questo modulo gestisce le transizioni tra pseudo-classi, come potrebbe essere il passaggio allo stato :hover di un link e viceversa. Per la transizione è possibile specificare un determinato periodo di tempo (transition-duration), il passaggio non sarà quindi istantaneo. Ad esempio un link potrebbe cambiare colore sfumando.
Animazioni CSS
Se già con il modulo dedicato alle transizioni è possibile associare ad un oggetto dei brevi movimenti, con questo modulo si possono raggiungere risultati ancora più complessi.
Definendo gli eventi associati ad una determinata animazione, è possibile infatti indicare quali siano le proprietà che cambiano, il loro valore, e per quanto tempo.
Esempi pratici
Mi rendo conto che con queste novità sia facile fare confusione. Per chiarirsi le idee basta avere installato Safari: il browser Apple infatti supporta queste funzioni con dei comandi proprietari (con il prefisso -webkit-).
Per trasformazioni e transizioni questo è uno dei migliori esempi disponibili. Se invece volete vedere un’animazione CSS, la trovate in questa pagina, ma vi servirà una delle ultime nightly build di Safari (anche Safari 4 beta).
Possibili problemi
Siamo sicuri che queste novità siano positive per gli sviluppatori? Fino ad ora la parte interattiva di una pagina era gestibile con JavaScript (lasciamo da parte Flash): introdurre dei nuovi meccanismi di controllo direttamente nei CSS potrebbe generare diversi problemi.
Compatibilità tra i browsers
Inutile dirlo, se già adesso ci sono problemi ad ottenere risultati equivalenti sui vari browser, occupandosi esclusivamente dell’aspetto visivo delle pagine, cosa succederà quando il discorso riguarderà anche l’interazione tra vari elementi? Queste proprietà saranno di fatto inutilizzabili, a meno che non si voglia ricorrere a JavaScript per ottenere risultati simili sui browser che non le supportano. Ma allora perchè non usare direttamente JavaScript?
Interazione con JavaScript
Separando l’aspetto dell’interazione tra CSS e Javascript, si presenta un altro problema: l’interazione tra i due mondi. Non è possibile (al momento) intercettare un oggetto quando è nel mezzo di un’animazione CSS, ma nemmeno sapere se una transizione sia già avvenuta.
Accessibilità
I problemi non mancano nemmeno per quanto riguarda l’accessibilità. Già adesso per uno screen reader non è facile sapere tutto ciò che succede in una pagina, soprattutto se certi script AJAX vengono realizzati senza seguire le specifiche. Introdurre altre complicazioni aumenterà inevitabilmente le difficoltà per alcune categorie di utenti.
Conclusioni
Le possibilità offerte da trasformazioni, transizioni e animazioni CSS potrebbero essere interessanti, ma sarà bene valutarne pro e contro quando sarà il momento di utilizzarle. Il fatto che esista una determinata tecnologia, non significa che debba essere per forza utilizzata.
La tentazione potrebbe essere forte, perchè con poche righe di CSS sarà possibile animare facilmente gli elementi della pagina, ma la cosa migliore sarà continuare a gestire le interazioni esclusivamente con JavaScript, così come HTML e CSS sono riservati rispettivamente a contenuto e presentazione.
Una panoramica sulle possibilità di controllo dei form offerte dalla nuova specifica HTML.
Dopo aver affrontato una prima volta l’argomento HTML 5 su questo sito, nelle ultime settimane ho sperimentato diverse soluzioni interessanti di questa nuova specifica.
Il linguaggio è stato semplificato e reso molto più immediato, ma ci sono diversi elementi come i form che hanno subito una rivoluzione. Per capire di cosa sto parlando vi basterà installare l’ultima versione di Opera, che supporta le novità di HTML 5 e vi permetterà di fare alcune prove.
Per far sì che una pagina segua la specifica, è sufficiente usare questa doctype:
<!DOCTIPE html>
Come vedete, è tutto molto più immediato rispetto alle dichiarazioni in uso attualmente.
Utilizzando i form vi renderete conto che le novità sono ancora più interessanti. Sono supportati infatti una serie di attributi e valori per gestire i campi obbligatori, la validazione dei moduli ed i diversi tipi di elementi.
Ad esempio type=”email” su un campo impedisce l’invio del form se il dato inserito non è un formato email valido. La stessa cosa vale per gli indirizzi web con type=”url”. Il tutto è interamente gestito dal browser, senza bisogno di script aggiuntivi.
Usando invece type=”date” su un campo input, al click appare un box per la selezione della data come quello che potete vedere qui sotto. Niente JavaScript e altri elementi nella pagina, basta un attributo.
Per i campi obbligatori invece basta specificare required all’interno dell’elemento richiesto. Così un campo email potrà essere definito:
<input name="email" type="email" required>
Potete vedere alcuni esempi e sperimentare le potenzialità dei form in HTML 5 in questa pagina, ricordando di utilizzare l’ultima versione di Opera. Gli altri browser si comporteranno senza errori, ma vedrete dei semplici campi input. Per quanto riguarda invece la selezione della data, Bruce Lawson ha realizzato un semplice esempio, correlato ad un articolo molto interessante su HTML 5 e WAI-ARIA.
Questa nuova specifica HTML non sarà largamente supportata entro breve, ma è tempo di iniziare a conoscerla. Potrebbe diventare una realtà prima del previsto senza bisogno di attendere molti anni: tra gli obiettivi c’è anche quello della retrocompatibilità, e questo gioca a suo favore.
Una guida per la corretta formattazione dei link di testo, evitando soluzioni poco usabili.
I collegamenti testuali di una pagina sono un elemento basilare; capita spesso però che vengano sottovalutati dagli sviluppatori, dando per scontato la loro riconoscibilità.
Per avere dei link usabili in realtà basta seguire alcune semplici convenzioni: implementarle non richiede molto tempo, ma i vantaggi per i vostri utenti saranno evidenti.
Le convenzioni da seguire
In certi casi il rischio di confondere chi visita la pagina è alto: quante volte vi è capitato di provare a cliccare su un testo che in realtà non era un collegamento? Per evitare questi problemi, bisogna tenere presenti alcuni parametri:
Colore – Uno dei fattori principali per distinguere un link dal resto della pagina è il suo colore, differente da quello del contenuto. Attenzione però, perchè il colore da solo non è sufficiente: pensate ai problemi che potrebbe incontrare un utente daltonico.
Stile – Ci sono numerosi stili a disposizione, dalla sottolineatura al grassetto, passando per il tipo di font utilizzato. L’importante è che venga usato uno stile differente dal resto della pagina: la pratica comune vede i link sottolineati, ed è bene seguire questa convenzione.
Contrasto – Un link deve essere in evidenza, e non deve essere difficile da identificare. Cambiare il colore non basta, il contrasto deve essere elevato.
Comportamento – Tra le convenzioni più diffuse c’è quella del cambio di cursore al mouseover. Vedere il puntatore trasformarsi in una mano è indispensabile.
Tenendo presenti questi fattori, è possibile ottenere molteplici combinazioni usabili. Sperimentare è lecito, ma ricordate che innervosire i vostri utenti con dei link non riconoscibili, o ancora peggio dei testi normali che sembrano collegamenti, potrebbe causare la loro fuga. Non aspettatevi di ricevere segnalazioni nel caso ci siano problemi di questo tipo, il visitatore medio lascerà il vostro sito innervosito senza concedervi altre possibilità.
Qual è la pratica migliore?
Di default i collegamenti hanno la sottolineatura con text-decoration: underline, ed un colore blu facilmente riconoscibile.
Personalizzando questa impostazione, tenete presente che la sottolineatura è tuttora la pratica migliore e più diffusa. Se però non vi piace il risultato finale, potreste considerare di utilizzare un border-bottom al suo posto, come viene fatto su A List Apart. Il risultato può essere ulteriormente migliorato con 1 pixel di padding-bottom:
Un’altra pratica piuttosto diffusa, che utilizzavo su questo sito qualche tempo fa, sono i link in grassetto, senza sottolineatura. Il problema è che la distinguibilità dei collegamenti in questo caso dipende molto dal colore. Un esempio chiaro si ha su TechCrunch: guardando la pagina in bianco e nero grazie a GrayBit, i link non sono così evidenti come quelli sottolineati:
Ovviamente le varianti possibili sono infinite, l’importante è essere sempre consapevoli di quello che si sta facendo.
Ricordate comunque che in certi casi l’originalità può essere messa da parte e riservata ad altri dettagli: dei link usabili e facilmente riconoscibili sono indispensabili per garantire ai vostri utenti la migliore esperienza di navigazione possibile.
Analisi delle ultime statistiche sulle risoluzioni più utilizzate e consigli per la creazione del layout ideale.
Quello della risoluzione migliore per un sito web è un problema spesso sottovalutato. Negli ultimi anni la situazione si è semplificata visto l’ormai definitivo tramonto dei siti ad 800×600, ma questo non mette al riparo da possibili scelte sbagliate.
Le statistiche aggiornate
Secondo il report aggiornato a Dicembre 2008 di Net Applications, 1024×768 resta la risoluzione più diffusa con il 37%, e lo sarà ancora per diverso tempo.
Seguono valori più elevati, da 1280×960 (20%) a 1280×1024 (13%), per poi passare a risoluzioni ancora maggiori.
Una piccola curiosità: la risoluzione più bassa dopo 800×600 (4.49%) è quella di Safari su iPhone, 320×396 pixel (0.53%), importante segno dell’evoluzione del settore mobile.
Le altre combinazioni esistenti sono innumerevoli, soprattutto con l’avvento dei monitor widescreen, e proprio per questo realizzando un sito web è necessario valutare tutte le possibili situazioni.
Le dimensioni della finestra del browser
Un altro fattore difficile da valutare è quello della dimensione della finestra del browser. Pensate alle vostre abitudini: la tenete sempre a tutto schermo? La risposta in genere dipende dal monitor, io dove lavoro, con un monitor a 1280×1024 ho il browser a tutta pagina, ma questo non succede a casa su una risoluzione di 1680×1050 pixel.
Non è detto quindi che i dati ricavati dalle statistiche corrispondano alla situazione reale: un utente con un grande monitor difficilmente terrà la finestra del browser a tutto schermo.
Le percentuali cambiano anche a seconda del sistema operativo. Gli utenti Mac si comportano diversamente da quelli Windows, come era emerso da questo interessante sondaggio di Roger Johansson. Su Mac Os infatti si è più portati a non massimizzare le finestre.
I problemi con l’alta risoluzione
Avere come target un’ampia gamma di alte risoluzioni è comunque un problema da considerare. Questi sono i principali errori da evitare:
Layout a larghezza fissa allineati a sinistra
Layout fluidi senza max-width, con aree di testo molto estese in orizzontale o font-size troppo piccolo.
I siti allineati a sinistra possono andare bene fino ad una certa risoluzione, ma su monitor particolarmente grandi l’utente sarà portato a guardare solo un lato dello schermo. E’ una soluzione alternativa, che però mi sento di sconsigliare. Molto meglio mantenere l’allineamento centrale.
I layout fluidi sono più difficili da curare nei dettagli e presentano un grave problema di leggibilità se non controllati a dovere. A risoluzioni particolarmente elevate infatti i blocchi di testo rischiano di diventare troppo lunghi e faticosi da leggere.
Come scegliere il layout migliore
La prima cosa da fare rinnovando la grafica di un sito esistente è guardare le statistiche dei propri visitatori. I dati globali della rete hanno ben poca importanza rispetto a quelli dei vostri utenti e del target che vi siete prefissati. Potete usare le statistiche generali per capire quale sia l’andamento, riportandolo alla vostra esperienza.
Se invece state realizzando un nuovo sito, una larghezza minima intorno ai 960 pixel è la base di partenza ideale. A voi la scelta se utilizzare un layout a larghezza fissa, uno fluido, o addirittura uno elastico (anche se potrebbe essere giunto il momento di abbandonarli).
La soluzione a larghezza fissa in generale è quella più sicura, ma anche la più scontata. Una interessante via di mezzo si ottiene sfruttando il background della pagina per riempire lo spazio altrimenti vuoto. In questa galleria di Web Designer Wall ci sono degli ottimi esempi.
Nel caso invece vogliate un layout fluido, ricordate di impostare sempre una larghezza minima ed una massima, oscillando ad esempio tra i 900 ed i 1400 pixel.
Conclusioni
Queste indicazioni vogliono essere semplicemente un consiglio, non esistono verità assolute. In generale i layout a larghezza fissa sono sempre i più diffusi soprattutto per la facilità di realizzazione e le possibilità di controllo della struttura. Se però volete mettervi alla prova con un layout fluido, i vostri utenti potrebbero apprezzare un sito che si adatta alle loro abitudini.
Quali sono le vostre abitudini? Preferite un determinato tipo di layout o cambiate scelta a seconda delle situazioni? Dite la vostra per condividere pratiche e suggerimenti.
In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.
Approfondimenti sulla specifica HTML 5
Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.
Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.
In questo contesto, ci sono già stati i primi esperimenti:
il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript
Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.
Evoluzioni future
Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.
Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.
La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.
Pro e contro dei layout con misure definite in em. Sono ancora validi o non vale la pena spendere tempo e risorse per realizzarli?
I layout elastici sono definiti in questo modo per la loro capacità di adattarsi alle dimensioni del testo di una pagina. Ingrandendo i caratteri cambiano tutte le dimensioni di conseguenza: questi layout sono infatti definiti interamente in em, unità di misura relativa. Per chiarirvi le idee potete trovare un esempio pratico su CSS Zen Garden.
Chi ha realizzato un layout elastico sa quanto lavoro comporti, ma come sempre prima di cimentarsi in pratiche dispendiose è sempre bene valutarne pro e contro.
Conviene ancora realizzare siti interamente in em?
La domanda sorge da un dato di fatto: tutti gli ultimi browser offrono la possibilità di ridimensionare le pagine con un effetto zoom. In questo modo anche i layout a larghezza fissa non presentano grandi problemi, ancora meno le altre tipologie.
I layout elastici hanno sempre avuto la fama di essere accessibili e utili per l’utente che desidera personalizzare la dimensione dei caratteri, ma allo stato attuale l’unico browser che ottiene un vantaggio netto da questo tipo di design è Internet Explorer 6.
Mettendovi nei panni di un utente con problemi di vista o con la necessità di ingrandire il testo, cosa fareste? Molto probabilmente usereste un browser con la possibilità di zoomare le pagine, o un ingranditore di schermo, non IE6. E’ così assurdo come ragionamento? Non credo.
Per questo i layout in em ormai si stanno avviando verso l’estinzione. Considerando anche i tempi di sviluppo ed il rapporto costi/benefici, ormai non conviene più realizzare siti simili, a meno che non si abbia un ampio target di utenti utilizzatori di Explorer 6. Non esistono certezze assolute, ma a distanza di 5 anni dallo storico articolo di A List Apart sui layout elastici, è ormai tempo di metterli da parte per la maggior parte dei casi, tenendoli comunque presenti per le necessità impreviste.
Le migliori soluzioni JavaScript per realizzare gallerie di immagini accessibili, utilizzando i framework jQuery e Mootools.
Dall’uscita di Lightbox le soluzioni JavaScript per realizzare gallerie di immagini si sono moltiplicate: le scelte a disposizione sono innumerevoli, ma non è solo l’aspetto estetico quello che conta. Molto spesso gli script disponibili in rete sono fin troppo pesanti per il loro scopo, o non tengono presenti gli standard minimi per quanto riguarda l’accessibilità dei contenuti.
In questo articolo troverete una selezione di alcuni effetti che consentono di creare gallerie di immagini accessibili: non intrusivi, degradano nel modo giusto se JavaScript è disabilitato, e si appoggiano a framework già collaudati come jQuery e Mootools. Potrebbero essere migliorati ulteriormente, ma sono un’ottima base di partenza.
Soluzione basata sulla libreria Mootools, consente di creare slideshow di immagini mettendo a disposizione vari parametri come lo scorrimento automatico ed il tempo riservato ad ogni fotografia. E’ possibile anche avere più set di immagini nella stessa galleria: funzione comoda per risparmiare spazio nella pagina.
In assenza di JavaScript, le immagini appaiono comunque precedute da titolo e descrizione. Il difetto riguarda i controlli, non è infatti possibile scorrere le foto da tastiera.
Un buon set di effetti a disposizione anche per questo script basato sul framework Mootools, che può essere a sua volta esteso con altre funzionalità, come l’anteprima delle immagini con Lightbox.
Notevole la realizzazione degli esempi: disabilitando JavaScript le funzionalità restano le stesse, spariranno semplicemente le transizioni. Ottimi anche i controlli, non c’è alcun problema a spostarsi tra le immagini utilizzando anche la tastiera.
Probabilmente il migliore tra quelli presentati, questo script si basa su jQuery e pesa solamente 4kb. Non è intrusivo, degrada senza problemi in assenza di JavaScript o con i CSS disabilitati e può essere personalizzato facilmente anche nell’aspetto. Le immagini sono organizzate in una lista nel codice HTML: una soluzione ottimale.
Notevole anche l’efficienza dello slideshow, perchè le foto vengono caricate e mostrate solo quando disponibili, evitando attese nel momento dell’interazione.
Se conoscete altre soluzioni accessibili per la creazione di gallerie di immagini segnalatele nei commenti, è sempre utile conoscere le migliori risorse in questo ambito. Potete trovare altri script nel mio precedente post dedicato a Lightbox ed ai suoi cloni: se comunque volete uno slideshow accessibile il mio consiglio è di partire dagli script appena illustrati.
Con Internet Explorer 8 sarà possibile usare la proprietà CSS display:table. Cambierà qualcosa per i web designer?
Dopo aver abbandonato l’uso delle tabelle per il layout, in questo periodo si sta tornando a parlare del loro utilizzo in forma diversa: non più all’interno del codice HTML, ma con la proprietà display dei CSS.
Come fa notare Digital Web Magazine, con l’imminente uscita di Internet Explorer 8 questa proprietà supporterà correttamente i valori table, table-row e table-cell per la prima volta su un browser Microsoft. Le ultime versioni di Safari, Opera e Firefox seguono già gli standard e non dovrebbero avere alcun problema.
Come funziona la tecnica?
Basta realizzare una semplice struttura nel codice HTML con dei div:
<div id="main">
<div id="nav">
...contenuto della colonna
</div>
<div id="content">
...contenuto della pagina
</div>
</div>
Quindi è sufficiente applicare gli stili relativi, facendo in modo che il contenitore principale abbia un display: table, e le singole colonne un display: table-cell:
Da notare che una tecnica simile dal punto di vista della semantica del codice non presenta alcuna controindicazione. L’aspetto tabellare infatti viene gestito interamente tramite i fogli di stile, il markup è ben organizzato e non ha particolari differenze rispetto a quello di un layout con i float.
Incompatibilità e difetti
Per ogni nuova tecnica è fondamentale considerare quanto essa sia realmente applicabile. Nel caso dei layout a tabelle con i CSS, uno dei punti deboli è sicuramente il mancato supporto di IE6 e IE7. Non poter usare questa soluzione sui due browser che da soli rappresentano più del 70% del mercato, la rende di fatto inutilizzabile: al momento è poco più che esercizio di stile.
Un altro aspetto poco considerato è l’ordine dei contenuti all’interno del codice HTML. Con questa tecnica si ripresenta uno dei difetti principali delle tabelle: l’impossibilità di organizzarli secondo la loro importanza. Usando un layout tabellare tutti i vantaggi del posizionamento con i float spariscono, dovendo per forza di cose ordinare gli elementi secondo il loro ordine di apparizione nella pagina.
Se volete continuare ad approfondire il discorso, vi rimando ad un post di Edit di qualche settimana fa. Dal mio punto di vista, potrebbe essere interessante sperimentare la tecnica per il futuro, ma con qualche riserva. Sarà infatti possibile usarla quando IE6 e IE7 spariranno dalla circolazione, ma i CSS3 saranno ormai alle porte con nuove soluzioni per gestire il layout di un sito.
Il difficile equilibrio tra innovazione e buone consuetudini nella realizzazione di un sito web.
Nella realizzazione di siti web è normale che emergano delle tendenze più o meno di successo. E’ accaduto con i siti Web 2.0, poi è stata la volta dello stile grunge, nei prossimi mesi noteremo sicuramente nuove mode.
In questo ambito però viene spesso trascurata la componente innovativa: quanto è conveniente seguire le tendenze del momento a scapito della sperimentazione? Realizzare un sito che somigli a qualcosa di già visto potrebbe essere controproducente, e sicuramente non darà ai visitatori dei motivi per rimanere impressionati positivamente.
Un esempio chiave è il recente redesign di Duoh.com, presentato qualche settimana fa sul blog di Veerle Pieters: se non avete visitato la sua creazione vi consiglio di impiegare qualche minuto del vostro tempo per navigare tra le pagine ed esplorarle a fondo.
In questo caso l’obiettivo era realizzare qualcosa di innovativo, ed è stato centrato in pieno. Raggiungere un simile traguardo non è impresa da poco, anche perchè sperimentare significa uscire dagli schemi ed andare contro le mode del momento: a volte è indispensabile.
Veerle scrive a questo proposito:
we needed to explore some new territory and be a little experimental along the way
Esplorare nuove strade è necessario: se nessuno avesse il coraggio di andare oltre le consuetudini, avremmo siti tutti uguali. E’ quello che è accaduto nel periodo di maggior successo dello stile Web 2.0, che fortunatamente ora sta diventando obsoleto.
Sicuramente con il passare degli anni il Web Design ha le possibilità di evolversi e conservare alcune buone abitudini, l’importante è non fossilizzarsi su di esse. Non vanno dimenticati i passi avanti fatti nell’utilizzo della tipografia e in alcune scelte di layout (mi vengono subito in mente i footer alti), ma un Web Designer deve anche saper osare.
Nei vostri lavori quanto concedete alla sperimentazione? Trovare il giusto compromesso è probabilmente l’aspetto più difficile, ma se avete intenzione di farvi notare ricordate che non sempre è sufficiente imitare.
