Skip to content

Commit

Permalink
Small typos
Browse files Browse the repository at this point in the history
  • Loading branch information
m-allanson authored Apr 24, 2018
1 parent a9e5498 commit ee7bc36
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions docs/docs/website-teams.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ _Take advantage of extended evaluation periods to build a component library_

Larger companies considering adopting Gatsby often plan in terms of migrating multiple sites (or internationalized versions of sites) over a timeframe of a few months to two years. These projects can have long preparation times before active development starts.

One high-leverage activity during these time windows is focus development on a React component library. Then, when development begins the team is able to quickly assemble Gatsby React pages from these pre-built components. Consider designating senior UI developers as "component architects" in this process.
One high-leverage activity during these time windows is to focus development on a React component library. Then, when development begins the team is able to quickly assemble Gatsby React pages from these pre-built components. Consider designating senior UI developers as "component architects" in this process.

_Consider a less-expensive CMS or multi-modal architecture_

Expand All @@ -28,13 +28,13 @@ In order to do user testing, usually user researchers work with designers to con

Gatsby makes another option possible. Some Gatsby users report [setting up a production site](https://www.gatsbyjs.org/blog/2018-01-18-how-boston-gov-used-gatsby-to-be-selected-as-an-amazon-hq2-candidate-city/) with live UI that is building and deploying in under an hour.

Especially if your organization already uses a React- or HTML-based component library, your team may consider bringing in a developer to construct live wireframe-level prototypes. This may enable you to accelerate the user research process, start the development process with a working prototype rather than from scratch, and ultimately let you arrive at a better version of your site.
Especially if your organization already uses a React or HTML-based component library, your team may consider bringing in a developer to construct live wireframe-level prototypes. This may enable you to accelerate the user research process, start the development process with a working prototype rather than from scratch, and ultimately let you arrive at a better version of your site.

### Development

_Make progress without access to the client CMS_

Sometimes website development teams don't gain access to the client's CMS until development has already started. This can happen for a variety of reasons -- internal client policies, the need to onboard content editors, and so forth. Typically this is a difficult situation where development can be blocked or delayed, and can leads to timeline slippage, crunch time at the end of the project, and so on.
Sometimes website development teams don't gain access to the client's CMS until development has already started. This can happen for a variety of reasons -- internal client policies, the need to onboard content editors, and so forth. Typically this is a difficult situation where development can be blocked or delayed, and can lead to timeline slippage, crunch time at the end of the project, and so on.

With Gatsby, the CMS-agnostic development workflow gives teams tools to continue to make progress even without access to client content. One common approach is to develop and prototype UIs pulling placeholder content from markdown files stored in the repo. When the team gains access, it only takes a few lines of code to reconfigure the site to pull content from the CMS.

Expand All @@ -47,12 +47,12 @@ _Use development pages to communicate project status & collaborate with designer
One option some teams have found powerful is to create static page components within Gatsby to [handle necessary parts of the development/QA workflow](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#1-pre-integration-qa).

This could include:
* Checking UI implementation of various components to ensure behavior is intended.
* Checking UI implementation of various components to ensure behavior is intended
* Enabling QA visibility into desired site-specific page-level validations, such as "don't end a page in a carousel"
* Communicating build history and last build status.
* Communicating build history and last build status

_Use branch- and pull request-based artifacts to collaborate on specific pieces of work_
_Use branch and pull request-based artifacts to collaborate on specific pieces of work_

Using the [branch- and pull request-based artifacts](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls
Using the [branch and pull request-based artifacts](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls
) automatically created by a service like Netlify for collaboration between developers, designers, and QA. Because generated artifacts are static, pull request collaboration workflows are resilient to underlying content schema changes, such as field deletion, that might break a typical CMS development environment.

0 comments on commit ee7bc36

Please sign in to comment.