[MUD-Dev] Mozilla: unity of interface

[J C Lawrence]

Consider the following in terms of MUD client interface _and_ MUD user
interface (currently the MUD command line, potentially something
differently structured):

URL:http://www.mozilla.org/unity-of-interface.html

               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 at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...