Katter og hunder. Kain og Abel. Designere og utviklere. Disse er bare noen av de store historiske ansikts-offene.

Designere og utviklere synes ofte å komme fra forskjellige planeter og har helt forskjellige hjerner.

Utviklere ønsker at et nettsted skal fungere riktig, designere vil ha det til å se riktig ut.

For noen uker siden undersøkte vi hovedrollen pet peeves som webdesignere har med webutviklere , og foreslo noen løsninger for dem.

I dag skal vi diskutere den andre siden av mynten: de fem vanligste gripene som utviklere har med designere .

PEEVE # 1: "Hvorfor ønsker designere å lage alt i Flash?"

Nettstedet er bare en knapp og litt tekst, men designeren insisterer på å bruke Flash, selv om det tredobler nedlastningstiden.

Utgave
For noen designere, ved å bruke kjerne webteknologier (HTML, CSS og JavaScript) for å lage en nettside, kan det føles som en dødskule av innovasjon. De begrenser deres kreativitet og tvinger dem til å stole på utvikleren for å realisere sin visjon.

Flash gir designere potensielt ubegrensede designmuligheter, og de kan beholde langt mer kontroll over sluttproduktet, spesielt hvis de kjenner ActionScript. Med Flash kan designere velge mellom alle typer typografi, vippe og skrå elementer, legge til animasjoner og lage spesial effekter som bare er umulige i kjedelig ol 'HTML.

Løsning
Det første spørsmålet å spørre deg selv som utvikleren er, "Hva er den beste tekniske løsningen på problemet?" Det kan være kjerne webteknologi, eller det kan være Flash. Å ha et åpent sinn er viktig. For å finne ut hva som vil fungere best, sett deg ned med designeren og godta en liste over tekniske og designkrav for prosjektet.

For eksempel, undersøk om siden må lastes raskt, bruk en bestemt skrift for markedsføringsformål, møt tilgjengelighetsretningslinjer eller ha animasjon. Når du svarer på slike spørsmål, vil du være bedre i stand til å veie fordelene og ulemperne ved å bruke Flash.

Informere designeren om JavaScript-rammer som Dojo og jQuery er en god ide. De kan ikke innse den interaktive funksjonaliteten og spesialeffekter som kan oppnås med AJAX og DHTML.


PEEVE # 2: "Har designeren selv hørt om HTML CSS?"

Designeren har skapt et flott design ved hjelp av Photoshop, men nettet virker bare ikke slik.

Utgave
Noen designere synes å være forsettlig uvitende om selv de mest grunnleggende aspektene av webteknologi. Dette kan resultere i design som er slett urealistiske eller ekstremt vanskelig å gjenskape på nettet, som stole for mye på bilder for enkel typografi eller som fører til en underjordisk brukeropplevelse.

Løsning
CSS er språket for webdesign, og designere som arbeider i mediet, har egentlig ingen unnskyldning for ikke å forstå grunnleggende. Jeg ligner dette på mitt tidligere arbeid i utskriftsdesign. Jeg behøvde ikke å kjøre en av de mammutiske industrielle trykkpressene, men jeg måtte vite om fangst, halvtoner og CMYK.

Jeg måtte forstå prinsippene i utskriftsprosessen hvis jeg ønsket å oppnå de beste resultatene med designene mine. Det samme gjelder for webdesign. Designere trenger ikke å vite hvordan en server fungerer, men de bør ha grunnleggende kunnskaper om linjehøyde, polstring, bakgrunnsbilder og de andre faktorene som utgjør webutviklingsprosessen.


PEEVE # 3: "Designeren ga meg en PSD med 50 000 ikke navngitte lag og ingen mapper!"

Du laster ned 50 MB Photoshop-dokumentet, vent fem minutter for at det endelig skal åpnes, begynne å kutte en enkel knapp bakgrunn og står overfor en vegg med uidentifiserte lag i tilsynelatende tilfeldig rekkefølge, og halvparten er slått av.

Utgave
Utviklere må holde dokumentene godt organisert, ellers vil de ikke være effektive. Men hvis noe ser rett ut i visningsporten til Photoshop, er det ofte bra nok for designeren. Til en utvikler som er vant til objektorientert programmering (OOP) og en logisk rekkefølge for kode, kan dette være et mareritt!

Løsning
Utviklere er ikke de eneste som blir frustrert av uorganiserte og rotete PSD-filer. Som kreativ direktør sendte jeg tilbake mer enn en PSD med en forespørsel om at designeren organisere og navngi alle lagene. Adress dette problemet med designeren så tidlig som mulig. Gjør det klart at du trenger en ren og organisert fil.

Hvis det ikke er mulig (eller designeren er bare envis), er et triks for å finne laget av en gjenstand å rett / Ctrl + klikk det i visningsporten med Move-verktøyet (hurtigtastet er "v").

