FreeEMS Issues - Tunix
View Issue Details
0000466TunixGeneral Featurespublic2011-12-05 17:482012-04-07 00:02
0000466: Consider some changes to the table manipulation key map
I noticed while working with you on 0000444 that the up and down arrow keys work intuitively to navigate between cells, however left and right do not adhere to this standard regime and move the cursor within a cell. I don't like this and I'm not alone. I suspect that it's this way due to the widget type that you construct these tables from, however if not, and it is possible to change, please consider changing it.

I spoke with a friend who tunes professionally every day and he had this to say on the matter:

him: Have the usual small/large increment/decrement keystrokes... CTRL+up and CTRL+down for small, etc. But have another keystroke open up an edit box
The edit box can + or - by a percentage to one or more highlighted cells, offset by a + or - fixed value, or fill with any single value of your choosing.
me: so arrows do what? navigate around the cells?
him: yes, that's pretty universal, intuitive to the n00b and expected by the veterans. Have the cursor navigate too

I'm not sold on any of the other aspects, only the nav = arrow keys one. I'm going to link this issue to Ben Fenner who I know will have a strong opinion on the matter and I'm hoping you can document how it works right now in this issue for future reference. I'm guessing that it's in the tooltips, but if you could copy paste that here with your comments/reply, that would be good.

Don't close it, leave it open for discussion, please.
No tags attached.
related to 0000467assigned ToxicGumbo Page Up/Down Events Not Consumed When Values Railed 

2011-12-05 19:26   
(edited on: 2011-12-05 19:37)
The tables are a pile of text entries so I'm limited by its functionality, L/R arrows navigate WITHIN the cell to place the cursor in an appropriate place, by using the arrows to switch cells it makes it impossible to edit PART of the text (i.e. change 0.83 to 0.82), I can probably make it jump to the next cell when the cursor is already at the LIMITS of the existing cells, but there's also VI navigation and TAB navigation as well

TAB and Shift+Tab will give you left and right, as well as VI navigation (h==left, j=down, k=up, l = right) which does what you want and doesn't conflict with the arrow keys.

+/q -/w increment/decrement by small amounts, Pgup/Pgdn by large amounts, click then shift+click into other cells grabs cells for group manipulation, i.e. it'll ungrey the box just below the table to allow things like math expression, +,-,/,*.

2011-12-05 19:38   
You probably am not aware of the VI navigation mode....
2011-12-06 16:26   
I was aware that there was an alternative, but it's not the natural default that anyone would assume. For example, when I use the letters, I assume an ijkl layout for arrow movement. Both are common enough.

I was thinking about this just now and what I realised is that editing a cell to a specific value is not actually a common operation in the field. What you want to do is move around quickly and inc/dec small/large cells until things run right. Only when fine tuning later would you do that, and even then, you'd want access to the full precision value, not a shrunk for visuals version. So here is what I propose:

 - Existing VI scheme plus:
 - Arrows for nav (and mouse, of course)
 - Something for for small inc/dec (perhaps ctrl up/down (to prevent having to move your hand around) as well as -/= (just checked, you don't use plus, you use the plus _key_))
 - Something for large inc/dec (perhaps ctrl -/= and/or ctrl-alt or ctrl-shift up/down, as well as the pg up/down keys?)
 - A key binding to enter the group edit mode as well as ctrl click
 - A way to select an area of cells rather than one-by-one
 - A way to enter edit mode in a cell to allow convenient in-place editing of a single cell to function with natural arrow nav

Please, no flames, yet! :-p Assigning to Ben for comment.
2011-12-06 16:29   
Additional comment, it's fine to have multiple sets of controls that do the same thing in this view of data, provided that they don't overlap and are all complete and reasonable sets. Having stuff that is mouse only is bad considering bumpy in car use and touch pads.
2011-12-06 17:12   
(edited on: 2011-12-06 17:16)
You're correct in assuming my opinions are strong on this. =D

I love TAB and Shift+TAB for move focus one cell to the right and one cell to the left respectively. Good job on that. The analog for up and down is ENTER and Shift+ENTER (both keyboard and pad ENTER). Those should work too if they do not.

Arrow keys IMO should also navigate between cells identical to the TAB and ENTER above.

Moving within a cell should only take place once a cell is active for editing, not just focused/selected. This means a double click on the cell or pressing F2 (Windows) (or Control+U apparently on the Mac?). Once a cell is active for editing, arrow keys traverse the text inside the cell and cannot move focus from that cell until ENTER/TAB is used to move focus to a new cell, or the mouse pointer is clicked on a new cell to move focus there.

This is expected spreadsheet behavior, and IMO expected behavior of any cell-driven software. This is (mostly) how AEM-Tuner behaves as well.

Obviously if you're not editing a cell, and it is merely selected, you can use other shortcuts to fine/coarse adjust the cell value.

2011-12-06 17:21   
Well articulated, Ben! Good spotting on the enter/shift-enter thing, though I bet dave won't like that as currently enter commits the change, however enter could still do that once in edit mode for a cell is activated, as you so succinctly put it. Glad you agree about the arrow keys. Back to Dave for more deliberation :-)
2011-12-06 17:32   
(edited on: 2011-12-06 17:36)
Moving focus to any other cell (via ENTER/TAB, MouseClick, etc.) should commit the change. This is a small detail not many seem to get right.

The only thing that should void the commit is pressing Esc. Esc should return the value to the previously committed value, exit from cell edit mode, but maintain selection/focus on the cell.

2011-12-06 17:36   
You mean when editing, right? If incrementing or decrementing clearly it should be sent to volatile device memory immediately.
2011-12-06 17:38   
If you're not in edit-mode on a cell, and you're simply incrementing/decrementing with shortcuts, then yes, those changes need to be committed right away (without additional action).
2011-12-06 17:43   
If the text is red (being edited) its NOT sent, changing FOCUS or hitting enter sends it, hitting escape reverts to original value.

small increment is q/w +/-, large increment is pgup/pgdn

so you can navigate and edit all cells with keyboard, q/w for inc/dec, and hjkl for nav.

Will look into issues regarding focus/shift via enter, but it may be hard/impossible to acheive reliably due to enter triggering a different (activate) event, vs a generic key event.
2011-12-06 23:01   
L/R/Up/Down arrows added, however this'll break the ability to move hte cursor WITHIN a cell for the time being (perhaps forever). when it jumps out of the cell it sends the value as well...

in hash: 73607d2ec665227756da331c155d7f8d620a4732