Bad Pattern: Pre-Scolding

Home / Interaction Patterns  / Bad Pattern: Pre-Scolding

Here’s a crappy little form field pattern I encountered a few days ago. I haven’t seen it mentioned anywhere yet, so I’m claiming naming rights and calling it “pre-scolding.”

I’m sure you’ve encountered something like it: you’re filling in a website or app form, you enter a particular field set – in my example, it’s a DOB field set – and the second you enter what is definitely valid data, you’re scolded with flaming red error indicators.

Dude. I’m not even finished.

Notifying users of an error as quickly as possible – that is, without waiting for them to submit the whole dang form – is a good practice. But this is an overzealous application of the principle. A better and more common pattern would be to validate input and flag errors when the user leaves the last field of a set. The way this validation scheme is working, I feel like I’m being scolded before I’ve actually made a mistake. In other words, I’m being pre-scolded.

One situation where the pre-scolding pattern might be useful is when the field asks for a password with complexity requirements. In that case, flagging the field as errored upon entry and until the user satisfies the complexity rules is actually a good practice. This can also be done with dynamically refreshing content and strength meters. Here’s one example:

As you can see, the interaction make use of both textual guidance and color to guide the user toward creating a stronger password. Thanks to Misha Rudrastyh for the example.

But before you run off implementing password strength indicators everywhere, you might want to give this article a read.

No Comments
Post a Comment