Tips for installing windows and freeBSD both.. anyone??

[Polytropon]

On Thu, 11 Nov 2010 18:19:34 -0700, Chad Perrin <perrin at 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, ...