Hand Vs Pointer

"Hand" is the term given to the object that lets users pick up and drop other objects in the game BlackAndWhite, an important example of good interaction design. A hand is significantly different from a mere mouse pointer; it's a full-fledged direct-manipulable stateful object controlled by a combination of the mouse and keyboard.

A mouse pointer is a stateless reference to the mouse, the low-level tool of the naive programmers. A hand is a stateful object controlled by the mouse, the high-level tool of the user! As long as people think in terms of pointers, it's impossible to have the user actually pick up objects and hold them in their hand. This is why dragging and dropping requires keeping the mouse button down; because it's not a hand.

A hand is principally a stack of picked up objects (selections).

We could pick up 'tools' as a basis for managing context options. In a game, we might provide options based on the player character's inventory - e.g. if we have the key, we can open the door. This can apply quite directly to the notion of hand vs. pointer - a developer or user can pick up various tools, and apply them based on other held objects and the pointed target:

  def buildMenu(target,hand):
    contextMenu = new Menu
    foreach t:Tool in hand
      contextMenu.add(t.getOptions(target,hand))
    return contextMenu

Existing programs often work in a similar fashion (e.g. pick up different brushes for a paint program). Tools become a way to 'reprogram' the hand object that regular users can understand and power users can easily augment. I imagine we could organize a hand by use of 'bags' and 'toolboxes' and other notions. Options such as 'put the tool down' might appear when clicking on a shelf.

Besides tools, hands might also carry 'abstract' artifacts such as tasks and roles.

Disagree that B&W's hand is an example of good interaction design. It's used for several tasks that real hands are not used for, so is unintuitive in those ways, and in addition it is very clumsy at doing some tasks.

Nearly all movement is done with the hand by clicking and dragging the ground in relation to the camera. If the camera is pointed straight forward, parallel to the ground, then it can be difficult to make fine adjustments to position; attempts to do so often launch the camera forward or backward at high speed. This is because the speed of motion is calculated based on the distance on the ground between the hand and the position directly below the camera. When the camera is at a shallow angle, a small screen region corresponds to a large distance.
Aiming the camera can be done by clicking and dragging near the edge of the screen. It's very slow to position the mouse there every time a turn is desired, so most people use the shortcut of a simultaneous left and right click plus drag to aim (or maybe it's control-click and drag. I forget.) The problem is, any attempt to use a normal click and drag to slide the camera around when the hand is near the edge of the screen leads to aiming instead.
Inside the temple, the only enclosed space in the game, the function of a normal click-and-drag changes to be "aim the camera". Not only is this inconsistent and counter-intuitive (who turns their body by twisting off of a wall?) but it's difficult to use. The algorithm to decide how fast the camera turns is different from the one used in the normal mode. It now requires multiple cycles of picking up, clicking, and dragging the mouse over the entire mousepad to accomplish a full rotation. If any one of those clicks is on a wall surface not roughly perpendicular to the camera, then the hand graphic does some crazy spins and the camera rotation is jittery and unpredictable.

: I agree this is a major problem.

It's not all bad; for throwing objects around and petting or slapping the creature, the hand is very natural feeling and effective.

Okay, first of all "natural" and "intuitive" mean absolutely nothing, either in human-computer interaction or in interface design. So whether you use them as compliments or criticism, well you shouldn't use them at all.

Second, one of my other favourite games (StarCraft?) actually has serious and fundamental interaction design problems. Like the fact that despite having a build menu of only 9 items, in a square grid no less!, which could be entirely controlled by the 9 keys on the left-hand side of the keyboard (QWE-ZXC) plus ALT to access the advanced build menu, the keyboard shortcuts are scattered all over the keyboard in completely unpredictable ways. Starcraft basically makes it completely impossible to play in a straightfoward or ergonomic manner. Compared to that, B&W's problems are piddling details.

Now, commenting on your point about translations, a much bigger problem is that zooming is controlled in the opposite way from other motions (pushing against the ground instead of pulling on it), IIRC. This is a bigger problem because it breaks the basic mental model, as opposed to a mere algorithmic / optimization detail like how much movement is calculated.

Moving on to your point about rotations at the edge of the screen, overloading the edges of the screen with rotations is bad for several reasons:

1. it produces a discontinuous input map
2a. it makes the rotations not as easily accessible as the translations (which you barely allude to)
2b. it makes the rotations second-class transformations

the fact that it blocks some tiny fraction of possible translations at the edges means literally nothing compared to the fundamental interaction problems above.

And while we're at it, I think you should get a better appreciation of good vs bad InteractionDesign.

Nobody I know ever used the edges of the screen to rotate, except by accident when they were trying to do a translation.

Re: B&W "Nearly all movement is done with the hand by clicking and dragging the ground in relation to the camera."

Hmmm... I'm just trying to visualize watching a god move around by grabbing the ground in front of them and pulling themselves forward. What's up? Don't gods have legs?!?

Also re this... B&W has a whole load of interface design issues that make it seriously painful for me to play, or did at least until I figured out the keyboard shortcuts, half of which are undocumented in the program material. I have NEVER used the hand to move; I always use the arrow keys.

Don't gods have legs?!?

If the Akashic record, very nearly every NearDeathExperience, Shamanic vision, and even the Holy Bible is to be believed, the answer is NO. Gods and angels tend to be beings either constructed of light or other incorporeal "stuff." Their ability to affect the material world directly seems severely compromised, being limited to bumps, strange noises, and sudden cold spells. However, their psi capabilities are world reknowned (as anyone who is possessed can personally attest to ... if they want to). Somehow, that movement in a game of gods is made difficult when dealing with the material plane seems strangely fitting.

Us cockroaches are offended by limiting the icons to human appendages.

CategoryInteractionDesign CategoryUserInterface