Date: 24 Oct 95
From: Bill Kayser

I was looking over the PPR and read through your document describing the CHECKS pattern language. I think that will be really useful for what I'm working on now. Actually, I'd already utilized the concept of whole value and exceptional value (to some extent) so it's nice to have a vocabulary for what I've done.

A question:

How would you describe a situation where the user types in "garbage" for which there is no corresponding "whole value." In effect, the UI is in an invalid state, but there's no way to find that out from validating the domain object. Right now, we ask both the UI AND the domain object if the user has entered data valid for "posting." I think we'd like to just ask the domain object though. Any thoughts?

From: Ward Cunningham

Thanks for your note. Regarding CHECKS, I use the word "value" to refer to objects that are defined by their (normally stable) content rather than their identity. Magnitudes, Points, Rectangles and Strings are often used as values. A domain may require more "whole" values such as CalendarPeriods or ForiegnCurrency. Fields should construct WholeValues when they complete: 
        6mm usd  ==>  six million U.S. dollars
        *&^*&^*& ==>  nil
Typing junk is the same as typing nothing. The model has to check for an appropriate value (i.e. above minimum) but not for absent values (nil exhibits UninterpretableBehavior) or junk values which are turned to nil.

From: Bill Kayser

But what if you don't want to blank out what they typed in? You might want to indicate they've typed in something meaningless, but you may not want to erase it. I might have thought I typed in "3/11/67" but instead typed "311/67" but I may not know what I did wrong if it goes blank.

From: Ward Cunningham

True, if someone typed 311/67 for a date, you might want to tell them that they didn't type enough slants (/). You might also want to tell them which side of the slant key they hit that kept it from registering their finger stroke. You might even want to recommend some finger exercises that would improve their typing.

Now the thought experiment: If you could do all that, should you?

CHECKS says no. Echo Back argues that such diagnosis of the user by the computer interrupts the user's control of the dialog. Even if you were to delay the diagnosis until Deferred Validation, you would find that the user is focused on larger issues than diagnosis of typing errors. By draging the dialog down to the level of typing you make your own program seem picky and judgemental. Compare:

The first diagnostic, while trying to be helpful, actually says: The second says:

Our goal as programmers is to graple with the toughest business issues we can handle. Our users will allow us the simplifications that CHECKS recommends. Its our way of climbing our side of the ladder.

ward@c2.com