NIH Scenario Web Mockup

Here is an HTML mockup of the flow #1, #2 and #3 of the Use Case: Unmodified Browser, First Visit within the NIH Scenario. In v2+ it also implements the Nth visit:

Note: The above should work in IE 8, Firefox and Safari. It may have problems in IE 6 or 7.

Feedback on Version 5
  1. Let us know!
Feedback on Version 3.1
  1. Former user (Deleted): On the call we suggested that one or more of the choices be a full-frame login process instead of a popup.
  2. Former user (Deleted): Too many initial choices, probably more likely to be a small set of big players and the MyNCBI choice. Paul Trevithick: Yes, in our enthusiasm for showing 3+ protocols under the same UI, we didn't create a "realistic" mockup--we created one with more account-buttons (IdPs) than would be realistic in most cases. We should go back to Debbie Bucci and ask what a realistic set of trusted IdPs might be.
  3. Former user (Deleted): We probably need some kind of "Help" or "What is this?" link on the pop up to give people some exposition.
  4. Former user (Deleted): I'd suggest adding at least a couple of IdP choices that don't show up as "preferred" icons but will show up if you start typing them (maybe there are now? obviously this is a function of knowing the options exist).
  5. Former user (Deleted): There's nothing on the various login forms that references back to the site requesting the login. That's something we're building into the new Shibboleth work being done.
  6. Former user (Deleted): There ought to be a "see all choices" capability to break out of the captive list. Not clear whether a drop down or just actual presentation of a list is best. This leads into....
  7. Former user (Deleted): Accessibility. Not so much a mockup issue, but that will be a major concern for anything we do with it and this might need to be noted to any testers, that it's not in that state yet. For current purposes, I think the point to be made is we should ensure anything mocked up could be rendered in an accessible fashion for screen readers and such.
  8. Valeska: One user actually thought that you had to click all 8 account-buttons. So clearly we need to change the "Connect with:" language
  9. Paul chanelling Nate Klingenstein: In the interest of creating more "connective tissue" we should create a template that constrains more tightly on what the IdP's authentication popup window (not the initial "discovery" popup) looks like for "best practice". At present the mockup shows only the text name of the site your connecting to (aka "service provider"). Nate suggested that the logo of the site as well as the name of the application also be included.
  10. Paul Trevithick: The Oauth/permissioning third window is present in the Google account-button flow but is missing from the Yahoo, PayPal and MSFT Live flows.
  11. Paul Trevithick: Scott suggested that the account-buttons should be vertically separated into two groups: (i) those that you've used before at the site and (ii) all the rest of "preferred" choices. Seems to be no reason the RP (and certainly the active client) can't remember this.
  12. Paul Trevithick: Although we've been focusing on the unmodified browser cases, our goal is that the "with active client" UI looks remarkably similar/consistent although in ths case rendered by the active client instead of the RP. So when we look at the popup from the point of view of it being a prototype active client UI we immediately see that the account buttons are much smaller than the IMI i-card images, and they have a different aspect ratio. The account button that starts off being simply the Equifax logo must somehow morph into an account button that represents the card that you downloaded when you became an active client user. Further, we need to handle the case where more than one Equifax card may be displayed--and thus they need to be distinguishable. One possible approach might be for the account buttons to inherit some kind of color/texture or sub-title wording from the information card image that they represent and in addition, if you hover over the account-button it explodes into the full image of the i-card.
  13. Paul Trevithick: V3.1 Doesn't work on an iPhone/iPad: the popup appears, but the secondary browser invocation fails (not surprisingly).
Feedback on Version 2

Based on the ULX call of February 24th, we would at least like to make the following changes to version 2:

  1. Add an upper-right "X" close button to the popup (see #3 below)
  2. Replace the word "Search:" with "Select:" in front of the words "i.e. type Boston University"
  3. Replace the magnifying class icon with a checkmark icon (because we are selecting from a fixed list, not searching as with keywords, etc.)
  4. Change the code so that it opens a separate browser window and sizes it in roughly the same place as the popup vs. today's embedded HTML. This way there will be browser chrome showing so that the user has more trust that this really is, say, Google, (if you'd clicked on the Google button)
  5. Add hover text over the "Connect" button to teach the person what on earth it is. The hover text should say "Click here to log in".
Feedback on Version 1
  1. [ulx:Paul]: The text "Login with" should be changed to "Connect with" to be consistent with "Connect to" language on the connect button at the beginning
  2. [ulx:Benoit]: What happens after the first visit when the box "Remember me for 2 weeks" is checked ? Is there something planned to show clearly that the login form is provided (and secured) by the choosen IdP ? What if the IdP doesn't allow an embeded login form ? The magnifying glass button is not for searching, but for launching the login process : it is ambiguous.
  3. [ulx:Benoit]: What about a "x" in the upper right corner of the main "Login with" box, to close it explicitly ?