Best practices for using custom requirement types
Evaluate the correct requirement type to use from these three different categories:
- Static data set: If a requirement is one of a static data set, for example, LOC1, LOC2, LOC3, a Restricted Custom Requirement Type is the best option.
- Standardized data set: If a requirement follows a general format such as three capital
letters followed by a number, for example, LOC1, POC2, HCM3, use an Expanded Custom
Requirement Type. You can provide examples of this format in order to accept varieties of
that same format as input. For example:
- ABC9 is valid.
- HBO MAX 9 is invalid.
- Small dynamic data set: If the other 2 options are not viable, the best recommendation is
to look up the available options and insert them into a Dynamic Multiple Choice prompt. Then
the user can directly select the answer rather than a potential misunderstanding.
Although Coleman supports up to 250 options with the multiple-choice approach, the user will have to iterate over 6 options at a time in a telephone operator style when using Alexa. For example, Say 1 for LOC1, say 2 for LOC2, etc. If this is not practical, consider checking the number of options planned on being dynamically prompted. If possible, attempt a secondary lookup with a search parameter to help narrow the size of the options being prompted. This can alleviate having to prompt for too many options.
For example, prompt for the first requirement. If Coleman detects 200 options, have Coleman prompt the user for a second requirement such as region. Re-run the search with the additional parameter to result with 50 options, which will then be dynamically prompted.
If none of these 3 options are viable, then evaluate the objective of the skill. It may be a better experience to navigate the user to a page to fulfill the skill instead of navigating through a requirement that is often misunderstood.