Skip to main content

A mercenary view of STC

STC has announced their new dues structure.

To summarize:

  • Dues are going up.
  • Printed publications are no longer included in basic dues.
  • No chapter or SIG membership are included in the basic dues.
  • There are still tiered dues for “persons located in low and lower middle-income countries as classified by the World Bank,” but those dues have also increased.

Predictably, reaction is largely negative, such as this comment from Julie Ross:

Good luck, STC! Your membership is not worth $215, especially when it includes less than it did before! I will not renew at these increases. Money better spent in other ways.

I have been a freelancer/business owner for the vast majority of my career (so far). Let me say a few things about STC’s value proposition for mercenaries like me.

Flickr: amagill

Money // Flickr: amagill

Cold, hard cash

My participation in STC events, especially the annual conference, has led to enormous amounts of business for my company. Let’s take just one example: During an STC conference a few years ago, I was approached by representatives of a government agency to discuss a major project. (I found out later they had attended my session to see if they wanted to talk to me. I apparently passed that test.) That meeting resulted in a new customer and over $250,000 in revenue for Scriptorium.

We ask customers and prospective customers how they found us. “I saw you at a conference” is a common answer. I don’t have exact figures on how much revenue we derive from conference participation, but I know that it’s significant. Even if we only get one project a year from an event, the investment is worthwhile.

Those of you who are freelancers or consultants probably have similar experiences. Conferences are an excellent marketing tool. If you are a regular employee or the thought of speaking in public makes you ill, this argument is perhaps less compelling, which brings me to…

Wishing well // Flickr: dystopian

Wishing well // Flickr: dystopian


It’s become a cliché that networking is the best way to get a job. But I think a lot of people approach this the wrong way:

  1. Oops, I lost my job.
  2. Time to do some networking.

Wrong. Networking is a lifelong project. If you want help getting your next job, you need to lay the groundwork months or years ahead of time. Got a job opening at your current employer? Send it out to respected colleagues. Have an acquaintance who’s been laid off? Help them out; offer to review or proofread their resume. When you need help (and believe me, at some point we all do), your network will return the favor.

At the last STC chapter meeting I attended, at least 30 percent of the people there were unemployed. I wonder how many of them started attending meetings only because they need a job. A long time ago, I read Dig Your Well Before You’re Thirsty by Harvey Mackay, and I highly recommend it if you want some advice on how to become a successful networker.

Let’s say you change jobs once every five years or so. And let’s assume that networking inside STC can help you get a job just a few weeks faster than you would on your own. If you make $60,000 per year (for easy math purposes), that’s $5000 per month or about $1250 per week. Five years of STC dues is around $1,000. If you can find employment even one week sooner, your STC investment breaks even. If you find a job two weeks faster, you come out ahead.

I’m not even addressing the case where your network helps you find a better job where you make more money or improve your commuting time. What’s that worth to you?

You do not want to be a paper clip. Flickr: bbaunach

Don't be a paper clip // Flickr: bbaunach

Avoiding commoditization

The mission of STC is to “advance the arts and sciences of technical communication.” How does this help you, the member?

If STC succeeds, you are more likely to find jobs that pay well because your work is respected.

You are less likely to be the first person laid off in a downturn.

You are less likely to find job postings that include general office work among technical communication tasks.

You are less likely to be replaced by another, less skilled, less expensive writer.

In short, if technical communication is valued, your work is less likely to be viewed like a commodity.

Commoditization is very, very bad for your income and employment prospects. Paper clips are commodities to be procured at the lowest possible cost. Quality is rarely an issue. You do not want to be a paper clip.

Based on these major factors, the value of STC is clear to me.

Read More
Conferences Webinar

Coming attractions for October and November

October 22nd, join Simon Bate for a session on delivering multiple versions of a help set without making multiple copies of the help:

We needed to generate a help set from DITA sources that applied to multiple products. However, serious space constraints prevent us from using standard DITA conditional processing to create multiple, product-specific versions of the help; there was only room for one copy of the help. Our solution was to create a single help set in which select content would be displayed when the help was opened.
In this webcast, we’ll show you how we used the DITA Open Toolkit to create a help set with dynamic text display. The webcast introduces some minor DITA Open Toolkit modifications and several client-side JavaScript techniques that you can use to implement dynamic text display in HTML files. Minimal programming skills necessary.

Register for dynamic text display webcast

