Re: [mmox] Creating walled gardens considered harmful

[Morgaine <[e-mail]>]

Lisa, I liked your "persona-oriented" angle for a virtual travel/teleport
use case.

It conveys the "user experience" aspect of interop, and so it reminds us
that our rather complex technical goals are all just a means to an end, that
of providing the user with an effective virtual experience.  That is a
social goal, and success requires making it seamless with respect to its
social elements:  in this case, homes, party places, friends, and easy
travel or access.

Individual worlds try to provide this already of course.  Our goal in
interop is to let it happen between worlds, to the greatest extent possible,
by designing a communications infrastructure that can carry the common
social and perceptual elements between the worlds in question.  It won't
always be possible to make the experience seamless, but where it is
possible, we should strive to allow it.

Morgaine.





On Mon, Mar 30, 2009 at 11:57 PM, Lisa Dusseault
<[e-mail]>wrote:

> How about a very persona-oriented (specific) use case...
>
> Lisa has a house in one virtual world, with virtual rooms that she
> frequently hangs out in, that friends might find her at.  One day she
> goes to a party in another virtual world.  She leaves behind a note on
> her virtual door or bulletin board (she has control over the
> presentation, it could be a spinning hovering party hat or a blue
> police phone booth if the home world allows that).  The note has a
> link to the party world because it's an open party.  Lisa's friends
> can now find her, and the more seamless their experience in getting
> from the first virtual world to the second, the more likely they are
> to enjoy the experience, follow through, and see her.
>
> Seamless is a goal, but might involve:
>  - Not launching a new client, if possible, and if it is
>      - A transition that is not too jarring, minimizing reload
> screens, blank screens, dialog boxes, choices
>  - Low time consumption for transport, including time navigating from
> an initial destination to a final destination, if allowed by the
> destination world
>  - Avoiding a registration step if possible, and if it is
>      - Lisa can recognize her friends under the moniker she'd
> normally see them under
>  - Keeping avatar consistency to the extent possible, for recognition
> as well as seamlessness
>
> For bonus points, Lisa can open a door from her house into the party,
> and visitors can get a glimpse of what's beyond, then just walk
> through.
>
> Lisa
>
> On Mon, Mar 30, 2009 at 4:04 PM, Jon Watte <[e-mail]> wrote:
> > Kari Lippert wrote:
> >>
> >> <clearing throat>
> >>
> >> I've been lurking for some time now and reading and trying to understand
> >> the basic user requirement that is driving this work. I have to admit
> this
> >> is as close as I've seen.
> >>
> >> I understand "teleport" (and believe if you can define it well enough,
> >> smart people can make it so) but it leaves me asking why? Why would a
> user
> >> desire to "teleport" from one VWE to another? The answer to this will, I
> >> believe, help you focus on what needs to be included in the definition
> of
> >> what it means to "teleport", and what can be safely set aside for the
> >> moment.
> >>
> >> Kari
> >
> > I think "teleport" is an implementation detail. Does this use case seem
> like
> > a good description of what you consider a "teleport"?
> >
> >
> >     2.1. Friend Invite
> >
> >
> >       2.1.1. Description
> >
> >
> >
> >  1.  User A uses virtual world system A that complies with MMOX
> >      interoperability.
> >  2.  User B uses virtual world system B that complies with MMOX
> >      interoperability.
> >  3.  User A wants user B to visit him/her in system/world A, and gets
> >      a suitable URL from his/her system (A), and sends this to user B
> >      using any transport (mail, IM, integrated communication, carrier
> >      pigeon, ...)
> >  4.  User B clicks/activates this link.
> >  5.  After a brief "loading" screen, user B sees user A in user A's
> >      environment, including a representative form of any simulated
> >      object in that environment.
> >  6.  User B can interact at some level with the objects from user A.
> >  7.  Objects that user B take out of inventory show up in some
> >      representative form for both user A and user B.
> >  8.  User A can interact at some level with any objects that user B
> >      bring out of inventory.
> >
> >
> >
> > Note that I assumed that if you have avatars and objects, you also have
> > text/speech, but that's a poor assumption -- it should go as line 5.5 in
> > this use case, I guess.
> >
> > Sincerely,
> >
> > jw
> >
> > _______________________________________________
> > mmox mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmox
> >
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>