[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar

[Dr. Cat]

> If I might interject, I have the same sort of issues with most other MUD
> developers. Unfortunately, I don't have the time to seriously develop an
> active project; however, interface design and mass marketability are key
> issues I would dearly love to discuss. Some time back, I tried to start
> such a thread. It crops up peripherally now and again, but I've never
> really seen as much interest in it here as I'd like to.
[snip]
> Basically, I'm hearing you say that you want to talk about the same things
> *I* want to talk about, and postulating that no one wants to hear it. I do.
[mild flattery snipped]

Well, I don't know if many people do, given the "not much interest" you 
cite from prior attempts.  Anyway despite my earlier cranky remarks (I 
suppose I forgot to take my geritol that morning and the nurse didn't 
bring me my walker either so I couldn't cross the room to turn on the TV)
the main reason I don't talk about my work too much is because I have 
hundreds of things to implement, most of which I thought up years ago, 
and only one programmer (me) working on them.  And talking about the 
stuff doesn't get it done, adds only a small amount to my pool of ideas 
for what to do through the ensuing discussion - and with hundreds of 
things to do already that will make my product better, I really don't 
need ANY new things tossed in there, do I?  With the tiny subset of my 
plans that's currently implemented, and usage levels that only reach 
around 150 players at peak times, it's really "put up or shut up" time, 
and I'd rather go "put up" and talk later.

Still, flattery is flattery, and I can toss out a few more comments here 
- even though I sense you're asking somewhat different sorts of questions 
about user interface design than the ones I'm thinkg about.

> Let me open this up with a few observations I've made about command
> interfaces. I don't talk about this much, because command interfaces don't
> seem to be of much concern in discussions here. By command interface, I
> don't necessarily mean a command line, but whatever method the user employs
> to communicate with the server; in most cases here, that means a command
> line, but most people have at least some interest in going partially or
> fully point-and-click. It's not much of a secret that I tend to prefer text
> to graphical, based on certain economies of bandwidth and disk which come
> from that, but I have to admit that when push comes to shove graphical will
> pull more users. 

This is a non-issue to me.  All functions wherever possible must be 
executable using either mouse-only or keyboard only.  This just seems 
intuitively obvious to me.  Generally the "easy for novices" way of doing 
a thing (usually, but not always, the mouse interface) should be the 
easiest to notice (or have shoved in your face by the documentation), 
while the "power user" interface should be not too hard to find out 
about, but not "in your face" if you don't desire it and don't go looking 
for it.

Bandwidth isn't a big issue either.  Right now the traffic for Furcadia 
with 100 users online is usually small enough that it could fit through a 
single 56K modem.  Of course the server's going through a T-1, as well it 
should be - a maxed out modem would be giving people lots more latency, 
not to mention choking on the occasional bursts of higher bandwidth 
utilization.  But the point is, bandwidth usage on a well designed 
graphic mud doesn't necessarily have to be high.  Indeed, the current 
bandwidth usage on Furcadia can be (and will be) further reduced with 
some additional optimizations.

> To a degree, this can be remedied with natural
> language processing, like shorthand: 
> 
> 
> "Look." [There is a blue box here.] "Examine it." [You pick up the blue box
> and examine it; there is a button on the side.] "Press it." [You press the
> button on the box; the box makes a loud noise and begins to vibrate.] "Drop
> it." [You drop the blue box; it vibrates more urgently.] "Hide." [You duck
> behind something; the box explodes, but you are shielded from the blast.] 

This, to me, is a false grail.  As I mentioned earlier with regard to my 
scripting language, I'm a strong believer in mapping the tools tightly to 
the expected solution space.  Regretably most software developers seem to 
feel that the solution space is (or should be) "as many different things 
that are possible to do as I can possible enable the users to do".  This 
is the correct solution space to shoot for if you're developing a C 
compiler.  If I wanted my players to have the maximal power to interact, 
maybe I should just give them Unix shell accounts and a C compiler and 
say "Ok, go to it!  Play, have fun!  If you want to play in some 
particular specific way, go code it!"

In software aimed at consumers, particularly non-programming consumers 
(the majority of the human species, even now), I think the value your 
software has is directly related to how well you figure out "what is the 
set of things most users of this category of software most want to do", 
and build the capabilities of your software to be tightly coupled to that 
set of desires.  Where you provide more power or flexibility, you should 
do interface design such that the most desired options are obvious and 
easy to figure out, and the extra stuff is findable but not "in your 
face" to the users with simpler wants/needs - who will only become 
distressed if you throw up some screen with 173 options, buttons, 
sliders, and commands.

Print Shop was a good example of this, back in the 80s.  When it came out 
us power-users and developers-of-tools-for-other-power-users looked down 
our noses at it.  Things like paint programs, desktop publishing 
software, etc. etc. was FAR more powerful than this wussie little toy.  
Why would anyone even want it?  Well, it did a few things, but it turned 
out it did the few things that a LOT of people wanted to do, and it made 
it so quick and EASY to figure out how to do them!  They sold that thing 
so fast that everyone at Broderbund had to pitch in to help duplicate 
disks and stuff boxes in order to ship all the orders to distributors - 
from the secretaries right on up to the president!

Natural language doesn't fit well with this, for me.  Not only are you 
suggesting, by providing it, that "any English sentence you can type is a 
valid command string", thus offering the poor person trying to learn your 
game the hugest possible solution space, but it's not even a case of 
covering all that solution space for the power-users at the expense of 
the novice.  Your game is always going to be stuck understanding only a 
tiny percentage of the potential command strings, and even the power 
users will have to learn which things really work.  My senior apprentice 
calls this kind of thing "fighting the interface", and it's very bad.

"Look. [There is a blue box here.] Turn it over and read the writing to 
see if it was made in Taiwan. [I see no writing on the blue box.] Listen, 
jamoke, I wanna know if it was made in Taiwan! [I see no player named 
"jamoke" here.] Whassa matter with you, you stupid computer, don't you 
understand plain english? [I'm not sure what you're trying to do.  Type 
'help' for more instructions.] Aw nuts to you, just nuke that blue box 
and tell me where I can go in this game to find some lasagna to eat or 
meet some cool people to talk to that like the same TV shows I do. [I'm 
sorry, Dave, I'm afraid I can't do that.]"

By contrast, if you had SimpleGraphicMud where you had four compass 
arrows to click on to move, a text input box labelled "type messages here 
to talk to other players on your screen", and buttons labelled "get" 
"drop" and "use" for dealing with objects you see on the ground, it's 
unlikely that anyone would waste much time trying to do things that 
aren't doable in your game.  Players not feeling like they're wasting 
time is a good thing.  Tightly map your interface to what's actually 
doable.  And try to map what's actually doable to what players will want 
to do and what will generate large amounts of the mystic quantity known 
as "fun".

> Graphical interfaces offer a great way to avoid ambiguity.

Precisely.  They also generate simple, immediate "rewards" in the form of 
easy to digest feedback.  You see the little blue box move from the 
ground at your feet to the inventory box that shows "item currently in 
your hands".  There's a percentage of the human race that will feel that 
same sort of satisfaction at "seeing" it move out of the text paragraph 
that describes your current location, and "into" the paragraph of text 
that comes up whenever you type "inventory".  But they're a minority, one 
that just happens to have been a majority of the early adopters of 
computers.  While that minority is important and more intelligent on 
average and should be catered to forever (and I'm even a member of it 
probably), my job is to cater to the majority that really requires 
graphical feedback in order to maximize their fun.

> What gets overlooked in a lot of games I've played is whether a given
> interface is confusing or not. Every time a user has to go use your help,
> no matter how good that help is, his frustration level builds.

The real issues here, and the solutions they suggest, seem to me to be 
territory that most user interface designers aren't even aware of yet.  
For one - the "help file" concept, which Windows has gone so far as to 
define a bunch of fancy tools and standards for, is very static.  But the 
fact is, learning is an ongoing, dynamic process, and the help a users 
wants/needs in their first hour of using your product is very different 
from what they need in their second day, which is different from what 
they need after three months.  But pressing F1 for help in any Windows 
app is likely to pop up the exact SAME help menu with the same sub-menus 
and documents every time, forever.  Context-sensitive help is a small 
step in the right direction.  But considering learning the game to be an 
ongoing process, unfolding along the time axis, lets us immediately think 
of alternative solutions.  Consider that you, as creator of a game, feel 
that most people will want to learn about the "buddy list" feature after 
a certain amount of usage.  You could monitor every player, see if 
they've already found/used it on their own, and if not, say that 5 days 
after they first play, or 12 playing-sessions after they first play, or 
20 usage-hours after they first play, or the first time they get past the 
Palace of Gralfalnibar, you have "Beekin the Help Dragon" pop up and 
suggest "Say, now that you've gotten this far in the game, I think you 
might want to learn how to be told automatically when your friends are in 
the game.  Click [Here] to find out or [Here] if you're not interested."

The ultimate solution to the "help" problem, though, comes from the 
unique nature of the online medium, and wasn't even available as an 
option in the old days of single-user applications running on 
non-networked computers.  Consider "RTFM syndrome" or "my dad's 
navigation method".  Why do so many people ask "stupid questions" that we 
needed to even invent a half-joking acronym to tell people to try reading 
the documentation?  You could say it's because much documentation is so 
difficult to get the answers from for a novice user that they avoid it 
for that reason.  You could say it's because much software is so 
difficult and loaded with complex features that it's not bad writing that 
makes manuals so, it's almost inevitable that they will be unless maybe 
you had unusually brilliantly GOOD writing.  These may have truth to 
them, but they're only the tip of the iceberg.  You could say it's because 
most people don't come from a culture where "reading big long 
instructions things or browsing through them to get to some particular 
part that answer my question" is part of the life experience they're 
used to, acculturated to from experience with other things besides 
computers, accustomed to, conditioned to, trained to expect.  There 
you're getting a little close to the key underlying truth.  Why is it, 
though, that most people don't have to read even the simplest 
instructions about how to turn on a TV and change channels, how to run 
the microwave oven, the washing machine?  Why doesn't a farmer's son ever 
have to read an instruction manual on how and when to plow the fields, 
harvest the crop, feed the chickens and collect the eggs?

It's because people learn how to do all the basic things in life from 
other people.  That's what people are used to, what they want, and what 
they're conditioned to do to seek out knowledge when they perceive that 
they're missing something.  My partner and I have put out games with not 
many commands, and a little summary of the key ones permanently displayed 
in the lower left-hand corner of the main game screen.  It's ALWAYS 
there, and it says how to move, talk, whisper, and pick up items.  
Doesn't matter.  You'll still see newcomers ask how to do those things, 
and older players tell them how.  (Or whine about the newbies, but we try 
to do social engineering to minimize that!)  In the first few seconds, a 
typical person's eyes will register static text and think subconciously 
"more work to do", and see scrolling text that is people talking to each 
other and think "Aha, people!"  And immediately they will want to be 
talking to those people.  It's the most natural reaction in the world.

My other example is how my dad gets directions to places.  We can be in 
some city we're travelling to, ask someone for directions to the art 
museum, and find out it's three and a half blocks away, and here's five 
obvious landmarks on the way there.  Doesn't matter.  We'll have walked 
one block, spotted the first two of the five landmarks, and come to the 
street sign with the name of the street to turn left on...  I'm thinking 
we're well on course with no worries.  But if dad sees a fellow human on 
the sidewalk - he's asking for directions again.  It's an excuse to talk 
to people!  How could you ever pass up a chance to talk to people?  My 
dad can't, because it's the most pleasurable thing he could possibly do.
Compare this with the stress of reading through manuals or helpfiles.  
Most of which are static, don't understand natural language queries, and 
aren't flexible enough to figure out a response to questions they never 
expected or encountered before.  Even if it's just "Gee I dunno, but I 
think Bernie might know that."  That beats the hell out of what happens 
with manuals, which is usually that you spend extra time browsing even 
every vaguely-related topic to make sure the info you want isn't buried 
in there somewhere obscure, before you finally give up in disgust.

The ideal help interface to me is a big button that says "help", and when 
you press it a dialog pops up that says "Do you want to A) ask for help 
from another user, or B) browse through the game documentation?"  When 
people (most of them) pick A, in an ideal world there'll be enough 
volunteer player-helpers that most or all of the time a little chat 
window can pop up instantly, with someone typing "Hi, what can I help you 
with?" and you can type right back and you're off and running with the 
questions.

There's various enginery of thought about how you encourage players to be 
the volunteers for this, and whether or not you can really get enough and 
what to do if you don't, but I won't go into all of that here.  Back to 
work, or something.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  http://www.bga.com/furcadia
  Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

--
MUD-Dev: Advancing an unrealised future.