command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: blmblm on 6 Dec 2005 04:51 In article <874q5mdai9.fsf(a)informatik.uni-freiburg.de>, Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "Jacob" == Jacob Sparre Andersen <sparre(a)nbi.dk> writes: > > Jacob> No matter what, the basic concept of a command line seems > Jacob> to be so foreign for many computer users, > >Is verbal communication that foreign? > >Have you never given written instructions to somebody else, so that he >can do something for you in your absence? > > > Jacob> that it might be necessary to camuflage it as a mouse-based > Jacob> interface. > >When I go to a drug store, I say the name of the drug I want to buy, >and in 10 seconds, the purchase is done. > >You go to a drug store. You open the draws and cupboards of the shop >one after the other, trying to look for some visible object which >looks like what you want. Spend 30 minutes there, still doing the >hunting. > > >Which "interface" to the drug store is more intuitive, efficient and >user-friendly? (Ignore the shopkeeper-friendliness for this >discussion.) I claim that this is not as good an analogy as you think, especially for buying products for which no prescription is required: Some people do indeed remember the name of the drug, but others may remember "oh, it's that stuff I bought last time that worked so well, can't remember the name, but the box is pink with green letters .... " Something similar applies to CLI/GUI. If you remember the command and the options, a CLI is often more efficient, but if you don't .... -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 6 Dec 2005 05:21 In article <7r4963-j4k.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc blmblm(a)myrealbox.com wrote: >> If I understand you right, you're proposing a GUI that allows you >> to build expressions in the canonical form. Right? > >Well, in a form that _covers_ the normal forms, yes. > >> But for complex search criteria, I question whether this will be >> more effective than the CLI, > >It's just the same - indeed it may help you factor your search into >a sequence of simpler filters. The interface can calculate the most >effective equivalent form. > > >> mathematically possible, I'm not sure it's something most people >> will be willing and able to do, even ones who are willing and >> able to think in terms of Boolean expressions. > >It's a "normal" way of organising ones thinking. The idea is that you >carve out in a first search roughly what you want, and pass it into >a second search that excludes some more things you didn't want, etc. >This is also an efficient way of going about things in general, since >the preselection cuts down on the number of later tests. You don't seem to have allowed for the possibility of making the search criteria *less* restrictive -- in an easy way. Let's try a concrete example .... If I want the equivalent of find . -name "*.bak" -mtime -1 -ls then with your GUI, I first check the "-name" box, type in "*.bak", then click "more", then check "-mtime", then select "<1", then "more" again, then "-ls". Right? Okay. Point and click and point and click versus having to remember command-line options, but that may be a YMMV, and the expressive power seems the same. Now suppose I want the equivalent of find . ( -name "*.bak" -mtime -1 -ls ) -o ( -name ".*rc" -print ) How do I do this with your GUI? I'm not saying it can't be done -- I'll buy that all Boolean expressions can be converted to CNF -- I just think it's less than obvious how to express the above in CNF, and as far as I can tell your GUI only supports expressions in CNF. [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 6 Dec 2005 05:30 In article <1rmf63-hrp.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >> Obviously, you never really worked with rewriting or simplifying >> Boolean expressions. Otherwise, you should know that DNF/CNF are >> usually less compact and less intuitive and more redundant than a more > >Sigh ... > >> deeply nested form. The normal forms are only good because they're >> only 2 levels deep (ignoring the depth of the "NOT" operator) and the > >They can be as long as you like, left to right. I prefer length to >depth > > A & B & C & D > >is four levels "long", for example. I don't know why you think deep and >complex is better than long and simple! We are aiming at a >comprehensible user interface! Clearly clarity is better. > And to add "or E" to the above .... If you need conjunctive normal form, you need ( A or E) & ( B or E) & ( C or E) & ( D or E ) rather than the briefer -- and in this case simpler -- ( A & B & C & D ) or E Right? If so .... As I understand it, your GUI represents A & B & C & D with four panels, one each for A, B, C, and D, and to add "or E", you need to point and click your way through these four panels, adding "or E" to each one. Right? For the expert user, this is more point-and-click effort. For the novice .... You think it will be obvious that this is how you add "or E" to the search? Maybe so, but I'm skeptical. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 6 Dec 2005 05:37 In article <cdld63-ubp.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc Jacob Sparre Andersen <sparre(a)nbi.dk> wrote: >> Peter T. Breuer wrote: > >>> Because it's NOT infinite. Boolean forms have a "normal form" to >>> which all may be reduced: > >> Do you really, honestly consider it user friendly to require the user >> to reduce his/her search criteria to their normal form before giving >> them to the program? > >Please don't draw up strawmen! I did not suggest reducing to normal form >- I merely noted that normal form is SUFFICIENT, and since I proposed a >method that covers normal form, THAT METHOD is therefore sufficient too. >You get to judge whether you like the form I proposed on its own merits >or demerits - I suggested a GUI to tick the boxes in for each one of >the atomic propositions (i.e. one window, with boxes to tick in it), >and a check box asking "finished?". Well, you seem to me to be proposing a GUI that only allows entering expressions in conjunctive normal form. How do you propose that users enter expressions that are not in CNF? If your answer is "all expressions can be converted to CNF" .... Who/what is doing the converting? If it's the GUI -- how? If it's the user -- how is this *not* requiring the user to reduce his/her criteria to CNF? >Why is $orld full of people who cannot argue properly? -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Peter T. Breuer on 6 Dec 2005 06:28
In comp.os.linux.misc blmblm(a)myrealbox.com wrote: > In article <1rmf63-hrp.ln1(a)news.it.uc3m.es>, > And to add "or E" to the above .... If you need conjunctive normal > form, you need > ( A or E) & ( B or E) & ( C or E) & ( D or E ) > rather than the briefer -- and in this case simpler -- > ( A & B & C & D ) or E > Right? That's an interesting one - yes, that's part of a real and useful discussion of the format I proposed and would lead to one accepting or modifying it. To argue FOR, I'd say that all you need to do is click "again" three times. The first time you unclick "A" and click "B", the second time you unclick "B" and click "C", the third time you unclick "C" and click "D". > As I understand it, your GUI represents A & B & C & D with four > panels, Panels? checkboxes. One panel for all. > one each for A, B, C, and D, and to add "or E", you need to > point and click your way through these four panels, adding "or E" to > each one. Right? Wrong. See above. Peter |