User journey

User without consent

Users without consent prompted with a widget should be encouraged to activate the widget, for example click on a Get started with the subscription manager button. The user can choose to click on or remove the widget. When the user clicks on the widget, the user is redirected to the onboarding flow. After completing the onboarding, the user will be redirected to the subscription overview.

For users that have been deleted from Minna's systems, the flow is the same, with only different copy telling the user to re-activate to enable the subscription manager.

User with consent

Users with consent should see the in-use state with monthly subscription cost and number of subscriptions. If it takes long to load the data, the widget is shown in the loading state. If loading data fails, then the widget is shown in the error state. When the user clicks on the widget, the user is redirected to the subscription overview.

Quick actions

You can augment the widget with quick actions. For more information on the products that power the quick actions, see Cancel, Switch and, Insights.

Implementing a widget

When implementing a widget in your client, you are expected to add your own brand and theming to the widget.

A widget can have five possible states:

• zero
• opt-in
• error
• loading
• in-use

More information on widget states

Zero state

The user should be encouraged to activate the subscription manager from the widget. When clicking Get started with the subscription manager, the user should be redirected to the onboarding flow. The user should also have the option of removing the widget.

Opt-in state

Users that have used and then disabled the subscription manager, should be encouraged to activate it again to view information in the widget. You will have to track if the user is new, existing, or has disabled the subscription manager (or is there an endpoint to tell?). You should fallback to the zero state in case you cannot determine if the user is new, existing or, deleted. The user should also have the option of removing the widget.

Error state

The user should be informed with a generic error message when the widget fails to load data. The error state has no additional actions that the user can take.

Loading state

The user should see that the widget is loading. You should implement the widget to load separately and not block the rest of the view. While loading, the widget should retain the same dimensions as the in-use state. The widget should not be clickable? while loading.

In-use state

The user should see monthly subscription cost and number of subscriptions. The entire widget or at least a section of it should be clickable and redirect the user to the subscription overview.

Retrieve widget data

When you have the visual part of your widget done, then you also have to connect your widget to two backend endpoints on your end:

1. Your first endpoint should be used to get monthly subscription cost and number of subscriptions to display in the widget.
2. Your second endpoint should be used when the user interacts with the widget and is redirected to the subscription service.

The steps required to create your backend endpoints are defined in Widget API.

Error handling

Any HTTP 4xx or 5xx status code should result in the widget error state.

Handle user states

If you want to store the state on your end. You can keep track of whether the user has consent or not. If you do not want to have state you can call Minna's User API. Where HTTP 200 status indicates that the user exists and 404 that the user does not exist. After deleting a user, Minna will treat a previously existing user as a new user. If you want to know if a user is deleted then you will have to store this state on your end.