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.
Ashaki Hamlett wondered: <<The hiring manager stated she wanted to
verify my friend's competency using Office, therefore, she requested
writing samples of technical documentation using Microsoft Excel. Does
anyone have any suggestions or experience creating technical
documentation using Excel?>>
Although it's most likely that the interviewer simply screwed up (not
enough coffee) and said "Excel" when they meant "Word", this isn't the
only reasonable explanation.
Many people (including my former employer) use Excel to rapidly create
and distribute decision-support software in the form of worksheets. The
quite reasonable rationale for this is that it's faster, easier, and
often more accurate than going through the full development cycle using
a programming language such as Delphi, particularly when most of the
functionality you need is already built into Excel and (at least in
theory) adequately debugged.
In this context, the documentation comes in three forms: the Good, the
Bad, and the Really Ugly. The "good" is embedded help: instructions
provided directly in the spreadsheet cells, in headings, in field
descriptions, and so on. When intelligently designed, this integration
of help with the interface (rather than in an external file) is very
effective. The "bad" is an external help file linked to the Excel
spreadsheet; I call it "bad" because it's not likely to be context
sensitive unless the spreadsheet developer goes to heroic lengthst to
make it so, and in any event, external help will always be less
effective than good embedded help.
The "really ugly" is when the help is made contextual by using Excel's
"insert comment" feature to attach a comment to various cells in the
spreadsheet. Although this does provide context-sensitive help, the
presence of the comments is denoted only by a tiny, scarcely visible
arrow at the right edge of the cell that hints (to the eagle-eyed
spreadsheet user who knows that this feature exists) that a comment is
present. In my experience (editing the comments), the comments are easy
to miss, hard to click on when you want to display the comment, and
generally poorly integrated with the surrounding interface. Zooming in
on the spreadsheet makes the comments more usable, but you still have
to educate users of their existence--few people realize that they
exist, just as some computer users still don't know of the existence of
online help or how to use it.
--Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
