Adaptive Cards

I maintain a list of Adaptive Cards projects and resources here:

https://github.com/miguelrochefort/awesome-adaptive-cards

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.

3 years ago by jagged-chisel

Docs are 404, the Heroku app is nonexistent … is jasonette still alive?

3 years ago by easrng

https://github.com/jasonelle/jasonelle/wiki/History

3 years ago by dchuk

Interesting, seems similar to what Joel is doing here: https://blockprotocol.org

3 years ago by vladsanchez

Coincidence? This all reminds me of [https://en.wikipedia.org/wiki/Microformat]

3 years ago by michaelmior

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.

3 years ago by hyperrail

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.

3 years ago by valgaze

+ 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

  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}})

const fullCard = myCard.render() // JSON passed to an API/client

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

3 years ago by spankalee

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.

3 years ago by paulcam206

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.

3 years ago by jacknews

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?

3 years ago by paulcam206

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

3 years ago by nsriv

Perhaps the video is, but your questions are answered in the text above the video.

3 years ago by eliseumds

Wow, this is very hard to read. It should be illegal to use light grey text on a white background.

3 years ago by Tao332

It's technically black, but the font weight is ultra ultra light.

3 years ago by thermin

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".

Adaptive Cards

Daily Digest