diff --git a/docs/wwwroot/content/autocomplete.png b/docs/wwwroot/content/autocomplete.png
new file mode 100644
index 000000000..92b31f7a3
Binary files /dev/null and b/docs/wwwroot/content/autocomplete.png differ
diff --git a/docs/wwwroot/content/invalidjson1.png b/docs/wwwroot/content/invalidjson1.png
new file mode 100644
index 000000000..e9d6d7d01
Binary files /dev/null and b/docs/wwwroot/content/invalidjson1.png differ
diff --git a/docs/wwwroot/content/vscode-extension-marketplace.png b/docs/wwwroot/content/vscode-extension-marketplace.png
new file mode 100644
index 000000000..d2e05d71a
Binary files /dev/null and b/docs/wwwroot/content/vscode-extension-marketplace.png differ
diff --git a/docs/wwwroot/content/vscode-extension.png b/docs/wwwroot/content/vscode-extension.png
new file mode 100644
index 000000000..5e29c5517
Binary files /dev/null and b/docs/wwwroot/content/vscode-extension.png differ
diff --git a/docs/wwwroot/content/wpfvisualizer.png b/docs/wwwroot/content/wpfvisualizer.png
new file mode 100644
index 000000000..6375852b4
Binary files /dev/null and b/docs/wwwroot/content/wpfvisualizer.png differ
diff --git a/docs/wwwroot/documentation/index.html b/docs/wwwroot/documentation/index.html
index 63c56fc1a..05a710eb2 100644
--- a/docs/wwwroot/documentation/index.html
+++ b/docs/wwwroot/documentation/index.html
@@ -29,9 +29,6 @@
About
+
Tools and Samples
Partners
Related projects
diff --git a/docs/wwwroot/documentation/markdown/about/Goals.md b/docs/wwwroot/documentation/markdown/about/Goals.md
deleted file mode 100644
index d25ea0353..000000000
--- a/docs/wwwroot/documentation/markdown/about/Goals.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Goals
-Adaptive cards goals are to be:
-
-* **Portable** - to any device and ui framework
-* **Open** - Libraries and schema are open source and shared.
-* **Automatically Styled** to the Host application UX and brand guidelines
-* **Low cost** - Easy to define, easy to consume
-* **Expressive** - Targeted at the long tail of content that developers want to produce.
-* **Purely declarative** - no code is needed or allowed
-
-
diff --git a/docs/wwwroot/documentation/markdown/about/Overview.md b/docs/wwwroot/documentation/markdown/about/Overview.md
index b57fc66d6..a0825fc6a 100644
--- a/docs/wwwroot/documentation/markdown/about/Overview.md
+++ b/docs/wwwroot/documentation/markdown/about/Overview.md
@@ -1 +1,64 @@
# Overview
+Adaptive cards are an open common JSON card exchange format which provides an easy way for developers to exchange
+UI content.
+
+## How it works
+
+A developer creates interactive content by creating a simple JSON object and sending it to the target application.
+The schema is made up of simple building blocks that can be combined in an endless number of combinations.
+
+An adaptive card aware application uses an open source library for their platform/ui framework to renders the card
+natively into their application.
+
+## Content developers
+If you are a developer of content adaptive cards are great because:
+* **One card** - You get one format, minimizing the cost of creating a card and maximizing the number of places it can be used.
+* **Richer Expression** - Your content can more closely align with want you want to say because you have a richer pallete to paint in.
+* **Broad Reach** - Your content will work across a broader set of applications without you having to learn new schemas.
+* **Input controls** - Your card can include input controls for gathering information from the user that is viewing the card.
+* **Better tooling** - Because there is a shared card ecosystem better tooling can be created that is shared by everyone.
+
+## App developers
+If you are an app developer which displays content you will love adaptive cards because:
+* **Consistent user experience** - You get a consistent experience because you own the style of the rendered card
+* **Native performance** - You get native performance as it targets your ui framework directly
+* **Safe** - Content is delivered in safe payload, you don't have to open up your ui framework to raw html
+* **Easy to implement** - You get off the shelf libraries to easily integrate
+* **Free documentation** - You save time because you don't have invent schema, document schema, creating tooling around it, etc.
+* **Shared tooling** - You save time because you don't have tooling for your schema
+
+# Goals
+The goals for adaptive cards are:
+
+* **Portable** - to any device and ui framework
+* **Open** - Libraries and schema are open source and shared.
+* **Automatically Styled** to the Host application UX and brand guidelines
+* **Low cost** - Easy to define, easy to consume
+* **Expressive** - Targeted at the long tail of content that developers want to produce.
+* **Purely declarative** - no code is needed or allowed
+
+## Core Design Principles
+The design of adaptive cards has been driven by some core principles that have been useful for keeping the
+design on track.
+
+### Semantic instead of pixel-perfect
+As much as possible we have strived for semantic values and concepts as opposed to pure pixel pefect layout.
+Examples of semantic expression show up in colors, sizes, and in elements like FactSet and ImageSet. These all
+allow the prod allow the host application to control decisions about the actual look and feel.
+
+### Card creator owns the content, card displayer owns the look and feel
+The creator owns what they want to say, but the application which is displaying it owns the look and feel of
+ of the card in the context of their application.
+
+### Keep it simple, but expressive
+We want adaptive cards to be expressive and general purpose, but we don't want to build a ui framework. The whole point
+is to create an intermediate layer which is expressive enough in the same way markdown is expressive enough.
+
+By focusing on keeping it simple and expressive, markdown created an easy and consistent expression of document content. In the
+same way we believe that adaptive cards can create a simple, expressive way for card content.
+
+### When in doubt, keep it out
+It is easier to add later then it is to live with a mistake. This means that if we find ourselves arguing about whether
+we should add something or not, we opted to leave it out. It is always easier to add a property then to live with a legacy property we wished we didn't want to support anymore.
+
+
diff --git a/docs/wwwroot/documentation/markdown/about/Principles.md b/docs/wwwroot/documentation/markdown/about/Principles.md
deleted file mode 100644
index c32ad3a2c..000000000
--- a/docs/wwwroot/documentation/markdown/about/Principles.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Core Design Principles
-The design of adaptive cards has been driven by some core principles that have been useful for keeping the
-design on track.
-
-## Semantic instead of pixel-perfect
-As much as possible we have strived for semantic values and concepts as opposed to pure pixel pefect layout.
-Examples of semantic expression show up in colors, sizes, and in elements like FactSet and ImageSet. These all
-allow the prod allow the host application to control decisions about the actual look and feel.
-
-## Card producer owns the content, card host owns the look and feel
-The producer owns what they want to say, but the card host owns the look and feel of how that content is expressed
-in the context of their application.
-
-## Keep it simple, but expressive
-We want adaptive cards to be expressive and general purpose, but we don't want to build a ui framework. The whole point
-is to create an intermediate layer which is expressive enough in the same way markdown is expressive enough.
-
-By focusing on keeping it simple and expressive, markdown created an easy and consistent expression of document content. In the
-same way we believe that adaptive cards can create a simple, expressive way for card content.
-
-## When in doubt, keep it out
-It is easier to add later then it is to live with a mistake. This means that if we find ourselves arguing about whether
-we should add something or not, we opted to leave it out. It is always easier to add a property then to live with a legacy property we wished we didn't want to support anymore.
-
-
diff --git a/docs/wwwroot/documentation/markdown/about/ValueProp.md b/docs/wwwroot/documentation/markdown/about/ValueProp.md
deleted file mode 100644
index 9cda8163c..000000000
--- a/docs/wwwroot/documentation/markdown/about/ValueProp.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Value proposition for devlopers
-If you are a developer we think you are going to love adaptive cards.
-
-## Content producers
-If you are a developer that wants to create content:
-* **One card** - You get one format, minimizing the cost of creating a card and maximizing the number of places it can be used.
-* **Richer Expression** - Your content can more closely align with want you want to say because you have a richer pallete to paint in.
-* **Broader Reach** - Your content will work across a broader set of applications without you having to learn new schemas.
-* **Better tooling** - Because there is a shared card ecosystem better tooling can be created that is shared by everyone.
-
-## Content consumers
-If you are a developer that owns an application that would like to display cards
-* **Easy to implement** - You get off the shelf libraries to easily integrate
-* **Consistent user experience** - You get a consistent experience because you own the style of the rendered card
-* **Native performance** - You get native performance as it targets your ui framework directly
-* **Safe** - Content is delivered in safe payload, you don't have to open up your ui framework to raw html
-* **Free documentation** - You save time because you don't have invent schema, document schema, creating tooling around it, etc.
-* **Shared tooling** - You save time because you don't have tooling for your schema
\ No newline at end of file
diff --git a/docs/wwwroot/documentation/markdown/create/libraries/Javascript.md b/docs/wwwroot/documentation/markdown/create/libraries/Javascript.md
index 45d14d323..0d7ae3eb6 100644
--- a/docs/wwwroot/documentation/markdown/create/libraries/Javascript.md
+++ b/docs/wwwroot/documentation/markdown/create/libraries/Javascript.md
@@ -1,5 +1,5 @@
# Javascript
-There is no javascript library, but for completeness
+There is no javascript library, but javascript is already pretty good at manipulating JSON.
## Example creating
```javascript
diff --git a/docs/wwwroot/documentation/markdown/create/libraries/Typescript.md b/docs/wwwroot/documentation/markdown/create/libraries/Typescript.md
index 2db7cba44..def61e916 100644
--- a/docs/wwwroot/documentation/markdown/create/libraries/Typescript.md
+++ b/docs/wwwroot/documentation/markdown/create/libraries/Typescript.md
@@ -13,29 +13,38 @@ npm install adaptive-cards
```
## Example creating
-```javascript
-TODO
-var card = new AdaptiveCard();
-card.Body.Add(new TextBlock()
+There are interface definitions in schema.d.ts which describe the shape of the schema
+
+```typescript
+let card :IAdaptiveCard = {
+ "type": "AdaptiveCard",
+ "version": "1.0",
+ "body": [
+ {
+ "type": "Container",
+ "items": [
+ {
+ "type": "TextBlock",
+ "text": "Meow!"
+ },
+ {
+ "type": "Image",
+ "url": "http://adaptivecards-staging.azurewebsites.net/api/cat"
+ }
+ ]
+ }
+ ]
+};
+```
+
+There is also an object model for creating cards which can be used
+
+```typescript
+let card :IAdaptiveCard = new AdaptiveCard();
+card.body.add(new TextBlock()
{
- Text = "Hello",
- Size = TextSizes.ExtraLarge,
- Color = TextColor.Attention
+ text = "hello world"
});
-card.Body.Add(new Image()
-{
- Url = "http://someUrl.com/example.png"
-});
-```
-## Example saving
-```javascript
-TODO
-var json = JsonConvert.SerializeObject(card);
+
```
-## Example loading
-```
-var card = JsonConvert.DeserializeObject
(json);
-```
-
-
diff --git a/docs/wwwroot/documentation/markdown/resources/Tools.md b/docs/wwwroot/documentation/markdown/resources/Tools.md
new file mode 100644
index 000000000..a6393d5e6
--- /dev/null
+++ b/docs/wwwroot/documentation/markdown/resources/Tools.md
@@ -0,0 +1,65 @@
+# Schema validation
+Schema validation is a powerful way of making authoring easier and enabling tooling.
+
+## JSON Schema file
+We have provided a complete (json schema file)(/schemas/adaptive-cards.json) for editing and validating
+adaptive cards in json.
+
+In Visual Studio and Visual Studio Code you can get automatic intellisense by including a $schema reference like this:
+
+![bad](/content/invalidjson1.png)
+
+![autocomplete](/content/autocomplete.png)
+
+Example:
+```javascript
+{
+ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
+ "type": "AdaptiveCard",
+ "version": "1.0",
+ "body": []
+}
+```
+
+## Xsd Schema file
+The Microsoft.AdaptiveCards .NET library has XML annotations so that you can serialize and deserialize XML
+as well as JSON, making it easy to use with XML based toolsets.
+
+We have provided a complete (xsd schema file)(/schemas/adaptive-cards.xsd) for editing and validating
+adaptive cards in xml.
+
+In Visual Studio and Visual Studio Code you can get automatic intellisense by including a xsd reference like this:
+
+```xml
+
+
+
+
+```
+
+
+# Tools & samples
+There are some tools and samples in the source tree which are useful references as well as being useful tools.
+
+## Visual Studio Code Extension
+We have created a visual studio code extension which allows you to visualize the card you are editing in real time
+inside the editor itself.
+
+![extension](/content/vscode-extension.png)
+
+To Install, open Extensions Marketplace and search for **Adapative Card Viewer**
+
+![marketplace](/content/vscode-extension-marketplace.png)
+
+
+## WPF Visualizer Sample
+The WPF visualizer lets you visualize cards using WPF/Xaml on a windows machine. Built into it is a hostconfig
+editor which allows you to edit and view host config settings and save as a json file so you can then use in rendering
+in your application.
+
+![wpf visualizer](/content/wpfvisualizer.png)
+
+## Render2Image Sample
+The Render2Image sample turn any card into a PNG from the command line.