Re: First UI component needing replacement.

[Dylan Griffiths <Dylan_G bigfoot com>]

colin z robertson wrote:
> I'm not actually sure that a special character is needed for
> auto-completion, certainly not in Open mode. Consider how Netscape 4
> handles auto-completion in the url bar: the auto-completed section
> after what has been typed is selected, so when the user hits the next
> character it is replaced and then updated again. Whether we want a
> open/save dialog box to work like this is another matter... I'm not
> quite sure about it myself.

You know what I hate?  When the computer thinks it's smarter than me but
isn't.  Like, not even close.

Yes, auto complete makes sense if you type slowly (< 40wpm), AND if you
visit a small subset of sites, but every time I have had the misfortune to
use a system with auto complete, I have hated it.  An explicit request for
autocompletion is cool, I like hitting tab to see my options or save some
typing.  However, when I use Netscape on Windows and decide to go to a new
URL and it tries to "out wit me" by autocompletely at a rate only slightly
faster than my typing, I want to scream.  The few times I've used IE 5
"enabled" PCs where they've shoved this "strap the user down, hold their
eyes open, and drip water into them" clockwork-orange like approach to auto
completetion in every dialog, I've just GIVEN UP and moved on.

Yes, it's that bad.  Yes, I hate it that much.  You'd think that they'd
include a way to turn it off.  No such luck.

That's why I'm hoping we get a good way of letting the user signal for
help.  Since tab has been taken, we'll have to get creative.  Perhaps
alt+tab, etc.  But I'd prefer to not allow auto-complete into anything
unless we 1) provide a way to toggle it, and 2) have it in a sane default
(like off).

I think it's not apropos to this particular discussion, since selecting the
file name from the listview works far better anyway (even via keyboard
shortcuts) :)
 
> I can't agree with this. If I want to clear an entire text box I often
> hold down the backspace key until I see that everything has gone.
> Other users might repeatedly press backspace very fast to achieve the
> same effect. Either way it would result in backspacing past the
> beginning of the text field resulting in some unintended directory
> jumps.

I highlight and delete.  IE: Shift, home.  Although Linux's support for such
time savering shortcut keys as home and end is spotty, to put it incredibly
nicely.
 
> Also the idea of tying this to the history rather than to the
> directory hierarchy seems highly unintuitable.

Yes.
 
> > Why? The system beeps and displays a little popup-tip window over
> > the text field that says "no such file". You don't want people
> > typing in non-existant file names when the dialog is asking for
> > a file to read.
> What happens if the user is editing the middle, rather than the end,
> of a filename? "food.txt" is already in the text field, say, and the
> user wants "foolish.txt", so the user deletes the "d" and types
> "lish". I'm not sure what the correct behaviour in that situation is.
> Certainly it is not to restrict what gets typed on a character by
> character basis.

Yes.  The dialogs should not attempt to outthink the user.  This leads to
frustration, hatred, and finally formatting.
 
> Another problem with this restriction is that users won't be expecting
> it. The user wants "foobar" (which exists) but instead types "foobat"
> (which doesn't), quickly realises his mistake and hits backspace and
> then "r" without looking at what's on the screen. The result is
> "foobr" if it exists or "foob" if it doesn't.

-- 
    www.kuro5hin.org -- technology and culture, from the trenches.