unity of interface
by Jamie ZawinskiIf 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.