« Now don't tell me I've nothin' to do | Main | Going LOCAH: a Linked Data project for JISC »

July 07, 2010

On federated access management, usability and discovery

A little over a week ago I attended a meeting in London organised by the JISC Collections team entitled From discovery to log-in and use: a workshop for publishers, content owners and service providers.

The meeting was targetted at academic publishers (and other service providers), of whom there were between 30 and 40 in the room. It started with presentations about two reports, the first by William Wong et al (Middlesex University), User Behaviour in Resource Discovery: Final Report, the second by Rhys Smith (Cardiff University), JISC Service Provider Interface Study. Both reports are worth reading, though, as I noted somewhat cheekily on Twitter prior to the meeting, if the JISC had paid more for the first one it might have been shorter!

Anyway... the eagle-eyed amongst you will have noticed that the two reports are somewhat different in scope and scale. Both talk about 'discovery' but the first uses that word in a very broad 'resource discovery' sense whilst the second uses it in the context of the 'discovery problem' as it applies to federated access management - i.e. the problem of how a 'service provider' knows which institutional login page to send the user to when they want to access their site. This difference in focus left me thinking that the day overall was a little out of balance.

For this blog post I don't intend to say anything more about 'resource discovery' in its wider sense, other than to note that Lorcan Dempsey has been writing some interesting stuff about this topic recently, that there are issues about SEO and how publishers of paid-for academic content can best interact with services like Google that could usefully be discussed somewhere (though they weren't discussed at this particular meeting), and that, in my humble opinion, any approach to resource discovery that assumes that institutions can dictate or control which service(s) the end-user is going to use to discover stuff is pretty much doomed from the start. On that basis, I'm not a big believer in library (or any other kind of) portals, nor in any architectural approach that assumes that a particular portal is what the user wants to use!

The two initial presentations were followed by a talk about the 'business case' for an 'EduID' brand - essentially a logo and/or button signifying to the user that they are about to undertake an 'academic federated login' (as opposed to an OpenID login, a Facebook Connect login, a Google login, or whatever else). Such a brand was one of the recommendations coming out of the Cardiff study. I fundamentally disagree with this approach (though I struggled to put my case across on the day). I'm not convinced that we have a 'branding' problem here and I'm worried that the way this work was presented makes it look as though the decision that we need a new 'brand' has already been taken.

During the ensuing discussion about the 'discovery problem' I mentioned the work of the Kantara Initiative and, in particular, the ULX group which is developing a series of recommendations about how the federated access management user experience should be presented to users. I think this group is coming up with a very sensible set of pragmatic recommendations and I think we need to collectively sit up and take some notice and/or get involved. Unfortunately, when I mentioned the initiative at the meeting, it appeared that the bulk of the publishers in the room were not aware of it.

To try and marshal my thoughts a little bit around the Kantara work I decided to try and implement a working demo based on their recommendations. I took as my starting point a fictitious academic service called EduStuff with a requirement to offer three login routes:

  • for UK university students and staff via the UK Federation,
  • for NHS staff via Athens, and
  • for other users via a local EduStuff login.

I'm assuming that this is a reasonably typical scenario for many academic publishers (with the exception of the UK-only targetting on the academic side of things, something I'll come back to later).

Note that this scenario is narrower than the scope of the Kantara ULX work, which includes things like Facebook Connect, Google, OpenID and so on, so I've had to interpret their recommendations somewhat, rather than implement them in their totality.

You can see the results on the demo site. Note that the site itself does nothing other than to provide a backdrop for demonstrating how the 'sign in' process might look - none of the other links work for example.

The process starts by clicking on the 'Sign in' link at the top right (as per the Kantara recommendations). This generates a pop-up 'sign in' box offering the three options. Institutional accounts are selected using a dynamic JQuery search interface which, once an institution has been selected, takes the user to their institutional login page. (My thanks to Mike Edwards at Eduserv for the original code for this). The NHS Athens option takes the user to an Athens login page. The EduStuff option goes to a fairly typical local login/register page, but one which also carries a warning about using one of the other two account types if that is more appropriate.

Whichever account type is chosen, the selection is remembered in a cookie so that future visits to the pop-up 'sign in' box can offer that as the default (again, as per Kantara).

Have a play and see what you think.

