Avoiding Confirmation Boxes

One thing I try to avoid in interface design is unnecessary user interaction – Basically, asking the user for feedback when it isn’t needed. The area that probably bothers me the most are “confirmation boxes” – Especially those that block the entire application until you’ve clicked ‘OK’?

I’m not really sure why you see them so often in applications since I’m pretty sure that users and developers alike probably get tired of seeing them. Not only that, studies have shown that they are mostly ineffective, normally only earning a cursory glance before being dismissed.

So what can you do instead?

Don’t Confirm Success, Notify On Failure

Probably the easiest and quickest improvement to an application is to stop confirming when your application worked. How many times have you seen this pointless little window pop up?

Uh, yeah…

For the most part, a user should be able to assume that their “request completed successfully.” — Otherwise, why the heck did they buy your software to begin with?

Instead, pop up a modal dialog box if something goes wrong and their request didn’t work. This is a much better time to interfere with user work flow.

Allow Permanent Dismissal

New users of an application don’t mind confirmation boxes as much since they are still poking around and trying to figure out what everything does. But after the 10th or 15th time the ‘your request has been completed!’ message is starting to wear on them.

Sure, it was helpful at first but now that they know the expected behavior, the additional confirmation is an annoying extra click.

Ah, now that is better. I’m confident using this part of the program – stop bugging me!

Even Better – Don’t Confirm, Make It Easy To Undo

Remember the computer before the undo button? It was painful and frustrating, but then one day like magic we could fix our silly fat-finger mistakes – Genius!

What about the Internet before the undo button? Oh… wait. The ‘undo’ button is actually still pretty uncommon in web applications. Of course, web applications aren’t the only area that this applies – but it is still possible to make it happen. GMail is a great example of how this applies to any application – including the web.

The message explains what happened and gives immediate actions for the two most probably user responses – “What the heck did I just do?” and “Oh snap, I didn’t mean to delete that!”.

Use Visual Indicators As Confirmation

Visual indicators work well as additional confirmations. If you make it clear enough what a user is about to do then normally you can avoid a confirmation box.

Red highlights, short and clear sentences, explanation of the final result – All of these items act as an additional confirmation for the user to understand the result of their action. To take it a step further, the text on the button OK would be even clearer if it said Delete (see how easy this is!)

It doesn’t take much to reduce, and in many case eliminate, the dialog boxes we pop up in our applications. You’ll be happier, your users will be happier — Heck, I’ll even be happier even if I never use your application.

What are ways you can use to limit the number of dialog boxes you use in your applications?

More jQuery Magic – iPhone Style Password Box

I like to think of myself as a technology-neutral developer that can look past any Microsoft-Apple rivalries and instead focus on the best tool for the job…

I like to think that — but I know that I’m a total Microsoft fanboy… 🙂

So wouldn’t you know it that my entire FAMILY has been purchasing Apple stuff lately? Each (adult) family member has an iFail iPhone (except me, of course), my brother has an iTouch, sister-in-law with MacBook – Blasphemy! From my own flesh and blood!! ACK!!

However, despite this treachery I did discover that I did like the way that Apple handled inputting passwords.

iPhone Style Password Box

It’s worth mentioning up front that this code is just an experiment — it’s not a finished product and probably shouldn’t be pasted into a live site.

If you’ve used an iPhone before then you’ve probably noticed that you can see the last character you entered when inputting your password. This character disappears after a moment or two or the next time you enter a character. Using some jQuery and a hidden password field I attempted to create something similar.

[Sample version here.]

Now unfortunately, by using a div instead of an input I’ve taken away the ability to select the characters in the field. When I was working on this I had an idea that I might try using the ‘contenteditable’ property instead and then display the normal password box for browsers that don’t support it.

Why Not A Input[Type=Text]

I tried doing a similar idea with by using a regular text box and just masking the characters on the fly, but ran into a problem where pasting a password would cause the whole thing visible for a moment — which seems like too much of a risk.

Another Approach

The basic idea of the Apple style password box was to show the most recently entered character but the first example lost some of the usability of a normal password box. I figured I’d give the idea a second pass, but adjusted it to be a little more HTML friendly.

[Sample version here.]

You’ll notice in this version that the characters actually float up as you enter them. Similar to before, after a few moments, or when you press a new key, they will disappear.

This version is better from a usability standpoint, but it does have a couple problems of its own. For example, if you enter a really long password then the floating box stops moving at the end — no big deal right? Well for the end of the box, no, it looks fine — but if you click back out in the middle then your floating hints may be off-centered.

Simple But Effective Interface Designs

