Interactive Help v0.5
Chosen Approach: keyboard shortcut bar & formatting bar, at bottom of the screen.
Because
When paired with a good WelcomeTree, might be all we need to explain gingko’s theory and practice.
As Elena said once “it’s simple, Ctrl for create, Enter for edit, arrows to move. No need for a 6 step tutorial.” (paraphrasing)
Also, this allows for better “tablet hack” that Aleksey uses for iPad.
Alternatives considered:
- Keyboard shortcuts shown on card
- Shelved: too hard for now, possibly annoying.
- Guided tutorial, as now.
- Problem: Assumes faithful follow-through by user.
- Cheat Sheet like Gmail/GIthub ‘?’ page.
- Problem: not visible when needed, in context.
UI
Behavior
By default, the keyboard shortcut box is open. Which buttons are shown depends on the state (edit or normal).
Buttons change state depending on what key is pressed, and whether that action is available.
Normal Mode Buttons
When in normal (navigation) mode, these are the buttons shown:
- Ctrl
- h ←
- j ↓
- k ↑
- l →
- Enter
- Backspace
- /
Edit Mode Buttons
When in edit mode, these are the buttons shown:
- Ctrl
- h ← (shown for consistency, but never available)
- j ↓
- k ↑
- l → (shown, but not available when in col 3)
- Enter
Button States
Buttons are in one of three states:
- Active (key is down)
- Available (key can be pressed)
- Unavailable (key press does not do anything)
Color suggestions are green, gray-blue, opacity-0.2 for active, available, and unavailable respectively.
Bonus Details
For non-held keys (like “Enter” for entering edit mode), we can briefly flash the active state of the Enter key, and then fade it. This provides a consistent experience (keydown triggers active state always). Something similar to jQuery’s Highlight effect?