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

Type a prefix for performing types of clicks (e.g. right click, double-click) #57

Open
keithadams opened this issue Aug 15, 2022 · 9 comments

Comments

@keithadams
Copy link

I tried Homerow.app's method for performing different types of clicks (e.g typing a prefix before the hint like r for a right click) and I prefer it over modifiers now. It'd be great if a similar option could be added to Wooshy someday.

It'd need to work a little differently. Perhaps a convenient separator (like ; or , or double space) to indicate type of click:

  • r;button or r,button or r _ _ button would perform a right click

And maybe the ability to do a prefix or suffix:

  • d;button or button;d would perform a double click
@godbout
Copy link
Owner

godbout commented Aug 15, 2022

yeah, i'm not a big fan of modifiers either, but because it's standard and follows macOS habits i've added them at first.

i prefer typing also à la Homerow, but i haven't found yet a natural way of dealing with this. i don't want to have an overly complicated manual for Wooshy. it should feel quite natural without having to think too much. like if you want to target links you type "links". straight from brain to results.

so yes, i want to add something through typing, but i need time and focus to digest a proper idea.

thinking out loud here: your double space sounds nice. people should already be used to type double spaces on iOS for example. but typing this, thinking that some people may have the double space being replaced by a ., even on macOS hmm. so that's gonna be a problem. maybe actually just single space then? if the search terms start or end with a single letter, we check if it's a r, d, etc. and if it is, we take this as a command for a type of click?

@keithadams
Copy link
Author

keithadams commented Aug 15, 2022

i'm not a big fan of modifiers either, but because it's standard and follows macOS habits i've added them at first.

For sure and I bet some people even prefer the modifiers. I used mods with Shortcat and was skeptical of Homerow's method, but I ended up liking it.

maybe actually just single space then? if the search terms start or end with a single letter, we check if it's a r, d, etc. and if it is, we take this as a command for a type of click?

If you use single space, then I think you would need to disallow spaces for matching words. For example, if they type r t d, then it's ambiguous, right?

  • normal click r, t, and d like "Read The Documentation"
  • right click t and d like "Test Dictionary"
  • double click r and t like "Read Tweet"

This can totally work, though. It would look like this:

  • type rtd to normal click "Read The Documentation"
  • type r td or td r to right click "Test Dictionary"
  • type d rt or rt d to double click "Read Tweet"

LaunchBar (an alternative to Alfred) works similar to this. It uses space to select items and go into sub menus. It's a very fluid way to navigate menus because it feels like you're just typing sentences, except using the least amount of letters to fuzzy match. It's worth checking out how their app works if you haven't already.

@keithadams
Copy link
Author

Also, if you end up adding the feature, maybe the best option is to let the user to define the delimiter. Perhaps start with a sensible default, but offer tweaking tucked away in an "Advanced" tab under preferences?

@godbout
Copy link
Owner

godbout commented Aug 15, 2022

If you use single space, then I think you would need to disallow spaces for matching words. For example, if they type r t d, then it's ambiguous, right?

  • normal click r, t, and d like "Read The Documentation"
  • right click t and d like "Test Dictionary"
  • double click r and t like "Read Tweet"

This can totally work, though. It would look like this:

  • type rtd to normal click "Read The Documentation"
  • type r td or td r to right click "Test Dictionary"
  • type d rt or rt d to double click "Read Tweet"

