Simple widget – Complex interaction

Recently I was working on a widget for an internal product group when I found myself spending a lot of time refining the user experience. This widget is just a test widget, intended to provide a bare-bones frontend so the product engineer can know things are working (or not) as she figures out how to hook up the backend. Not much to the interface, really: a text input field and a button. The user is just supposed to enter a person’s name or the name of a company, activate a search, then get back a simple yes/no status (these are still early days for this widget, it will do more).

So, to start, I took an early version of the Argo widget which was just a text entry field and added the group’s name (actually, just initials). However, usability testing of this widget had revealed the interface was too simple (this is possible) and users didn’t know they were supposed to press Return to make something happen. In response to this finding, I figured I would just add a button. But just a button is not enough.

First, I had to make the button respond to the user on hover to cue the user they were on a clickable interface element. To provide this feedback, I made the button a bright color on hover by swapping images when the mouse was over the button. Hint: Bright on hover is best as you can make the button only subtly visible most of the time, then have it come to life in response to the user’s action.

But what does this button do when you click it? To answer that question, I added a tooltip, the wording of which I labored over ’til I got it pared down to something brief but informative. So then the button explained itself to the user.

I continued to labor over this button until I told myself to stop because I simply didn’t have any more time. One of the things I didn’t have time to implement: Currently, even when the widget doesn’t have the input focus, the button highlights on hover; the button should be unresponsive. I also wanted its brightness to pulsate while the widget was busy getting the yes/no response from the web service; this is not hard to do, and does provide important feedback to the user, but I just had to move on.

There is another form of interaction feedback I put in this simple widget worth mentioning: field prompting. Field prompting is a form of integrated Help which tells the user what kind of input a text field is looking for. It does this by pre-populating the field with a string of text, dimmed (#BABABA), which describes (again, like a tooltip, brief and informative) the expected data. When the user clicks this field, the prompting text is cleared and the text color is changed to black (#000000) so the user can enter whatever she wants. But if the user doesn’t enter anything and the widget loses focus, the prompt reappears.

There is nothing particularly spectacular or inventive here, just fulfilling user expectations of how a professional software product should behave. It takes a lot of honing and polishing of the user interaction to deliver this level of quality. But all this smoothing the rough spots, making the application surface responsive and informative, is well worth it because it is what makes it possible for the user to work without the widget getting in the way. In the end, that is how you can really help people do their work: By making your work as an interaction designer invisible. The compact nature of a widget makes this all the more important.