New Search Options

[+Baad Daata]

I did a search for "Arizona" and filtered for "events" and came up empty. I find the new search parameters to be non-intuitive and useless for a dumb-bunny like me. Does this all mean that there are no events in the state of Arizona in the next day, week, month or three months or....?

[+cerberus1]

Events in Arizona.

I went to the US subforums and simply clicked on the State.

[+cerberus1]

Otherwise, I'd go on Find a Geocache from the Play dropdown on my profile page, then hit the Take me to the old Search link (in the trees to the right).

Even dumb bunnies like me can use the old search.

[Pup Patrol]

I did a search for "Arizona" and filtered for "events" and came up empty. I find the new search parameters to be non-intuitive and useless for a dumb-bunny like me. Does this all mean that there are no events in the state of Arizona in the next day, week, month or three months or....?

 

I think I'm starting to get the hang of the new search.

 

1.) leave the box on the front page empty

2.) click on "Add filters"

3.) "Geocache Types"...uncheck every cache type except Events

4.) over in "Search Only In..." United States: Arizona

 

https://www.geocaching.com/play/search?types=6&r=3

 

Or use the old search page:

 

https://www.geocaching.com/seek/nearest.aspx?state_id=3

 

 

B.

[+niraD]

I did a search for "Arizona" and filtered for "events" and came up empty.

As others have mentioned, you need to leave the first search field blank. Yes, this is completely unintuitive.

 

If you enter Arizona in the first search field, then you are searching within a certain radius (10 mile default, 30 mile maximum) of the geographic center of Arizona.

 

That's because the first search field does only one thing: it specifies the center of your search radius. It does that with anything you enter into it.

[knowschad]

I did a search for "Arizona" and filtered for "events" and came up empty.

As others have mentioned, you need to leave the first search field blank. Yes, this is completely unintuitive.

 

If you enter Arizona in the first search field, then you are searching within a certain radius (10 mile default, 30 mile maximum) of the geographic center of Arizona.

 

That's because the first search field does only one thing: it specifies the center of your search radius. It does that with anything you enter into it.

 

Is that 1st page good for anything? That seems to be the major source of confusion.

[+niraD]

Is that 1st page good for anything? That seems to be the major source of confusion.

I suppose it's good for searching for caches within a given radius of a specific location. But yeah, it does seem pretty confusing.

 

I think separating it from the other filters was a bad idea. When there's just one search field, people think it's a generic search field. Except this one isn't.

[+Baad Daata]

I know that this topic needs to be merged with others. I have never worked with a search feature that is less intuitive and less helpful. I can't type in a keyword, the first word is often irrelevant. If you are going broke, up the fees and charge for services. Make this a toll road and make your searches useful.

[Pup Patrol]

I know that this topic needs to be merged with others. I have never worked with a search feature that is less intuitive and less helpful. I can't type in a keyword, the first word is often irrelevant. If you are going broke, up the fees and charge for services. Make this a toll road and make your searches useful.

 

There are other threads where specific problems have been answered by helpful people. And there are other threads of general ranting.

 

There's also this:

 

A Guide to Searching on Geocaching.com

http://forums.Groundspeak.com/GC/index.php?showtopic=330554

 

And the Help Center:

 

2.1. Advanced Search FAQ

http://support.Groundspeak.com/index.php?pg=kb.page&id=649

 

2.2. I have feedback about the new Advanced Search

http://support.Groundspeak.com/index.php?pg=kb.page&id=653

 

 

B.

[Keystone]

I merged together two threads about the new search feature, both started by the same OP.

[+thebruce0]

Is that 1st page good for anything? That seems to be the major source of confusion.

I suppose it's good for searching for caches within a given radius of a specific location. But yeah, it does seem pretty confusing.

 

I think separating it from the other filters was a bad idea. When there's just one search field, people think it's a generic search field. Except this one isn't.

