Skip to main content

Default user controls

7 replies [Last post]
paulby
Offline
Joined: 2003-06-13
Points: 0

There are so many styles/configurations of user controls that we will never please all the users all the time so we must have a configurable input/control system. However we also need a default that is intuitive to both gamers and office users. During various demos it's already been fun trying to guess what a new user will do when they approach Wonderland for the first time. Will they go straight for the cursor keys, or awsd and the mouse ?

This system is designed for users to interact with desktop apps, in world, so the control system has the added constraint of dealing with that.

So I spent the weekend looking at a few new games (research can be tough, but someone has to do it!) and I have a proposal for the default controls.

1) JUST KEYS : Cursor keys and awsd move the user forward backward and turn left/right
2) KEYS and MOUSE : Dragging the mouse with the right button pressed causes the avatar to turn left/right and look up/down. While the mouse button is pressed the left/right and A D keys cause the user to step (strafe) left/right (instead of turn).

So pressing the right mouse button effectively switches the input mode. I found it to be very natural and the really nice thing, for the non gamers the default mode is perfect.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
nicoley
Offline
Joined: 2007-02-12
Points: 0

Paul,

This scheme sounds good. Can you explain a bit more about how this works when you want to interact with an object in the world? For example, how does the mouse and keyboard behave when you want to edit an application or press some virtual control?

Nicole.

paulby
Offline
Joined: 2003-06-13
Points: 0

When no mouse buttons are pressed the mouse controls the cursor so users can point at and select objects in the world. If they want to drag something in world, like move a window then they will have to enter a different mode. Actually this is true for any application interaction, we need to define how the user moves between avatar control and application interaction. The window system metaphor of click to type (or click for focus) seems a reasonable place to start. Do you have any other ideas on how this could be achieved ?

Nicole Yankelovich

Click for focus seems reasonable, if you are primarily navigating. It
might be irritating, however, if you're doing a lot of window
manipulation. If we imagine the day when people use Wonderland for
their every day real work, I think it would annoying to have to click
before every drag operation. What happens if you press and drag by
accident before clicking? I assume this does some sort of avatar
navigation? For people who are doing lots of window manipulation,
would it be possible to turn off the mouse-style navigation so that
dragging would work as it does on a desktop?

Nicole.

On Apr 9, 2007, at 4:35 PM, wonderland@javadesktop.org wrote:

> When no mouse buttons are pressed the mouse controls the cursor so
> users can point at and select objects in the world. If they want to
> drag something in world, like move a window then they will have to
> enter a different mode. Actually this is true for any application
> interaction, we need to define how the user moves between avatar
> control and application interaction. The window system metaphor of
> click to type (or click for focus) seems a reasonable place to
> start. Do you have any other ideas on how this could be achieved ?
> [Message sent by forum member 'paulby' (paulby)]
>
> http://forums.java.net/jive/thread.jspa?messageID=211586

paulby
Offline
Joined: 2003-06-13
Points: 0

Yes I agree. The problem is I think both use cases are diametrically opposed. The only solution I can think of is the introduction of more 'modes' where one or other of the use cases takes precedence.

The best solution would be to introduce a new input device for navigation, that would free up the mouse and keyboard for application work. We can use the jinput work for this that supports various devices. However it can't be our primary interface as requiring every user to add new hardware to a machine would be a burden.

Experimentation in world once we get the first desktop apps will help significantly in refining the defaults. Hopefully we will get lots of user feedback ;-)

Kirk Turner

Two thoughts that I had relating to mouse/key movements - I initially
changed the key bindings to be more like I'm used to from a gaming
perspective - two things I realised here:
1. The key setup I'm used to comes from RPG style games - where you
are actually controlling an avatar while watching the back of their
head. In this case being able to turn your avatar without necessarily
changing the field of view is important primarily for interaction
purposes. I'm not sure if this fits necessarily within the design
constraints of wonderland, but I can see one potential application
whereby you want to turn your avatar to address others at a conference
table (therefore affecting elements of the spatial sound), while
maintaining a view of the a whiteboard or such. This would however
potentially affect the immersive nature of wonderland - being that you
could theoretically have the 'eyes in the back of the head'

2. My original dislike for the default controls in wonderland was the
mouse look so I changed the control to be based on a right mouse
button drag. The potential issue of integrating a mouse look with
window control is as you stated - it could be burdensome if modes have
to be changed. So I went back and had that hard task of playing games
where I liked the controls (like Paul) and what I realised is - most
of the actions performed there didn't conflict because there is a
difference between mouse clicks and mouse drags. From my own usage I
haven't seen an application for right mouse button drags in a desktop
environment - the only time I can think of using it is when I've
wanted to abort a right click on a particular target and not released
until off the said target. I also played around with this in
wonderland - clicking on the only interactive thing at the moment -
the task bar, and for me it improved the use - but I'll admit that is
limited and when there is desktop apps it could be a different issue.

Final thought regarding modes of control - I'm not opposed to them as
long as it is simple to change between them (F1 toggle is fine for
example) - but I'm a long time VI user - I think the issue we might
have is again about conflicts between 'system' functions and
'application' functions, so choice would have to be carefully made (or
letting the user choose ultimately).

Kirk

paulby
Offline
Joined: 2003-06-13
Points: 0

We do intend to support both 1st and 3rd person camera views so your points are well taken. We also want to support modes where the camera is detached from the avatar. In some cases this will result in the 'ears' moving with the camera.

I've integrated the changes that I described above, so please give it a try and tell me what you think. In particular the switch between left/right keys turning and stepping.

Kirk Turner

> We do intend to support both 1st and 3rd person camera views so your points are well taken. We also want to support modes where the camera is detached from the avatar. In some cases this will result in the 'ears' moving with the camera.

Woot - we can all share in an 'out of body experience' then :)

> I've integrated the changes that I described above, so please give it a try and tell me what you think. In particular the switch between left/right keys turning and stepping.

I've had a quick play. For me it isn't as intuitive but I'm used to
changing keys to differentiate between turn and strafe (I would use a
QWEASD setup where QE strafe and AD turn - vertical movement is
normally either mouse controlled, or is only jumping - which is usally
space). That said I think it isn't a big jump to adapt to such a
change. I'm not sure of the advantages of it thought. I'd be
interested to hear from someone without gaming experience as to what
is natural for them. An interesting thought that just occurred is that
perhaps a shift one to the right ( ESDF) would actually be better for
integration with a desktop, given that this would position the users
keys on the 'home' key F with the left hand.

However to help us to experiment with this I've committed a first cut
at an input configuration tool. If you go to Tools -> Config Input
you'll get a JFrame to change the input. Just double click the primary
or secondary control and enter the key. As I noted in the cvs commit
it'll need revising (not to mention a clean up of some ugly code) as
we play with these things - one thing I'll look at adding is the
ability to change the mouseButtonMap that Paul has just added. Changes
also aren't permanent yet, so on a restart of the client they'll be
lost, and 'Defaults' is only a quasi default - returning to the last
saved state.

Kirk