| Date: | June 22, 2005 / year-entry #160 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050622-47/?p=35233 |
| Comments: | 3 |
| Summary: | In an earlier comment, Aswin Gunawan asked why the Run dialog does autocorrection but not the Run key? One is a programmatic interface and the other is an end-user control. End users are not expected to be understand how computers do things. They want, and even expect, the computer to help them out with what... |
In an earlier comment, Aswin Gunawan asked why the Run dialog does autocorrection but not the Run key? One is a programmatic interface and the other is an end-user control. End users are not expected to be understand how computers do things. They want, and even expect, the computer to help them out with what they're typing. This means spell-checking, guessing missing information, and generally "doing what I mean". For example, web browsers don't require you to type "http://" or "ftp://" in front of web addresses any more; they guess whether you're trying to connect to an FTP site or an HTTP site based on context. Of course, sometimes the computer guesses wrong—maybe you really wanted to use HTTP to connect to a site whose name begins with "ftp."—in which case you can re-enter the command and provide more information so the computer won't have to guess as much. Programming interfaces, on the other hand, are for people who do understand how computers do things. If a program makes an invalid request to a function, the expectation is that the function will return an error and not try to "guess" what the programmer "really meant to do". Because a computer program can't look at the "autocorrected" result and say, "No, that's not quite what I meant," and retry the operation with "a few more hints". (Heck, if the program had "some more hints", why not just pass the "fully hinted" version in the first place? Save you the trouble of calling the function twice.) Computer programs prefer predictability. Autocorrection and context-driven guessing are unpredictable. Imagine how much harder it would be to write code if a stretch of code changed it behavior based on fuzzy logic like "Well, there was a file in the directory that had a similar name, so I used that one instead", or "This class doesn't have a field called 'current', but the one over there does, so I'll guess that you meant that one." I'm sure some people will point out that the CreateProcess function breaks this rule of "don't guess; just fail". We'll discuss this next time. |
Comments (3)
Comments are closed. |
I always thought it would be nice if the auto-complete filled on when the text box loses focus. So when I type "c:pro" and hit Tab, it will become the highlighted entry, which is "C:Program Files".
I guess if I wanted to override this and really keep my "c:pro" without changes, I would have to hit Esc first.
Is autocorrection the same thing as autocomplete, i.e. when you start to type the current date in MS Word, it suggests whole string?
This kind of feature is useful, but has a potential to be terribly annoying if not done properly. My favourite example is Visual Studio 2003, where virtually any keypress is interpreted as a confirmation of the suggestion. But maybe I wanted stringb not StringBuilder, thank you very much.
This is not meant as a troll, so I want to mention Visual Web Developer 2005 (currently public beta) as a positive counter-example. (I write ASP stuff mostly.) I don’t know what it does differently; its suggestion go even farther than those of VS2003, but somehow it manages to be not so annoying, but indeed very helpful. It’s even better than Eclipse (IBM’s Java IDE), in my opinion.
My actual point is that programmers should exercise great care to make autocomplete suggestions easily overridable. Your user will thank you!
I think Raymond is talking about, for example, when you enter C:Program Files and the system guesses you mean "C:Program Files" and not "C:Program" "Files".