Fwd: [sldev] Second Life User Experience

Richard Nelson richard at lindenlab.com
Wed Mar 14 10:35:09 PDT 2007


> *Doesn't mean it's not a problem. It's bad design to have your state
> (position, whatever) that you've put yourself in changed on you as a side
> effect of some other action.*
>

This is a design tension between never change my camera/avatar orientation and make your avatar respond smoothly to your actions and communicate intent to others around you.  There was no way to bodily communicate your avatar manipulating something behind his back without turning around.  Yes, the current arm point animation is ugly, but it was *much* worse before we added this behavior.

I would consider this more of a problem if it caused your camera to move as well (your camera will pan to the object you selected unless you turn off the automatic camera behavior in preferences).  As it stands, your WASD controls still map to the camera orientation, regardless of what direction your avatar is facing.

> *No. Moving my camera away from where I have it placed is the wrong thing to
> do. Snap or slow. If we're worried about newbies who need the camera to be
> moved for them, fine. But it should be an option I can turn off. Leave my
> camera where I put it. *
>

> *Ok, I'll re-phrase. Anytime my camera or AV moves as a side effect of
> something, and I can't remove the script/option/whatever that is doing it to
> me, it's a bad experience.*
>

For the avatar customization camera motion, you can set "ZoomTime" to 0 in the Debug Settings window.  Unfortunately, you still have to wait for your avatar to turn around, so it's not much help.  The avatar turns to face you for several reasons:

* This puts you in a visible state (I'm busy customizing my avatar) and a known pose for seeing all parts of your avatar.
* Zipping the camera around to your avatar front was dismissed early on as too disorienting.  Any *rapid* (or instantaneous) camera movement out of the users control was considered worse than taking over animation of the avatar.  We have some basic pans and zoom when entering build or customize avatar modes just to frame the task the user is accomplishing for all those new users who can't handle Alt-zoom.

Yes, the transition is too slow...that animation needs to be speed up and probably overlapped with the actual transition into the interface.

> *So there isn't any answer then? See other systems. Gmail uses labeling. I'm
> sure there are others. This is not a unique problem.*
>

Yes, there are lots of ways of tagging, labeling, and so on for managing large inventories.  We've built the initial viewer side architecture for doing attribute-based searches (filters) but we don't have enough useful metadata.  You're right, we need this.  And by no means are we planning on keeping the filter UI as it is.

> *Open your inventory. Click on one of the menus (File, Help, whatever), it
> opens. Should be able to click the header again to close it. I believe this
> was fixed, however, I still see oddness, at least in the inventory window in
> relations to this. *
>

This is a problem with how click events are routed.  Clicking to close an open menu works for the top level menu now because it has a priveleged position in the mouse event handling hierarchy.  Menus on arbitrary floaters (windows) such as the inventory don't yet.  I'd personally like to get rid of window-specific menus, and keep everything at the top, with perhaps some context sensitivity, but that's a big design argument...I mean discussion.

For those who care, the underlying problem is that the global behavior to close menus when you click off of them triggers when you click on the inventory menu header (which is not part of the menu overlay, as it is attached to the underlying inventory window).  This closes all open menus, but does not eat the mouse click.  Afterwards, the menu bar itself handles the mouse click event, notices that the menu attached to it is closed, and helpfully opens it for you again...:)  This isn't right, but I'd like to make sure we either ditch per-window menus or figure out a way to support them as first-class citizens.

R.




More information about the SLDev mailing list