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:Glossary functions and features in elearning? From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 30 Jan 2002 08:49:47 -0500
Brad Jensen is <<... an elearning vendor, and we are about to put a glossary
function in our Eufrates coruse module maker. The way I see this happening,
is from the text page, you can highlight a word or phrase, and create a
defintion using rich text. Words/phrase and definitions are uploaded to the
Eufrates server. Then as modules are added or updated, the server parses all
module text, creating a link for every word or phrase that appears in the
glossary. It also parses itself, creating links for words in glossary
definitions that are also in the glossary.>>
Sounds like an interesting technology, and isn't it nice that you're taking
the time to consult with people who might end up using it? Wish more
companies were that way. One thing that wasn't clear about the methodology
was whether the software rescans pages that are already in the database if a
new word is added; I'd assume so, but it's worth checking.
<<1. Are there any favorite/semistandard colors for such links?>>
If possible, use "browser defaults"; in HTML projects, blue underlining
seems pretty common for hyperlinks and solid blue (no underline) for popups,
but in good old WinHelp, glossary links were often emphasized with a broken
underline (in green, if memory serves). If the user has changed these
settings, it's probably not great to override those preferences.
<<2. what would you do if such a word (dogwood) is inside an html link
(innertext)>>
To avoid confusion, you shouldn't link to words within links; you should
distinguish between words intended to be read (which you can link to the
glossary) and words intended to be used without (in many cases) ever reading
them. Among other things, I'll guarantee you that at some point, you'll run
into a technology conflict with some future browser that causes glossary
links within a hyperlink to prevent the hyperlink from functioning. Best to
avoid this problem by sticking with standard linking technologies for now.
<<what do you love and hate about the glossary definers you have in other
products now?>>
An overzealous author can easily create a page that looks like it was
typeset by an enthusiastic 6-year-old with a leaky fountain pen. My
preference for glossary links is to have them unobtrusive, and though I
don't recommend this without considerable consultation with your real
audience, one thing I would personally prefer is that glossary links remain
invisible until I hold the mouse cursor over the word. I'm dubious about the
usability of this approach*, which is why I recommend testing, but speaking
as someone with a large vocabulary who wants to read without all the lines
getting in the way, this is one possible consideration. My personal
preference in designing help systems is to make the glossary available at
all times via a glossary button or link, and dispense with in-text popups.
This seems to be more obvious to users and avoids cluttering the help topics
with all these annoying links. A hybrid approach might be the following: let
users select a word with the mouse, then click on a prominently visible Word
Definition button to jump to that word in the glossary, with a polite
"sorry, not in our glossary" note if the word isn't in the glossary.
* Many users will never know that the glossary exists if you work this way.
<<I'm wondering if an automated tool to convert, says Robohlep, would be a
winner.>>
The biggest barrier to any new product is compatibility with existing
products. Since RoboHelp is the Microsoft of online help (and I don't say
that with purely positive intent), you can only help your prospects by
making your product work with the defacto industry standard. The easier it
is for users to convert their projects into your technology, the more of
them will be tempted to do so.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"Any sufficiently advanced technology is indistinguishable from a
personality, and an obnoxious one at that."-Kim Roper
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Attention ForeHelp and Doc-to-Help Users! Upgrade your existing product to
RoboHelp for only $299, through January 31st. RoboHelp can import your
existing Help projects! Learn how else RoboHelp can benefit you. www.ehelp.com/techwr
---
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.