Ok, some thoughts from my perspective...

  • In the more general Kantara scenario, some options (Facebook, Google, OpenID, etc.) are presented using clickable buttons/icons. I haven't done this for my scenario because the text wording felt more helpful to me. If icons were to be used, for example if a publisher wanted to offer a Google-based login, then I would probably present the NHS Athens and EduStuff choices as icons as well.
  • You'll note that the word 'Athens' only appears next to the NHS option. I think that our Athens/OpenAthens branding should become largely invisible to users in the context of the UK Federation - or, to put it another way, one of our current usability problems is that publishers are still presenting Athens as an explicit 'sign in' option when they really do not need to so. In the context of the UK Federation, OpenAthens is just an implementation choice for SAML - users need be no more aware of it than they are of the fact that Apache is being used as the Web server. (The same can be said of Shibboleth of course). Part of our current problem is that we are highlighting the wrong brands - i.e. Shibboleth and OpenAthens/Athens rather than the institution - something that both the JISC and Eduserv have been guilty of encouraging in the past.
  • The institutional search box part of the demo is currently built on UK Federation metadata, so it only offers access to UK institutions. There is no reason why this interface couldn't deal with metadata from multiple federations. Indeed, I see no reason why it wouldn't scale to every institution in the world (with some sensible naming). So although the current demo is UK-specific, I think the approach adopted here can be expanded quite significantly.
  • On that basis, you'll note that there is no need in this interface for an EduID brand/button. Users need only concern themselves with the name of their institution - other brands become largely superficial, except where things like Google, Facebook, OpenID and so on are concerned.
  • I've presented only the front page for the EduStuff site. On the basis that we can't control how users discover stuff, i.e. we have to assume that users might arrive directly at any page of our site as the result of a Google search, the 'sign in' process has to be available on each and every page of the site.
  • Finally, the demo only deals with the usability of the first part of the process. It doesn't consider the usability of the institutional login screen, nor of what happens when the user arrives back at the publisher site after they have successfully (or otherwise) authenticated with their institution. I think there are probably significant usability issues at this point as well - for example, how to best indicate that the user is signed in - but I haven't addressed this as part of the current demo.

I'd be very interested in people's views on this work. It's at a very early stage - I haven't even presented it properly to other Eduserv staff yet - but we have some agreement (internally) that work in this area will likely be of value both to ourselves and our current customers and to the wider community. On that basis, I'm hopeful that we will do more work with this demo:

  • to make it more fully functional, i.e. to complete the round-trip back to the EduStuff site after successful authentication,
  • to make the 'sign in' pop-up into a re-usable 'widget' of some kind,
  • and to experiment with the usability of much larger lists of institutions, taken from multiple federations.

Whatever our conclusions, any results will be shared publicly.

Overall the day was very interesting. I'll leave you with my personal highlight... the point at which one of the (non-publisher) participants said (somewhat naively), "What would it take to make all this [publisher] content available for free? Then we wouldn't need to worry about authentication". Oh boy... there was a collective sharp intake of breath and you could almost hear the tumble-weed blowing for a minute there! :-)

Addendum (8 July 2010): in light of comments below I have re-worked my demo using a more icon-based approach. This is much more in line with the current Kantara ULX mockups (version 4) including the addition of a 'more options'/'less options' toggle on second and subsequent sign ins. Overall, it is, I think, rather better than my initial text-based approach. I stand by my assertion that an EduId button is not required in the 'sign in' process demonstrated here (irrespective of whether the icon-based or text-based approach is used). That said, I'd welcome views on how/where such a button would fit in.


TrackBack URL for this entry:

Listed below are links to weblogs that reference On federated access management, usability and discovery:


