Many TR members have been e-mailing and posting to discussions about our series of Outlook articles. By far, the hot topic has been HTML and Rich Text vs. the plain text e-mail format. In Joys and pitfalls: Teaching beginning Outlook, I suggested that trainers talk with system administrators before teaching students about stationery, HTML mail, and other space gluttons (or memory pigs). I reiterated that suggestion in Outlook training: E-mail formats and signatures. The following comments go a long way toward bolstering that point.
Captkirkdmzreally can’t stand graphics in his e-mail.
“Abomination: HTML and Rich Text e-mail are abominations. Anyone who uses either one is asking for me to ignore them. Just my 2 cents!”
Sleppert warns that enhancing your e-mails with “cool” stationery and formatting your text with color is often a waste of time and causes more grief than good.
“… keep in mind that the recipient may not see what you see! Many e-mail systems do not see anything except plain text. We recently tested this option by sending a formatted e-mail using Outlook 2000 via Exchange 5.5 to a system using Outlook 2000 and Exchange 5.5. The recipient did not see any of the formatting—the e-mail was in plain text. In addition, stationery with graphics makes the messages larger and could lead to slowing down the system.”
Playing the blame game
Trmcdougle thinks TechRepublic shouldn’t post articles that spread the word that these options even exist! Nevertheless, his comments are a true taste of the strong feelings some harbor about the value of such “features.”
“Following these suggestions you can easily turn a 30 word e-mail that should weigh in at less than 0.5 KB into a 32 KB message. And then find that the receiver cannot read it anyway! Please be more responsible in your articles. Bells and whistles are not like mountains, ‘Because it’s there,’ is not a suitable reason.”
I’d bet my bottom dollar that Trmcdougle isn’t a trainer. If he were, he would know that most trainers have their outlines or course objectives dictated by the person paying for the training. Just as often, the person setting up and paying for the training hasn’t consulted with her IT department about what the training should comprise.
The customer is always right
That’s where trainers can bridge this gap between good intentions and reality—by asking the right questions. Sometimes there are legitimate reasons for your students to learn about these options. If there is, go in and knock their socks off. If there isn’t a reason and you open your customer’s eyes to a potential problem, you’re the hero. It’s a win-win situation if you take the time to ask.
Mdeans wrote to us about an experience with these features you love to hate:
“Outlook E-mail Options: As a trainer, I love showing cool tips and tricks like this. However, I found that the organization I was training for was not too happy about this. It does cause issues with people accessing Outlook messages through the Internet with Outlook Web Access. Trainers need to be aware of internal policies regarding some of the bells & whistles.”
What are your favorite features of Outlook 2000? What features do you find useless and inane? What have been your most requested objectives to be included in your Outlook training? Write and tell us about it or post your comments.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays