Thinking of building with Adaptive Cards? Here's what you should consider

Published Tue 18 Dec 2018

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 simply show you what you gave them. Thus, there are a few 'typical business requirements' you need to implement separately in addition to using Adaptive Cards:

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 which, once released, may make Adaptive Cards much more powerful.

This may not be a big problem however! Arguably, not having business logic baked into Adaptive Cards is not a problem. It simply isn't the mission Microsoft was 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.

Fragmented versions:

Despite only a handful of platforms supporting 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 instance, 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 into the native formats 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.

If you enjoyed this article, you might also like...

Build an AI chatbot for your team in 10 steps

Build an AI chatbot for your team in 10 steps

How to make an employee-facing chatbot with Dialogflow in 10 steps

How to make an employee-facing chatbot with Dialogflow in 10 steps

Oracle Digital Assistant comparison

Oracle Digital Assistant comparison

Try Digital Assistant with your team for free

Get started