All aboard! Onwards to structured authoring!

Our team of technical writers is embarking on a journey towards structured authoring. With 10 writers, we’ll move from an unstructured Word to PDF/CHM environment to a structured Flare to WebHelp/PDF environment. Or I should say “semi-structured”: We do have an information model based on DITA, but we won’t actually be able to enforce it with Flare (which we knew before we chose the tool).

It’ll be an interesting cruise, to be sure! Four writers already apply topic-based authoring rather than the previous free-form documentation guided mainly by common sense. The others have had training, but no real opportunity to write topics continuously. We have drafted tighter new processes to draft, write, review and edit topics to replace the previous loose processes of writing and reviewing, but they are not in place yet.

And then there’s the new tool, of course. Only one of us has worked with Flare before. Many of us are excited about getting Flare. Some really like it – what we’ve seen in several demos so far. Others just really loathe the current writing environment.

“Regarding the pain of others”

So as we’re about embark, I’ve been looking out for others who’ve taken the trip before. Scriptorium’s State of Structure webcast has been very helpful: Its results of a survey among 200 tech communicators helps to position us in relation to others who are currently implementing structured authoring or considering it. It also collects some mistakes respondents have gone through. I’ll just be quoting a few select points, but the whole webcast by Sarah O’Keefe is totally worth checking out, so thanks to Scriptorium for making this webcast available!

Reasons

The top reasons why survey respondents (consider to) move to structured authoring made us nod emphatically: Reuse, consistency and cost savings are also at the top of our wish list of achievements. Looking ahead, it’s promising that the majority of respondents achieve these goals.

We’ll also take other goals that respondents achieved, whether it’s to automate processes or to reduce content (oh, yes, please, we’re not even exactly sure how much redundant, almost identical content we have). So far we’re confident, we’re not only doing the right thing, but doing it for the right reasons, too!

Efforts

Savings have their own price, of course. Sarah’s survey confirms several cost points we’ve already identified in the project.

  • Converting legacy content is a biggie for us, simply because we currently have a lot of stuff.
  • Redefining output layout will take time, but will be worth it given what Flare is capable of doing with CSS in both web and print outputs.
  • Integrating a new system with its writing and publishing processes into our product and workflow systems will also take some time.

Mistakes

Mistakes have been made by others before us, and we’ll have plenty of chances to make our very own mistakes. If we’re lucky, we can avoid repeating the mistakes of others:

  • Planning and project management cause problems, maybe because most companies lack the experience of major documentation overhaul projects. Sarah specifically mentioned the lack of understanding of the project scope and of the need for testing. So we’ll look through our project plan again and ensure that the estimates are plausible.
  • Converting legacy contents can also get you into trouble, especially when you convert something that’s less than structured. It doesn’t help if you reserve too little time to do it or get inexperienced people to do, whether it’s off-shore labor or student helpers. That’s sound advice: GIGO (“garbage in, garbage out”) can certainly endanger the expected benefits. A new tool can help us be more efficient, but we still have to learn and apply structured writing in topics. So this confirms one of my two tech comm dogmas: Don’t get a new tool to fix your processes!

Setting out

What do you think? Is our crew well-equipped, given a tried and proven method, well-defined processes, a new tool and the words of warnings above? If you have additional advice, please leave a message.

Advertisements

Top 5 things I like about WritersUA

WritersUA is a very stimulating and inspiring conference! This year’s 19th annual conference draws 360 attendees (speakers included) which makes it the largest tech comm conference I’ve attended so far. Kudos and compliments to Joe Welinske and his whole team who simply “get it right”.

Here are the top 5 things I like about WritersUA:

1. Great program, good pace

An online community on the conference web site allows attendees to connect as much or as little before the conference as they like. The program is paced very well: At 60 minutes, sessions are long enough to be thorough and leave time for questions and discussions. 20-minute breaks between sessions allow for several contacts with attendees and/or exhibitors.

2. Proceedings are available before hand

At first, I was overwhelmed by the package I received at registration, but it makes sense: Looking through the slides allows you to make the best possible decision which session to attend. Even if several presenters have edited their slides after submitting them for print, but the earlier versions are always a good, reliable indication. Initially, I had selected sessions by my general interest in the topics. After reviewing the slides, I changed my schedule for Monday completely. One session looked more basic than I had expected, and the slides are so comprehensive I couldn’t imagine I would miss much (and from what I heard from attendees I didn’t).

3. Sessions that are worth attending – in person

I got the most out of sessions that offered constructive discussions in addition to mere presentations:

  • Rob Houser presented a “community-works-in-progress”, a Pattern Library for User Assistance, where we discussed whether this was something worth having, whether we could imagine contributing to it and how to best go about it. (For more information, follow the link above, see Chuck Martin’s write-up or watch this space for a more elaborate review.)
  • Linda Urban described and analyzed her experiences with Opportunities for Reuse Between User Assistance and Training and invited a discussion which was very enlightening: Even between two such closely related domains, different cultures, organization, budgets and deliverables make it difficult to break down the silos and to collaborate successfully.

4. Comprehensive look at help authoring tools

WritersUA offers a unique combination of first- and second-hand experiences to compare tools in depth.

The exhibition area at WritersUA

  • In the exhibition area, most of the relevant vendors are present among the 14 exhibitors and more than willing to present their products in the best possible light.
  • In a lab, attendees have access to most of the relevant tools at workstations. You can just play around with them or visit at a time when a vendor is at hand to ask questions (though these are not presentations).
  • And during the meals and breaks, you can ask other attendees about their experiences with the tools.

5. Great gathering of passionate, fun tech writers

As early as Saturday afternoon, I met friends from previous conferences and people who’s writing, blogs or tweets I’ve seen online. The various networking opportunities make it easy and fun to strike up a conversation, trade travel stories, share frustrations about clueless managers or absurd processes or quote obscure Doors’ songs.

– So far, WritersUA has been a great example of my Top 5 reasons to attend a tech comm conference. If you’re attending WritersUA or have attended a tech comm conference in the past, feel free to share what you liked best about them in the comments.

MadCap roadshow in Long Beach

MadCap kicked of the 2011 season of roadshows on March 13 in Long Beach, CA, to coincide with the workshop day of the WritersUA conference.

A full-day program offered primers on topic-based authoring and single sourcing, best (and less recommended) practices of collaborative authoring, and a passionate introduction to Cascading Style Sheets (CSS). Shorter breakout sessions (which don’t seem to be part of the other roadshow dates) presented tips and tricks for Flare: How to handle tables, create print output and localize, as well as a case study about moving from RoboHelp to Flare.

Mike Hamilton at the MadCap roadshow

Mike Hamilton reminds us to think topics!

More like a conference

Several aspects made the event feel more like a Flare-centric conference than the marketing or sales event it was as well:

  • Presentations address tech writing challenges in general, whether or not you use Flare:
    • How to optimize topics for reuse
    • How to efficiently publish to several media from one source
    • How to collaborate with other authors.
    • And, oh yes, how you can do these things with Flare. But the general emphasis was on: “Here’s how you can work efficiently.” In fact, the helpful introduction to CSS didn’t rely on Flare at all. The more sales-y “Wanna see what the new version can do?” came only in a longish rock video with MC Mike during the drinks reception.
  • Networking opportunities galore during breakfast, lunch, the concluding reception and to some extent even during the breakout sessions.
  • A day’s worth of Q&A. MadCap brought more than a dozen people from all teams to be able to answer any question that we present and future users might throw at them. Their answers were usually constructive and frank, though my question about the number of employees got the PR-tinted answer “fewer than 100”. When asked whether Flare can do X, Mike sometimes says: “Not at the moment.” Previously, I thought this was just supposed to sound better than “No.” But after following Flare’s development for a few versions, I now see that many of such features have been added, such as the long-awaited formula capabilities in version 7.

Taking tech comm seriously

