Archivio per la categoria 'Design'

Rebranding web 2.0 logos

Martedì, 23 Gennaio 2007

Web2Logos

Da qualche tempo c’è un nuovo “virus” che sta dilagando nella community FlickR. Ridisegnare ogni tipo di brand conosciuto con stile web 2.0. Una vera droga. Sia per chi guarda, sia per chi partecipa.

Le produzioni per tutti gli utenti flickr, di cui vedete alcuni esempi nella foto che apre il post, sono taggate con: yay2dot0logoparody. Tutti possono partecipare ovviamente.

Il lancio dell’idea è stato dato su www.yayhooray.com, interessante notare come l’autore del thread discende da onetwentysix design studio e non lo nasconde.

Non so se il tutto era premeditato o meno, ma è nei fatti una brillante operazione di marketing promozionale 2.0.

Interessante anche vedere come onetwentysix ha disegnato il suo sito, un book fatto blog. Ogni post è un “dettaglio” visivo del brand su cui hanno operato, il tutto suddiviso in categorie che corrispondono alla loro offerta. Idea originale e presentata in una forma talmente “grezza” che per la teoria del contrasto emerge più di qualunque sito flash-corporate-design-trendy.

Colorfull Web 2.0

Martedì, 14 Marzo 2006

Tanto per variare su un argomento meno pesante di quelli trattati negli ultimi post, oggi mi soffermo su un aspetto del Web 2.0 che non ha a che fare con script, rails, ruby, CSS e simili. Il colore.

La generazione di designer che hanno il compito di vestire applicazioni web 2.0 sta scoprendo che esistono ben altre cromie che trasferiscono ben altre emozioni e soprattutto differenziano le nuove applicazioni 2.0 dalle precedenti, queste ultime infatti erano spesso basate esclusivamente su alcune gamme della web safe palette.

In questa nuova fase, la scelta ricade spesso su colori accesi, vitali, felici, ad alto contrasto. Vengono inoltre utilizzati spesso i pattern che in questo caso servono più come espediente grafico che non come una soluzione alla mancanza di colori di base. Il tutto sempre sotto il segno della legibilità.

Ovviamente l’uso spinto o meno di colori forti è dettato dalla complessità dell’interfaccia che si vuole vestire. Più l’applicazione è semplice, immediata, priva di troppe funzioni ed in linea con la filosofia 2.0, più diventa possibile utilizzare “blocchi” di colori forti, che servono in questo caso sia a dare uno stile riconoscibile che a rendere immediata l’identificazione dei diversi elementi che compongono l’applicazione. L’utilizzo di queste cromie legato ad altri espedienti grafici come i caratteri in dimensioni più grandi della media e un utilizzo maggiore degli spazi vuoti, fa si che il tutto venga percepito come più amichevole, semplice, divertente… “Lo può usare anche un bambino”.

Esistono oggi agenzie che si stanno specializzando in questo tipo di filosofia del colore come firewheeldesign, che di questo fa un vero e proprio valore del suo brand, mentre basta farsi un giro per siti e Web App 2.0 di spicco come flickR, blinksale, 30secondrule, 37signal, script.aculo.us, odeo e molti altri ancora per rendersi conto dell’uso che molti stanno facendo di queste gamme cromatiche.

Detto questo, di seguito ho tentato di riassumere questa gamma di colori in una palette.

In realtà, non è la base dei colori a fare la differenza ma il modo “intelligente” con cui questi vengono applicati. Se avete voglia di guardarvi qualche esempio, fate un salto su netcocktail.com dove vengono presentati alcuni casi molto interessanti.

Web Palette 2.0

Ragionando sulle Web App 2.0

Sabato, 4 Febbraio 2006

In questi giorni sto cercando di farmi un’idea più precisa su quelli che saranno i problemi da affrontare nella realizzazione di un’interfaccia applicata ad una Web App 2.0.

Quelli che seguono sono alcuni dei macro ragionamenti e relative assunzioni (in versione beta) che mi sono ritrovato a fare a riguardo, per quanto questo sia possibile in un ambito che nei fatti è tutto meno che definito… “beta” per l’appunto.

Develop for Developers

Quello che proprio non vorrei vedere nel Web 2.0 è il ritorno di quel tipo di fenomeno che molti di noi hanno conosciuto degli anni passati di internet definito come “Design for Designers”, una specie di fase edonistica in cui l’utilizzo di applicazioni rich media come Flash erano più usate per stupire o compiacere la comunità di noi creativi web che non come un mezzo per realizzare interfacce e/o passare messaggi utili al target finale.

Gli utenti non utilizzeranno le Web Application perché queste sono “Web”, sono sviluppate in RubyOnRails o solo perché “ieri su web non si poteva fare”, non faranno distinzione tra una Desktop Application e una Web Application ma utilizzeranno ciò che con maggior efficacia gli farà raggiungere un determinato obiettivo.

Marketing… Be clear!

Se dichiariamo al mondo che abbiamo realizzato una Web Application che si comporta come una Desktop Application, poi non ci stupiamo se l’utente rimane confuso o peggio deluso davanti a dinamiche che per limiti tecnici non saranno riproducibili su Web. Una Web Application non è = ad una Desktop Application. Non ancora per lo meno (qui parlo del presente).

Non sarà infatti la trasposizione dell’interfaccia Desktop -> Web a decretare il successo di una Web App ma l’efficacia delle modalità uniche del web che essa è preposta a servire. Se perdiamo il fuoco su questo, perdiamo il valore vero di questa trasformazione.

Keep it light
Teniamo presente che uno degli elementi che rendono un’interfaccia usabile e accessibile è la sua reattività. Inutile realizzare un’applicazione che ci stupisce con effetti speciali, Drag & Drop, bottoni super dettagliati e funzioni strabilianti se poi questa viaggia come un MacOSX fatto girare su un commodore 64. Esistono inoltre tutta una serie di limitazioni di cui tenere conto nell’interazione Client/Server asincrona tipica di AJAX, il click su un bottone non significa necessariamente l’esecuzione immediata e relativo ritorno di una determinata funzione. Va posta molta attenzione ai feedback da dare all’utente in questi casi.

Paradigmi acquisiti

Ricordiamoci che gli utenti hanno fatto propri dei paradigmi ormai consolidati nel loro quotidiano utilizzo dei software. Se la nostra applicazione web non ci permette di riprodurli per via di limiti tecnici, meglio rivederne le funzioni e provare altre strade che costringere l’utente ad imparare una nuova modalità di interazione ed un nuovo paradigma. Questo perlomeno se ci troviamo a trattare funzioni già consolidate nelle applicazioni tradizionali.
Facciamo in modo che sia la nostra applicazione ad adattarsi all’utente e non viceversa.


Creative Commons License
This work is licensed under a
Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Italy License.