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.
Tim Altom wrote:
> Imagine a newbie picking among those dozens or hundreds
> of topics, searching for the right one. Now, a seasoned
> pro might use the search string "account, setting up" and
> get a few topics. But few users are so sophisticated.
Tony Ioven added:
> are you giving enough credit to your "lowest-denominator"
> audience? I don't think a user needs to be a terribly
> sophisticated to define a focused search. I guess I don't see
> it as the burden you describe.
I include search in the training. I provide full text
search with all the Boolean operators (and variations thereof).
I include proximity searches and frequency count. Results
are on the fly, so you don't have to enter a new search
argument to refine the results. I provide for naming and
saving search results as well. I emphasize that the search
results are only as good as *you* the user are at preparing
the search criteria. This is a very important part of the
training. Sometimes we even have fun proving the software
functions as described.
Richard Mateosian wrote:
> Application developers have the option of compiling and shipping
> the resulting LARGE file. It could easily mean added expense for
> systems that ship on diskette. Every user would than have to deal
> with that file, whether they plan to use full-text searches or not.
All true, but I am working with a large information database
that is growing every day. I can't imagine putting it in the
field without the full text search.
Tim Altom wrote:
> Another thing that bothers me about full text searches is that
> it gives the writer a graceless way out of designing a good
> keyword index, which demands a good and thoughtful
> consideration of the user's needs.
How many keyword indexes have you used that were prepared
with *thoughtful consideration of the user's needs?* If
you, the writer, need to prepare a perfect keyword index,
then by all means, go for it. But, don't take away my
full text boolean search (assuming DASD is cheap). I need
it, I use it, I am comfortable with it, and I want it. I
am the user, and you irritate me when you take away my
good and useful tool.
Bonni Graham wrote:
> I prefer to include both searching techniques -- I feel that
> the more entry points you provide for users the more likely
> those users are to find the information they require.
I think Bill Horton said, "the more navigational tools,
the better." I agree with Bill--somewhat, provided the
tools don't make it too easy to enter hyperspace.
scot -at- hci -dot- com -dot- au wrote:
> I have to agree with you Tim. Full text seraches are not
> nearly as helpful as a proper Index, but they are easier
> for the writer to implement (so maybe its not "user-centric"
> at all).
I disagree for all the reasons I gave. Perhaps the
difference is the size and structure of the database.
NOTE: I do use a keyword index. I use it for the help
files for the online software. The difference is the use,
and it's a BIG IMPORTANT DIFFERENCE. For online
information retrieval, not online help, and not an online
manual, you need the full text search with all the bells
flahertj -at- smtpgw -dot- liebert -dot- com