Question: I have some information to enter in a text box. The data is structured and only some sequences are valid. For a phone number, for instance, a letter such as `A` is invalid.

So should I intercept keyboard events and prevent typed letters from reaching the text box, or should I draw some red squiggly lines (or another visual cue) to let my user know the letter is not acceptable? Which is a better user experience?

Answer: 
I would suggest a hybrid of both approaches, but only for strictly-validated fields like phone numbers (SSN, zipcodes, etc ... anything that **must** be numeric by definition).

Track each keystroke and, when the user types an invalid character, show it ... but immediately signal that something's wrong. Maybe turn the input field red and display a "Please enter numeric characters only" to the right of the field.

Blocking input is a no-no because it can be misinterpreted by the user. They might assume a problem with their machine or input device, not that they weren't supposed to type a letter in a numeric entry box.

Validating *after* the input is completed can be annoying. Particularly with fields like those used in password creation. Some sites require 6-character passwords with only alphanumeric characters. Others require 9-character passwords and allow any character (including !@#$% and such). Typing a password and only finding out *after* I've typed it is the most annoying form type I've found and has actually turned me away from several services.

Providing dynamic feedback as the user enters data helps them

1. Know which field had the error while they're still in the field
2. Proactively correct input errors before submitting data
3. Learn from the experience as they go

Blocking input fails on all 3 accounts. Highlighting validation errors after the textbox is filled in fails on all 3 as well.
As with most things..depends on context. I have a more specialized take on the topic. Most of the applications I, or my group, work on are technical in nature and are only used by the reasonably trained. As such we can place more responsibility and freedom in the hands of the users than you could with the general public. Briefly, some of the guidelines we use...

* Disregard any invalid entry....block invalid keystrokes.
* Indicate invalid fields, a state that
should be all but impossible, by
contrast and color\*.
* Focus is always under user control.
Do not trap the user or prevent
a change of focus.
* Never throw a modal warning/error
box. Ever.
* Never ask the user questions. Software is a tool not a person. Yes I am sure.
* The Enter/Return keys always mean:
Accept changes and move on. Do not
change this by using focus on a
cancel/exit button as the default on
Enter.
* The Escape key always means: Discard
and exit.
* Provide auto-completion whenever
possible.
* Provide short-cut entry for numerics
that have a min/max limit. e.g. If a
valid value is between 0.12 and 100.387 then
entries greater that 100.387, like 999, are taken as 100.387, etc.
* Establish very clear black and white
rules on behavior..rules the user can
understand. If this becomes overly complex...re-think it.

Almost all of the examples are user requested and, yes...implementation is sometimes a real bear/nightmare/killer but rarely impossible.

Caveat: *Again, these examples are given in the context of a vertical system with a technical user base....not a web general public form, etc. Your mileage my vary.*

\*Except red. In our business red means: Danger you could be killed...or worse.