New Shibboleth IdP Login page mockups

[Grady, Michael Allen]

On Dec 24, 2012, at 3:00 PM, Tom Scavo wrote:

> Hi Mike,
> 
> Thanks to Unicon for this eventual contribution.
> 
> - You're not planning to distribute the page as-is, with the Shib logo
> included, are you? If you do, people will unknowingly start using the
> Shib logo on their login pages, which wouldn't be good.

What to do about the default logo to have in this page is one area for discussion. I suppose one could design a simple logo that just said "replace this with your own" (with suggestions on sizing of such), and stick that as the default in the page.

> 
> - Lack of an SP logo is not a concern at all. It would just serve to
> complicate the design. The characteristics of logos in metadata are
> highly variable anyway.

Yes, if a SP logo was to be included, that would need to be accompanied with strong recommendations on the sizing/characteristics of such. I'm not myself a fan of including such, but I know there are at least a few folks that think including a SP logo would be a good thing.

> 
> - 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.

> - 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. Do other federations besides InCommon support something similar?

> 
> Other syntaxes should be possible of course.
> 
> - 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.

> 
> Thanks,
> Tom
> 
> On Mon, Dec 24, 2012 at 3:15 PM, Michael A Grady <mgrady at unicon.net> wrote:
>> Unicon has mocked up a proposed new default Login Page (username/password authentication) for the Shibboleth Identity Provider, and we'd like to begin a discussion with the Shib Dev (and, eventually, the Shib User) community on this design, and incorporate feedback, before we implement it. The screen mockups can be found at the following link (these were too big to send to the mailing list directly):
>> 
>>  https://wiki.shibboleth.net/confluence/x/hoCk
>> 
>> Background and a point or two that need discussion and feedback
>> ------------------------------------------------------------------------------------
>> 
>> As part of Unicon's Cooperative Support program, a pool of hours is generated to contribute time to working on items of interest/need for the Shibboleth project, whether that be added features to the software, documentation, writing up our experience with helping get various services working with Shibboleth, etc. Bill Thompson and I have been talking with the Shib Dev team to help identify particular areas we could work on, particularly related to the Shib Identity Provider, that would complement their work and be a part of the next Shib IdP release (2.4).
>> 
>> One area identified by the Shib Dev team was to deliver a well-designed default Login page with the Shib IdP. (The Login page that is used when enabling the username/password handler.) A Login page that would incorporate responsive design principles and thus adapt well to various screen sizes. Unicon has a skilled design team that has experience doing exactly that, and the following is the first mockup of what we are proposing to implement and provide to the community so it could be incorporated into the next IdP release as an alternative starting point for an institution's Login page.
>> 
>> There are two mockups following, illustrating the "responsive nature" of the design, with the 2nd showing how it becomes linear with a shrinking screen width (e.g. mobile device). I want to note one thing that I'd hope to start a dialog with the community on:
>> 
>> - Note that with this mockup, there is only allowance for the Service Provider description (or name, or entityID if it falls back to that), and not the SP icon/image if such is in their UI metadata. I looked at a number of currently deployed institutional login pages, and I *cannot* find any instances of such where that SP image/icon is actually used/included. Other than ones associated with InCommon. (Perhaps because most/all of the ones I looked at pre-date the existence of those UI metadata elements for an SP, and have not been redesigned to incorporate such.)
>> 
>> I know that there are at least some folks who think that including more info on the SP, particularly the logo if available, and perchance the link to that SP's privacy policy, makes things clearer for end users who end up on their institution's Login page and perhaps are not quite sure why. I'd like to gauge whether there is anything close to a consensus opinion on that, so I'm hoping this email can spark a conversation on that.
>> 
>> Clearly, adding more SP info, particularly a graphic (logo), would require some adjustment to the following design. Before we implement these mockups, we'd like to have more input on the perceived importance of that SP info. And any other comments/thoughts on this design.
>> 
>> --
>> Michael A. Grady
>> Senior IAM Consultant, Unicon, Inc.
>> 
>> --
>> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

                      
--
Michael A. Grady                      
University of Illinois at Urbana-Champaign (retired)
217-721-3890