In a nutshell, MadCap continues to take tech writers, their requests and issues seriously. Here are some examples of insights from the sessions to illustrate how they go beyond the bells and whistles of selling a new version:

  • Customer focus is important – but documentation must also recognize and satisfy the owner (usually, the company that pays for the documentation) and the manager (who needs to ensure that documentation is completed in time and in budget).
  • Create separate target definitions for separate deliverables. Don’t rely on manual steps in the production process which might get lost in the hustle and bustle. For example, don’t trust that you’ll remember to update the global variable with the correct company name…
  • When you share source files over a network, even in a small team, use either a dedicated source control system or SharePoint (which includes source control) which avoids two people editing the same file at once and allows to lock down central resources like stylesheets.
  • There is no one font size that’s always appropriate. How large a font appears depends a lot on the “x-height” (roughly the height of the letter x), and that can vary in fonts of the same size.

Wish list

Taking my cue from other conferences I’ve attended, I think MadCap could add two things to improve the roadshow:

  • Book table. There are a few books available about MadCap products. For those of us who like books with their tools, why not have at least a sample copy by the registration table, so we can check them out whether we want to buy them or not?
  • Rant & rave session. This one might not be in MadCap’s best interest, but hey, they’re generally a pretty accessible company who like to collaborate with their customers and prospects. I think they should put on a session where attendees can get one minute each to rant and/or rave about the products. Such a forum would give MadCap a quick way to see what bothers a lot of users – and what they like. Two peeves came up:
    • The previously free reviewer module “X-Edit” has been replaced by “Contributor” which requires a license per user. This is not feasible in environments where each writer easily has one or two dozen potential reviewers. MadCap needs to come up with a better licensing model for this.
    • Flare lets you define separate CSS Mediums for print and online in great detail. A field near the top indicates which one you’re editing. Yet a lot of users still manage to edit the “wrong” one when they get all engrossed in styles. Simply highlighting this better would improve usability for focused, single-minded users.

If you’ve attended a MadCap roadshow or other such industry event or are considering to attend, feel free to share impressions or questions in the comments.

Recommended video: What’s new in MadCap Flare 7

Here’s a timed summary of the “MadCap Flare V7 – What’s New Demo” and more resources that review the latest Flare release.

The 55-minute video is by Mike Hamilton, VP Product Management of MadCap Software, recorded on March 3. The audio is not spectacular, but other than that it’s a lively, engaging demo. You’ll find the video on MadCap’s webinar web page.

I’ve prepared this transcript summary, because I wanted to refer to individual “chapters” of the demo. I like Flare and MadCap Software, but am not affiliated with them, other than as a fan and past and future user.

More MadCap resources

Flare 7 covered elsewhere

MadCap Flare V7 – What’s New Demo, Topics & Times

0:00 Webinar preliminaries

1:30 Find more info about Flare 7 at the MadCap web site

3:40 Agenda

  • General
  • Editor
  • Workflow/Team Environments
  • Viewing/Testing
  • MS HTML Help Enhancements

5:20 1. General Topics

  • Accessibility Enhancements
  • Reports Engine (which is new, not MadCap Analyzer)

6:50 General > Accessibility Enhancements

  • Web help and PDF enhanced for users with disabilities
  • Add screen tips to graphics for screen readers
  • Optional build warnings remind you of accessibility issues: missing alternate text, etc.

10:50 General >Reports Engine

  • Create custom reports about all files in project
  • Build a report from scratch or use included report templates
  • Examples: Show all conditions in report files, show all topics with changes and comments

14:30 2. Editor Enhancements

  • QR Codes
  • Equation Editor
  • Vector Graphics
  • Auto Suggestion
  • Alias Editor Enhancements
  • Table Enhancements
  • Customize Flare UI Grids
  • Remove Inline Formatting
  • Shortcut Buttons (Snippets/Variables)
  • Paste Options

15:20 Editor > QR Codes

  • QR codes are smartphone-readable (“square barcodes”)
  • Include an URL, e-mail address, or text in print output
  • For online output, you can make the barcode clickable…

18:05 Editor > Equation Editor

  • Supports MathML code
  • Formulas are inserted in author mode as stylable, scalable vectors
  • Formulas render as lossless, non-blurry postscript in print & PDF
  • Formulas render as graphics online

