To implement this use case, there are a couple possibilities using the current feature set (both of which I’d consider to be workarounds; see the note at the end about upcoming features):
This first solution shows the user one card, but is requires more development effort. If there is a reasonable upper limit to the number of options, one solution is to create a number of cards equal to this upper limit, with each card having a different number of
On Select actions. Then, depending on the number of options we would like to show, only display the card that has that number of options – this is probably done most easily using a collection-structure view. Note that for a given card, each action will have to point to a different script. This means that we will end up with scripts named something like
selectOption2, all the way up to
selectOptionN. If the actions are labeled like
Option 1, then the user can say those labels to enact the associated script for that option and then depending on the current data in
skylight.session.data, the new location can be shown.
This second solution shows the user multiple cards, but is easier to develop and maintain. The different options can be put into an array in
skylight.local.data, then a card in a list-structure view can set that array as its context. This will create one card for each of the options. In the same list-structure view, we can have a summary card before this array-databound card, which can show the user what the possible options are (similar to the attached photo). The user can then scroll to the appropriate card and select it, which will then bring up the location information.
There are a couple upcoming features that will help in making this easier to implement.
The first, which is further along in the development process, is the ability to databind the actions on the card. This will allow developers to show a dynamic number of actions – this use case is a fantastic example of what we’d like to solve with that feature.
The second is the ability to perform a voice-based search of cards. This is farther on the roadmap, but would enable the second workaround to work without the user having to scroll to the location card; they will be able to speak the label associated with that card even while having the summary card selected. In effect, this would also solve this use case.
If a better end-user UX at the cost of development is desired, I would suggest the first workaround. When the new action sheet-databinding feature arrives, it will require some development effort to simplify the application to use the feature, but the end-user UX will remain pretty similar.
If faster development at the cost of more steps for the end-user to select the location is desired, I would suggest the second workaround. When the voice search feature arrives, it will require minimal development effort to enable this and the user experience will change (for the better) as it will then be more similar to the single-card UX.
Feel free to reach out if there are any questions about the particular workaround methods.