Adaptive Cards(adaptivecards.io)
adaptivecards.io
Adaptive Cards
https://adaptivecards.io/
36 comments
This reminds me of https://jasonette.com/
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.
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.
Docs are 404, the Heroku app is nonexistent … is jasonette still alive?
Interesting, seems similar to what Joel is doing here: https://blockprotocol.org
Coincidence? This all reminds me of [https://en.wikipedia.org/wiki/Microformat]
Would be great to see something like catch on for other chat platforms as well (e.g. Slack, Messenger, etc.). Being able to define a UI once for all those would be great.
Webex's Slack-like chat room service uses Adaptive Cards to define interactive messages from bots, just like Microsoft Teams does.
I do agree with you that it should catch on more and it's unfortunate that it hasn't.
I do agree with you that it should catch on more and it's unfortunate that it hasn't.
+ 1
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
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
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
This is what HTML is for, and if you look at the schema it has many of the same element/container concepts that HTML has.
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.
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.
Probably the first thing to call out is that solving cross-plat UI in the general case is a non-goal for Adaptive Cards. It's not intended to replace e.g. ReactNative. Adaptive Cards exists to allow small snippets of card-like UI to be defined and shared across platforms.
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.
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.
Is it just me or is the video a word-soup marketing pitch of benefits, possibilities etc? 'Open yourself up to content, with adaptive cards'.
What does this thing actually do, and how does it work?
What does this thing actually do, and how does it work?
When I was first introduced to AdaptiveCards, it took me a while to grok just what it's for.
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
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
Perhaps the video is, but your questions are answered in the text above the video.
Seems incredibly like an intentionally style-less, script-less version of HTML: a tree structure of blocks, tables, lists etc with simple actions like "show", "hide" and "submit form".
Looks amazing! It's not every day I see a new technology that actually stands out. I could see a lot of apps being built largely as card galleries.
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.
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.
Hey everyone -- I'm a dev on AdaptiveCards and happy to (attempt to) answer any questions folks might have :)
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
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
Our industry has been chasing the dragon of universal GUI components for nearly as long as there have been GUIs. What's different this time?
Unfortunately it didn't work in Linux Firefox :(
Smells new. Anyone willing to recommend how long to wait before adopting a new MS technology?
Adaptive Cards have been around since 2016: https://github.com/microsoft/AdaptiveCards/graphs/contributo...
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.
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.
It looks like a lot of documentation is pointing to the wrong branch. It took me a minute to understand why I was looking at code that hadn't been touched in 2+ years. The docs are pointing to the "master" branch but everything has moved to the "main" branch.
ex. https://docs.microsoft.com/en-us/adaptive-cards/rendering-ca...
ex. https://docs.microsoft.com/en-us/adaptive-cards/rendering-ca...
filed https://github.com/microsoft/AdaptiveCards/issues/7475 to track :)
It's not so new, but its MS, and the thing didn't look like a popular one, so chances for it to be abandoned are very high, I suppose.
It's also MIT licensed, and we're still very much working on it :)
I don’t believe it’s particularly new. Microsoft has thoroughly embraced this in the Teams API, so I wouldn’t expect it to go away soon.
This has been around for several years now at the least
Use this in teams automation.
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.
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.
Makes sense to have the Markdown equivalent but for UI. (In fact that wouldn't be a bad idea.)
This concept is patented:
https://patents.justia.com/patent/9285977
https://www.wrap.co/
https://patents.justia.com/patent/9285977
https://www.wrap.co/
[deleted]
"there are now 15 competing standards" vibes (https://xkcd.com/927/)
https://github.com/miguelrochefort/awesome-adaptive-cards