I will be visiting New Orleans for LavaCon. This event, organized by Jack Molisani, is always a highlight of the conference year. I will be offering sessions on XML and on user-generated content. You can see the complete program here. In addition to my sessions, I will be bringing along a limited number of copies of our newest publication, The Compass. Find me at the event to get your free copy while supplies last. (Otherwise, you can order online Real Soon Now for $15.95.)

Register for LavaCon (note, early registration has been extended until October 12)

And last but certainly not least, we have our much-anticipated session on translation workflows. Nick Rosenthal, Managing Director, Salford Translations Ltd., will deliver a webcast on cost-effective document design for a translation workflow on November 19 at 11 a.m . Eastern time:

In this webcast, Nick Rosenthal discusses the challenges companies face when translating their content and offers some best practices to managing your localization budget effectively, including XML-based workflows and ways to integrate localized screen shots into translated user guides or help systems.

Register for the translation workflow webcast

As always, webcasts are $20. LavaCon is just a bit more. Hope to see you at all of these events.

Read More

Strategy < tactics < execution

I read Execution: The Discipline of Getting Things Done several years ago, and much of this post is based on the information in that book. 

Because of a Series of Troublesome Committees, I find myself thinking about three big-picture concepts: strategy, tactics, and execution:

  • Strategy is the overall plan. For example, one strategy for getting new projects at Scriptorium is to establish ourselves as experts in our chosen field.
  • Tactics are specific actions to achieve the plan. Our tactics include writing articles and delivering conference presentations that buttress our claim of expertise.
  • Execution is what happens after you pick a strategy and develop some tactics. That’s when we write the articles and attend the conferences.

Each of these stages is a prerequisite for the other. That is, you start by developing a strategy and can then pick your tactics. Finally, you have to execute on the plan.

You can fail at every point in the process:

  • Choose the wrong strategy, and not much else matters. Great tactics and excellent execution will not rescue you if you have chosen the wrong approach.
  • If you have the right strategy, but the wrong tactics, you may have some limited success, but poor tactics will work against you.
  • Worst of all, though, is bad execution. You pick the right strategy and the right tactics, and then sabotage the whole thing with poor follow-through or lousy performance. For example, writing an article full of bad grammar or delivering a boring, technically inaccurate presentation would be bad execution for us.

At every stage, you face constraints. For instance, if your budget is limited, you might not be able to justify the most expensive tactic, even though it might have been the most effective. But once you work through your constraints and choose your tactics, there’s really no excuse for doing those activities badly.

Some things to keep in mind when working with technical communicators:

  • Forget the spin. Exorcising marketing and PR messages from technical content is a core job skill for many of us. Simple, honest, and straightforward messages are better. If you try to spin your message, expect a scornful response.
  • Language matters. Writers become writers because they care about language. If you want their respect, you need to show that you also care about language. At a minimum, grammar and mechanics need to be accurate. If you can go beyond the basics and demonstrate graceful writing, you will score bonus points.

Read More

The ABCs of XML

STC Intercom, September/October 2009

XML is rapidly becoming part of the required knowledge for technical communicators. This article discusses the three most important reasons that you should consider XML: automation, baseline architecture, and consistency.

Download the PDF PDF file (144K)

Read More

XML 101

My latest XML Strategist article, “The ABCs of XML,” is available as a PDF file (144K). This article was originally published in the September/October 2009 issue of Intercom.

The technical side of XML is not much more difficult than HTML; if you can handle a few HTML angle brackets you can learn XML. […] If […] you don’t like using styles and
prefer to format everything as you go, you are going to loathe structured authoring. 

Just trying to make sure that there are no surprises. The article itself is a very basic introduction to the principles that make XML important for technical communication: automation, baseline architecture (sorry…I had problems with B), and consistency.

Read More

A strident defense of mediocre formatting

In addition to a gratuitous (and entertaining) swipe at “noisome” DITA “fanboys,” Roger Hart argues that we need to reconsider the disadvantages of automated formatting:

The thing is, [separation of content and formatting has] all been taken rather stridently to heart in certain quarters, leading to a knee jerk reaction whenever author-controlled formatting/pagination/lineation is mentioned as anything other than bleak, sulphurous devilry. This is twaddle. […]

Uncertainty in meaning is anathema to user intelligibility. If we’re going to make sure we’re not writing poetry, there’s definitely value in having poetry’s level of control over semantic blocks.

