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

[Andrew Wilson]

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

>> 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.

True enough I guess and this sort of thing does happen, usually when
the object I though was there has been moved by someone.  It's a
text mud we're talking about here, which means people read the room
description once, memorise the location of all the cool toys and
then assume that they'll never move.  In reality stuff moves about,
although on the social mud I frequent it doesn't move around too
much.  It's a bit like walking into your bedroom and trying to put
on your shoes only to find that they're in the hall.  More or less
harmless.

The UI I described works because people remember the ways they can
interact with objects.  There's no sense of having to learn every
command sequence from scratch each morning.  The UI is there to
minimise the amount of typing that people have to do, plain and
simple.

It's not a good descovery mechanism.  Sure you can type 'a' and then
[tab] a few times and a range of commands beggingin with 'a' will
appear on the command line.  But you don't get told what the command
does or which object it operates on.  Specifically the UI has not
been designed to provide this additional information, though the
object that owns the command *is* known and could be made available
to the client.

Several muds have developed an 'examine' command, which cuts to the
quick and provides a list of useful syntax for the object in
question eg: It's a door, valid commands are: 'open door', 'close
door', 'slam door', 'lock door with <any key>' etc.  Quite how I'd
put all that on a command line I just dunno.  Mmm, perhaps [tab]
should bring up templates, whole sentences with gaps for the
modifiers eg: lo[tab] produces 'lock door with '.  Well that might
work.

I find this UI to be easy to use, and worth any hassle it may cause.
You can bet this is because I've *learned* to find it easy - such
imperfections as it contains han be glossed over by an able brain
(which I keep in a box under my bed).  Like with Grafiti, the
shorthand for PalmOS PDAs, it's a case of the user's skill making up
for any shortfall in the UI.

>> 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.

Yeah.  It was one of those cases where I dropped the ball and
shipped a new feature with the wrong defaults.  The new gadget was
On instead of Off.  I still have the dunce's cap somewhere...

>> 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.

Certainly not a good thing to do when designing an aircraft
flight-deck, probably not so bad when designing a social mud.  Most
people sit around all day talking about last-night's pizza party,
it's not as if they have emergencies down there.  For twitch games,
a good UI is make or break and the last thing a new game needs is a
5 hour learning curve before people can pick up the sword and attack
the monsters.

> 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

Thanks, I'll take a look at these.

Cheers,
Ay.

andrew at awns.com
Cell: 07889 61 61 44                 Voice/Fax: +44 (0) 1865 513 091  
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev