schmoozy space Mark Szpakowski's szpace blog

I've had a recent interesting UI experience with providing an iNames login for a site: many, many error messages showing that people are typing search terms into it. Ie, they are using it as a search box!

One reason this may be so is that an OpenID (which includes URL-based IDs and iNames) login just asks you for your OpenID: there is no password field. When you authenticate, you enter your OpenID, and are taken to your Identity Provider (IP) (unless iName Single-Sign-On is taking place), where you provide your password. In OpenID, your IP is the only site to which you provide your password! So the site you're accessing (technically the Relying Party) asks only for your id, and not your password, and so displays a single text field in which to enter that ID.

However, I think people are used to a single field, especially at top of a window, being a search field, in which you enter search terms.

One proposed solution: intially display a Login button, and no text field. When that is clicked, a text field for entering your id slides open, you type your iName there, and click the Login button to get authenticated. If nothing has been entered in the text field it slides shut when the Login button is clicked. I'll see how well that works.

There's been a related discussion (cf Joannes Ernst's blog) on best practices for an OpenID enabled login design that also supports the username/password option. I wonder if the same issue will hit that design if the OpenID version of a login box is shown by default. No, people do not read the fine print!