I’ve been over-analyzing the process I use for content creation. In fact, it’s pretty simple, and the requirements are low. I don’t require a lot of technical overhead to create documentation for my company, and that includes written content, videos, screenshots, and diagrams. And tags and links and comments and a bit of organization.
I’m not creating a set of manuals, or building in-product help. (Not yet, anyway.) Which is what the majority of tech writers do, and I think that’s why I don’t get a lot of value out of most tech writing organizations and conferences.
A little more detail
That said, I’m not much of a joiner in the first place. I’ve never been a member of STC; it’s always seemed too academic and conceptual, and without enough practical value to justify the expense. It seems to be good for personal development and recognition if you’re willing to put in the time and effort, but I’m more afraid of being drawn into debates over “e-mail” vs. “email,” a pastime that many tech writers seem to really enjoy.
But…I attended TC Camp last year (I was unable to attend this year), and I went to LavaCon in 2012. And I enjoyed both of them. I talked to a lot of people, and went to a lot of panels, and took a lot of notes.
I just didn’t end up using a lot of that. Many of the panels deal with processes that I’ve followed for years: Topic-based writing? Of course! Who isn’t writing that way?
DITA and PDF generation? Nah, not something I need. Content reuse? I’ve gone back and forth over that one, and I’m now in favor of NOT having the same info copied in multiple places. But…I do have a few small bits of info in multiple places in my docs, because they’re very small and it’s more work for the user to go to a new page to get that little bit of info. But it’s not a great solution, and I intend to fix it…once I figure out a good solution.
Who I turn to
Probably no surprise, but I get the most value from Tom Johnson and Mark Baker’s blogs. Tom, for example, recently described my doc requirements almost perfectly in this post. I’ve been using Google docs to make it easy for SMEs to review my docs, but I hadn’t discovered the StackEdit piece of the puzzle. Now I can write in Google docs, use StackEdit to convert to HTML, and post that to my knowledge center (which runs on ZenDesk).
Since I’m writing online docs, I need to follow something awfully close to Mark’s Every Page is Page One philosophy: Topics must be self-contained, but at the same time must contain plentiful links to related topics to provide the reader with full context.
Sharon Burton and Sarah Maddox also provide very useful info, but I find that their blogs often focus on old school doc topics (hardly their fault, though, since they spend so much time working with companies who refuse to change those processes). For example, Sarah’s post about API types is an incredibly useful summary. I’ve documented SOAP and REST APIs, but I haven’t worked closely with the other types.
Problems with conferences
The first problem is the expense. Most small companies aren’t eager to spend money to send their single doc resource away from the office for a few days. I’ve had more than one manager who told me that they didn’t see the value in conferences, so that makes the request a non-starter.
When I look at conference schedules, I can often cross of entire schedule tracks. There are often entire programs designed around DITA, or specific tools that I don’t use (I’m sure ArborText is very nice; I am, however, perfectly happy to not be using FrameMaker anymore, even though the keyboard shortcuts are burned into my brain).
With the more relevant topics, I get the impression that the speaker is only slightly further along then I am. It would probably be more useful to sit down with that person and a small group and throw around ideas.
More value from small groups
That’s the benefit of working with tech writers: When you can get away from the silly grammar battles and focus on developing new processes. That’s why TC Camp was more valuable than the much more expensive LavaCon: LavaCon has an impressive lineup of speakers, but it’s just not as valuable for experienced content creators, or tech writers who aren’t using the most popular tools or workflows.
Which makes sense: A conference that appealed solely to content creators who do what I do would attract a very small number of people. Not a good business model. If most writers are use FrameMaker or RoboHelp or whatever, then conference organizers need to appeal to them.
With the standard speaker/listener role at the larger conferences, I don’t feel as engaged. But I feel like I should be engaged, and should be interested in conferences. Although maybe I’m just grumpy because my twitter feed is full of techcomm people on a sort of conference holiday month; but, again, that’s what happens when you follow a lot of contractors/professional speakers who are doing their jobs.
I’ll give TCCamp another shot next year, and maybe actually get off my butt and suggest some topics that I would find interesting. Until then, I have some problems to solve (largely of my own creation), and maybe I’ll come up with some answers that would be of more general interest.