We've also been using an outside contractor to create one possible interface. The first images were disseminated to some MIT staff members on May 21, 2007. Some of the comments in response to the first version were:
I worry that the current layout places an overwhelming emphasis on the option to enter the username and password. This is due to three issues. It is presented as the first choice (top to bottom). It spans two columns while each of the other choices span one column. The choice has more than twice the vertical weighting compared with the other two choices.
I think it is important to remember that the option to enter the username and password is what we consider the least desirable choice from a security perspective. Despite any text warning the user to be careful about using their password in other places, it simply trains the user to enter their password on web forms.
Perhaps a three column layout where each choice is an identical size would be better. The password choice could then lead to a subsequent screen which prompts the user for the username/password combination.
I also noticed that the introductory blurb we have at the
top of the current page on foonalagoona isn't present. I think
something like this is needed to explain the various options,
etc.
Subsequently issues were raised from the developer's perspective:
1) What to do about the confirmation page, i.e. should it refresh (immediately, or after <n> seconds) automatically back to the destination site?
2) Should the preference setting (for trying Kerberos or certifcates automatically) UI remain on the confirmation page, or move to the login page, and/or a separate new page? Having this somewhere other than the confirmation page seems more important if we go with the automatic refresh back to the destination.
3) Currently we have the settings (button label, descriptive label (e.g. "existing Kerberos tickets"), etc.) pertaining to each alternate authentication method (i.e. besides username/password) in a separate config file, not hard-coded in the cgi script or HTML templates. It would be nice if none of the UI changes forced us to have to hard-code these things anywhere besides the config file.
4) Keep in mind that we will likely add other possible authentication methods in the future.
5) Besides the login and confirmation pages, what pages will she work on? WebAuth also has logout and error pages, and Shibboleth has its own confirmation and error pages (the Shibboleth confirmation page only appears when the user has JavaScript disabled). These should probably at least be customized to have a similar look.
5a) There are also stock error pages for the SP, which should probably be customized by each web server admin. Should we have the UI design person do anything here? (Would that even make sense, given the diverse set of web sites we will potentially deal with?) Or should we just remind admins to do something with these?
We received some revisions to the proposed look and feel. On July 27th the attached PDF was provided as feedback along with the following comments in email: