Re: Apologies to gnome-gui if I ever said you guys were flamers...

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: Tom Vogt <tom@lemuria.org>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 19, 1998 1:59 PM
Subject: Re: Apologies to gnome-gui if I ever said you guys were flamers...


>Dan Effugas Kaminsky <effugas@best.com> wrote:
>> >it would have been YOUR job to find out how screenplays can be done,
>>
>> So, I shouldn't design, I should code.
>
>could you please abstain from playing dumb? I'm not know for liking that
>very much.


Well, if you take it totally out of context, yes, that sounds quite dumb.

The next line was "and the original programmer shouldn't design, he should
code too."  or something to that effect.

I am actually asking where the design phase comes in, Tom.
>
>
>> No, unconcerned.  My way of looking at it is that it's never been done
>> right, it's never been integrated universally with an operating system,
it's
>> never been part of the help paradigm, essentially, I was *designing a
better
>> helpsystem* and Xlab came along and showed that the design structure I
was
>> defining wasn't all that impossible.  Am I supposed to look at this like
a
>> bad thing?
>
>yes, you are. it's showing clearly that all you had was a nifty idea and
>that you didn't care to do the basic research one could have expected from
>someone who demands webspace and people to listen.


The webspace was because I thought the proposals already on the gnome home
page were being hosted there.  I was peeved that I wasn't even getting a
response for *linking* from that index of proposals.

You state that I should keep my proposals secret until such time as I have
done x amount of research.  I am confused here, because I thought secrecy
hurt projects such as this.  Regarding screenplays, I went into detail into
why such a philosophy would be a good thing(tech support, collaborative
apps, etc.) instead of going into detail about its possibility.  Knowing
that X is a client/server protocol unlike GDI/Win32, it has to be recordable
by nature, and in a pre-bitmap phase no less.  So I didn't worry that much
about implementation.  I thought more blueskyish.

I dunno, Tom.  Seems like people reacted pretty well to the idea, once I
trashed the admittedly silly requirement for voice accompanyment.  Did I
misunderstand?

>
>> Tom, I devote something like three paragraphs to this, exactly.  I
provide
>> references.  I describe old systems.  My word, I didn't stay holed up in
my
>> room researching and typing.  What happened to all that starry eyed
>> idealism, that style guides shouldn't be held up waiting for perfection,
>> that they should be open to the public?  I agreed with you here, is this
my
>> reward?  Being burned by the person who taught me?
>
>geez, I'm not teaching anyone, my ambitions in that direction faded several
>years ago.
>but my opinion on this is that all that idealism isn't worth a dime if it's
>not supported by down-to-earth research.


Well, I researched, and didn't find out everything.  So I received email,
and now I know more.

I did attempt to ask my peers for research.  Nobody responded; I assumed the
obvious stuff was taken care of.

>
>> >I'm not surprised that the reaction you get from the gnome-coders is
very
>> >much like what you'd get from any big games company with the same kind
of
>> >approach.
>>
>> You know, it's funny you use this big games analogy, because, like
movies,
>> alot of games suck.
>
>as with movies, the problem here is not bad design, but bad design goals.
>both have to be sold to as many people as possible, which leads to lowest
>common demoninator strategies. but this list is not the place to discuss
>that. I was making an example, I did not intend on talking about it's the
>finest details of the area where I took it from.


Odd how this happens to be relevant.  We've been discussing lowest common
denominator stuff; it's the core of what Sun is talking about.  I happen to
agree with him, by the way--GNOME *should* break free of some of the
traditions from the past.  We probably need to define some keyspace
standards.  This will break *TONS* of things, but it'll be much better
overall.

>
>
>> wonderful.  Why not in GNOME?  Total Annihilation has build queues.
They're
>> wonderful.  They should be in Starcraft.  They're not.
>actually... they are - for the protos, the race advanced enough in both
>technical and management areas to implement some. I don't know for terrans,
>I have played starcraft only once during a network session.
>
>but all of this IS besides the point.


Hang on, this happens to be relevant.

In TA, you can shift-click a bunch of buildings to be built, and your
builder will go point to point to point.  WONDERFUL UI, you never need to
think about the gruntwork of "ok, good that you're done with X, move onto
Y."

TA figured out what game players are forced to do that they don't like to
do, and fixed it.

Find out what people hate, and fix it.

That's been my point all along.  People hate losing stuff on the taskbar, or
just not having a taskbar?  Minbar.  People hate knowing what they want but
having to type it all?  Cluehunting.  People hate documentation, because
it's too dense and disconnected from the actions themselves?  Screenplays.
People hate not being able to use the keyboard for everything? Keyboxes.

Fix what people hate and you generate what people love.