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 ZEST:attached PDF was provided as feedback along with the following comments in email:
Okay, I have collected the feedback for you. I'm presenting it in raw form, because I don't want to put a barrier between you and ideas unless it is actually helpful. One thing I can say - you don't need to worry overmuch about the fiddly details of text. We need help figuring out where we need a heading, a sentence, or a paragraph, but given a general idea of what should be where, we feel comfortable hashing it out with the various internal folks who need to be satisfied. So long as I understand what you're referring to in a particular place, I can talk to them and figure out what the final words should be.
One of the replies is in the form of a pdf file (attached), and the rest are in text, below:
-----------------------
One piece of feedback on the "success" pages for tickets and certificates -- having just a checkbox for the "Always use ..." options is problematic, since the "continue" button takes you back to the calling web site. That's why we're using a button for this currently in the test environment. (We could have a checkbox with, say, a "Save" button for it, but it seems better to minimize the number of clicks a user has to make).
[ZEST:The other idea we have discussed is to have a checkbox like this on the login page, and perhaps have a separate (new) page allowing you to set the preference. But that would require fairly significant effort, which I fear we don't have time for at this point.]
Has she said anything specifically about this? Can we ask about using a button instead of the checkbox (or some other way to get the preference cookie saved)?
-------------------------------------------------------------------
1) It's important that we come up with a name for the service and have that clearly displayed on the page. This will give people something to refer to this by and will help avoid any kind of confusion with explaining what it is that they are referring to when they call regarding issues.
2) The username/password form will not only be used by people with MIT IDs. It's expected to be the entry point for MIT people who choose to log in using their Kerberos authentication as well as other folks who have non-MIT (external IDs). It's misleading to ask people to enter their MIT ID and to specify that this is the preferred way to log in for MIT collaborators and visitors. In this case, it may be better to stay away from trying to explain and leave it up to users to decide what log in method works best for them. [Note: this is inaccurate. The current intent is to have a seperate IdP and login server for people with an external email address. -pbh]
3) This one's more cosmetic but I was wondering why we picked the color palette we did? Is it really helping us to make it look so different than anything else our users are familiar with?
------------------------------------------------------------
I think the first two panels on the main page are OK, but the third, the username/password form, is unnecessarily confusing. It's best for anyone who can't use any of the other two methods. People don't know if they're a 'visitor', and anyone who reaches this form will want to be a 'visitor' if they're just visiting. They won't think that that means a sponsored account. Technically, there's no difference among people who may log in via any of the three methods. The idea is to encourage them to choose the best method for them and the browser they're currently using. These boxes don't do that now.
-----------------------------------------------------------
-- The first two boxes establish a strong visual pattern that the third box promptly breaks.
-- The "LOG IN" button in the third box (I'm assuming it's a button) looks exactly like the headings of the first two boxes, except it's at the bottom and the user is supposed to click on it to log in. Buttons should look like buttons, however stylized.
-- The same problem is apparent in the small, black-bordered headings which look almost exactly like the "HELP" and "NOT REGISTERED?" and "INSTALL LEASH" and "RENEW CERTIFICATE" buttons. There is little difference between what is clickable and what isn't.
-- The dual headings of "MIT CERTIFICATES" plus "USE CERTIFICATES" below it and so on are redundant. How about "Use MIT Certificates"?
-- What is the registration process (presumably accessed by clicking on "NOT REGISTERED?") and what does it accomplish?
-- Why would a visitor need to register? Is this a new feature? Does an anonymous option exist?
-- Why would "MIT Visitors" have an "MIT ID" as the label requires?
-- What is an MIT ID? The number on your MIT card or your Kerberos username? (See https://ca2.mit.edu/fcgi-bin/ca ) How would a visitor know that?
-- The form label font should be significantly darker than the "Note" font.
-- This is supposed to be a universal login process across all Institute systems. It should be MIT branded but generic enough to be useful when logging in to Stellar, TechTime or WebMail or SloanSpace or DSpace or any other site. Use a simple white and gray background with touches of MIT red (see http://web.mit.edu/graphicidentity/colors/index.html for the styles) and make the logos stronger. The Easter egg colors make no sense.
-- I suggest adding the MIT website banner at the top of the login pages (see example here: http://web.mit.edu/newsoffice/contact.html or here http://calendar.mit.edu/techtime/index.shtml). This banner provides a link back to the MIT homepage and changes color to match it, thereby tying the whole together into a clear identity. The News Office pages are also a very good example of the subtle use of MIT colors.
-- Are three discrete HELP buttons necessary? Does each one go to a different place? Why? The effect is more visual clutter on the page.
It seems that we are asking users to self-identify according to categories which are set by us and meaningful to us. All the users want to do is get to a page via a link that they clicked on. This page is a barrier, both visually and functionally, as it stops the user's progress through the MIT experience dead in its tracks. It needs to be an interchange, like on a highway, with clear road signs. Rather than asking users to provide information according to our needs, why don't we try to see the matter from the users' perspective and anticipate what would be meaningful to them? Then we can use labels and text in a way that leads them in the direction of doing the correct thing without forcing them to stop and ponder.