Build a survey tool for non-Anvil developers

Anvil Q&A
#1

Hi all,

I would like to build a survey tool (like Microsoft or Google Forms).

The application would allow users to build surveys, without them having to be Anvil developers (thus without using the Anvil developer IDE).

If I create a “survey builder” app, how could a non-Anvil user “spawn” a new application based on information in the “survey builder” app?

Open source survey and reporting platform
Replacing google forms
#2

There is a way to make it look like a separate Anvil app, without it being a separate Anvil app.

  1. Put all of the per-user data in tables. (This would include questions, answers, color schemes, icons, titles, etc.)
  2. In each such table, include an “owner” column.
  3. Use Client-writable views to ensure that the current user sees only their own data.
#3

Thanks for the suggestion. I think that makes the most sense.

In order to share a given survey, I was thinking I could add a survey ID as a parameter to the app’s URL, and then use get_url_hash() to pull that data and build the appropriate survey.

Does that sound like a reasonable approach to you?

#4

Yes, it does.

IDs should probably not be sequential numbers. Otherwise, people will find it easy to guess IDs that do not belong to them.

#5

Agreed!

Thanks for helping me through that. It is an ambitious project but it would be great to tailor a survey tool to our specific needs.

Thanks again.

#6

For what it’s worth, I think you’ve picked the right tool (Anvil). We had considered

  1. emailing questionnaires in PDF format (with embedded JavaScript for sanity-checking)
  2. LimeSurvey
  3. JotForm

But all of those require substantial additional infrastructure to make them effective. At the time, some of them also had serious limitations in the kinds of answers we could capture, the screen layout, or both.

Once we had a good look at Anvil, we never looked back. :star_struck:

#7

That is encouraging.

I’m trying to suggest to my team that, in the long-run, we’re better off building a custom internal tool for this, rather than paying additional licensing costs for a “one size fits all” product. Further, even if an off-the-shelf survey tool is affordable, Anvil is just so customizable that in my mind, it wins anyway.

It’s good to know others have done this. Thanks.

#8

Here’s how I would go about it, if I’m correct in what you’re imagining:

There are two types of user for this app: ‘survey creator’ users, and ‘survey fillers-in’. You can store all your uses in the Users table and use the standard login form - just create a ‘role’ column in the Users table to switch to a different workflow for each type of user.

I’m guessing you want each ‘survey creator’ user to be able to construct surveys by entering what questions the survey has, potentially with page numbers so that the survey can run over several pages. At that point it’s essentially the TODO list app.

You would store all the questions for all surveys in a single ‘questions’ table. You would have a ‘surveys’ table, and each survey row links to multiple rows in the ‘questions’ table.

Then you could present the ‘survey fillers-in’ with a list of surveys. When they click on each survey, they get a new view that lists the questions, with input boxes. The ‘survey creators’ could have the option to choose what sort of input box each question should have.

Answers are stored in a table that links each answer to a survey, question and user (and possibly an id to distinguish different fillings-in, if a user can fill in the same survery multiple times.) Then you can present views of ‘average answer’, ‘last 10 answers’, ‘surveys you’ve filled in’, and you can prevent a user from filling in the same survery twice if you want to.

1 Like
#9

Thanks Shaun. This is very helpful information.

#10

I might even be inclined to make two separate apps: one for the Survey Creator, and one for the Survey Filler, and share Tables between them.

  1. The Creator app is likely to need Tables not needed by the Filler app, so these would not be shared.
  2. Dividing the responsibilities this way is likely to make each app much simpler. Without them, your code may end up constantly asking “which mode am I in? Creator or Filler?”
1 Like