[Pen-devel] more pie
Brought to you by:
mdgeorge
From: Michael G. <mdg...@cs...> - 2008-12-23 18:16:02
|
Hello all, Val and I had a discussion this weekend about the menus, and I wanted to share what we came up with to get some feedback. Here's most of it: 1. To invoke the menu, user right-clicks anywhere on an object 2a. the cursor is warped to the center of the object - we move the cursor because there are two logical places for the menu to appear. We want it to appear around the center of the selected object so that we can show the object without it obstructing the menu. We want it to appear where the cursor is so that the same gesture (i.e. right-click move up and right) always selects the same action. 2b. the menu expands in an animated way - however the menu is completely responsive during the animation 2c. if the menu is off the edge then the screen slides to make it visible - the cursor slides with the menu so that it stays in the same logical spot. Again, this supports the correspondence between gestures and actions - something amusing should be in the background 3. The appearance of the menu - something like this: \ <-> / \ / foo \ / other \ / action ------ obj ------- toggle / \ set state / \ target / X \ / \ - objects obscured by the menu should be either faded out, drawn with dashed lines (it's not clear the best way to do this), or both - the object in the center is drawn normally, above the menu - the entries themselves, and their positions and sizes are specified by the part. I was thinking of an api where the designer specifies, for each entry, an action, an image, and a weight. The weight determines the relative size of that entry. For example, to get the following shape: | | --- --- / \ / \ they could specify weights of 3, 3, 2, 2, and 2 - I think we should have conventions for where things "should" go though, for example rotation is always on top, delete is always on the bottom or something. Again, this helps muscle memory - One thing I'm a little worried about is that the menus have to be different for the editor and the game. - It's also not clear what to do with large objects (e.g. a plank that spans half the screen). - finally, it's not clear whether the inner and/or outer radii of the menu should be fixed, specified by the designer, or computed 4. Interaction with the menu - there's no buttons that the user has to hit exactly. Anywhere they click is in one of the "wedges". I think this will aid usability - as they move the cursor around the selected action is highlighted (e.g. drawn in blue). We might make a little clicky sound when they cross the border - Left click selects an action from the menu, right click dismisses the menu - Some actions (e.g. rotation) may change the shape of an object, possibly causing it to intersect with another object. We will always show the black object where the user has positioned it, but we will also have a faded object underneath that shows the closest legal position. When the menu is dismissed, the gray object will be the actual one. - - - - - - - - - - - - - - - | (Obstruction) +---+ | - - - - - - - - | | - - - - | | / | | \ | | / | o | / | b | (gray object) | j | / | e | | c | / | t | / | | | | / | | | | / /| | now that I think of it, this might be a good way to do the collision avoiding dragging as well. That's enough for now. I've checked this in in docs/menu as well. Thoughts? --Mike |