Walking Down the Path: Branching Logic
Photo by Einar Storsul on Unsplash
Very simple interviews might just ask a user some questions and spit out some result. Most interviews, though, will want to change what the questions they ask and the results they show based on a user's answers.
Our code has to make a choice and, until the AI take over, we have to give it very specific instructions about how to make that choice. That's often called branching logic. Probably because of trees.
Panel by Randall Munroe from xkcd.com
Suppose you have a friend who comes to you for advice. They were invited to a party, but they're not sure if they should go. You give them advice, your friend is happy, and now you have lots of friends, and even strangers coming to you looking for advice on the same topic. You decide code is the answer and you'll write a simple form to help them out.
You start simple.
Thinking through outcomes
What outcomes will our flowchart have?
- Go to the party
- Stay home
We'll need two ending screens. You make endings screens with an
event specifier in a
question block. Unlike regular question screens, your user isn't going to give an answer here, so there's no variable for Docassemble to find. The
event specifier tells Docassemble how to find the question without needing a variable name.
What do you need to know?
Well, without user research, you don't really know what good questions would be. You don't have funding or time to do that discovery work, though, but you don't care that much about those strangers and it's not like they have other options, so you'll start by making a guess and worry about it later.
Do they even like parties? That seems like a place to start.
Docassemble will show two buttons on this question screen. If the user clicks 'Yes',
user_likes_parties will have a value of
True. If they click 'No', it will have a value of
False. We can use that to help our program decide what to do. Read more about yes/no fields.
If this, then that
We'll use what's called an
if statement. It tells our program, 'if the situation is this, then do that.'
We already learned about using
if statements inside a
question block. The
if statement inside a
code block is very similar. However, we don't need to start our line with a
% symbol. We also use indentation to show the start and end instead of an
So that's not really all that matters, right? For example, do they have a ride or would they have to walk?
We could ask them both questions separately...
...but we'd be wasting their time. If they don't like parties, why does it matter if they have a ride? They want their answer as soon as possible! So we nest the
if statements inside each other. We only ask the second question if they said yes to the first question.
We've put the app out there and people aren't happy. They feel the situation is more nuanced than the questions you have. Add some more questions! What else could you ask? Copy the script above and add some more questions.
Add three more questions to the file we already have. If you are short on inspiration, you could choose from this list:
- Do you have a big assignment due the next day?
- Is it really far away?
- Will it be mostly people you don't know?
- Do you have someone you want to meet?
- Did you promise someone a ride?
The basic steps will be:
- Create a question block for each question.
- Add the question in the right place inside your nested
Turn in your work
Use Blackboard to turn in your work. As you see in the comment at the top of the script, you will need to turn in a link to your working interview, as well as the actual YAML code.
This exercise was prepared by: