February Book Club recap: DITA Code Editing

We discussed chapter 12: DITA Code Editing of DITA Best Practices at the February 15th meeting of the PDX DITA Book Club. Attendees included DITA enthusiasts from Wacom and NetApp.

book club

Helping your team apply DITA consistently through code reviews

Code reviews are a great idea, especially when your team is first starting with DITA. Discussing different options and getting advice from your team means you will all learn faster. Josh had some great advice for teams implementing code reviews. He suggested agreeing on feedback rules before you start. It takes the focus off of what the writer is writing and places it on the rules you all want to follow.

The Common Problems lists at the end of the chapter are a great guide for people learning DITA. They can help people learn what to avoid and can be useful as a guide during code reviews. They can give you a place to start.

 

Figuring out where to start

Because that can be a real issue when teams first start with DITA. DITA gives you so many options. Which ones are right for your team?

The chapter recommends creating a DITA style guide for your team to follow, but it can be difficult to know which DITA elements you should use before you’ve even written one topic in DITA. Making some guidelines about what you’d like to use is a good idea, but your team should be very flexible in the beginning. As you write topics in DITA, the style guide should slowly create itself from what you’ve learned while actually working in it. The most important thing is to keep track of what you want to continue using and what you don’t!

September Book Club recap: Converting Content to DITA

We discussed chapter 11: Converting Content to DITA of DITA Best Practices at the September 28th meeting of the PDX DITA Book Club. Attendees included DITA enthusiasts from Jive Software, NetApp, Intel, and Viewpoint.

book club

Some of the members had converted to DITA years ago and some of the members are doing it currently. We shared stories about implementing DITA and compared them to what we had read.

What was your company’s motivation for switching to DITA?

  • Lots of available tools
  • Open source architecture
  • Content reuse

How did you convert?
Most of the members converted to DITA manually by copy/pasting from their old tool into their new DITA tool. Leona particularly remembers a huge spreadsheet logging the progress of what was converted and what wasn’t.

Did you have to publish while converting?
None of our members had the space in their schedules to devote exclusively to migration. It was a gradual process of conversion, mostly scheduled between releases, with some writers on a team continuing to use an old tool while their teammates moved onto the new DITA tool.

Did you have a team devoted to conversion?
We all had a nice chuckle at the huge pilot team suggested in this chapter. Many of the members had little to no in-house DITA expertise when converting. As Marya noted, DITA is often aimed at large teams but is adopted by small teams, too. Those small teams are doing what they can, with whatever expertise they have and whatever training they can get.

What is the most important training you need while you are converting?

  • Topic types
  • Tagging
  • Maps
  • Folder organization

What are some good ways to get that training?

  • The “automatic” training you get by using a tool that validates against a DITA DTD is a great way to learn as you are converting, by warning you when you are doing something that DITA doesn’t allow.
  • Take a hint from “mob programming” and sit down with your co-workers to write some DITA topics as a team so you can discuss strategies and learn together.

Some things to remember while converting:

  • If you have a lot of topics in a fairly flat folder organization, you’ll need a good naming convention for your topics. Try keeping the name close to the title of the topic so you can find your topics more easily.
  • Converting HTML tables to DITA is time-consuming. If you are converting a lot of reference docs, make sure you allow time for it. If anyone has come across a solution that makes this easier, please let us know in the comments!
  • Start a book club of your own! You can learn so much by reading a beginner DITA book and discussing it with others in your DITA community.

Couldn’t make it to the meeting but have something to add? Want to share a story about your DITA conversion? Tell us in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Viewpoint, 1510 SE Water Avenue
When: October 26, 2016 from 5:00 to 6:00 pm
What: Chapter 12 of DITA Best Practices
RSVP: Email canncrochet@gmail.com

August PDX DITA Book Club recap: Content Reuse

We discussed chapter 10: Content Reuse of DITA Best Practices at the August 24th meeting of the PDX DITA Book Club. Attendees included DITA enthusiasts from Jive Software, NetApp, Intel, Viewpoint, and DITA Strategies.

book club

This chapter discussed the benefits of content reuse and single-sourcing as well as covering specifics of how you can do it with DITA. Our conversation on this chapter centered on how to think strategically about content reuse and DITA.

Conref source files
Our members have a bunch of great names for the topics that house content they plan to reuse in conrefs: master reuse files, conref libraries, warehouse topics. No matter what you call them, remember to set the processing-role attribute to resource-only and keep them in a place where you can find them easily.

Keys
Amber gave us a great overview of keys. Keys do for reuse what reltables do for links by storing information outside of topics, making it easier to find and update. Just like linking behavior is stored in reltables but resolve in topics, key values are defined in maps and resolve in topics.

