TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Alternative to typo? From:Joel <eleysium -at- gmail -dot- com> To:Geoff Hart <ghart -at- videotron -dot- ca> Date:Fri, 27 Mar 2009 09:14:24 -0400
Great points - thanks!
On Fri, Mar 27, 2009 at 9:12 AM, Geoff Hart <ghart -at- videotron -dot- ca> wrote:
> Joel wondered: <<For some reason I am having trouble coming up with an
> alternative to "typo." I have a sentence that says: "A typo in this command
> may render the unit unresponsive." Should I change it to, "a typographical
> error"? That sounds stuffy. "A mistake in typing..."? Something else?>>
>
> Strictly speaking, a typographical error would be choosing Times New Roman
> for any font designed to communicate with members of this list. <g> and
> <stitch> When in doubt, be direct: "If you type this command incorrectly,
> the unit may stop responding [to what: your inputs? to juidicious blows with
> a hammer?]."
>
> But there are two additional problems here. First and most important, why
> (in this day and age) would any sane engineer (if such a creature exists)
> allow this to happen? How hard is it to parse the commands first and refuse
> to perform such a dangerous command? Why is there no way to solve the
> problem? On the other hand, if there is a secret command that will cause it
> to begin responding again, revise the sentence as follows: "If you type this
> command incorrectly, you will need to type [reset command name] to reset the
> unit so it will again respond to [whatever]."
>
> Second, and no less important, "may" is unacceptably vague: if at all
> possible, make the SME tell you clearly and unequivocally when a typo will
> and will not cause this behavior, and clearly spell this out for the reader.
>
> ------------------------------------------------------------------------
> Geoff Hart (www.geoff-hart.com)
> ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
> ------------------------------------------------------------------------
> Effective Onscreen Editing:
>http://www.geoff-hart.com/books/eoe/onscreen-book.htm
> ------------------------------------------------------------------------
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-