On Wed, Mar 21, 2007 at 08:18:52PM +0100, Oswald Buddenhagen wrote: > On Wed, Mar 21, 2007 at 05:32:55PM +0000, Dave wrote: > > On Wed, Mar 21, 2007 at 03:51:02PM +0100, Oswald Buddenhagen wrote:
> > > this is silly. everbody makes mistakes. > > > > That doesn't matter. The user is in charge of deciding how many (if > > any) limits he wants to place on his own decisionmaking authority. > > The question is outside of the domain of the programmer. > > > i sure agree that the programmer has no right to forbid the user to do > something utterly stupid, nor to interrupt him by asking questions before doing what he asked for > but he definitely has the "moral obligation" > to guide the user away from doing it. I don't think there's any such obligation. I think it's nice to tell people in the documentation about "interesting" things your program can do as side-effects of doing its job, but that belongs in the documentation (to educate the user), not the program (to get in the user's way). > the sillier the thing, the > stronger the guide should be. simple principle. You're working on a sliding scale here. Sliding scales are never simple without a mapping function. Your mapping function here is way too subjective to be simple. > > > confirmation dialogs are a typical example of a measure to prevent > > > small mistakes from having big effects. > > > > That's why mv(1), for example, offers the -i option. [...] > > > in which case it is perfectly ok. however, when pressing F8 instead of > F7 means as much as deleting all of /home instead getting a dialog to > create a directory, you really start to appreciate confirmation dialogs. > ;) The problem there is artificial, created by the user interface. I'd counter (from a UI design perspective) that since the function keys aren't on the QWERTY keyboard, they're probably not being hit accurately. If that's the case, then assigning a destructive (i.e., difficult to undo) function to a function key is probably not wise in general. Additionally, I'd argue that if you're going to assign a destructive function to a function key (say, it's a commonly used function), you'd probably be wise to keep it away from often used nondestructive functions. However, none of this is the domain of the programmer. It's up to the UI designer (who's ideally (very close to) the user himself) to decide what functions (if any) should be mapped to function keys. I, for example, wouldn't want to map anything to the function keys, since (a) they're off the QWERTY keyboard (er, the Dvorak keyboard), and (b) they're used for VT switching. As the user, it's my domain to decide on my interface. (After all, it's called a user interface for a reason.) The cleanest interface for a program is a command-line interface. The second-cleanest is a command-based interface. (There are some applications where a command-line interface is considered impractical for one reason (excuse) or another. For them, the best recommendation is to simply read commands on stdin and dump results on stdout. A user can then easily script a UI to meet his own needs, or ask (pay) a friend (vendor) to script one for him. The original programmer may want to bundle his own UI (if he uses one himself) for users to take a look at and maybe even use as a starting point. That (among other things) is what contrib/ is for.) > i cut the rest of the quote, as it just doesn't make sense. the example > simply doesn't fit. ;) Why doesn't it fit? > > > but like any other safety measure, they have to be placed wisely. > > > > You just hit the nail on the head: the user himself is the only one in > > a position to reverse engineer his own psychology in order to place > > prompts wisely. > > > it might surprise you, but hardly anybody is able to do that. It does surprise me. I'm not a UI design "expert" and I was able to build my own UIs for my own (now defunct - thanks to dead server) editor, chat program, and email program. (My primary toolchain revolves around those three applications, so I don't really need any other substantial user applications in the course of my normal life.) > apart from that, you are completely misinterpreting my statement. ;) Sorry ... what did you mean? ;-) > > A programmer should write programs that simply do their job without > > asking qusetions, and leave Psychology assignments to Psychology experts. > > > surprisingly (not really, at least to me), those psychology experts found, > that confirmation dialogs in sensitive places are really sensible. ;-) The Psychology experts who conducted those tests were looking for a Democratic solution. Unfortunately, people aren't all the same. What's "really sensible" for your average user is "a real drag" for a power user. One of the things I hate most about programs with an integrated GUI is the "Are you sure you want to overwrite this file?" prompts every time I want to clobber a file. Psychology experts may decide that those dialogs are the greatest thing since sliced bread, but not for me. I don't want my programs to decide that I don't know what I'm doing just because they're too narrowminded to know (or care) that I'm working on a versioned filesystem. I don't like programs that try to be smart. I like stupid programs that do exactly what they're told. I'm the expert, and I backup anything I care about. (That last part about backing up I learned the hard way. It's the reason I'm back on Mutt again.) > in less critical places, confirmation dialogs with a "do not ask again" > checkbox have proven useful. [OT] That's probably covered by some patent in the US :-( At any rate, there's nothing stopping your UI from doing that. Here's an obvious "user-friendly" sample for an rm(1) interface (assuming you already have a window program that fits in with your way of life): FILE=$1 ANS=$(window -opts='Yes|No' "Are you sure you'd like to delete '$FILE?'") if [ "$ANS" = 'Yes' ]; then rm "$FILE" window -opts='OK' "File deleted" else window -opts='OK' "Deletion cancelled" fi Another advantage of separating the UI from the program is that you can combine programs in an interesting way (much like the UI bash(1) already allows), say, to create an entire file management UI. Programs with hardcoded UIs don't play well with other programs they know nothing about. > undo functions (to which i account the trash bin) have also proven to be > very useful, because they don't disrupt the workflow and still even big > mistakes can be reverted. I love undo functions. If I never discover an error, it doesn't matter; if I discover the error someday, I can find and restore the pre-error state, and/or merge it with the current state, and/or any point in between. > however, this only works closed systems. Please explain. I'm stupid ;-) > and > is useless if you don't realize you made a mistake, That's only the case without multilevel undo. A versioning system is the correct solution to the problem, and it works without special support from programs. I get to keep my rm(1) binary, which does one thing and does it right, rather than being stuck with some bloated "file manager" application that doesn't even let me clobber a file without croaking at me first. > which is often > enough the case in security context. An undo button is extremely useful after a guy breaks into your system and trashes everything he can get his hands on. > > A programmer shouldn't have to be a security expert and a psychology > > expert, in addition to being an expert at whatever task he's actually > > hoping for his program to perform after all the prompts. > > > don't you think that the programmer is quite more likely a security > expert than the user? He might be. It makes no difference, though. If he happens to also be a security expert, he can do two jobs. However, that fact doesn't automatically merge the two jobs into one. > also, in every professional software development > environment which takes its users seriously, there is a psychology > expert (usually called usability expert ;). There you have a fantastic reason to KISS. No Psychology/usability/whatever expert is required in the design of the rm(1) program, nor in the design of the mv(1) program, nor the cat(1) program, etc. I've just shown you how to save a lot of money _and_ take your users seriously :-) > of course it is not their > task to take away the gun from the user, but pointing out to him that > pointing it at himself is no good idea is perfectly within scope. In the documentation, they can point out some easy ways to shoot yourself in the foot. The program shouldn't try to be smart and guess when the user is shooting himself in the foot. > > > dude, it is a config file that can be overridden, so such dogmatic > > > argumenation is completely pointless. > > > > As Robin Hood would put it, it's the principle of the matter, if nothing > > else. > > (We don't know if it's anything else, because once you start violating user > > rights, all bets are off. [...] > > > i give up. it's a lost case. Mwahaha ... I win! (Actually, I lose. At the end of the day, we both lose out, as does anybody else who happens to be reading our exchange.) The problem is that it's trivial to prove the possibility of a fair world if you start out with the assumption that everybody has full rights to his own stuff and no rights to other stuff, and that all stuff is owned by somebody. In the world of computers, that assumption is trivially true in virtually all cases. In other words, we have a formula that guarantees us a fair world. If you're not going to stick to that formula, though, all bets are off. - Dave
