-
Notifications
You must be signed in to change notification settings - Fork 2
Navngivning af indhold, REDCap variabler etc.
Navngivningen er noget af det vigtigste og sværeste, når man et nyt behandlingsprogram skal laves. Det gør en kæmpe forskel for, hvor nemt eller svært det bliver senere hen at finde rundt i indholdet i et program og de tilhørende id'er, som er blevet brugt både før og efter den første test af programmet.
I vores system er det meget vigtigt at forstå forskellen på "Systemtitel" og "Overskrift". Et modul eller en modulside, som tilføjes via platformen til programmet, oprettes med begge dele. De har hver deres felt, når man opretter det, og det kan senere ændres ved at klikke "Edit" på en modulside eller et modul. Især
Systemtitlen er den titel, som vi bruger bagved selve programmet. Det er en maskinlæsbar titel, som vi f.eks. bruger, når vi er på indholdssiden og prøver at søge et specifikt modul frem. Det er også systemtitlerne vi bruger, når vi kobler moduler sammen med modulsider. Derfor er det meget vigtigt, at systemtitlen er god, deskriptiv og samtidig kortfattet, så det er nemt at søge frem igen.
Undgå at bruge modulets placering i rækkefølgen af moduler som en del af titlen! Hvad nu, hvis de senere skifter plads?
Det er vigtigt at have et system til den her navngivning. Hvis de første moduler f.eks. følger systemet [programnavn]_[modulnavn], så skal de andre moduler ikke følge systemet [modulnavn] - [programnavn] eller et tredje system. Det er samtidig rart at have et system, hvor man forsøger at undgå potentielle slåfejl. F.eks. kan man undgå blokbogstaver fuldstændigt. Eller operere med, at det kun er programnavnet, der er skrevet med blokbogstaver. Her er vi ude i en smagssag.
Det vigtigste for de her titler er, at navngivningssystemet er er konsistent! Det skal ikke skifte halvvejs.
I modsætning til systemtitler, så er overskrifter de titler, som patienter læser. Det er den udadvendte titel på et modul, som kommer frem på "Program" siden. Eller titlen på siden, som kan komme frem i navigationsmenuen. Der er frit slag her og det ændres nemt igen.
F.eks. kan det være problematisk at navngive moduler efter deres placering i en rækkefølge af moduler. Det kan illustreres med et eksempel:
Tobias har behandlingsprogrammet med navnet Mit Behandlingsprogram. Programmet har 10 moduler i alt. Derfor har Tobias valgt at navngive moduler på platformen efter systemet "Mit Behandlingsprogram - Modul 1" og derefter. Men nu er der gået 3 måneder og det viser sig efter test, at det faktisk er mere optimalt, at modul 1 bytter plads med modul 2, og at modul 3 bytter på plads med modul 4. Og så har vi problemet. For nu har modul 1 faktisk titlen og symstemtitlen modul 2 og modul 2 har faktisk titlen og systemtitlen modul 1. Det samme med modul 3 og 4. Nu begynder det at blive ekstremt svært at holde styr på, hvad der ligger hvor, fordi der er en sammensmeltning af navnet på modulet og en rækkefølge, som skal være fleksibel og uafhængig fra navnene. Og problemet bliver faktisk værre. For det samme gør sig gældende for REDCap, hvor han har brugt samme system. 3 mdr senere sidder Tobias i sin lejlighed og bruger variablen "modul_1_side_4_øvelse_3" på selve Modul 2 Side 2 Øvelse 1. Navngivningen er gået galt, og han kan ikke finde rundt i noget længere.
Derfor: Giv meget gerne moduler en deskriptiv systemtitel. "Modul 4" er ikke særlig deskriptivt. "Min fysiske energi" er til gengæld nemt at huske og har forbindelse direkte til indholdet af selve modulet. Det kan også nemt laves om til en kortfattet systemtitel som f.eks. "energi", "fysisk" eller lign. som er kortfattet, men deskriptivt alligevel.
Tobias har behandlingsprogrammet "Tobias' underlige program", som har projektnavnet "TSC". TSC har 3 moduler:
- Øl er god terapi
- Få mindre styr på dine tanker
- Jeg fryter, at internetbehandling bliver en politik spareøvelse
Tobias kan godt lide at give sine moduler meget lange titler, fordi han ikke ved bedre. De 3 moduler har derfor indenfor Tobias' eget system fået nogle kortere titler: Øl, tanker, internetbehandling.
Tobias opretter de 3 moduler på selve platformen under "Indhold" og "Add Content" og giver dem de korte titler som systemtitel og de lange som overskrift indenfor modulet. Systemtitlens navn bare skal hjælpe ham selv med at holde styr på modulet imens selve overskriften er den patienter ser.
Men Tobias har inden han har færdiggjort det første program allerede fået en million ideer til nye behandlingsprogrammer, fordi hans hoved ikke har en stopklods og det første program er ikke så lovende som han troede. Hans patienter har det ikke så godt, så han laver et nyt program for at give dem behandling for det første program. Det er jo det internettet er til for. Tobias er snedig og beslutter sig derfor for at alle modulerne, som hører til det første behandlingsprogram i systemtitlen skal have præfixet "TSC", som er det korte, interne projektnavn, som alligevel ikke er offentligt. Så det første modul i program 1 hedder nu i systemtitlen "TSC-øl". Tobias har valgt ikke at lave mellemrum på siderne af bindestregen, fordi han kender sig selv og ved, at han kommer til at glemme mellemrummene alligvel. Han opererer heller ikke med blokbogstaver i systemtitlen, fordi det kan han ikke administrere, når han laver behandlingsprogrammer, imens han er påvirket.
Det viser sig at være en god ide, fordi senere kan Tobias bare søge på "TSC" efter content type "moduler", og så ved han, at det kun er modulerne for det første program, der dukker op. Hvis Tobias ikke havde 2 programmer liggende på den samme side, så kunne han have undladet præfixet, for så giver det sig selv, at alle moduler hører til det program. Men i det her tilfælde, hvor der er flere programmer på samme underside til internetbehandling.dk giver det mening. Og uanset, så skader det ikke, at modulets navn er forbundet direkte til programmets navn-
Når Tobias laver modulsider til sine 3 moduler, så bibeholder han navnet for modulet og forlænger det bare med "-side-x", hvor x er sidetallet. Tobias vil gerne lave deskriptive systyemtitler til alle 300 sider i programmet, men det bliver simpelthen for meget arbejde, fondsmidlerne er opbrugte, alle er trætte og det kommer næsten til at gøre det sværere at finde rundt i. Så side 1 i modul 1 (TSC-øl) kommer til at hedde "TSC-øl-side-1" i systemtitlen, og så finder han senere på en bedre titel, som kan komme i "Overskrift"-feltet for siden og som er den hans patienter kommer til at læse. "TSC" er deskriptivt nok præfix til at identificere det enkelte program og "alkohol" er deskriptivt og kort nok til at man både kan kende modulet og skrive det hurtigt.
Ok, ok, men hvad gør han så for at sikre, at variablerne er navngivet fornuftigt, og at det senere er til at finde rundt i?
I forlængelse af det ovenstående eksempel er der allerede et navngivningssystem på plads på platformen og nu er det mere ligetil at lave REDCap variabler, som afspejler den form. F.eks. hvis der i det første modul "TSC-øl" på side 3 er 2 tekstfelter, så kunne selve instrumentet hedde "TSC-øl", så det er et instrument, som indeholder alle variabler for det modulet og det andet tekstfelt kunne som variabelnavn hedde "TSC-øl-side_3_felt_2". Ja, man kunne udelade programnavn og modulnavn som præfix til selve variabelnavnet. Men det er rart at have et variabelnavn, som man kan placere helt præcist alene udfra det navn! Så er man aldrig i tvivl om, hvilken variabler, der hører til hvilket element.
Ok, men der er et kæmpstort monster af et spørgeskema midt inde i et modul, og hvis jeg følger de her regler, så bliver instrumentet et monster med over 100 variabler, hvoraf skemaet udgør de 60 af dem?
I de tilfælde kan man med fordel oprette et instrument, som udelukkende er den øvelse. F.eks. et instrument, der hedder "programnavn-modulnavn-øvelsesnavn". I virkeligheden burde alle øvelser som hovedregel altid være separate instrumenter, og det ville gøre arbejdet med variabler lettere. Men det er noget vi arbejder på at lave lige nu, og det er meget komplekst. Hvad definerer en øvelse i et program? Og hvor meget kan man antage om en psykologisk øvelse? Det er noget vi arbejder på ved at lave en ny "Content type" i vores system, som kan håndtere det.