Archive for July, 2006

Second Thoughts?Second Thoughts?

Posted July 21st, 2006 by paul.
Category: Work | 1 Comment »

Am I totally and completely crazy? Have I lost all connection with reality?!?!

I quit my job yesterday!

It is starting to feel real. I was sent an exit survey from the corporation where I work, and the IT department sent me an e-mail notifying me of the procedures they are going through to remove my access from the network.

I really quit my job yesterday.

I’m leaving a position of safety and security and relative ease for a position of responsibility, more work, and less security. And what sounds even crazier to me right now is that I’m excited about it!

I really am. I think this new company presents me with a lot of really cool opportunities. I’ll be the lone writer in the entire company, and I’ll be responsible for all documentation from conception through delivery. I’ll get to hone my existing skills and develop some new ones. The company is a cool start-up-like company and has that start-up feel. They create software used for textual analysis of free-form text—a subject that I find fascinating. I like my manager, and liked all the people I met today when I turned in my acceptance letter.

Now I’m waffling between wondering if I can wait three weeks to start and freaking out because in three weeks my world is getting turned upside down, by my own choice!

No really, I’m excited about the opportunity, and am really looking forward to this new job. I have that nervous, excited feeling in the pit of my stomach. But everything is cool. This is the right thing for me right now. It is a good move personally. It is a great move professionally. It will be good for our family, and it is going to be a lot of fun.

So why am I so nervous?

Three weeks!!

And no, I’m not crazy. Not yet at least. Ask me in two and a half weeks. ;)

Moving onMoving on

Posted July 20th, 2006 by paul.
Category: Work | 1 Comment »

Here is a copy of the e-mail I sent to my manager, Mark, this morning:

Mark,

After much thought and consideration, I am writing to inform you of my decision to resign from my position at [company name] effective Friday August 11, 2006. I have been offered, and intend to accept, a position with [company name], a software company in Salt Lake.

I intend to take my scheduled vacation from July 24-28, and then work my final two weeks from July 31 through August 11 such that I can wrap-up as much as possible on my remaining projects.

Mark, I want to thank you for the opportunities you’ve given me [here]. It has been a wonderful ride, and I appreciate the confidence you’ve shown me as I came into my first full-time job out of college. I have learned so much from you and from this organization. I appreciate your support, example, and help in teaching me as I’ve worked in this position. Nothing short of a perfect professional opportunity could have lured me away from this team; however, this opportunity is too good to pass up. As we discussed this morning, this isn’t simply a matter of “more money”, but it is a chance for me to stretch my wings a bit and learn more about the trade in a way that I wouldn’t be able to do [here].

Thanks again for your support.

Paul Pehrson

A new approach to maintenanceA new approach to maintenance

Posted July 11th, 2006 by paul.
Category: Technical Writing | 1 Comment »

Today I read the following post on the Yokneam Forum of Technical Writers called “Marinated User Guide.” I thought it was funny and worth a read.

In defense of the color-blind userIn defense of the color-blind user

Posted July 3rd, 2006 by paul.
Category: Adobe FrameMaker, Technical Writing | 2 Comments »

I write this post in defense of the color-blind users of the world. First, let me give you some background.

I worked previously for a company that produced language learning software. A writer was added to my team, and after a couple of weeks of using the software, he complained that while doing a specific activity, he couldn’t tell that he had matched the items incorrectly. He asked me how he was to know that it was wrong. I explained that the big red “X” next to the item showed him that it was wrong. He indicated that he couldn’t see a red “X”, but that it was probably because he is colorblind.

Since then I’ve been much more aware of color-blind issues as I work with computer software and as I design documentation. Thus, when a question arose recently on the Techwr-L list regarding document design and color, I decided to chime in with my own response.

In case you didn’t read the threads, here is a summary. The original poster was talking about document design in Framemaker, and wondered if there are people that use blue text to indicate a link in their Frame documents. A couple of people responded to the thread and said that they do use blue text to indicate links. I thought it prudent to point out that for good document design you shouldn’t just use color to indicate that a span of text is a link. Problems include that users who are colorblind may not be able to differentiate the link, and users who print the documentation on a black and white printer won’t be able to tell that the text was a link.

My response was challenged by one of the users on the list who wanted to know why I care how a link is shown in a printed doc. After all, he asked, “Is there a way of clicking a link from a printed page?”

Besides thinking that the question was stupid, I was annoyed that my attempt to point out a principle of good design had been brushed off as if I were to dumb to contribute to the conversation. I decided to explain my comments further, which I did.

Here was my response:

Well, obviously they aren’t going to click a link from a printed page. Give me a little bit of credit here. As you can see from my answer, I was giving a general warning about using color; I wasn’t giving a specific response to obair81′s original question.

And in my own defense, the advice I gave is good general advice from a design perspective.

When you use only color to indicate that something is different about a particular string of text, then you run the risk of alienating part of your user audience. My first example dealt in general with the area of accessibility. Of particular concern are colorblind users who may have difficulty differentiating the color from the rest of the body of text. My second example dealt with the inherent inconsistencies in the way end users access our documentation. Some use it online and can follow links while others print the documentation to use as a reference.

If the user of the printed document can’t differentiate the subtle color shift to indicate that there is a link in the on-line version of the document, then your user will not benefit from the knowledge that additional information is readily available via a link in the electronic copy.

So in reference to your question, John, no I don’t expect a user to click on a link from a printed page. But I do think that I have a responsibility as a designer and writer to provide documentation via a method that doesn’t inherently alienate users who either have accessibility issues, or choose not to read the documentation on the screen.

In general, this is good advice. You’ll have to adapt it for your users based on what you know about them. If you know that you have non-colorblind users who will never print the documentation for any reason, then by all means, use color alone for your links. If you can’t guarantee this scenario, then you should at least be aware that your choices are limiting your documents usefulness to potential users.

I stand by my comments. When you are designing documentation, you should never use color as the sole indicator of some additional information without first considering the risks involved in alienating some portions of your audience.

After all, somebody has to stand up for our color blind friends out there!

(You’re welcome, Dave.)


Bad Behavior has blocked 538 access attempts in the last 7 days.