The STC is also offering other types of “help” to writers who would like to attend. Things like:

• The option to pay half your registration fee online and the other half onsite.
• A list of ideas you could present to your boss to see if your employer will pay for your attendance.
• A list of discounted hotels and transportation ideas.

Personally I have never attended the STC Tech Comm Summit, but I would definitely like to one of these days. You can be sure that I will be taking advantage of all the discounts (like registering early) to make sure I can go. Perhaps next year.

Seriously though, I am pleased that I am now a Senior Member, as it makes me feel a little more validated in my choice of profession. Silly, I know, but it’s true. Especially since I’ve been going through some trying times with my current employer, it’s nice to get the validation, and reminder that I did make a good career choice. I enjoy writing, and explaining complex technical concepts to people. While I know not many people always read what I write (that’s my standard joke when people ask me what I do for a living “I write manuals that people don’t read.”), I do enjoy writing them. I enjoy exploring the software that I’m writing about, talking to developers and QA analysts to get all the info, and working with project management and the training department to get all the documents ready. It’s challenging and fun, all at the same time.

So please allow me this indulgence and let me enjoy the moment.  I am a SENIOR MEMBER! Woo!

Interesting.

What’s even more interesting is that my current employer’s software has some of the longest UI strings I have ever seen in a piece of software. I’m used to short strings, button and field labels, but these are 3- and 4- line long descriptions, calls-to-action and explanation of benefit. It’s not only challenging to write from a creative/writing perspective, but it’s challenging because most of the time we don’t know what the character limits are, so we have no idea how verbose or terse we’re supposed to be! Half the time I feel like we’re working in a Twitter-like restrictive area, in that we’ve only got 140 characters worth of space to write up a call-to-action, other times I feel like I’ve got 15 lines worth of space in the UI. Very odd sensation, and you would think that it would be liberating, however I find the contrary to be true.

Handcuffed.

That’s how I feel sometimes as I try to craft the perfect group of sentences that efficiently and succinctly describe the benefits of using our Acme software, only to be told my the Engineering department that the character limit is 350 characters. And my boss tells me I still have to get all the benefit information in those 350 characters, as well as the call-to-action, and also the “what have you done for me lately” angle as well. *Phew*

And who thought tech writers couldn’t be creative?

I enjoy the challenge of coming up with these 350 character UI strings for our Acme software. I enjoy the challenge of trying to determine the benefit to the user clicking the Next button. Of trying to figure out how to get the user to click that Next button.

Copywriting meets tech writing in 350 characters or less.

• a technical writer
• a technical editor
• the Style Police Chief
• the Standards Policy Maker
• the Translator

That last one is a new one for me at my current position because we haven’t had to use my language skills as of yet. At other jobs I often coordinated the French translation of our documentation, however because I’m not a certified translator, my employer didn’t want me doing it. And that was fine by me, because quite frankly, I wouldn’t feel comfortable doing it. My current employer needed to fill the gap between the contractor translation company we previously used, and the in-house translators we will be hiring shortly, so I was asked if I would be willing to do some translation work for us. Normally I wouldn’t be comfortable doing it, however the documents I would be translating were in a conversational tone, (informational bulletins for our user base), and not a technical manual on how to install our software. So this made it somewhat easier to say yes. Besides, I have been wanting to flex my French & Italian muscles at work for a while now, so it was a good opportunity to do so.

Having been a French and Italian literature student in my academic days, I was used to writing up 20-page essays in those languages discussing the literary themes of abandonment in 18th century France (or comparing the existential nature of 20th century French & Italian literature), but these bulletins are an absolute treat to work on since the longest is only 600 words. The main issue right now is going to be the timeline of doing the translations. I’ve got 11 bulletins to translate into both French & Italian, so that’s 22 “documents” to produce in under 9 business days. I thought I was going to have to work a few late nights or on the weekend, however in two days I was already able to finish off 10 of the 22, so I figured I was making good headway. I started off with the shortest bulletins, and did them first in Italian and then in French, and was in a good groove.

Translation work is also a good way to exercise some of my tech writing skills as I’ve had to research online resources (I’m simply amazed at the host of good websites out there that help me conjugate my verbs, or provide me with synonyms in both French & Italian), and use these online tools. It’s been a great experience so far, and is a welcome change to my usual tech writing duties.

I’m enjoying helping out my current employers out of a jam, however I am also aware that I don’t want to let this become a regular habit, because I know that this could interfere with my TW mandate there. And I am finally making good headway on my mandate, producing some documents that are a great starting point for system documentation, so I don’t want to derail that.

This one’s a particularly interesting one, since it’s forcing me to exercise all of my TW muscles.

• Restructuring: The document suffered from being unfocused, as it meandered from topic to topic.
• Rewriting: It was originally written by someone whose command of the English language isn’t that great, so the language had to be redone to be understood.
• Re-Styling: I had to reapply a new version of our department’s document template to it. This was the “simple” part of the project.

The Restructuring portion of the show is taking the longest time, although it’s complicated by the Rewriting task. Sometimes the language problems are getting in the way of the Restructuring since I’m having trouble figuring out what the developer was trying to say. A quick 30-minute session with another developer helped solve a lot of the clarity issues, so that I could concentrate on restructuring the information better.

All in all I spent about 4 days working on this document before delivering it back to the managing author. She’s actually going to add more content to it, however needed to have it “massaged” before she could really see what was going on. I look forward to finishing off this Developer Guide as it’ll go a long way to helping out the developers work with this new aspect of our system.