Quoth Rob Farmer on Tuesday, 09 November 2010: > On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bon...@mail.r-bonomi.com> wrote: > > A GUI provids a _fixed_ set of predefined operations that it is possible to > > perform. > > > > IF your needs are met =entirely= by the provided operations, great. If not, > > you're dead in the water, without any way to accomplish the task. > > How is this different from the command line? If I have a set of data > and want to sort it in a way that "sort" doesn't have an argument for, > I'm just as dead in the water as with the GUI. In fact, with the GUI I > am probably better off because I can see that this is not supported > within the program, without having to use the documentation.
I don't know how anyone who has done much automation could say such a thing. Command lines and pipes offer an exponentially greater set of possibilities than could ever be presented in a GUI. I don't know about others, but I spent many years being pro-GUI. I led the charge for getting software companies to port their applications to Windows and use IDEs for development. It is only recently that I have come to my senses. I should have known better. Back in the 80s when I worked on tax preparation software, the marketing department wanted a more demoable UI. So we put a ton of time into creating an interface that looked like the IRS forms, instead of the one we had where the user keyed in a code that indicated what line on what form they wanted to input, followed by the input itself. When we released this, the marketing department loved it, our customers' higher-ups thought it was nice, but the actual input operators hated it. They were evaluated on how much data they could enter, not on their enjoyment of the task. > > > > > GUIs are great for the casual user, because they provide a consistent > > 'look&feel' > > acrross the spectrum of apps available under them, and, _generally_ what you > > learn from using one application 'generalizes' to any other app that runs > > under > > the same GUI. > > > > OTOH, a GUI is the worst thing in the world for 'production' use. It > > absolutely > > _kills_ productivity for production tasks. Automation for productivity > > _REQUIRES_ > > a complete/comprehensive command language. > > > > With a command language, you can 'automate' a series of operations by simply > > listing the commands in a file, and feeding that file to the > > command-processor > > input. > > > > With a GUI there is no way to describe the series of mouse > > 'motions'/'clicks'/ > > 'double-clicks'/'drags' and keypresses required to perform an operation. > > 'screen coordinates' are meaningless when a window, or icon, or button, may > > be > > 'repositioned' at will. > > > > An _individual_ application may allow scripting via an internal command > > language, > > but since it is internal to the app, and *not* part of the GUI, it doesn't > > 'generalize' (no guarantee that similar capability is present in any other > > app) > > *AND* is utterly worthless for 'automating' annything that involves more > > than > > the single app. > > The CLI doesn't generalize either. How many ways are there to get > input into a program? > > Some can open files on their own and the file is listed as an argument > (app input) > Some have a flag for input, which of course isn't consistent (app -in input) > Some have multiple flags for input, but which ones work depends on the > platform/implementation (such as GNU long flags) > Some need it provided to stdin > Some can process multiple types of input and are smart enough to > figure it out on their own while others need to be told what format > they are being given > Some can do multiple unrelated things in one instance (file a b) while > others can't (date +"%H" +"%M") > Some have historic idiosyncrasies, such as tar defaulting to a tape drive > Some have other strangeness, like java using aaa.class as input but > wanting you to list it without the .class extension, whilst javac > needs the .java extension > Some are just unusual for no obvious reason, like dd's xx=yy thing > etc. > > On the other hand, 99% of GUI apps that handle files have a File > > Open dialog that is provided via a toolkit and works the same > everywhere. > > > > > Years ago, I worked at a place that, among other things, produced a > > reference > > manual of statistical data for our cusotmers. About 800 pages of tabular > > data, > > practically all of it updated on a staggered, monthly basis. In the 'early' > > days (MS-DOS vintage, before 'windows'), each table was kept in a separate > > spreadsheet, which _did_ require the redundant entry of a _small_ amount of > > the data. OTOH two (or more) differnt people could be updatdin different > > paes > > simultaneously, regardless of whether or not they were 'related'. And, at > > the end of the week, when it was time to send out the weeks 'updates' to the > > customers, we had a simple little '.BAT file, each line of which; (a) > > invoked > > the spreadsheet (b) specified the spreadsheet file to use, and (c) invoked > > a 'start-up macro' that printed the contents of the spreadseet, and exited > > the program. Thus, on 'publication' day it was just type in the name of the > > '.BAT file and everthing got printed. It took an hour or two -- of > > _machine_time_ > > that is, but _zero_ human intervention. > > > > Fast forward a few years, a new-hire analyist (in a senior capacity) felt > > humiliated at having to use this 'old' technology (they had Windows at his > > prior employer), and made a big enough stink about it that the shop upgraded > > to Windows just to keep him happy. He proceeds to bundle all 'his' > > spreadsheets > > into a single workbook, so that only one person can be working on any of > > them > > at any given time, and, on 'publication day', somebody had to sit there and > > click on each relevant/changed sheet in the workbook, click on' file', > > click > > on print, select the page to print, and click 'doit'. What a *wonderful* > > productivity increase!! We've now got a system that requires a -human- to > > play babysitttr the machine. For a couple of -hours- every week. all to > > save > > the complainer from having to enter a few numbers redundantly. > > This isn't really a GUI problem, because the issue is the file format > changing such that your .bat no longer worked. If you retained the > original format or fixed the script, it would still work fine. > > However, it still points out one of the biggest problems with the CLI > - there is a barrier to entry in knowing what commands to run with > what arguments to make everything work the way you want. File > Print > was easy for your office staff to figure out. The CLI equivalent > apparently wasn't. Perhaps a barrier to entry is a good thing for those who don't know what they're doing. > > I think many here are underestimating the value of GUIs, because they > have been running many of these traditional UNIX commands for years > (or decades) and are also technically oriented enough that learning > them in the first place wasn't a big deal. > > -- > Rob Farmer > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Sterling (Chip) Camden | sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips.com
pgplm9MgbU0up.pgp
Description: PGP signature
