command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Shmuel (Seymour J.) Metz on 10 Dec 2005 19:00 In <3vqg0nF172etdU1(a)individual.net>, on 12/08/2005 at 10:25 AM, blmblm(a)myrealbox.com said: >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?? It is well understood how to determine the results of a survey by careful selection of the questions. I can easily prove that a CLI is more efficient, and I can equally easily prove that a GUI is more efficient. The tasks that I test the users against will be determined by which answer I want. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap(a)library.lspace.org
From: Shmuel (Seymour J.) Metz on 10 Dec 2005 19:06 In <3vqnjvF17cqm3U1(a)individual.net>, on 12/08/2005 at 12:35 PM, blmblm(a)myrealbox.com said: >Can you think of a reason why mail sent using the above instructions >would bounce, with the following error messages (actual e-mail >address edited)? At one time patriot.net was giving the wrong error code for messages rejected due to their source, but I thought that they had fixed that. Check that you included the plus sign and that your software didn't strip it out. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap(a)library.lspace.org
From: Shmuel (Seymour J.) Metz on 10 Dec 2005 18:51 In <3vod1cF16u73aU2(a)individual.net>, on 12/07/2005 at 03:22 PM, blmblm(a)myrealbox.com said: >If you remember the menu structure, *and* either the GUI supports >keyboard shortcuts (which you also remember) or you're faster with >the mouse than with the keyboard. No? Well, yes, but the point was that the menu structure of a GUI can be as difficult as, or even more difficult than, the syntax of a CLI. The devil is in the details, and saying that a UI is CLI or is GUI does *not* say how easy it is to learn or to use. Either style can be more efficient in specific cases, and either style requires that you memorize things in order to be efficient. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap(a)library.lspace.org
From: Tobias Brox on 10 Dec 2005 23:39 [Lee Sau Dan] > Tobias> - My claim is only that, for somebody not using 'find' > Tobias> often, the user interface below in the very most cases > Tobias> will be easier to use than the manuals. > So, the GUI isn't complete. Well, pretty much - except for the prune action, I cannot see anything that is impossible through my suggested interface. It is not impossible to include the prune-action ... just let the user do one extra prune-search. I'm also constantly claiming that the big disadvantage with GUIs is that at once one attempts to do something that was entirely not on the developers mind it will probably either not be doable at all, or doable only with lots of tedious work. When trying to point this out, one is often unable to make good examples of what you actually would like to do that is not possible, but the "nobody would ever need to do that"-argument is simply not valid. Sooner or later, some new, _real_ use case will appear out from the blue and it will be a cant-do-that-thing. That's also one of the reasons why I detest comercial, closed-source code. Sooner or later, one would probably need to hack around in the source anyway. > Wow! That screen already looks so crowded that it would deter casual > end-users. "OneButton" and "OneTouch" are marketing buzzwords today, things should be as simple as possible for the end user. Certainly, a design minimizing "clutter" allowing only some few buttons would not be useful for anything except the most common daily tasks. As said, I'm not a designer, before releasing such a product (maybe even before starting to implement it), somebody more competent than me should go through to make it look and feel more convenient. > Go on and add more features. I think this one is pretty much feature-complete; I can't think of anything except the prune-stuff that cannot be done. Anyway, one do have the full power of the cli since the command is not hidden for the user, but rather the opposite, the user can edit the command directly if he is not satisfied with fickling with the buttons. Even for a power user that actually would use this feature, this UI will be easier/faster than to search through the manuals for the right options. Another thing, when doing things non-interactively, say, find . (...) -exec rm '{}' ';' (hm, actually find supports -delete - didn't know that) it is much easier to do mistakes than when first doing a find without side effects and then seeing the list and then removing the files. > You'll end up in a mess inevitably. > 'find' can do complicated things. You can't pretend that it is simple > without hiding the complexities. My main claim is that for a user not familiar with find, using this interface would be easier than reading the manual - nothing else - and I stand by that. > Tobias> I'll start from the top left: > Tobias> * Possibility to enter base dir. Defaults to '.' > Tobias> Possibility to add more base dirs by pressing "add dir". > That's so inconvenient. In CLI, I simply type in al the search > directories, separated by space. No need to do the extra pressing of > the "add dir" button. What I find inconvenient is the error message: find: paths must precede expression since most command line utilities are the other way around. But anyway, minor detail. I never claimed the GUI would be faster to use then the CLI - and the beuty of this interface is that one actually still have the power of the command line since the command will appear in an editable text field. For anyone beeing familiar with find, probably the user interface would not be much useful, but if nothing else the proposed user interface is a nice way of learning to use find. > Tobias> * Pressing "execute" or "search" would eventually add to > Tobias> the file list, but the program will be smart enough to > Tobias> keep out duplicates. > Hence reinventing "|sort -u"? I'm asserting that it's possible to implement this, but I'm not going to prove it. Sorting/unique-test is trivial using a high-level programming language or apropriate libraries. Sort buttons on the file list would be a nice thing, and for the most fields and most people easier than to use the sort command. Actually, I think that there is no way to use 'sort' for sorting on the nth field in the space-aligned output one gets from "find -ls". > No "load search" feature to do the opposite of the "save search"? Probably that would be an idea. However, the saved search can be executed directly from the command line :) -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: Alan Connor on 11 Dec 2005 06:48
On comp.os.linux.misc, in <439b6c17$2$fuzhry+tra$mr2ice(a)news.patriot.net>, "Shmuel (Seymour J.) Metz" wrote: <body not downloaded> I see that you've altered your From header in order to evade people's killfiles. Didn't work here. Alan -- URLs of possible interest in my headers. ~ ~ |