Advice for content reuse
Make sure you always have a good reason why you want to reuse something. The ability to reuse is not a reason to reuse. When in doubt, don’t do it.

Start talking about content reuse strategy with your team, and keep talking about it. Amber suggested setting up brown bags where you and your team rewrite a topic together, talking about what to reuse and what not to. Josh has regular topic reviews with his team. I’m looking forward to scheduling something like it with my team soon.

Couldn’t make it to the meeting but have something to add? How does your team reuse content? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: TBD
When: September 28, 2016 from 5:00 to 6:00 pm
What: Chapter 11 of DITA Best Practices
RSVP: Email canncrochet@gmail.com

Large-team DITA vs. Small-team DITA: A Friendly Face-Off

After the monthly PDX DITA Book Club meeting on June 23rd, DITA enthusiasts met for the quarterly meeting to discuss using DITA in small teams versus in large teams.

small vs large

Everyone took a turn talking about the benefits and challenges of their DITA teams. Most of our attendees work on small teams, but we still had great insights about life with large teams, too.

Let the friendly face-off begin!

Small-team DITA

  • Small teams are nimble and flexible and can respond to new information very quickly. Although there are less people to manage some important aspects of DITA, like content strategy, members of a small team get the opportunity to try a little of everything.
  • Small teams also get the chance to be problem solvers on a regular basis. On the other hand, if there is a problem, you are the one who needs to solve it. If you are on a small team (or a team of one), you may not have anyone to turn to with questions or for advice.
  • Small teams may not need a CMS…yet. Also, it might be more difficult for small teams to get resources, like a CMS. Kate’s team chose their company’s new flagship product for their first DITA project, to take advantage of the excitement around the new product to gain their company’s support for DITA.

Large-team DITA

  • Large teams often have enough people that different aspects of working with DITA can be delegated to different people. This may mean less diversity in the work that a member of large team performs.
  • Big teams need structure and policies, and they have enough people to provide that structure and make those policy decisions, such as which DITA elements to use and how to use them. But, with, large teams, these kind of decisions tend to be made at a slower pace.
  • It can be easier to onboard new writers in a large team because there are usually protocols already in place. In fact, Josh’s team has a help system just for their writers.

One of our members is finding out that, if your team grows because of acquisitions, you might find yourself with a large team made of a bunch of small teams. There might be a sweet spot for a DITA team, when your team is still small enough to be flexible and large enough to have considered DITA policies in place. What do you like best about being on a DITA team? Tell us in the comments!

June PDX DITA Book Club recap: Metadata and Conditional Processing

We discussed chapter 8: Metadata and chapter 9: Conditional Processing of DITA Best Practices at the June 22nd meeting of the PDX DITA Book Club. Attendees included a new member from Viewpoint and DITA enthusiasts from Jive Software, NetApp, and Daimler.

book club

These two chapters were a perfect pair to discuss together. Our group members had great tips for using metadata and conditional processing and plenty of examples of how they use them day-to-day.

  • If you have a long topic, instead of putting all of your <indexterm> elements in the <prolog>, you can put them nearer to the information that the index entry is describing to make that information easier to find.
  • Set the translate attribute to “no” for items that shouldn’t be translated or that will cause issues with translation services. Our members have used this for superscripts, part numbers, and button UI text that shouldn’t be translated.
  • Stan Rhodes made a great point about publication dates and the <prolog> element. It’s possible that the publication dates you use internally for a topic are not the same as the dates you want to use in your published topic. Consider whether the publication date you use in the <prolog> element is the one you want associated with your published topic.
  • Even though you can add conditional processing attributes to rel tables and inside topics, most of the group members preferred to add them to the <topicref>, if possible. It’s easier to find them and keep track of them that way.
  • We discussed whether or not any members dealt with condition sprawl, a term coined by the book writers to describe when a team has multiple conditions for the same purpose. We all agreed that condition sprawl would probably be more of a problem in large teams than in small teams, which was the perfect segue to PDX DITA quarterly meeting that followed!

Couldn’t make it to the meeting but have something to add? How does your team use metadata? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: August 24, 2016 from 5:00 to 6:00 pm
What: Chapter 10 of DITA Best Practices
RSVP: Email docs@jivesoftware.com

May PDX DITA Book Club recap: Short Descriptions

We discussed Chapter 5: Short Descriptions of DITA Best Practices at the May 18th meeting of the PDX DITA Book Club. Attendees included DITA enthusiasts from Jive Software, NetApp, Daimler, and PSU’s Technical Writing program.

book club

Personally, my favorite thing about short descriptions is the way they show up in mini-TOCs. I love being able to easily view a summary of the information in a set of topics. It helps me organize my information, and it helps readers know what to expect, too.

