You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Low-priority, power-user request from Sina:
"I'd like to be able to hit Ctrl-F3 and automatically have PageUp/PageDown jump to searching by nodeType. Hitting it again should jump to the next nodeType. That way I can work rapidly, scanning for struct definitions or conditionals...without having to break my flow to bring up the search box. The rotor's last entry should be the most-recent text search, and any time a text search is performed the rotor should automatically jump to that."
This is actually generalizable to something akin to iOS's webpage rotor, which gets high praise in the a11y community. It's basically a UI-less version of our modal search box, and the two can go hand-in-hand nicely. Search box is nicely discoverable, Rotor is super efficient.
F3 currently brings up the search box, and LeftArrow/RightArrow switch between different types of search (e.g. by string, by nodeType, by aria-level, etc). Within a search type there are refinements (e.g. "case sensitive 'hello'", "only function definitions", "only level 3 elements", etc). Once a search and a refinement have been selected, PageUp/PageDown jump to the next/prev node that matched.
If we play our cards right and assign the right keyboard shortcuts to the search box, it will naturally mimic a Rotor. This lets programmers develop muscle-memory and quickly fly through searches as they learn the shortcuts. Common use-cases:
Searching by level
It's definitely come up in user testing that it would be nice to skim blocks of a given level, without having to navigate inside them. Collapsing sort of gets us there, but only if the user first collapses all. iOS already has a command for this, which is basically rotor+num. Pressing the rotor key and then hitting 2, for example, would navigate to nodes whose aria-level is 2.
Once the search box is up, I can't think of a good reason not to let a typed number immediately switch to a "search by level" tab and set the appropriate level: F3, 1 => "search by aria-level, specifically level 1 elements"
Searching by NodeType
Already implemented. To add this into the rotor, we need a kbd-shortcut to say "search for nodetype" and a way to quickly select a nodetype. Since we already have a shortcut for the first: F3, rightArrow, 2 => "search for nodeType, specifically the second type in the list"
Searching by string/regexp
F3, leftArrow, 4 => "search for strings I've looked for in the past, specifically the 4th one in the search history"
F3, leftArrow, tab, "hello" => search for nodes containing the string "hello"
The text was updated successfully, but these errors were encountered:
schanzer
changed the title
Rotor for searching by nodeType
Search Rotor
Sep 7, 2018
Low-priority, power-user request from Sina:
"I'd like to be able to hit Ctrl-F3 and automatically have
PageUp
/PageDown
jump to searching by nodeType. Hitting it again should jump to the next nodeType. That way I can work rapidly, scanning for struct definitions or conditionals...without having to break my flow to bring up the search box. The rotor's last entry should be the most-recent text search, and any time a text search is performed the rotor should automatically jump to that."This is actually generalizable to something akin to iOS's webpage rotor, which gets high praise in the a11y community. It's basically a UI-less version of our modal search box, and the two can go hand-in-hand nicely. Search box is nicely discoverable, Rotor is super efficient.
F3 currently brings up the search box, and
LeftArrow
/RightArrow
switch between different types of search (e.g. by string, by nodeType, by aria-level, etc). Within a search type there are refinements (e.g. "case sensitive 'hello'", "only function definitions", "only level 3 elements", etc). Once a search and a refinement have been selected,PageUp
/PageDown
jump to the next/prev node that matched.If we play our cards right and assign the right keyboard shortcuts to the search box, it will naturally mimic a Rotor. This lets programmers develop muscle-memory and quickly fly through searches as they learn the shortcuts. Common use-cases:
Searching by level
It's definitely come up in user testing that it would be nice to skim blocks of a given level, without having to navigate inside them. Collapsing sort of gets us there, but only if the user first collapses all. iOS already has a command for this, which is basically
rotor+num
. Pressing the rotor key and then hitting2
, for example, would navigate to nodes whosearia-level
is 2.Once the search box is up, I can't think of a good reason not to let a typed number immediately switch to a "search by level" tab and set the appropriate level:
F3, 1
=> "search by aria-level, specifically level 1 elements"Searching by NodeType
Already implemented. To add this into the rotor, we need a kbd-shortcut to say "search for nodetype" and a way to quickly select a nodetype. Since we already have a shortcut for the first:
F3, rightArrow, 2
=> "search for nodeType, specifically the second type in the list"Searching by string/regexp
F3, leftArrow, 4 => "search for strings I've looked for in the past, specifically the 4th one in the search history"
F3, leftArrow, tab, "hello" => search for nodes containing the string "hello"
The text was updated successfully, but these errors were encountered: