Show Onboarding Modal to Newly Registered Users

[jmoldyvan]

Related Issues

• Project: Onboarding #23
• Depends on:
  • Create Modal and Form for Onboarding #61
  • Handle Form Submission #62

Description

• Create a migration to alter the users table and add an is_onboarded boolean field.
• Update the User model to reflect the changes.
• On the homepage, if is_onboarded is false, set it to true, and show the onboarding modal to the user.

Acceptance Criteria
User model is changed
Migration for the users table has been created
Onboarding modal appears after first login
End-to-end tests have been created

[timmyichen]

Is this necessary? It wasn't in the tech spec - I think we should avoid adding one-off flags to tables if at all possible

[Caleb-Cohen]

Is this necessary? It wasn't in the tech spec - I think we should avoid adding one-off flags to tables if at all possible

How do you recommend making the modal appear for testing?

[timmyichen]

I guess I meant specifically the idea of modifying the user schema to account for this.

A more flexible option would be to add an additional tables flags or something that has the following schema:

• user_id foreign key to users (id)
• flag_name that represents the flag we are setting.

For example, in this case, once the user 1 has seen/completed onboarding, we'd insert a new row (1, 'onboarding').

We'd also add additional routes for fetching a user's flags:

const flags = await Flags.findAll({ where: { user_id: user.id } });
return flags.map(flag => flag.flag_name);

This could then be returned as part of the "current user" object which can then be used to determine other logic, such as when to put someone through onboarding.

As far as how we make the modal appear, I disagree that it should be a modal at all, because:

1. they're far too easy to skip/dismiss and people often do so out of habit
2. we draw attention to the onboarding elements/forms by putting it on its own page so that there's nothing to distract the user
3. if we have multiple onboarding steps, it's a lot easier to manage the flow of web pages than to have logic to determine which modal to show, and the order to show them in

[Caleb-Cohen]

I guess I meant specifically the idea of modifying the user schema to account for this.

A more flexible option would be to add an additional tables flags or something that has the following schema:

• user_id foreign key to users (id)
• flag_name that represents the flag we are setting.

For example, in this case, once the user 1 has seen/completed onboarding, we'd insert a new row (1, 'onboarding').

We'd also add additional routes for fetching a user's flags:

const flags = await Flags.findAll({ where: { user_id: user.id } });
return flags.map(flag => flag.flag_name);

This could then be returned as part of the "current user" object which can then be used to determine other logic, such as when to put someone through onboarding.

As far as how we make the modal appear, I disagree that it should be a modal at all, because:

1. they're far too easy to skip/dismiss and people often do so out of habit
2. we draw attention to the onboarding elements/forms by putting it on its own page so that there's nothing to distract the user
3. if we have multiple onboarding steps, it's a lot easier to manage the flow of web pages than to have logic to determine which modal to show, and the order to show them in

Are flags a separate object or directly attached to the user object?

[timmyichen]

Separate table, but has a relation to users