[MUD-Dev] Usability and interface and who the hell is suppo

[Travis Casey]

Caliban Tiresias Darklock <caliban at darklock.com> wrote:
>On Friday, September 19, 1997 4:56 AM, Chris Gray
>[SMTP:cg at ami-cg.GraySage.Edmonton.AB.CA] wrote:
>> [Caliban:]
>>
>> :Graphic interfaces
>> :are inherently limiting in expression, which I think we all agree is Bad
>on
>> :MUDs.
>>
>> Limiting expression is bad. That does not imply that graphics is bad. It
>> only implies that a limited graphics-only input system is bad.
>
>That's what I said: limiting expression is bad. Since a graphic interface
>inherently limits expressiveness, you must therefore offer additional input
>mechanisms.

What Chris is getting at is that there graphic interfaces come in a wide
variety, not just the "point your mouse at things and click on them"
variety.
While *some* graphic interfaces limit expressiveness, many do not.  See, for
example, such innovative graphic interfaces as NLS/Augment and KMS.

>I don't actually care what the output is, I care how the user is expected
>to tell the game what he's doing. That's my point. The client he uses is
>irrelevant. The server behind it is irrelevant. Even the feedback he
>receives is irrelevant. I am trying to keep the issue focused on one
>specific area, since when I proposed more general solutions everyone told
>me I was an idiot. (I don't know why. The approaches I present are grounded
>in exactly the same concepts as distributed computing, the component object
>model, remote procedure calling, and what user interface experts have
>championed as the 'right' way to build software for years. One of us --
>either me or the group -- is looking the wrong direction.)

"Everyone" and "the group?"  Is this the same Caliban who said in another
post, "I really detest statements of vast generalisation?"  Do you only
detest them when you're not the one making them?

IMHO, input mechanisms for a mud should be made as broad as possible --
that is, they should accept a wide variety of input, try to do something
reasonable with it, and if they can't, give informative error messages.
Some aspects of NLP can play a role in this, but I'd personally use it to
augment the standard mud command system, not to completely replace it.
(That is, rather than trying to create a full NLP interface, I'd like to
set up a system which can understand that "the second ball", "2nd ball",
"ball 2" and "ball.2" are all references to the same thing.  The LP-
and Diku-isms may be grammatically incorrect, but I believe supporting
them is useful.)

A GUI with mouse support, etc. could also be nice -- but it definitely
shouldn't be the only way to access the mud.
--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
     '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html