First Time Sign-in Experience
One of the biggest goals for CardSpace in the .NET Framework 3.5 is to simplify and improve the user experience. We’ve received a lot of feedback regarding the complexity of our UI and scenarios. One area we decided to improve was the first time sign-in experience. Given that this scenario is most likely how a first time user would open CardSpace, we attempted to make this experience as smooth and simple as possible.
The things we did include:
· Removed Out of Box Experience Window
· Simplified Card Creation and Sending
· Addressed the “No Existing Card That Matches Request Type” scenario
· Addressed the “Self Issued Card Needs Extra Information” scenario
Removed Out of Box Experience Window
The Out of Box Experience window that shows up whenever CardSpace is launched (unless you checked the box to tell it to never show you again) has been removed. Most users found it not useful and ignored it.
Simplifying Card Creation and Sending
When a user is creating a card to send to the site, we used to display this page:
We noticed that users would often fill out the entire card, even when certain claims weren’t being requested. Then they would wonder why the site would want to know their birth date or mailing address, not noticing the “Card data that will not be sent” label. Also, during the card creation, if the site is requesting optional claims, that information wouldn’t be shown to the user until he/she saved the card.
In the new Edit Card page, we simplified the UI to only display the claims being requested; furthermore, we make a very clear distinction between required claims and optional ones, offering a streamlined experience should the user decide to fill in the optional data as well. If the “Include optional data” check box isn’t checked, we disable those fields.
Previously in .NET Framework 3.0, the creation of a new card always offered the same UI, regardless of the fact that the card was being created in the context of a request or out of band (like, for example, when accessing the identity selector from the Control Panel). The side effect of this was that the user had to close the card editing experience (by clicking Save) and get back to the card list screen before being able to send the newly created card.
In .NET Framework 3.5, we eliminated that limitation: as shown in the screenshot above, the card editing experience offers a Send button that can be used for sending the newly created card as soon as all the requested claims have been filled (in the screenshot, the Send button, on the left of Save, is disabled because the one of the required claims is still empty).
No Existing Card That Matches Request Type
When the user has no existing card that matches the request type, instead of showing the user an empty card list or a list of all disabled cards, we take the user directly to the Create a New Card page or Install a Managed Card page. This will be the biggest hint to the user on what he/she needs to do to fulfill the current request.
Self-Issued Card Needs Extra Information
If a request is received is for a self-issued card and the user doesn’t have a self-issued card that can provide the required the claims, previously the user would see a list of disabled cards and might be inclined to create a new self-issued card to satisfy the current request. However now, if we detect that the user has an existing self-issued card, but without all the claims needed to satisfy the current request, we’ll highlight that card and in the preview area, tell the user that he/she can send this card by adding extra information.
//Toland Hon