Feedback
Last updated
Last updated
The Bucket Browser SDK includes a UI you can use to collect feedback from user about particular features.
The Bucket Browser SDK feedback UI is configured with reasonable defaults, positioning itself as a dialog in the lower right-hand corner of the viewport, displayed in English, and with a light-mode theme.
These settings can be overwritten when initializing the Bucket Browser SDK:
See also:
Positioning and behavior for the position option.
Static language configuration if you want to translate the feedback UI.
Automated feedback surveys to override default configuration.
Automated feedback surveys are enabled by default.
When automated feedback surveys are enabled, the Bucket Browser SDK will open and maintain a connection to the Bucket service. When a user triggers an event tracked by a feature and is eligible to be prompted for feedback, the Bucket service will send a request to the SDK instance. By default, this request will open up the Bucket feedback UI in the user's browser, but you can intercept the request and override this behavior.
The live connection for automated feedback is established when the BucketClient
is initialized.
You can disable automated collection in the BucketClient
constructor:
If you are not satisfied with the default UI behavior when an automated prompt event arrives, you can can override the global defaults or intercept and override settings at runtime like this:
See also:
Positioning and behavior for the position option.
Runtime language configuration if you want to translate the feedback UI.
Use your own UI to collect feedback if the feedback UI doesn't match your design.
To open up the feedback collection UI, call bucketClient.requestFeedback(options)
with the appropriate options. This approach is particularly beneficial if you wish to retain manual control over feedback collection from your users while leveraging the convenience of the Bucket feedback UI to reduce the amount of code you need to maintain.
Examples of this could be if you want the click of a give us feedback
-button or the end of a specific user flow, to trigger a pop-up displaying the feedback user interface.
Minimal usage with defaults:
All options:
See also:
Positioning and behavior for the position option.
Runtime language configuration if you want to translate the feedback UI.
The feedback UI can be configured to be placed and behave in 3 different ways:
A modal overlay with a backdrop that blocks interaction with the underlying page. It can be dismissed with the keyboard shortcut <ESC>
or the dedicated close button in the top right corner. It is always centered on the page, capturing focus, and making it the primary interface the user needs to interact with.
Using a modal is the strongest possible push for feedback. You are interrupting the user's normal flow, which can cause annoyance. A good use-case for the modal is when the user finishes a linear flow that they don't perform often, for example setting up a new account.
A dialog that appears in a specified corner of the viewport, without limiting the user's interaction with the rest of the page. It can be dismissed with the dedicated close button, but will automatically disappear after a short time period if the user does not interact with it.
Using a dialog is a soft push for feedback. It lets the user continue their work with a minimal amount of intrusion. The user can opt-in to respond but is not required to. A good use case for this behavior is when a user uses a feature where the expected outcome is predictable, possibly because they have used it multiple times before. For example: Uploading a file, switching to a different view of a visualization, visiting a specific page, or manipulating some data.
The default feedback UI behavior is a dialog placed in the bottom right corner of the viewport.
A popover that is anchored relative to a DOM-element (typically a button). It can be dismissed by clicking outside the popover or by pressing the dedicated close button.
You can use the popover mode to implement your own button to collect feedback manually.
Popover feedback button example:
By default, the feedback UI is written in English. However, you can supply your own translations by passing an object in the options to either or both of the new BucketClient(options)
or bucketClient.requestFeedback(options)
calls. These translations will replace the English ones used by the feedback interface. See examples below.
See default English localization keys for a reference of what translation keys can be supplied.
If you know the language at page load, you can configure your translation keys while initializing the Bucket Browser SDK:
If you only know the user's language after the page has loaded, you can provide translations to either the bucketClient.requestFeedback(options)
call or the autoFeedbackHandler
option before the feedback interface opens. See examples below.
When you are collecting feedback through the Bucket automation, you can intercept the default prompt handling and override the defaults.
If you set the prompt question in the Bucket app to be one of your own translation keys, you can even get a translated version of the question you want to ask your customer in the feedback UI.
You can adapt parts of the look of the Bucket feedback UI by applying CSS custom properties to your page in your CSS :root
-scope.
For example, a dark mode theme might look like this:
Other examples of custom styling can be found in our development example style-sheet.
You may have very strict design guidelines for your app and maybe the Bucket feedback UI doesn't quite work for you. In this case, you can implement your own feedback collection mechanism, which follows your own design guidelines. This is the data type you need to collect:
Either score
or comment
must be defined in order to pass validation in the Bucket API.
Examples of a HTML-form that collects the relevant data can be found in feedback.html and feedback.jsx.
Once you have collected the feedback data, pass it along to bucketClient.feedback()
:
When using automated feedback surveys, the Bucket service will, when specified, send a feedback prompt message to your user's instance of the Bucket Browser SDK. This will result in the feedback UI being opened.
You can intercept this behavior and open your own custom feedback collection form: