<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar -->
<!--X-From-R13: "Re. Qng" <pngNotn.pbz> -->
<!--X-Date: Thu, 30 Apr 1998 10:13:29 -0700 -->
<!--X-Message-Id: 199804301712.MAA09076#zoom,bga.com -->
<!--X-Content-Type: text -->
<!--X-Reference: 199804300717.DAA05032#relay,mnsinc.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cat#bga,com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00268.html">Previous</a>
| <a href="msg00270.html">Next</a>
]
Thread:
[ <a href="msg00264.html">Previous</a>
| <a href="msg00279.html">Next</a>
]
Index:
[ <A HREF="author.html#00269">Author</A>
| <A HREF="#00269">Date</A>
| <A HREF="thread.html#00269">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</LI>
<LI><em>From</em>: "Dr. Cat" <<A HREF="mailto:cat#bga,com">cat#bga,com</A>></LI>
<LI><em>Date</em>: Thu, 30 Apr 1998 12:12:13 -0500 (CDT)</LI>
<LI><em>Cc</em>: <A HREF="mailto:pixel#bga,com">pixel#bga,com</A></LI>
<LI><em>Delivery-date</em>: Thu Apr 30 10:13:31 1998</LI>
<LI><em>Delivery-date</em>: Thu, 30 Apr 1998 10:13:31 -0700</LI>
<LI><em>Envelope-to</em>: claw#kanga,nu</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent,,,," <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> 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:
*-------------------------------------------** <A HREF="http://www.bga.com/furcadia">http://www.bga.com/furcadia</A>
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>
<ul compact><li><em>From:</em> Caliban Tiresias Darklock <caliban#darklock,com></li></ul>
<li><strong><A NAME="00279" HREF="msg00279.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>
<ul compact><li><em>From:</em> s001gmu#nova,wright.edu</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00264" HREF="msg00264.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></STRONG>
<UL><LI><EM>From:</EM> Caliban Tiresias Darklock <caliban#darklock,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00268.html">[MUD-Dev] Re: PK's: A solution?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00270.html">[MUD-Dev] Re: There can be.. only ONE! (fwd)</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00264.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00279.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00269"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00269"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Java for Mud Client (Crossfire MUD topic)</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00245" HREF="msg00245.html">[MUD-Dev] Re: Java for Mud Client (Crossfire MUD topic)</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 30 Apr 1998, 00:04 GMT
</LI>
</ul>
</ul>
<LI><strong><A NAME="00244" HREF="msg00244.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 29 Apr 1998, 23:52 GMT
<UL>
<LI><strong><A NAME="00259" HREF="msg00259.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Thu 30 Apr 1998, 04:29 GMT
<UL>
<LI><strong><A NAME="00264" HREF="msg00264.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 30 Apr 1998, 07:18 GMT
<UL>
<LI><strong><A NAME="00269" HREF="msg00269.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Thu 30 Apr 1998, 17:13 GMT
<UL>
<LI><strong><A NAME="00279" HREF="msg00279.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Thu 30 Apr 1998, 20:53 GMT
<UL>
<LI><strong><A NAME="00287" HREF="msg00287.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Thu 30 Apr 1998, 23:23 GMT
<UL>
<LI><strong><A NAME="00407" HREF="msg00407.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 05 May 1998, 18:21 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Fri 01 May 1998, 04:12 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
