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:RE: When is it too much information? From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:Debbie Hemstreet <D_Hemstreet -at- rambam -dot- health -dot- gov -dot- il>, Ryan Young <ryangyoung -at- gmail -dot- com>, Ryan Pollack <ryan -at- clicksecurity -dot- com> Date:Wed, 20 Feb 2013 10:55:00 -0500
I agree, in this case, because it seems that the very specific feature (an option at a particular menu location) was not just deprecated - meaning it would still be right where you expect it, but its use would be discouraged, pending future removal. Rather, it was removed.
Doesn't matter if the functionality is available elsewhere in the interface. If what you could do before is gone, then it's not really "deprecated".
Tell it like it is.
It's moved.
It's gone.
I don't know that I've seen "deprecated" used with GUI stuff.
In my mind, it applies to command-line or code options that still exist, but that have new, improved, better, stronger, faster, nicer-smelling replacements now available.
-----Original Message-----
From: techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Debbie Hemstreet
Sent: February-20-13 2:37 AM
To: Ryan Young; Ryan Pollack
Cc: tech2wr-l
Subject: RE: When is it too much information?
Except why make the user have to think by using the term "Depracated" Why not "Deleted Features" or "Removed Features"?
Debbie
דבורה
_____________________
Deborah Hemstreet
English Editor
Rambam Health Care Campus
Ext. 1285
Tel. 04 854-1285
Mobile: 050.206.1273
Fax: 04 854-2657
From: Ryan Young [mailto:ryangyoung -at- gmail -dot- com]
Sent: Tuesday, 19 February, 2013 19:07 PM
To: Ryan Pollack
Cc: Debbie Hemstreet; tech2wr-l
Subject: Re: When is it too much information?
The release notes at my new position have a section called "Deprecated Features" as well as a section called "Changed Functionality." I feel like that's not a bad idea. Seems like it would address situations like the one described in the original post.
On Tue, Feb 19, 2013 at 6:57 AM, Ryan Pollack <ryan -at- clicksecurity -dot- com<mailto:ryan -at- clicksecurity -dot- com>> wrote:
Ah, that is a really good idea. I second that! I do something similar in my release notes. I have these sections:
- New
- a
- b
- c
- Changed
- d
- e
- f
- Fixed
- g
- h
- i
- Known Issues
- j
- k
- l
On Tue, Feb 19, 2013 at 12:36 AM, Debbie Hemstreet < D_Hemstreet -at- rambam -dot- health -dot- gov -dot- il<mailto:D_Hemstreet -at- rambam -dot- health -dot- gov -dot- il>> wrote:
> I think you can best solve this problem by having a section:
>
> Deleted features:
>
> XXX information is no longer displayed in XXX location. The same
> information can be found XXXX.
>
> In the release notes I write for one of my clients we go for redundancy.
> Hence, for the above example, under NEW features, we would also have:
>
> XXX information is now accessible only via XXXX (and not in XXX location).
>
> So the user sees where to get the information but also knows that it
> is no longer displayed in a certain spot. If a user was relying on the
> displayed information, there will be a support call to find out where
> the heck the information went to and how do I get it now.
>
> If there is no way to get the information that is no longer displayed
> -- bad move on the developers part and you need to point this out.
>
> Hope this contributes to the discussion
>
> Deborah
>
>
> -----Original Message-----
> From: techwr-l-bounces+d_hemstreet=rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com<mailto:rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com>[mailto:
> techwr-l-bounces+d_hemstreet=rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com<m
> techwr-l-bounces+ailto:rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com>] On
> Behalf Of yehoshua paul
> Sent: Monday, 18 February, 2013 17:07 PM
> To: tech2wr-l
> Subject: When is it too much information?
>
> While reviewing the latest release notes that my company sends out
> every couple of weeks, one of the support guys suggested that I add
> the following words (or something similar) to one of the change
> descriptions: "The user does not need to do anything." What changed is
> information that was displayed in one area of the UI is no longer
> displayed. The support guy thought the users might think they need to
> do something, now that they no longer see this information.
>
> I told him, if the users needed to do something, I would write this in
> the release notes like I did with some of the other changes, and
> include the relevant steps, or the appropriate reference to the online
> help. If I didn't write anything, why would the users think they need to do something?
> His argument was that it doesn't hurt to add the sentence, and it may
> prevent confused customers from calling customer support.
>
> What do you guys think? Would adding a superfluous sentence (in my
> opinion) help or hinder users.
>
> Yehoshua
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EPUB Webinar: Join STC Vice President Nicky Bleiel as she discusses tips for creating EPUB, the file format used for e-readers, tablets, smartphones, and more.
