Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Mar 2002 13:11:48 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Chip Morton <tech_info@threespace.com>
Cc:        FreeBSD Chat <chat@freebsd.org>
Subject:   Re: Free BSD
Message-ID:  <3C93B514.9AB4BB7E@mindspring.com>
References:  <4.3.2.7.2.20020315181331.01b26160@threespace.com> <20020314204235.L152-100000@pogo.caustic.org> <15505.28725.937368.158235@guru.mired.org> <20020314204235.L152-100000@pogo.caustic.org> <4.3.2.7.2.20020315181331.01b26160@threespace.com> <4.3.2.7.2.20020315190230.01b2a4f8@threespace.com> <4.3.2.7.2.20020316100234.01b21638@threespace.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Chip Morton wrote:
[ Jef Raskin ]
> Oh I read the article, all right.  And I disagree with most of it.  And the
> only thing that I've "suggested" here is that he ante up and actually
> *implement* some of his ideas.  I really take issue with his blanket
> assertion that (paraphrasing here) "All windowing systems/GUIs are screwed
> up, and I could do it so much better--but I won't."

First of all, he specifically asked for programmers to contact
him, as part of the article, so the "but I won't" doesn't hold
water.

Second, his design philosophy is that you build the interface,
and the build the underlying system to support it.  In this
philosophy, it's impossible to glue a UI on an existing system
and meet the design goal, unless you design the UI, and then
go looking for a system that matches it and can be forced into
supporting it, and/or build a new system from scratch.


> And let's be real here about the rest of your/Raskin's points.  All
> windowing systems with significant market share operate under a de facto
> standard.  Regardless of whether you think that standard is the best or
> not, most people use WMs that are functionally very similar.  And switching
> from one to the other doesn't require a degree in astrophysics to figure out.

He specifically stated that the learning curve was not
the porblem, it was the fact that the differences were
in your face to the point that they required conscious
acknowledgement in the decision making process.

The point of interfaces is to abstract complexity, so that
you can concentrate on tasks.  Any time you concentrate on
the interface itself, you detract from the attention that
can be committed to the task.

A good analogy here is the leaky vs. non-leak boat.  If I
am in a boat, and am there for the task of transportation,
I concentrate on getting from point A to point B.  On the
other hand, if the boat has a slow leak, I am distracted
from the task for which the boat was designed -- getting
from one place to another -- and caught up with burning at
least some of my time bailing water, rather than the task
for which I'm using a boat in the first place.


> Now if Raskin wants to change that de facto standard, he's essentially
> going *against* the standardization that he argues for.  The
> standardization of the interface is essentially done.  Let's leave it be
> and move on to bigger issues.

I guess this means you run Fvwm95, and every place it does
not match the standard of Windows, you chip away at it
until it more closely resembles Windows.

Or this is your strawman argument, to argue against the
merits of standardization, by implying that a bad standard
is worse than no standard.

The answer is that this is not true.  A bad standard is in
fact better than no standard.

A standard, no matter how poor, means that I can save the
training costs for a new employee, or that it's possible
to hire a temporary worker, and have them be productive
within the window of temporary need.

I think Jef is arguing for good standards, more than poor
standards, but primarily for standards over none.


> I read an article in which an engineer at one of the major American car
> manufacturers said that response time could be improved by placing
> braking/acceleration controls on the steering wheel.  He argued that the
> time required for the driver to move his feet was significant in decisions
> requiring split-second responses.  But you know how many car makers were
> interested in adopting his idea?  Zero!  Because nobody wants to relearn
> how to use his hands rather than his feet to drive the car.  I sure
> wouldn't rent/buy one.

THere are a couple of assumptions implicit in this example:

1)	The engineer was right, not wrong
2)	That improved response time is desirable
3)	That it's impossible to implement dual controls
4)	That the base cause was an unwillingness for people
	to relearn things

#1 is an urban legend, without references

#2 is arguable, from a safety standpoint (one has to wonder
   how many people go to step on peddles, only to reconsider
   before actually doing so, or how many accidents are caused
   because the car in front has anti-lock brakes, and the car
   behind has ordinary brakes)

