Share
Come sviluppatore front-end che lavora la maggior parte del tempo con file di progettazione predefiniti trasmessi da un designer, mi trovo spesso di fronte al compito di spiegare cosa può effettivamente tradurre da Photoshop sul Web. Questo non è affatto un compito facile, dato che le sfumature del web sono in costante aumento, e acquisire un'intuizione per queste possibilità è altrettanto crescente in difficoltà.
Credo che sia importante mettere questo sul tavolo per tutti i manager, gli ingegneri e gli altri che sono preoccupati per il lato dell'implementazione della creatività: è tempo di lasciare che i designer costruiscano cose impossibili. È tempo che spingiamo i nostri progettisti fuori dalle scatole (e dai modelli di scatole) che abbiamo costruito per loro, ed ecco perché.
La creatività prospera all'interno dei giusti tipi di confini; in particolare, la creatività prospera all'interno dei confini concettuali che implicitamente forma l'artefatto creativo.
"Stiamo prendendo di mira individui che godono di film indipendenti e vivono in aree suburbane" è un insieme di vincoli molto diverso rispetto a "possiamo usare solo quattro grandi immagini di sfondo su una data pagina".
Mentre il primo modellerà il messaggio e l'impatto del manufatto creativo, il secondo plasma l'artefatto stesso. Se stiamo lavorando con buoni designer, i confini impliciti (piuttosto che i confini espliciti) forniranno una direzione piuttosto che un ostacolo al processo creativo.
La rete di oggi è molto diversa dalla rete di un mese fa, molto meno la rete dei primi anni 2000. Una forza primaria dietro questo rapido cambiamento è il fatto che l'evoluzione della tecnologia web è guidata dalla concorrenza per soddisfare le esigenze degli sviluppatori e degli utenti.
Ciò che in pratica significa in pratica è semplice: gli sviluppatori e gli utenti danno costantemente input ai team dietro lo sviluppo del layout del browser e dei motori di rendering. I giocatori principali di questa arena sono WebKit (Chrome, Safari e ora Opera), Gecko (Firefox) e Trident (IE). I primi due motori sono open-source, quindi diverse varianti di questi trovano la loro strada verso i browser che usiamo ogni giorno. Il Trident di Microsoft è closed-source. Tradizionalmente, i motori open source hanno visto una più rapida inversione di implementazione delle funzionalità e una maggiore flessibilità con le funzionalità sperimentali, e man mano che queste funzionalità diventano standardizzate, si fanno strada in IE.
La standardizzazione delle caratteristiche viene implementata mediante una "specifica" e tale specifica viene spesso creata in base al feedback e all'iterazione della community. In effetti, puoi far parte dei gruppi che standardizzano queste funzionalità partecipando alle mailing list del W3C (World-Wide Web Consortium). Consentendo ai designer di immaginare cose che sono attualmente impossibili con la tecnologia del browser web, realizzeremo esigenze insoddisfatte nel browser di oggi e spingeremo l'innovazione in avanti per domani. Queste mailing list sono accessibili dalla community e cose come box shadow e API di geolocalizzazione sono nate in questi thread. Senza il feedback della comunità e la necessità di cose nuove e impossibili, il web sarebbe comunque pieno di GIF animate e tendoni. yikes.
Il punto di artefatti web ben progettati non è semplicemente quello di ritrarre le funzionalità integrate del browser web, ma piuttosto di trasmettere un messaggio in modo sufficiente e stimolare un'azione. Perché, quindi, l'inizio di un progetto dovrebbe essere limitato da qualcosa che è irrilevante per il messaggio o l'azione dell'utente desiderata? Invece, concedete creatività e progettate le migliori pratiche per definire lo "scenario migliore" - se nulla era possibile, quale sarebbe stato il migliore? Dopo che questo è stato definito, l'ingegnere che sta portando il manufatto dall'esplorazione creativa a un'interfaccia utilizzabile può ridurre le caratteristiche impossibili o meno pratiche e adattare lo scenario del caso migliore al meglio possibile scenario.
Ciò potrebbe allungare i limiti del processo di sviluppo front-end e potrebbe non essere un processo di sviluppo "naturale". Tuttavia, questo metodo consente al messaggio di regnare sovranamente sul processo e all'esplorazione creativa per aiutare a dettare più di una funzionalità naturalmente opaca.
Naturalmente, come ogni altra pratica, è necessario praticare l'equilibrio. Se tutte le caratteristiche di un dato artefatto web sono progettate al di fuori del regno della possibilità, la riduzione a qualcosa di plausibile per il web sarebbe un incubo per un ingegnere. L'arte del design è, alla fine, l'equilibrio della comunicazione attraverso possibili mezzi in modi nuovi ed efficaci.
Per creare un ambiente in cui le possibilità siano comunicate al momento giusto nel processo creativo, segui queste semplici linee guida.
I designer dovrebbero sempre lavorare in iterazioni, praticando una comunicazione aperta con lo sviluppatore che lavorerà a quel progetto. Il compito dello sviluppatore è quello di porre domande al fine di comprendere il piano del progettista e rispondere a domande riguardanti la fattibilità. Va sottolineato allo sviluppatore che a duro lavoro non è un lavoro impossibile, e quello attributi sconosciuti non sono attributi non fattibili.
Ciò significa in pratica che gli sviluppatori dovrebbero rimanere ottimisti sul rendere possibili le cose apparentemente impossibili e astenersi dal porre restrizioni sulle idee del designer in ogni iterazione. Tuttavia, dovrebbero anche essere in grado di fornire un feedback utile ai progettisti in merito a difficoltà e fattibilità quando è noto. Prendi i seguenti esempi, ad esempio:
Joe Designer:
"Mi piacerebbe creare un'interfaccia che rimuova in modo dinamico lo sfondo da un'immagine del profilo utente e la sostituisca con un dinosauro, per consentire ai nostri utenti di avere avatar dinoidi! E sarebbe fantastico."
Sviluppatore Bob:
Joe, hai ragione. Sarebbe fantastico. Naturalmente questa è una "possibilità", ma la difficoltà di fare una cosa del genere è probabilmente un po 'alta; Vale la pena investire per creare un dinosauro, o potremmo lasciarli aggiungere dinos accanto alla loro immagine (che raggiunge un obiettivo simile, con molto meno sforzo)?
Questo è un esempio di collaborazione al lavoro e sottolinea il nostro prossimo argomento.
Equilibrare "lo sforzo richiesto" con "guadagni potenziali" è un compito importante, spesso lasciato ai più alti nelle corporazioni. Tuttavia, in un ambiente ad alta velocità ad alto ritmo, questo tipo di processo decisionale deve avvenire molto più spesso di quanto possa essere delegato verso l'alto. Realizzare lo stesso obiettivo con una soluzione parallela che porta meno investimenti è una sfumatura dinamica ma importante che ogni sviluppatore e progettista dovrebbe prendere in considerazione quando si lavora su un progetto.
Affinché ciò sia possibile, i progettisti e gli sviluppatori devono avere il potere di prendere decisioni e i valori del progetto devono essere comunicati fino in fondo affinché tali decisioni siano prese bene e in piena fiducia. In altre parole, per Bob Developer sapere che lo sfondo dino non vale l'investimento in sviluppo, deve aver acquisito un'intuizione per i valori incorporati nel progetto. Allo stesso modo, Joe Designer dovrebbe essere in grado di comprendere immediatamente quel valore.
Con la conoscenza precedente in mano, possiamo raccogliere che la comunicazione aperta dovrebbe essere uno standard, in tutti i livelli di ogni progetto. Se il progettista ha una domanda o ha bisogno di chiarimenti su un componente del messaggio sottostante di un artefatto, dovrebbe avere accesso alle risorse necessarie per rispondere a tale domanda.
I progettisti dovrebbero avere la libertà e il potere di prendere decisioni selvaggiamente innovative, e gli sviluppatori dovrebbero avere il potere di guidare l'adattamento sui progetti. Coltivare una cultura della creatività: prima l'empowerment e l'innovazione adattativa alla fine porteranno a team più intuitivi che creano artefatti web più efficaci.
Accentsconagua