Re: Portals vs Links

Mark Waks ([email protected])
Thu, 4 May 95 19:04:22 EDT


>analagous to an html link.
>
>Portal: i was thinking of a portal as any object that allowed the user to
>look into another space.

While those are perfectly reasonable terms (a "link" is almost exactly
our current WWWAnchor, and a "portal" is a subset of my concept), I
think it introduces a dichotomy that just doesn't match the real world
well. Take your example here:

>this way you are walking down the Street, and you see a store (a static
>object registered to that location on the Street RC/C) you dont know
>whether you are interested in entering that store so you look in the
>window (read Portal) and see what is actually in the store. you see
>something you want (the one of kind widget!) and decide to go in. open
>the door (read Link) and enter (register yourself as a dynamic object
>with the Store RC/C and simultaneously unreg with the Street RC/C).
>Shopping and window shopping are allowed, voila!

The problem is that, in the real world, there is no separation of
"what you can see" and "what's physically transportable into". (Modulo
closed windows and such, of course, but those are readily modelable
with even the technology we've already got.) It seems unintuitive and
jarring to me that there is any real difference. A door should be both
a "portal" (you can see through it) and a "link" (you can walk through
it). Moreover, the link process should, in theory, be *seamless*. Which
is the whole point of the portal idea, and why I get a little
frustrated when people say, "Oh, just use transporter tubes" or
something like that. That isn't how the real world *feels*. The real
world is *seamless* -- and so should cyberspace be, even if it *is*
actually n-dimensional.

Also, I note that a *lot* of people here are making some *very* casual
assumptions about how people "register" in cyberspace. In particular,
there's an assumption all over the place that if you enter a room,
you are "registering" with a server attached specifically to that
room.

I think this is an *extraordinarily* bad assumption. It's the standard
MUD model, which is no doubt why everyone's assuming it. But look at
the *real* numbers of the Web. We're not talking hundreds of people --
we're talking *millions*. Popular sites may have *tens of thousands*
of people moving in them at once, particularly if they've just been
"noticed". MUD assumptions break down in this environment, very badly.

As I've been saying over and over -- the key to remember is that what
makes a MUD special is the *social* aspect, the *people*. So define
a MUD to be a group of *people*, not a *place*. Use the "static" Web
as the database, and have a MUD dealing with smallish numbers of
people at a time. You *can* have a MUD customized to work with a
particular set of places, but that's limiting -- instead, have it
work with the whole of Cyberspace. Break the hard part, the interactions
of the people, down into manageable chunks of a few hundred per MUD
server, grouped however they like, not "geographically".

-- Justin
Determined to keep poking holes in the
assumptions that aren't going to work
well...

Random Quote du Jour:

"Just Say NO to Sushi"
-- Slogan of the Suicide Squid National Tour