[MUD-Dev] The morality of logfiles [was 'Wild west']

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Thu Jan 8 01:20:09 CET 1998


JC Lawrence <claw at under.Eng.Sun.COM> wrote:
>On Wed, 31 Dec 1997 10:10:38 PST8PDT Ola wrote:
>> "Jon A. Lambert" <jlsysinc at ix.netcom.com> wrote:
>
>>> I think there is greater _danger_ (perhaps not a good word choice)
>>> of personal information being used in an offensive, vindictive or
>>> harassing nature by another player rather than a benevolent, just
>>> and dictatorial big-brother administrator, like myself. :P
>
>> The difference is a huge one.  Players are on the same level.  You
>> see other players, you are aware.  (Depending on the system design,
>> I don't accept bad designs..)
>
>Which would seem to make cameras, recorders, and other remote
>surveillance/fly-on-the-wall objects "bad design"?

Depends.  I only care about how things are used and perceived from the
individual user's POV.  If you want some principle pertaining to this
particular problem: Make it visible.  Familiarity.  Use the language
(in the broadest sense) of the user. (Etc)

The actual logging/monitoring is however a moral/ethical/philosophical
issue.

>  Getting back to the point, the result is that unless a given
>character investigates the ownership state of every body in his
>environment he can not be sure who is watching what.  This can get
>especially nasty given that names are assigned to bodies no matter who
>owns them...

Your design is rather weird in the first place.  Only testing would
give an idea of how people would react to it. Besides, a mere abstract
description is not neccessarily enough to evaluate the design.  The
entire context matters.

>The general problem I'm having is that you are using an unstated and I
>suspect largely undefined set of criteria to define "bad design".

I can't go in details, can I?  I don't have time, because "I am
working on it".  I could put up references on a website, but how many
would order the litterature from their bookstore?  What you get from
books is only the framework anyway.

I also want to point out that thinking in terms of definitions as you
imply is not a very good idea.  The better framework, the more
techniques, the more you reflect over what makes artifacts work and
fail in everyday life will help you out in pinpointing bad design
choices.  I am a novice at this, therefore I have mostly the
principles.  I can use them when people describe designs here, but
they won't help me in more vague situations. (After a design has
passed heuristic methods and my base of experience).  Sellers is
having a real advantage here (I assume) he has the framework (probably
different from mine, but still) and has been able to digest
experiences in his "online work".  The real advantage is of course
that framework+experience hopefully will enable you to reach better
designs faster.

>I
>expect that we'd have a much easier time in this thread if we knew and
>could evauluate the rules by which the judgements are made.

The problem is, one need background info.  The first chapter of
Normans "The design of everyday things" is a good startingpoing
according to most HCI books.  But other types of background info is
spread out on research articles, different books (from different
fields) and even lectures... :(

Design (human factors) is far from easy, even for rather simple
problems.  Designing a good interface for VCR is not an easy task.

Generally a good design is a design that doesn't work against the
human nature, does what it should do and is accepted by the user.
A morally/ethically acceptable design however...

Some attitudes: Give the user the initiative. Empower the user.  Let
the user shift focus. Take advantage of human intuition (prior
knowledge).  Makes effects/state visible! (unless it is hide-and-seek
game of course). Etc.

There are lots of techniques for evaluating designs, and I guess that
is what it usually boils down to. It is difficult to design from a
book (you have to use intuition, which means you have to internalize
principles), but you can use a technique from a book to evaluate a
design.

>Too often these things at some level fall into the, "I don't like it.
>I don't know exactly why I don't like it, but I don't like it and
>therefore it is a Bad Thing".  Such views are impossible to debate.

Well, my "I don't like it" is largly based on current paradigms. Which
are based on practioners/researchers experiences/research.  This goes
for my generic statements.  I am of course not entirely objective, the
paradigms aren't entirely objective! That does however not make a bad
design good.  It is rather difficult to end up at a really good
design, it is rather easy to pinpoint flaws.

When it comes to role-acting, then everything I say is "I like it" or
"I don't like it" in the most subjective sense.  Same, when it comes
to the actual setting.

>The usual challenge is to reduce the definition to a set of base
>principles which are supported by a stated set of (hopefully) atomic
>and logically consistent assumptions.

I'll type in Nielsens checklist one day.

Ola.



More information about the mud-dev-archive mailing list