Prototyping i kode

Først og fremmest, lad os få noget ud af vejen. Prototyping i kode er noget af en misvisende beskrivelse inden for rammerne af det, vi skal diskutere. Kode lyder skræmmende, det er noget, programmører gør. Det, vi taler om her, er langt mindre skræmmende - alt, hvad vi sigter mod at promovere, er det grundlæggende koncept, at du med nogle meget enkle HTML og lidt CSS kan producere prototyper, der kommunikerer dine ideer langt bedre end noget diagram- eller wireframing-værktøj. nogensinde kunne.

Hverken HTML eller CSS kræver nogen som helst programmering. HTML beskriver strukturen på en side, og CSS håndterer layout og dekoration. Der er ingen voodoo involveret, ingen skjulte fælder eller noget, der kan gå mystisk galt, hvad du skriver er, hvad du får. Det er også en meget øjeblikkelig form for tilfredshed.



Skrivemærkning er på en eller anden måde havnet i udviklingsopgaver i en masse bureauer. Designere, der skriver markering, er lige så sjældne som gyngehestepo, hvilket synes at være i modstrid med den retning, som nettet er på vej mod. Med responsivt design, der vinder fordel og webtypografi, der endelig modnes til en tilstand, hvor webskrifttyper er anvendelige, er dagene til produktion af billeder af websteder nummererede. Medmindre designere begynder at reagere, vil der være en meget ubehagelig periode, mens vi tilpasser os den nye måde at tænke og designe på nettet på.



Prototyping i kode bringer med sig en hel række fordele og meget lidt i vejen for ulemper. Denne artikel er ikke designet til at være en tutorial om HTML eller CSS (der er masser af dem omkring: tjek for eksempel Anna Debenhams crashkursus ) men mere en gennemgang af nogle af begrundelsen, de tricks, de processer og teknikker, du kan bruge til at opbygge HTML-prototyping i din arbejdsgang.

Fordelene

At designe en brugeroplevelse til websteder eller apps ved hjælp af diagram- eller wireframing-værktøjer er af flere årsager problematisk. For det første og sandsynligvis vigtigst ud over alt andet fejler du oplevelsen. Uanset hvor fangled eller interaktivt dine værktøjer giver dig mulighed for at få, er output generelt ikke noget som et rigtigt websted. De få værktøjer, der findes, der faktisk spytter HTML ud, gør et så dårligt stykke arbejde med at gengive HTML, du bruger mere tid på at hacke dine diagrammer for at gøre dit bud, og filerne bliver så uhåndterlige, at de er et mareridt at vedligeholde og arbejde med.



Mere vigtigt er det, at ved at bruge et værktøj til at skrue din HTML ud, lærer du faktisk ikke, hvad HTML er og gør, og derfor går du glip af muligheden for at gøre dig bekendt med grænserne og nuancerne for den teknologi, vores ideer bliver bygget med. Jared Spool, der er en stor forkæmper for designere og UX-udøvere, der kender kode, siger det pænt: ”Du forstår bedre det medium, du arbejder i” og fortsætter “hvis du ved, hvad der er let at kode og hvad der er svært at kode, du kan få dine ideer implementeret hurtigere (og flere af dem, da udviklingstid er en begrænset ressource). At forstå, hvad dit medium klarer sig godt, og hvor det ikke er så effektivt, giver mere informerede designbeslutninger. '

Når du ser på det på disse vilkår, ser det ud til, at enhver, der designer til internettet, ikke forstår de ting. Selvom du ikke ender med at være ansvarlig for produktionsopmærkning (vi taler mere om det senere), vil du være i stand til at have mere informerede diskussioner med dem, der gør det, og selvfølgelig give informeret vejledning om præcis, hvad du vil have bygget.

Den anden åbenlyse fordel ved prototyping i native HTML er designet til dit websted eller din app bliver præsenteret, hvor det hører hjemme: i en browser. Ikke i en PDF eller på papir eller i en sød Powerpoint-præsentation. De brugere, du tester den på, eller den klient, du præsenterer for, får beskæftige sig med produktet i dets naturlige habitat. Interaktioner er ægte, klik / berøringsadfærd er helt naturlig, tekst ser ud og reagerer på en måde, som folk er fortrolige med, og formularer fungerer, som de skal. Ved at gøre prototypen tættere på den faktiske tilsigtede oplevelse får du meget mere trofast feedback fra både brugere og kunder. Der er ikke noget hul i kognitiv proces eller fantasi, der er nødvendig for brugeren at engagere sig i proto på en naturlig måde. Det gør dit liv som designer så meget lettere, når du opererer i et paradigme, der faktisk matcher den tilsigtede levering af den ting, du designer.