#3 is both an economic and a human factors issue; the cost of
   dual controls is going to be higher, but perhaps not very
   much so, if the controls are electronic, since a fly-by-wire
   system doesn't really care where the inputs to the wire are
   from, so floor and wheel controls become the cost of the
   switch components themselves.

#4 could be completely wrong.  It could be that humans are
   just hard-wired incorrectly to be able to deal with the
   controls on the whel.  We don't know *what* process was
   behind the decision... assuming there even was one, and
   we aren't talking urban legend, here.


> The point is that once the population at large has settled on a particular
> method--whether through conscious decision-making or lack thereof--getting
> them all to switch to another method, even a better one, is damn near
> impossible.  Believe me that if the music industry hadn't shoved CDs down
> our collective throats, some of us would still be listening to cassette
> tapes or 8-tracks.

I guess that explains why most of the world, besides the US,
hasn't been able to switch to MKS units?  Or why the Euro
never happened?  There are tons of counter examples.

Frankly, the idea that a switch can't occur is wrong in so
many ways, it's hard to pick only a few of them to list.


> The actual look of a window manager (or car, or woman, or anything else)
> only matters very early up front.  You may be wowed by the look of the
> windows and widgets early on, but after that it really doesn't matter to
> you while you're working.  Sure, I don't like the look of twm, but I would
> be no more/less productive by using it.  In fact, I might argue that the
> pleasure I get out of having an attractive, colorful windowing system with
> my girlfriend on the wallpaper would actually make me more productive on
> the whole.  Productivity isn't just about the milliseconds saved in
> dragging the mouse from one corner to the next.

For large purchase decisions unlikely to be repeated, it's a
motivating factor, and it's an important part of the consideration
in deciding on "the whole package".  If it weren't, people would
not pay to run advertising.

Your argument about your wallpaper is incorrect, since we
are not talking about machines limited to a single user,
we are talking about transportation of productive skills
between machines.  This could be hindered for you by the
lack of the background you are used to seeing during your
operation of a machine.  Or it could be hindered by the
presence of the picture of your girlfriend creating a
hostile work environment for someone else who is looking
over your shoulder in order to collaborate with you in a
particular problem.

It's a matter of perspective: "one man's mead is another
man's poison".

You seem upset that someone else might be able to dictate
your UI.  The answer is that it's not dictation, it's a
consensus.  The government you live under right now is
consensual; not everyone can install the "society manager"
of their choice, or an entirely different "society system",
if the current one doesn't suit them.  Basically, you are
arguing that anarchy pleases you.  8-).


> I really think that the shortcomings in Raskin's arguments become apparent
> when he mentions the ridiculous prospect of using a wallpaper that looks
> like open windows.  Who the hell would do something that stupid?  Besides
> him, I guess.

Someone who likes to screw with people would do it.  Someone
who doesn't want someone else to be able to casually look at
their screen and see what's really going on there.  Someone
with poor taste in backgrounds.  Someone who doesn't have a
copy of that picture of your girlfriend.  THere are a lot of
bad background choices; the argument is called a "reductio ad
absurdum".

> Because frankly, I think that he deserved to get his ass
> beat for changing somebody's color scheme to red on red and forcing them to
> have to reinstall it.  If that's his best argument for why we don't need
> color in the GUI, then I rest my case.

No, that was also a reductio ad absurdum argument.

Consider a public library computer.  What harm is it, if
someone sets the color scheme to read and green during
the Christmas season?  None, I guess, unless you happen
to be red-green color blind.

The red-on-red example, though, is more of an example of
a customizable interface that permits stupid choices, as
well as permitting good ones.  It's pretty obvious that
it should not have permitted indiscernable choices for
colors that are required to be contrasting for the UI to
be usable.

Even if you agree with none of his other premises, you have
to agree that an interface that permits converting the
product from its intended use to a doorstop is a poorly
designed interface.


> Like I said, he can develop his 1-bit WM and then he can have it.

It's not about monochrome.  Just because he designed the
most critically acclaimed user interface of all time on
a machine incapable of displaying color, doesn't mean
that he would have limited himself to monochrome, had the
choice been available.  In fact, we see that he didn't;
when the first color macintosh came out, the background
was blue.

In any case, developing a new window manager would not serve
to solve the problem he's pointing at, any more than denying
the existance of the problem solves it.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C93B514.9AB4BB7E>