When offering xID on your website, we recommend that you get to know how xID is presented for the user, depending on the different login hints and the state of the user. In this document, you can find information about what you should consider when implementing xID - from a user perspective.

1. The different states of the user

We recommend that you customise the xID user experience based on the different states of the user:

• The user is not recognised with xID because he doesn't have xID, is on a new device or gets a negative response from the safety net
• The user is recognised with xID, but have not accepted to use xID every time at your website
• The user is recognised with xID, and have accepted to use xID every time at your website

For more information about how xID is presented to the user: How xID appears to the user.

2. Recommended use of login hints

xID supports three different login hints, as described in the technical documentation

A short summary: 

• XID:userintent gives the user a choice to start the xID-process. Implementing this login hint makes the user able to create xID, activate xID on a new device or refresh his existing xID on his device. This loginhint also gives a recognised user the choice to use xID every time he visits your website .
• For XID:unsolicited the xID-dialogue is automatically presented to the user, but only if he is recognised with xID. Using this login hint gives the user a choice; if he wants to use xID at your website.
• For a more silent approach we recommend using the login hint XID:unsolicited:nodialog, which will return a recognised user only if he has already accepted to use xID every time at your website. No dialogues are presented to the user. 

A few recommendations for the use of login hints:

• Please combine the different login hints for a better user experience
• When you implement either of the login hints XID:unsolicited or XID:unsolicited:nodialog, we recommend that you also implement the login hint XID:userintent behind a button or link somewhere on your website. This way you provide the user with an option to log in if he visits your website on a new device where he has not activated xID yet, or if the safety net has a negative response. Since the user is not recognised with xID, the login hint XID:unsolicited will not return a recognised user and thus, the user will not be logged in. In this case, the user needs to go through a stepup, which only the login hint XID:userintent provides. You decide if you want to expose this login hint only to users not recognised with xID, or to all users visiting your website. Note that the latter might result in two xID transactions if a user already recognised with xID is clicking on the login button.
• We recommend using XID:unsolicited:nodialog for recognition of users on the front page of your website, or else xID might feel forced on the user, for instance when browsing through your website with no intention of creating a user account.
• When using XID:unsolicited for personalisation and customisation, keep in mind what elements you want to personalise on your website. After the user has accepted the use of xID on your website, these personalised elements might change in an instant in the background, making the customisation visible to the user. Make sure that the user is given a great digital experience when visiting your website.
• Please keep in mind the different states of the user when deciding the ideal user experience with xID. Some customers may not want to use xID. How will your website look and feel for those without xID?

3. Window, re-direct or inline?

When implementing xID at your website, you need to decide how you want to present the xID-dialogues. These can either be presented through a window unattached to your website, inline (iframe) or through a re-direct. Please also see the technical documentation on this issue.

Window is the easiest implementation of xID, since it requires minimal interference on your website. It also works well on mobile devices. However, remember that the dialogue window might fall behind the browser window on the users desktop, and its easy to loose track of the xID process for the user. A window implementation might initiate popup blockers depending on individual browser settings, and especially when using the login hint XID:unsolicited. Note this special use case for in-app browsers when selecting a window implementation.

A re-direct implementation will take control of the entire browser window, redirecting the user to the xID dialogues. The user will no longer see your website until they either finish or cancel the xID process and the URL will change as well. Note that the important elements of the xID-dialogue, like the logo, cancel button and changing the xID user, become easy to ignore, due to their placement along the edges of the browser window. On the other hand, re-direct works excellent on mobile phones. We recommend this implementation on mobile phones.

With an inline (iframe) implementation, the xID dialogues can either become an integrated part of your website or be placed "in front" on your website (see the example below). This way the focus is set on the dialogues and the user will have to cancel or finish the xID-process to return to your website. As an iframe gives a poorer user experience on mobile phones, we recommend implementing xID as an iframe for desktop and as a redirect for mobile phones.

4. Provide the user a way to disconnect his xID from your website (logging out)

When a user is logged in with xID, he also needs a way to disconnect his xID from his account at your website. We offer a REST API that results in a reversion of the users choice to use xID every time on your website. This means that the user will meet the dialogue for accepting xID at your website when he later returns to your website, thus is not recognised automatically with the login hints XID:unsolicited and XID:unsolicited:nodialog. The user will meet xID as a login option at your wesite, thus this REST-API should be a integrated part of your Log out-function. 

5. Show explanatory error messages to the user when something is wrong 

When implementing xID on your website, you need to make sure that your website properly respond to errors codes returned by xID. Some errors that may occur, require a message to the end user, especially if the end result is that they are not able to log in using xID. 

6. Choosing a proper display name

When ordering xID, you need to decide on what name of your website you want to display in the xID-dialouges. The display name will be shown in the dialogue where the user is asked if he want to use xID at your website (X_04 AddClient in the UDD Viewer: How xID appears to the user#1.ThexIDuserexperience), with the following text: 

 Vil du bruke xID hos <display name>?

 Do you want to use xID at <display name>?

Note that:

• The name will be the same in both the Norwegian and English dialogues
• The name should be representative for the area of your website you are using xID for recognition
• If you want to use an URL, the user is not able to click on it
• Note that the same display name will also be shown in the consent screen asking for the users consent to share information from TINFO