Shibboleth Developers

[Tom Scavo <>]

On Fri, Feb 18, 2011 at 4:04 AM, Rhys Smith 
<>
 wrote:
> On 17 Feb 2011, at 14:52, Tom Scavo wrote:
>
>> If I understand correctly, you want a language-specific description
>> for each attribute? Well, there's no good way to do that as others
>> have already pointed out, but I think it's a bad idea anyway. If you
>> have to write words on the user interface to explain to the user
>> what's going on, then it's not going to work. Have we learned nothing
>> all these years of building discovery interfaces? (sorry :)
>
> Not sure I agree with this. I agree that things need to be as simple as 
> possible, but sometimes more is less... You either need to get the 
> technology out of the way as much as possible (i.e. don't do user consent 
> at all), or enable the user to make informed decisions in as simple as way 
> as possible.

I don't disagree with that (basically), but putting more words on the
UI is not going to solve the problem. If you think otherwise, then
you're one of the 20% verbal types in the world (which I know is true
:) but the other 80% of people are not going to get anything from your
words, and putting them on the UI is just going to make their
experience worse.

We're gonna "require" each SP to provide a pointer to a Privacy Policy
(<mdui:PrivacyStatementURL>) and suggest that all the words needed to
explain the service to the 20% of users who care be written in that
document. Then if we can get the software to display a prominent link
to the Privacy Policy...

> A simple form listing required / optional attributes with an explanation 
> for why each is needed and check boxes on optional attributes - e.g...
> *     Persistent Identifier (required): You have to provide this to use our 
> service as we use it to manage your session on this site;

You can scan the previous two sentences to find a handful of words
that 80% of users will not understand at all and couldn't care less.

> * [X] Email address (optional): If you provide your email address, we can 
> notify you of site updates;
>
> * [X] First and Last name (optional): If you provide your name, we can 
> personalise greetings to you.

I claim you can easily remove all of the above words without loss of
generality or understanding.

> ...has to be better than a list of attributes (eduPersonTargetedId, email, 
> firstName, sn) with values, with no explanation at all as to why they're 
> wanted and what the implications of providing or not providing them are. 
> Surely?

Well, you obviously think so and I obviously disagree :-) and I guess
only time will tell.

By the way, ePTID is doubly problematic. Since you're providing PII in
your example, ePTID serves no useful purpose. Indeed, it will be
impossible to explain to ordinary users what a persistent identifier
is for, especially one they're not gonna be able to see.

> People who aren't interested will just ignore the text and click on "OK", 
> but it enables people who give a damn to make an informed consent.

The 20% who care can read the privacy policy.

> (I agree with you in the context of discovery by the way - no amount of 
> explanation will help people understand what's going on. But to release or 
> not release attributes is conceptually a different kettle of fish and I 
> don't think can't be compared directly...)

I don't think so. The basic concepts of user interface design apply
regardless of the application.

Tom