20:45 Editor > Vector Graphics

  • Supports inserting SVG, PS and EPS graphics in topics
  • They allow lossless scaling
  • Render as lossless, non-blurry postscript in print & PDF
  • Render as graphics online

24:10 Editor > Auto Suggestion

  • Can be turned on and off
  • Reminds you of existing snippets (=sub-topics) and variables (=module names)!
  • Makes reuse of snippets and variables easy
  • Supports added common phrases, too

26:25 Editor > Alias Editor Enhancements

  • Completely reorganized
  • Shows complete, incomplete and missing aliases
  • You can auto-generate file IDs from pattern

(29:20 You can move tabs of open pages around.)

30:30 Editor > Table Enhancements

  • In Flare editor, you can convert text to table and table to text
  • (Be patient with Mike; he needs a minute to find the feature in the GUI…)
  • You can also merge tables

34:15 Editor > Customize Flare UI Grids

  • You can customize any dialog, any GUI grid in the Flare editor for custom column layout and appearance

35:50 Editor > Remove Inline Formatting

  • You can remove inline formatting easier, without highlighting exactly

37:45 Editor > Shortcut Buttons (Snippets/Variables)

  • Icons in text workspace provide faster access to selection of snippets and variables

38:50 Editor > Paste Options

  • Paste text as paragraph, list, table

40:00 3. Workflow/Team Environment Enhancements

  • SharePoint Integration
  • Subversion Integration
  • External Resources
  • Review/Track Changes

40:15 Workflow/Team Environments > SharePoint Integration

  • You can integrate Flare projects into SharePoint or import any SharePoint file into Flare

41:15 Workflow/Team Environments > Subversion Integration

  • Subversion is now directly integrated
  • Without 3rd party plug-ins, such as Tortoise
  • This is now like Microsoft Team Foundation Server and Visual Source Safe

42:15 Workflow/Team Environments > External Resources

  • You can use any external resource/file in Flare
  • … even if it’s not part of any Flare project
  • Link to any network file that’s accessible
  • However, these resources are then outside of Flare’s source control

44:30 Workflow/Team Environments > Review/Track Changes

  • Comments and Track Changes essentially acts as in Word
  • With multi-colors, strike-through
  • Several users can see each other’s edits
  • You can accept/reject changes individually or accept/reject all
  • This works only in the Flare editor and in Contributor (previously X-Edit)
  • It doesn’t work in any output

49:10 4. Viewing/Testing Enhancements

  • Chrome
  • Preview Any Format
  • WebHelp Output – Choose Browser

49:10 Viewing/Testing > Chrome

  • Fixes bug that you couldn’t view (any vendor’s!) local web help in Chrome browser

50:20 Viewing/Testing > Preview Any Format

  • You can quickly select to preview the topic in any defined target format, not just one selected format
  • Easier, more realistic previews

52:30 Viewing/Testing > WebHelp Output – Choose Browser

  • You can quickly check web help output in any installed browser: IE, Firefox, Chrome, Safari

54:10 5. MS HTML Help Enhancements

  • You can import a .CHM file as a Flare project, including the TOC and index

55:30 End

Top 5 reasons to attend a tech comm conference

The benefits of attending a tech writing conference go way beyond learning about methods and tools. That’s why I really look forward to Writers UA next week!

Most reasons are kinda obvious really. But put them all together, and they create a serious pre-conference buzz, almost like when you follow a band on tour or attend an intense music or theatre workshop. If you’ve never been to a conference, I can assure you all the benefits will make it worth your while. And if you know what it’s like, I invite you to add your own reasons in the comments.

(tekom 2010, photo by jophan).

1. Learn about methods and trends

This is the “official”, token reason: Of course, you’ll learn about tech writing methods, tech comm trends and case studies. Look at the conference web site which gives you an idea what to expect. (Here’s my earlier list of links to conferences this year.)

2. Check out new tools and versions

Many conferences double as a trade fair, so you can get a guided tour and a hands-on impression of new tools without installing trial versions and wondering “now what?”.

3. Meet experts (a/k/a make friends)