in practice is that working smoothly? i can't avoid feeling that this requires extra cognition to think about the first letters of each word. personally that has never worked for me. i'm way faster just typing "read the d" than "rtd" (just typing "rtd" right now i made a mistake. i didn't with "read the d"). also, personally, i tend to avoid stuff that would build bad (or at least not useful) habits. like typing "read the d" is useful. it trains me to type something i'll use in a lot of places. but "rtd" doesn't. which is why Wooshy started without even any fuzzy matching at all.

apart from this, how would you distinguish roles then? like in your examples?

  • type r td td is what? Test Dictionary? Tab Dictionary?

or then we need a different system for the UI elements roles? then you'll need a 96 pages PDF to understand the complicated system to match your stuff. argh no thanks.

so, i'm not sure. i have several feedback about "better" ways to type, but they are mostly all seeing their own point of view, and it crumbles as soon as i add some basic cases that will just not work, bring Targets pollution, etc.

LaunchBar (an alternative to Alfred) works similar to this. It uses space to select items and go into sub menus. It's a very fluid way to navigate menus because it feels like you're just typing sentences, except using the least amount of letters to fuzzy match. It's worth checking out how their app works if you haven't already.

yeah i know LaunchBar and i'm aware of their fuzzy matching, it's just again that it doesn't match how i work.

Also, if you end up adding the feature, maybe the best option is to let the user to define the delimiter. Perhaps start with a sensible default, but offer tweaking tucked away in an "Advanced" tab under preferences?

i try to avoid giving options, unless when it's clearly necessary. i like to do apps that "Just Work" and need minimal config. that being said, i could have a "Fuzzy Matching" option like i did with The Input, and you could choose "À la Alfred", "Like LaunchBar", etc. this would be acceptable. but probably not before v1.

@keithadams
Copy link
Author

keithadams commented Aug 15, 2022

in practice is that working smoothly? i can't avoid feeling that this requires extra cognition to think about the first letters of each word.

Interesting. I'd find typing "read the d" cumbersome and I'd prefer to type less. (Edit: cumbersome in the context of typing to click hundreds of things a day). Thinking rtd is pretty instant, but that's me. Ultimately, we're all different which is why I like the idea of sensible default, but with the ability to change things.

apart from this, how would you distinguish roles then? like in your examples?

Again, this is probably owing to everyone being different but I don't find the UI roles helpful. They can actually be a hindrance. You have a lot of experience with UI elements and their accessibility roles. I can only guess at some ( like I bet button is one). There have been times where I get a match that I don't want and I have no clue why. I reverse engineered one to be "Labeled" something. For my experience, it just added a match that I had to tab through. I suspect many people that use the app won't know roles either.

yeah i know LaunchBar and i'm aware of their fuzzy matching, it's just again that it doesn't match how i work.

Again, different strokes. The reason I like fuzzy matching so much is that it's more dynamic. A good fuzzy match could match "Read the Documentation" with:

  • read the d
  • rtd
  • readdoc
  • countless others

@godbout
Copy link
Owner

godbout commented Aug 16, 2022

Interesting. I'd find typing "read the d" cumbersome and I'd prefer to type less. (Edit: cumbersome in the context of typing to click hundreds of things a day). Thinking rtd is pretty instant, but that's me. Ultimately, we're all different which is why I like the idea of sensible default, but with the ability to change things.

my bad. that was a very bad example 😅️ was just to show you don't need to type the whole thing. for Read The Documentation what i would personally do is type doc coz that's the first thing that comes to my mind (yes, very personal). then if there are too many targets, i'd probably type read. like targeting in two shots. also, if after the doc i actually have very few targets, what i do naturally is start kV (with capslock) and navigate with jk.

Again, this is probably owing to everyone being different but I don't find the UI roles helpful. They can actually be a hindrance. You have a lot of experience with UI elements and their accessibility roles. I can only guess at some ( like I bet button is one). There have been times where I get a match that I don't want and I have no clue why. I reverse engineered one to be "Labeled" something. For my experience, it just added a match that I had to tab through.

hmm. interesting. the roles are supposed to be self-explanatory. i don't really know them myself, i just type what comes to my mind: button, link, checkbox, radio, tab, etc. what happened with your "labeled" is not because of a role, it's because Wooshy doesn't only match what you see on the screen, but all the metadata behind. currently the only way to see this is to use the Accessibility Inspector that comes with Xcode. at a later stage there'll be something integrated to Wooshy (the reason why it's in alpha now is because it's missing this feature) where you'll be able to see all the terms that will match your Target.

I suspect many people that use the app won't know roles either.

seems at least a few people do. for checkboxes and tabs at least. personally i use the link all the time.

Again, different strokes. The reason I like fuzzy matching so much is that it's more dynamic. A good fuzzy match could match "Read the Documentation" with:

  • read the d
  • rtd
  • readdoc
  • countless others

ok. i think that will come then as a "preset" at a later stage, yes. thanks for the idea.

@godbout
Copy link
Owner

godbout commented Aug 16, 2022

ok. i think that will come then as a "preset" at a later stage, yes. thanks for the idea.

actually do you mind opening a new issue regarding this? this is different from the right click etc. through typing. thanks!

@keithadams
Copy link
Author

at a later stage there'll be something integrated to Wooshy (the reason why it's in alpha now is because it's missing this feature) where you'll be able to see all the terms that will match your Target.

That'll be cool.

actually do you mind opening a new issue regarding this? this is different from the right click etc. through typing. thanks!

Will do!

@godbout
Copy link
Owner

godbout commented Aug 28, 2022

funny, i'm coming back here to say that i think it may be nice if we add a new narrower at the end, like d for double-click, t for triple-click etc., but it seems i've already mentioned this before and it didn't go well 😅️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants