A Browser UI for a Hardware Dongle

The Network Identity Manager is, essentially, a hardware dongle for web sites. It is a smart card in a USB token with a browser-based UI that provides public/private key authentication to a web site or web application. It provides two-factor authentication for the web in a novel and very usable way. I developed the browser-based user interface, a modified version of which is currently shipping.

Methodology

The design process for the NIM UI had a springboard in the form of nine months of R&D for the Axalto Network Card, which also used a browser-based UI. The Network Card UI had gone through at least one usability test, where things like wider-than-tall numeric pads were rejected on unfamiliarity grounds.

In addition, while we had a concrete set of technical tasks (presenting a PIN pad, logging the user in, presenting a list of sites, processing a set of cryptographic keys and finally submitting them to a web site), we still had no idea of the aptitude of an ultimate end-user, browser or hardware specifications, etc.

As our sales group was targeting large, mass-market organizations like online banking, auction sites, etc., I decided to target the basest possible specification: Internet Explorer 5+ or Firefox 1.0+ at 640x480, with only rudimentary browser aptitude and no operating system-specific affordances used.

Rationale

I started with the idea of trustworthiness, because if the user can’t feel like they can trust the device, they won’t use it, no matter how usable it is. This was the only aspect that usability came second to, because security must be usable to be used.

Trust is conveyed through reliability (Raskin’s monotony) and transparency (plain language). These two ideas are especially important, given that a “web dongle” is an unfamiliar object.

I decided to pattern the user interface using as many existing traditional web affordances as possible, and to keep the interface as internally consistant as possible. If the interface always performs the same, a difference (such as an error or a spoof) should be easier to notice.

I also treated the interface as a conversation. The interface always presents itself with no jargon, no distractions and no attempt to sell itself. By plainly leading the user through each (entirely new) process, the device can build up a comfort level with the user.

Design Artifacts

For a browser-based interface, paper sketches are a little unusual for me to have very many of. I will often go right to HTML, CSS and JavaScript to iterate through wireframes.

Setting Up the Token

This sketch was working through the various levels of detail in each step of the UI; how much was too much to present to the user? Should I be extremely obvious (on the left) or go with a possibly more confusing tab-based structure (on the right)?

These three sketches continued this, trying various ways of displaying progress through the token setup process and how it might function during each type of input or information display. The left sketch simplifies the presentation of the steps, showing only the current step's name and spelling out the number remaining. The right and bottom sketches use a sort-of progress bar indicator near the top, a design pattern often used in application “wizards”. In the bottom sketch, you can also see the right-pointing arrow from the PIN pad being used as the submit button for the text entry form to maintain interface consistency (at the possible expense of existing web affordances).

This sketch leaves out the display of steps and focuses on the presentation of multiple input fields. One immovable object, as far as the company was concerned, was the presentation of the PIN pad. Along with the traditional number layout, the lower left button would be a red “X” for clear or reset. The lower right button would be a right-pointing green arrow for enter or submit. I believe that the affordance of a PIN pad is to press the number buttons and then press the enter button. Adding a text field for a human interaction proof (a “CAPTCHA”) on the same screen confuses this process, especially if the field is to the right of the PIN pad: the user would have to enter their PIN but not click submit, then enter the HIP, and finally either hit Enter or (more likely, given the awkwardness of the situation) go back to the PIN pad to click submit. Placing the HIP to the left of the PIN gives a more visually logical progression and makes the single submit button of the PIN pad more obvious, even though, semantically speaking, the HIP is a secondary factor to the PIN.

Logging into a Web Site

As these are original sketches, the pixelated areas are written names of potential client sites (not pixelated logo images).

This seemed relatively straightforward: one link for each web site account to set up, and a traditional pair of username and password input fields (note the use of the PIN pad submit button again) to associate the token with the user's existing account. I intentionally did not include a second password field for verification.

This brief experiment with using icons instead of text links confirms Raskin's assertion that “instead of icons explaining, we have found that icons often require explanation.” The “next action,” purpose of the screen and discoverability of functionality simply isn't as obvious as it is in the next iteration.

Here, I used text links for every possible action, offsetting them from the login links to reduce the chance of mis-clicks. I also brought forward the large setup link for the situation when one site's account has been set up, but the other hasn't been. It looked better on paper than it did in practice, as you'll see in the actual screens.

Technical Workflow

Along with layout sketches, I also produced sort-of flowcharts of the technical and user-facing workflow using yellow sticky notes in a grid format. These ten charts helped convince the developers to separate the user's steps from the back-end technical process. Three examples are provided here.

Original Implementation

Three things are constant across the top of every page: the purpose of the current screen, a Help link and the token ID. The page title is always in large type in the upper left (where you start reading). The help link is always in the upper right. The token ID, beneath the title, is presented in the hopes that the user will internalize it; a spoofed page would not be able to pull the ID from the card. The icon next to the token ID is just to set it apart visually; color might have worked just as well.

Everything is plainly and concisely written. “Setting up your token” is used instead of “Smart Card Enrollment” or “Token Personalization.” The token ID is presented as a sentence, including a period at the end: a subtle cue that part of the ID hasn’t been cut off. Progress through the unfamiliar setup process is shown with a sort of progress bar along the top. I elected to present a highlighted list instead of spelling out “Step X of Y” so you wouldn’t have to actually read the words to know where you were in the process, you could subsume the position of the highlighted region itself.

You “choose” and “confirm” a PIN. Form buttons read “Start over” instead of “Reset” and “Save your security questions and answers” instead of “Submit.” The graphical PIN pad buttons have individual tooltips and the cursor changes to a finger to maintain the “clickable” affordance.

The “Accounts” page lists the sites the token has been preconfigured for (the “relying parties,” although we never call them such in the UI). There’s a logout link next to the token ID: this conveys the importance of logging out by putting it with the other permanent page items, and it’s on every page after you’ve logged in.

New here is the use of site logos instead of spelling out the name. The issuer sites have their logos grayed out, as no accounts are set up yet. They’re “turned off.” “Add a new account” is the largest link on the page to provide an additional cue that it’s the next thing to do. The token update service is in small type at the bottom of the site list, aligned with it; it represents where the next site installed will go.

Once an account is set up, the logo is “turned on.” “Add a new account” is reduced in size and pushed down within that site’s list of items. The account username is now the most important item in that section, so it gets the large size. “Remove from token,” the same size as the add account link, makes it clear that the account won’t be deleted from the service provider, only the device. Each link is clearly positioned. There’s no way to accidentally click “remove” instead of choosing your username, no way to log out when you mean to click “help” (hopefully Fitt’s Law makes clicking your username more likely than adding a new account).

One thing missing in the original prototype design was a “Change PIN” link. Given these rationalizations, I’m not sure where I’d put it: it’s not a relying party function, so it shouldn’t go under the “update” link, but putting it with the log out link (the right place) puts it in dangerous proximity to log out and help, and I’d think you’d use those two functions more than changing your PIN. A sentence might work out the best, such as “Log out or change your PIN.”

Note the differences here compared to the implementation of the sketch design, which had a different appearance for the “blank slate” of having no accounts. This turned out to be visually awkward in practice:

Marketing’s Changes

For the product launch, marketing made some changes to the UI.

First, the top of every page was given a branding banner (changed here to generics). I suppose our company name is arguably the most important part of a product launch demonstration UI!

The token ID was moved to the bottom right of the UI and was changed from a sentence to a more technical representation. This means its position will always change as the length of every page is different.

The progress bar was originally changed to a “Step X of Y” message, but later reverted to a narrower version of the original.

Many of the prompts were changed, notably “Activate” instead of “Setting up,” “Select your 4-digit PIN and click green arrow” instead of just “Choose your PIN,” “Your secure services” instead of “Accounts,” and “Clear” and “Save Answers” instead of the original, longer form buttons.

On the Accounts page, the vertical spacing between usernames was increased. “Add services,” “Change PIN” and “Logout” became graphical buttons at the bottom left of the page, outside of the relying party column.

Errata

The token ID information icon is from Mark James’ Silk icon set.