Return users to the prior program 🔗

exit, go back

There's a keyword that works particularly well when partnered with *navigation and at least one *program keyword, though it could have simpler use cases as well: the *return keyword, which functions like a high-tech *goto . When users pass over the *return keyword, they go to the very end of the current program they're in, which returns them to wherever they were prior to that.

Here it is in a somewhat simpler form:

Starting program: 🔗
How 'bout we burn a few calories?
*program: Super Fun Exercise
Now we'll do something else!
Super Fun Exercise program: 🔗
*question: Ready?
	This is lame.

Let's get ready to prancercise!

In the above example, users start the program, which then launches into the "Super Fun Exercise" program via the *program keyword. Once there, they have a choice to "Play" or say "This is lame." If they choose the latter, they immediately exit the Super Fun Exercise program via *return , and next see the text "Now we'll do something else!" from the original program. If they instead choose "Play," they'll see the line "Let's get ready to prancercise!" and any lines that follow.

So why use *return when you could instead use a *goto keyword that could direct users to a *label at the end of a program? For one, laziness. You can accomplish the same feat in one line of code instead of two. But suppose you didn't actually know which program users were in? And suppose you instead wanted users to be able to exit out of the current program via an option in *navigation . Sounds weird right? Here's an example to show you what I mean:

I'm gonna randomize you to one of three tools to try. If you get bored with the tool, just click "Exit this tool" at the top of the screen.
*button: Begin

	Exit this tool
		*goto: End

	*program: Tool1
	*program: Tool2
	*program: Tool3

Alright, that's the end!

The *goto keyword does NOT work across programs, so trying to add it beneath this navigation option would be of no use. But no matter which tool users are randomized into, the *return keyword will bring them out of the tool, to the next line in the original program, which reads "Alright, that's the end!" Of course, it doesn't have to be the end here; you could allow users to return to the beginning to try a new tool, or your program could just continue going forward.

Note: If one of the tool programs itself includes an additional *program keyword that leads to a program that would carry the user through two or more screens, and the user is in that second program, *return alone isn't going to cut it; *return only exits the user back one program layer, not several. So keep that in mind if you end up using *return ! It can be tricky to use if the user needs to exit out of a program within a program within a program!