...
We received some revisions to the proposed look and feel. On July 27th the attached 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://mv-ezproxy-com.ezproxy.canberra.edu.au/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.ezproxy.canberra.edu.au/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.ezproxy.canberra.edu.au/newsoffice/contact.html or here http://calendar.mit.edu.ezproxy.canberra.edu.au/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.