Re: *text-restricted-dialog-item*

[moon (David A. Moon)]

> Date: Fri, 06 Mar 92 13:54:19
> From: cfry@MIT.EDU (Christopher Fry)
> > 
> > (defclass *text-restricted-dialog-item* (editable-text-dialog-item)
> >   ((max-length :initarg :max-length :accessor max-length)
> >    (char-set   :initarg :char-set   :accessor char-set))
> >   (:default-initargs
> >     :max-length nil
> >     :char-set   nil))
> Bravo! Restricting user input is  useful MOST times an editable text 
> dialog is required. 
> 
> Having worked on much hairier systems that have a superset of this 
> functionality, let me guide further development by offering this 
> obvervation.
> The user needs to know the status of the currently being typed in string 
> on a character-by-character basis. There are four possible states:
> 1. The current string can match a correct result if extended.
> 2. The current string is a correct result
> 3. Both one and two
> 4. Neither one or two.
> 
> It would be nice to find an intuitive display of these two bits that 
> didn't take up much space in the dialog.

Dimming the OK button is the standard way to distinguish #2 from the others,
or to distinguish #1 and #2 from the others if the OK button would 
automatically extend the string.  To clarify my tangled syntax: #2 undims the 
OK button.  However this doesn't extend to complex dialogs where you need to 
distinguish between "all fields contain valid values" and "this field is valid 
even if other fields aren't filled in yet."

The other thing you're trying to indicate is whether, when the OK button is 
dimmed, the user could turn it undimmed without using the rubout key (more 
exactly, by adding characters to the end of the input field without adding 
any).  I don't have a good suggestion for this, but one possible suggestion is 
to have a text field in the dialog which is normally blank, but can contain 
commentary about what the user has typed so far.  So it could say, for 
example, "There is no valid completion of ``fou''." if the user should have 
typed foobar.  This could also be used for things like "Punctuation characters 
such as $ are not allowed here." and "32 characters is too long." rather than 
only feeping when invalid input is entered.

Alternatively there could be a small icon next to a field which is a comment
on its current value, perhaps ? if the value is no good, ... if it is good so 
far but needs to be extended, <- if it is blank and needs to be filled in, 
blank if it's okay.

> Two more pieces of information should be available to the user, perhaps 
> with balloon help, or some other action requiring just a little effort:
> 5. What are the legal possbile results
> 6. Given the current string, what are the legal possible extensions.

I think balloon help is inappropriate for this, because balloon help is 
supposed to be a small amount of text but the number of possible valid inputs 
is potentially large, and because balloon help is a mode whereas this sounds 
like something one wants to request explicitly.  Probably a small icon button 
next to the input field, the icon being some "more detail" kind of icon like a 
magnifying glass, would be appropriate.

> One way to tell the user what he needs to know WHEN he needs to know it 
> is to pop up a dialog containing number six [or number five, if six not 
> available] only when state 4 is reached.

This needs to be unobtrusive, but is worthy of experimentation.  Think of 
"context sensitive help", "user modelling", and "intelligent user interfaces."  
Think also of the fact (factoid?) that most power users hate balloon help, and 
try to analyze the reasons for that (which I think have to do with whether or 
not the help tells you something you find useful at that moment, or only 
something that is useless or that you already knew).

Disclaimer: I have no credentials as a user interface expert.