The code above isn’t ready for publishing, but they are some interesting examples of how you can take a typical form element and use a little jQuery to make some great usability enchancements to them.

You may have read some of my earlier jQuery posts about mimicking Vista style password boxes or creating search highlighting for web pages and noticed that it doesn’t take that much code to transform the functionality of your pages.

How do you enhance your pages for your visitors? It doesn’t take much!

More jQuery Magic – Search Highlighting

So at first glance, which browser do you think we’re using in the screenshot below? FireFox? Chrome? IE8?

It’s actually IE6 and all that search highlighting is done via jQuery!

Now most modern browsers do some sort of highlighting now when you do a “Find On Page” search so this may not be the most incredible jQuery trick you see in your life — but at the very least it’s the most impressive jQuery trick on this page.

Highlighting The Page

If you’re interested in following along, you can view the demo/source code at this page.

In order to search the page we’re going to need to a couple things…

1. Check for user input.
2. Use the search phrase and find matching text.
3. Replace our matches with the new highlighted text.

Let’s jump in.

Checking For Input

jQuery makes it easy to work with events that we’re previously… well… a pain. The .keyup() function allows you to supply a delegate to monitor for changes to your search field. Below is the code you’ll find in the example.

//snip ...

self.input.keyup(function(e) {
	if (self.search) { clearTimeout(self.search); }
	
	//start a timer to perform the search. On browsers like
	//Chrome, Javascript works fine -- other less performant
	//browsers like IE6 have a hard time doing this
	self.search = setTimeout(self.performSearch, 300);
	
});

//snip...

As you can see by the comment, we don’t do the search each time the key goes down. IE6, bless it’s heart, tries it’s best to keep up but it’s a losing battle. Instead, we use a short time out to check for when the search begins. In many ways this is a lot better anyways. It’s fairly transparent to the user and saves undue strain on the browser.

Search And Find

Once we’re ready to search, we need to check the user’s input and format it as required.

//snip...

//create a search string
var phrase = self.input.val().replace(/^\s+|\s+$/g, "");					
phrase = phrase.replace(/\s+/g, "|");

//make sure there are a couple letters
if (phrase.length < 3) { return; }			

//append the rest of the expression
phrase = &#91;"\\b(", phrase, ")"&#93;.join("");

//snip...
&#91;/sourcecode&#93;

If you've read some of my blog before you know that <a href="https://somewebguy.wordpress.com/2009/06/04/complete-control-over-your-webforms-output/">I really like Regular Expressions.... a lot...</a> In this part we use our expressions to format our search phrase. Specifically, we're trimming it down and replacing spaces with "or". This makes sure that any phrase in the box is matched.

You may want to change this depending on your needs, for example, require all values to match, etc...

<h3>Find, Replace, Repeat</h3>

Once we have a valid search phrase, now it's time to actually replace the values on the page. You'll notice that I target specific types of elements since you don't want to search the entire document. Unlike a built in browser search option, this function actually makes changes to the markup. If you we're to highlight a value inside a <code>textarea</code> then you're going to end up with markup instead of a yellow block.

It's worth noting that this version only works with elements that don't have additional markup within them. Links, bold text, spans, etc... they are going to be wiped out by this. I'm working on another version that respects child elements, but for now - be warned.

The code below shows what we're doing to make this change.


//snip...

//find and replace with highlight tags
$("h1, h3, p").each(function(i, v) {

	//replace any matches
	var block = $(v);
	block.html(
		block.text().replace(
			new RegExp(phrase, "gi"), 
			function(match) {
				return ["<span class='highlight'>", match, "</span>"].join("");
			}));
	
});



//snip...

In this example I’m limiting my changes to a couple header tags and paragraphs. This helps me avoid things like my search bar at the top of the page. You could also create a class named .search and use that as a target.

The code starts by removing any existing highlighting classes from the element and then follows up by replacing any matches with a highlight tag.

Practical Uses… (tell me if you think of one)

I’ll admit that this was written just to see what it would look like. Most browsers already have a search on page feature that can be used to achieve the same effect. However, there are a few places that something like this may be handy.

AJAX Search Field
Have a page that searches other pages on the site and shows them as an list below the search field? Why not search the page they are on at the same time and highlight possible results?

Client Side Highlighting
Showing lists of data? Why not highlight matching values when a user hovers over certain buttons and filter options? Give them a preview of things to come?

Highlighting? How About Formatting?
Why just highlight text? Why not use this as dynamic formatting for text? Give users a preview of a change they are getting ready to make when they roll over a button?

Think this could be useful? Who knows! But it just goes to show just how much you can do with just a little bit of jQuery!