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
Overview - Goals - Core principles - Value proposition Future work
Creating a card @@ -68,6 +65,7 @@ Resources
+ 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.