Below are the motivations and principles govering the evolution of the Adaptive Card format.
Motivations behind the format
In early 2016, several teams at Microsoft (including Outlook, Windows and the Bot Framework) came to the realization that they all wanted something extremely similar ("cards") and that each of them were designing their own solutions independently:
Windows had its own Live Tiles and Notifications format
The Bot framework was using a set of predefined card templates developers could choose from when sending Bot messages
Outlook was using its own MessageCard format for its Actionable Messages feature
At the same time, other platforms such as LINE, FaceBook Messenger, Slack and more were defining their own, proprietary "card" format. So a few Microsoft employees gathered up and started an effort to define a single, open card format and a set of SDKs that:
Would facilitate the interchange of cards between hosts
Would allow each host to keep control over the styling of cards to ensure visual consistency
Would make it easy for a host application to display cards with minimum effort via ready-to-use SDKs
And that would also provide value to third parties and eventually get adopted widely by the industry
Principles governing Adaptive Cards
Adaptive Card is a simple and declarative card format
It is not meant as an HTML or XAML replacement/alternative
There is no "code behind" with Adaptive Cards
Card authors cannot embed custom/arbitrary code with their payloads, and as a result an Adaptive Card host never needs to run third party code
Dynamism and interactivity are achieved solely via declarative markup
This ensures that the effort necessary to build an Adaptive Card SDK for a new platform remains reasonable
The Adaptive Card format can't impose the use of any particular underlying technology
The Adaptive Card format does not rely on JavaScript, C#, Python or any other language
Similarly it doesn't rely on HTML or XAML or any other graphic/UI framework
This way, Adaptive Cards can be rendered natively on any platform for as long as a renderer exists
The Adaptive Card format is a shared property
Along with its SDKs, the format is to be open source and its evolution community driven
The format is therefore not owned nor driven by any one team
The Adaptive Card format is not designed "just for Microsoft's use"
Instead it is designed to suit the needs of a wide variety of applications and use cases
The Adaptive Card Working Group governs the evolution of the format
This working group is comprised of a set of Microsoft employees that are all deeply involved in the success of the format
The Working Group conducts weekly meetings (currently on Monday) during which feature proposals are reviewed, open issues are discussed
and triaged and overall progress on vNext work items is tracked
The Working Group uses feedback from the community at large, including internal Microsoft teams, to decide how the format evolves
Anyone can participate in the working group through opening issues in GitHub (see below)
Issues/feature requests rooted in actual usage of the Adaptive Cards framework (either as a host or as a card author) have the most impact on the future of the format
To be approved by the Working Group, proposed new features:
Must be justified by real life use cases
Must have a functional specification
Approved new feature are added to the backlog and considered for vNext
The criteria used to prioritize new features include the breadth of scenarios the feature enables, its complexity/maintainability and more
When in doubt, keep it out! It's a lot easier to introduce a well designed feature later than to live with a mistake forever.
All new features are implemented in all supported SDKs
All new features are documented and associated with a test card published in the samples folder
New versions of the format and SDKs go through a beta phase
The release schedule for Adaptive Card schema and SDK versions is driven by quality, not date
Interoperability
Cards authored in accordance with the documented format (e.g. not using any host-specific extensions) will render properly in any Adaptive Card-capable host
The only exceptions to this principles are:
Some hosts might not allow interactivity, and will therefore not render inputs nor actions
Execution of Action.Submit actions is at the discretion of the host, and not all hosts will necessarily properly handle all Action.Submit payloads. Furthermore, some hosts might not support Action.Submit at all
The format needs to be extensible
Hosts should have the freedom of adding support for custom elements or custom actions that go beyond what the format is capable of
This is particularly important for actions, as various hosts don't necessarily support the same set of actions
These additions are at the discretion of the host
They are not a de facto addition to the Adaptive Card specification
As such, they make a payload that uses them incompatible with the mainstream Adaptive Card format
They can however be presented to the Working Group and proposed as new features for a future version of the format, as described in point #5
Card authors own the content, host apps own the look and feel
Host apps impose their styling so cards look and feel like they are native extensions of the app's experience
Card authors can still specify styling, but only via semantic expressions of colors, sizes, etc.
SDKs will be provided for the most popular developer platforms
SDKs make it easy to render Adaptive Card payloads in any host
This ensures the barrier to entry is as low as can be both for third party developers and Microsoft teams
Adaptive Cards are platform-agnostic snippets of UI, authored in JSON, that apps and services can openly exchange. When delivered to a specific app, the JSON is transformed into native UI that automatically adapts to its surroundings. It helps design and integrate light-weight UI for all major platforms and frameworks. In this module, you'll learn how to create engaging messages with Adaptive Cards to create Outlook Actionable Messages and conversations in Microsoft Teams.