[FEATURE] New placement option for "In-App Survey" -> Component

[DerekWolfie]

Is your feature request related to a problem? Please describe.

It's not really a problem but I believe that it would be an amazing solution for lot's of developers

Describe the solution you'd like

Currently the "In-App Survey" only has modal as embedding. Imagine if I'm a NextJS developer and want to embed my survey on my page but I would also like to make use of the custom attibutes to display different informations like the current logged in user name and so on... It would be really cool if we could embed the survey as a component.

Describe alternatives you've considered

Another alternative would be custom link generation for surveys so that we can generate custom surveys with custom parameters already included

Additional context

No response

[github-actions[bot]]

Thank you for opening your first issue! 🙏❤️ One of our team members will review it and get back to you as soon as it possible. 😊

[JoaoAmadio]

🚀 That's a really good idea! Would help me a lot! 🎉

[mattinannt]

@DerekWolfie Thanks for creating this feature request 😊 Just to clarify: You would like to embed the survey as a (React) component into a page of an existing web-app, right? Should targeting and triggering work the same as with the current version of in-App surveys, but instead of rendering the survey in a modal it would render in a preset div? Or do you just want to embed one specific survey on a website; more like an iFrame?

[DerekWolfie]

@mattinannt Perfect, targeting and triggering should work the same and instead of rendering the survey in a modal it would render in a div with a 'ref' and maybe you could specify the survey ID so that we don't need to create a trigger.

[mattinannt]

@DerekWolfie Understood 😊💪 We already planned a feature like this but first focus on the Modal since with rendering it in a div there is a lot more styling and edge cases for rendering to consider.

@JoaoAmadio @DerekWolfie What are your use case for this? What kind of surveys would you like to display inside a div in your web-app?

[DerekWolfie]

@mattinannt For me it would be more for UX, and the only possible way to register a "person" is using the in-app survey method...

Another "alternative" is the possibility to set "person" properties/attributes and custom attributes directly in the URL (safely, without URLSearchParams. Like, encrypted parameters), so we don't need a component for that.

***The MAIN idea is to be able to define user data and custom attributes, attaching them to the survey without the need to authenticate an user, for example, we would still be able to know who answered the survey. But then again, the only way to achieve that is using the in-app survey.

[mattinannt]

@DerekWolfie You can also create a person via the API and we also have an API package (that still needs a bit of documentation): https://www.npmjs.com/package/@formbricks/api

But you could use this to manage your person in your app and embed an iframe survey where you append the userId of the newly created / managed person: https://formbricks.com/docs/link-surveys/user-identification

[DerekWolfie]

The thing with link survey is that they expose custom attributes (hidden attributes) and can be changed...

With the in-app survey component, hidden attributes will be passed directly to the component

[jobenjada]

Hey @DerekWolfie and @JoaoAmadio - thanks for your requests :)

When we designed what the Formbricks Surveying Infrastructure should be able to do, we approached it from two angels: Depth of Integration and Ease of Running Surveys.

Tech Architecture Approach

To be able to facilitate a lot of different use cases with the same technical infrastructure, we separated the different functionalities needed into different packages:

1. API Wrapper ✅: Makes it easy to send data to the Formbricks APIs
2. Formbricks JS ✅: A headless widget to handle triggers and targeting (@mattinannt we should call this "Targeting & Trigger Package")
3. Survey UI Package ✅: Contains the Survey UI currently used for both in-app pop ups as well as link surveys
4. FB Inline UI Package ⏳: A package with survey UI components to render inline UI in a specific style. Kinda like shadcn components with extensive theming for native look & feel. Not built yet.
5. Community UI Packages ⏳: Community members have requested a large variety of different UIs. We want to support them to use the API Wrapper and Targeting & Trigger Package to be able to use the Formbricks App to target who they want to reach with their custom-built UI. We won't build that but we need to write better docs to facilitate that.

Now if I understand right what you are requesting, it would be what we called "Dynamic Inline Surveys":

Use Case: Dynamic Inline Surveys

Natively embedding surveys inline in UIs incl. Formbricks targeting possibility

Value: Highly specific targeting of users to get deep insights. Inline embedded in UI. Pro: Easy to create and run surveys. Contra: More effort to setup, more maintenance as product develops. As a developer: I want to natively embed inline surveys in my product. Dependent on the tech requirements I want to use my existing form tech and UI components. In other cases, I want to use the Formbricks UI lib to render survey questions inside my product. With theming I can get exactly the right look and feel I want. How it works: The widget pushes the survey schema to the Formbricks UI package which consumes it and renders the survey inline, when the user qualifies and the correct div is shown.

This is how I understood what you want to do with inline surveys.

What I don't understand is this:

***The MAIN idea is to be able to define user data and custom attributes, attaching them to the survey without the need to authenticate an user, for example, we would still be able to know who answered the survey. But then again, the only way to achieve that is using the in-app survey.

Why do you not want to authenticate or identify the user? This is exactly what we built the identification and attribute logic for 🤓

Feel free to snag a time in my Cal to have a chat about this: https://cal.com/johannes/15

Cheers!

[mattinannt]

After iterating over different concepts we decided to not go with supporting embedding surveys as components due to the high complexity of building and maintaining this library and the lack of requests for this feature in an experience management context.