One of the most mind numbing things to do as a technical writer or information developer or executive information producer is to fix something that’s broken. Try this tag. Nope, that didn’t fix it. Try that code. Nope, didn’t fix it.
But sometimes you have to do it to fix what went wrong. A bullet in an unordered list starting in the middle of the page. Strange characters (on the page, too, not just asking for unusual things).
Somewhere in there, we throw our hands up and say, “Enough!” We implement standards. We go through templates, line by line, not just to make them look alike, but act alike. Then, when someday we have to change all the instances of “calulator” to “calculation device of DOOM”, it’s easy.
You do not get your blue text. Deal. Er, I mean:
Thanks so much for your email. While we appreciate the effort you’ve put into your suggestion, it would fail against the rules our system has in place to validate the code of the documents we publish.
I’m afraid we cannot honor your request to make your tips blue.
Which is good when you’re in a position of some power; not necessarily in level at a company, but in showing your competency and your reasoning – you don’t hate the color blue, you may or may not think the suggestion is completely useless or ridiculous, or that the person suggesting it should stick to his or her own knitting, but you have to usually say so and why.
But sometimes, I find, it’s also good to not have to be the one to say “We aren’t going to break our rules for you,” but it’s helpful to know how.
Post a Comment