[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cfry@MIT.EDU (Christopher Fry)
- Subject: Re: *text-restricted-dialog-item*
- From: moon (David A. Moon)
- Date: Mon, 09 Mar 92 18:32:06 EST
- Cc: email@example.com, firstname.lastname@example.org, email@example.com
> 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
> 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.