New Shibboleth IdP Login page mockups

[Tom Scavo]

>> - I assume the phrase "Service Provider" is a placeholder and that the
>> MDUI DisplayName will go there? Fallback would probably be entityID, I
>> suppose. MDUI Description does not appear to be an option (which is
>> fine).
>
> Yes, that is a placeholder. There is already quite a bit of logic built into the Shib Taglib support for Service Provider Name:
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPassLoginPage#IdPAuthUserPassLoginPage-ServiceProviderName
>
> I'm thinking that having that Name, with a hover (or whatever could be done to stay accessible) that would be the MDUI Description might be the best combo. But I'm interested to hear what others think on that.

Well, that doesn't agree with the claimed responsive design principle
since hover doesn't work on mobile devices. The design would have to
be smart enough to change the hover to something else on alternative
devices. It's a rathole, which is why I suggest a link to an external
document, but even that presents some design challenges. Like I said,
the proof is in the pudding :-)

>> - I'll suggest that a link could replace the placeholder such that the
>> link is a function of the SP entityID. In the InCommon Federation,
>> that link would be:
>>
>> https://incommon.org/federation/info/entity.html?entityID=entityID
>
> It could be interesting to have a link to such, particularly if multiple federations support such an "info page" on an entity. Although that might just be a bit too "technically/administratively" oriented to be of much value to most users.

Just the opposite. All the MDUI information is there, and as much
technical detail as the user is willing/able to consume. For example:

https://incommon.org/federation/info/entity.html?entityID=https%3A%2F%2Fcilogon.org%2Fshibboleth

Note that the technical info is hidden behind a "more technical info" link.

> Do other federations besides InCommon support something similar?

I don't know. PEER supports something similar, I think. (Note that a
global PEER service will be deployed in 2013.) MDX supports such a
syntax as well. InCommon will adopt the MDX syntax eventually.

Just to be clear, I'm not asking for a particular syntax to be
supported, just a function that accepts an entityID and spits out a
well-formed URL based on some simple template.

>> - The phrase "responsive design" could mean a variety of things.
>> Continuously responsive is one approach. Snap-to is another. The proof
>> is in the pudding, I guess :-)
>
> I'm not much of a web designer in real life or on TV :-), so I'm relaying the terminology our design team uses. I believe, based on how our own Unicon login page performs (choose Unicon as your IdP to see it, of course, even though you obviously won't be able to login in there), that we're talking continuously responsive (down to some minimum width), not snap-to.

Okay, using the Unicon login page as an example, here are some
additional comments:

- I like the strategy of focusing on the SP (rather than the IdP) but
the description doesn't really work in this context. It is sometimes
short and sometimes long, and it doesn't get to the heart of the
matter, that is, the human-readable display name of the SP. This is
especially true on a mobile device.

- I think a design like this will accommodate an SP logo just fine.
I'd replace the description with the display name and put the logo
right above that. In that case, I'd lose the cacti.

- The text fields and the button are indeed responsive, but it's
possible to have the two text fields vertically aligned while the
button is to the right. That doesn't look good. All three should be
vertically aligned in that case. (I suspect that's difficult to
achieve but no one said responsive design was easy :)

- The button responds to a hover event, which is a possible problem on
a small device. (I can't test it since the login page won't load in
Safari on iPhone.)

Hope this helps,
Tom