Re: *text-restricted-dialog-item*

[cfry@MIT.EDU (Christopher Fry)]

Moon has made an important discrimination when we are considering the 
design of *text-restricted-dialog-item*, the case where there's just one
editable text item in the dialog, and the case where's there's more than 
one. If we can solve the > 1, we can simply use it in the 1 case. But 
the dimming of the OK button that Moon mentions is such an attractive 
idea for the 1 case that its probably worthwhile to special case the 1 
case, esp considering that its common.

I've been mainly considering the > 1 case since my application 
frequently has dialogs with 10 or so editable text items.
In a message I send to hohmann personnally [cause I wasn't sure of the 
general interest in this item] I wrote:
______
The main approach I've been thinking of is have 4 separate bit maps
of faces. Frown means current string is illegal and can't be extended to 
be legal
straight face means current string is first part of a legal string but
not yet complete.
Little smile means current string is legal but there are additional 
legal strings that you can get by extending the string

Big Smile is current string is legal but if you add chars, it will 
become illegal no matter what chars you add.
I'm not wild about this scheme. but its at leastan idea to shoot at.
_______
This morning, while considering Moon's proposal, I thought of another 
scheme, which at the moment I like better than the above:

We use the presence or abscence of whitespace between the last char 
typed and the right border of the editable text dialog item to signify 
possibilities to the user. Specifically:
If there is whitespace, it means the user can type more to get a legal 
string. If there's not, then the current string is acceptable and cannot 
be extended. 

To descriminate between "legal and there's extensions which are legal 
also" vs "legal and their aren't", I propose a dotted vertical line
drawn just after then last char for the case that there are more 
possible completions. This line is meant to look like the right border 
of the editable text dialog [which signifys no more can be typed] but 
not a STRONG border, ie you  can break through it by typing more.

Scenario:
Dialog rect starts out empty and wide enough to contain the maximum 
length string that is legal.
User types in a char. If no legal completions begin with that char, the 
char is NOT inserted into the rect. Machine beeps.
If char is legal and no extensions to the string are legal, the dialog 
rect SHRINKS to contain just that char with no whitespace between the 
last char and the right of the dialog.
If the lastchar types forms a legal string but there ARE extensions that 
are legal, a dotted vertical line gets drawn to the right of the char 
simulating the right border of the dialog yet indicating that its not a 
hard barrier.

One reason I think this interface might work is by analogy to a word in 
a crossword puzzel. If there's space for a long word, you don't have to 
count the squares to know its got to be a long word. You think of a 
longword yet are unsuere if its exactly the right number of chars.
Without bothering to count them, [or the squares] you start writing them 
in [in pencil]. If you can write the whole word and leave no whitespace 
on the end, you know your word is legal.

As in a crossword, we could consider the whitespace conveying > 1 bit of 
info. ESP if the user is typing in a fixed width font, the AMOUNT of 
whitespace can let the user know about how many chars are needed for 
completion. Dynamically adjusting the size of the rect to always contain 
exactly the right amount of space for the possible completions might be 
too distracting. Its something that should be played with.

Related ways of showing the same information:
Instead of resizing the dialog, draw a solid, [maybe 2 pixel wide] line 
after the last char. Also consider graying out the remaining 
"whitespace" in the rect if it can't be used. Light gray means you can 
still type more, dark grey or black means you can't.

Not inserting a bad char may be too drastic. If users want to see what 
they've typed, whether its right or wrong, consider putting the bad 
chars in a different font, or even better, a different style. My 
favorite "strikeout" style would be perfect for this though 
unfortunately its not commonly available on the Mac.
One advantage of this is that a user may type in, say a 10 char word, 
yet misspell the 2nd char. Then the 2nd through 10th char would be shown 
in strikeout style. When the user corrects the 2nd char [moving cursor 
with mouse vs rubout], then the characters become un-struck-out. [Try 
that in the major leagues!]

Implementation advice to hohmann:
Do the easy stuff first. Draw the dotted and bold vertical line.
One advantage of the bold vertical line vs rect shrinking is that it 
still shows the user the Max length the string COULD be if the existing 
chars where erased. Aleviate the tendency for a line-delimited rect to 
look like TWO separate editable-text dialogs by extending the line 
several pixels beyond the upper and lower borders of the rect.