* Marc Chamberlin
[02-10-11 14:01]: And he decides to bring up the map file using Xemacs, and damned if there weren't some non-printing characters embedded in that file. Dunno how they got there, and kwrite was not showing them to me... Sigh... Removed em and all started working as expected... Hint, kwrite is not a :text-editor". Then what is it? It presents a text file to a user to manipulate. It apparently has a fault in that it does not display non-printing characters. Why am I, as a user, to be belittled for having chosen what appeared to be an easy to use tool to edit the configuration files? Graphics/GUI is *not* always better (er, ever). I NEVER claimed GUIs based tools are inheritantly better than command
On 2/10/2011 12:26 PM, Patrick Shanahan wrote: line tools, both can be badly designed. What I did say is that GUI's have a far better POTENTIAL to teach and guide a user in a tools usage, and make it easy for them to reach a satisfactory solution. Non-interactive command lines with external documentation has repeatedly been shown over and over, again and again, to be a failed approach when it comes to teaching/guidance. GUIs offer a far richer medium, using pictures, diagrams, built in layers of organization, can present models via easy to understand graphical concepts, automate much of the underlying difficult parts, make transparent the connections between different subsystems etc. Another advantage of GUI driven software is that the presentation layer/documentation often stays in better sync with the underlying tools capabilities, it HAS to in order to work. Yes, many GUIs are poorly design and only present a subset of a tools capabilities, but that is not the fault of the GUI approach per say, that is the fault of the designer. What Anton, and many Linux zealots fail to understand, is that half the battle of designing a well design tool(s) is that it is the job of the designers and programmers to make it easy for newcomers to learn how to use it also, intuitive if possible, and how to integrate said tool into their processes/needs to solve a particular problem. Stay with your command lines exclusively if you like, along with your external difficult to understand, unorganized documentation. The rest of the world will choose the easiest tools that guide and help them to learn, and I, as a programmer myself, will continue to be a champion for them. Why do you think GUI based tools such as Turbotax and H&R Block are so damn successful in helping people file their taxes? They are GUIDES! Try doing that with your command lines and external documentation and see how successful you will be. The current NFS system FAILED me, and many many others because of it's lack of guidance, organization, and usage of overwhelming large amounts of difficult to understand documentation. Yes the answers may be in that heap somewhere, but I am tired of having to sift through so much documentation, parse and understand the obtuse semantics used, just to find some little gem of information buried on some document page somewhere. And I am really sick and tired of callous answer such as RTFM. The moment someone says that, I KNOW I am dealing with badly designed/written software. Implementing features is one thing, designing for usability is quite another. Until you learn the difference, and understand that there are multiple levels of target audiences competency levels, please stay out of software design and development. People who do not understand this, and are writing programs, are making a mess out of computers and ruining them. I got no problems with experts who want to use concise command lines to quickly accomplish some task, but I got one hell of a problem with those same experts who want to force newcomers into HAVING to quickly learn so much background/underlying information/concepts necessary, in order to accomplish the same task, because the only means available is via those same concise command lines. That is building a needless barrier against entry into the world of Linux. Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org