Specify region in the search, like a bang

Vlad

donbex We will implement it through bangs to keep syntax easier..

so !de will show results for Germany

seventhwave

Vlad I don't agree here.
it would be difficult to separate a "region bang" from a "standard bang"
we need a prefix for the user who wants to specify a region inline
a namespace like !r:de or !reg:de.

This "bang namespace" will help us for eliminate future bang clashes, and reduce mental fatigue
So, I'm against direct "country code bangs".

Vlad

One one side there is bang fatique, on the other is keeping it simple and consistent. Remembering !r:xx syntax sounds difficult already IMO

riddley

What happens when the ISO country code clashes with an existing duck duck go bang? E.g. I often use the existing duck duck go bang !au which searches the Arch Linux AUR repository.

I would also prefer the duck duck go syntax, r:au, it's easy to remember and type, is equivalent to the well-established site: syntax, and doesn't clash with bangs.

Browsing6853

My country's ISO code also clashes with an existing bang... I guess the only way to implement it correctly is investing in personalized bangs.

Vlad

We will have a way to perosnalize bangs soon.

donbex

Having to remember custom bang overrides would definitely result in "bang fatigue"... much more so than a simple scoped notation like r: or the proposed !r:. Clashes would also be confusing for people who, like me, come from years of using DuckDuckGo.

Vlad

So is the ask to change region selection to r: or !r: ?

If region can be altered in this way should we do it with other search settings? Which ones?

riddley

Vlad

So is the ask to change region selection to r: or !r: ?

The ask is to do it in a way that the 249 iso codes don't conflict with bangs. The syntax you use is arbitrary and I don't think anybody cares that much as long as you avoid the conflict.

Personally I now like r: because:

it's simple, clear and easy to type
it's consistent with existing site: syntax
it's the same as existing DDG syntax, creating a de-facto standard

But if it's simpler for you to implement !r: for technical reasons that would be fine too.

If region can be altered in this way should we do it with other search settings? Which ones?

Verbatim and safe search. For me personally these are only "nice to have", I can't see them being as useful as region control, but since you asked...

DDG has !safeon and !safeoff which seems good to me. My first thought is that !verbatimon is too annoying to type, so maybe !von and !voff? They look kind of ugly but are easy to type.

donbex

I second what riddley wrote above.

Vlad

riddley Thanks for your input.

If we are deciding to use r: syntax for toggling a setting and keeping ! syntax for redirecting to sites it does seem surprising to me that you are suggesting using a bang like !safeon to toggle a setting.

I was expecting something like o:verbatim or o:safe or o:24h to toggle any setting for consistency.

seventhwave

Vlad I'm strongly for orthogonality. I see users use/approach bangs with search facets related to search content (on which website, etc). We have an easy DDG compatibility precisely because no bang is related to DDG per se.
For every modifier related to the Kagi UI, I think it's really better to take another syntax.
My proposal was !r:XX, but now I'm more for simply r:XX.
In this way, we could choose to have all the options listed on
o:verbatim
o:24h
o:safeon
or also have namespacing with a single letter related to an option, if we prefer. Something like:
l:verbatim
t:24h
s:on

I prefer the second variant, but I think that the important thing here is to separate from bangs
Also because we could customize bangs in future, and I don't think will be useful to customize also bangs related to these options.

riddley

Vlad You and @seventhwave are right, I just looked at what DDG does but didn't think it through, using a bang for settings is not orthogonal and has the same problem as for regions.

Ok looking at boolean options: I think you would need a way to turn them off as well as on, right? I see the syntax o:verbatim works well to turn it on, but do you want to give users the ability to disable it as well? In which case what would you use? o:noverbatim or o:verbatimoff... ?

So my idea is to have variable_name:value, for booleans the values are on and off.

So we have one boolean option, safe search, which is a toggle in the settings. For this we have:
safe:on
safe:off

Then we have named drop-down menus in the search interface, e.g. time. For this we have:
time:24h
time:week
time:month
time:year

Verbatim is interesting because it could be a boolean but it exists as a drop-down with two options. Is this so Kagi can add a third option later? Anyway to match the interface we'd have:
results:all
results:verbatim

But if it really is a boolean you could equally have:
verbatim:on
verbatim:off

Vlad

riddley What I proposed would always toggle an option on/off so no need for implicit on/off in the command itself.

We can do anything we just need to get a formal suggestion in place that will cover the wanted syntax.

riddley

Vlad Do you mean it would swap it from its current state? I don't like that approach, I can think of three reasons:

I have to know/remember the existing state to know whether I want to change it. For me the main use of this feature is from the location bar or Kagi search page where the GUI options are not visible, so I don't necessarily remember what the current setting is
If the results page is reloaded in the browser for any reason, the setting is changed back, which is not what I want
If I edit the search to re-run it with slightly different keywords, I have to remember to remove the setting

So, I'd prefer to explicitly specify "on" or "off"

Vlad

riddley Ok can you then propose the format for all settings as found in our filters? Starting with web search for now.

riddley

Vlad I put suggestions in my previous post... is that not what you are asking for? https://kagifeedback.org/d/378-specify-region-in-the-search-like-a-bang/29

Vlad

riddley yes, just that they are not covering all filters we have so wanted to get user feedback on those as well.

« Previous Page