Site FeedPalimpsest has moved. Please visit our blog in its new location for the most recent posts from Scriptorium.
Palimpsest
Let the conversation begin
Wednesday, August 05, 2009 — posted by Sarah O'Keefe
Conversation and Community: The Social Web for Documentation (XML Press, ISBN: 9780982219119) by Anne Gentle provides technical communicators with a roadmap for integrating social media -- blogs, wikis, and much more -- into their content development efforts. This is critical because, as Anne notes in the preface, "professional writers now have the tools to collaborate with their audience easily for the first time in history."Anne provides overviews of all the major social media concepts -- from aggregation to syndication, wikis, discussion, presence, and much more. But it is Chapter 3, "Defining a Writer's Role with the Social Web," that will make this book a classic. Here, Anne lays out a detailed strategy for determining whether and how to introduce social media in an organization. Consider this:
It's important to find a balance between allowing an individual's authentic voice to speak on behalf of an organization and the requirements of institutional messaging and brand preservation. [...] It's also possible that you are ahead of the curve and need to help others see ways to apply social technologies for the company.
She goes on to explain just how to accomplish these things.
Wikis and blogs each get a chapter of their own, in which Anne discusses how to start and maintain these types of environments.
After reading so much of Anne's work on her blog, it's a bit odd to see her writing on paper in an actual book. The feeling that I've wandered into the wrong medium is augmented by extensive footnotes, most of which point to web site resources, and the many examples of web-based content (such as videos or interactive mashups). However, it's likely that the book's target audience is more comfortable with paper.
Conversation and Community: The Social Web for Documentation provides an excellent introduction to wikis, blogs, forums, and numerous other social media technologies for the professional content creator. There is valuable (and perhaps career-preserving) information about how to develop a strategy for user-generated content that is compatible with your organization's corporate culture.
If you think that community participation in your documentation is coming soon, read this book immediately. If you think that it's not coming, you're wrong, and you especially need to read this book.
Sample chapter (PDF)
[Disclosure: I reviewed an early draft of this book. I have met Anne in person a few times and we have ongoing email and blog correspondence.]
Labels: book, reviews, web 2.0
10:19 AM Permalink | |
Flare 5 DITA feature review, part 2
Wednesday, June 17, 2009 — posted by Sarah O'Keefe
[Alan Pringle wrote most of this review.]This post is Part 2 of our Flare 5 DITA feature review. Part 1 provides an overview and discusses localization and map files.
Cross-references and other links
I imported DITA content that contained three xref elements (I shortened the IDs below for readability):
- Reference to another step in the same topic:
<stepresult>
Result of step. And here's a reference to the <xref href="task1.xml#task_8F2F9" type="li" format="dita" scope="local">third step</xref>.
</stepresult>
- Reference to another topic:
<stepresult>
Result text. And here's a link to the other task topic:
<xref href="task2.xml#task_8F2F94 type="task" format="dita" scope="local"></xref>.
</stepresult>
- Link to web site:
<cmd>
Here's another step. Here's a link with external scope:
<xref href="http://www.scriptorium.com" scope="external" format="html">www.scriptorium.com</xref>
</cmd>
All three came across in the WebHelp I generated from Flare:
On the link to the topic, Flare applied a default cross-reference format that included the word "See" and the quotation marks around the topic's name. You can modify the stylesheet for the Flare project to change that text and styling.
Relationship tables
DITA relationship tables let you avoid the drudgery of manually inserting (and managing!) related topic links. Based on the relationships you specify in the table, related topic links are generated in your output.
I imported a simple map file with a relationship table into Flare and created WebHelp. The output included the links to the related topics. I then tinkered with the project's stylesheet and its language skin for English to change the default appearance and text of the heading for related concepts. The sentence-style capitalization and red text for "Related concepts" in the following screen shot reflect my modifications:
conrefs
DITA conrefs let you reuse chunks of content. I created a simple conref for a note and then imported the map file with one DITA file that contains the actual note and a second file that references the note via a conref.
Flare happily imported the information and turned the conref into a Flare snippet. It's worth noting that the referencing, while equivalent, is not the same. In my source DITA files, I had this:
aardvark.xml contains:
<note id="">Do not feed the animals
baboon.xml contains:
<note conref="aardvark.xml#aardvark/nofeeding">
Thus, we have two instances of the content in the DITA files -- the original content and the content reference. In Flare, we end up with three instances -- the snippet and two references to the snippet. In other words, Flare separates out the content being reused into a snippet and then references the snippet. This isn't necessarily a bad thing, but it's worth noting.
Specialization
Specialized content is not officially supported at this point. According to MadCap, it worked for some people in testing, but not for others. If you need to publish specialized DITA content through Flare, you might consider generalizing back to standard DITA first.
Conditional processing
When you import DITA content that contains attribute values, Flare creates condition tags based on those values. I imported a map file with a topic that used the audience attribute: one paragraph had that attribute set to user, and another had the attribute set to admin. When I looked in the Project Organizer at the conditions for the WebHelp target, conditions based on my audience values were listed:
I set Audience.admin to Exclude and Audience.user to Include, and then I created WebHelp. As expected, the output included the user-level paragraph and excluded the admin-level one.DITA support level
Flare supports DITA v1.1.
Our verdict
If you're looking for a path to browser-based help for your DITA content, you should consider the new version of Flare. Without a lot of effort, we were able to create WebHelp from imported DITA content. Flare handled DITA constructs (such as conrefs and relationship tables) without any problems in our testing. Our only quibble was with the TOC entries in the WebHelp (as mentioned in Part 1), and we've heard that MadCap will likely be addressing that issue in the future.
We didn't evaluate how Flare handles DITA-to-PDF conversion. However, if the PDF process in Flare works as smoothly as the one for WebHelp, Flare could provide a compelling alternative to modifying the XSL-FO templates that come with the Open Toolkit or adopting one of the commercial FO solutions for rendering PDF output.
2:00 PM Permalink | |
Flare 5 DITA feature review (Part 1: Overview and map files)
Friday, June 12, 2009 — posted by Sarah O'Keefe
[Disclosure: Scriptorium is a Certified Flare Instructor.][Full disclosure: We're also an Adobe Authorized Training Center, a JustSystems Services Partner, a founding member of TechComm Alliance, a North Carolina corporation, and a woman-owned business. Dog people outnumber cat people in our office. Can I start my post now?]
These days, most of our work uses XML and/or DITA as foundational technologies. As a result, our interest in help authoring tools such as Flare and RoboHelp has been muted. However, with the release of Flare 5, MadCap has added support for DITA. This review looks at the DITA features in the new product. (If you're looking for a discussion of all the new features, I suggest you wander over to Paul Pehrson's review. You might also read the official MadCap press release.)
The initial coverage reminds me a bit of this:
(My web site stats prove that you people are suckers for video. Also, I highly recommend TubeChop for extracting a portion of a YouTube video.)
Let's take a look at the most important Flare/DITA integration pieces.
New output possibilities
After importing DITA content into Flare, you can publish to any of the output formats that Flare supports. Most important, in my opinion, is the option to publish cross-browser, cross-platform HTML-based help ("web help") because the DITA Open Toolkit does not provide this output. We have created web help systems by customizing the Open Toolkit output, and that approach does make sense in certain situations, but the option to publish through Flare is appealing for several reasons:
- Flare provides a default template for web help output (actually, three of them: WebHelp, WebHelp Plus, and WebHelp AIR)
- Customizing Flare output is easier than configuring the Open Toolkit
Not bad at all for 10 minutes' work. I added the owl logo and scriptorium.com in the header, changed the default font to sans-serif, and made the heading purple. Tweaking CSS in Flare's visual editor is straightforward, and changes automatically cascade (sorry) across all the project files.Ease of configuration
Flare wins. Next topic. (Don't believe me? Read the DITA Open Toolkit User Guide -- actually, just skim the table of contents.)
Language support
The Open Toolkit wins on volume and for right-to-left languages; Flare wins on easy configuration (I'm detecting a theme here.)
Out of the box, both Flare and the Open Toolkit provide strings (that is, localized output for interface elements such as the "Table of Contents" label) for simplified and traditional Chinese, Danish, Dutch, English, Finnish, French, German, Italian, Japanese, Korean, Norwegian, Portugese, Spanish, Swedish, and Thai (I have omitted variations such as Canadian French).
Beyond that, we have the following:
- Right-to-left language support: Only in the Open Toolkit
- Language strings provided by the Open Toolkit but not by Flare: Arabic, Belarusian, Bulgarian, Catalan, Czech, Greek, Estonian, Hebrew, Croatian, Hungarian, Icelandic, Latvian, Lithuanian, Macedonian, Polish, Romanian, Russian, Slovak, Slovenian, Serbian, Turkish, and Ukrainian
- Ease of adding support for a new language: Flare wins. In the Open Toolkit, you modify an XML file; in Flare, you use the Language Skin Editor (although it looks as though you could choose to modify the resource file directory directly if you really wanted to)
Map files
I imported a map file into Flare and published. Then, I changed the map file to include a simple nested ditamap. Here is what I found:
- Flare recognized the map file and the nested map file and built TOC files in Flare with the correct relationships.
- Inexplicably, the nested map file was designated the primary TOC. I speculate that this might be because the nested map file was first in alphabetical order. I changed the parent map file to be the primary TOC to fix this. I don't know what would happen for a more complex set of maps, but I am concerned.
- Flare inserted an extra layer into the output TOC where the nested map is found.
- The titles generated in the TOC are different in Flare than they are through the DITA Open Toolkit (see below).
Then, I imported the same map file into Flare, generated WebHelp, and got the following TOC output:
Notice that:- The TOC text is different (!!). The DITA Open Toolkit uses the text of the topic titles from inside the topic files. Flare uses the text of the @navtitle attribute in the map file. My topic titles and @navtitles don't match because I created the map file, then changed a bunch of topic titles. The map file didn't keep up with the new titles (because it doesn't matter in the Open Toolkit), but it appears to matter for Flare. The entry in the map file for the first item is:
<topicref href="introduction.xml" navtitle="Introduction" type="topic">Flare picks up the "Introduction" from the navtitle attribute.
Inside the file, you find:
<title>Executive summary</title>The Open Toolkit uses the content of the title element from inside the file.
In part 2 of this review (coming soon), I'll look at cross-references, reltables, conrefs, specialization, and conditional processing.
Labels: analysis, dita, DITA Open Toolkit, flare, reviews
10:05 AM Permalink | |
Top five reasons to like XMetal and oXygen
Thursday, June 11, 2009 — posted by Sheila Loring
Full disclosure: We're an XMetaL Services Provider and have no particular affiliation with oXygen.I'm in the fortunate situation of having access to both XMetaL 5.5 and oXygen 9.3. Both are excellent XML editors for different reasons. I'd hate for Scriptorium to make me choose one over the other.
From the viewpoint of authoring XML and XSLT, here are my top five features of both editors:
oXygen
- Apply XSLT on the fly: You can associate an XML file with an XSLT and transform the XML within oXygen. Goodbye, command line! XMetaL will convert the document to a selected output format. You don't choose the XSLT--it hasn't been a big concern for me.
- Indented code: The pretty-print option makes working with code so easy. You can set oXygen to do this automatically when you open a file or on demand. The result is code indented according to the structure. XMetaL doesn't have pretty print.
- Autocompleting tags:
As you type an element, oXygen pops up a list of elements beginning with the typed string. You press Enter when you find the right tag, and the end tag is inserted for you. The valid attributes at any particular point are also shown in a drop-down list. XMetaL doesn't have autocompleting tags. - Find/replace in one or more documents: I've often needed to search and replace strings in an entire directory. In XMetaL, you can only find and replace in the current document.
- Comparing two documents or directories: Compare files by content or timestamp. In a directory, you can even filter by type so only XML files, for example, are compared. XMetaL doesn't offer this feature.
- Auto-tagging content: You can copy and paste content from an unstructured document (a web page, for example), and XMetaL automatically wraps the content in elements. Even tables and lists are wrapped correctly. This can be handy if you have a few documents to convert. In oXygen, the content is pasted as plain text.
- Auto-assignment of ID attributes: Never worry about coming up with unique IDs. XMetaL will assign them to the types of elements you select. Warning: The strings are quite long, as in "topic_BBEC2A36C97A4CADB130784380036FD6." oXygen only inserts IDs on the top-level element but full support will be added in version 10.3.
- Auto-insertion of basic elements: When you create a document, XMetaL inserts placeholders for elements such as title, shordesc, body, and p. It's a small convenience. oXygen will also insert elements if you have Content Completion selected in the Preferences.
- WYSIWYG view of tables: The table is displayed as you'd see it in a Word or FrameMaker document. In oXygen, all you see are the table element tags.
- Reader-friendly tag view: The tags are a bit easier to read in XMetaL than oXygen. In XMetaL, the opening and closing tags are displayed on one line when possible.
This feature saves space on the page and makes the document easier to read in tag view. For example, you might have a short sentence wrapped in p tags. In XMetal, the p tags are displayed on the same line. In oXygen, the p tags are always on separate lines. This is another convenience that doesn't sound like a big deal, but it really makes a difference while you're authoring.
What I'd like to see in XMetaL: The ability to indent code, the ability to drag and drop topics in the map editor.
What's I'd like to see in oXygen: The ability to view a table--lines and all--in the WYSIWYG view instead of just the element tags.
So how do I choose which editor to use at a particular moment? When I'm casually authoring in XML, I choose XMetaL for all of reasons you read above. The WYSIWYG view is more user-friendly to me. But when I'm writing XSLT or just want to get at the code of an XML document, oXygen is my choice.
Get the scoop on oXygen from http://oxygenxml.com. Read more about XMetaL at http://na.justsystems.com/index.php.
Update 6/15/09:
I'm thrilled to report that two deficiencies I reported in oXygen 9 are now supported in the latest version of oXygen -- 10.2.
- In Author view, tables are now displayed in WYSIWYG format. Just like in your favorite word processor, you can drag and drop column rulings to resize columns. After you resize columns, the colwidth attribute in the colspec element is updated automatically. This is much easier than manually editing the colwidth.
- In Author view, the tags are now displayed on one line when possible. Before, the tags were always on separate lines from the content.
Labels: analysis, oxygen, reviews, xmetal, xml, XSLT
1:54 PM Permalink | |
Review of screen capture programs
Tuesday, February 17, 2009 — posted by Sheila Loring
Matthew Ellison reviews seven screen capture programs: FullShot, HyperSnap, SnagIt, Madcap Capture, RoboScreen Capture, ScreenHunter (free), and TNT. He also points out what to look for in a screen capture tool and compares features in a handy table.http://www.writersua.com/articles/capturetools/index.html
SnagIt lands at the top of the bunch. Matthew describes it as "the most full-featured of the capture tools reviewed in this article."
I'm a recent SnagIt convert after using Paint Shop Pro for years. SnagIt can't be beat for a quick, easy screen shot. I also like the torn edge options to indicate a partial shot of the GUI. But the jagged edges might be more of a creative device than helpful visual cue. What do you think?
Labels: reviews, screen captures, SnagIt
11:37 AM Permalink | |