Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

50%
+0 −0
Q&A Should creativity or eloquence in a technical document be removed during review?

This is a supplement to this answer. Readers, especially technical readers, notice small variations and especially inconsistencies. If you talk about "removing" a resource in one place and "delet...

posted 6y ago by Monica Cellio‭  ·  last activity 5y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T08:31:23Z (almost 5 years ago)
Source: https://writers.stackexchange.com/a/35031
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by (deleted user) · 2019-12-08T08:31:23Z (almost 5 years ago)
This is a supplement to [this answer](https://writing.stackexchange.com/a/35019/1993).

Readers, especially technical readers, notice small variations and especially inconsistencies. If you talk about "removing" a resource in one place and "deleting" it in another, some _but not all_ readers will think that's two different operations. This problem is amplified if your documentation is translated into other languages, because now both the translator _and_ the reader have to interpret your subtle variations.

You can minimize this confusion by consistently using the nouns and verbs already in use in your documentation set. (When something _is_ different from a similar-seeming one, call it out explicitly.)

This does not mean that there is never room for humor or even whimsy in technical documentation. _If it is not unusual in your domain_, you can sometimes be more creative with your examples. Never do this at the cost of clarity, but, for example, you can do this if you need to show some sort of user workspace and the actual content doesn't matter. If you're showing how to lay out a circuit board and your audience is expected to be geeky, it's not wrong to name the project in the screenshot NCC-1701-replicator instead of circuit-2. But don't do it if there are 500 examples in the documentation and you're just changing this one; be consistent in your style throughout the documentation set. I've found that "whimsical" examples are best reserved for shorter, less-formal, stand-alone documents like blog posts and use-case descriptions.

#1: Imported from external source by user avatar System‭ · 2018-04-12T16:18:29Z (over 6 years ago)
Original score: 5