We write and build apps with a person-first perspective. Being aware of the impact of your language is one way for us to live out our [values](values).
Some people will read every word you write. Others will just scan. Help everyone by grouping related ideas together and using descriptive headers and subheaders.
Focus your message, and create a hierarchy of information. Lead with the main point or the most important content.
* Use active voice and positive language.
* Use short words and sentences.
* Avoid unnecessary modifiers.
* Use specific examples.
* Avoid vague language.
* Be consistent. Adhere to the copy patterns and style points outlined in this guide.
* Use the serial comma. Otherwise, use common sense. (Also known as the Oxford comma, it helps clarify when items in a list of three, four, or more things are their own items.)
Many of these repeat or reinforce George Orwell's six rules from his essay "Politics and the English Language" (1946), and it is worth keeping all of them in mind, especially the last:
> (i) Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
> (ii) Never use a long word where a short one will do.
> (iii) If it is possible to cut a word out, always cut it out.
> (iv) Never use the passive where you can use the active.
* Create a hierarchy, with the most important information first.
Place similar topics in the same paragraph, and clearly separate different topics with headings.
* Use plain language. Write short sentences and familiar words.
* Links should provide information on the associated action or destination. Avoid saying “click here” or “learn more.”
* Avoid using images when descriptive text will do.
* Avoid directional instructions or language that requires the reader to see the layout or design of the page.
* Label inputs on forms with clear names and use appropriate tags. Think carefully about what fields are necessary, and especially which ones you mark as required.
* Write briefly, but do not sacrifice clarity for brevity. You may need to repeat or add words to make the meaning of your sentences clear to a translator.
* **Authentic**. Write about what you are passionate about.
* **Useful**. Before you start writing, ask yourself: What purpose does this serve? Who is going to read it? What do they need to know?
* **Appropriate**. Write in a way that suits the situation. Just like you do in face-to-face conversations, adapt your tone depending on who you’re writing to and what you’re writing about.
## Voice and Tone
One way we write empowering content is by being aware of our voice and our tone.
What’s the difference between voice and tone? Think of it this way: You have the same voice all the time, but your tone changes. You might use one tone when you are out to dinner with your closest friends, and a different tone when you are in a meeting with your boss.
Your tone also changes depending on the emotional state of the person you’re addressing. You wouldn’t want to use the same tone of voice with someone who’s scared or upset as you would with someone who’s laughing.
The same is true for Agaric. Our voice doesn’t change much from day to day, but our tone changes all the time.
Agaric’s tone is usually informal, but it’s always more important to be clear than entertaining. When you’re writing, consider the reader’s state of mind. Are they curious about a post on our blog? Are they distrustful after being burned by a previous vendor? Are they excited to be engaging in a redesign? Once you have an idea of their emotional state, you can adjust your tone accordingly.
Agaric has a sense of humor, so feel free to be funny when it is appropriate and when it comes naturally to you. If in any doubt, do not make the joke. Generally avoid humor in written communication to clients.
We write the same way we build software: with a person-first perspective. Whether you’re writing for an internal or external audience, it is important to write for and about other people in a way that’s compassionate, inclusive, and respectful. Being aware of the impact of your language will help make Agaric a better place to work and a better steward of our values in the world. In this section we will lay out some guidelines for writing about people with compassion, and share some resources for further learning.
Don’t refer to a person’s ability unless it’s relevant to what you’re writing. If you need to mention it, use language that emphasizes the person first: ”she has a disability” rather than “she is disabled.” When writing about a person with disabilities, do not use the words “suffer,” “victim,” or “handicapped.” “Handicapped parking” is OK. Avoid using ableist language whenever possible.
If a reference to a person’s medical condition is warranted, emphasize the person first. Don’t call a person with a medical condition a “victim.” Instead, use "patient.""
Don’t refer to a person’s mental or cognitive condition unless it’s relevant to what you’re writing. Never assume that someone has a medical, mental, or cognitive condition.
Don’t describe a person as “mentally ill.” If a reference to a person’s mental or cognitive condition is warranted, use the same rules as writing about abilities or medical conditions and emphasize the person first.
Adhering to certain rules of grammar and mechanics helps us keep our writing clear and consistent. This section will lay out our house style, which applies to all of our content unless otherwise noted in this guide. (We cover a lot of ground in this section—the search feature will help if you are looking for something in particular.)
Write for all readers. Some people will read every word you write. Others will just skim. Help everyone read better by grouping related ideas together and using descriptive headers and subheaders.
Focus your message. Create a hierarchy of information. Lead with the main point or the most important content, in sentences, paragraphs, sections, and pages.
Be concise. Use short words and sentences. Avoid unnecessary modifiers.
If there’s a chance your reader won’t recognize an abbreviation or acronym, spell it out the first time you mention it. Then use the short version for all other references. If the abbreviation isn’t clearly related to the full version, specify in parentheses.
If the abbreviation or acronym is well known to your full intended audience, like API or HTML in technical documentation, use it instead (and do not worry about spelling it out).
We use a few different forms of capitalization. Title case capitalizes the first letter of every word except articles, prepositions, and conjunctions. We use title case for the titles of pages, including blog posts and basic pages.
Sentence case capitalizes the first letter of the first word.
When writing out an email address or website URL, use all lowercase.
They are bad! Even though they may give your writing an informal feel, they provide difficulty for readers that donnot speak English. You can surely make your email look informal without the use of contractions.
Emoji are a fun way to add humor and visual interest to your writing, but use them infrequently and deliberately. Keep them out of blog posts and web copy entirely.
#### Numbers
Spell out a number when it begins a sentence or is under ten. Ten to twenty is a judgement call (but usually spelled out if not paired with numerals). Otherwise, use the numeral. This includes ordinals, too.
We hosted a group of 8th graders who are learning to code.
(Sometimes it feels weird to use "1" instead of "one." Just go with your gut.)
Numbers over 3 digits get commas:
999
1,000
150,000
Write out big numbers in full. Abbreviate them if there are space restraints, as in a tweet or a chart: 1k, 150k.
#### Dates
Generally, spell out the day of the week and the month. Abbreviate only if space is an issue in the app.
Saturday, January 24
Sat., Jan. 24
#### Decimals and fractions
Spell out fractions.
Yes: two-thirds
No: 2/3
Best: ⅔
Use decimal points when a number can’t be easily written out as a fraction, like 1.375 or 47.2.
#### Percentages
This depends on context - use the % symbol or spell out "percent" depending on which looks best.
#### Ranges and spans
Use an en-dash (–) to indicate a range or span of numbers. (On Mac: Option + - (dash). On Windows: Control + -. On Debian with compose key enabled: compose + --.
It takes 20–30 days.
#### Money
When writing about US currency, use the dollar sign before the amount. Include a decimal and number of cents if more than 0.
$20
$19.99
When writing about other currencies, follow the same symbol-amount format:
¥1
€1
#### Telephone numbers
Use dashes without spaces between numbers. Use a country code if your reader is in another country.
555-867-5309
+1-404-123-4567
#### Temperature
Use the degree symbol and the capital F abbreviation for Fahrenheit.
98°F
#### Time
Use numerals and am or pm, with a space in between. Don’t use minutes for on-the-hour time.
7 am
7:30 pm
Use an en-dash (–) between times to indicate a time period.
Specify time zones when writing about an event or something else people would need to schedule. Since Agaric was founded and has several worker-owners in Boston, Massachusetts, we default to ET.
Abbreviate time zones within the continental United States as follows:
Eastern time: ET
Central time: CT
Mountain time: MT
Pacific time: PT
When referring to international time zones, spell them out: Nepal Standard Time, Australian Eastern Time. If a time zone does not have a set name, use its Coordinated Universal Time (UTC) offset.
Abbreviate decades when referring to those within the past 100 years.
the 00s
the 90s
When referring to decades more than 100 years ago, be more specific:
The apostrophe’s most common use is making a word possessive. If the word already ends in an s and it’s singular, you also add an ‘s. If the word ends in an s and is plural, just add an apostrophe.
Apostrophes can also be used to denote that you’ve dropped some letters from a word, usually to match spoken language— an unofficial contraction*. This is fine, but do it sparingly.
Use a colon (rather than an ellipsis, em dash, or comma) to offset a list.
Erin ordered three kinds of doughnuts: glazed, chocolate, and pumpkin.
You can also use a colon to join 2 related phrases. If a complete sentence follows the colon, capitalize the 1st word.
I was faced with a dilemma: I wanted a doughnut, but I’d just eaten a bagel.
**Commas**
When writing a list, use the serial comma (also known as the Oxford comma).
Yes: David admires his parents, Oprah, and Justin Timberlake.
No: David admires his parents, Oprah and Justin Timberlake.
Otherwise, use common sense. If you’re unsure, read the sentence out loud. Where you find yourself taking a breath, use a comma.
**Dashes and hyphens**
Use a hyphen (-) without spaces on either side to link words into single phrase.
first-time user
To indicate a span or range, use an n-dash (–).
Monday–Friday
Use an em dash (—) with a space after the dash to offset an aside. Use a true em dash, not hyphens (- or --).
Multivariate testing—just one of our new Pro features— can help you grow your business.
Austin thought Brad was the donut thief, but he was wrong— it was Lain.
**Ellipses**
Ellipses (...) can be used to indicate that you’re trailing off before the end of a thought. Use them sparingly. Don’t use them for emphasis or drama, and don’t use them in titles or headers.
“When in the Course of human events it becomes necessary for one people to dissolve the political bands which have connected them with another and to assume among the powers of the earth, [...] a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.”
**Periods**
Periods go inside quotation marks. They go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
Christy said, “I ate a doughnut.”
I ate a doughnut (and I ate a bagel, too).
I ate a doughnut and a bagel. (The doughnut was Sam’s.)
Leave a single space between sentences. Unless using a period ligature that provides more space at the end of a sentence than in acronyms, this can be ambiguous: We went to the U.S. I told him.
**Question marks**
Question marks go inside quotation marks if they’re part of the quote. Like periods, they go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
**Exclamation points**
Use exclamation points sparingly, and never more than one at a time.
Exclamation points go inside quotation marks. Like periods and question marks, they go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
Never use exclamation points in failure messages or alerts. When in doubt, avoid!
**Quotation marks**
Use quotes to refer to words and letters, titles of short works (like articles and poems), and direct quotations.
Periods and commas go within quotation marks. Question marks within quotes follow logic— if the question mark is part of the quotation, it goes within. If you’re asking a question that ends with a quote, it goes outside the quote.
Use single quotation marks for quotes within quotes.
Who was it that said, “A fool and his doughnut are easily parted”?
Brad said, “A wise man once told me, ‘A fool and his doughnut are easily parted.’”
**Semicolons**
Go easy on semicolons. They usually support long, complicated sentences that could easily be simplified. Try an em dash (—) instead, or simply start a new sentence.
When referring generally to a file extension type, use all uppercase without a period. Add a lowercase s to make plural.
GIF
PDF
HTML
JPGs
When referring to a specific file, the filename should be lowercase:
slowclap.gif
MCBenefits.pdf
ben-twitter-profile.jpg
ilovedonuts.html
**Pronouns**
If your subject’s gender is unknown or irrelevant, use “they,” “them,” and “their” as a singular pronoun. Use “he/him/his” and “she/her/her” pronouns as appropriate. Don’t use “one” as a pronoun.
For more on writing about gender, see Writing about people.
**Quotes**
When quoting someone in a blog post or other publication, use the past tense.
“Working with Agaric has helped our business grow,” said Jamie Smith.
**Names and titles**
The first time you mention a person in writing, refer to them by their first and last names. On all other mentions, refer to them by their first name.
Capitalize the names of departments and teams (but not the word "team" or "department").
The first time you mention a school, college, or university in a piece of writing, refer to it by its full official name. On all other mentions, use its more common abbreviation.
Georgia Institute of Technology, Georgia Tech
Georgia State University, GSU
States, cities, and countries
Spell out all city and state names. Don’t abbreviate city names.
Per AP Style, all cities should be accompanied by their state, with the exception of: Atlanta, Baltimore, Boston, Chicago, Cincinnati, Cleveland, Dallas, Denver, Detroit, Honolulu, Houston, Indianapolis, Las Vegas, Los Angeles, Miami, Milwaukee, Minneapolis, New Orleans, New York, Oklahoma City, Philadelphia, Phoenix, Pittsburgh, St. Louis, Salt Lake City, San Antonio, San Diego, San Francisco, Seattle, Washington.
On first mention, write out United States. On subsequent mentions, US is fine. The same rule applies to any other country or federation with a common abbreviation (European Union, EU; United Kingdom, UK).
**URLs and websites**
Capitalize the names of websites and web publications. Don’t italicize.
Avoid spelling out URLs, but when you need to, leave off the http://www.
Our company's legal entity name is "Agaric, LLC." Our trade name is "Agaric." Use "Agaric, LLC" only when writing legal documents or contracts. Otherwise, use "Agaric."
Honor companies’ own names for themselves and their products. Go by whatever is used on their official website. Unless they end with an exclamation point ('!'); that is absurd and will not be respected!
Write in plain English. If you need to use a technical term, briefly define it so everyone can understand.
Agaric’s ops team is constantly scaling our servers to make sure our users have a great experience with our products. One way we do this is with shards, or partitions, that help us better horizontally scale our database infrastructure.
**Text formatting**
Use italics to indicate the title of a long work (like a book, movie, or album) or to emphasize a word.
Dunston Checks In
Brandon really loves Dunston Checks In.
Use italics when citing an example of an element, or referencing button and navigation labels in step-by-step instructions:
The familiar A/B testing variables—Subject line, From name, and Send time—have now been joined by Content, and up to 3 combinations of a single variable can now be tested at once.
Don’t use underline formatting, and don’t use any combination of italic, bold, caps, and underline.
Left-align text, never center or right-aligned.
Leave one space between sentences, never 2.
**Write positively**
Use positive language rather than negative language. One way to detect negative language is to look for words like “can’t,” “don’t,” etc.
Yes: To get a donut, stand in line.
No: You can’t get a donut if you don’t stand in line.
## Content Types
Content at Agaric takes many forms. Here’s a rundown of the types of content we most often write, the functions they serve, and the teams that handle them.
Example: Looks like you may have left our default header content unmodified. Specifically, we still see ‘Use this area to offer a short preview’ in the pre-header/header area.
Example: The City of Camrbidge uses Agaric's Find It platform to make it easier for people to find activities, events, and resources. Here is how it works: https://agaric.coop/work/find-it-cambridge
Every piece of content we publish is supported by a number of smaller pieces. This section lays out our style in regards to these web elements, and explains our approach to the tricky art of SEO.
Alt text is a way to label images, and it is especially important for people who can’t see the images on our website. Alt text should describe the image in a brief sentence or two.
For more on how and why we use alt text, read the Accessibility section.
#### Buttons
Buttons should always contain actions. The language should be clear and concise. Capitalize every word, including articles. It’s OK to use an ampersand in button copy.
Standard website buttons include:
Log In
Sign Up Free
Subscribe
Email Us
Checkboxes
Use sentence case for checkboxes.
Drop-down menus
Use title case for menu names and sentence case for menu items.
#### Forms
Form titles should clearly and quickly explain the purpose of the form.
Use title case for form titles and sentence case for form fields.
Keep forms as short as possible.
Only request information that we need and intend to use. Don’t ask for information that could be considered private or personal, including gender. If you need to ask for gender, provide a field the user can fill in on their own, not a drop-down menu.
#### Headings and subheadings
Headings and subheadings organize content for readers. Be generous and descriptive.
Headings (H1) give people a taste of what they’re about to read. Use them for page and blog titles.
Subheadings (H2, H3, etc.) break articles into smaller, more specific sections. They give readers avenues into your content and make it more scannable.
Headings and subheadings should be organized in a hierarchy, with heading first, followed by subheadings in order. (An H2 will nestle under H1, an H3 under H2, and on down.)
Include the most relevant keywords in your headings and subheadings, and make sure you cover the main point of the content.
Use title case, unless the heading is a punctuated sentence. If the heading is a punctuated sentence, use sentence case. Use sentence case for subheadings regardless of end punctuation.
Provide a link whenever you’re referring to something on an external website. Use links to point users to relevant content and trusted external resources.
Don’t include preceding articles (a, an, the, our) when you link text. For example:
Don’t say things like “Click here!” or “Click for more information” or “Read this.” Write the sentence as you normally would, and link relevant keywords.
Links should look different than regular copy, strong text, or emphasis text. They should have a hover state that communicates they’re interactive, and should have a distinct active and visited state. When setting the hover state of links, be sure to include focus state as well, to help readers using assistive technologies and touch devices.
Use lists to present steps, groups, or sets of information. Give context for the list with a brief introduction. Number lists when the order is important, like when you’re describing steps of a process. Don’t use numbers when the list’s order doesn’t matter.
If one of the list items is a complete sentence, use proper punctuation and capitalization on all of the items. If list items are not complete sentences, don’t use punctuation, but do capitalize the first word of each item.
Sometimes a long piece of copy lends itself to a list of related links at the end. Don’t go overboard—4 is usually plenty.
Related articles should appear in a logical order, following the step down/step up rule: The first article should be a step down in complexity from the current article. The second one should be a step up in complexity to a more advanced article.
If you can, avoid repeating links from the body text in related articles.
We write for humans, not machines. We do not use gross SEO techniques like keyword stuffing to bump search results. But we also want to make it easy for people and search engines to find and share our content. Here are some not-icky ways to do this:
Organize your page around one topic. Use clear, descriptive terms in titles and headings that relate to the topic at hand.
Use descriptive headings to structure your page and highlight important information.
Give every image descriptive alt text.
## Writing Blog Posts
Agaric blog posts are written by people from all over the company, not just those with “writer” in their job titles. We love having experts from around the office blog about their work. The person most familiar with the subject is in the best position to convey it, and the writers on the marketing team can help with brainstorming and editing as needed.
We publish blog posts that explain the “why” behind the work we do at Agaric. We want to show people that we are an industry leader and we use our blog to tell the stories behind our work and services.
When writing for the blog, follow the style points outlined in the Voice and tone and Grammar and mechanics sections. Here are some more general pointers, too.
If you are writing about data, put the numbers in context. If you are writing about an Agaric client, give the reader plenty of information about the organization’s purpose, workflow, technical needs and results.
Get to the important stuff right away, and don’t bury the kicker. Blog posts should be scannable and easy to digest. Break up your paragraphs into short chunks of three or four sentences, and use subheads. Our users are busy, and we should always keep that in mind.
Agaric is a fun company, and we want our blog to reflect this. Feel free to throw in a joke here and there, or link out to a funny GIF or YouTube video when appropriate. Just do not overdo it.
In Drupal, add keywords that apply to your article. Look through existing posts for common tags. If you are not sure if a word should be a tag, it probably should not be a tag.
Include images in your blog posts when it makes sense. If you’re explaining how to do something, include screenshots to illustrate your point. Make sure to use alt text.
*This section is heavily influenced by Nick Disabato of [Draft](https://draft.nu).*
A case study shows potential clients a named real-world client we have worked with, along with the impact (economic or other) we had on their business or organization, with social proof from one or more members of the client’s team.
### What to enforce upfront
This involves three bits that need to be contractually enforced before starting any engagement:
* The impact must be measurable. We cite a specific number that indicates the impact of our work. No numeric ranges here: only specific, precise numbers.
* Social proof must be present. Get an awesome quotation about the impact of Agaric’s work from the client and publish the case study with their name in it.
* These must be contractually enforced before the engagement begins, because they are always points of contention later.
**The problem.** Explain or enumerate why a client came to Agaric, as well as any unique aspects of their problem. (The more expensive a problem is for a client, the more clearly we can show our impact.)
**Our thinking.** How did we begin approaching the problem? What research did we conduct to address it? What worked and what did not? What did we try?
**The outcome.** What was the measurable impact of our work?
**A quotation.** What did the client say about our work?
**What happened next.** Did the engagement expand in any capacity? Did we do other valuable things for them that were not part of the initial, agreed-upon scope?
**A call to action.** Case studies exist to generate additional leads for the consultancy, so end with a clear next step for the reader to take – one that probably begins with introducing the kind of work we can do for them, and encourages them to apply.
Initiatives are meant to inform our audiences of how our work extends out to the greater world. Clearly convey their purpose, impact and how people can get involved.
Start with the essentials: what, when, where, cost and then follow with more specific details such as information about the people presenting or links to further background information.
This is an opportunity for people’s individuality to come through. Make these personable, highlight people’s passions, expertise and interesting facts that connect them to the reader.
Someone reading technical content is usually looking to answer a specific question. That question might be broad or narrowly-focused, but either way our goal is to provide answers without distraction.
We don’t want to overload a reader with unnecessary information, choices to make, or complex ideas or phrases, when we don’t have to. This is particularly critical when a user may be new and/or frustrated. When relevant, prime the reader with a brief outline of an article’s focus in an introductory paragraph or section, and stick to the topic at hand. Keep sentences, paragraphs, and procedural steps focused and concise.
Before you begin writing a new article, reach out to a subject matter expert (like an engineer, tester, designer, researcher, or technical support advisor) to get as much information as possible. You may only use a small portion of what you learn, but it helps to have more information than you need to decide where to focus your article.
Consider how many articles are needed and what article types will best describe a new feature or tasks to the user.
Outline your article, then write a draft. Stay in touch with your subject matter expert and revise as needed for accuracy, consistency, and length.
When you’re happy with a draft, pass it to another technical writer for peer review. Then show it to a lead technical writer for additional review and revisions. For new content or highly complex content, send last draft to your subject matter expert for final approval.
When writing technical content, follow the style points outlined in the Voice and tone and Grammar and mechanics sections. Here are some more general pointers, too.
**Stay relevant to the title**
When a user clicks the title of an article, they expect to find the answer they want. Don’t stray too far from the title or topic at hand. Use links to make related content available. If you find you’re getting too far from the intended topic, then you may need to create a separate but related article.
**Keep headlines and paragraphs short and scannable**
Focused users often scan an article for the part that will answer their particular question. Be sure headlines are short, descriptive, and parallel, to facilitate scanning.
**Use second-person and describe actions to a user**
Technical content talks to users when support agents can’t.
**Strive for simplicity and clarity**
Be as clear as possible. Use simple words and phrases, avoid gerunds and hard-to-translate idioms or words, focus on the specific task, limit the number of sentences per paragraph. If you must include edge cases or tangentially related information, set it aside in a Before
You Start list or Notes field.
**Provide context through embedded screenshots and GIFs**
Screenshots and GIFs may not be necessary for every article or process, but can be helpful to orient new users. Crop screenshots tightly around the action to focus attention.
Technical content uses organization, capitalization, and other formatting to help convey meaning. Although different articles are organized differently, some formatting tips are consistent throughout all technical content.
Capitalize proper names of Agaric products, features, pages, tools, and team names when directly mentioned. In step-by-step instructions, capitalize and italicize navigation and button labels as they appear in the app.
Group article content with H2s and H3s. Use H2s to organize content by higher-level topics or goals, and use H3s within each section to separate supporting information or tasks.
Upload a List
Format your CSV File
Import your CSV File
Match Fields
Best Practices for Lists
List Collection
List Management
Email Content and Delivery
**Ordered Lists**
Only use ordered lists for step-by-step instructions. Separate steps into logical chunks, with no more than 2 related actions per step. When additional explanation or a screenshot is necessary, use a line break inside the list item.
**Unordered Lists**
Use unordered lists to display examples, or multiple notes in a Notes block. If an unordered list comprises more than 10 items, use a table instead.
## Writing for Social Media
We use social media to build relationships with Agaric clients and supporters and share all the cool stuff we do. But it also creates opportunities to say the wrong thing, put off clients, and damage our brand. So we’re careful and deliberate in what we post to our social channels. This section lays out how we strike that delicate balance.
### Basics
Agaric has a presence on most major social media platforms. Here are our most active accounts and what we usually post on each:
* LinkedIn: Product news, recruiting content, media mentions, evergreen content
### Guidelines
Our writing for social media should generally follow the style points outlined in the Voice and tone and Grammar and mechanics sections. Here are some additional pointers, too.
**Write short, but smart**
Some social media platforms have a character limit; others don’t. But for the most part, we keep our social media copy short.
Twitter: 270 characters or less (this leaves room for a manual retweet and comments)
Facebook: No limit, but aim for 1-2 short sentences.
Instagram: No limit, but try to keep it to 1 sentence or a short phrase. Feel free to throw in an emoji.
To write short, simplify your ideas or reduce the amount of information you’re sharing—but not by altering the spelling or punctuation of the words themselves. It’s fine to use the shorter version of some words, like “info” for “information.” But do not use numbers and letters in place of words, like “4” instead of “for” or “u” instead of “you.”
### Engagement
Do your best to adhere to Agaric style guidelines when you’re using our social media channels to correspond with users. Use correct grammar and punctuation—and avoid excessive exclamation points.
When appropriate, you can tag the subject of your post on Twitter or Facebook. But avoid directly tweeting at or otherwise publicly tagging a post subject with messages like, “Hey, we wrote about you!” Never ask for retweets, likes, or favorites.
No: “Hey @mlncn, can you RT this post we wrote about the training you are giving? https://agaric.coop/blog/learn-how-migrate-drupal-8-successfully-nonprofit-technology-pre-conference-day”
We employ hashtags rarely and deliberately. We may use them to promote an event or connect with users at a conference. Do not use current event or trending hashtags to promote Agaric unless it applies directly to our work (eg: #drupal#freesoftware#netneutrality).
### Trending topics
* Do not use social media to comment on trending topics or current events that are unrelated to Agaric.
We’re always working to make our content more accessible and usable to the widest possible audience. Writing for accessibility goes way beyond making everything on the page available as text. It also affects the way you organize content and guide readers through a page. Depending on the audience and country, there may be laws governing the level of accessibility required. At minimum, an accessible version should be available. Accessibility includes users of all mental and physical capacities, whether situational (broken glasses!) or more permanent.
## Basics
We write for a diverse audience of readers who all interact with our content in different ways. We aim to make our content accessible to anyone using a screen reader, keyboard navigation, or Braille interface, and to users of all cognitive capabilities.
As you write, consider the following:
* Would this language make sense to someone who doesn’t work here?
* Could someone quickly scan this document and understand the material?
* If someone can’t see the colors, images or video, is the message still clear?
* Is the markup clean and structured?
* Mobile devices with accessibility features are increasingly becoming core communication tools, does this work well on them?
Many of the best practices for writing for accessibility echo those for writing technical content, with the added complexity of markup, syntax, and structure.
* Avoid directional instructions and any language that requires the reader to see the layout or design of the page. This is helpful for many reasons, including layout changes on mobile.
Use a skip navigation link so that screen reader or keyboard-only users can avoid listening to or tabbing through many navigation elements before getting to the main content.
Headers should always be nested and consecutive. Never skip a header level for styling reasons. To help group sections, be sure the page title is H1, top-level sections are H2s, and subsequent inside those are H3 and beyond. Avoid excessive nesting.
### Employ a hierarchy
Put the most important information first. Place similar topics in the same paragraph, and clearly separate different topics with headings.
Starting with a simple outline that includes key messages can help you create a hierarchy and organize your ideas in a logical way. This improves scannability and encourages better understanding.
Make true lists instead of using a paragraph or line breaks.
### Label forms
Label inputs with clear names, and use appropriate tags. Think carefully about what fields are necessary, and especially which ones you mark as required. Label required fields clearly. The shorter the form, the better.
### Use descriptive links
Links should provide information on the associated action or destination. Try to avoid “click here” or “learn more.”
### Use plain language
Write short sentences and use familiar words. Avoid jargon and slang. If you need to use an abbreviation or acronym that people may not understand, explain what it means on first reference.
### Use alt text
The alt tag is the most basic form of image description, and it should be included on all images. The language will depend on the purpose of the image:
* If it’s a creative photo or supports a story, describe the image in detail in a brief caption.
* If the image is serving a specific function, describe what’s inside the image in detail. People who don’t see the image should come away with the same information as if they had.
* If you’re sharing a chart or graph, include the data in the alt text so people have all the important information.
Each browser handles alt tags differently. Supplement images with standard captions when possible.
### Make sure closed captioning is available
Closed captioning or transcripts should be available for all videos. The information presented in videos should also be available in other formats.
### Be mindful of visual elements
Aim for high contrast between your font and background colors. Tools in the resources section should help with picking accessible colors.
Images should not be the only method of communication, because images may not load or may not be seen. Avoid using images when the same information could be communicated in writing.
## Resources
* [Accessibility evaluation for web writers](http://www.4syllables.com.au/2013/05/writers-accessibility-evaluation/)
* [WAVE Web Accessibility Evaluation Tool](http://wave.webaim.org/)
## Writing for Translation
Agaric serves users in several countries and territories, not just the United States. As our user base grows, it becomes more and more important that our content is accessible to people around the world.
We call the process of writing copy for translation “internationalization.” This section will address things you can do to help international audiences, including translators, better comprehend your text.
We try to write all of our content in standard, straightforward English that can be understood by users with limited English proficiency. It is much easier for a translator to clearly communicate ideas written in straightforward, uncomplicated sentences.
Use positive words when talking about positive situations. For example, because a question like “Don’t you think she did a great job?” begins with a negative word, a non-native English speaker may interpret its implication as negative. A better version would be “She did a good job, right?”
When writing for international audiences, we generally follow what is outlined in the Voice and tone and Grammar and mechanics sections. But in this section more than others, some style points contradict what is stated elsewhere in the guide. If you’re writing something to be translated, the guidelines in this section should take precedence.
Agaric’s voice is conversational and informal. However, in some cultures, informal text may be considered offensive. Check with your translator to see if this is the case for the particular language you’re writing for.
The translation company should give the option to translate in a formal or informal tone, if the language allows for it. (For example, in Spanish, it is possible to write informally where tú = you or formally where usted = you.)
When writing text that will be translated, be careful about making references to things of local or regional importance. These may not be recognizable to readers outside the US.
### Prioritize clarity
Keep your copy brief, but don’t sacrifice clarity for brevity. You may need to repeat or add words to make the meaning of your sentences clear to a translator.
#### Repeat verbs that have multiple subjects.
Yes: Customers who have ordered online can pick up their food at the cashier. Walk-in customers should stop by the cashier to order their food.
No: Customers who have ordered online or who are walk-ins should stop at the cashier to order or pick up their food.
Many words, parts of speech, and grammar mechanics we don’t think twice about have the potential to cause confusion for translators and non-native English speakers. Here are some of the big trouble spots to avoid.
Yes: Many believe that making functionality changes directly to a live site is OK. Such action can actually cause a site to break. Making functionality changes directly to a live site is not recommended.
No: Many believe that making functionality changes directly to a live site is OK. This can cause a site to break. It is not recommended.
In English, many different types of words end in -ing: nouns, adjectives, progressive verbs, etc. But a translator who is a non-native English speaker may not be able to recognize the distinctions and may try to translate them all in the same way.
Because of this, we want to avoid -ing words when possible. One exception to this rule is words like “graphing calculator” and “riding lawnmower,” where the -ing word is part of a noun’s name and can’t be worked around.
Here are some other cases where you might see -ing words, and suggestions for how to edit around them.
* Synonyms, generally. Do not use a lot of different words for the same thing in a single piece of writing. Instead of mixing it up with “campaign,” “newsletter,” “bulletin,” etc., pick one term and stick with it.
“Once” (could mean “one time,” “after,” “in the past,” or “when”)
Yes: After you log in, you will see your account’s Dashboard.
No: Once you log in, you will see your account’s Dashboard.
“Right” (could mean “correct,” “the opposite of left,” “politically conservative,” etc.)
Yes: In the File Manager, click the correct image and drag it to the pane at right.
No: In the File Manager, click the right image and drag it to the right pane.
“Since” (could refer to a point in time, or a synonym of “because”)
Yes: Because you already have a complete mailing list, you can send your campaign at any time.
No: Since you already have complete mailing list, you can send your campaign at any time.
“Require” plus an infinitive (could confuse the relationship between subject and object)
Yes: Autoresponders can be configured and sent from paid accounts.
No: A paid account is required to send autoresponders. (This could imply that users with paid accounts are required to send autoresponders.)
“Has” or “have” plus past participle (could confuse the relationship between subject and object)
Yes: The folder contains sent campaigns.
No: The folder has sent campaigns.
#### Numbers
**Measurements**
When writing for an international audience, use the metric system. Spell out all units and avoid abbreviation.
**Currency**
Many countries call their currency "the dollar," but the value is going to differ between countries. The US dollar is not the same as the Canadian dollar, for example. So it’s important to specify.
Avoid colloquial phrases that relate to money, like “five-and-dime,” “greenbacks,” or “c-notes.” These won’t translate well.
Adapted from [MailChimp](https://styleguide.mailchimp.com/) and available under a Creative Commons Attribution-NonCommercial 4.0 International license.
