[MUD-Dev] Clients

[Caliban Tiresias Darklock]

At 06:20 PM 2/11/98 +0000, coder at ibm.net wrote:
>
>A good and well worded point.  Define by need, not feature.  Its a base
>rule of design, and is a common problem I face as a contractor with client
>requirements.

Another point which I'm facing right now in a project:

We have a series of requirements for an application. These requirements
dictate the functions that need to be performed. These functions map
excellently to an existing concept which our main target audience
understands, and which serves as a fantastically easy metaphor -- "It works
just like X." In our target market, everyone knows that program, everyone
uses that program, and everyone is comfortable with that program. The
problem is that we are expanding the target audience, and we expect other
people -- who have never seen this program and probably know jack squat
about it -- to use the new application, as well. The program this system
resembles is difficult to learn and use. In attempting to document the
interface for these new users, we have come to the conclusion that the
interface would map much better to a new concept which will provide
enhanced functionality and be easier for the new user to learn and use. 

Needless to say, this idea is meeting resistance from the existing
audience, who feels that there will be an immense amount of time saved in
training if we just go ahead and use the cryptic and difficult interface
they're used to.

The end result we are faced with here, which I think faces MUD developers
even more than it faces me on this project, is how much importance should
we place on "this is the way we've always done it", and how much should we
place on "this is the way it makes the most sense"? I'm reminded of the
introduction of the Lisa, when the entire computing world laughed at how
stupid Apple seemed to think users were. After all, who needed a picture of
a file folder to know that a directory was meant to contain files, and who
needed a picture to remind them of what a program did? The industry scorned
the Lisa, Apple insisted it was the future, and what do you know...
suddenly here we all are, regardless of our personal preferences, working
on various architectures from XFree86 to NExTStep to BeOS (first Intel
developer release expected next month, *jump* *jump*) to Rhapsody to the
Mac to Windows variants -- which *all* enforce the use of windows and icons
and meeces (plural of mouse: mice are small fuzzy animals, meeces are
computer peripherals) and pointers. Those of us who still feel more
comfortable in front of an 80 by 25 terminal screen running in a glorious
16 colors and an ANSI 3.64 screen interface (okay, VT-220 is acceptable, if
I have to) are considered pretty much dinosaurs. 

The obvious conclusion would be 'ignore the users and do it right', but you
can't *entirely* ignore the users or they just ignore you back (NExT q.v.);
doing it right isn't always enough (AmigaDOS q.v.); and if it doesn't do
the job, they'll go get something that will (can't think of a good example
of this right now). 

Anyone have thoughts on this? It seems to relate rather well to the
graphics/text argument, as well: why text? Well, we've always done it that
way. Graphic MUDs? Of course not! They'd never be hostable on modern
equipment, you'd need to spend years programming them, and everyone would
have to relearn the whole interface! Never mind that in the infancy of
MUDs, this was exactly the sort of situation we faced with respect to large
worlds -- a 50,000 object database would just not work, you couldn't have
more than a dozen or so people online without bogging the CPU, and MUD
commands were different everywhere you went. (Not that I particularly
support the idea of graphic MUDs, but I have different issues around them.
Certainly we could manage a lot more now than we ever could before, but
somewhere along the line someone still has to create it...)


Ah, well. Just more unanswerable questions, I guess. ;)