Share
Som en front-end-utvikler som jobber mesteparten av tiden med forhåndsdefinerte designfiler levert av meg av en designer, blir jeg ofte utsatt for å forklare hva som effektivt kan oversettes fra Photoshop til nettet. Dette er på ingen måte en enkel oppgave, siden nyansene av nettet øker stadig, og å få en intuisjon for disse mulighetene vokser like hardt.
Jeg tror det er viktig å legge dette på bordet for alle ledere, ingeniører og andre som er bekymret for implementeringssiden av kreativiteten: Det er på tide å la designere bygge umulige ting. Det er på tide å skyve våre designere utenfor boksene (og boksene) vi har bygget for dem, og her er hvorfor.
Kreativitet trives innenfor de riktige grensene; Spesielt trives kreativitet innenfor begrepsgrenser som implisitt forme kreativ artefakt.
"Vi er rettet mot personer som liker uavhengige filmer og bor i forstadsområder", er et helt annet sett med begrensninger enn "vi kan bare bruke fire store bakgrunnsbilder på en hvilken som helst side".
Mens den første vil forme budskapet og virkningen av den kreative artefakten, former den artefacten selv. Hvis vi jobber med gode designere, vil de implisitte grensene (i stedet for de eksplisitte grenser) gi retning snarere enn hindring for den kreative prosessen.
Internett i dag er veldig annerledes enn nettet for en måned siden, mye mindre nettverket i begynnelsen av 2000-tallet. En primær kraft bak denne raske forandringen er at utviklingen av webteknologi drives av konkurranse for å møte utvikler og brukerbehov.
Hva dette betyr i praksis er enkelt: Utviklere og brukere gir stadig innspill til lagene bak utviklingen av nettleserlayout og rendering motorer. De viktigste aktørene i denne arenaen er WebKit (Chrome, Safari, og nå Opera), Gecko (Firefox) og Trident (IE). De to første motorene er åpenkilde, så forskjellige varianter av disse finner veien til nettleserne vi bruker hver dag. Microsofts Trident er lukket kilde. Tradisjonelt har open-source-motorer sett raskere vendinger av funksjonalisering og mer fleksibilitet med eksperimentelle funksjoner, og ettersom disse funksjonene blir standardiserte, gjør de seg til IE.
Funksjonsstandardisering implementeres ved hjelp av en "spec", og den spesifikasjonen opprettes ofte basert på tilbakemelding og iterasjon fra fellesskapet. Faktisk kan du være en del av gruppene som standardiserer disse funksjonene ved å delta i W3C (World Wide Web Consortium) postlister. Ved å tillate designere å drømme opp ting som for øyeblikket er umulige med nettleserteknologi, vil vi realisere uoppnådde behov i nettleseren i dag, og presse innovasjon fremover i morgen. Disse postlister er fellesskap tilgjengelige, og ting som bokseskygger og Geolocation APIs er født i disse tråder. Uten tilbakemeldinger fra samfunnet og behovet for nye, umulige ting, vil nettet fortsatt være fullt av animerte GIF og marquees. Yikes.
Poenget med godt utformede webartefakter er ikke bare å skildre den innebygde funksjonen til nettleseren, men i stedet for å formidle en melding og tilskynde til en handling. Hvorfor bør starten på et prosjekt være begrenset av noe som er irrelevant for meldingen eller ønsket brukerhandling? I stedet, la kreativitet og utforme beste praksis for å definere "best case scenario" - hvis hva som helst var mulig, hva ville være best? Etter at dette er blitt definert, kan ingeniøren som tar artefacten fra kreativ leting til et brukbart grensesnitt, redusere de umulige eller mindre praktiske funksjonene, og tilpasse beste scenario til det beste mulig scenario.
Dette kan strekke grensene for utviklingsprosessen for fronten, og det kan ikke være en "naturlig" utviklingsprosess. Denne metoden gjør det imidlertid mulig for meldingen å herske overlegen over prosessen, og kreativ leting å bidra til å diktere mer enn naturlig kjedelig funksjonalitet.
Selvfølgelig, som alle andre øvelser, er det nødvendig å øve balanse. Hvis alle funksjonene til en gitt web-artefakt er utformet utenfor mulighetsområdet, vil reduksjon til noe som er plausibelt for nettet være et mareritt for en ingeniør. Konstruksjonskunst er til slutt en balanse mellom kommunikasjon gjennom mulige midler på en ny og effektiv måte.
For å skape et miljø der mulighetene kommuniseres til rett tid i den kreative prosessen, følg disse enkle retningslinjene.
Designere skal alltid jobbe i iterasjoner, praktisere åpen kommunikasjon med utvikleren som vil jobbe med det prosjektet. Utviklerens jobb er å stille spørsmål for å forstå designers plan, og svare på spørsmål om feasability. Det bør legges vekt på utvikleren at en vanskelig jobb er ikke en umulig jobb, og det ukjente attributter er ikke ugjennomtrengelige attributter.
Hva dette betyr i praksis er at utviklere skal forbli optimistiske om å gjøre de tilsynelatende umulige tingene mulige, og avstå fra å begrense designørens ideer i hver iterasjon. De bør imidlertid også kunne gi nyttig tilbakemelding til designere om vanskeligheter og gjennomførbarhet når det er kjent. Ta følgende eksempler, for eksempel:
Joe Designer:
"Jeg vil gjerne lage et grensesnitt som dynamisk fjerner bakgrunnen fra et brukerprofil bilde og erstatter det med en dinosaur. Dette vil la brukerne ha dino-ified avatars! Og det ville være fantastisk."
Bob Utvikler:
Joe, du har rett. Det ville være fantastisk. Selvfølgelig er dette en "mulighet", men vanskeligheten med å gjøre en slik ting er sannsynligvis noe høy; er det verdt investeringen å skape en dino-ifier, eller kan vi la dem legge til dinos ved siden av deres bilde (som oppnår et lignende mål, med mye mindre innsats)?
Dette er et eksempel på samarbeid på jobb, og det peker på vårt neste tema.
Å balansere "innsats som kreves" med "potensielle gevinster" er en viktig oppgave, ofte etterlatt til høyere oppstart i selskaper. Imidlertid må denne typen beslutningsprosesser i et raske høyt iterasjonsmiljø skje mye oftere enn det som kan delegeres oppover. Å oppnå det samme målet med en parallell løsning som bærer mindre investering er en dynamisk, men viktig nyanse som alle utviklere og designere bør ta hensyn til når de jobber med et prosjekt.
For at dette skal være mulig, må designere og utviklere ha fullmakt til å ta avgjørelser, og prosjektets verdier må kommuniseres helt til bunnen for at beslutningene skal bli godt og i full tillit. Med andre ord, for Bob Developer å vite at dino-bakgrunnen ikke er verdt utviklingsinvesteringen, må han ha fått en intuisjon for verdiene som er innebygd i prosjektet. På samme måte bør Joe Designer også forstå den verdien umiddelbart.
Med den forrige kunnskapen i hånden kan vi samle at åpen kommunikasjon skal være en standard på alle nivåer i et gitt prosjekt. Hvis designeren har et spørsmål eller trenger avklaring av en komponent av den underliggende meldingen til en artefakt, bør de ha tilgang til ressursene som er nødvendige for å svare på det spørsmålet.
Designere bør ha frihet og makt til å ta vildt nyskapende beslutninger, og utviklere bør ha kraft til å drive tilpasning på prosjekter. Å dyrke en kreativitetskultur - første empowerment og adaptiv innovasjon vil til slutt gi mer intuitive lag som bygger mer effektive webartefakter.
Accentsconagua