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.
Well, a battery is one solution, sure (works for my PC, after all). But, why
cannot the VCR interpret a time signal from the cable company, or wherever,
and update itself automatically once per month? Such a feature would relieve
much of the documentation about changing the time.
Anyway, I argue that people don't set the time on their VCRs because they
have no need to. They use other clocks to figure out what the time is and,
obviously, they don't bother recording televisions programmes on a schedule.
(For example, I don't record tv that I miss. I just miss it. It's only tv,
after all. If it's important, like tonight's Florida versus Miami bowl game,
I'll be there with the chips and beer . . ..)
It's not an issue of documentation, or ease of use. It's about a feature
that many people have no need for--even if they think they do at the point
> -----Original Message-----
> From: Sandy Harris [SMTP:sandy -at- storm -dot- ca]
> > Take the prime example -- VCRs. It's become a joke -- everyone's VCR
> > blinks 12:00 (well, 1:00 during daylight savings time! <g>). Are we, as
> > a country, really all that stupid? I don't think so. But some of the VCR
> > UIs I've seen are abominable.
> I don't think the blinking 12:00 is either a UI or a documentation issue.
> The obvious fix is to put a small rechargable battery and a charging
> in the device. Then it would retain the time, and other info like station
> presets, through a power outage.
> "If carpenters built houses the way programmers build programs, the
> first woodpecker to come along could destroy civilisation."
> An interesting question is what we should do when the product we're
> supposed to document brings those woodpeckers to mind.
> (Apart from getting the resume ready, of course.)
You could log the bug, find the workaround, and document the workaround. If
you are printing 6 billion books from an offset press, documenting the bug
is kind of permanent <vbg>. However, if you document only or primarily for
online delivery, help and PDF that can be updated by a download or as part
of a patch, then you are really helping out. You could always, of course,
provide a hidden (Easter egg) pop-up with a picture, home phone, work phone,
cell phone, pager number, of the SME responsible for not considering the
woodpecker . . ..
Sponsored by an
anonymous satisfied subscriber since 1994.
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.