7 Common Grammar Myths You’ll Never Fall For Again

GrammarMyths

Source: Lindsay Kolowich, HubSpot

Spelling and grammar matter. Consistently correct grammar makes content more credible, and could impact its presentation. But there’s a lot of conflicting advice about what things are (and aren’t) grammatically correct. Here are seven common grammar myths.

Myth #1: You shouldn’t end a sentence with a preposition.

Ending a sentence with a preposition is not a grammatical error.

For example: “Bob has a lot to be happy about.” This sounds worse: “Bob has a lot about which to be happy.”

Although the revised version is technically and more formally correct, it sounds stiff and unnatural.

So, go with whichever sounds better.

Myth #2: You shouldn’t split infinitives.

An infinitive is a verb in its most basic form: “to walk,” “to see,” “to eat,” etc. To break an infinitive means to put a word or several words in between “to” and the verb itself — as in, “to automatically update an account.”

There’s actually nothing grammatically incorrect about splitting infinitives. The only reason you wouldn’t want to do this is if the resulting sentence just didn’t sound right.

Myth #3: “i.e.” and “e.g.” mean the same thing.

If you struggle with remembering which is which, here’s what’s up: “i.e.” means “that is” or “in other words,” and “e.g.” means “example given” or “for example.”

Myth #4: “–” and “—” are totally different.

Both “–” and “—” are versions of the dash: “–” is the en dash, and “—” or “–” are both versions of the em dash. You can use either the en dash or the em dash to signify a break in a sentence or set off parenthetical statements.

The en dash, not the em dash, can also be used to represent time spans or differentiation (e.g., “that will take 5–10 minutes” and “we crossed the Spanish-French border”). The em dash, not the en dash, can be used to set off quotation sources (e.g., “‘To be or not to be, that is the question.’ —Shakespeare”).

Myth #5: You use “a” before words that start with consonants, and “an” before words that start with vowels.

You use “a” before words that start with consonant sounds, and “an” before words that start with vowel sounds. For example, it’s correct to write “I have an RSS feed” but incorrect to write “I have a RSS feed.” When in doubt, sound the sentence out in your head.

Myth #6: “Irregardless” is not a word.

Yes, it is a word. And it means “regardless.” Someone even wrote an entire article about it in the Huffington Post.

But even though it’s technically a word, you may not want to use it. Some people still frown upon it, so you may not want to use it in your content.

Myth #7: You can’t start sentences with “and,” “but,” or “or.”

Often, the choice is stylistic. If the sentence reads better, keep the conjunction. If it functions just as well without the conjunction, or if you can connect it to the previous sentence without compromising readability, then reconsider using it.

 

 

Does Topic-Based Authoring Help Readers As Much As It Does Writers?

topics2

*Due to web issues, we lost information on who authored this piece.  If this is your work, please let us know and we will give you publishing credit.*

Many large companies have adopted a modular, topic-based approach to technical documentation. This is mainly because content can be reused in various ways from a single source, preventing multiple versions of the same information. This approach helps writers publish the same information in different combinations to different media (for example, mobile devices and TV screens).

Does topic-based authoring also help readers? In a number of ways, it does.

Structured content helps readers because the format and approach are consistent, therefore it is easier to use and understand, even when it is accessed from an index or search.

Standalone topics are based on their content type: tasks, concepts, and references. For example, tasks provide the steps necessary to perform a specific goal; concepts provide a way to understand how that goal fits into a larger scheme of information; and references often provide alphabetical lists in tables, such as a command options list.

Separating descriptive information from task-oriented information helps readers access only what’s relevant to them. Topics provide just enough detail for readers to understand the content contained in each one without having to look somewhere else.

Linking related topics is an important part of modular documentation. Links help readers navigate, and the information they find will be exactly the type of information they need. If different topics are written by different authors, readers should still be able to navigate efficiently through the content to find what they’re looking for. For example, task topics almost always have related concept topics, reference topics are referred to by multiple concept topics.

Mark Baker, who writes about developing task-oriented, topic-based content in his blog Every Page Is Page One, points out that “breaking down content into small structured units is a good way to improve consistency and productivity.” Topics help readers, he says, when they include context and links. “Context can be a sentence or two that helps readers figure out what the topic is about and how it relates to other topics, for example, what it covers, what release it applies to, and what type of information it is (task, concept, or reference).”

So perhaps the answer is that what helps writers also helps readers.

Have something to add? Please share it in the comments.

Technical Writing Tools: Help Authoring

HelpButton

*Due to web issues, we lost information on who authored this piece.  If this is your work, please let us know and we will give you publishing credit.*

The most common reason for a user to look at an online help file is to find an answer to a specific question. The most important aspect of a help file is accessibility of the information it contains. Help files range from small, simple “read-me” files with very limited information to hypertext-based documentation.

First Steps

  • Identify topics: Help files are designed to work in conjunction with other types of documentation to form a complete information package. It is the task of the developer or technical writers to identify the help file topics. The best way to do this is to analyze the product. Then, once you have identified all of the topics, separate them into related groups.
  • Create a structure: Once you have identified the topics, you can start structuring the help file. Although the structure can depend on the software, the main purpose of the help file is to provide quick access to specific information. You can achieve this goal by using a simple content tree and keywords to build the help file index. Typically, the content tree should not exceed three nesting levels, although you can use two levels for small files that contain short topics and sub-topics.
  • Design: Design a structure that does not change often, even if information for a specific topic changes. Create a modular and flexible help file that can be used for the next version of the software. The HTML file names should remain stable. If the help tool allows it, it would be good to have a method of differentiating the various HTML files of the same name.

Creating a Help File

  • Access: A help file is not read in the order it is written, so make sure the most important information is accessible from accessing it in multiple ways. For example, the introduction page might never be read, while other information might be accessed by the index directly without the use of the content tree. If a specific topic is discussed in another part of the file, create a link to help users access the related page.
  • Content: The most important part of a help file is its text content. Even if you use graphics and formatting to make a point, the help file will be ineffective if the text is limited.
  • Hypertext: Provide links for users who are interested in knowing more about a specific topic. The most important rule is to make sure the links are actually relevant and useful. With this in mind, it is probably better to use too few links than too many.
  • Keywords: Prepare a list of keywords that are related to the specific HTML pages of the help file. Some users like to browse through the content tree, but others go directly to the index to find the topic by keyword.
  • Size: It’s not a good idea to create a smaller file by limiting the information included in it. A help file should contain everything necessary to use the software and solve simple, typical problems. This means the size of the files can vary from very small to 15 MB and more.

Have something to add? Please share it in the comments.