I wonder what might be a good way to redefine the mapping of the nav keys, so as to incorporate the functionality you mentioned...? Currently, 'Select' maps to "OK" (done with the current form), and 'Left' maps to "Cancel" ('Left' seems to make sense for backing out of the current context ... in Folders, it lets you navigate closer to the root, for example).
One approach might be to forego a mapping for "Cancel", map 'Left' to "OK", have 'Select' switch from normal mode to navigating the cursor mode (and then back when done). I'm not sure if this would be a better approach overall (i.e. is "OK" a better mapping for the 'Select' button?) Any thoughts?
-- Stephen
Can't this all be dependent on whether or not the user is in Edit mode or not? When in Edit mode, and there's an active (blinking) cursor in the note field because the user touched the note field with their finger or stylus, it seems logical that the Nav key should now control the cursor.
What's missing here is a way for the user to navigate to the Ok New Cancel Delete buttons, etc. A typical way to do this with other applications is Fn-Down to get to the bottom row of buttons and Fn--Up to get to the top row of buttons. Some apps use Fn-Space to get to the top row of buttons. Whatever you use, it would highlight each button with a blue border, and then at that point you use Right and Left to navigate the buttons.
I also notice that when in List view, I have to hit the Center button to active the Nav key for scroling a list of notes, otherwise the Nav key doesn't work there. If the borders were blue, then I'd know I needed to hit the Center key to activate the Nav key within that list.