Share
I den här artikeln diskuteras ett sätt att skriva steg-för-steg-handledning. Medan fokus här är för NETTUTS, kan mycket av tillvägagångssättet tillämpas för alla webbplatser. Om du planerar att skriva handledning för NETTUTS, bör du läsa / bläddra i den här artikeln. Det finns också en parallellartikel på PSDTUTS som redaktör Sean Hodge skrev, som faktiskt inspirerade den här.
NETTUTS handlar om handledning för webbutveckling. Det betyder webbläsarbaserad kodning, vilket kräver åtminstone en förståelse av HTML, en del CSS och något webbkodningsspråk. Allt annat beror på vad din handledning kommer att täcka. Detta kan vara CMS / bloggplattformskodning, PHP, JavaScript-bibliotek, CSS-ramar, databaser, etc..
Du har nog lagt märke till att de mest populära handledningarna här fokuserar på webbutveckling med ett design-y-element. Så att veta hur man använder grafikprogramvara som Photoshop eller Fireworks kan hjälpa till. Åtminstone veta hur man får en skärmdump, eftersom det här är det minsta du vill inkludera i din handledning för visuella element.
Du behöver inte bli riktigt formell, men du bör planera din handledning och tillämpa en checklista. Här är en föreslagen checklista, men ändå gärna ändra den enligt dina önskemål:
Det finns ett par sätt du kan gå på att bli publicerad på NETTUTS. Ett sätt är att skicka dina fungerande demofiler, källkod, handledningstext och bilder (alla ZIPped tillsammans) via formulärlänken på guiden Tutorial Guidelines. På så sätt får du ett svar mycket tidigare, men det är mycket arbete för dig att ha gjort om det inte är lämpligt för NETTUTS. (Detta rekommenderas fortfarande om du aldrig har lämnat in en handledning.)
Gör det lättare för dig själv. Istället för att skriva upp demokod och en handledning först, häll en idé först. Det rekommenderas faktiskt om du tidigare skickat en fullständig handledning, även om den inte publicerades:
I båda fallen, om en demo visar potential men handledningen behöver fungera, försöker jag att arbeta med dig på ett begränsat sätt för att förbättra texten. Men jag kan inte skriva det för dig. En massa kodutdrag och en del text som bara funktionellt beskriver vad som händer är inte en handledning.
När läsarna av NETTUTS växer, har jag mindre tid att bedöma huruvida en handledning passar NETTUTS. Gör det lätt på mig, gör mig vill använda din handledning och demo:
Sätt dig själv på min plats och fundera på vad som gör att jag vill acceptera din handledning. Testa inte en serie om du inte redan har fått en handledning godkänd och publicerad. Detsamma gäller för cross-site-serier (dvs del 1 för PSDTUTS, del 2 för NETTUTS).
I slutändan handledning är för läsare av webbplatsen, inte för mig. Om titeln på handledningen lockar dem, och om de läser igenom handledningen efter att ha tittat på demoen eller till och med den ursprungliga visuella bilden (bild, diagram mm), vill de lära sig. Medan du inte behöver behålla och beskriva varje kodlinje som om en läsare aldrig har kodat tidigare måste du beskriva kodens rader som är relaterade specifikt till bibliotek, plugins eller speciella tekniker du använder.
Det största problemet med inlämningar hittills: Använda ett kodbibliotek eller plugin, som visar en kodbit, men som inte beskriver de relevanta raderna av kod. Att säga, "här är koden att göra X," räcker inte. Varför skulle en läsare stör med din handledning om du inte avslöjar hur-till?
Innan du skickar in verklig handledningstekst, läs över några av Collis 'handledning här, som utgångspunkt. Även om det är bra att ha din egen stil, måste du också komma ihåg att de flesta webbplatsläsare har lite (eller mycket) webbkodningserfarenhet. Prata med dem, inte hos dem. (Jag är en verbose typ, som kommer från att ha varit en universitetsundervisningassistent / labinstruktör för icke-datorstudenter som tar en obligatorisk datorkurs.)
Det finns redan en handledning för riktlinjer för handledning, som har en länk till en blank handledning ZIP. Kontakta den här sidan och använd den här ZIP-mallen.
Vet du verkligen vad du vill ha typ av handledning du vill göra? Inte singling någon här ute, men några inlägg gav mig intrycket att personen bara ville ha fjädern i sitt lock att ha publicerats på en webbplats som NETTUTS. Deras handledning och demo kod beskrivning var vag, och trots min nudging om vad du ska försöka, bita de inte.
Ett av de bästa sätten att planera och bygga en handledning är att skissa ut dina idéer och skissera funktionerna såväl som vad du demonstrerar. Eftersom NETTUTS handledning är koddriven, har du extra krav att ha funktionskod att presentera. Här är min föredragna process för att skapa en handledning - men glöm inte den tidigare nämnda checklistan:
Även om det är trevligt att din demo fungerar i alla webbläsare, så är det inte alltid möjligt. Vissa kodbibliotek - t.ex. jQuery - stöder inte bara äldre webbläsare. I åtminstone bör din kod fungera för webbläsarna att bibliotek som du använder stöd.
Förresten, trots protesterna i form av kommentarer från vissa NETTUTS-läsare, är Firefox 3 inte i stor utsträckning vid tidpunkten för detta skrivande. Det är också buggy och fortfarande ett minne hog, enligt vissa Twitter och Plurk användare. Vi måste överväga webbläsarkompatibilitet från fall till fall, men försök att täcka de senaste stabila webbläsarna. Ange om din kod inte fungerar någonstans borde det, och varför det är.
Ett verktyg som hjälper dig med testning av webbläsare är webbplatsens webbläsare, vilket är ett enkelt sätt att testa din kod i flera (virtuella) webbläsare för Linux, Windows, Mac OS och BSD.
Till skillnad från vår systerwebbplats PSDTUTS, när det gäller web dev-tutorials är det inte alltid lätt att komma med sexiga bilder. Fortfarande gör visuella en handledning mer intressant, liksom hjälp att visa koncept. Så visuella i din handledning är ett måste, och du kanske måste bli kreativ. Här är några alternativ:
Inkorporera visuella bilder så ofta och tidigt som möjligt i din handledning. Många av de handledningar jag har avstått hittills hade inga bilder alls. Det är inte så svårt att ta en skärmbild av din applikation i bruk, eller en mockup-skärm produceras i Photoshop, eller vad som är relevant. Du behöver inte dussintals visuella bilder, men även ett fåtal välgrundade skärmbilder kan vara tillräckligt.
Notera: Om du använder visuella bilder från andra källor - antingen i din handledningstekst eller din demo - måste du ha uttryckligt eller underförstått tillstånd och måste citera källan / källorna. Till exempel kan du använda bilder från en källa som Flickr, under lämplig CC-kommersiell licens.
Förutom att kreditera bilder, se till att du krediterar alla kodbibliotek, källor etc. Det betyder inte att du kan presentera någon annans kod som din egen, men snarare om du har en stor handledning och använder en teknik som ursprungligen presenterades av någon annan, kreditera dem.
Utöver tutorials publicerar vi en artikel per vecka i samband med webbutveckling. Artikelbidragen är en gång varannan vecka. Resursartiklar är bra kandidater, till exempel min CSS Grid Frameworks artikel - men din behöver inte vara så massivt lång.
Min preferens är att acceptera ställen för artiklar från personer som är erfarna författare / bloggare, men du behöver inte ha skrivit en handledning eftersom stilen är annorlunda.
Jag försöker att svara på alla så snabbt som möjligt, men i några veckor är volymen av inlägg tillräckligt hög för att det är lätt för mig att förlora spåret. Jag är säker på att jag kommer att svara, men du kan knyta mig om du inte hört tillbaka om några veckor efter att ha skickat en idé eller handledning.
Jag ser fram emot fortsatta idéplatser och inlägg från NETTUTS-läsare. Om du inte vet var du ska börja, är Collis tutorials här på NETTUTS och PSDTUTS en bra modell att följa, både när det gäller skärmklipp, kodning och skrivstil.
Accentsconagua