Of course, it’s fully possible that this is an expensive distraction.

Possible? It’s definitely expensive. It’s possible that it’s a distraction.

I think Hart perhaps unintentionally put his finger on the real issue: value. How much value (in the form of improved comprehension) is added to a technical document when you are able, in the words of commenter Brian Harris, to “lovingly handcraft” each page?

How much value (in the form of cost avoidance) is added to an organization when you are able to spit out a reasonably formatted document in a few minutes?

Actually, I have a different question. How far should we take this argument? Here’s an example of the pinnacle of handcrafting:

Book of Kells image
Can we all agree that this might perhaps take handcrafting a little too far?

Compared to the Book of Kells (above), the Gutenberg Bible looks quite pedestrian:

Gutenberg Bible image

You can just imagine the scribes with their quills, lapis, gold leaf, and other implements muttering, “That Gutenberg and his noisome fanboys. He can’t even render two colors without our help. Poser. It’ll never last.”

Formatting automation removes cost from the process of creating and delivering content. For technical documents that change often and are perhaps delivered in multiple languages, it removes a lot of cost. Let’s assume that handcrafted pages can improve ease of reading and comprehension with careful copy-fitting and adjusted spacing (Hart’s article mentions “headings, line breaks, intra-word, etc”). This increases the cost of the content.

What happens when content is expensive? Fewer people get to see it.

Books in Europe went from 50000 before Gutenberg to 12 million 50 years later.

I think we can all agree that e-books offer none of the typographic sophistication in question here. Bill Gates (yes, that Bill Gates) wrote in 1999:

It is hard to imagine today, but one of the greatest contributions of e-books may eventually be in improving literacy and education in less-developed countries. Today people in poor countries cannot afford to buy books and rarely have access to a library. 

Essentially, we can produce documents inexpensively and give more people access to them as a direct result of lower cost, or we can climb on our typographic high horse and whine about word spacing.

I’m with the noisome fanboys.

Read More

Ignoring DOCTYPE in XSL Transforms using Saxon 9B

Recently I had to write some XSL transforms in which I wanted to ignore the DOCTYPE declarations in the source XML files. In one case, I didn’t have access to the DTD (and the files wouldn’t have validate even if I did). In the other case, the XML files were DITA files, but I had no need or interest in validating the files; I simply needed to run a transform that modified some character data in the files.

In the first case, I ended up writing a couple of SED scripts that removed and re-inserted the DOCTYPE declaration. By the time I encountered the second case, I wanted to do something less ham-fisted, so I started investigating how to direct Saxon to ignore the DOCTYPE declaration.

My first thought was to use the -x switch in Saxon. Perhaps I didn’t use it correctly, but I couldn’t get it to work. Even though I was using a non-validating parser (Piccolo), Saxon kept telling me that the DTD couldn’t be found.

I went back to the drawing board (aka Google) and found a note from Michael Kay that said, “to ignore the DTD completely, you need to use a catalog that redirects the DTD reference to some dummy DTD.” Michael provided a link to a very useful page in the Saxon Wiki that discussed using a catalog with Saxon. After a bit of experimentation, I got it working correctly. In this blog post, I’ve distilled the information to make it useful to others who need to ignore the DOCTYPE in their XSL.

Before I describe the catalog implementation, I’d like to point out a simple solution. This solution works best when a set of XML files are in a single directory and all files use the same DOCTYPE declaration in which the system ID specifies a file:

&lt;!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd"&gt;

In this case, you don’t need a catalog. It’s easier to create an empty file named “topic.dtd” (a dummy DTD) and save it in the same directory as the XML files. The XML parser looks first for the system ID; if it finds a DTD file, it uses it. Case closed.

However, there are many cases in which this simple solution doesn’t work. The system ID (“topic.dtd” in the previous example) might specify a path that cannot be reproduced on your machine…or the XML files could be spread across multiple directories…or there could be many different DOCTYPEs…or…

In these cases, it makes more sense to set up a catalog file. To specify a catalog with Saxon, you must use the XML Commons Resolver from Apache (resolver.jar). You can download the resolver from SourceForge. The good thing is, if you have the DITA Open Toolkit installed on your machine, you already have a copy of the resolver.jar file. The file is in %DITA-OT%libresolver.jar. You specify the class path for the resolver in the Java command using the -cp switch (shown below).

