Eugene Eric Kim wrote: (01)
>... you say Java was "sufficiently elegant." and Mozilla isn't "sexy."
> Seems like you've got two different standards here.
>
I'll rephrase. Java was sufficiently sexy. Mozilla is
insufficiently elegant. Same standard. Sexy = elegant
= simple + powerful. (02)
> In my references section, I cite Richard Gabriel's "Worse Is Better"
> essays:
>
> http://www.blueoxen.org/papers/0000D/#nid3N2
>
> Many researchers implement good ideas in tools that nobody ends up
> using. One way to avoid this problem is to implement the ideas in
> tools that people do use. If you're happy about having a sexy tool
> with no users, then you can safely ignore my point.
>
I've been guilty of that. Neither Mozilla or Java is short of users,
so that's not the issue. But the growth curve is. Mozilla has many
end users, but how many toolkit users? Granted, some really good
things are happening in the RSS aggregator space. But most "take a
look at this" messages I've seen for aggregators are Outlook-based.
That could be a statistical blip, since I've only recently been
alerted to the subject, or it could be indicative of ease of
development. (Developers who spend less time getting things done
spend more time on quality, functionality, and ease of use.) (03)
I took a look at the toolkit when HTML forms were insufficient for
a client I was building. But the toolkit was neither sufficiently
powerful enough or simple enough to be attractive. So I suspect
that, rather than being a statistical blip, the aggregator story
may well be indicative of the development environment. (04)
So I don't think it's enough to say that developers should use
the tool because it's there. Every corporation that makes a
development product says the same thing, sooner or later --
our developers should use our product. If they have a really
good product, that's no problem. But they usually wind up
saying that because it isn't. (05)
My response to that is that "the product should be good enough
that our developers *want* to use it". All things being equal, the
number of internal developers using the product is a measurement
of its quality. "Our developers should be using our product" is
correct as a quality measurement. If they're not, it says the
company has to improve either its internal marketing or the
product. Generally, it's the latter. That statement is not valid
as a prescription, however. If it's effective, it dooms the
company to lowered production. (06)
I understand that the issue you're describing is somewhat different,
but there is much that is analogous. The balkanization of the client
space is not a good thing. But the solution is to make it so easy
to develop a robust client that the choice is a no-brainer. Clients
based on the same foundation will then, presumably, have an easier
time talking to each other, as well. (07)
>> "What's needed is a standard way to express and manipulate the
>> fundamental constructs of a document, regardless of the syntax
>>
>>Powerful thought. Have you done any preliminary thinking about
>>what it might be like? Can you put forth a strawman proposal
>>that hits the highlights? I love the concept. Can it be made
>>any more concrete, or are we starting with a blank page (and a
>>great idea).
>
> There's been plenty of preliminary thinking: Groves, NODAL, RDF to
> name a few.
>
Then why are we still searching for a standard way to express and
manipulate the fundamental constructs of a document? (08)
> My emphasis is on "shared concepts." I think that the fundamental
> pieces of the solution already exist. The problem is that several
> people have pieces of the solution, but they are working in isolation.
> These folks need to come together and create a common framework on
> which all of their work can be based.
>
Now *there* is an idea with real merit. We need a summit meeting.
You have a wide enough global view to identify the world leaders
who should be invited. Let's call a summit meeting, get them
together, and make history. (09)
--
This message is archived at: (010)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=407C6CA7.7080409@sun.com (011)
|