Ud over de åbenlyse fordele ved at være i stand til at skabe egentlige interaktioner, ikke tilnærmelser af dem, er det faktum, at du nemt kan se og teste dit arbejde på andre enheder en gave. Der er i øjeblikket ingen andre måder til effektivt at designe et lydhørt sted lige nu end ved markering, så hvis dit projekt kræver, at du imødekommer det behov, skal du omfavne teknikken temmelig hurtigt, ellers bliver en anden nødt til at afhente dette projekt.

Det faktum, at du kan se og teste dit arbejde på andre enheder er en gave (kredit til Nathan Ford for håndmodellering)

Det faktum, at du kan se og teste dit arbejde på andre enheder er en gave (kredit til Nathan Ford for håndmodellering)

Debunking myterne

Prototyping i kode er ikke (for de fleste mennesker) en rute til at blive en frontend-udvikler, eller jeg skal nok påpege, nogen form for trussel mod en frontend-udvikler. Rent pragmatisk bruger du bare HTML som et værktøj til at udtrykke dine ideer, omend på det naturlige sprog på nettet. Og det er her, der en gang imellem opstår strid, når udviklere føler, at deres tæer bliver trampet på og måske håner over din indsats. Ud over at være sårende og utroligt nedslående, når du er ny på alt dette, er det også helt meningsløst. Der er nul plads til kodesnobberi i prototyper. Hvis du gør det klart, at HTML og CSS, du laver, bare laver et job og ikke har til hensigt at gøre det til produktion, vil folk slappe af. Det betyder også, at du ikke bekymrer dig om at gøre din markup og CSS perfekt. Det er der for at være rent funktionelt, og da det er en prototype, der uundgåeligt vil ændre sig uden at blive genkendt og / eller blive smidt væk - jo hurtigere og undertiden mere snavset, jo bedre.

Også, jeg skal nok nævne værktøjer kort her. Du kan begynde at prototype HTML nu uden at installere noget på din pc eller Mac. Selvfølgelig kan du købe specialsoftware, der gør redigering af tekst lidt mere velsmagende, men valg af teksteditor er en ret personlig ting, så prøv et par ud og se, hvad du bedst kan lide. De fleste har en gratis prøveperiode, så prøv og se, hvad der fungerer for dig.

Snyde

Hvilket pænt fører mig til mit næste punkt. Hvis du er i tvivl, snyder du. De fleste smarte udviklere gør aldrig det samme to gange. De genbruger koden. Det er god praksis. Men ud over det og opret dit eget sæt med dele (mere om det lidt), se dig rundt på nettet.

Fordi du arbejder i HTML og CSS, bliver du ret dygtig til at springe hætten (højreklik, se kilde) på et websted og hjælpe dig selv med en eller anden kildekode. Hvorfor genopfinde hjulet? Hvis der er en formular, der ligner den, du har brug for, skal du nab den. Hvis der er lidt af et billedgalleri, der stort set ligner det, du har designet, så lån det.

Selvfølgelig er der et stort forbehold her. Du er nødt til at udvise en form for sund fornuft og have dit moralske kompas sat til anstændighed. Det er absolut ikke sejt at bare engros stjæle et helt websted eller faktisk rulle nogen af ​​den 'lånte' kode i produktion uden udtrykkelig tilladelse fra forfatteren. For at være ærlig er der masser af nyttige tutorialsider og open source mønsterbiblioteker rundt (for eksempel hackbook.hackasaurus.org/) : du skulle ikke rigtig nogensinde have brug for det, men du er blevet advaret!

Mozilla

Mozillas Hackbooks er et praktisk kodebibliotek med kode til dine hacks

