UNIX and Linux. Believe it or not, they’re everywhere. And no where more so than in the software development world. If you haven’t already encountered either of them at work, chances are you will. And you’ll probably need to document something (or several somethings) at the command line.
I can’t think of a technical communicator who isn’t comfortable working within a GUI. But not everyone is comfortable, or even has any experience, at the command line. The command line isn’t as daunting as some people think it is. In fact, you can get up to speed quite quickly. It’s just a matter of how.
Yes, that Seth Earley. If you’re in the Toronto area, you might not want to miss this one. On May 5 at 7:00 PM, Seth Earley will be talking about using taxonomies to improve search. The session:
covers a variety of ways that you can integrate and fully leverage large public taxonomies as well as apply small controlled vocabularies in search applications and search systems.
You can learn more about the talk here. To attend, you’ll have to join the Knowledge Workers Toronto Meetup group (which is free. Note that there is a $15 fee for the session, and you can pay by PayPal.
Unfortunately, I won’t be there. It’s my daughter’s birthday and my choices are to hear Seth Earley speak or to live. I chose the latter … If I can find links to one or more posts about this session, I’ll put them in this space.
advised hiring managers to pay attention to the candidate’s approach to professional development, to look for candidates who identify with the profession outside the nine-to-five day.
Read the post to get a full picture.
This creates an interesting conundrum. I believe in being passionate about what you do, and think that there’s more than just a little truth to this quote:
You know who you are. It comes down to a simple gut check: You either love what you do or you don’t. Period.
– P. Bronson
But I don’t believe that tech comm (or any other career) should take up your entire life or subsume your identity. You can read more about my thoughts on this here.
In this space and elsewhere, Aaron and I tell people to take what they do seriously but not to take themselves seriously. Living, eating, breathing, dreaming, thinking, and whatever else technical communications (or any other job) is … well, it’s not a good thing. It makes someone very one dimensional, and I’m not sure I’d want to work with or hire someone like that.
I’ve worked with a few people who wrapped their identity in their careers, and they really had nothing else outside of that. No real life, few (if any) close relationships, and a lack of personality in some cases. In order to be effective at what you do, you need to step back from what you’re doing for a living. You need to take a break, and let the part of your mind that deals with your career go fallow. Even for a few hours.
And I hate to imagine what happens to those types of people when their careers don’t work out. Or, if during tough times, they lose their jobs and can’t get another one. A mind and a personal life are truly terrible things to waste.
Thoughts? Feel free to leave a comment.
Last Sunday, Tom Johnson tweeted an interesting question: What’s your biggest tip for documentation usability? Seeing as how I was deep in writing a bunch of things, I didn’t see that until late in the day. By then, a few people replied.
Looking at those replies, I thought Yeah, that’s what I would have said. In fact, those answers — especially that documentation should about specific tasks that users want to carry out — mesh well with the documentation philosophy that Aaron and I try to follow. And which we looked at in our presentation at DocTrain West 2009.
Then, I thought back to the presentation and another answer to that question came to mind. That answer:
Remove any material that disrupts the main flow of the documentation, and then give them quick, easy access to it
Therein lies the problem, though. Where do you put that information, and how do you give users access to it? Aaron and I usually advocate:
- Using popups or mouseovers to define terms or present extra background information
- Put the information somewhere else, like a supplementary help file, or on a wiki or a blog
That works well if you’re delivering documentation in electronic format — over the Web or as a PDF. But what about printed manuals? Believe it or not, there are more than just a few shops that still deliver documentation as dead trees.
So, what’s the solution? There really isn’t one. Aaron and I sometimes suggest putting all of the overview information upfront. Then, use cross references in the chapters that cover the actual procedures. Unfortunately, though, this doesn’t always work. We’ve found that in a few instances, we’ve had to go back to doing things the way they were done in the past in order for a printed manual to properly flow. Thankfully, not often. But often enough.
Do you work with documentation that will be primarily delivered in print? If so, what’s your biggest usability challenge? Feel free to leave a comment.
While I’ve been using mobile devices for over a decade, I’ve been seriously pondering the interfaces of such devices since I broke down and got a BlackBerry.
I’ve seen some good. I’ve seen much bad. I don’t know what the situation is like on other mobile devices, but on the BlackBerry the interfaces for many applications have a number of similarities. They share some good points, and some bad.
While I don’t think the perfect interface is beast that exists, there are good interfaces that work around any issues there are with the displays on mobile devices.