Very interesting idea because it can be much more platform agnostic then html. Ideally resulting in moving away from the html everywhere, which often means including a separate browser everywhere and non native UIs.
I do agree with you that it should catch on more and it's unfortunate that it hasn't.
ex. You can do something like this: https://i.imgur.com/dcbzn3w.gif
I do a lot of thinking about conversation design "tooling" for automated agents and I found wrangling Adaptive Cards with "dynamic" content was a bit annoying since there's so many options. I needed a simple subset of functionality to cover most cases and to add features like tappable suggestion "chips"
I made little a utility called "Speedycard" which lets you "build" Adaptive Cards kinda like this:g
const myCard = new SpeedyCard()
.setTitle('System is ')
.setSubtitle('If you see this card, everything is working')
.setImage('https://i.imgur.com/VQoXfHn.gif')
.setInput(`What's on your mind?`)
.setUrl('https://www.youtube.com/watch?v=3GwjfUFyY6M', 'Take a moment to celebrate')
.setTable([[`Bot's Date`, new Date().toDateString()], ["Bot's Uptime", `${String(process.uptime())}s`]])
.setData({mySpecialData: {a:1, b:2}})
While I am convinced about the importance of conversation design and being thoughtful about this stuff sometimes it's convenient to just have a little form and the user adds their data and call it day
Cards source (can use this anywhere): https://github.com/valgaze/speedybot/blob/master/src/cards.t...
Experiment optimized for Cloudflare Workers: https://www.npmjs.com/package/speedybot-hub
Main Library: https://www.npmjs.com/package/speedybot
A subset of HTML designed for easy embedding, possibly removing features and quirks and allowing for a smaller and faster runtime was the goal of the project that directly preceded and led to Flutter. I wish that goal had remained so that we had a cross-platform UI runtime that was still lightweight on the web.
The problem with using HTML (or a subset thereof) to solve this problem is that it necessarily requires HTML rendering on every platform you want to support.
If your intent as a dev is to integrate card-like experiences into an existing app, requiring a web rendering surface might be too heavyweight... and even if apps chose to adopt web rendering, there would still be the issue of getting styling to line up.
The goal of Adaptive Cards is to use a platform's native rendering and controls. Apps should get native performance with native styling.
Of note, these cards may not be originating from within your team, so there's no way to guarantee that card authors will make design choices that fit within the design language of your app. The solution is to only allow for semantic styling choices (e.g. card author can't specify "Ubuntu Mono" as the font, but can specify "monospace"). The app hosting the card gets to define how these semantic choices are actually implemented.
What does this thing actually do, and how does it work?
This video is a good walkthrough covering the type of scenarios that are enabled with their use: https://www.youtube.com/watch?v=wT1yFr_j6IM
Also, "Experience Owners" should be nominated for Buzzword of the Year. It's so incredibly plastic corporate buzzword-y, but actually kind of does give a bit of a buzz when you see it.
I'd be remiss if I didn't mention our monthly Community Calls. Feel free to join in! You can grab a .ics reminder here: https://aka.ms/adaptivecardscommunitycall
It's a healthy project, with multiple development teams within Microsoft both using and contributing to it. If you scroll down the originally linked homepage, you see 4 Microsoft products that have used it, 3 of which are in active development today.
ex. https://docs.microsoft.com/en-us/adaptive-cards/rendering-ca...
It’s just another priority format you need a full blown editor to build your UI in.
Difficult to debug with, but works fine as long as you hardly ever need to change your templates.