Likely want to be consistent: tab/enter in text vs. code cells

[scottnonnenberg]

[doolittle]

In code cells, enter executes the current cell and moves you into the next cell. In a text cell, enter creates a new line. Shift + enter in a code cell creates a new line.

In both, tabbing creates a tab.

We need to determine a sensible set of rules for managing command keys and flow between cells.

I often push enter in the middle of a code cell meaning to create a new line (i.e. another comment line to describe what I'm doing in the code). Instead of creating a new line, the notebook executes the cell and places my cursor in the next cell. If I try to use my keyboard to navigate up to the previous cell, I instead lose the content in my current cell (because up/down changes the current cell's contents to the previous/last in history, not letting you navigate). Now I'm confused and frustrated. I need to use my mouse to click back into the previous cell.

[usarid]

Agreed it bears thinking, but let's still keep top of mind the desire to type in a line of code and hit enter to run it. At least for new users, anything else (like command-enter) to execute the current cell will be non-obvious, hence a steep price to pay. I'm not ruling it out, just wanting us to keep that top of mind. And I've never been fond of any kind if "expert modes" that have different behaviors for different users/modes.

On Dec 7, 2013, at 11:25 AM, Brad Bouse [email protected] wrote:

In code cells, enter executes the current cell and moves you into the next cell. In a text cell, enter creates a new line. Shift + enter in a code cell creates a new line.

In both, tabbing creates a tab.

We need to determine a sensible set of rules for managing command keys and flow between cells.

I often push enter in the middle of a code cell meaning to create a new line (i.e. another comment line to describe what I'm doing in the code). Instead of creating a new line, the notebook executes the cell and places my cursor in the next cell. If I try to use my keyboard to navigate up to the previous cell, I instead lose the content in my current cell (because up/down changes the current cell's contents to the previous/last in history, not letting you navigate). Now I'm confused and frustrated. I need to use my mouse to click back into the previous cell.

— Reply to this email directly or view it on GitHubhttps://github.com/mulesoft/api-notebook/issues/187#issuecomment-30062616 .

[doolittle]

What bothers me about "enter" executing the cell is how expensive it is to do so accidentally. We shift the user's focus to the next cell which--if the inspector returns a lot of text or the next cell is long--can be a lot of vertical pixels away from what the user was just looking at. That's confusing and doesn't let the user examine the contents of the inspector.

So, let's make those accidental "enters" cheaper.

How about this logic:

• User pushes 'enter' in a code cell we execute cell but do no move cursor. We provide visual indication that the cell executed (async requests show a spinner; for sync cells we could highlight the inspector upon execution then fade it back to normal) so the user realizes something is happening when s/he pushes enter.
• Up/down navigates between cells instead of changing contents of cell (in multi-line cells, up/down would navigate within cell first. pressing up on the first line of the cell would go to the previous cell, and down on the last line takes you to the next cell). If anyone finds the changing-cell-contents-with-arrow-keys-functionality useful, we can make it available with a modifier key (i.e. shift + up). Allowing the user to use up/down to change cells makes it easier to traverse the notebook with the keyboard.
• Enter works normally in a text cell.

[usarid]

But note that this makes the typical flow not work: type in code, hit enter to run, type in more code, hit enter to run. You have to use a down-arrow in the middle of that flow, which I think nobody would guess.

Can you point out the notebook where you’re experiencing the annoying behavior, or make a small screencast, so we can feel it too? I’ve found the Screencast-o-Matic app for Mac useful.

On Dec 7, 2013, at 1:05 PM, Brad Bouse [email protected] wrote:

What bothers me about "enter" executing the cell is how expensive it is to do so accidentally. We shift the user's focus to the next cell which--if the inspector returns a lot of text or the next cell is long, can be a lot of vertical pixels away from what the user was just looking at. That's confusing and doesn't let the user examine the contents of the inspector.

So, let's make those accidental "enters" cheaper.

How about this logic:

User pushes 'enter' in a code cell we execute cell but do no move cursor. We provide visual indication that the cell executed (async requests show a spinner; for sync cells we could highlight the inspector upon execution then fade it back to normal) so the user realizes something is happening when s/he pushes enter. Up/down navigates between cells instead of changing contents of cell (in multi-line cells, up/down would navigate within cell first. pressing up on the first line of the cell would go to the previous cell, and down on the last line takes you to the next cell). If anyone finds the changing-cell-contents-with-arrow-keys-functionality useful, we can make it available with a modifier key (i.e. shift + up). Allowing the user to use up/down to changes cells makes it easier to traverse the notebook with the keyboard. Enter works normally in a text cell. — Reply to this email directly or view it on GitHub.