lentinj
commented
2 years ago As well as more interesting tours, this also would allow us a more generic way of implementing exit_confirm, which just becomes another tourstop that we visit on interaction.
To implement these sorts of things we at least need:
- [ ] A way of saying "this tourstop isn't part of the normal prev/next" flow (this could just be allowing
"ts-first" = trueandts-lastto be defined intemplate_data, since this is what we use anyway.) - [ ] A "to tourstop (x)" command
- [ ] A "previous tourstop" command, i.e. whatever one we jumped from, not (x-1)
- [ ] JSON specification of which buttons appear at bottom (and in the process removing the tourstop dropdown).
A treasure hunt wouldn't need any core Tour.js code changing, the tourstop could have it's own javascript to intercept the node clicks and generate corresponding tour commands.
jrosindell
Suppose we want a tour stop to have a multiple choice question that you have to get right to move on, or that takes you to a different next stop depending on how you answer. This can be achieved just by generalising the 'next' and 'last' buttons to call a function that jumps you to any other tour stop instead.
Suppose we want a treasure hunt tour where you have to navigate by zooming to a given destination to advance, this could be achieved by adding another type of transition to the tours framework and having the tour listen to clicks on nodes so that it can react to that and advance if it wants to. The tour could if we want to be cruel, access the UI and switch off search, or could pop up a timer so users compete to find all places in the least time.
These functionalities make tours a lot richer because you can create games, exams, make your own adventure stories and all kinds of other things with very little extra groundwork over and above what's already being done.