Yep, it looks like a google search single unified field. One would expect that whatever you enter there will turn up results if there are any listing matches that are related in some way to the text in the box. It most certainly needs clarifying text, at the very least, that it is only to define a center point (even more confusing when the entered text isn't a point but an area from which a center point is calculated or cross-referenced) and will then default to a maximum distance.

Edited April 14, 2015 by thebruce0

[+Viajero Perdido]

The next killer app is obvious - for this game at least. A Google-like front end, a simple text input box, that figures out what you're trying to search for, and submits it to Groundspeak's new interface behind the scenes.

 

"Events in Alberta" - how hard can that be? "Events" is a known keyword, Alberta is a known place, ...

[+thebruce0]

Yep!

Natural language search.

If you don't get what you want, try something different, or use the alternate explicit search filters (aka "Advanced Search")

Edited April 14, 2015 by thebruce0

[+NYPaddleCacher]

The next killer app is obvious - for this game at least. A Google-like front end, a simple text input box, that figures out what you're trying to search for, and submits it to Groundspeak's new interface behind the scenes.

 

"Events in Alberta" - how hard can that be? "Events" is a known keyword, Alberta is a known place, ...

 

What would this killer app do If I entered Mingo. Should it take me to Mingo the geocache or search for caches with the town of Mingo (in Kansas) as a center point.

 

How about if I enter Rome. Should I see a list of cache in Rome, Italy, Rome, New York, or Rome, Georgia...or, if there is a cache with Rome in the title should it show that?

 

With a single, multi-purpose search box there will often be some amount of guessing to figure out what you're trying to search for and when it guesses, it will sometimes guess wrong.

 

I find it amazing how often people will try to compare a search engine developed by a small company or department to Google. Google has over 53K employees and a massive amount of server resources (and money) and companies like GS only have 70 or so and a handful of servers, yet those small companies are expected to have a search engine equal to what Google has created.

 

 

 

[+narcissa]

I find it amazing how often people will try to compare a search engine developed by a small company or department to Google. Google has over 53K employees and a massive amount of server resources (and money) and companies like GS only have 70 or so and a handful of servers, yet those small companies are expected to have a search engine equal to what Google has created.

 

I think people just expect that the redesign will be better than the previous version.

[+Viajero Perdido]

I know, it's harder than it looks.

 

But a quickie "killer app" would take the user input, add "site:geocaching.com", and pass that to Google. Which is what already works fairly well when done manually.

 

Now if Groundspeak would open their database to full indexing...

 

EDIT: I'm going to quit while I'm behind.

Edited April 14, 2015 by Viajero Perdido

[+thebruce0]

What would this killer app do If I entered Mingo. Should it take me to Mingo the geocache or search for caches with the town of Mingo (in Kansas) as a center point.

 

How about if I enter Rome. Should I see a list of cache in Rome, Italy, Rome, New York, or Rome, Georgia...or, if there is a cache with Rome in the title should it show that?

 

With a single, multi-purpose search box there will often be some amount of guessing to figure out what you're trying to search for and when it guesses, it will sometimes guess wrong.

 

It's an interesting situation, but I would presume it would be sort of like say an iTunes search, where different common categories could result. First if there's any exact match, they would appear first. Exact GC code? Exact name? Partial name match? Exact owner name? If it's not sure how to interpret, it could ask "did you mean...?"

"Caches owned by Keyst" could say "No caches found owned by Keyst. Did you mean caches owned by Keystone?" If there happens to be a cache called "Caches owned by Keyst" then it would show up in its section too.

 

Yep. It's complicated.

I don't think it's feasible for Groundspeak. But one can dream big

May as well just use Google anyway. I mentioned in another thread a while back, what are the chances Groundspeak could license a Google indexing service in-house to catalog the database and provide such a complex algorithmic search? Google apparently does offer that.

 

Pie in the sky.

Filters are the easy way, the most likely way. A unified natural language search - localized, worldwide - would be a monumental task to get right.

 

So that search box needs to be labelled properly.

Edited April 14, 2015 by thebruce0

[knowschad]

Is that 1st page good for anything? That seems to be the major source of confusion.

I suppose it's good for searching for caches within a given radius of a specific location. But yeah, it does seem pretty confusing.

 

I think separating it from the other filters was a bad idea. When there's just one search field, people think it's a generic search field. Except this one isn't.

Yep, it looks like a google search single unified field. One would expect that whatever you enter there will turn up results if there are any listing matches that are related in some way to the text in the box. It most certainly needs clarifying text, at the very least, that it is only to define a center point (even more confusing when the entered text isn't a point but an area from which a center point is calculated or cross-referenced) and will then default to a maximum distance.

 

You mean, like this? (Google search for "geocaching Events in Alberta, CA" which brought this at the top result: http://www.geocaching.com/seek/nearest.aspx?state_id=63

[+thebruce0]

Yep, but the other problem is sifting out the matches that aren't quite intended. In some cases google currently will be useful if the link that's relevant has text to which the search is very related. In this case, actually I'm not even sure what the link is doing... Isn't that just a search for all caches in Alberta? How is it showing events first? There's no parameter to set that. Map this location even shows how many non-event caches are nearby. How is it showing events when state_id is all that's set? *confuzzled*

I guess the default search filter is for events? Set nothing else and the search focuses on events? I've never noticed that before

 

Anyway I'd still use something like site:geocaching.com inurl:geocache intitle:"(Event Cache) in Alberta, Canada" were I to stick with google to find standard Event caches.

But Google only shows you what it's indexed, which is key to remember - a generic google search for a cache won't necessarily give you the result you're looking for. But the search engine is very powerful and fast. Incorporate that power locally directly to the GC database, and boom.

 

PS: Alberta, California?

Edited April 15, 2015 by thebruce0

[+NYPaddleCacher]

Yep, but the other problem is sifting out the matches that aren't quite intended. In some cases google currently will be useful if the link that's relevant has text to which the search is very related. In this case, actually I'm not even sure what the link is doing... Isn't that just a search for all caches in Alberta? How is it showing events first? There's no parameter to set that. Map this location even shows how many non-event caches are nearby. How is it showing events when state_id is all that's set? *confuzzled*

I guess the default search filter is for events? Set nothing else and the search focuses on events? I've never noticed that before

 

The search query that KC suggests ("geocaching Events in Alberta, CA") just produces a page for a list of caches in Alberta, CA. Executing that search produce a list with the default sort order (placed by date) and since Events are "placed" in the future they'll be at the top of the list.

A google search for "geocaching in Alberta, CA" results in the same page as the first hit in the google results. Including "Events" in the search query is superfluous. Actually, the page that it returns isn't a list of caches in Alberta, CA. It's a list of caches with the state_id field = 63. Of course, Google doesn't know that in the GS database a state_id=63 indicates Alberta, Canada but when it crawls the "nearest.aspx" page and includes the state_id=63 parameter, every result in the list of caches includes the string "Alberta, Canada" and oddly enough, the word "Event" doesn't appear anywhere on the page.

 

 

Anyway I'd still use something like site:geocaching.com inurl:geocache intitle:"(Event Cache) in Alberta, Canada" were I to stick with google to find standard Event caches.

But Google only shows you what it's indexed, which is key to remember - a generic google search for a cache won't necessarily give you the result you're looking for. But the search engine is very powerful and fast. Incorporate that power locally directly to the GC database, and boom.

 

PS: Alberta, California?

 

One of the biggest complaints about the new search engine is that it shouldn't require one to be a computer scientist to use it. If GS wants to use a single search box *without* using the field searching syntax (e.g. intitle:"Alberta, Canada") it would need to guess if a term is a cache name or a location, and if it guesses it's not always going to be how the user intended the term to be used.

 

If GS used field searching syntax similar to Google (Lucene/Solr is done in the same manner). It would be something link:

 

location:"Alberta, Ca" type:event

 

which would product a search url like:

 

https://www.geocaching.com/play/search?types=6&r=63&sort=PlaceDate&asc=False

 

I still think that if GS reorganized things such that the Filters appear on the left side of the page and not as an overlay it would be a lot more intuitive. Somehow they've got to make it clear that the search box is for producing a center point and that one either needs to use a center point or filter based on a "region" (country_id or state_id) to get any results.

[+thebruce0]

Yep, but the other problem is sifting out the matches that aren't quite intended. In some cases google currently will be useful if the link that's relevant has text to which the search is very related. In this case, actually I'm not even sure what the link is doing... Isn't that just a search for all caches in Alberta? How is it showing events first? There's no parameter to set that. Map this location even shows how many non-event caches are nearby. How is it showing events when state_id is all that's set? *confuzzled*

I guess the default search filter is for events? Set nothing else and the search focuses on events? I've never noticed that before

 

The search query that KC suggests ("geocaching Events in Alberta, CA") just produces a page for a list of caches in Alberta, CA. Executing that search produce a list with the default sort order (placed by date) and since Events are "placed" in the future they'll be at the top of the list.

A google search for "geocaching in Alberta, CA" results in the same page as the first hit in the google results. Including "Events" in the search query is superfluous. Actually, the page that it returns isn't a list of caches in Alberta, CA. It's a list of caches with the state_id field = 63. Of course, Google doesn't know that in the GS database a state_id=63 indicates Alberta, Canada but when it crawls the "nearest.aspx" page and includes the state_id=63 parameter, every result in the list of caches includes the string "Alberta, Canada" and oddly enough, the word "Event" doesn't appear anywhere on the page.

Ah right, sorted by date placed descending by default - hadn't thought of that.

Everything else, yep. The content of that search result is most relevant to the search criteria provided to google, which is why it's near the top of the list. Even though the page hasno thing explicitly to do with events.

 

Anyway I'd still use something like site:geocaching.com inurl:geocache intitle:"(Event Cache) in Alberta, Canada" were I to stick with google to find standard Event caches.

But Google only shows you what it's indexed, which is key to remember - a generic google search for a cache won't necessarily give you the result you're looking for. But the search engine is very powerful and fast. Incorporate that power locally directly to the GC database, and boom.

 

PS: Alberta, California?

 

One of the biggest complaints about the new search engine is that it shouldn't require one to be a computer scientist to use it. If GS wants to use a single search box *without* using the field searching syntax (e.g. intitle:"Alberta, Canada") it would need to guess if a term is a cache name or a location, and if it guesses it's not always going to be how the user intended the term to be used.

 

If GS used field searching syntax similar to Google (Lucene/Solr is done in the same manner). It would be something link:

 

location:"Alberta, Ca" type:event

 

which would product a search url like:

https://www.geocaching.com/play/search?types=6&r=63&sort=PlaceDate&asc=False

 

I still think that if GS reorganized things such that the Filters appear on the left side of the page and not as an overlay it would be a lot more intuitive. Somehow they've got to make it clear that the search box is for producing a center point and that one either needs to use a center point or filter based on a "region" (country_id or state_id) to get any results.

Agreed. I'm not proposing that GS instead creat a google-style free text entry unified search field with filter options I commented earlier about a possible way the field could interpret the natural language search, and present the results in categorized forms prioritized by most likely... but it's just way to complex for this site I think; notr eally worth the effort.

But at the very least, any search field should, ideally, jump to (or show) exact matches (or single best match) first, by GC code, Cache name, then Owner name. That would be one step closer to a simplified search that one would expect. Enter a GC code, be given a link directly to the cache and/or show results with it centered. *shrug*

There's no simple solution. This setup is not conducive to a simple backend =/

 

I'm not fully sold on a left hand/tall region for search parameters. I think people are still happy with or satisfied with the idea of seeing and setting parameters on a page, and getting results on another page. It gets muddy when you combine the results of a complex search on the same page as managing all the parameters for the search. It's a lot of information for a single page. Desktop ormobile

 

ETA: What if the cache search function had a UI similar to the full page Map? Scrollable left region with filters, and the 'map' block on the right were instead the table of results? That could work... and people are already used to that sort of UI setup because of the big Map.

Edited April 15, 2015 by thebruce0

[+lefisher]

Otherwise, I'd go on Find a Geocache from the Play dropdown on my profile page, then hit the Take me to the old Search link (in the trees to the right).

Even dumb bunnies like me can use the old search.

[+lefisher]

I've been trying to find caches by name and haven't had any success. Today I thought I would try searching the forums and came across your text. Thank you so much for pointing out the old search link! I had not noticed it until you said.

[Pup Patrol]

I've been trying to find caches by name and haven't had any success. Today I thought I would try searching the forums and came across your text. Thank you so much for pointing out the old search link! I had not noticed it until you said.

 

Using the old search, you need to know the first word of the cache name: "Cache Starts with:"

 

It does not search for "name contains".

 

Trying the new search might be helpful, if you don't know the exact first word on the cache name.

 

The very first thing you do on the new search is click on "add filters" on the front page.

 

https://www.geocaching.com/play/search

 

Now you are on the page where you can use "Geocache name contains", top of the 3rd column.

 

In that column, at the bottom, you will need to input a location: "Search only in"

 

Start typing your location name, for example "Cyprus". The system will fill in the name in a dropdown list. Click on that. Then click "search".

 

 

B.