[MUD-Dev] When the interface becomes the challenge.

[Edward Glowacki]

Quoted from Andrew Wilson on Fri, Jun 22, 2001 at 11:51:00AM +0100:

> I use this approach in the tkMOO-light client, using some MCP
> messages to tell the client which commands are visible to the user
> at any time (so it's also useful for tab-to-command-completion
> tricks).  MOO-server commands are generally of the form ' verb
> object [on/to] object ', so it's enough to check that the first
> word in the client's input window matches one of the visible
> commands.  If the word matches then the client underlines the
> word, as a simple visual cue, and hitting [enter] sends the
> window's content to the server unchanged.
 
> If the first word doesn't match then the client assumes that the
> words are to be spoken and sends the window's content preceeded by
> 'say'.

It seems that what would happen a lot is that typing the same thing
in two different rooms results in two different things.  For
example, if you are in a room with a chest and you type "open
chest", it would do as you command, but if the room had nothing to
open, you would say to everyone in the room, "open chest", to which
they would probably respond, "What chest?" instead of you getting an
error message saying that there was nothing in the room to open.

Until you complete the first word of whatever you're typing, you
won't know what mode you're in, command mode or say mode.

> When this feature first turned up in the client, several
> unsuspecting users complained - it wasn't what they were used to.

It's reasonable to expect them to complain if it was an unannounced
change, because suddenly the game was behaving differently.

> Of course the feature is optional, and the client can revert back
> to a simple what-you-type-is-what-you-send approach if needs be.
> But it seems that, whatever approach you take, there'll always be
> someone who was educated differently and who is quite comfortable
> with the existing setup.  It's almost like having an accent or
> dialect, but for typing, and perhaps not something a designer
> should strive to normalise.  Perhaps providing a range of input
> modes is something worth aiming for.

Actually, I think having a range of input modes is probably a bad
choice if you're aiming to design a good, efficient user interface.
If there is more than one way to do the same thing, the user has to
choose which one to use every time they want to use that feature,
and that decision takes time.

If you're designing any kind of user interface, I recommend
investing some time in reading a UI design book or two.  "The Humane
Interface" by Jef Raskin (one of the early Macintosh creators) has
some good information about modes that might directly apply to this
topic (I've used some of his arguments in my response).  Another
very good book is "The Design of Everyday Things" by Don Norman,
which doesn't cover computers so much as everything you see in the
world, and after reading it, you really begin to think about things
differently.  Some good web sites to take a look at are
www.asktog.com and www.useit.com, and also the Interface Hall of
Shame at www.iarchitect.com


--
Edward Glowacki			glowack2 at msu.edu
"Speak softly and carry a +6 two-handed sword."  --fortune
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev