Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make our documentation the best in the world #1

Open
3 tasks
rmccue opened this issue May 29, 2014 · 4 comments
Open
3 tasks

Make our documentation the best in the world #1

rmccue opened this issue May 29, 2014 · 4 comments

Comments

@rmccue
Copy link
Member

rmccue commented May 29, 2014

WP API's documentation should be first-class, and better than every other API out there. This might seem unachievable, but let's aim for it anyway. 🌠

The documentation itself currently lives in the main WP-API repo, but we can move it here if that works better.

How do we do this? Here's some initial things I can see that we need to do:

  • Include guides on the site
  • Include OAuth documentation on the site
  • Integrate all route documentation

This is a tracking ticket for everything else, let's talk about how to do this here, and handle specifics in individual tickets.

Stripe's API docs are widely considered some of the best, let's take inspiration from them where possible. Parse also has some great thoughts.

@rmccue
Copy link
Member Author

rmccue commented May 29, 2014

With route documentation, should we use the URLs themselves instead? What's the best way to format our sidebar navigation?

Example from WooCommerce's docs:
screenshot 2014-05-29 11 16 11

Counter-example from Stripe's docs:
screenshot 2014-05-29 11 16 39

What ours looks like currently:
screenshot 2014-05-29 11 17 57

@pollyplummer
Copy link
Member

A few thoughts in response:

On how to structure the sidebar:

In the current theme, side navigation anchor links seem to be broken. It lists each endpoint with "input" and "response" subnav items, but this becomes a bit repetitive and unwieldly. I like how the Stripe API docs sidebar navigation lists the main object with very readable subnav items for each endpoint, describing what you can do them, ie. Charges > Create a Charge.

In the same way, I'd suggest restructuring our nav to be like so:

Posts

  • Create a post
  • Retrieve a post
  • etc

Media

  • Create Attachment
  • Get Attachment

(Recommend removing "Input" and "response" subnav items entirely.)

Docs Need a Better Theme

I find the current Flatdoc theme very difficult to read, due to small text and very little contrast. It's all grey and very light aqua and strains the eyes. I would suggest using a different documentation theme. One that looks interesting is MkDocs, which you can host on Github pages or on a site of its own. It was built for writing docs in Markdown and includes a built-in devserver allowing you to preview your documentation as you're writing it. MkDocs also has a number of different themes available that you can apply, including ReadTheDocs, which provides much higher contrast.

Another option would be to install WordPress on wp-api.github.io and use or create a WordPress documentation theme.

The better the docs are, the faster developers will be able to start building with the API. I think it would be good to add a section linking to some examples of projects that utilize the WP API as some people learn better from looking at the code of real-world examples.

@bradoyler
Copy link

Are there any docs on how to use the filter querystring?
ie. /posts?filter[type]=person

@amr
Copy link

amr commented Jan 17, 2015

I think you guys might want to check asciidoctor.org, it might be a better companion than MD in assisting you in writing great technical docs. With MD, I always stopped writing and went on how to present the information at hand using its limited formatting features. Great for comments and general writings, but not fit for technical writing, IMHO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants