From: ghudson@athena.mit.edu (Greg Hudson)
Subject: Request for input: graphical design for an Xwindows mud client
Summary: Author seeks input for graphical client design
Keywords: interface client X
Organization: Massachusetts Institute of Technology
Date: Wed, 27 Jan 1993 00:54:49 GMT

I am planning at some point to write an Xwindows interface for VT, my
more recent client project.  This interface might possibly be coupled
with some object-oriented extensions to the VTC language.  In keeping
with the philosophy of involving the user in the design process as
early as possible, I would like at this point to request information
on users' conceptions of what a good graphical interface for a mud
client would be.

There are existing X-based mud clients--the BSX client, for one, and
pmf, which I never tried out.  To the best of my knowledge, none of
these support an essential feature of VT, which is multiple
simultaneous visible connections.  The issue of what sort of workspace
to deal with and how to divide this workspace up between connections
can be answered in several different ways.

One possible model is to leave the workspace more or less as it looks
when you run VT in an xterm.  For those of you who are not VT
users--that is, most of you--this interface resembles both emacs and
TF's visual mode.  There is a horizontal divider line close to the
bottom of the screen separating input from output, and then several
more divider lines separating various output regions.  The only
modification required in this approach would be the ability to create
windows on the fly to display information in, but not other
connections.  For instance, instead of typing 'help' and having to
turn /more on to keep a large block of help text from scrolling past,
you might type '/show help' and a window would pop up to display the
output of that command.  One could even build in an interface to emacs
or emacsclient to provide a little of the functionality that mud.el
gives to MOO users.

Another model is to create a workspace and allocate subwindows within
it--a little like the way sam (the Plan 9 editor) does things.  I am
not terribly enamored of this approach, since my experiments with line
numbering indicate that it's inconvenient to mud with fewer than 80
columns.  There isn't much occasional to split one's workspace into
other than vertically-stacked regions.

Probably the most intuitive model is to have one window for each
connection.  There are two problems with this approach.  The first is
that it's difficult to decide where to hold input.  Storing it in a
separate window is rather bizarre, and having a separate input region
for each server connection destroys a lot of the flexibility of the
current interface--for instance, if a user sends text to the wrong
server, he or she currently need merely switch to the correct server
and use ^P <return> to recall and send the previous line.  On the
other hand, this interface makes it less likely to make such mistakes,
since it's clear what server (or at least which window) one is sending
to.  And we do have cut and paste.

The second problem relates to a personal preference on my part.  My
current job involves Macintosh programming, and I'm finding that I
work much more efficiently if I tile my windows, even if this requires
I make them smaller than I might like to.  Windows have a fairly
amount of screen overhead for the border and the scrollbar and the
title bar (if you have one) and anything else you care to put in them
besides text.  Windows also have a tendency not to pack well without a
lot of fiddling.  A proliferation of semi-permanent windows strikes me
as somewhat annoying.  In particular, I find the Finder interface for
the Macintosh highly annoying, since it puts semi-permanent windows on
the screen like mad.

Why do I not keep things simple and have just one server connection
per client process?  Because it's often useful to use the text from
one server while communicating with another.  Manual operations of
this nature can be dealt with to some degree by cut and paste, but
automatic operations cannot deal with this.  Also, in almost any
windowing system there is a noticeable time overhead in launching or
terminating an application; in VT I can open a connection to a mud
almost instantly by temporarily reusing one of my current output
regions.  I don't want to lose this advantage.

References to style guides are appreciated, if they contain
information on how to deal with applications that involve multiple
input destinations and multiple output regions.

Thanks in advance for any input on this subject.

VT, incidentally, is a generic client program (although it doesn't
support the telnet program or any terminal emulations, which limits
its usefulness right now).  It is currently used mostly for Tinymuds,
and has the most support for line-based servers.  Using it for LPmuds
and Dikumuds requires a very small amount of hacking on the
distribution VTC code at the current time to arrange for echoing of
outgoing text, but I doubt that problem would carry over into the
distribution for the graphical interface.

--Greg