Skriftlig Info ➜ DITA-publisering ➜ DITA topics ➜ DITA Task topic
Her er en den "offisielle" beskrivelsen fra Oasis (oversatt av meg):
DITAs "strict task" dokumenttype støtter utviklingen av instruksjoner for fullføring av en prosedyre. [...] Oppgaver er de essensielle byggesteinene for å gi prosedyreinformasjon. En "strict task" dokumenttype svarer på "Hvordan gjør jeg det?"-spørsmål ved å gi nøyaktige trinnvise instruksjoner som beskriver kravene som må oppfylles, handlingene som må utføres og rekkefølgen handlingene må utføres i. <task>-emnet inkluderer seksjoner for å beskrive kontekst, forutsetninger, forventede resultater og andre aspekter ved en oppgave.
Oasis: Task topic (strict task), [REF]
Jeg velger å definere en task topic slik:
En DITA Task topic er en frittstående datamodul som inneholder multimodal tekst. Modulen har en tittel og nok informasjon til å forklare en spesifikk prosedyre. En task topic skal kun forklare en oppgave, og den skal forklares på en lettfattelig måte med fast struktur. Hver handling skal forklares i imperativ med nummererte trinn. Hvert trinn i prosedyren skal bare inneholde en handling og vises i den rekkefølge de skal utføres.
TipsUnder "DITA-elementer" kan du finne en mer detaljert beskrivelse av de elementene som brukes i en task topic. |
Task topics er de viktigste emnene i en publikasjon. De forklarer hvordan leseres skal gjøre noe. Viktigheten av task topics i DITA er basert på prinsippet om oppgaveorientert skriving. Det prinsippet er basert på følgende påstander:
Innholdet i task topic skal forfattes etter følgende prinsipper:
Normal praksis er at en prosedyre ikke skal inneholde flere enn maksimalt ni trinn. Hvis du får flere trinn enn dette bør du vurdere å slå sammen trinn, etablere underliggende trinn (<substeps>) eller dele prosedyren i to eller flere separate task topics.
Det er viktig at vi i våre brukermanualer fokuserer på det produktet skal gjøre, det vil si de oppgavene brukeren vil at det skal utføre. Vi må derfor alltid fokusere på prosedyrer. |
TipsI teknisk dokumentasjon brukes uttrykket oppgaveorientert skriving (engelsk: task-oriented writing) om en metodikk hvor informasjonen i størst mulig grad organiseres som prosedyrer. Disse beskriver hvordan et produkt skal brukes. Metodikken baserer seg på en erkjennelse om at leseren primært er interessert i å vite hvordan oppgaver utføres, og kun sekundært interessert i å vite hvordan noe virker. De fleste produkter du handler skal du bruke til noe konkret. Dette gjelder alt fra forbruksvarer som lyspærer og toalettpapir til teknisk avanserte produkter som mobiltelefoner og privatbiler. Stikkordet er likevel bruke, ethvert produkt skal utføre en eller flere oppgaver for deg. I bruksanvisningen må hver oppgave forklares med en eller flere prosedyrer. |
For ordens skyld vil jeg nevne at DITA-standarden beskriver to forskjellige task topics; "General" og "Strict". Som det fremgår av navnene er den ene litt "strengere" enn den andre. Den største forskjellen er at "General" task topic tillater deg å sette inn ekstra <section>-elementer.
En DITA task topic er strukturert som følger.
<title>
Alle task topics skal ha en tittel.
<shortdesc>
Alle task topics må ha en "short description" som definerer kontekst.
<prolog>
Dette elementet kan brukes for å legge inn indeks-informasjon. Indeks-informasjon kan forøvrig også legges inn andre steder i topic'en.
<taskbody>
Dette elementet brukes for å samle all informasjonen i topic'en. Se <taskbody>.
Av disse elementene er det bare <title> og <taskbody> som er obligatoriske.
<prereq>
Dette er et valgfritt <section>-element som brukes for å beskrive hva brukeren trenger å vite, eller trenger å ha, før oppgaven kan starte. På engelsk kalles dette prerequisites.
Dette elementet skal ikke inneholde noe leseren skal gjøre!
<context>
Dette er et valgfritt <section>-element som brukes til å formidle bakgrunnsinformasjon. Denne informasjonen skal hjelpe leseren til å forstå formålet med oppgaven og hva som oppnås når den utføres riktig. Informasjonen i <context>-elementet skal ikke erstatte konseptuell informasjon. Hvis du har informasjon som du mener leseren kan ha nytte av kan du ta med kortfattet informasjon om dette. Hvis oppgaveforståelsen krever omfattende konseptuell informasjon skal det henvises til en concept topic.
<steps>
Dette elementet gir en numerisk liste over de oppgavene som skal gjøres. Se <steps>.
<result>
Dette valgfrie <section>-elementet brukes for å beskrive eventuelle resultater etter at oppgaven er utført.
<example>
Dette valgfrie <section>-elementet brukes for å beskrive et eventuelt eksempel.
<postreq>
Dette valgfrie <section>-elementet brukes for å beskrive hva leseren eventuelt må gjøre etter at oppgaven er utført.
Av disse elementene er det bare <steps> som er obligatorisk.
De elementene som er bygget opp av <section>-elementer kan inneholde vanlig multimodal tekst, og de aller fleste standard DITA-taggene kan brukes.
<steps>-elementet har en helt spesiell oppbygning. Det kan inneholde ett eller flere <step>-elementer. Hvert av disse inneholdet ett <cmd>-element. Etter <cmd> kan du bruke flere elementer for å utdype den handlingen som skal utføres, presentere konseptuell informasjon, eller forklare eventuelle resultater av handlingen.
<step>
Dette obligatoriske elementet skal inneholde en handling. Se <step>.
<steps>-elementet kan inneholde mange <step>-elementer. Hvert <step>-element kan bruke de elementene som listes opp her.
<cmd>
Dette obligatoriske elementet skal inneholde den handlingen som leseren skal utføre. Setningen i <cmd>-elementet skal skrives i imperativ (bydende) form med verbet først.
<info>
Dette valgfrie elementet kan brukes for å legge inn multimodal informasjon. Elementet skal ikke inneholde noe leseren skal gjøre.
<stepresult>
Dette valgfrie elementet kan brukes for å legge inn multimodal informasjon. Elementet skal inneholde tekst som beskriver resultatet av det som ble utført i <cmd>-elementet. Elementet skal ikke inneholde noe leseren skal gjøre.
<substeps>
Dette valgfrie elementet kan brukes for å legge inn underordnede step. <substeps> kan inneholde et gitt antall <substep>-elementer. Hvert av disse inneholder ett obligatorisk <cmd>-elementet samt eventuelle <info> og <stepresult> elementer. <substep>-elementet kan ikke inneholde underliggende <substeps>.
<step>-elementet kan også inneholde andre underliggende elementer, men de er ikke så mye brukt.
Husk at en velskrevet prosedyre bruker bare en setning i hvert <cmd>-element. Denne setningen forklarer hva som skal gjøres i imperativ. All annen informasjon knyttet til hvert <step> skal plasseres i de underliggende elementene. |
<step><cmd>Skru på bryteren.</cmd>
<stepresult>
<p>Lampen tennes og lyser grønt hvis alt er i orden.</p>
</stepresult>
</step>
Lage en ny DITA topic fra en mal
Lage en ny DITA topic ved å duplisere en eksisterende topic
Sette en topic inn i en topic map
Sette en topic inn i en bookmap
Alle eksterne linker åpner i et nytt vindu. Jeg tar ikke ansvar for informasjon på eksterne nettsteder, selv om jeg har linket til dem. Vennligst rapporter linker som ikke virker.
Informasjonen på denne siden representerer mine personlige meninger, og min egen forståelse av temaet som beskrives. Du kan gjerne linke til siden, men ikke kopiere større deler av innholdet uten tillatelse. Jeg tar ingen ansvar for eventuelle feil, misforståelser eller manglende informasjon om omfattende temaer. Jeg tar heller intet ansvar for feil du måtte gjøre eller forårsake som et resultat av feilaktig eller manglende informasjon. Du kan gjerne bidra med kommentarer, egner erfaringer eller utfyllende informasjon. Se Kontaktinformasjonen.