New Shibboleth IdP Login page mockups

[Rod Widdowson]

I’ll start by really thanking Unicon for undertaking this task. In
particular anything which means I do not have to swap in so much about
mobile browsers earns my personal gratitude.

I’m not going to profess any knowledge about user interfaces nor can I in
any way speak on behalf of the community, but I have picked up a fair bit of
meta-knowledge over the past few years and I’d like to wind the conversation
back slightly.

In thinking about web pages shipped with the IdP I think we should
understand the various roles that they play.

 - A login in page.  Although this is an area where people love to help
(“It’s the face of the School and it is important that it represent our core
values”), many of the people who deploy and manage IdPs also have to change
the backup tapes and clean the coffee out of the Dean’s keyboard, so they do
not have the time to spend do more than a minimum, so we want something
which can hit the road running.

- Didactic.  There are two parts to this:
   Firstly the person with time to spend doing a login page should be able
to learn stuff by looking at the examples.  Again taking the overworked
sysadmin – if she can clearly see how to do an easy mobile page rather than
have to swap in all the crappy non-standard or
standardized-but-no-one-conforms stuff that that characterizes the midden
that is the browser-as-a-platform (not that I am bitter you understand) then
she will have an easier life.   
  Secondly if there are behaviors we believe to be important we should
encourage them with our web pages, if there are behaviors we wish to
deprecate (Iframes, XSS honey pots) then we want to show how to avoid them.
  My belief is that the educational function that the examples have is
probably their most important function.

- A forcing function.   If there is a thing we seek to achieve we can
sometimes use the example to demonstrate why it is important that people do
this.  For example, I have always hoped that discovery might be a forcing
function for MDUI adoption (well I can hope!).

The next thing I think we need to remember is that a login page is not a
standalone entity, but part of a flow.  Just on the IdP itself there may be
Terms of User before login and Attribute Release after.  I have seen the
eyeballs plots and the neophyte (we’ll get back to him) reacts
extraordinarily badly at branding (or look and feel) boundaries.    As far
as I am concerned any example IdP page must be part of the story
SP-Disco-TOU-login-AttributeRelease-SP;  further the example login page
should be easily tailored to be the example TOU page and the example
Attribute release page.

Finally (and here we begin to get into the area of personal opinion) when
looking at these pages I only care about the non neophyte in as much they
should be able to navigate the login process as quickly as possible and that
they should easily be able to spot things that change.  People are good at
learning this sort of thing.    It is the beginner who needs our help in
navigating middleware; whilst this is less important at an IdP than for
discovery I do believe that they need support during what can feel like a
very non-intuitive flow.

As far as my thoughts, as I said at the top I am not really qualified to
comment beyond that.  But I will.

Mostly I want to comment on co-branding.  Obviously (most) organization will
brand their IdP, but my personal belief is that there is a need to
co-branding, mostly for the neophyte, but also for the accustomed user (“why
did I get here?”).  In the presence of SSO, this might be more important for
attribute release than login.  I happen to be a picture person rather than a
words person and so I think that displaying the SP Logo and some text about
it is a useful addition to a login page.  This, coupled with the need to
consider attribute release, is one of the reasons why we went for the two
pane login page which is currently in use.  The idea was that the pages was
embedded in home organization branding, the right hand pane was unchanging
for one run of the protocol (TOU/Login/AttributeRelease) and the left hand
side.

Finally as Scott mentioned, KISS is important – not only does it make for an
easier login experience, it makes is easier for the person tailoring the
site – I can say that with the humility of the person who learnt that after
imposing the CDS JSP code on those poor people who chose to use it.

Rod