BMC Communities Banner

- By Michele Marques, Lead Information Developer, ITSM

 

Some of you technical communicators have been working for years in XML and DITA. However, until recently, I wrote all of my product documentation in Adobe FrameMaker. Sure, you can write XML documents in FrameMaker. But I had been using "unstructured" mode, which doesn't enforce structure.

 

I just wrote a doc for an upcoming release using an XML editor and the DITA DTD. I was nervous starting out - after all, I've been using the same tools for years, and XML involves a new paradigm. But I also knew that this was a great time for me to move ahead in the new direction. I was about to reorganize the manual that I was working on.

 

Some things are easier in an XML authoring environment

Have you ever tried to reorganize a manual? Cutting and pasting between chapters isn't pretty - especially if you end up changing the hierarchy.

 

In XML, all my topics were separate files. All I had to do was edit (or create)  component and book maps. DITA uses component maps and book maps to determine the sequence and hierarchy of topics. Did I mention sequence and hierarchy? Each of the topics is a separate object in the component map; I can move the object up, down, left, and right. Within the topic, I have a title, and maybe one or more headings. The headings are relative to the topic title. But the overall hierarchy (which titles are chapter titles, which are heading1, which are heading2, and so on) is determined by the topic's placement in the hierarchy.

 

Actually, the titles aren't really chapter titles, heading1, and heading2 - that's a relic of paragraph styles from unstructured FrameMaker or Microsoft Word. Transforms give the visual appearance in the output (such as a PDF) that mark chapter titles and help readers differentiate between heading levels in the hierarchy.

 

But, enough of the technical digression. The point is that it was really easy to reorganize this material in the XML authoring environment!  If I had still been working in unstructured FrameMaker, I would be cutting and pasting.... and changing paragraph styles for the headings. And, somewhere along the line, I'd probably make a mistake or two, and maybe lose track of where I was in the hierarchy.

 

What about the pain?

OK, I didn't move into a fairytale when I started writing in XML. I'm new to this environment, so I'm still coming up to speed. As I learn the new tags and the new processes, I'm getting faster.

 

The most frustrating part was editing my index. I'm used to FrameMaker, where I have a tool (IXGEN) that will pull all of my index entries into one editable table - even sort them alphabetically. Then, I edit the entries in one place, and can push the changes back out to my FrameMaker files. And without this tool, I was able to generate an index, click with a special key combination on the index entry, and get to my index marker.

 

In the XML authoring environment, I can only see the generated index in my output (in this case, a PDF). I can see index entries as plain text within the XML topic files, but most of my index editing happens when I see the entire index together and realize that I need to modify some terms to be more consistent with others.

 

If any of you know about great tools for developing and editing index entries in XML topics, please let me know!

 

Was it worth the pain?

Yes! There are lots of benefits of working in small topic files. It's easier to reorganize material. And it's easier to divide parts of the document between writers. I'm looking forward to the next steps, when more people join me in this environment, and we can start sharing content.

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.

| More
0 Comments Permalink
- By Michele Marques, Lead Information Developer, ITSM

I still use pen and paper to take notes during meetings. But now I can use my low-tech preference to meet hi-tech needs.

 

Often, when I look at news how technology might affect writing, I envision myself sitting at a computer, using some new software that lets me use XML tags to mark up my content, or that uses Web 2.0 to interact with my readers.

 

But today, I am sitting on my sofa, writing this blog entry, not on my laptop, but with pen on a piece of paper. It looks and feels like old technology, but really it's new. The pad of paper is clipped into a special board (actually, a computer, although it barely resembles one), and the pen - although it does write with ink - is sending signals to the board. The board captures what I write (or draw). After, I will upload this entry to a more traditional computer, and run the tools I typically think of as hi-tech to complete the publication process.

 

How else can low-tech be harnessed to meet our hi-tech needs? Do you have a favorite low-tech tool that you wish could meet your hi-tech needs?

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink
- By Michele Marques, Lead Information Developer, ITSM

Sometimes in the rush to learn new skills, we forget old skills.

Recently, I read on Mark Cuban's blog how he realized that he's forgotten how to write. He's been taking notes electronically and become proficient at it - then when he was stuck in a meeting trying to take pen to paper, he realized that his skills had degraded.

 

I don't think I'll forget how to put pen to paper. After a brief experiment with electronic note-taking, I returned to hand-written notes. His post makes me wonder, however, whether there are other skills I've forgotten, and whether they'll prove useful again. For example, when I first started using a computer to write, I had to insert all sorts of mark-up tags in the middle of my writing. There was no WYSIWIG capability on terminals, and my PC didn't even have a graphics card.

 

Now, of course, I can write and mark my text as bold or italic with the click of a button, and see the effects of my mark-up. Will I ever need to see tags as plain text again? It could be a useful skill to relearn for working with XML. What do you think?

 

Have you ever forgotten a skill and wanted to use it again?

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink
- By Michele Marques, Lead Information Developer, ITSM

Does anyone outside of information developers care what technology we're using?

When I'm writing a guide, white paper, or even a blog entry, does anyone care what technology I'm using? To a certain point, it's the content that matters, and not how it got there. But technology can affect how that information is presented. It's not just whether you're reading my content in a PDF, HTML pages, or a help system. For example, the right graphic tools can make it easier to create certain types of illustrations (such as flow diagrams) or to annotate my illustrations.

 

It can also make a difference to all the people who work with me in producing documentation. Although I might be the person doing the writing, there are many people who play a role: product managers requesting new documents, subject matter experts (developers and others) providing information and reviewing documents, editors, and translators.

 

At times I've had discussions with subject matter experts on whether I use Microsoft Word or Adobe FrameMaker to create documents. Experts who like to write want to be able to enter their changes directly to the document - and they all have Microsoft Word. FrameMaker, however, is often the tool of choice for technical writers.

 

Do writers still have these discussions when they create HTML or XML documents? After all, developers often have tools fo editing HTML and XML documents. And tools shouldn't matter as much if we don't use proprietary file formats.

 

And what about moving to a content management system? That can change workflows for everyone who touches the document.

 

If you're not an information developer or technical writer, do you care what tool I'm using?

 

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
| More
0 Comments Permalink