En kontekstmeny for alle lagene og laggruppene under markøren vises. Velg laget du vil ha, og hvis lagpaletten er åpen, blir det riktige laget uthevet.

Jeg anbefaler også å be designere å lære å bruke Photoshops smarte objekter . Smarte objekter lar deg samle de ulike lagene som utgjør et objekt (for eksempel lagene som inneholder en knapp), i en diskret fil innebygd i hoved Photoshop-filen.

Smarte objekter er enkle å bruke og tilbyr flere fordeler:

  • De lager en "objektorientert" Photoshop-fil, der gjentatte elementer har et enkelt "symbol".
  • De kan bli utført som web-klare elementer uten behov for rotete lagskive teknikker.
  • De gjør organisasjonen av PSD enklere ved å redusere antall lag i hovedfilen.


PEEVE # 4: "Designeren hadde ikke plass til innhold i realverden."

Vi bruker et CMS-system som gir kunden full kontroll over innholdet. Designmockupen viser imidlertid kun en linje med tekst for overskrifter og ett stykke tekst for teasers.

Designeren forventer balansert modulhøyder og kolonner, men vi kan ikke forutse mengden kopi som må passe der.

Utgave
Generering av greske (eller "Lorem Ipsum") -tekst er en tidskrevd metode for å legge til realistisk utseende, i fravær av nettstedets endelige kopi. Men fordi det ikke er ekte innhold, kan det føre til at designere gjør feilaktige konklusjoner om sidens endelige design.

Løsning
Designkomponenter er statiske, men ekte websider må være flytende og dynamiske. Designere bør gjenkjenne dette og dekke alle mulige scenarier. Dette er en av de viktigste begrensningene for å opprette statiske comps: de er ikke den virkelige tingen.

Jeg finner det nyttig å definere høyden på områder som vil bli brukt til å vise elementer som for eksempel overskrifter og teasere, i stedet for å la dem være åpne. Dette vil hjelpe deg med å finne ut nøyaktig hvor mye plass de vil ta opp i den endelige utformingen.


PEEVE # 5: "Designeren forventer at jeg skal gjette hvilke stiler han har brukt."

Designeren henvender deg til en kompis uten forklaring og forventer at du finner ut skriftfamilien, linjehøyder, farger, bredder, polstring, grenser og marginer.

Utgave
I motsetning til å lage en mockup i Photoshop, er webutvikling vanligvis ikke gjort i et WYSIWYG-miljø (det du ser er det du får). I stedet tilordner utvikleren spesifikke verdier for målinger, farger og typografi.

Løsning
Jeg ser denne sammenbrudd i kommunikasjon i mange prosjekter; Det fremhever en av de største forskjellene mellom "design" og "utvikling." Selv om designeren brukte en mal med et forhåndsdefinert grid, må utvikleren ofte øyeeball andre stiler.

Å ha designeren lage en stilguide som en leverbar, da er viktig. Stilguiden vil fungere som en avtalt plan for design og redusere forvirring.


Spesiell Bonus Peeve: "Jeg trenger ikke en designer som forteller meg hvordan man programmerer!"

Designeren vil ha noe gjort på en bestemt måte, uansett om du, utvikleren, mener at veien er tilrådelig.

Utgave
Designere som forteller utviklere hvordan man kodes, er like frustrerende som utviklere fortelle designere hvordan de skal gjøre jobben sin. Men linjen mellom designer og utvikler er ofte tynn, og noen ganger er begge roller berørt av samme person.

Hvis du har klart definert ansvar for et prosjekt, hører du noen som ikke var involvert i beslutningsprosessen andre, gjetningene dine er irriterende.

Teknikker som virker bra for andre på overflaten passer ikke alltid til det programmeringsmiljø du jobber med. Forklarer detaljene i dine tekniske beslutninger tar verdifull tid, når alt du vil, er at designeren skal stole på at du har gjort klare beslutninger .

Løsning
Lytt til hva designeren har å si om tekniske alternativer; du har kanskje ikke tenkt på dem alle. Mer enn en gang har jeg vært i diskusjoner med designere som brakte løsninger til bordet som jeg ikke var klar over, som for første gang jeg så jQuery i aksjon.

Husk at du og designeren (forhåpentligvis) deler det samme målet med å skape det beste produktet som er mulig. Hvis du holder et åpent sinn og en nivåhodet tilnærming, kan du ikke gå galt.


Skrevet utelukkende for WDD av Jason Cranford Teague . Han tilbyr spesialiserte web konsulenttjenester og treningsøkter. Du kan forhåndsbestille sin nye bok, Snakker i stiler: Grunnlaget for CSS for webdesignere på Amazon.com.

Hvilke pet har du med designere? Vi vil gjerne vite mer om dette, vennligst del dine kommentarer nedenfor.