ULX Teleconference 2010-04-14
ULX Telecon 2010-04-14
Logistics
- Time: 16:00-17:00 Eastern
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214
Agenda
0) Roll Call
- Valeska O'leary
- Paul Trevithick
- Nate Klingenstein
- Scott Cantor
1) Valeska: Report from IA2010 Poster Session
The Information Architecture summit was held in Phoenix, and the screenflow associated with the mockup was presented to people. There was a lot of interest in what we were doing from the community, and Chris Messina from Google in particular spent roughly an hour in the booth. Some were also puzzled by the use of MyNCBI, rather than a direct PubMed login. The general sense was that this is very important work to be done at present.
2) Review Web Mockup
Walk through as a group this page
Valeska could also observe a handful of individuals using the interface on her own computer, before the conference, where connectivity was limited. A commonality in the feedback was, "why are there so many options?" Eight people were observed, and a majority stated that. One person thought all eight buttons needed to be pushed. "Connect with" may have been a reason for this, with something like "Login using any one of these options" -- truncated -- being a more appropriate instruction to the user.
Google believes that four buttons is the most that should be shown at any given time. The set of eight was somewhat artificial, intended to result in a full set of protocol options, but it does raise some questions about logo size. But it seems likely that the largest identity providers will expect to have their own buttons on there.
Google is also currently focused on "just type in your email address", but Nate believes that the prospects for that are very poor. Major consumer identity providers such as Twitter and Facebook don't have email addresses associated with their users, so this is likely to be a long-running battle if Google presses it. Paul observed that Google has vast resources at their disposal to work on user interface issues, but Nate and Scott believe that Google is trying to solve potentially a fundamentally different problem from the scenarios that this mock-up needs to be able to accommodate.
Nate opined that a reduced number of buttons is actually a reasonable request and the more common situation, since the set of most likely IdP's will be small, and the other options will be associated with prior user selections. The search options will be more important in the majority of situations, and should be made sufficiently prominent.
Valeska also thinks there needs to be a mockup of some other interface options. She'd like to explore the focused pattern language of a mobile device. This interface gives users very few options, and is very task-oriented. But Scott thinks that people don't consider login to be a task; it's a nuisance to be avoided. What task are you trying to represent to the user?
The Shibboleth project is going to try to encourage IdP's to create a more consistent experience around federated identity login, and passing some information back from the Service Provider to the Identity Provider can improve the login display presented to the user. The three pieces of information Nate believes are most important are the logo, the application name, and the service provider's organizational name.
Some way to do "see all" is of interest, whether a drop-down or an actual list, which ties into usability issues. Pull-down menus have been preferred by users in large deployments of educational federated identity to type-ahead search by string. Having a link that closes the popup and takes the user to a full list of identity providers or a pull-down menu, or clears the popup and replaces it with just the menu, is probably the best way to offer this menu in the context of the current interface proposal.
Pop-ups bother Scott from the perspective of a login interface, but he's comfortable with a pop-up being used for discovery. The actual authentication page needs to be fully-framed, and he believes what Google is doing is completely wrong and inconsistent with the security model that prevails on the web today. It's likely that some identity providers will want to be able to make the choice themselves, and enhancing the mockup to allow for both possibilities would be nice.
Some sort of visual distinction in the main interface between prior choices, preferred choices, and other choices would be preferable to Scott. Everyone concurred.
Paul also thinks it would be very interesting to potentially replace the default logos and names, or at least decorate them, to indicate some specific details about the identity they have at that particular site to the user. Scott thinks the question about which logo to present is a more general one; e.g. at a University, do you use the logo of the identity provider, the logo of the local student/employee card system, the University authentication system, etc.
Adding a help link of some sort might be a good idea too, to explain to users exactly what's going on if additional instruction is needed.