Skip to content
This repository has been archived by the owner on Sep 29, 2023. It is now read-only.

propose baseline for style guidelines #229

Open
wants to merge 11 commits into
base: update-contribution-guide
Choose a base branch
from

Conversation

gewenyu99
Copy link
Contributor

@gewenyu99 gewenyu99 commented Jul 27, 2022

Style Guideline Proposal

What is this PR?

This PR proposes a set of refined styling guidelines to make our documentation more consistent and easier to read. This is intended as a styling suggestion for all documentation contributors to reference and for all reviewers to reference.

New UI Elements Needed

We need a monospace UI element to reference code, file names, hostnames, and other types of text that look better as monospace. Similar to the backtick ` in GitHub, so we can reference monospace inline, like appwrite.json.

Why is this important?

As the community and project grow in complexity, we need to make sure the information, voice, and formatting in our documentation remain consistent.

Notice the way the <application> tag and [PROJECT_ID].

Screen Shot 2022-07-28 at 1 50 15 PM

Notice how the "X-Appwrite-Webhook-Signature" is display extremely differently.

Screen Shot 2022-07-28 at 1 52 48 PM

First with a span tag

Screen Shot 2022-07-28 at 1 50 44 PM

Then with bold text.

Screen Shot 2022-07-28 at 1 58 29 PM

Notice the below example of how we reference UI elements, first with quoted plain text:

Screen Shot 2022-07-28 at 1 55 23 PM

Then with quoted bold:

Screen Shot 2022-07-28 at 1 56 27 PM

This makes the documentation look less professional and difficult to read without consistent visual hints

Notice how these examples from the same guide have a different placeholder for the project. This makes it much harder to follow when I switch from one language to another:

Screen Shot 2022-07-28 at 2 04 40 PM

Screen Shot 2022-07-28 at 2 05 05 PM

@gewenyu99 gewenyu99 marked this pull request as ready for review July 28, 2022 21:39
@stnguyen90 stnguyen90 self-requested a review July 29, 2022 22:57
Copy link
Contributor

@Meldiron Meldiron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing stuff 😇 Left a few comments

README.md Outdated
Documentation is an integral part of Appwrite and follows the same philosophy of quick to get started, easy to grow. Before proposing additions to Appwrite's documentation, think about where these additions fit best.
- The **Getting Started** section helps a developer create their first Appwrite project and make their first requests so they can begin exploring Appwrite. Avoid adding unnecessary information to this section so a developer's first-impressions remains quick and smooth.
- The **Guides** section helps a developer get comfortable with individual Appwrite services. Guides are structured to walk a developer through features of an Appwrite service. The topics should be ordered by level of complexity, where complex topics are positioned later into a guide.
- The **REST API** section helps a developer understand details of individual endpoints. Additions to REST API documentation should remain focused on the API endpoint itself. Avoid adding information about related endpoints and services that are not integral to undestanding documented endpoint. Code example changes should be submitted to the [SDK Generator repo](https://github.com/appwrite/sdk-generator).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also mention that endpoint names or descriptions are to be updated in appwrite/appwrite.

- The **Getting Started** section helps a developer create their first Appwrite project and make their first requests so they can begin exploring Appwrite. Avoid adding unnecessary information to this section so a developer's first-impressions remains quick and smooth.
- The **Guides** section helps a developer get comfortable with individual Appwrite services. Guides are structured to walk a developer through features of an Appwrite service. The topics should be ordered by level of complexity, where complex topics are positioned later into a guide.
- The **REST API** section helps a developer understand details of individual endpoints. Additions to REST API documentation should remain focused on the API endpoint itself. Avoid adding information about related endpoints and services that are not integral to undestanding documented endpoint. Code example changes should be submitted to the [SDK Generator repo](https://github.com/appwrite/sdk-generator).
- The **Advanced** section helps a developer learn more complicated concepts like pagination or using permissions. If your proposed addition are not a core component of using a service or requires lengthy explanation, consider adding them to **Advanced**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it clear what should go into "Guides", what into "Advanced" and what should not be part of docs? (like OAuth article)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something worth discussing. I heard Steven and Torsten are having a conversation about how to divide the guides up, but the idea is guides are "getting started" for the primary services, everything else that's not core/self-host related will be "Advanced".

### Naming Files
File names should reflect it's content. In general, use dash separated file names that reference the title of the page. For example "Documentation Guidelines" could be "documentation-guidelines".
### Internal and External Links
Internal links that direct to any link under [https://appwrite.io](/docs/command-line#installation) should be relative and precise. For example, when referencing the Appwrite Documentation page, use the `<a href="/docs">Documentation</a>`. When referencing a specific section of a page, link to the section heading where possible. For example `<a href="/docs/databases#databases">Create Your Databases</a>`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get what you mean, but I don't think these links are called relative. Relative would be ../docs/command-line. Maybe there is a batter word for internal VS external links?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://www.w3.org/TR/WD-html40-970917/htmlweb.html

I believe this is in fact relative:

Screen Shot 2022-08-02 at 5 30 27 PM

README.md Outdated Show resolved Hide resolved
<li>Create a script to backups and restore your InfluxDB stats. If you don’t care much about your server stats, you can skip this.</li>
<li>Create a script to backup Appwrite storage volume. There are many online resources explaining different ways to backup a docker volume. When running on multiple servers, it is very recommended to use an attachable storage point. Some cloud providers offer integrated backups to such attachable mount like GCP, AWS, DigitalOcean, and the list continues.</li>
</ol>
```

