[Pen-commits] SF.net SVN: pen:[131] doc/menu

[<mdg...@us...>]

Revision: 131
          http://pen.svn.sourceforge.net/pen/?rev=131&view=rev
Author:   mdgeorge
Date:     2008-12-23 18:17:04 +0000 (Tue, 23 Dec 2008)

Log Message:
-----------
Added note about menus

Added Paths:
-----------
    doc/menu

Added: doc/menu
===================================================================
--- doc/menu	                        (rev 0)
+++ doc/menu	2008-12-23 18:17:04 UTC (rev 131)
@@ -0,0 +1,90 @@
+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.
+
+


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.