[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com (David A. Moon)
- Subject: Re: *text-restricted-dialog-item*
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Wed, 11 Mar 92 13:36:58
- Cc: cfry@MIT.EDU (Christopher Fry), firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
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
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
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.
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
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.