command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: John-Paul Stewart on 8 Dec 2005 15:06 blmblm(a)myrealbox.com wrote: > > That's what I generally assume too, but I vaguely remember hearing > about a study Apple conducted many years ago that demonstrated that > people *think* a CLI is faster, but if you do actual measurements of > how long tasks take, it turns out the point and click is as fast or > faster. No, I don't (want to) believe it, but it could be true?? How complex were the commands being entered? Were the CLI users proficient typists? I can certainly understand how a point-and-click GUI is faster than hunt-and-peck typing on the CLI. But if you can type quickly (using proper technique or otherwise...as long as its fast), I would expect typing in a command to be a lot faster (especially since your hands don't have to leave the keyboard).
From: Tobias Brox on 8 Dec 2005 18:02 [Lee Sau Dan] > Show me your design, then. I don't require you to implement it. Just > show me the design, instead of claim that "there exists such a > design". That's what I get for involving myself in stupid discussions :-) Some disclaimers first: - I'm not a designer, and I have very poor skills in both design and human interfaces. I have implemented several systems allowing users to query databases through web interfaces, though those user interfaces have been ment only for internal use for employees and not something to be shown to external users. - When it comes to the implementation, the design below can as well be implemented in a curses application, a "TUI" - text user interface. - While I in general agree with Breuer that it should be possible to make a GUI, I'm not claiming that it will be easy to use in all possible cases. It is beeing said that an image can express thousands of words - but it is also true that sometimes some few words can express more than a thousand pictures. There will always be special cases where a short command will require lots of tedious work to enter into the GUI part. - While Breuer is correct that any boolean expression can be normalized, I think he is overlooking that it's actually possible to mix _actions_ into the boolean expressions given to find - and honestly, I also overlooked that. I think a boolean expression with side effects cannot be normalized. Particularly the "prune" action is not catered for in the interface below. - I must admit that I haven't spent much time thinking about the stuff below, there are probably things I have overlooked or problems I haven't foreseen. - My claim is only that, for somebody not using 'find' often, the user interface below in the very most cases will be easier to use than the manuals. Ok, load up a monospacefont if you don't already have one, and here we go: ----------------------------------------------------------------------------- | Base dir: ____ <browse> <add> | [actual command] | |---------------------------------------| find . -type f -size +60k ... | | [Global options] | | | {Follow Symlinks} {daystart} | <clear button> <execute-button>| | {max|mindepth}: ___ {mount} (...) |-----------------------------------| |---------------------------------------| [found files list] | | {tattr} {min|max|btw|eq} ___ {res} | | | Size: {min|max|btw|eq} ___ {b|k|M|G} | | | Type: m{type} | | | {name|path|iname ...}: ____ | | | (...) | | | empty: [X] nogroup: [X] | | | nouser: [X] | | | (...) | | | | | | | | | | | | | | | |-----------------------------------| | | [Action menu] <save search> | | | <save list> <execute command> | | <add restrictions> <clear> <search> | <clear list> <formatting options> | ----------------------------------------------------------------------------- [] indicates a comment or header, <...> indicates buttons, {...} indicates a select box / pulldown, m{...} indicates multiple-selection select boxes, [X] indicates a checkbox and ___ indicates a textbox. To use "and" above, one can either fill in several boxes, or use the 'add restrictions'-button. For some few attributes, it's possible to do "OR" by multiple selection boxes. Except for that, one can simply press the "search"-button several times to add the results from several queries. There should be negation checkboxes above, they are skipped for space reasons. I'll start from the top left: * Possibility to enter base dir. Defaults to '.' Possibility to add more base dirs by pressing "add dir". Possibility to browse for dir. Possibility to enter directories with wildcards. * Global options - section with the different options for symlinks (follow, never follow, follow those on command line, etc), maxdepth, mindepth, etc (most of those options can be used in a local scope when using command line, so here we clearly miss out something compared to the CLI) * Next, section of restrictions. First there are time restrictions, a select-box - {tattr} above - on which time we want to restrict on (access, status change, modified, etc), then a select box for choosing between "min", "max", "equals" and "between" - in the latter case, two text fields will appear. After the text field is a resolution selection box, minutes, hours, days, weeks and monthes. * Clicking the "add restrictions" will always cause the top right find command to be extended. Clicking "search" will (if needed) cause the find command to be extended, and then the command to be executed. * At the top right, [actual command], the actual command is displayed in a text box, and the user is free to edit it and execute it. Eventually, there has to be an area for displaying errors ... * Pressing "execute" or "search" would eventually add to the file list, but the program will be smart enough to keep out duplicates. * It's possible to manually delete and add items to the list * At last, there is the action menu - what to do with the list of files. They can be deleted, the format of the file listing can be changed, the list can be saved to file, the list can be cleared, etc. When pressing "save search", a single find expression is written to disk. I.e. if the user is fist building "find -size +6M" through the user interface, executes, and then exeuctes "find -type d", then the query "find -size +6M -o -type d" is saved to the file. -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: Tobias Brox on 8 Dec 2005 18:04 [Lee Sau Dan] > Peter> Chose A, C checkboxes. Click "again". Chose B, C > Peter> checkboxes. Click "finish" ("search", whatever). > So, you've done the conversion to CNF in your brain, haven't you? A user accustomized to such a tool will think in CNF, no conversion needed. -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: Peter T. Breuer on 8 Dec 2005 18:38 In comp.os.linux.misc Tobias Brox <tobias(a)stud.cs.uit.no> wrote: > - While Breuer is correct that any boolean expression can be > normalized, I think he is overlooking that it's actually possible > to mix _actions_ into the boolean expressions given to find - and > honestly, I also overlooked that. I think a boolean expression > with side effects cannot be normalized. Particularly the "prune" > action is not catered for in the interface below. That's true - but then it's an ill-thought out feature of find in the sense that the extra complexity allowed by embedding various execs at once in a search expression is not wanted. What they MEANT to do was apply an action at each of the selected subset of nodes and leaves in the file hierarchy. That's simply a final coup-de-grace on the end of the filter chain. > Ok, load up a monospacefont if you don't already have one, and here we > go: [loadsa work snipped! Wow!] Peter
From: blmblm on 9 Dec 2005 05:04
In article <87wtifv7l6.fsf(a)informatik.uni-freiburg.de>, Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "blmblm" == blmblm <blmblm(a)myrealbox.com> writes: > > blmblm> I claim that this is not as good an analogy as you think, > blmblm> especially for buying products for which no prescription > blmblm> is required: Some people do indeed remember the name of > blmblm> the drug, but others may remember "oh, it's that stuff I > blmblm> bought last time that worked so well, can't remember the > blmblm> name, but the box is pink with green letters .... " > >At least, you describe it, and then the shopkeeper follows your >(vague) instruction to fetch the drug for you, right? Isn't that CLI? >You may need a few iterations of trial-and-error or a selection from a >list of candidates before getting the drug you want, but so does the >interactive completion feature of bash (GNU readline). Well, that's if you ask the shopkeeper. I had in mind a scenario in which you're just browsing the shelves yourself (that's why I said "no prescription required" -- so you wouldn't need the help of a pharmacist or such). Not the best analogy overall, now that I think about it. > blmblm> Something similar applies to CLI/GUI. If you remember the > blmblm> command and the options, a CLI is often more efficient, > blmblm> but if you don't .... > >Still the CLI is faster. Type "less a*.txt<TAB>" in /bin/bash and the >completion would look for a filename that begins with "a" and ends >with ".txt" for you. You don't need to go through the other 100 files >that don't begin with a or don't end with ".txt". If there is only 1 >match, bash will type that filename for you -- however length it is, >and quote all the special characters (space, *, etc.) in the filename >for you. Ah yes, but this doesn't really help you find *commands*, does it? well, yes, if you remember the first few letters of the command, you can use command-name completion, but if you don't remember the first few letters? And as for options .... No, I think you have to read the man/info pages, or try running the command with "-h" or "--help" and hope it will tell you .... Sure, I know how to do a lot of this stuff, and I'd probably rather use "man" to track down the right CLI command than mess with a GUI, but I don't think it's actually more efficient, just a matter of preference. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor. |