While it seems like there isn’t much we could add to the illuminating and in-depth presentation and blog post that Marya DeVoto did on short descriptions, here are some highlights from the meeting!

  • A helpful short description could make it so that an advanced user wouldn’t even have to read the topic.
  • To a similar point, sometimes the short description IS the whole topic, and that’s okay.
  • Short descriptions should be readable on their own. Avoid introducing lists in a short description, and refer to other topics by name instead of by “previous topic” or “next topic.”
  • Being consistent in applying short descriptions helps search results.

Some great final advice from Marya–if your topics are well-structured, your short descriptions should be easy to write. If you are having difficulty writing it, take a second look at your topic and make sure it contains only one point or task.

Couldn’t make it to the meeting but have something to add? What’s your favorite thing about short descriptions? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: June 22, 2016 from 5:00 to 6:00 pm
What: Chapter 8 and 9 of DITA Best Practices
RSVP: Email docs@jivesoftware.com

April PDX DITA Book Club meeting recap: Linking

We discussed Chapter 7: Linking of DITA Best Practices at the April 20th meeting of the PDX DITA Book Club. Attendees included DITA enthusiasts from Jive Software, ADP, Daimler, and PSU’s Technical Writing program.

Here are the highlights!

book club

Inline links
We discussed how behavior influences inline links. Readers today are accustomed to inline links because of sites that use them heavily, like Wikipedia. Since readers have become somewhat immune to them, they are neither particularly disruptive nor do they appear that much more important than the surrounding text.

Still, we agreed that it is best to be selective when using inline links and to take advantage of the automatic ways you can create links with DITA, such as the sequence collection type. Toni’s team even implemented an “avoid inline links” policy.

Rel tables
Some of us use them; some of us don’t; and a few of us would like to try.
Advice for starting small with rel tables: They can be added to sub-ditamaps, as long as that sub-ditamap is above all of the links in your rel table. Putting rel tables at the sub-ditamap level also keeps them portable.

Collection types
The collection type we all thought would be the most useful (and some of us take advantage of) is sequence, especially for very long processes and wizards.

Scope attribute
The scope attribute on a link tells your .xslt where to look for the link. The peer attribute is useful when the topic you are linking to is not currently published, so the link will not break your build.

Couldn’t make it to the meeting but have something to add? Do you want to tell about your linking strategy or expound your love of rel tables (looking at you, Josh!)? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: May 18, 2016 from 5:00 to 6:00 pm
What: Chapter 5 of DITA Best Practices
RSVP: Email docs@jivesoftware.com

March PDX DITA Book Club meeting recap: DITA Maps and Navigation

We discussed Chapter 6: DITA Maps and Navigation of DITA Best Practices at the March 16th meeting of the PDX DITA Book Club. The book club members provided great insight. Members included DITA enthusiasts from Jive Software, Netapp, Harmonic, and ADP.

Here are the highlights!

book club

We started by talking about information modeling:

  • Marya tried to install the IBM Information Architecture Workbench software discussed in the chapter, but it wasn’t compatible with her 64-bit computer. No one at the meeting had experience with it. Have you ever used it? Let us know what you think in the comments!
  • When first starting a large project, Josh used a digital sticky-note tool to organize information, and Marya and Leona used actual sticky notes when reorganizing their doc sets a few years ago.
  • We all agreed that it is difficult to figure out how to use modeling tools when you inherit docs or are in the middle of a project. For a team starting out fresh, information modeling seems crucial, whether you use software or sticky notes (or sticky-note software).

We were introduced to new tags and elements by our fellow book club members:

  • Josh introduced us to the “resource-only” tag. You can tag a topicref as “resource-only” when you want to refer to a topic from another ditamap but don’t want the topic pulled into your current ditamap.
  • Toni introduced us to the <topichead> element. If you want a heading in your TOC but don’t want to create a topic just to get it in there, you can add a <topichead> to a ditamap. This reduces the need for one-sentence summary topics created only to get a heading into your TOC. However, <topichead> does not generate a landing page with mini-TOC grabbed from topic titles and short descriptions, so you’ll need to weigh your need for a mini-TOC against your need for a topic-less heading.

We discussed ditamap ownership:

  • Whether or not a team has someone responsible for creating the structure of its ditamaps depends largely on the size of the team.
  • A small team can spread ditamap ownership over the whole team, allowing all team members to get involved. This is a joy to some on small teams, and it is also a necessity.
  • A large team needs ditamap owners for consistency across the team.
  • Josh’s team has Book Captains who are responsible for the published book at the end of a project and for the ditamap structure at the beginning of it.

1375216042000-MacLeodCover-1307301628_3_4

We considered good use cases for submaps:

  • Submaps make reusing maps easy. Content reuse at its best!
  • We also really like the mini-TOCs that are automatically created when using submaps.
  • Kate creates ditamap templates for her teammates, complete with recommended submaps, for consistency across her team.