### Code Examples
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's please also mention how to put <> symbols in there. It's relevant in some languages and breaks if you don't do it properly. I think we used it in Flutter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yus. I agrees

<h2>Important Message</h2>
<p>Message content here.</p>
</div>
```

### Screenshots
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading this section, we say:

  • If no dark mode is provided, light mode will be the fallback
  • All screenshots of the Appwrite dashboard should support light and dark mode
  • All screenshot of the Appwrite dashboard should support light and dark mode.

We say it too much. Just making sure we are aware and do it in purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch

README.md Outdated Show resolved Hide resolved
README.md Outdated
Documentation is an integral part of Appwrite and follows the same philosophy of quick to get started, easy to grow. Before proposing additions to Appwrite's documentation, think about where these additions fit best.
- The **Getting Started** section helps a developer create their first Appwrite project and make their first requests so they can begin exploring Appwrite. Avoid adding unnecessary information to this section so a developer's first-impressions remains quick and smooth.
- The **Guides** section helps a developer get comfortable with individual Appwrite services. Guides are structured to walk a developer through features of an Appwrite service. The topics should be ordered by level of complexity, where complex topics are positioned later into a guide.
- The **REST API** section helps a developer understand details of individual endpoints. Additions to REST API documentation should remain focused on the API endpoint itself. Avoid adding information about related endpoints and services that are not integral to undestanding documented endpoint. Code example changes should be submitted to the [SDK Generator repo](https://github.com/appwrite/sdk-generator).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the Guides and Rest API bullet point orders be swapped to match the order in our docs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're gonna swap the order in docs soon ;)

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
gewenyu99 and others added 7 commits August 2, 2022 16:23
Co-authored-by: Steven <1477010+stnguyen90@users.noreply.github.com>
Co-authored-by: Steven <1477010+stnguyen90@users.noreply.github.com>
Co-authored-by: Steven <1477010+stnguyen90@users.noreply.github.com>
@gewenyu99
Copy link
Contributor Author

I think we might need to go back to "Appwrite Console'

It already exists in way to many places for us to change, and it never really caused confusion. This was a bad call on my part.

christyjacob4 added a commit that referenced this pull request Nov 14, 2022
Update Install guide to conform to guidelines proposed in PR #229.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants