Botframework-sdk: DCR: AdaptiveCard Prompt

Created on 16 May 2019  路  5Comments  路  Source: microsoft/botframework-sdk

Related

Issue

Link to my AdaptiveCardPrompt:

Samples

@v-kydela and I have answered quite a few questions about how to use Adaptive Cards to capture user input, particularly within Waterfall Dialogs. I think I've answered this same question 5-6 times already.

Normally, my answer is to:

  1. Send the adaptive card
  2. Send a blank text prompt
  3. Set Activity.Text to Activity.Value in OnTurnAsync when message is a PostBack (Adaptive Card submission)

This felt hacky, so I wrote my own AdaptiveCardPrompt.

My AdaptiveCardPrompt improves on the ActivityPrompt in the following ways:

  • Card can be passed in constructor or as prompt/reprompt activity attachment
  • Includes validation for specified required input fields
  • Displays custom message if user replies via text and not card input
  • Ensures input is only valid if it comes from the appropriate card (not one shown previous to prompt)

Proposed change

  • Adds an AdaptiveCardPrompt class

Component Impact

  • None

Customer Impact

  • None

Tracking Status

Samples

  • [X] [Experimental Dotnet](https://github.com/microsoft/BotBuilder-Samples/pull/1616)
  • [X] [Experimental JS](https://github.com/microsoft/BotBuilder-Samples/pull/1616)

Dotnet SDK

  • [ ] PR
  • [ ] Merged

Javascript SDK

  • [ ] PR
  • [ ] Merged

Java SDK

  • [ ] PR
  • [ ] Merged

Python SDK

  • [ ] PR
  • [ ] Merged

Emulator

  • [ ] PR
  • [ ] Merged

Samples

  • [ ] PR
  • [ ] Merged

Docs

  • [ ] PR
  • [ ] Merged

Tools

  • [ ] PR
  • [ ] Merged

[dcr]

Most helpful comment

I plan to work on this too.

AdaptiveCardPrompt spec ideas:

  • [X] Allow options to be specified when the prompt is constructed or when BeginDialogAsync is called.
  • [ ] Include an AdaptiveCardBuilder class that specializes in the kinds of cards that work well for AdaptiveCardPrompt. It could create an Adaptive Card from just a list of information that the developer wants to get from the user, kind of like FormFlow.
  • [ ] Allow the prompt to accept an Adaptive Card as a JSON string (or possibly a JSON file) or an AdaptiveCard object or an AdaptiveCardBuilder object.
  • [ ] Allow simple validation options like "require all fields" as well as highly specific validation options like a delegate for each individual field.
  • [ ] Allow reprompting options that can either modify the existing card in place to show which fields are invalid or send a new card. There should be an "auto" option that checks if the channel supports message updates.
  • [ ] Allow control over reusability of the card. If the channel supports message updates then the card could be deleted or have its button removed. Otherwise, the submit action should contain metadata that binds the card to the Adaptive Card prompt. That would mean all Adaptive Card prompts would automatically know to ignore submit actions that are from the wrong card, but if the button is clicked outside of the Adaptive Card prompt then it would be up to the developer to write code in their activity handler to ignore those actions.
  • [ ] Account for situations when the user enters text input or sends an attachment during an Adaptive Card prompt. The prompt could then make sure its card is the most recent message in the conversation by resending it and optionally deleting the old one. Because it might be ambiguous to the bot whether an activity has actually been rendered in the conversation or not, it might be a good idea to have deleting the old message and sending a new message be the default behavior, rather than updating the old message.

All 5 comments

I've seen enough demand that I'm going to continue working on this in the following order:

  • [X] [Implement in C#](https://github.com/mdrichardson/botbuilder-dotnet/blob/adaptiveCardPrompt/libraries/Microsoft.Bot.Builder.Dialogs/Prompts/AdaptiveCardPrompt.cs)
  • [X] [Write tests for JS](https://github.com/mdrichardson/botbuilder-js/blob/adaptiveCardPrompt/libraries/botbuilder-dialogs/tests/adaptiveCardPrompt.test.js)
  • [X] [Write tests for C#](https://github.com/mdrichardson/botbuilder-dotnet/blob/adaptiveCardPrompt/tests/Microsoft.Bot.Builder.Dialogs.Tests/AdaptiveCardPromptTests.cs)
  • [X] [Submit examples to Samples/Experimental repo/branch](https://github.com/microsoft/BotBuilder-Samples/pull/1616)

I plan to work on this too.

AdaptiveCardPrompt spec ideas:

  • [X] Allow options to be specified when the prompt is constructed or when BeginDialogAsync is called.
  • [ ] Include an AdaptiveCardBuilder class that specializes in the kinds of cards that work well for AdaptiveCardPrompt. It could create an Adaptive Card from just a list of information that the developer wants to get from the user, kind of like FormFlow.
  • [ ] Allow the prompt to accept an Adaptive Card as a JSON string (or possibly a JSON file) or an AdaptiveCard object or an AdaptiveCardBuilder object.
  • [ ] Allow simple validation options like "require all fields" as well as highly specific validation options like a delegate for each individual field.
  • [ ] Allow reprompting options that can either modify the existing card in place to show which fields are invalid or send a new card. There should be an "auto" option that checks if the channel supports message updates.
  • [ ] Allow control over reusability of the card. If the channel supports message updates then the card could be deleted or have its button removed. Otherwise, the submit action should contain metadata that binds the card to the Adaptive Card prompt. That would mean all Adaptive Card prompts would automatically know to ignore submit actions that are from the wrong card, but if the button is clicked outside of the Adaptive Card prompt then it would be up to the developer to write code in their activity handler to ignore those actions.
  • [ ] Account for situations when the user enters text input or sends an attachment during an Adaptive Card prompt. The prompt could then make sure its card is the most recent message in the conversation by resending it and optionally deleting the old one. Because it might be ambiguous to the bot whether an activity has actually been rendered in the conversation or not, it might be a good idea to have deleting the old message and sending a new message be the default behavior, rather than updating the old message.

I think this has been addressed here, closing this for now, feel free to reopen if we need it.

Was this page helpful?
0 / 5 - 0 ratings