On Apr 12, 2013, at 12:44 PM, eugene.krissi...@stfc.ac.uk wrote: > What, I'm afraid, people rarely realise these days, is that their desktops > are, essentially, GUIs to various OS features, so they obviously use GUI more > frequently than they think :) After all, this is all matter of habits and > training, and the reality is that people get more and more GUI-oriented these > days, like it or not. Whether to fight the reality or try to use it for > benefit is, certainly, every developer's own choice. I still remember payroll > officers saying that hand calculators (and even their predecessors) were much > more convenient and robust than modern software, but do not hear this for > some 15 years already ... > > Eugene
There is nothing intrinsically wrong with a GUI. The problem, for those who like to take advantage of automation, is that a GUI is a bottleneck if it can't be automated in some way. In my opinion, the best automation is based on an API (in my favorite scripting language, of course). The original unix tools were built with automation in mind, using pipes, redirects, and file I/O to control the flow of information. This automation wasn't designed because the architects couldn't conceive of a GUI, but because it was and is efficient. A utility can easily lock a user into a GUI. The usual cruel method is by spawning a dialog box the forces the user to acknowledge whatever triviality the program is trying to communicate (instead of sending the information to a log file where it belongs). If a program locks the user into a GUI, by whatever means, then the program can't be automated. And if it can't be automated it becomes a source of inefficiency. I think this is James Holton's point. Most of CCP4 can be automated by using the utilities from the command line, taking advantage of pipes, redirects, and file I/O as envisioned by the unix architects. CCP4 can also be run via a GUI, which I take advantage of in certain situations. It's a great model for user interaction. Long may it live (and may modal dialog boxes die a horrible and quick death). James > > On 12 Apr 2013, at 19:09, James Holton wrote: > > > I agree with Nat. There are good GUIs and bad GUIs, just like there are good > command-line programs and bad command-line programs. Bad programs are easy > to write and good ones are hard. Conservation of "work" I think. > > -James Holton > MAD Scientist > > On 4/12/2013 10:38 AM, Nat Echols wrote: > On Fri, Apr 12, 2013 at 10:27 AM, James Holton > <jmhol...@lbl.gov<mailto:jmhol...@lbl.gov>> wrote: > But, when it comes to GUIs, I have always found them counterproductive. In > my humble opinion, the purpose of computers and other machines is to DO work > for me, not create work for me, and I already have enough buttons to push > each day. > > This is a very defensible position with regards to your normal workflow (or > mine) - but beamline scientists (or software developers) are not very > representative of crystallographers as a group. I've seen a lot of reflexive > anti-GUI mentality from users who don't fall into either category, presumably > because a senior postdoc or PI told them "real crystallographers use the > command line", when in reality they'd be better served by figuring out on > their own what workflow is most efficient for them. > > -Nat > > > > -- > Scanned by iCritical. >
