Top 10 Workspace Configurations for Technical Writers
Here's my list of the Top 10 Workspace Configurations for technical writers. (By "workspace configuration," I mean the characteristics of your work environment that make you most productive and happy.)
- Dual Monitors. Allows you to put the application you're documenting on one screen, your authoring tool on the other. No more scrunched windows or frustrations with constantly maximizing and minimizing your screens.
- Laptop with docking station. Gives you mobility of workspaces. For example, this morning the train stalled for 40 minutes, but I was working on my help file anyway. I don't even have a work desktop -- the laptop with docking station combo is perfect. It's like having both a desktop and laptop, but having their files always perfectly in sync.
- VPN connection. Essential for connecting to the Intranet from home to access the application you're documenting. Especially when you're trying to meet a tight deadline, VPN can help save your bacon as you work late into the night.
- Enterprise-integrated BlackBerry. My favorite new toy. Tonight I had a quick thought about improving the usability of an application while waiting for my wife to pick a movie at BlockBuster, so I thumbed an email msg to the PM and other team members. I've also just loaded my BlackBerry up with tech podcasts to listen to while I'm going to work. If I'm away from my computer for a while in meetings or at lunch, I won't experience that eerie feeling of disconnect.
- Open tool office policy. "Use the tools you're most comfortable with to produce the needed help materials." Freedom of tools is a writer's dream. It gives you more responsibility and ownership of your toolset, since you chose it and it wasn't forced upon you. It also allows you to author in the most comfortable environment for you.
- Google Talk as the IM Client. IM avoids the dozens of pointless messages you get daily that shouldn't be emails. IM is quick, and Google Talk is one of the best (and free).
- SharePoint 2007 platform for publishing help files. I set my publishing target in Flare to automatically push my help files to a SharePoint directory. Because it's SharePoint, I can update all help information on the fly, and I'm not restricted to the developers' code freeze and hardening deadlines. This removes a lot of pressure, and I know that if I later discover an error, or want to add more material, I can adjust the production help within seconds. April Update: After more experience using SharePoint as a file repository, I no longer recommend this method. SharePoint is not a stable platform. It's loading speed fluctuates, and if you have 20 MB videos, they don't load at all. SharePoint is like a Pinto for performance. You need a stable, robust server instead. Trust me on this one. Also, the anonymous access feature is also problematic. It can cause your entire server farm to crash.
- Proximity to project managers and project team members. As I said in a previous podcast, proximity to people with key project information is one of the best ways to get the information you need. If you're remotely located, or if your project team is scattered across different floors and department buildings, camaraderie and communication will go downhill. In contrast, proximity opens up the channels of communication.
- Open access to Pandora, Yahoo Music, or other online radio. Music helps me focus and blocks out random voices of people yakking away in the hall. I especially love Pandora because it's free and doesn't have audio commercials. It also loads almost immediately and begins playing.
- Ubiquitous wireless connectivity. A laptop's wireless capabilities can give you incredible freedom when your entire building has wireless access points on every floor, in every conference room. You can take your laptop to meetings and still be productive.
**Bonus configuration: A manager who reads your blog and who also blogs. This seemingly small gesture yields big returns in workplace rapport.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.