---
title: "DITA’s output does not require separation of tasks from concepts"
date: 2014-01-05
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2014/01/05/ditas-output-does-not-require-separation-of-tasks-from-concepts/
---
# DITA’s output does not require separation of tasks from concepts
## Tasks versus concepts

Pretty much any tutorial you read about DITA starts off by defining DITA's three main topic types: concept, task, and reference. When you author DITA content, these topic types impose certain limitations about tags that are and aren't allowed.

With concepts, you cannot include the `steps` tags (used extensively with tasks). With tasks, you cannot include the `section `tag. Although you can include brief conceptual content in a task in the `shortdesc`, `context`, and `prereq` tags, the bulk of the conceptual material is shifted into a concept file.

This separation of tasks from concepts in the *building blocks* of DITA is fine, because your dita files aren't the same as your output files. In your ditamap file, which defines how each of these components is arranged in the output, you can combine concepts and tasks to your heart's content.

For example, here's a ditamap file that combines five subtasks into one article:

The `chunk="to-content"` attribute says to combine the children with the parent. The parent is denoted by the lack of a closing `/>`. All contained topicrefs are thus included as children to this topicref, until the closing ``.

In the output, users will see just one file: "Managing Contests." This file probably includes some conceptual information about contests followed by 5 tasks: Create a Contest, End a Contest, Find Contest Winners, Export Contest Winners, and Archive a Contest.

Sure, my source files have 6 different DITA files, but the output is just one article.

One reason so many people mistake the architecture of the source files with the architecture of the output files is because the term "topic" tends to get used for both situations. I prefer to call the output files "articles" rather than topics. An article might consist of several topics. Each of those topics might be of several different types: concept, task, or reference.

If DITA tutorials were a bit more explicit in differentiating between source file architecture and output architecture, we wouldn't end up with so much confusion. There would be fewer DITA-authored help files that fragment information into lots of tiny files, and the user experience would improve.

## Reasons to combine concepts and tasks in the output

One might ask, why *not* separate concepts from tasks? After all, isn't a minimalist design philosophy task-oriented, so help should mainly consist of standalone tasks? We want to get all the conceptual information out of the way so users can do the task they need, right?

In some cases, it may make sense to separate out tasks into their own articles. In other cases it might not. It all depends on the material. If it seems like the material belongs in the same article, like the example I described above, where the tasks are pretty short, then combine them. If not, if the tasks are longer and more elaborate, separate them into their own articles.

![Sometimes concepts and tasks belong together. If that's the case, combine them in the ditamap.](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/concept_and_task.png)

When you start separating some information into one article simply because it consists of conceptual paragraphs, and you put other information into another article because it's a list of steps, even though both the concept and steps go together like a pair of shoes, you end up fragmenting the help information. You force users to jump around from article to article, trying to find all the information necessary to achieve their goal. Mark Baker calls this fragmented output a [frankenbook](http://everypageispageone.com/2012/02/24/frankenbooks-must-die-a-rant/).

DITA isn't built on any kind of learning theory propounding that separating tasks from concepts in the output improves the user experience. Certainly many users are task-oriented because they're trying to perform a goal, no question. But performing that goal often requires more than starting at step one. Often the conceptual information is the information the user needs to complete a goal. More complicated processes are not often reduced to a list of steps. 

In other words, an action-oriented approach doesn't mean you marginalize conceptual information, splitting it off from tasks.