In the Adaptive Cards community call for September, Matt Hidinger shared the Q4 roadmap and a sneak peek at a new concept called “Adaptive Components.”

Roadmap Updates

We’ve divided the Roadmap Portal to 3 distinct sections: Under Consideration, Planned, and Launched. This change provides more clarity into what stage any given feature currently is and when you can expect a given enhancement.

Coming in Q4 and Q1 2021 you can expect the following things:

• Templating SDKs for iOS, Android, and UWP. Currently the templating SDKs are only available for .NET and JavaScript. This work will pave the way for exciting improvements once we are able to evaluate template bindings and expressions directly on the client where the cards are being rendered.
• A new Universal Action model for handling actions in your backend in a consistent way, whether the card appears in Teams, Outlook, or elsewhere. We’ll share more details on this shortly.
• In the Rendering/Schema category, we’ve got some nice fit-and-finish improvements under way:
  • Improved accessibility across the board.
  • Text password masking.
  • ChoiceSet is getting a new filtering UX, Auto Complete support, and the ability to trigger an Action when a choice is made.
  • For Actions we’re adding an isEnabled property to disable actions and creating enhanced UX for additional actions by allowing them overflow into a “…” menu.
• And much more that we are still fleshing out the details on…

As always, be sure to vote on the features that are important to you and click that Submit Idea button if you don’t already see it!

Adaptive Components

Adaptive Components are a new concept that enable the creation of high-level UI “components” powered by templating and Adaptive Card elements.

For example, in the card below there are two great use-cases for “components”:

1. The File Chiclet, showing the file icon, title, URL and set of actions.
2. The two “Personas” next to Requested by and Approver showing the profile picture and name.

The way components are used within a Card is by a Component. convention. For example, see the Component.File usage below. Notice only the data is provided to the component, so for files, you pass along the title, fileType, and the objectUrl.

{
    "type": "AdaptiveCard",
    "body": [
        {
            "type": "Component.File",
            "title": "FY2020-Contoso.docx",
            "fileType": "docx",
            "objectUrl": "https://example.com/assets/AdaptiveCardsSpec.docx"
        }
    ]
}

When authoring a component, the creator describes the shape of the data it expects using JSON-Schema and uses Templating and Expressions to transform the data into Adaptive Card elements. Take a look at the GitHub issue for a detailed example of this.

The power of components is really in 3 areas:

1. Allow apps to learn new UI components on the fly. Because Components are purely declarative, we can rely on component registries to allow the fetching of remote components via HTTP.
2. Help bootstrap the sharing of common types of UI among teams internally or with the public. Components can be hosted in GitHub repos and shared with others, making developers much more productive when building Cards.
3. Support multiple views over data. Lastly, we plan to make a component broadly useful, on different Hosts, with different display constraints, and different renderer schema versions. The example below shows a simple “Thing” component that has 3 different views over the same data.

Let us know on GitHub or Productboard if components is something you would benefit from in your day-to-day card usage!

Watch the call here

Resources

• Watch the latest Adaptive Cards session from Build 2020
• Adaptive Cards Roadmap
• Adaptive Card Templating Overview

Next month’s call will be held on Thursday, October 8, 2020 at 9:00am PST. We look forward to talking to you then! Download a recurring calendar invite here at https://aka.ms/adaptivecardscommunitycall.

Check out the previous month’s call recording on our Office Development YouTube Channel