Skip to content

Commit 2eb08cb

Browse files
authored
Merge pull request #29 from BitcoinDesign/feature/content-guidelines
WIP: First draft of a page with content guidelines
2 parents a5b932d + c8ea35d commit 2eb08cb

File tree

1 file changed

+54
-0
lines changed

1 file changed

+54
-0
lines changed

guide/content-guidelines.md

+54
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
layout: guide
3+
title: Content guidelines
4+
nav_order:
5+
---
6+
7+
# Content guidelines
8+
9+
Thank your for helping shape the Bitcoin Design Guide. We have many different authors with different ideas and voices. To ensure a coherent and consistent experience for readers, we collected a few tips on writing here.
10+
11+
#### Know your reader
12+
13+
The guide is primarily meant as a tool for people who work on open-source, non-custodial bitcoin projects, with a focus on design.
14+
15+
#### Speak to the reader
16+
17+
Address the reader directly via "you".
18+
19+
#### Use simple language
20+
21+
Bitcoin is meant for a global audience, so you need to assume that many readers are not native English speakers. Many speech writers intentionally write for a 6 to 8th grade proficiency level. This allows a wider audience to understand the content (including non-native speakers), and it forces them to clarify their thinking. You can take advantage of readability tools like [Hemingway](http://www.hemingwayapp.com). They analyze text, provide a readability score, and suggest ways to simplify the writing.
22+
23+
Note that simple language does not mean "dumbing things down". There are also some specific topics that require more complex language. A good guidelines is that the deeper a reader gets into a topic, the more complex the language can be (it does not have to be).
24+
25+
#### Be precise
26+
27+
Focus on the information that will be the most useful to your reader. If a page gets too long, split it up into multiple pages. If you want to allow users to dive deeper into a topic that is not core to the guide, see if there are third-party resources you can link to.
28+
29+
#### Give practical tips, but don't be overly prescriptive
30+
31+
Provide recommendations and best practices but do not force specific solutions on readers. The project the reader is working on may require something slightly or completely different because of unique context.
32+
33+
#### Get the reader involved
34+
35+
You can consider asking questions directly to the user before giving answers. You can also use work-sheets, to-do lists, do's and don'ts or other formats to get readers hands-on.
36+
37+
#### Use the right medium
38+
39+
One picture can say more than one thousand words. Plus, we can use videos, interactive prototypes, diagrams, and more. Take advantage of these different media and their strengths at communicating differen types of information. If you'd like help creating this type of content, ask in the community.
40+
41+
#### Show examples
42+
43+
It is OK to show screenshots of other software as reference points. Make sure to indicate the product and version. Avoid negative examples and focus on showcasing good solutions and explain why they are good.
44+
45+
#### Be humble
46+
47+
The guide is a work in progress and needs to evolve to stay relevant. What we write today may not be applicable tomorrow.
48+
49+
#### Write in the open if you can
50+
51+
It is healthy to get early feedback as it may prevent you from going into a wrong direction for too long. There is a whole community around you to help you create better content that helps more people.
52+
53+
54+

0 commit comments

Comments
 (0)