Hur börjar du bygga en webbplats?
Majoriteten av utvecklare startar förmodligen från början eller drar in några resurser från tidigare webbplatser. Ju mer organiserade bland oss har utvecklat en anpassad verktygslåda för att starta en webbplats som visar sig vara en viktig del av deras arbetsflöde.
Idag diskuterar vi varför du borde överväga att bygga ditt eget frontpaket för att fungera som utgångspunkt för varje enskild webbplats du skapar.
Vad är ett frontpaket?
Vad jag menar med frontenpaketet är i huvudsak en uppsättning verktyg och konventioner som standardiserar vissa delar av webbutvecklingsprocessen. Inspirationen för denna artikel kommer från de kreativa sinnena hos Erskine Design. Som designer är du förmodligen en visuell tänkare så vi skär direkt till diagrammet:
Basic Outline eller Erskines Ultimate Front End Package
Som du kan se har Erskine väsentligen byggt en grundläggande ram för att hoppa av för stora webbdesignprojekt. De summerar det som • En stötfångarekompendium av kaskad och ansluten CSS-filer, namngivningskonventioner, moduler, plugins och biblioteksskript som säkerställer att ett projekt som leddes eller arbetats av någon eller några medlemmar i laget kommer att vara kvar på konventionen och vara enklare för någon annan att stega in i och arbeta med när som helst.?
Att ha ett sådant ramverk kan vara ovärderligt av ett antal skäl, som vi kommer att diskutera nedan. Argumentet av vissa är att en sådan ram eller verktygsverktyg inte bara är till hjälp, men absolut nödvändigt. Erskine Design s Simon Collison går så långt som att säga. Utan fråga eller kompromiss måste varje hemsida byggas med ett solidt fundament och ett Ultimate Package.?
Låt oss ta en titt på några av fördelarna med och anledningarna till att du bygger ditt eget anpassade frontenpaket. (Baserat på några av de förslag från Erskines presentation som hittades)
Eliminering av upprepning
Detta är den mest grundläggande och förståeliga orsaken till att du utvecklar ett frontpaket. Varje gång du börjar bygga en webbplats går du igenom flera installationssteg, som att bilda den tomma HTML-strukturen, skapa de externa CSS-filerna, länka HTML-filen till den externa CSS, importera jQuery och / eller andra JavaScript-biblioteken du använder ofta etc . Att utveckla ett front-paket återställer hela denna förlorade tid genom att göra det extremt enkelt att starta en ny webbplats: kopiera bara mappen som innehåller ramverket och du är igång.
Du kan hävda att dessa uppgifter inte tar betydande tid eller är till och med nödvändiga för att få din hjärna till en webbutvecklingsinriktning. För att svara på dessa argument skulle jag först föreslå att du själv tar tid för att se hur länge du förlorar på varje projekt att få din filhierarki på plats, konfigurera och ladda skript och stilar, räkna ut namnkonventioner och fixa slarviga misstag. Jag satsar det är mycket mer än du tror. Slutligen, till det senare argumentet, skulle jag utmana dig att omskola din hjärna för att acceptera en ny del av processen som början. Försök hoppa direkt in i experiment med ditt system på plats och upptäck hur mycket trevligare det är att hoppa över alla tråkiga, upprepade uppgifter.
Standardisering
Standardisering är en stor fördel med att använda en prefabricerad verktygslåda. Varje gång du startar ett nytt projekt kan du göra saker lite annorlunda. Det här kan vara något stort, som att ändra hur du layoutar din HTML, eller något litet, som att bestämma om en ny namngivningskonvention. Detta kan göra det extremt svårt för andra att följa ditt arbete eller till och med för att du ska gå tillbaka senare och komma ihåg hur du gjorde saker vid den tiden.
När du utvecklar ditt frontändspaket, behåll standardisering i spetsen av ditt sinne. Bestäm det bästa sättet du vet att göra varje liten sak och hålla fast vid dessa konventioner genom varje projekt du börjar. Markera dina kommentarer på samma sätt, organisera din CSS på samma sätt, använd samma variabla namngivningskonventioner, använd samma mapphierarki, använd samma CSS-återställningar etc. Med alla de små besluten och gissningen från ditt system har du fördelen av effektivisera hela utvecklingsprocessen för att säkerställa att du skapar en urskiljbar, organiserad webbplats så snabbt som möjligt.
Detta är inte att säga att du ska bestämma ett system och hålla fast vid det permanent. Låt det utvecklas när du lär dig och upptäcka bättre metoder, helt enkelt inte integrera nya metoder flippigt eller tillräckligt ofta för att ogiltiga användbarheten av hela paketet. När du bestämmer dig för ett bättre sätt att göra något, se till att du är helt säker på att det kommer att förbättra ditt system och vara säker på att göra en anteckning som beskriver förändringen och när den integrerades så att du vet vad du kan förvänta dig av äldre projekt.
Bättre samarbete
Det här är en frontpaket som passerar över från? Trevligt att ha? till "absolut nödvändigt". När du arbetar med ett team av utvecklare på ett stort projekt är en av de största ineffektiviteterna du kan ha ett misslyckande att få alla på samma sida från början av projektet.
Om du har Bill att strukturera sin del av projektet på ett sätt, Jill strukturerar sin del på ett annat sätt, och kommer att försöka hålla sig till både Bills och Jills metoder, kommer saker att bli rotiga snabbt (och inte bara för att alla dina anställdas namn råkar vara rimligt). Detta kommer oundvikligen leda till att långa möten spenderas över diskussioner. Om du har teammedlemmar som redan har startat ett projekt med vissa konventioner kan du satsa på att de ska försvara den metoden till döden för att undvika att gå tillbaka och bestämma vad de anser vara färdiga arbeten. Därför är det ytterst viktigt att utveckla ett frontpaket i de fall där ett betydande samarbete är inblandat.Du kommer förmodligen fortfarande att hålla ett möte för att bestämma specifika konventioner att följa, men du kommer att upptäcka att lagmedlemmarna är mycket mer flexibla för nya metoder om det inte kräver backtracking.
Den viktigaste borttagningen här är att utveckla ett system innan ett projekt börjar, inte under. Detta ökar chansen att acceptera och förhindra många inkompatibilitetsproblem på vägen. Också, var noga med att ta med ditt lag i beslutsprocessen. Detta är enormt viktigt för paketets framgångar av ett antal skäl. För det första är det alltid en dålig idé för ledningen att skapa ett system för att effektivisera en viss uppgift utan att samråda med de personer som är närmast den uppgiften. Oavsett hur många mer college grader du har än folket under dig, chansen är att de är den enda bästa auktoriteten på vad som kommer och inte kommer att fungera. Slutligen är bortsett från frågan om effektivitet återigen fråga om acceptans. Om du ger ditt lag en uppsättning riktlinjer som de inte har haft någon roll att utveckla, kommer de att dra sina fötter och klaga hela vägen för att du tvingar dem till något de inte vill göra. Om du låter lagmedlemmar från alla nivåer aktivt delta i konventets utveckling, är de dock mycket mer benägna att överensstämma med det nya systemet eftersom de hjälpte sig i skapandet och inriktningen.
Kvalitetskontroll
Genom att utveckla ett frontpaket kan du implementera en viss grad av kvalitetskontroll över medlemmarna i ditt team från början av projektet. Det säkerställer vanliga misstag, som att ta bort fel doc-typ eller glömmer att inkludera ett visst webbläsars specifikt stilark, görs inte. Vidare, med ett strikt system på plats kan det förhindra avsiktligt slarvigt arbete. I en galna rush för att få ett projekt att gå, kommer utvecklare ofta använda icke-standardkompatibel kod, oklara variabla namn, obscure tricks och några andra genvägar med argumentet att de kommer att gå tillbaka och fixa dessa saker senare. Problemet är naturligtvis att det vanligtvis inte är dags att gå tillbaka och fixa dessa saker senare i projektet när du närmar dig viktiga deadlines. Många av dessa problem kommer att försvinna om du skapar en kultur som undviker sådana metoder och avskräcker från att komma överens med överenskomna konventioner.
Med hänsyn till design och innovation
Innan jag stänger och ber om att höra era åsikter vill jag förutse ett argument som kan uppstå. Många ser gemensamma konventioner och strikta regler som något som kommer att förkrota designprocessen, vilket nästan eliminerar utrymme för kreativitet eller innovation. Detta är helt enkelt inte fallet i det här fallet och är faktiskt det motsatta resultatet av vad en väl utformad frontändspaket kommer att ge.
Ett bra frontpaket låter dig faktiskt fokusera mer på de kreativa elementen i utvecklingsprocessen genom standardisering av områden som äter upp tid och vars variation inte skulle göra någon signifikant skillnad i slutresultatet. Vad jag menar med detta är att sådana element som din mapphierarki kommer att gå helt obemärkt av slutanvändaren och är därför inte platsen att fokusera din kreativitet på varje enskilt projekt. Tanken här är att komma igenom de tråkiga grejerna i ett fall, så att du snabbt kan gräva i de saker som gör och borde variera från sida till sida. de saker som gör varje webbplats unik. Med den här typen av system på plats kan du spendera mer tid på att utveckla ursprungliga användargränssnitt, välja egna färgscheman, försöka använda olika typsnittfamiljer och kodande innovativa funktioner.
Om det system du uppstår hindrar den kreativa processen, gör det helt enkelt inte sitt jobb och bör därför skrotas till fördel för en resa tillbaka till ritbordet.
Gratis resurser
Såld på idén att utveckla ditt eget frontpaket men vet inte vart du ska börja? Här är några gratis resurser för att komma igång.
- En Killer Collection av Global CSS Reset Styles
- HTML Blank Page Exempel
- Ett enkelt PHP-mallsystem
- Google-kod: Hosted JavaScript-bibliotek (jQuery, MooTools, etc)
- 16 Grundläggande CSS Layout Mallar
Tala om dig
Ovanstående representerar mitt långvariga argument för varför jag tror att Erskine Design har rätt att hävda att varje webbplats borde byggas från en stark, standardiserad och förinställd grund. Låt oss veta om du tror att utveckla ett sådant system är värt din tid. Bättre än, om du har ett system på plats, låt oss veta hur det fungerar!