To: mailto:mozilla-general@DOMAIN.HIDDEN 
Subject: A point to ponder 
From: David Wright  
Date: Tue, 08 Sep 1998 23:11:12 +0200 
Newsgroups: netscape.public.mozilla.general 
Organization: Another Netscape Collabra Server User 
Resent-date: Tue, 8 Sep 1998 14:10:18 -0700 (PDT) 
Resent-from: mailto:mozilla-general@DOMAIN.HIDDEN 
Resent-message-id: <"BPKePD.A.mtB.d0Z91"@gila.mozilla.org> 
Resent-sender: mailto:mozilla-general-request@DOMAIN.HIDDEN 

I know we are all engaged in tireless bug-hunting, but the next time
your eyes glaze over and you have to stop looking at code for a
quarter-hour, indulge me and read and ponder this:

At http://www.mozilla.org/unity-of-interface.html is an exhortation
by Jamie Zawinski to keep the unity of the user interface that
Mozilla represents uppermost in our minds, even to the point of
sacrificing the application's ability to accomplish the subtle tasks
which are protocol-dependent.

This is not a dumb position, and it is certainly not an uncommon
one.  It represents the thrust of development of ever larger and
more monolithic applications like Communicator, Office, and
Mathematica (which is now trying to steal the preperation of
mathematical documents from TeX) which are dominating the CPU time
of ever more desktop computers.  But it is, in my opinion, a wrong
position, and I would like to argue here for an alternative.  It is
too late to move Mozilla 5 in the direction for which I will argue,
but I hope that these ideas will spur debate on the direction our
efforts should move afterward.

Let me begin with some personal examples:

I use Communicator for email (since mailto links call up
communicator's messenger component automatically) and for a lot of
ftp downloading (since ftp links call up communicator's ftp engine
automatically).  It's kind of nice to have this sort of unity of
interface that Zawinski advocates.  But it's also kind of
problematic.  It means I can't use my beloved text editor (Alpha)
and all its tricks I know so well (like regular expression search
and replace and the ability to upload text -- by running my ftp
client in the background -- from a remote disk) to write email and I
can't do batch downloads from an ftp directory (because communicator
does not support them and it's a pain to start up my ftp client and
login to a directory my web browser has already sent me to).  These
are the kind of sacrifices Zawinski is asking us to accept.

But they're not necessary.  In fact, they stand in opposition to the
spirit of open source development, the great advantage of which is
-- no, dummy, not free software -- end-user reconfigurability and
comitment to open standards.  Microsoft wants you to use Office for
everything so you won't use something else.  Netscape (under the old
model) wanted you to use Communicator for everything for fear that
you might use somebody else's software instead.  But we should be
happy to let you use whatever damn software you like.  Mozilla
should easily be configurable to call up Alpha or any other text
editor the end-user likes for composing email.  It should be able to
farm out ftp downloads to any ftp client I specify.
And if some of us think Mozilla's abilities in these areas are just
peechy, then fine with me, keep these components (perhaps even as
independent binaries) and let any user that wants to use 'em.

Let me point out some (again, personal) successes of this model:  On
the MacOS, the Alpha editor can send its output to any TeX engine,
code compiler, or browser you specify, along with the AppleEvent
instructions to do the correct thing, and many of these applications
can return Alpha the favor.  (Under Unix, emacs can function in much
the same way.)  So I'm successfully using one interface -- the one I
want -- to write TeX documents, code to compile for both my c++ and
Perl compilers, and html for my browser.  This is exactly the unity
of interface Zawinski wanted to achieve.  But I'm not using it for
my email, because Communicator won't talk to it, and I'm not using
it to write Mathematica code, because Mathematica insists I use its
own monolithic interface.

So let's work to improve Mozilla's communication with foreign
processes.  Remeber we are not working to make everyone use our
product for everything; we are working to provide the best possible
tools to a highly varied group of end-users: ourselves.

To: mailto:mozilla-general@DOMAIN.HIDDEN 
Subject: Re: A point to ponder 
From: Jamie Zawinski  
Date: Tue, 08 Sep 1998 23:09:24 -0700 
Newsgroups: netscape.public.mozilla.general 
Organization: the mystic knights of mozilla, http://www.mozilla.org/ 
References:  
Resent-date: Tue, 8 Sep 1998 23:10:26 -0700 (PDT) 
Resent-from: mailto:mozilla-general@DOMAIN.HIDDEN 
Resent-message-id: <"BMC39C.A.FEF.Yuh91"@gila.mozilla.org> 
Resent-sender: mailto:mozilla-general-request@DOMAIN.HIDDEN 

David Wright wrote:
> 
> At http://www.mozilla.org/unity-of-interface.html is an exhortation
> by Jamie Zawinski to keep the unity of the user interface that
> Mozilla represents uppermost in our minds, even to the point of
> sacrificing the application's ability to accomplish the subtle tasks
> which are protocol-dependent.

I don't think that's quite a fair characterization of what I said;
I would choose a different value-laden set of words than the above,
and phrase it as, "you should focus on the parts of a protocol that
actually matter to real users, and not spoil the user interface with
needless complexity just to support protocol features that are only
used by a tiny minority of your users."

> which are dominating the CPU time of ever more desktop computers.

Ah, some kind of jab intending to imply that programs with consistent
interfaces are necessarily bloated and slow?  

> It means I can't use my beloved text editor (Alpha)
> and all its tricks I know so well (like regular expression search
> and replace and the ability to upload text -- by running my ftp
> client in the background -- from a remote disk) to write email and I
> can't do batch downloads from an ftp directory (because communicator
> does not support them and it's a pain to start up my ftp client and
> login to a directory my web browser has already sent me to).  These
> are the kind of sacrifices Zawinski is asking us to accept.

Not at all.  I am not asking you to accept it.  I am claiming that by
focussing on the most-commonly-used operations of the majority of users,
the interface is more usable.  That's an important distinction. I'm not
trying to force you to do anything -- I'm trying to build programs that
provide maximal utility to the largest number of people.

Always remember, power users are the minority.  I am not the kind of
person for whom I am writing software -- and I hope you aren't either.

> So let's work to improve Mozilla's communication with foreign
> processes.

On this much, I certainly agree.

> Remeber we are not working to make everyone use our product for
> everything; we are working to provide the best possible tools to a
> highly varied group of end-users: ourselves.

That depends on where you draw the line around "ourselves."  I'm not
trying, primarily, to build software for myself, or for the people most
likely to read this message.  (My mom doesn't read this newsgroup.)  I'm
trying to build software that has the most utility to the largest number
of users.  While it's certainly important to make software that is
attractive to power users, making software that is usable by and
understandable by non-programmers and other non-members of the
technological priesthood is, in my opinion, far more interesting.

> Microsoft wants you to use Office for everything so you won't use
> something else.  Netscape (under the old model) wanted you to use
> Communicator for everything for fear that you might use somebody
> else's software instead.  

That may or may not be the case, but that is not the source of my
motivations in writing the Unity of Interface piece; obviously not,
since I wrote that after Mozilla was already open source.  My motivation
is simply what I said it was: I believe that environments that present
the same interface for the same basic task are easier to use.

Perhaps the amount by which they are easier is insignificant to a power
user; perhaps a power user doesn't care that the FTP program and the
Gopher program have different command names, and different screen
layouts; but I promise you, such details are *very* important to *most*
users in the world.

> But we should be happy to let you use whatever damn software you like.

And of course I said nothing to contradict that.  In fact, I strongly
encourage people to put in as many hooks as they can.

However, I will also point out another misconception that a lot of folks
seem to have taken away from the Unity of Interface essay that I didn't
intend (and perhaps this is my fault.)

I was writing about user interface: the on-screen presentation of
commands and functions to users.  I encouraged that the same interface
be used for the same task.  However, many people seem to have assumed
that this meant that there should be one *program* that does all tasks,
and that's not what I meant to imply at all.  Just because the interface
is unified does not necessarily imply that (for example) two pieces of
code are running in the same address space, or are both loaded into
memory at the same time, or are even written in the same programming
language.  Those are all implementation details.  I was talking about
interface.

This is one of the great things about XP-COM -- if two modules hook up
via a COM interface, they might be a part of the same program, or they
might not.  They might be running on the same machine, or they might
not.

So if you want to add hooks so that your favorite editor can be used,
more power to you -- everyone wins.  Because, if the main body of
Mozilla, and the editor component of Mozilla, are separated by a COM
interface, then we get the best of both worlds -- Mozilla now has a
pluggable editor, and comes with a default editor that has the "unity of
interface" properties I described.  Yet, the (minority of) power users
still get to use their favorite editors (and since they are power users,
they won't care that it has a different interface than the rest of
Mozilla).

> Let me point out some (again, personal) successes of this model:  On
> the MacOS, the Alpha editor can send its output to any TeX engine,
> code compiler, or browser you specify, along with the AppleEvent
> instructions to do the correct thing, and many of these applications
> can return Alpha the favor.  (Under Unix, emacs can function in much
> the same way.)  So I'm successfully using one interface -- the one I
> want -- to write TeX documents, code to compile for both my c++ and
> Perl compilers, and html for my browser.  This is exactly the unity
> of interface Zawinski wanted to achieve.  But I'm not using it for
> my email, because Communicator won't talk to it, and I'm not using
> it to write Mathematica code, because Mathematica insists I use its
> own monolithic interface.

Well now it sounds like you're agreeing with me...  That having a
consistent interface is highly desirable.  You're unhappy because most
of your tools are consistent, but that one (Mozilla) won't play with the
others.  It's the same problem, really.

-- 
Jamie Zawinski
jwz@xxxxxxxxxxx    http://www.mozilla.org/   (work)
jwz@xxxxxxx        http://www.jwz.org/       (play)