The trouble when you start talking about brands is that it always becomes the thing that everyone remembers :-( No decision has been made at all on the branding issue but we do feel it is necessary to have some kind of 'button' and not just words - this fits in with the ULX work very well if you look at their demo here: http://staging.kantarainitiative.org/ulx-mockup/new31/. We very much see the 'eduID' concept as part of the ULX work and Bob and I are linked in enough to the ULX stuff to make sure we aren't going off in different directions.

The real focus of the 'proper' work is on getting the UI write so it can be easily integrated on any Service Provider site with minimum fuss - this is hard. Chad and Rod are busily making this magic happen and you might be interested in their work here: https://spaces.internet2.edu/display/~lajoie@idp.protectnetwork.org/DSUI. Rod has a demo with some screen shots of a mocked up SP site that has his been demoing around the FooShib events if you are interested.

The idea of a 'brand' is just a level above this. Something small, something simple, our representation in that list of boxes you see on the ULX demo.

Why don't we just go with words? Simple. We've tried it. It failed. Miserably. You give someone text to put on their site, they will change it and mess around with it. We've always recommended a set text and it largely gets ignored. All the feedback from the publishers has told us that they would prefer the button approach. User testing has confirmed that this is prefered as well.

Anyway I'd suggest if you are going to take this forward you chat with Rod and Chad as the baseline proposals seem very similar.

Completely agree with the need to make the Athens brand and mistaken use of "shibboleth" invisible when applied to federated access. Additionally "we can't control how users discover stuff" is very true, and at JISC Collections we are trying to educate publishers that if users come via Google they won't always (even often) hit their site where they would like them to.
With reference to the balance of the day-it was an opportunity to hit alot of points of interest with key publishers - rather than being a traditional techie focused event.
Katara work is clearly important in this space and yes "content for free" was thinking very very outside the box...
Thanks for coming by the way...

Thanks for the link - the wireframes there look very similar to what I've implemented (unsurprisingly since I guess that both are based on the Kantara ULX work) so that is good.

However... re: 'words vs icons' I think you are missing the point (or we are talking at cross purposes or something). I'm not yet aware of many 'academic publisher' scenarios in which they will be offering icons for logging in via Google, Facebook, OpenID, etc. So those icons simply won't appear in their version of the sign in box. Any EduID icon will have to take the user to a 'choose your institution' interface anyway - I presume we are not talking about having an icon for every institution? - so all you will be doing with the icon is adding an extra click for the user. How does that help with usability? Answer... it doesn't!

Looking at my version of the sign in box (compared to the Kantara mock-ups), the only text I have over the Kantara stuff is that for 'NHS Athens' and a local site login - both could be replaced by icons (as I explained in the post) - I didn't do that because in thsi scenario they would be the *only* icons.

Whatever... there is still *no requirement* for an EduID brand/icon/button. I don't understand where such an icon would usefully appear in those mock-ups or in my demo.

What am I missing?

one other thing. You say that "Why don't we just go with words? Simple. We've tried it. It failed. Miserably.".

I'm not quite clear where and how this 'tried it' was done... but I strongly suspect that it was attempted in the midst of a set of very confusing advice (from both the JISC and from Eduserv) about what should be called 'Shibboleth', what should be called 'Athens', what should be called 'Federation' and so on.

My personal view is that consistency with our use of words is just as important as consistency with our use of icons - perhaps more so... irrespective of how we eventually agree to implement the sign in box.

Finally, I sense that, in part, the drive for an EduID icon comes from the perceived success of the OpenID logo. The trouble is that the technical environment in which the two things operate is significantly different. A single OpenID logo can function in a way that a single EduID logo cannot... because OpenID has a built-in solution for the discovery problem.

The drive does not come from OpenID, the drive comes from a review of our community and listening to the direction they want to go in. In fact, I personally think OpenID has failed as a brand.

The problem with your mock-up is it isn't extensible. You are restricting the site to only having those three options as anymore becomes ugly to manage and gives the same listing problems as the current WAYF approach. It's too heavy on the text, which user's eyes gloss over (we had a study commissioned by an organisation called Bunnyfoot to look at this, it was really interesting).

JISC has consistently given the same advice to publishers on how to 'brand' federated access ('institutional login') from day one (four years of service now!) and the publishers just don't like it. So they change it.

All our work to date has shown us that a neat logo for federated login that can sit alongside neat logos from other organisations / identity providers with a search option at the bottom is the best user experience rather than text. It's highly extensible, quickly recognisable, easy for the service provider and easy for the user. It's what all our studies have recommended, it what the publishers have asked for, it's what Kantara recommends and it has the backing of all the international federations. After a year of consultation I'm going to need some pretty strong evidence to say that a text approach against an icon approach is preferable. We are still consulting though so if people want to contribute, we would love to hear from you at: jisc-access-management@jiscmail.ac.uk.

again, we seem to be arguing at cross purposes? Or I am missing something. In a sense, my use of 'NHS Athens' and 'EduStuff login' is a red herring...

...but if I change my current options 2 and 3 (both currently presented using text) into icons, then I have an exact replica of what I'm seeing in the Kantara mock-ups? Agreed?

Kantara doesn't seem to me to be saying use only icons... it shows the use of some icons (Google, Facebook, etc.) and some drop-down lists (as I have implemented), e.g. see the second screen on http://kantarainitiative.org/confluence/display/ulx/NIH+Scenario+Static+Mockup .

My implementation is a close replica of that screen except that I have chosen (currently) to present two possible icons (NHS Athens and EduStuff) as text.

Perhaps I'm mis-interpreting those Kantara mock-up screens... but I still don't understand where an EduID icon would fit into them? The only place a federated institutional login fits into the current Kantara mockups is where they say "or search accounts, i.e. Boston University" - pretty much exactly as I have it.

Do you see federated institutional logins fitting somewhere else? If so, where?

Sorry... I'm confused!

Re: extensibility... again, I disagree. It is not limited to 3 choices - 3 was chosen as being reasonably typical for an academic publisher. It is extensible in the sense that the institutional search box can be extended to work across multiple federations (I haven't tested this but I'm reasonably confident it will still work) and as many icons can be added above that box as necessary/usable, as per the Kantara mock-ups.

In light of @Nicole's comments above I've added a new demo using icons rather than text - see the addendum above. I think this works better than the original.

The comments to this entry are closed.



eFoundations is powered by TypePad