One good reason not to use TypeForm
TypeForm is a tool that helps us get people’s feedbacks about many things at StudyLink, and we’ve chosen this particular tool because of it’s quality and the agility it gives us.
But, we won’t tell you why you should use TypeForm, we’ll rather tell you in what use cases you shouldn’t, based on our experience.
Maybe that will help you avoid the downside we recently came across, which slowed us down, because we didn’t anticipate/expect it.
Edit 27th May, 2019: Typeform has released a new feature around April 2019 that allows to customise “questions ref” directly through the Typeform builder UI.
Meanwhile, Nicolas has improved his tool https://tf-edit-ref.glitch.me/ which offer more advanced features such as editing “responses ref”, which isn’t yet available from the native Typeform builder UI.Edit July 5th, 2018: Since this post, a developer @Typeform, Nicolas Grenié has made a tool, which connects to your TypeForm account and allows you to edit the ref attribute for every forms and fields: https://tf-edit-ref.glitch.me/
This is basically what’s missing within TypeForm GUI, and is the best/easiest workaround I’ve come across so far.This tool doesn’t store any credential, it just uses TypeScript APIs to authenticate your account and gives you a temporary access (session) to it. Nothing is stored anywhere.
You can get in touch with with him on Twitter if you need additional information https://twitter.com/picsoung/status/1013922525724606464Kudos to him for coming up so fast with an alternative solution, I still hope a proper solution gets implemented quickly within TypeForm itself to avoid relying on an external tool.
In order to understand those limitations, we will first dive into how TypeForm works, from a user “form builder” point of view.
There are many ways of using TypeForm, amongst those:
- Manually, without processing results dynamically:
You create your TypeForm by hand, and you don’t need to build some complicated tool for data processing behind it, maybe you don’t process data at all, or you use the standard ones like Google Sheets, Zappier and alike.
- Programatically, using the APIs:
You can also create your TypeForm programatically, they have several APIs for different purposes, basically creating forms, fetching responses, and configuring web hooks.
In this case, you need a developer. Not everybody has the technical skills to build a form programatically or fetch results, it requires particular skills, unlike creating forms through their GUI, which is very simple to use. - Manually, with custom results processing:
A common case, at least we thought. But that’s where you’ll meet a big limitation, which makes this use case unusable.
Let’s say you want anyone in your team to be able to build a form. (therefore through TypeForm GUI)
But you also want to process your end-users responses, so you also use their Responses API to fetch those results and do whatever processing you need with them.
Our use case was straightforward, we wanted to ask questions, and then process the responses to those questions to provide our end-user with a result.
Under the hood, this requires to redirect the end-user to a web page, once he has submitted his form. The web page would fetch his Responses, process the response and finally display the results.
That’s it, nothing fancy. An advanced use-case for sure, but nothing fancy.
Why it is so hard to process TypeForm responses for a manually created form?
First, let’s take a look at what the TypeForm GUI has to offer when you are configuring a field:
It looks great, right? But something is missing. Can you guess what? We missed it at first, and when we realised it, we thought there would be another way…
But, sadly, there is no way to define a “field’s name”.
There is no way to tell TypeForm that we want to define a name for the input “Nom de la startup”, there is no way to name it
startup_name, for instance.
But how is that an issue?
Well, it may not be an issue when you don’t need to perform additional data processing, but it certainly is when you are relying on it.
Because, when fetching Responses, you can’t programatically tell which replies is related to which question. And that’s a big headache for any developer trying to process those data since he can’t tell what is what.
Here is what you get, when you fetch end-user data by using the Responses API:
This is the data you get from the Responses API. Do you notice the ref attribute? It is an identifier and its value is auto-generated by TypeForm, in this case, it’s 5f965ea6-fafb-4392–87b4–71426d00ba99.
What a developer would need instead of this auto-generated identifier, would be a field name. Something like startup_name , for instance, in this case.
Without proper variable naming, everything gets quite complicated from a developer point-of-view. And what was supposed to take seconds (matching the text “StudyLink.fr” with the field “startup_name”) now becomes much, much harder.
Technical workarounds #hacks
Of course, there are workarounds, the first thing you can do about this is building your own, hard-coded, index table, which will help making sense of those unknown ref attributes and match them with a proper variable name.
You “just” need to first build your form, then use the Response API, and build the index table by associating auto-generated refs with a proper variable name.
This is error prone, cannot be automated, very hard to debug if you make any mistake when manually building the index, not scalable -you have to do it for every form, as new refs will be generated-, anyone modifying the Form can break the software -by removing then adding a field back again, a new ref will be generated, causing havoc-, you won’t be able to add a new field without manually modifying the index, etc.
Another solution may be to use TypeForm API to change the ref of your form once it’s built:
If you read thoroughly, you’ll notice how complicated this is, if you forget a field then it’ll be deleted, and there are no good example about how to do this in the documentation either. Let’s say it’s a “less worse” solution, maybe.
Isn’t there a proper solution?
Well, there is one.
If you read the API documentation about creating a form, you will notice (in the example at the bottom of the page) that you can specify a custom ref attribute for every field.
It is therefore possible to specify a custom name for each input, when building the form programatically, through TypeForm API.
But, it is not possible to do so when creating the form through the GUI.
We contacted the support about this limitation and here is their official answer as of July 1st, 2018:
It isn’t something that is on our Roadmap right now but, to be honest, you’re far from the first person to request this and I will be sure to give your feedback to our Product Team. — TypeForm Support
It is both sad and frustrating, especially considering they just need to add an input on their GUI to allow to define a custom ref for each input.
They could probably deliver this faster than we did writing this article!
If you’ve encountered such or similar limitation using TypeForm, please let us know! We’re also interested about alternatives to TypeForm.
Thanks for reading, we hope they resolve this limitation as soon as possible because it’s still a great product overall.