The resolver requires you to specify a catalog.xml file, in which you map the the public ID (or system ID) in the DOCTYPE declaration to a local DTD file. The catalog.xml file I created looks like this:

&lt;catalog prefer="public" xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
&lt;public publicId="-//OASIS//DTD DITA Topic//EN" uri="dummy.dtd"/&gt;
&lt;public publicId="-//OASIS//DTD DITA Concept//EN" uri="dummy.dtd"/&gt;
&lt;public publicId="-//OASIS//DTD DITA Task//EN" uri="dummy.dtd"/&gt;
&lt;public publicId="-//OASIS//DTD DITA Reference//EN" uri="dummy.dtd"/&gt;

Note that the uri attribute in each entry points to a dummy DTD (an empty file). The file path used for the dummy.dtd file is relative to the location of the catalog file.

Putting it all together, I created a DOS batch file to run Java and invoke Saxon:

java -cp c:saxon9saxon9.jar;C:DITA-OT1.4.3libresolver.jar ˆ
-Dxml.catalog.files=catalog.xml ˆ
net.sf.saxon.Transformˆ ˆ ˆ ˆ
-xsl:my_transform.xsl ˆ

The Java -cp switch adds class paths for the saxon.jar and resolver.jar files. The -D switch sets the system property xml.catalog.files to the location of the catalog.xml file.

The switches following the Java class (net.sf.saxon.Transform) are Saxon switches.

  • -r – class of the resolver
  • -x – class of the source file parser
  • -y – class of the stylesheet parser

Note, I’m using Windows (DOS) syntax here. If you are using Unix (Linux, Mac), separate the paths in the class path with a colon (:) and use the backslash () as a line continuation character.

When you run Saxon this way, you’ll notice two things: first, Saxon doesn’t complain about the DTD (yay!), but secondly, there is no DOCTYPE declaration in the output. I’ll address how to add the DOCTYPE declaration back to the output XML file in my next blog post.

Read More

HTML 5: Browser Wars Reprise?

Recently, I ran across an article by Rob Cherny in Dr. Dobb’s Journal. He suggests that the added features in HTML 5 combined with an end to the development of XHTML point to a brighter standards-based future. He sees closed solutions like Flash, Silverlight, and JavaFX being supplanted directly by HTML 5 code. His view is that the web owes its success to standards.

It’s tempting to agree. Standards certainly allow for collaborative growth. Though I’m not the least bit convinced that collaborative growth is the foundation of the web’s success. I believe that the web’s incredible success is really traceable to the simplicity and flexibility of HTML. Each new version takes us further from that simplicity.

Through the browser war years we saw the impact of new features in HTML—incompatibility among browsers. My sense is that the success of Flash is largely due to the fact that Adobe owns both ends of the problem. They create the tools that generate Flash code as well as the viewer. Web developers can pretty much assume that what they see, when they build a Flash-based solution, is what the end user will see.

I fear that we will head right back to the bad old days if HTML 5’s complex capabilities are widely employed. I suspect that ‘wait and see’ will last a pretty long time. I have other concerns about HTML 5—more on that later. What do you think—will your organization take advantage of these new capabilities as soon as they are available?

Read More

Font snobbery? (I don’t think so.)

For its 2010 catalog, IKEA used Verdana font instead of the customized Futura it’s used for years. To say people noticed the switch would be an understatement:

“Ikea, stop the Verdana madness!” pleaded Tokyo’s Oliver Reichenstein on Twitter. “Words can’t describe my disgust,” spat Ben Cristensen of Melbourne. “Horrific,” lamented Christian Hughes in Dublin. The online forum Typophile closed its first post on the subject with the words, “It’s a sad day.” On Aug. 26, Romanian design consultant Marius Ursache started an online petition to get Ikea to change its mind. That night, Verdana was already a trending topic on Twitter, drawing more tweets than even Ted Kennedy.

As a fan of IKEA and its products, I can understand the reaction. If you showed me a page out of an IKEA catalog with just text and prices (and no pictures or funky product names, of course!), I could tell you in a heartbeat that the content was from IKEA.

Verdana may be easier to read if you’re looking at the IKEA catalog online, but that font lacks the designer-y flair of Futura. Because IKEA is known for its affordable cutting-edge design, Verdana just doesn’t seem to quite fit the bill.