Ud over at hakke pre-built markup fra andre kilder er der masser af onlineværktøjer derude til at hjælpe med de mere besværlige og skræddersyede krav til en prototype. De to største tidssænkninger og årsager til frustration er formularer og tabeller. Selv din mest hærdede frontend-udvikler stønner af at skulle bygge et komplekst bord eller en form, så vær ikke modløs, hvis du finder dem kedelige og lidt vanskelige. Heldigvis er der utallige smarte onlineværktøjer, der gør meget af det tunge løft for os, der automatisk genererer ret anstændig markering fra en simpel GUI. En hurtig Google-søgning vil trække et stort udvalg af værktøjer, der dækker mange af de smertefulde opgaver, og giver dig kodestykker, du bare kan falde ind i din egen og om nødvendigt tilpasse dig, hvilket sparer dig utallige timer og en masse besvær.

To, som jeg opbevarer i min bogmærkemap til reference, er Kotatsu , som er en pæn bordbygger, der giver dig mulighed for at injicere klasser på celler og rækker meget let, og pForm , som er en virkelig glat træk og slip formbygger, der gør sammensætningen af ​​virkelig komplicerede former en absolut brise. Du finder uden tvivl dine egne favoritter, men vær sikker på at hvis du finder dig selv i at kæmpe mod noget, kan du være temmelig sikker på, at en anden har oplevet det samme før dig og derefter lavet et lille script eller en widget for at berolige den smerte væk.

960.gs

Nathan Smith er en supersmart designer og udvikler, der sammensætter 960.gs , en fantastisk lille pakke med værktøjer, der gør prototyping (og produktion, hvis du vil) ved hjælp af et gitter til layout til et absolut stykke kage. Inkluderet i pakken er alt hvad du nogensinde har brug for fra gitterskabeloner og guider til fyrværkeri og Photoshop, til skitseark og vigtigst af alt det CSS-bibliotek, han oprettede, der gør al den magi.

Brug af 960 er latterligt simpelt. Henvis bare til CSS-filen i din HTML, og du kan lægge robuste prototyper i løbet af få minutter ved hjælp af meget enkle klassenavne på din markering. Der er en temmelig definitiv tutorial over på net.tutsplus.com/tutorials/html-css-techniques/prototyping-with-the-grid-960-css-framework/, så vi prøver ikke at dække det her, men når du først ' har hovedet omkring det grundlæggende, vil du undre dig over, hvorfor du gjorde det på en anden måde.

960-gittersystemet gør prototyping ved hjælp af et gitter til layout til et absolut stykke kage

960-gittersystemet gør prototyping ved hjælp af et gitter til layout til et absolut stykke kage

Behandle

Prototyping i kode fremskynder bestemt din arbejds- og testproces, når du først får hovedet rundt om det grundlæggende. Du skal dog sandsynligvis justere din egen arbejdsgang lidt for at tilpasse sig den. Jeg har stort set stoppet wireframing for de fleste projekter. I stedet for omhyggeligt at skitsere hver eneste detalje i et design, jeg arbejder på, arbejder jeg hurtigere og løsere med enkle tegninger. Ofte ikke af hele sider, men af ​​elementer: Jeg begynder at prototype mod brugernes mål og behov, så kommer disse sammen som mere komplette layout.

Skitse først: tegne nogle enkle skitser af elementer på siden, som senere, når du begynder at prototyper, kommer sammen som komplette layout

Skitse først: tegne nogle enkle skitser af elementer på siden, som senere, når du begynder at prototyper, kommer sammen som komplette layout

Det er en god øvelse i at validere dine beslutninger og fremme enkelhed. I stedet for let at chippe alt på siden og derefter blande dem rundt, da det er alt for let at gøre, når du tegner kasser i et diagramværktøj, har du en tendens til at rationalisere hver beslutning. Fokuser på, hvad der virkelig er vigtigt for at få det, du har brug for, og etablere hierarkier, topografi og flow på en faktisk side. Når du har at gøre med en rigtig side, er det overraskende, hvor meget det ændrer dit perspektiv på, hvordan en idé kommer sammen.

