Merge branch 'master' into salmanmanekia-page-validation

Author: KyleAMathews

README.md

@@ -153,7 +153,8 @@ Websites built with Gatsby:
 * [iContract Blog](https://blog.icontract.co.uk)
 * [Dona Rita](https://donarita.co.uk) ([source](https://github.com/peduarte/dona-rita-website))
 * [Andy Slezak](https://www.aslezak.com) ([source](https://github.com/amslezak))
-
+* [Odayaka](http://odayaka.net) ([source](https://github.com/odayakanaasa/odayaka))
+* [Ventura Digitalagentur Köln](https://www.ventura-digital.de)
 
 ## Docs
 

docs/blog/2017-09-18-gatsby-modern-static-generation/index.md

@@ -20,7 +20,7 @@ production by creating a landing page very fast.
 
 Static site generators like Jekyll all work pretty similarly:
 
-* Describe your content in some common templating language ([Pug](pugjs.org),
+* Describe your content in some common templating language ([Pug](http://pugjs.org),
   [Handlebars](http://handlebarsjs.com), etc)
 * While in development, start a local web server and add file "watchers" that
   will listen for content changes and re-render the site

docs/blog/2017-12-07-taking-gatsby-for-a-spin/index.md

@@ -52,27 +52,25 @@ Data from anywhere with static output. That's sort of the holy grail isn't it? R
 
 ```es6
 export const query = graphql`
-   query BlogPostQuery($slug: String!) {
-       markdownRemark(fields: { slug: { eq: $slug } }) {
-           html
-           fields {
-               slug
-           }
-           frontmatter {
-               title
-               date(formatString: "DD MMMM, YYYY")
-               cover {
-                   childImageSharp {
-                       resolutions(
-                           width: 1200,
-                       ) {
-                           src
-                       }
-                   }
-               }
-           }
-       }
-   }
+  query BlogPostQuery($slug: String!) {
+    markdownRemark(fields: { slug: { eq: $slug } }) {
+      html
+      fields {
+        slug
+      }
+      frontmatter {
+        title
+        date(formatString: "DD MMMM, YYYY")
+        cover {
+          childImageSharp {
+            resolutions(width: 1200) {
+              src
+            }
+          }
+        }
+      }
+    }
+  }
 `;
 ```
 

docs/blog/2018-2-3-sites-with-headless-cms/index.md

@@ -28,25 +28,29 @@ When content exists in a tight relationship with the presentation layer, adaptin
 > 'delivers' content to an application of some type. Its immediate consumer is code, and it’s assumed that
 > code will reformat the content for final delivery to a human." - Deane Barker
 
-To add to [Deane Barker's eloquent explanation in the quote above](https://gadgetopia.com/post/9743), a headless CMS only handles two things--content and managing that content through admin screens. This means that a separate presentation layer (or “head”) like GatsbyJS must reformat the content for delivery to a CDN and then final delivery to humans.
+To add to Deane Barker's eloquent explanation in the quote above (see his article [here](https://gadgetopia.com/post/9743)), a headless CMS only handles two things--content and managing that content through admin screens. This means that a separate presentation layer (or “head”) like GatsbyJS must reformat the content for delivery to a CDN and then final delivery to humans.
 
-There are advantages to this separation between headless CMSs and the presentation layer. Their separation allows both to become highly specialized and efficient, similar to the highly functioning microwave in the Jetson’s house:
+_Note on how CMSs usually work:_ Most headless CMSs require you to create various structures for your content, typically called "content models", and then enter content into that structure. Content can include words, images, URLs, lists, etc. Then, outside of the CMS, you push this content through a presentation layer (GraphQL queries are one way to do this pushing).
 
-![The Jetson’s microwave shoots food at them and makes it so easy to eat!](the-jetsons.jpeg)
-
-Following are some more advantages to using a headless CMS.
+Following are some advantages to using a headless CMS.
 
 ### Faster load times AND cheaper?
 
 With much less time (and therefore less money), you can set up a headless CMS with a presentation layer like GatsbyJS and a CDN and get your site running on edge servers.
 
-The advantage of this method is faster load times for most sites, which can be illustrated by the previous Australia example. Let’s say a person in Australia accesses a US site built with a headless CMS and GatsbyJS; the site can run off of a closer server, so it will load quickly. This is an enormous advantage for both the user and for whomever created the site.
+Besides being faster and therefore less expensive to set up, this method also produces faster load times for most sites. Let’s say a person in Australia accesses a US site built with a headless CMS and GatsbyJS; the site can run off of a closer server, so it will load quickly. This is an enormous advantage for both the user and for whomever created the site.
 
 Faster load times can be taken to the next level with sites that run offline. I recently chatted with a friend in New Delhi who used GatsbyJS to build his blog to run offline, which is an incredible advantage for commuters who want to read while on public transportation with spotty internet access.
 
 ### Higher quality AND cheaper?
 
-Headless CMSs perform well in scenarios in which a traditional CMS would prove inadequate. I’d like to point to Deane Barker’s [excellent article on use cases for headless CMSs](https://gadgetopia.com/post/9743), from which we've extracted a partial list:
+The separation between a headless CMS and the presentation layer allows both to become highly specialized and efficient, similar to the food production system in the Jetson’s house:
+
+![The Jetson’s microwave shoots food at them and makes it so easy to eat!](the-jetsons.jpeg)
+
+When businesses specialize in one thing instead of several, they tend to become more time-efficient and can produce things at a lower cost. In human terms, this means that headless CMSs tend to cost you less than traditional CMSs, because they cost less up front or they take you less time to maintain.
+
+This specialization also means that headless CMSs perform well in scenarios in which a traditional CMS would prove inadequate. I’d like to point to Deane Barker’s [excellent article on use cases for headless CMSs](https://gadgetopia.com/post/9743), from which we've extracted a partial list:
 
 * You need to gather content from disparate places and pull it together into one platform
 * You need to push content to various formats, including desktop sites, mobile sites, smart watches, ads, etc.
@@ -56,10 +60,6 @@ Headless CMSs perform well in scenarios in which a traditional CMS would prove i
 
 In all of these cases, a headless CMS is an excellent solution for you.
 
-### What is the editing experience like in a headless CMS?
-
-Most headless CMSs require you to create various structures for your content, typically called "content models", and then enter content into that structure. Content can include words, images, URLs, lists, etc. Then, outside of the CMS, you push this content through a presentation layer (GraphQL queries are one way to do this pushing).
-
 ## Which headless CMS should I choose?
 
 Whether or not you’re convinced that a headless CMS is a good idea, the next step would be to try some out for yourself. I found this handy site with a [list of headless CMSs to keep an eye on](https://headlesscms.org/about/).