Preface

Snart 20.000 emner har set dagens lys på FlashForum.dk. Nogle har været starten på lange diskussionståde, mens andre aldrig har fået så meget som en eneste tilbagemelding. Hvorfor kan det lade sig gøre? Har det været dårlige emner? Svære spørgsmål? - eller er der andet der holder folk fra at svare på en post? Måske er du en af dem der undre dig over du aldrig fik hjælp. I denne artikel vil jeg give mit bud på hvad der kan gøres for at lave en bedre post, som flere måske ville tage sig tiden at svare på.

Indledning

Jeg har efterhånden svaret på en mængde forum emner, gennem årene. Af og til tager jeg et kig ned over listen med ubesvarede emner, og ofte tænker jeg "Gad vide hvorfor der ikke bliver svaret på dem?". - jeg tager udgangspunkt i mig selv, og vender spørgsmålet til: hvorfor gider JEG ikke svare på den her post? Det er blevet til mange spørgsmål og svar gennem tiden, og det er disse svar jeg vil prøve at strukturere og samle her.

Fokus

Mit fokus er holdt omkring de emner der omhandler spørgsmål eller hjælp til at komme videre med et given problem. De har et fast mønster og udgør størstedelen af de emner der oprettes i forumet.

Motivation

Skåret til benet er motivationen at minimere antallet af ubesvarede emner, og give en lettere deltagelse for andre at kunne hjælpe. Sidste punkt er tanken om at jo bedre en problemstilling er formuleret jo lettere er det for folk at forstå og komme med et bud omkring.

Opbygning

Artiklen er opbygget i inddelinger der har hver deres overskrift, som afgrænser emnet, og derefter en diskussion af emnet.

Overskriften

Skriv en beskrivende overskrift. Der er ikke noget mere intetsigende end en post der er døbt: "Hjælp". De fleste emner omhandler hjælp eller spørgsmål til problemer, så ord som "Hjælp" , "problem" og lignende er helt overflødige i forhold til en overskrift. - og de kan slet ikke stå alene!
Hvis du synes det er svært at give et godt navn til dit emne, så vent eventuelt med at navngive det til du har skrevet selve indholdet. Det giver ofte en bedre klarhed omkring hvad det præcist er du ønsker.

Gå helt til benet. "Hjælp til preloader", "preloader problem", "problem med preloader" osv. siger næsten lige så lidt som bare "hjælp" eller "problem". Spørg dig selv, hvad det konkret er du ønsker at have ud af den post du er ved at oprette. Det er langt mere præcist at skrive "Udregning af load progress", "Automatisk fjernelse efter load", eller hvad det nu konkret er du har problemer med f.eks. med din preloader.

Lav en sandwich

Brug tid på at beskrive dit problem. Hvis nogen skal bruge tid på dit problem, er det kun fair at du har brugt tid på at formulere problemet så det er afgrænset og til at forstå for andre.

En såkaldt sandwich model, er en let måde at beskrive en problemstilling på. Sandwichen består af 3 lag, som er hver er en inddeling i dit emne.
Øverste lag er indledningen, næste lag er bøffen - selve problemet/spørgsmålet og nederste lag er afrunding.

Lav en lille overskrift til hver del, så det er let for folk at se afgrænsningerne. Et eksempel kunne se således ud:

OverskriftProcent tal for load af en swf.

Intro
Jeg er igang med at lave et site, hvor jeg loader swf filer ind, for hver hovedmenu punkt jeg har. Disse filer loades ind i en hoved swf som er holder for menuen og en preloader. Preloaderen skal komme frem hver gang men vælger et menupunkt mens der loades en swf ind.
Problem
Jeg vil gerne have preloaderen, til at vise et text felt med procent for hvor langt den valgte swf er kommet med at loade. Hvordan kan jeg finde frem til disse tal?
Afslutning
Jeg bruger Loader klassen til at loade mine swf filer ud med.
Et eksempel kan ses her: www...

I eksemplet ovenfor ville en overskrift som "problem med preloader" ikke være ret præcist.

En anden ting der er værd at bemærke er at ofte er introen til selve problemet langt den største part. Med en god intro kan folk lynhurtigt "fange" hvad der skal foregå, og når de så når til selve problemet, formuleret i form af et par konkrete spørgsmål, vil det være langt lettere at komme med gode og præcise svar.

Formater din kode

Et fantastisk værktøj når man skal beskrive et problem, er muligheden for at kunne indsætte den del af programmet som kan være skyld i problemet. Brug det som et værktøj til at vise bidder af din kode, der er i relation til problemstillinge.
Sørg for ALTID at bruge formattering. Du finder kodeformatteringsværktøjet her:

Her er et eksempel med og uden formattering for at vise forskellen.
Med formattering:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

//Create line kaldes hver gang der er fundet en linje der matcher vores krav
//vi får en række argumenter med ind.
//vi ved fra dokumentationen at det er argument 1 vi vil have fat i, det er 
//nemlig vores streng uden <br /> tag
function createLine(...args):String
{
  //Vores linje:
  var line:String = args[1];
  
  //vi laver et text felt:
  var tf:TextField = new TextField();
  tf.width = 500;
  tf.htmlText = line;
  addChild(tf);
  
  //lidt dummy kode der placere fetet et sted, så det ikke bare bliver placeret på 0,0
  tf.x = args[2];
  tf.y = args[2]
  
  //Vi returnere null, da retur væriden ikke er vigtig her
  return null;
}

Uden formattering:
//Create line kaldes hver gang der er fundet en linje der matcher vores krav
//vi får en række argumenter med ind.
//vi ved fra dokumentationen at det er argument 1 vi vil have fat i, det er
//nemlig vores streng uden tag
function createLine(...args):String
{
//Vores linje:
var line:String = args[1];

//vi laver et text felt:
var tf:TextField = new TextField();
tf.width = 500;
tf.htmlText = line;
addChild(tf);

//lidt dummy kode der placere fetet et sted, så det ikke bare bliver placeret på 0,0
tf.x = args[2];
tf.y = args[2]

//Vi returnere null, da retur væriden ikke er vigtig her
return null;
}

Formatteret kode er LANGT mere læsbart end uformatteret kode, og gør det lettere for dine læsere at orientere sig.

Indsæt kun den væsentlige kode

Lad være med at sætte mere kode ind end nødvendigt.
Det bliver hurtigt svært at overskue for læseren hvad større mængder kode rent faktisk gør. I hovedreglen hører meget kode sammen med en stor introduktion af problemstillingen og koden.

Hvis du blot skriver "Jeg har et problem med mit galleri" og derefter indsætter 200 linjer kode, så er det svært for læseren at overskue og gå aktivt ind i dit problem. Så igen reglen her er; skal du sætte meget kode ind, så brug tid på at forklare hvad der forgår og hvad scenariet er.
Kommenter også din kode, så man kan se hvilke elementer der i koden, hænger sammen med din beskrivelse af problemet. Kommenteret kode, gør det endnu lettere for læseren at forstå og følge flowet i dit problem.

Brug af filer

Lige som kode, er det et rigtig godt værktøj at bruge filer til at beskrive dit problem. Men præcist som med kode, kræver filer også mere beskrivelse af problemet. Fordi man tilføjer en fil, er det bestemt ikke ensbetyndende med at folk lettere kan se hvad man mener. Brug tid på at forklare problemet så det læseren kan forstå det uden at skulle kigge på filerne. Mange der læser et problem har ikke tiden til at skulle downloade en zip fil, og sætte deres Flash eller Flex op med dine ting.

Filer bør bruges som en ekstra reference til at give et eksempel på din problemstilling. Når du vedlægger filer, bør du også overveje om du kunne simplificere de filer du vedlægger. Hvis du har problemer med en preloader, behøver du ikke med sende hele dit projekt. Opret en ny .fla fil og flyt kun de elementer over, der skal til for at vise dit problem i praksis. - igen er det svært for dem der rent faktisk tager sig tiden til at hente dine filer, først at skulle til at finde rundt i din opbygning og derefter frem til den del det rent faktisk handler om.

Bed om hjælp, ikke gratis arbejdskraft

Forvent ikke at folk vil lave tingene for dig. - mange gør det gerne, fordi de har lyst. Men lad være med at forvente det.
Tag derfor stilling til, når du opretter en post, om du ønsker hjælp til at komme videre med dit problem, eller om du ønsker at andre skal lave dine ting.
Hvis du ønsker at andre skal lave dine ting, så er det helt fair. - men vær åben og ærlig omkring det, og forvent at bestilt arbejde ofte kræver betaling. Hvis du ved du vil have andre til at lave det for dig, bør du oprette din post som et jobopslag. Lad være med blot at skrive "Jeg skal lave X, er der nogen der kan hjælpe mig?". Det er ikke en god post at få hjælp til, og den minder mest om noget der burde være et jobopslag.

Et andet eksempel kunne være "jeg skal lave X, hvordan gør jeg det?". Igen en meget dårligt beskrevet problemformulering, som er svar at besvare. Dels fordi den intet fortælle om hvad det konkret er, og fordi det virker som om du ikke selv har gjort noget for selv at tilegne dig viden om emnet.
Sidst nævnte er en af de største motivations faktorer for at jeg personligt springer en post over. - jeg aner simpelthen ikke hvor jeg skal starte. Posten fortæller intet om situationen. I stedet bør posten give mere baggrund omkring hvor du er i processen og hvad du allerede ved, og ikke ved. Et eksempel :

"Jeg er i gang med at lave Y. Det skal bruges som en del af ABC og jeg vil rigtig gerne lave X for at få Y sat rigtig godt sammen med ABC. Jeg har foreløbigt gjort Z og søgt her på FlashForum.dk og fundet den her post .... men, hvordan får jeg Y og X til at virke så de kan sættes sammen med ABC?"

Konklusion

Alle kan få svar på deres posts, men ikke alle får det. Vær selv med til at gøre din del, for at gøre emnerne du opretter lettere at svare på. Hoved essensen af ovenstående er; brug den tid, det kræver at formulere et spørgsmål, så det kan forståes af andre. Nogles problemstillinger kræver mere tid end andre, med de kræver også større og mere omfattende svar fra læserne af emnet.
Alle starter et sted, så føl ikke du skal bruge svære tekniske ord når du skal beskrive dine emner. - folk skal nok forstå dig, selvom du beskriver det med "almindelige" ord... så længe du beskriver det.

Happy Posting