I’m always amazed at the combined expertise at conferences. And I don’t just mean the speakers. Go down to the hotel registration desk, and you may meet someone whose tweets you’re following. Sit down at the bar, and you may chat with someone who’s been using the content strategy you’re pondering. The chance acquaintance at the dinner table may have been using the tool you’re considering.

4. Connect with the hive mind

Often you can come with a specific question in mind and find ways to answer it. TCUK10 had a rant session that also gave people the opportunity to solicit answers from attendees. WritersUA has a more formalized Q&A opening session: “Let’s Look in the Mirror and See What We See“. Where else can you get instant, free consultation from dozens of experiences tech writers at once?

5. Visit with friends

If it’s your first conference, you’ll enjoy to get to know people better who you’ve just met. Then you can look forward to meeting people again you haven’t seen in a while, but you’ve seen their tweets, blog posts or articles.

Bottom line: Soak up inspiration and motivation

It all boils down to this: A conference can give you inspiration, motivation and confidence that you’re not alone, that you’re doing something professional and totally worthwhile! If that isn’t worth your time (and maybe even some of your money…) 🙂

Practical tip: Share costs and benefits

It’s pretty obvious that your company shares in most of the benefits. So it’s in their interest as well that you attend a conference. If your boss has more understanding than budget, consider if you could split the cost:

  • Maybe you can pay (and write off) travel costs?
  • Maybe you don’t have to take days off to attend?

[Update 8 March: Bill Albing answers that once-a-year conferences are sooo yesterday in the age of social media. Make sure you also read his Top 5 Reasons to Avoid a Tech Comm Conference.]

Your turn

Do these benefits work for you? What other benefits can you think of? If you’re freelancing, can you land new contracts at a conference? Please leave a comment.

Organize bookmarks in folders by task

Make the most of bookmarks by sorting them by tasks.

That’s the lesson I learned after months of trudging along with a looong list of bookmarks. I would add links for later reading, then randomly pick pages to read or otherwise process, and it was not working.

Around New Year’s, I cleaned up the mess, threw out dead links and pages that seemed merely vaguely interesting. The remainder went into separate folders. This has been working really well for me so far: I remember and find bookmarks faster, and I process them faster (which means reading and filing or deleting).

Organize by task, not by content

The trick for me was to create bookmark folders by tasks, not by subject matter or contents! I now have the following bookmark folders:

  • Tech Writing with pages to read and archive useful ones.
  • Blog with pages to write about in this blog.
  • [Project] with pages to work on for articles or presentations, one per project.
  • Portable Freeware with pages of software to try out.
  • Travel with pages of hotels and restaurants to visit.
  • Inspire with pages to get me unstuck from writer’s block.
  • Lookup with pages to look up grammar rules, translations, prices, streets, etc.

Why does this work?

It works for two reasons:

  1. It’s basically following our own professional advice: Create documentation task-based, not based on the stuff you organize, whether it’s a user interface or random web pages.
  2. It’s inspired by GTD (Getting Things Done): Get productive by ensuring you can simply crank widgets as a tech writer.

Bonus tip

Sync your bookmarks across all your machines for even better order and productivity. I use xmarks for Firefox to ensure all my bookmarks are always up to date, regardless of which PC I use. When I’m on someone else’s machine, I can still look up my bookmarks online.

Your turn

How do you organize your tech comm bookmarks? Do folders work? Is there a better way? Please leave a comment.

Recommended read: Practice technical writing

Becoming a better tech writer requires practice.

Mike Pope, tech editor at Microsoft in Seattle, has a brilliant blog post about 12 ways to practice tech writing. The catch is he means “practice” like a musician, so you learn to do stuff better than yesterday – instead of just doing the same things over and over.

Over the last years, I’ve tried all 12 ways, and they’ve all helped me to become a better writer. And most of them can be fun, too, at least most of the time… 🙂

Here are just six of the ways as a teaser, but I highly recommend you head on over to Mike’s post to find out about all of them with details and examples.

1. Read other technical writing attentively.
2. Read about writing.
5. Writing something outside your usual material.
7. Edit someone else’s work.
10. Learn new tools and new ways to use your existing tools.
11. Talk to other writers.