Background

It will support:

• displayText (optional string for text to display on transcript)
• image (optional image for the button)
• text (optional string to send back to the bot, invisible to the user by default)
• title (optional string for the text of the button)
• value (optional JSON to send back to the bot, invisible to the user)

The user can specify both text and value, although they are mostly duplicated in nature (one as a string, another as a JSON object).

Although all properties are optional, we have a fallback rule if property is missing:

• title will fallback to displayText if it is missing

In the meanwhile, we are not deprecating imBack or postBack. All 3 card actions are supported and there is no plan to add a deprecation warning.

Investigations

• Adaptive Card: how other channels behave? Do they still use postBack or moved to messageBack?
• Do we need a UI to tell the user what they actually sent (text vs. displayText)?
  • Should we tell the user about the actual text property?
  • How about preserve history story?
    • If displayText is not sent to the bot, we might lose it when history is restored.
    • It could be a Web Chat specific feature, i.e. store it in channel data.
  • Answer: No, we don't need to tell the user what is actually sent.
• How to surface retry logic if the messageback activity failed without text/displayText?
  • Post back is broken today, but I want to make sure messageback don't break again.
  • If you have no clues on this, I can run it thru our UX designers.
  • Answer: For visible response, use the standard "send retry" status. For invisible response, modify the button to let the user to retry clicking on it.

To-do

• Implement in suggested actions
• Need investigation: Implement in Adaptive Card (card actions)
• Talk to Adaptive Cards team to see if they can help on the UX for "retry postback"
  • If a user click on a button on Adaptive Card and is failed to send, we should try to surface the error to that button [Edit] - diverting this one to Story: how to retry when postback failed? #1119 since @DesignPolice is working on it