We figured out who uses bookmaps (and who doesn’t):

  • This chapter of the book advocated creating a bookmap for PDF output and a ditamap for other outputs. Since bookmaps can handle other outputs than PDF, and since ditamaps can handle PDF output, the group didn’t think it was necessary.
  • Tech writers for hardware docs tend to use bookmaps, because their readers rely on PDF output and may be in a place where there isn’t internet or a computer nearby.
  • Tech writers for software docs tend to stick with ditamaps, but most of the software tech writers present still made PDFs available from their ditamaps.

Couldn’t make it to the meeting but have something to add? Do you want to weigh in on bookmaps and submaps? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: April 20, 2016 from 5:00 to 6:00 pm
What: Chapter 7 of DITA Best Practices
RSVP: Email docs@jivesoftware.com

February PDX DITA Book Club meeting recap: Concept Topics and Reference Topics

We had a larger group for our second installation of the PDX DITA Book Club on February 17th, including a student from the Masters of Science in Technical Writing program at Portland State University and DITA enthusiasts from Jive Software, Netapp, and Harmonic. We discussed chapters 3 and 4 of DITA Best Practices at this meeting.

Here are the highlights!

book club

Chapter 3 reviewed concept topics and inspired conversations about what kind of topics we use the most (and what kind of topics we think we should use more):

  • We discussed using concept topics for information for beginners and targeting tasks to users with more experience. Beginners can be referred to concept topics for more information.
  • This led to one of the most interesting discussions from the evening, regarding how we refer those beginners to the concept topics that could help them. Even though it isn’t best practice, some of us admitted to adding cross-reference links directly in task steps or concept paragraphs, while some are big proponents of using <related-links>.
  • We discussed <sl>, <dl>, <ol>, and <term>, and the best uses for each. Most of us don’t tend to use <ol> but could see how it might be useful for workflows and rankings. We shared examples of when we used a <dl> instead of a <table> and why we decided on one over the other.

Chapter 4 reviewed reference topics (facts without explanations!):

  • We all use reference topics in different amounts, depending on our documentation needs. Some find references very useful for documenting UI, and others find less need for them.
  • We also discussed <properties> tables and <syntaxdiagram>.

Couldn’t make it to the meeting but have something to add? Do you want to weigh in on linking directly in steps or paragraphs versus using <related-links>? Discuss in the comments!

More people are coming to every meeting! You should join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: March 16, 2016 from 5:00 to 6:00 pm
What: Chapter 6 of DITA Best Practices
RSVP: Email docs@jivesoftware.com

January PDX DITA Book Club meeting recap: Topic-Based Writing in DITA and Task Topics

The PDX DITA Book Club is off to a great start! Five DITA enthusiasts from companies such as Jive Software and Netapp met for the first time on January 20th and discussed the first two chapters of DITA Best Practices.

We even grabbed a laptop and tested out a tag or two. Here are the highlights!

book club

The first two chapters touched on tags, specifically task tags, which inspired conversation about how we use certain tags:

  • Info tag: There’s so much to say about the info tag! The biggest takeaway, though, is that it’s not cheating to wrap an info tag around a note tag to get a note to appear in a step.
  • Context vs. stepsection: Most of us use the context tag regularly but haven’t explored stepsection as much. We thought that it could be very useful to split up a long topic.
  • Importance attribute: We checked out the different values that you can apply to the importance attribute. Optional! Default! Deprecated! So many choices!

We also had some interesting discussions about how DITA influences the way we work:

  • Topic titles: The book counseled to make your titles meaningful, and we talked about how we do that every day. Basically, think, but don’t overthink. Be consistent when it makes sense to be, but be clear first.
  • Task analysis: Some of us had done task analyses at the beginning of large projects but, in general, couldn’t find a place for them in the daily workflow.
  • Task, concept, reference: We commiserated about starting to write a topic and changing the type halfway through.
  • Topic-based authoring: The book had a concise section on minimalist writing. We all strive for this all the time, so it was fascinating to take a step back and talk about it with fellow writers. We agreed that a single task should generally have 10 steps or less. It is better to split up a long process into multiple task topics that are tied together by a supertask parent topic than to overwhelm your reader with a long topic.

Couldn’t make it to the meeting but have something to add? Do you use the stepsection tag or the importance attribute? Do you do task analysis as part of your daily writing process? Discuss in the comments!

Even if you missed the first one, join us for the next PDX DITA Book Club meeting:
Where: Jive Software, 915 SW Stark Street, Portland, OR
When: February 17, 2016 from 5:00 to 6:00 pm
What: Chapters 3 and 4 of DITA Best Practices
RSVP: Email docs@jivesoftware.com