[MUD-Dev] A new MUD-standard

[J C Lawrence]

On Tue, 20 Feb 2001 20:14:07 -0800 
Ben Chambers <bjchambers at phoenixdsl.com> wrote:

> Web management is nice, but there are better alternatives.  

Ben, you really need to step back and do some background analysis
here, both on the problem definition you are trying to solve, as
well as the relevant tools for solving that problem.  You seem to be
running about with a set of unsupported assumptions and not
realising that those assumptions are unsupported, and are not only
likely wrong, but in serious need of examination to further
understand why they are wrong.

To determine that statement above you first need to:

  a) Define the problem that the tool or interface is to solve.

  b) Determing the scoping of that problem set, and specifically
  what problems the tool or interface is not required to solve, as
  well as the list of "nice to haves".

  c) From the above build a requirements specification.

  d) Do a discovery process to determine what may possibly address
  those requirements.

  e) Analyse the results of your discovery process against your
  requirements, and evaluate how each found item applies and to what
  extent.

  f) On the basis of those findings design a solution.

  g) Re-evaluate the solution against all the steps from #a - #e.

  h) On the basis of that re-evaluation decide whether to repeat
  from #d or not and look for a better solution.

  i) Re-do steps #d, #e, #f, and #g assuming a web based tool
  instead (assuming that's not what you already picked).

  j) Compare the two resulting tool's effectiveness in addressing
  what you found in step #c,

When you get down to it this is standard engineering process.  While
most people don't formalise it as I have above (and that phrasing is
a quick jot -- I've never written it down before), and many people
have slightly different prhasings they use for the steps or their
explanations, and while its usually abbreviated (familiarity breeds
facility as well as contempt), __EVERY__ task follows that course,
be it building bridges, writing "Hello World!"  programs, designing
MUD servers, designing new protocols, or figuring out how to clean
that nasty stain out of your carpet.

Heck, to an extent even writing this reply followed that process.

> ... client that displays the same information is better, because
> it allows more functionality.  

Is functionality more important that user familiarity?  How about
simplicity of interface?  User training?  Extensibility?
Maintenance costs?  Ability to leverage and extend for other related
processes and tasks?  

"It does more" is an incompleat answer.  It doesn't adress
suitability for the task, which is mostly defined by soft factors.
A Formula 1 race car does more, in the sense of going faster, than
my Jetta.  An 18 wheeler big rig does more in terms of carrying
capacity and distance between refuels.  I wouldn't recommend either
for taking the kids to and from school.

> The web is limited by the design of the html and the other
> standards...

Every interface has limits.  That is not the problem.  The problem
are the constraints those interfaces enforce, the work flow and data
flow patterns they build (which result in models), and how those
things in turn define and constrict your problem solution (which is
why you do the re-evaluate and re-do steps above).  

There are no perfect tools.  I happen to think that Emacs is a
damned fine editor and tool.  My views on vi, let alone castrati
like the various commercial development IDEs are not suitable for
mixed company, let alone this list.  Those views are based on my
having followed the above process in considerable detail over a
course of years (I also revisit the area every year or so).

Others obviously vary.  They like vi.  Heck, even Bill Korn likes
vi.  Some people even assert that they like such pathetic idiocies
(I hope my bias isn't showing) as the Visual Studio/C++ development
environment.  It would seem that they have a different problem to
solve, a different scoping, different requirements, a different
solution definition, etc.

> ... which needless to say, weren't DESIGNED for MUDs.  Using a
> language designed for MUDs makes much more sense.

In my toolbox I have a set of adjustable spanners, a set of socket
wrenches in both metric and english sizes, and a set of open-ended
and ring spanners in metric and english, as well as various sizes of
mole grips, pliers, and other gripping tools.  In an ideal world I'd
use either the socket wrenches or the ring spanners all the time.
They do the best job delivering the best torque to the fastenings
each time with the least chance of slippage or buggering or marring
the fasteners.  The truth however is that most of the time I use
adjustable spanners and the various pliers.  They are faster,
easier, simpler, and require less consideration on my part for tasks
which don't require that level of tool quality to get the desired
result (ie get the damned nut/screw off and I can always replace it
if I need to).

Yet the ring spanners are the tool designed for and purpose built
the job, unique to that fastener size -- but I rarely use them.

Custom is not necessarily better.  You need to define your problem
*and* its various requirements and so forth before you can properly
evaluate "better".

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev