Hi,


   I've been looking at a third solution that I've included in the UI
Flows version 0.08 I've just completed.
http://dl.dropbox.com/u/34057557/Moonshot%20User%20Flows%200.08.pdf

  I thought I would run this by you for discussion.

The idea is that you have 3 states for associations. Associated, not
associated and disabled association (this indicates that the service is
in the saved services list but the user is still asked for an ID Card
when trying to authenticate against this service). The service appears
disabled in the saved list so nothing disappears as would be the case if
we were out right removing the association.
I've also added a button to the UI so now the user has the option of
clicking on "Send" and "Send and Save"

The idea is this. If the user wants to not associate the service to the
ID Card she presses Send. No association is made.

If the user wants to create an association she presses "Send and Save".
The association is made. If everything goes well and we know everything
is well the association is left untouched. If something goes wrong or
we don't know that everything is alright the association is disabled.
The user can see this in the saved services list.

If everything was alright at some point but this is no longer the case
then the association is disabled as well. The association is enabled
again when the user is able to connect to the service successfully.
There is a possibility that we might be able to enable the service
association manually as well from the saved services list.

The advantage of this approach is that we aren't removing something the
user has saved to a list. If we are telling the user that something is
being saved somewhere she needs to see that it has been saved but
something has gone wrong. The extra button removes the need for a
dialog which would make resending the ID card easy in the case of an error.

Maria




On 06/07/2011 10:21, Maria Turk wrote:
> OK that sounds good to me. I'll still be on a lookout for a third
> option.
>
> On 03/07/2011 21:32, Sam Hartman wrote:
>>>>>>> "Cantor," == Cantor, Scott E<[log in to unmask]> writes:
>> Cantor,> At least in the web case, we have not managed to come
>> up with any. It's
>> Cantor,> technically easy (you visit a URL), but we have no way
>> to make the URL
>> Cantor,> known.
>>
>> Right. we have neither found a solution that avoids this requirement
>> nor a way to meet this requirement. Unless you can get under a certain
>> threshhold of bad associations, which I don't think we can do, reducing
>> bad associations doesn't seem to me like it will help much.
>>
>> My conclusion from this is to suggest to the UI people that they go
>> forward with what they think is best, with the understanding we'll
>> probably be back for a round 2.