Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Efficient mouseless functionality #5

Open
keyserj opened this issue Dec 27, 2022 · 1 comment
Open

Efficient mouseless functionality #5

keyserj opened this issue Dec 27, 2022 · 1 comment
Labels
accessibility enhancement New feature or request needs tech design Technical solution should be figured out before implementing QoL small change the improves the feel of using the tool requested requested by a not-maintainer user

Comments

@keyserj
Copy link
Collaborator

keyserj commented Dec 27, 2022

Is your feature request related to a problem? Please describe.
I want to be able to exercise ameliorate's functionality without a mouse - both for accessibility, and for efficiency. Specifically, at least the following should be mouseless:

  • Add node
  • Edit node text
  • Edit selection's score already done, type 0-9 or dash when selecting a part
  • View score's claim
  • Go back to problem mapping from claim view
  • Select node up/down/left/right of current selection
  • Select edge up/down/left/right of current selection

Note: most of these can be accomplished through Vimium's [fF]-to-click functionality, but that's not as smooth as directly having shortcuts for these (and requiring Vimium for accessibility is probably not ideal).

Describe the solution you'd like
VIM-mode sounds pretty awesome (e.g. "cc" to change node text, "cs" change score, "apj" add problem below, "" to enter VIM-mode). Perhaps more common hotkeys like ctrl-[char] would be good for non-vimmers too.

Describe alternatives you've considered

Additional context

Technical ideas
We already use react-hotkeys-hook, which seems decent enough for this

@keyserj keyserj added enhancement New feature or request needs tech design Technical solution should be figured out before implementing exciter Feature that some users might really really like labels Dec 27, 2022
@keyserj keyserj added QoL small change the improves the feel of using the tool accessibility labels Aug 21, 2023
@keyserj keyserj added the requested requested by a not-maintainer user label Mar 24, 2024
@keyserj
Copy link
Collaborator Author

keyserj commented Aug 28, 2024

Some more thoughts:

  • j/k to navigate to nearest parent/child, h/l to navigate to nearest left/right node
    • how to navigate to edges? probably gj/gk
    • arrow keys easier to learn for newbies, but maybe worse when things like direction are needed elsewhere?
      • g[down]/g[up] seem not ideal
      • a[down]node-char/a[up]node-char seem not ideal
      • also they don't fit in the "[c]har that makes sense for char/vim-like command"
    • this should also work for navigating table cells
  • enter to focus selected node's input
    • if focused, enter to blur, shift + enter to add newline
  • shortcut to create parent/child
    • not sure what's best... possibly:
      • cp[node-type-char]/cc[node-type-char] for create parent/child
        • requires tracking a vim-like stack that can be escaped (and esc to deselect would have to be not possible unless nothing in vim-stack)
          • probably would want to add visuals to indicate what can be pressed, when the current stack is, option to turn off
      • cj[node-type-char]/ck[node-type-char] for create [direction]
      • aj[node-type-char]/ak[node-type-char] for add [direction]
        • a is closer to OG vim "append", whereas c is used for "change"
      • alt+p+[node-type-char]/alt+c+[node-type-char] for create parent/child?
        • hard to do triple shortcut actions that need to be held at the same time
        • but is nice that doesn't conflict with vimium i.e. require insert mode for vimium
    • what about when selecting a details/table node, not a diagram node?
      • maybe the add button itself could put "[p]arent"/"[c]hild" + "[n]ode-type-char" above/below itself
        • above if odd in container, below if even? to avoid text overlap
        • or could be within the button too, temporarily replacing the icon

@keyserj keyserj removed the exciter Feature that some users might really really like label Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility enhancement New feature or request needs tech design Technical solution should be figured out before implementing QoL small change the improves the feel of using the tool requested requested by a not-maintainer user
Projects
Status: No status
Development

No branches or pull requests

1 participant