Date: Fri, 12 Nov 2010 19:49:51 +0100 From: Polytropon <freebsd@edvax.de> To: Chad Perrin <perrin@apotheon.com> Cc: freebsd-questions@freebsd.org Subject: Re: Tips for installing windows and freeBSD both.. anyone?? Message-ID: <20101112194951.5d56b86a.freebsd@edvax.de> In-Reply-To: <20101112011934.GC35128@guilt.hydra> References: <201011100009.oAA09mfG024502@mail.r-bonomi.com> <AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6@mail.gmail.com> <20101112011934.GC35128@guilt.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Nov 2010 18:19:34 -0700, Chad Perrin <perrin@apotheon.com> wrote: > In fact, a set of CLI filters linked together by the Unix > pipeline (or even a DOS pipeline, at least in theory) is essentially > infinitely extensible to provide surprising levels of automation > customizability that might astonish the earlier creators of some of the > older tools being used, while an extension system for a GUI application > necessarily has to predefine what is possible, and obfuscates the inner > workings of the extended application behind designs that are largely > opaque to the user. >From computer science, please see the term "fully programmable". > > 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. > > . . . and it is shortly after that point that things get very specific, > and non-general. True - and non-functional sometimes. I may give an example: The File > Open... dialog in Gtk 2 has functional limitations (example here: attach a file in Sylpheed). It doesn't respond to keyboard opreations (except entering a file name, but [tab] to the next dialog element does not work). It *FORCES* the user to use the mouse if he wants to select something from the list. In the list, there is a HELPing element: typing the beginning of a file name moves the cursor to that file. Good idea, but bad in reality, because it doesn't work - as it mixes case: typing "abc" brings you to "ABC" in the list, except YOU want "abc" further down. Option: Again using the mouse. Using shell patterns, e. g. typing "*mp3" to have the list field just contain the MP3 files does not work - the dialog simply disappears. The same if you enter a directory manually, e. g. /export/share/mp3 - dialog disappears. If you add a / at the end, MAYBE it moves to the specified directory, but shows every file TWICE. And keep in mind what I said about limitations in using the copy buffer in an earlier message. THOSE (!!!) are the limitations of GUI - good ideas that got implemented that POORly that the final product is gettimg more and more unusable. Coming back to your statement: Of course every toolkit does the File > Open... dialog differently. That is noting bad per se, as the "advocates of GUI consistency" get more and more inconsistency in their own main domain of what they use. Consistency is not a problem. The problem is RECOGNITION. If the graphical representation of an object or an action cannot be recognized as what it IS, correct what it REFERS TO, all the design is completely useless. Today's approach is to waste screen space and overcomplicate things. Icon bars all over the place. Is that user-friendly? I don't think so. "Limited to the maximum" could be a good approach instead. Allow me to mention GeoWorks Ensemble, a GEOS office suite for the DOS-based PC. It is a GUI that is based on the Motif toolkit (that could to things in the early 90s that "Windows" cannot even do today, like *real* drag & drop, or detachable menus, NATIVELY). This system allowed the user to change the complexity of the GUI. There were 3 (?) levels: beginner, intermediate, expert. On beginner level, only basic functionalitites were exposed to the user. On expert level, all functionality was present. This concept assisted the learning courve development of the user BY USE of the graphical elements. > Actually, my understanding was that the problem was someone refused to > type a simple command, and would rather make a series of seven clicks > thirty times while babysitting the application, and had no conception of > the benefits of letting more than one person work in parallel on a given > task. Extend this idea: If a friend asks me: "Erm, I've got a bunch of JPEG images from my camera, but I need to convert them to PNG; those are 10,000 images. How can I do that?" I write him a mail: "Type this in a terminal: cd /where/your/files/are and then type: for f in *.jpg; do convert $f $f.png; done. That's all." If I wanted to assist him "the GUI way", I would stop using a language (the shell's command language in this case) and would need to draw him pictures - or describe them: "First you click on the blue square, this is either on the left of your desktop, upper region, or it is on the right. Then there will be a grey window and a blue window. On top of the grey window, click the yellow ball. When the ball is jumping into the blue window, a dancing elephant appears. Click on that." :-) You know what I mean: I have no idea how to convert a bunch of JPEG files to PNG per GUI. :-) > It wasn't the file format that changed; it was someone's tolerance > for using a keyboard instead of a mouse. The preference of tools used also depends HEAVILY on the task. For entering continuous data (e. g. for a tax software, for a document generation system, for a listing program), the keyboard is #1. There just is no way around it, and professionals (!) will KNOW that it is done that way. For many games, a combination of mouse and keyboard is used. Mouse-only operations are often used in graphics manipulation software or video editing. I would NOT claim that just because this concepts fit in THIS use, it fits in ALL uses. > This is the kind of thinking > that leads to the Mac defaulting to a mouse with only one button. And it worked, too. UNIX (X) defaults to a mouse with three buttons, because it can stand on them in a stable manner. :-) > That was not evident in the explanation of what happened. The > explanation suggested nothing about the batch file in question being > difficult to use (or "figure out"). From the sound of it, three > instructions on a 3x5 card would have sufficed to ensure everybody knew > what to do, except in the case of people who do not know how to operate a > keyboard. The primary REFUSE to use the keyboard because the mouse EXISTS prevents lazy users even from READING that 3x5 card. They are often not WILLING to follow instructions, no matter how simple (or even idiotic, sorry) they may be. In worst case, they expect YOU to come over and DO THEIR WORK. This leads to the misbelief that things which AREN'T easy "are easy" - because someone else does them. :-) > I think that GUIs are quite valuable when used where appropriate. I > think that the rest of the time, people greatly exaggerate the value of > the GUI, to the extent that they begin to think the CLI (as well as TUIs > in general) has no value at all. That's my observation, too. Everything that involves using the keyboard is called "DOS". :-) You can still see that, when it comes to REAL work, text mode things that look "old-fashioned" are still in use. An example is today's use of 3270 text mode applications (80x25 chars, some colors, all text) for programmers who work on a tax and payment system on the mainframe. NONE of them would be able to do that in GUI. I've spoken with such programmers, and they told me what they REALLY hate is that their boss requires them to load the results into some "Word" or "Excel" and manually (!) format all the stuff (instead of just writing an output program that creates PDF files by some means). They told me that this "after-work" consumes more time than the programming itself. > I used to be one of those idiots, and > there was a time when I would have been on your side of this little > debate. That was almost fifteen years ago. Times change, and I grow in > knowledge and experience. Let me emphasize your last sentence: Times change, and I grow in knowledge and experience. You do. Most "average users" don't, as they don't evolve. Those who resist learning will always be left with what others provide to them - even if that is the worst crap imaginable, and they would still believe that they are "doing it professionally". At the point where productivity transforms into money earned or lost, priorities change. The dancing elephant that has been interesting in the past is uninteresting now, as it costs amount X of $ per hour. > Obviously, many tasks related to visually oriented work like image > editing are excepted from this. Such tasks are a minority, however, > where non-casual use is concerned. Web browsing IS a majority, for example. A well-designed web browser could benefit both the average and the professional user. Let's say this "ideal browser" requires a bit of learning, maybe some reading. The professional will do that, and he will master this new program and productively use it. The average user will refuse to read in the first place, and resist to use "something different". There's a big aversion against anything that is "not like mine". The more average users are confronted with CLI, thinking and learning AT WORK, they seem to be more interested to get this experience in a home context. They learn something new at work because they are FORCED TO (as their employer needs them to learn the new XYZ program). This gives them the idea: "Oh, the keyboard operations are not that bad, I can much faster find my files, and those reqular expressions are a bit complicated, but I see they can be really useful! And writing my own commands to perform actions A, B and C, and D if needed, are great. At home, I don't have this." Average users tend to want to have "the same pictures at home as they know them from work" (the word "picture" refers to the GUI look & feel, obivously). This is the main reason they get pirated copies of expensive software just because their office also has that (maybe also an illegal installation, but nobody knows). The more average users become aware of ALTERNATIVES, the less they resist to learn something new. I've seen many friends being UNHAPPY with how things are forced upon them, and they asked for alternatives, which I could show them. Of course, at first sight, it looks like Magic, then it looks like Voodoo, after that like hard work, and finally like knowledge and experience. That's what I always tell them: I couldn't do that Magic from the beginning, I had to invest time and exercise - that's why I'm so very expensive :-) - in order to master those tools. But ***YOU*** are free to learn those tools, too. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101112194951.5d56b86a.freebsd>