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

[Edward Glowacki]

Quoted from Andrew Wilson on Wed, Jun 27, 2001 at 11:37:43AM +0100:

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

Sometimes though if the little things work well, the whole system
*feels* more friendly. =)

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

Minimization is good.  How does the minimization affect habit
forming though?  The real way to "zen" with an interface is to form
habits and have the interface fade completely into your
subconscious.  To do this, the same user input should always produce
the same output.  If the mud is generally social and the user forms
a habit of typing "a<tab> biff [a question]" to use the "ask"
command, then that user goes out of the social area and into the
wilderness where PK is allowed and suddenly "a<tab> biff [a
question]" becomes "attack biff", then there is a problem.

I use vi or vim as my primary editor for email and such, and I get
tripped up all the time between insert and command modes, where
sometimes "d" is a letter to be inserted into my document and other
times "d" means to delete (something).  It's a problem with modes.
In my case, it does actually say what mode I'm in at the bottom of
the screen, but when I want to type, I don't ever look at the bottom
of the screen to see what mode I'm in, I just type.  In your case,
it sounds like you might have a similar problem with modes.

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

Eeek... that could get messy! =)

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

I used to think that way a lot too (and I still do, as in the case
of vi ;) ), but as I read more about usability, I realize the
possibility is out there for so much better interfaces.  Things can
be improved greatly over existing conditions with very little work.
There are dozens of simple rules you can follow to make an interface
better, designers just have to start learning them.  It's actually
very eye opening to read some of the UI design stuff, you start
seeing things everywhere where designers have and have not done the
right thing.  After reading "The Design of Everyday Things", I'll
never look at a door the same way again, especially if I ever ask
myself, "Push or pull?"


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

=)


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

True, if the game is primarily social and laid back, it's probably
not a big deal.  For games in general that might have a more mixed
atmosphere of socialization and adventuring and combat, a good UI
can help tremendously, and a bad one can really kill a game.

Even in something as laid back as email, I've found a good interface
makes a lot of difference.  Right now I'm using MUTT to do email
because it threads messages (which is essential with the volume of
traffic and depth of threads on this list!!! ;) ), but I don't feel
as good using it as I did when I used PINE.  PINE just *felt* good
to use, and I never felt like a stray keystroke was going to hurt
anything.  With Mutt, I'm not so confident.  Sure I know how to use
it, and I can overcome its shortcomings somewhat, but there's always
that feeling in my mind that I'm not entirely in control.  Actually,
there's the key (the memory of my readings returns!!!), that the
user should feel in control at all times.  They should be running
the show, and the computer should be adapted to the way *they* work
instead of them adapting to the way the computer works.


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

Hope I didn't come across as too harsh on this, I really just want
to help and hopefully give you some good feedback.  I'm still
learning about UI design too, so hopefully I haven't twisted the
concepts too much when sharing them with you. =)

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