This situation reminds me of a comment a friend made about a failed hotel in Raleigh, NC. He said, “Did you see the awful Brush Script on the hotel’s sign? Those people clearly didn’t know how to run a business.” I doubt the Brush Script killed the hotel, but that bad design decision gave my friend (and probably many others) a very unfavorable impression about the company.

Earlier this week, Sarah O’Keefe and I were doing some web research and came upon a web site that used Comic Sans. My reaction to that site was less than positive. I loathe Comic Sans, and I find it hard to take any company seriously that uses a font that emulates text in a comic book.

A company’s use of fonts can become iconic–think about the fonts used by Coca-Cola and FedEx in their logos, for example. Font choice does have an effect on how people perceive content, a product, or a company.

I don’t think reactions to fonts are limited to just those who work in publishing and design. No snobbery here at all. (But if noticing fonts makes me a card-carrying font snob, you better believe that card would have no Comic Sans on it.)

For more about the impact of fonts, check out the documentary Helvetica:

Read More

Got plans for May 2010?

After my summer of complaints and criticism of STC and its various issues, I was more than a little surprised to be asked to manage the Design, Architecture, and Publishing track for next year’s STC Summit.

Hoist on my own petard (my obsession with Wordnik continues)…what could I do but agree. Or, go into exile.

Several of the other conference organizers are people I know quite well:

  • The author of Managing Writers: A Real World Guide To Managing Technical Documentation, Richard Hamilton, is the track manager for Managing People, Projects, and Business. He knows his stuff.
  • The principal of UserAid, Paul Mueller, is track manager for three (THREE!) tracks: Education and Training, Web Technologies, and Emerging Technologies. He’s also the Deputy Chair of the conference. (private note to Paul: I take it you were not able to retrieve the goat pictures. Sorry about that.) Another excellent choice.
  • Ant Davey of the UK and Ireland chapter has the Communication and Interpersonal Skills and Professional Development tracks. I’ve worked on STC-related matters with Ant, and he’s a great choice for this track.
  • Rachel Houghton, Program Chair. She did great work on last year’s conference.
  • Alan Houser, conference manager. You may remember him as the guy who retrieved David Pogue from a poorly timed bathroom break during the opening session. I’ve known Alan for many years, and I expect another well-organized event, in which he solves the inevitable emergencies with typical aplomb.

(I’m sure that the other track managers are excellent as well, but I don’t know them personally.)

Here is the description of the Design, Architecture, and Publishing track:

Choice of appropriate design and architectures can improve the efficiency, usability, and quality of an organization’s technical publishing. This track explores issues in information design and system architectures for publishing, with particular emphasis on systems and solutions for organization-wide publishing. Suggested session topics include:

  • Visual communication, integrating text and graphics, page layout
  • Single-source publishing, for multiple delivery formats, multiple purposes, and multiple audiences
  • Methodologies and solutions for content management
  • Comparing and selecting delivery formats
  • Issues in structured authoring and publishing, including migration, design, and deployment
  • XML-based publishing
  • Using industry-standard publishing architectures, such as DITA
  • Accommodating localization workflows in the publishing process
  • Moving unstructured content to structure

And now I need your help in two areas:

  1. Submit your proposals. The quality of the conference is determined by the quality of the presentations. And that, of course, is determined by the quality of the proposals submitted. Please send in your best stuff. I suppose you can look into the other tracks if you must.
  2. Help review proposals. I need two or three people to help out in reviewing conference proposals in this track. I’ve done this in the past; it’s a relatively limited time commitment. You will be asked to read lots of proposals and evaluate them, probably in mid-October. Along with reviewers, I will eventually generate a list of recommendations for which proposals to accept. If you have significant expertise in topics in this track, and especially if you do not intend to submit a proposal of your own, please consider volunteering to help with this effort.

Some notes on this year’s process:

  • The deadline for proposal submission is October 5, 2009 at 10 a.m. Eastern time.
  • This is a direct quote from the conference page: “With the smaller number of sessions (for the most part) only one proposal per speaker will be accepted.” (You can still submit multiple proposals, but do not expect to have more than one accepted.)
  • Two speaker references are required (unless you have presented at this conference in the past four years, in which case we will review your evaluations). I personally intend to put a significant weighting on previous highly rated speaking experience.
  • In 2009, sessions were recorded. I assume this will happen again.
  • The conference is May 2-5, 2010, in Dallas, Texas.

Get started with a proposal

If you have questions, leave a comment or contact me. I look forward to seeing lots of compelling proposals.

Read More