Add a "TEST" message to survey landing page if in test mode

[virginiascarlett]

Description

Hi,

Just a suggestion, I think it would be nice if there were a failsafe against doing what I just did, which is accidentally deploying my survey to hundreds of people, only to discover that I'd left ignore = TRUE in the sd_db_connect() call. I was making a quick edit to the survey locally and I told myself, "I'll remember to change it back", but of course I forgot.

I'm not sure what the right design for this would be in terms of implementation, but I think in terms of UX, I'm imagining a banner or big text box that says "this survey is in preview mode, your responses are not being recorded" while ignore = TRUE.

Thanks for considering it!

[jhelvy]

Hi, so sorry you had this experience. We talked about this internally before, but ended up not doing this because setting ignore = TRUE is sometimes desirable, e.g. if you're running a survey entirely offline and want to store data locally only in the preview_data.csv file. I personally have had exactly this use case where I had no internet signal at an event, so I just ran the survey locally from an R session and it worked perfectly.

I agree it's a problem though if in most cases people probably intend on running it with a db connection. Perhaps a different argument could be passed, like local = TRUE if you want to run explicitly local, and all that would do is override the warning message. So if you had ignore = TRUE and local = FALSE (the default), you'd get the warning message on the survey. The message could also say to set local = TRUE if you intended to run the survey locally, something like that. What do you think?

[virginiascarlett]

It's okay, it wasn't for a scientific study or anything, so not a disaster. But it was a very educational experiment lol.

I think your proposal makes sense. The only thing I might suggest is perhaps instead of local = TRUE, something like show_banner = FALSE, so it's very clear that that argument merely toggles the warning banner.

[jhelvy]

I've just pushed a change to a new branch where I replaced the ignore parameter in sd_db_connect() with a new
mode parameter that cleanly separates three distinct operating states:

Live deployment — connects to PostgreSQL (default): db <- sd_db_connect()

Preview/testing — saves to preview_data.csv, shows a red warning banner: db <- sd_db_connect(mode = "preview")

Local/offline — saves to local_data.csv, no banner: db <- sd_db_connect(mode = "local")

I'm leaning towards this because ignore = TRUE was conflating two different intentions:

1. Testing before deployment — where a visible warning makes sense
2. Intentional offline data collection — where no warning is desired

The new mode parameter makes intent explicit and is the single source of truth. There's no separate flag to forget — changing
mode from "preview" to "database" (or removing it entirely, since "database" is the default) is the only change needed to go live.

What happens in preview mode:

• A console message prints at startup confirming the mode
• A red banner is fixed to the bottom of every survey page: "⚠ PREVIEW MODE — Responses are not saved to the database. Do not share this survey link."
• Data is saved to preview_data.csv

What happens in local mode:

• A console message prints at startup confirming the mode
• No banner is shown (offline use is intentional)
• Data is saved to local_data.csv

Backward compatibility:

ignore = TRUE still works but is deprecated with a warning pointing to mode = "preview"

One open question: I'm also wondering whether sd_db_connect() is the right name for this function now, since in "preview" and "local" modes no database connection is made at all. A name like sd_connect() might better reflect that this function
configures how the survey handles data generally, not just database connections.

Curious what you think? Tagging @pingfan-hu as well to ask his thoughts.

[pingfan-hu]

After debating, I agree that we could introduce a new "local" parameter that distinguishes from "preview" and "database". Then, it's reasonable to give a notice in "preview" mode.
And yes, I agree with changing the function name to sd_connect() since it's not necessarily about database, but about how we store data.

[jhelvy]

I did some testing and it's looking pretty good. Here's what you see if you're in preview mode:

I also added a message for if you have the mode set to "database", but the database connection fails:

I thought this was important because you don't see if the connection fails except for in the console log. The survey still launches and you might accidentally deploy it without noticing that it's not correctly configured.

[pingfan-hu]

Amazing! Yeah I think this solves the problem! @virginiascarlett Let us know what you think!

[virginiascarlett]

Fantastic. This all looks and sounds great. Thank you for making the change, and so quickly!

[jhelvy]

I'm still going back and forth with a design setting on this. While it works functionally to add a mode argument to sd_db_connect(), it still doesn't quite feel right to me to put it in that function because this controls more than just the database connection. It's is a survey-wide setting that affects UI behavior (the banner), data storage, and potentially other things in the future. I think it belongs with the other survey settings in the survey.qmd YAML, not as a parameter on a function that's conceptually about database credentials. Something like:

 survey-settings:
    mode: preview

That way the mode will be stored in the _survey/settings.yml like all other settings, and the sd_db_connect() function will read from these settings. So users should never need to touch the db <- sd_db_connect() line - just leave it alone, and if you want to swap modes go over to the survey.qmd and change the yaml. That to me feels like a better placement for this setting, what do you think?

And also, if we do this, then I think we could just leave the function names alone since really nothing else is changing.

[virginiascarlett]

Oooh, I actually like that so much better. When working on the survey, I spent a lot more time looking at survey.qmd than at app.R, so I like putting this important parameter in a place where I'm more likely to see it. And this also feels less disruptive to current workflows, since (I think) it doesn't involve a breaking change.

[virginiascarlett]

BTW, let me know if you'd like me to create a PR updating the documentation to reflect this change. I don't think I can be very helpful when it comes to your codebase, but I would be happy to update the docs if it would save you some time.

[jhelvy]

Oh that's super thoughtful! I've been working in tandem on the docs repo and the main codebase for these edits, so it's all already mostly done, but I'd certainly welcome help on future edits. I'm planning on looking into that matrix check box one you posted.

[virginiascarlett]

Sounds good!

[jhelvy]

This is now fully implemented in v1.2.0.