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

Comments

• Anonymous
  October 22, 2007
  Great to see the CardSpace GUI evolving, guys!What's the ship vehicle for CardSpace 3.5? Will Vista users get this via a service pack?
• Anonymous
  October 26, 2007
  Regarding "Self-Issued Card Needs Extra Information".If I try to get inside the mind of a perpetually intermediate user, it's not obvious to me that "this card" in the text refers to the one that's highlighted.And I hope it's clear to folks that the ability to add self-asserted claims to a card has ramifications for relying party code that gets a token containing claims that the RP didn't specify as required or optional.
• Anonymous
  October 27, 2007
  The comment has been removed
• Anonymous
  October 28, 2007
  That doesn't clarify anything.  The question was about the behavior of an RP.  For instance, if an identity selector sends all required claims, alloptional claims, and some others, what should the RP do?  I think it should ignore the other claims.  Other people think shis should be an error.  
• Anonymous
  October 28, 2007
  It was unclear from your original comment which identity selector you were talking about, and since we were talking about CardSpace, I assumed you were talking about CardSpace.If you want to talk about other identity selectors, there's nothing we can control. What stops them from sending you garbage? Of course it's up to the RP to determine what to do when they encounter something abnormal.Are you asking for guidelines for what to do in this situation?//Toland