What is Adaptive Cards?
Adaptive Cards is a Card UI framework announced by Microsoft in 2017 that aims to standardize the layouting of Cards independent of the platform.
The goal is to define a Card just once, make it portable and leave it to the different platforms to skin it according to its own requirements.
Adaptive Cards are obviously best supported by other Microsoft products, like Cortana or Bot Framework. Microsoft Teams was also added officially a year later, while many others are available as developer preview only (like Skype). You can see an up-to-date list of supported platforms on the Microsoft website.
As of August 2019, Cisco Webex Teams announced they will be adopting the standard. Previously bots in Webex Teams were text only, so Cisco adopting the standard is a big nod to the standard being universally the best for Card UIs.
If you're reading this article chances are you're already working (or considering to work) with Bot Framework. Maybe you're making a chatbot for your organization and are wondering if there any hidden implications of committing your project to the hands of Microsoft.
So here we have a few thoughts you might want to take into consideration:
Benefits of using Adaptive Cards
Apart from a wider perspective on Card-based UX more generally, Adaptive Cards is Microsoft's attempt to be part of the development. And there are many solid aspects to it:
- Written in JSON: Adaptive Cards is a 'description' or a 'recipe' for how a Card should be structured, the styling or skinning of the Card is then subsequently customized by the service into which the Adaptive Card is deployed.
- Write once, deploy everywhere: This is obviously great, as you can write the layout of your Card once and then different solutions will take care of making your Card appear native for the respective application.
- Rich functionality: Microsoft has included a lot interactivity for Adaptive Cards. They offer a wide range of inputs like dropdowns, text boxes and button and individual sections can be dynamically shown or hidden. This exceeds the range of functions, that Alexa Presentation Language or Slack Block Kit offers.
- Even supports voice: As part of the JSON in which Cards are defined, admins can even specify what should be read from the Card if voice output is available.
Challenges when using Adaptive Cards
However there are also some drawbacks to using Adaptive Cards, namely:
Little cross-platform support:
Aside from Webex Teams, there isn't a single provider outside of Microsoft that supports Adaptive Cards. If you're project should work on either Slack, Alexa or Google Assistant, then you will need to support their respective frameworks separately.
Arguably even within Microsoft there isn't universal support for Adaptive Cards as not even Skype has made them generally available.
No built-in business logic:
Adaptive Cards are static, so they just show what you gave them. This means here is a list of things you need answer someway else:
- User authentication: Who is looking at the Card and what content may they see
- Data binding: How do I get dynamic data like numbers into my Card's JSON
- Conditional showing/hiding of sections: Do you want to hide a section if a condition in the data isn't met, or see a list of items when there are too many
- Multi-lingual/Localization: If you speak French you want to see French labels, and if you're European you want European date formats, etc.
- New data: If the data from an API changes, how will the Card get refreshed or recalled
- Natural language understanding: How will the Card appear? What will take care of understanding what the user wants
With the exception of the last point maybe (which Bot Framework would suitably take care of), none of these questions can be handled with Adaptive Cards.
Update 2019: Data binding has been announced for version 2.0 so that may potentially make Adaptive Cards so much more powerful.
This may not be a big problem however! Not having business logic baked into Adaptive Cards is not a problem. That simply isn't the mission they're after!
It's like comparing HTML with a CMS. One is simply a technology (HTML or in our case 'Adaptive Cards'), the other is a fully fledged platform (CMS) that handles and manages a plethora of tasks.
So if you're after a CMS for Cards, then you will find Adaptive Cards alone (even including Bot Services) isn't going to be a one-stop shop.
Despite only a small number of platforms that support Adaptive Cards, they use different versions which differ in functionality. For example at the time of writing, Microsoft Teams was on version 1.0, Webex Teams on 1.1 and Bot Framework on 1.2.
With that there might be some odd constraints when making a pretty looking Card, for example you need v1.1 to show specific image sizes, or v1.2 so you can show Action buttons in places other than along the bottom.
In a future v1.3 it looks like we might get media queries for responsive layouts, as well as GIF and SVG support. While cool this just exacerbates the problem that your pretty Card may not look so pretty everywhere.
How we do it
With Digital Assistant we want to give users the most native experience for the platform they're using. We have our own Assistant Cards which are HTML5, but we show those only in a browser environment.
For Microsoft Teams we translate this Card into an Adaptive Card on the fly.
For customers almost more important is that, if they use Alexa, Slack or Google Assistant we also handle transforming their Assistant Cards for these platforms. This is not an easy task as they all work completely differently in terms of their layouts, the buttons they allow, the number of inputs they handle, etc.
So to our mind using Digital Assistant is the only true 'write once, deploy everywhere' way to use a Card-based UX across multiple platforms and device categories.