<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Mozilla: unity of interface -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Tue, 16 Jun 1998 14:40:22 -0700 -->
<!--X-Message-Id: 199806162128.OAA01739#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Mozilla: unity of interface</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg01084.html">Previous</a>
| <a href="msg01086.html">Next</a>
]
Thread:
[ <a href="msg01096.html">Previous</a>
| <a href="msg01083.html">Next</a>
]
Index:
[ <A HREF="author.html#01085">Author</A>
| <A HREF="#01085">Date</A>
| <A HREF="thread.html#01085">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Mozilla: unity of interface</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Mozilla: unity of interface </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Tue, 16 Jun 1998 14:28:57 -0700</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Consider the following in terms of MUD client interface _and_ MUD user
interface (currently the MUD command line, potentially something
differently structured):
URL:<A HREF="http://www.mozilla.org/unity-of-interface.html">http://www.mozilla.org/unity-of-interface.html</A>
unity of interface
by Jamie Zawinski
18-May-98
If one must pick one thing as being the core concept and greatest
strength of the ``web browser'' as we know it today, it is this:
The same interface for the same task,
regardless of how the service is
implemented on the other end.
Short of being cross-platform (which deserves a document of its own)
Mozilla's greatest strength is that it manages to provide a unified
interface to a number of useful services and protocols.
It is more interesting to support a concept than to support a
particular implementation of it.
For example, document retrieval works the same way
regardless of the underlying protocols used, be they HTTP,
FTP, Gopher... The important detail is the act of clicking on a
link, and getting a document back. All else is implementation
detail, and of no interest to the end user.
Likewise, the Mozilla mail reader behaves the same way
regardless of where the messages are stored (on the local disk,
or on an IMAP server.) And the user interfaces for the
Mozilla mail reader and news reader are very similar because
they are very similar tasks: management and retrieval of
messages. They differ in certain specifics, but the concepts are
largely the same, and therefore, the interfaces are largely the
same.
As support for new protocols is added to Mozilla in the
future, such support should follow this same model: when
there are two protocols that do similar things, Mozilla should
support a common interface for each.
How do you write software that supports a general concept?
First by cataloging the various features of the specific
protocols that exist, and deciding what the most important
overlapping concepts are. Then, you try and build an interface
that does all the important stuff the same way, and (hopefully)
allows the protocol-specific features to show through when
they are available.
FTP, HTTP, and Gopher have disjoint sets of features, but
Mozilla supports each of these protocols. It doesn't support
them all fully; there are a number of commands that a
command-line ftp client supports that aren't accessible from
Mozilla; but the basics are there. And 99.5% of the time, it's
good enough.
Mail and News are another example of the same thing; there
are some very mail-specific concepts, like deletion; some
very news-specific concepts cancelling; and some concepts
that are pretty-much the same if you look at them right, like
the various reply options, and subscription, and kill files /
filters.
Note that the important detail here is not reuse of code, but
rather, reuse of interface: there's a good chance that there
won't be much code sharing between the implementation of
various protocols (HTTP and FTP share very little code, for
example, since their on-the-wire protocols are radically
different) but that doesn't mean that, in so far as they have
conceptual similarities, they shouldn't present themselves to
the user in a similar way.
Some people argue that when you try and make one program
that does many things, you often end up with a program that
doesn't do any of them perfectly.
I reject that argument, because the goal is to let the user
accomplish what they want to accomplish: not to produce the
perfect implementation of a particular protocol. The latter
may be a means to the former end, but that's all.
And, I believe that a program that does many things to the
70th percentile beats hands down a program that does one
thing perfectly; and also beats hands down a suite of programs
that all do one thing perfectly, but that each do so with totally
different interfaces that must be learned afresh for each task.
A specific example: chat.
For the sake of argument, I propose that Mozilla should
include a ``chat'' client. And, following the thesis presented
above, that Mozilla should support various chat protocols in
an abstract way.
It seems clear that chat systems like IRC and ICQ (and the
AOL chat rooms, and, to some extent, certain MUDs/MOOs)
are similar enough that one could come up with an interface to
each of them that makes sense for each: they all incorporate
line-at-a-time communication among (potentially) large
numbers of people. They each have concepts of ``rooms'' and
``private messages'' and so forth.
However, let's also consider a harder example: could we come
up with an interface that worked for both IRC/AOL-style
chat systems, and also for a more different system, the Unix
``talk'' protocol?
Let's imagine that we have a UI with the general form of: a
big text area in which the various typed comments of the
participants appear; a text-entry area at the bottom; and a
toolbar. Let's imagine that some of the commands available
are concepts that are not available on all chat systems, like
``change channel'' or ``change handle'' or ``upload GIF.''
Well, if the current protocol doesn't support it, the command
would be disabled. (Or perhaps the set of commands on the
toolbar would be slightly different, depending on the protocol
being used.)
Current implentations of the Unix ``talk'' protocol are
unbuffered, one-character-at-a-time systems in which the
participants can see each other typing, including deletions, as
they happen.
I think that most other chat systems are line-at-a-time, or
otherwise pre-editable. Assuming that this is the case, this
would suggest that that the right thing to do, in the ``talk''
implementation, is to make it do pre-editing as well: that is,
when using the Mozilla chat client to speak the ``talk''
protocol, characters would not be sent until the user hit return;
and likewise, the text from the person on the other end would
be presented one line at a time (or when the other person
stopped typing for a second or two, or something along those
lines.)
This would mean that if one person was using the Mozilla
chat client, and another person was using the classic Unix
``talk'' command, they would have rather different UI
experiences than they would have if they were both using the
same client. However, that is no different than the case of two
people exchanging email using radically different mail
readers: they each have their preferred interfaces, but
communicate via common protocols.
Conclusion: tools versus protocols.
The important thing to keep in mind when trying stuff like
this is that at some level, ``chat'' is a concept, like ``document
retrieval'' or ``message handling,'' and what you're trying to
do is build a useful tool on top of those protocols that can
interoperate with other tools that also happen to speak those
protocols.
You are not necessarily trying to clone the user interface of
those other, pre-existing tools.
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg01084.html">[MUD-Dev] Re: Is worse better?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg01086.html">[MUD-Dev] Re: Levelless MUDs</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg01096.html">[MUD-Dev] Re: Mozilla: unity of interface</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01083.html">[MUD-Dev] Is worse better?</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#01085"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#01085"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Prescience Rules?</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="01122" HREF="msg01122.html">[MUD-Dev] Re: Prescience Rules?</A></strong>,
Joel Kelso <a href="mailto:joel#ee,uwa.edu.au">joel#ee,uwa.edu.au</a>, Thu 18 Jun 1998, 01:42 GMT
</LI>
</ul>
</ul>
</LI>
<LI><strong><A NAME="01109" HREF="msg01109.html">[MUD-Dev] ADMIN: OS Wars</A></strong>,
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Wed 17 Jun 1998, 15:44 GMT
<LI><strong><A NAME="01101" HREF="msg01101.html">[MUD-Dev] Re: [Fwd: Warfare on retromud.org 3000]</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Wed 17 Jun 1998, 04:54 GMT
<LI><strong><A NAME="01096" HREF="msg01096.html">[MUD-Dev] Re: Mozilla: unity of interface</A></strong>,
John Bertoglio <a href="mailto:alexb#internetcds,com">alexb#internetcds,com</a>, Wed 17 Jun 1998, 03:15 GMT
<LI><strong><A NAME="01085" HREF="msg01085.html">[MUD-Dev] Mozilla: unity of interface</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 16 Jun 1998, 21:40 GMT
<LI><strong><A NAME="01083" HREF="msg01083.html">[MUD-Dev] Is worse better?</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 16 Jun 1998, 20:47 GMT
<UL>
<LI><strong><A NAME="01084" HREF="msg01084.html">[MUD-Dev] Re: Is worse better?</A></strong>,
Katrina McClelan <a href="mailto:kitkat#the486,bradley.edu">kitkat#the486,bradley.edu</a>, Tue 16 Jun 1998, 21:25 GMT
<UL>
<LI><strong><A NAME="01097" HREF="msg01097.html">[MUD-Dev] Re: Is worse better?</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 17 Jun 1998, 03:18 GMT
<UL>
<LI><strong><A NAME="01098" HREF="msg01098.html">[MUD-Dev] Re: OT:Re: Is worse better?</A></strong>,
Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 17 Jun 1998, 03:35 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
