Card Visual Block
Card Block Define a new block in convoworks with name Card Block which will make it easier to work with cards on Amazon Alexa, Google Assistant, Facebook Messenger and Viber.
Block Properties itself:
- item -> preferable this is the selected object of an list item ow which we want to perform certain actions like order, even more details, call and so on (just a object no more no lesss)
- item name -> under which name to store data item name
- back button visible -> choose between hidden or visible back button. (works only on Alexa)
- data item title -> Title of the item which will be displayed on the card
- data item subtitle -> subtitle of the item which will be displayed on the card
- data item description -> primary description of the item which will be displayed on the card
- data item image url -> link to the image of an item in the card (preferable an https link should be used)
- data item image text -> accessibility text of the image of an item in the card (Required if you want to display the image.)
Block Containers:
- Read Phase -> display the card itself (this is added automatically) and support is added for other convoworks responses such as text response, set parameter, if and so on. Also if the text is added the default text response will be overridden.
- On No Screen Supported -> will be executed instead if the device has no support for a screen
- Card Actions -> will be executed when an action of the issued card was selected (more on those card actions later)
- Additional Processors -> will be executed of another things of other processors are matched
Card Actions:
- this should be a specialized processor
- its filter checks for a card specific card event or utterance or anything of this nature
- this should be defined in an separate interface and checked as the specified interface to avoid confusion between CardActionProcessors and Other Convoworks Processors.
Additional specifications:
- Define new request interfaces IConvoCardRequest which will make it easier to get values from those requests from each platform and implement them in each PlatformRequest
- Define new response interfaces IConvoCardResponse which will make it easier to define the final response for each platform and implement them in each PlatformResponse
Please also refer to the Dummy representation of the Card Block.
Couple things I would like to point out
- This seems quite much related to the #9 lets see if they have similarities (talking about interfaces primary)
-
IConvoRequestandIConvoResponseextensions should be treated as separate task/issue (and covered with unit tests?) - The second task is actually a workflow component design and here is the major question should it be implemented as Block or should it be implemented as separate Element and separate Processor/Filter components
Here is an quick overview of the interface infrastructure for the Card Visual Element.
IConvoCardRequest makes it easier to detect any selected card action after a card response was sent.
interface IConvoCardRequest extends IConvoRequest
{
/**
* @return string
*/
public function getSelectedCardAction() : string;
}
IConvoCardResponse makes it easier to declare an card response.
interface IConvoCardResponse extends IConvoResponse
{
public function getCardResponse(IVisualCard $cardItem) : array;
}
IVisualCard is used in IConvoCardResponse->getCardResponse(IVisualCard $cardItem) card response. This definition makes it clearer how the CardResponse should be formed.
interface IVisualCard {
public function getCardVisualItem() : IVisualItem;
public function getCardActions() : array;
}
IVisualItem is part of CardResponse.
interface IVisualItem
{
public function getTitle() : string;
public function getSubtitle() : string;
public function getDescription() : string;
public function getImageURL() : string;
public function getImageText() : string;
}
ICardAction is used to render buttons in card responses.
interface ICardAction
{
public function getCardActionKey() : string;
public function getCardActionName() : string;
}