Vi har en tendens til at arbejde fra en delt Dropbox-mappe til de fleste prototyper og give klienter adgang til den mappe. Hvordan du vælger at dele din, afhænger af din personlige opsætning. Du kan gå meget lo-fi og arbejde fra din lokale maskine og bare sende en zip-fil, eller hvis du har en venlig sys-admin og en iscenesættelsesserver, kan du altid dumpe filerne derinde. En hurtig note om brug af en webserver ud over bare at køre prototypen fra din dokumentmappe eller hvad som helst. Du har mange flere muligheder for mere avancerede prototyper senere, hvis du tilføjer nogle server-scripting med simpel PHP eller aspx. Værd at overveje, da det virkelig er simpelt at få nogle meget nyttige funktioner til meget lille indsats eller faktisk kodningsevne.

bedste papirvægt til tredobbelt brochure

Ændringsstyring er naturligvis vigtig. At køre dine prototyper i mapper og bare duplikere og derefter inkrementere versionsnumre er en ret enkel, men effektiv måde at gøre tingene på. Det er sandsynligvis overdreven at begynde at tænke på korrekt versionstyring på dette tidspunkt, men det er værd at overveje i fremtiden, hvis dine prototyper bliver komplekse, eller hvis du har flere mennesker, der arbejder på dem.

Avancerede tip

Ud over det grundlæggende ved at lære grundlæggende HTML, jo mere du bliver fortrolig med ind og ud på de sider, du bygger, vil du uden tvivl udvikle en række smarte tricks og tip, der sparer dig meget tid og kræfter fremad. Hvert projekt bringer sine egne unikke krav med sig, men hvis jeg kan give dig to råd, der sparer dig utallige timer, ville de være:

  1. Byg et bibliotek med ting. Det betyder ikke noget, hvordan du gør det. Det kan være en mappe med uddrag eller noget mere struktureret som f.eks Coda klip (små stykker kode, du kan genbruge ved at trække til dit dokument). Uanset hvad vil du snart udvikle en bunke bits, som du stort set kan Frankenstein sammen til noget.
  2. Brug inkluderer. Hvis der er ting, du bruger på hver side, der måske eller måske ikke skal ændres på tværs af hele prototypen (en nav, en sidefod osv.), Så trækker du det afsnit ud og dynamisk inkluderer det i dit dokument, at du kun behøver at vedligeholde det på ét sted. Hvis du ændrer det, bliver det automatisk anvendt på hver side, der bruger det. Dette var tidligere begrænset til scripting på serversiden ved hjælp af PHP eller ASP.

Men takket være jQuerys vidundere kan du nu opnå det samme utroligt nemt ved hjælp af Johann Burkards fantastisk enkle inc.js-script . Uanset hvilken rute du vælger, sparer du bogstaveligt talt timer ved at bruge denne teknik.

inc inkluderer i IE uden ActiveX-kontroller, erklærende inkludering af fjernindhold og tilbagekald før og efter inklusion for at omdanne indhold

inc inkluderer i IE uden ActiveX-kontroller, erklærende inkludering af fjernindhold og tilbagekald før og efter inklusion for at omdanne indhold

Troskab

Endelig, men bestemt ikke mindst, er spørgsmålet om troskab. Skønheden ved prototyping med HTML og CSS er, at du med et sæt HTML kan anvende forskellige grader af styling på det samme dokument bare ved at slukke CSS. Så du kan starte meget enkle, sorte og hvide kasser, som en traditionel trådramme, og derefter øge troværdigheden til specifikke brugssager. Brugere (og klienter) kæmper ofte for at forholde sig til meget parede trådrammer, så til test kan du anvende mere UI 'glans' for at få prototypen til at føle sig tættere på et ægte produkt. Du kan selvfølgelig gøre dette selv eller arbejde sammen med dit designteam for at begynde at rulle på deres visuelle sprog tidligt for at se, hvordan det klarer sig med brugerne i en reel verdenssammenhæng.

Så for enhver, der er nervøs for at give prototyping i kode, vil jeg sige: vær ikke. Start lille og langsomt og arbejd dig op. Bed en frontend-udvikler om hjælp og råd, hvis du har brug for det (de bider ikke). Og hvis du hurtigt vil komme op i hastighed, UX Bootcamp kursus er meget billig og vil komme i gang på bare et par dage.

Hvis du kan lide denne funktion, skal du også tjekke Anna Debenhams crashkursus den opbygning af prototyper i HTML og CSS .