GO Geiger

Personally, I would want it to perform a new search at the new location or zoom level - always. I can't think of a time where I thought to myself "OK, I've searched at this location for a particular thing. Now let's zoom out and not refresh the search to show me the results in the area I'm now viewing." Kind of like if I search hotels on Google, it updates the view to show me the hotels in the area I'm currently viewing. (This is all things being equal and server hits not being considered, of course. Although, zooming in wouldn't require a new search, I suppose, for the view, but the list of caches on the sidebar would need to pay attention to the new viewing area.)

Good points and I agree with all of them. But it seems like the majority of use cases (or at least users on the forums) desire the use of the Browse map rather than the Search map. Would it be that bad (or that hard) to have the additional cache info added to the Browse map? (Serious question, I'm a computer programmer, but not an interface guy. It would seem easy enough to me, but I have no knowledge of the legacy code in the Browse map which may make this difficult/painful/impossible. Bolting it on just to have it, as opposed to designing it in, would also be a bad idea for the programmers.) Also, going to the Search map using the View Larger Map seems silly - I'm not actually searching for anything, other than the caches near to the cache I was previously looking at. As such, the view should not be limited to one screen full of caches at a certain zoom level. (Give a reasonable search radius around the cache, say 5 miles? 10 miles? Or go back to sending us to the Browse map. Or make it an option ) I do agree about the server load from doing constant re-searches being problematic. That makes me think that the Search map should be used in as few use cases as it makes sense to use it, not in the majority of them. (Although, I don't know what the server load is from constantly panning/zooming the Browse map.) Again, as a computer guy, I know all about the infamous "to-do" list that never gets done (or sometimes never even gets made), due to shifting priorities, employee turnover, difficulty of implementation, being distracted by shiny things, etc. Still not in love with the new Search map (too many extra clicks when panning around), but I can see its purpose. I think it may be getting used in too many use cases, though. At the very least, I would hope HQ is watching these discussions and evaluating the (hopefully) constructive criticism we're offering.

This seems a fairly one-sided conversation, but in any event, I'll add my (uncharacteristically not-so-negative) opinion: I very rarely use the Search map. That being said, the ability to see additional cache information when going to the "View Larger Map" screen is kind of nice. I have a few suggestions, though: Add a toggle to see the additional cache info in the Browse map. (Maybe make it another "tab-like" selection along with Search and Pocket Queries) When using the View Larger Map, it would be nice if zooming out didn't require a button click to refresh the view. After all, when viewing the area around a cache, it's probably because we want to see the other caches in the area. The limit of 1000 caches seems arbitrary for the Search map, especially in a cache-dense area (but then, I guess the primary function is to search for some specific set of attributes, not every cache, so maybe this isn't a big deal) Have an option to make the Browse map the primary interface (adding new interfaces is fine, but forcing them on the user, who is often unsuspecting, is not good practice. There was a bit of backlash against the ribbon when MS introduced it. Some people still don't like it.) Even better, leave the Browse map the primary interface and add an option so people can choose to make the new Search map their primary interface I fondly recall the days when interfaces had distinct colors and square corners and minimal whitespace. (Not exactly a critique of the new Search map, but of the "new" everything on the site - but then I don't use, own, or in any way interact with smart phones, so this may just be the "new normal.") In summary, do I like the new Search map? Not exactly (but I certainly don't hate, loathe, or despise it). Can it be improved? Certainly Would I like to see the Browse map as the primary interface? Most definitely Best compromise? Allow the Browse map to display more detailed cache info in the side panel and allow the Search map to more seamlessly update the view (i.e. not having to click the "Search This Area" button all the time).

A former co-worker had this view of software functionality over time: "You should never take away functionality people are used to. You also should never make it harder for people to do what they want to do." Having separate ways to get to the search map and the browse map would meet with his approval (as would adding functionality to each of those maps). Forcing the user to go through the search map to get to the browse map (adding extra clicks) would fall under the heading of "making it harder for people to do what they want to do." Again, let me state that I have no issue with the existence of the new Search map (even though I prefer the older one) nor the people that find it useful. My only concern is to easily get to the Browse map via the GC.COM interface (although bookmarking the Browse map could be a workable option, if that will still be a viable approach, as per @thebruce0's post).

Add our vote to the "Make it easy to get to the browse map" contingent. I would say that we use the search functionality about 10% of the time, at most, and then only when looking for very specific things (caches by favorite points or by particular COs). Generally we just open the browse map and look around for caches that are near where we're going to be (or where we might be going). Don't misunderstand me - we have no concerns about the "new search" map existing and wish it no ill will, we just don't want to be forced to use it or to have to take a workflow that adds steps to what we're already doing. (I've been trying to think of a good usability analogy but have continually come up short. The best I can come up with is going to the library or book store. Let's say you know exactly where you want to go to browse for a book. Normally, you'd just walk in, go to the appropriate set of shelves, and start browsing. Now, let's say someone decided to force you to access the card catalog or store inventory list every time you walked in the door before you could begin looking at books... It's an extra added unnecessary step that makes the experience of going to the book store or library less enjoyable and take longer.) My additional vote (assuming we're getting to vote) would be just to have 2 links on the main screen - one to the browse map and one to the search map. Groundspeak should be able to collect usage data to see exactly how often each of those links is used.

Agreed. This came as something of an unwelcome shock when trying to search for a cache last night. (A bit of hyperbole there, but we still were surprised and disappointed by the change.) I would also like the ability to opt out of this new look - the old one worked fine and seems to me to be easier and more straightforward to use. Not every view on every Web site needs to be redone to look like a smartphone app. Was this change made in error or is this a permanent thing?

We used to leave gift cards for a local coffee shop/donut chain in our caches as FTF prizes. But we had the same 2 or 3 people getting all the FTFs so we stopped subsidizing their breakfasts. Then we switched to unactivated trackables as FTF prizes for our puzzle caches. More variety in FTFers and I like to think people appreciate the coins. As far as stuff we've found as FTF, I think a $5 bill was the biggest monetary prize. I don't recall ever seeing a new phone or GPSr as a FTF prize, although I do hear of people leaving them behind at caches from time to time.

I'll see your +1 and raise it x1000.

So, to clarify, is this for ALL Lab caches from now on (like at every Mega event)? Or is it only for those that form a series, like the Seattle ones near the Space Needle? Don't have a smartphone, have never needed one to function, not going to get one just for Lab caches. (Our idea of caching, for whatever type of cache we're looking for, is "load up the GPS, get outside, get away from constant interruptions" - giving the telemarketers an avenue for contacting us while we're outside enjoying the fresh air doesn't fly with me. Might sound old-fashioned, but my very nice flip phone spends 95% of its life turned off sitting in my car.)

As someone who does enjoy the trackable side game, I'm bumping this so it doesn't fall over the edge of the Internets. (To me, this is a more important fix than any of the "make GC.COM look like a phone app" changes - the TB info in the PQ is actually broken whereas I've encountered no problems significant enough to remember with the existing ("old") map, drafts, or profile pages.)

Kind of a mess, apparently, but there's https://coord.info/GC1R6A7. It's a brick shed/TB hotel. It looks like it may have fallen into a bit of disrepair. There's also something similar in West Virginia (maybe?).

We don't own smartphones, so we've only ever cached with GPSr's (although we have borrowed a friend's phone once or twice for Wherigo's). I keep my GPSr in my car and refresh the "50 mile radius of home" PQ once a week, so I'm covered for impromptu caching trips. We also have several overlapping PQs centered around work and a couple of other areas we frequent. These PQs are updated less often (once a month or whenever we think we'll be in the area). As to learning curves, we recently switched from Magellan after 7 years (due to equipment failure) to Garmin Oregons. Even though the two devices serve essentially the same purpose, they do it differently enough that we're still learning after 6 months.

Hmm... Interesting. It's like Y2K all over again. I wonder if anyone can find out specific models that would be affected (or, possibly easier, which models AREN'T affected). (For example, we have a vested interest in Oregon 650t's working properly.) It sounds like the dates will just cycle through the same 19+ year range unless they update the base date in the firmware (or made some other accommodation, as you pointed out). (It's too early for me to write a program to model this, but it sounds as if, with only 10 bits, you're limited to 1023 weeks from whatever the base week is and this will constantly reset to 0 whenever it rolls over into the 11th bit.)

Part of the '11 influx of cachers and proud of it! ? We've noticed (and been the victim of) TB's disappearing, never to be seen again, usually due to newbies. We've got a TB on a Hot Wheels car. Last I checked the TB was still going, but the car had changed. Twice! (At least it was upgraded to a better car.) Now, if only some of the long-time members could hold off grabbing TB's from us until we logged them into the correct cache... (long time pet peeve - drop a TB in a cache, get home 2 hours later and it's already been grabbed from us).

Fair enough. I was simply voicing my agreement with Max and 99. Perhaps I inferred too much when I mentioned this as a ploy to discover the trackable. I still find it odd that the TB page hasn't been updated.

Agreed that it sounds suspicious. Especially since the mission of the TB is to be discovered as many times as possible. And no update to the TB description or logs about how getting too close to the car may be dangerous because of it being stolen... Or "if found, please contact local authorities."

That certainly would explain the seemingly (to us) easy qualifications. In our area (WNY), the majority of the people we run into at events find way more than 92 caches in a year. Then again, there are plenty of cachers we know who don't go to events (and, presumably, even more that we DON'T know, since we never see them at events). Before I read the details of the scoring, I was hoping for some sort of sliding scale: 0-5 favorites = 1 point, 6-10 favorites = 2 points, 11-15 favorites = 4 pts, 16-20 favorites = 7 points, 21+ favorites = 10 points. I know this wouldn't work well in cache-sparse areas or cached-out areas. And would probably be confusing to many people. But then, I like math and there are plenty of areas we haven't cached in, even within 60 minutes of home.

Our Garmin Oregons can also list the trackables in a cache (assuming they're in the GPX info on the GPS). It was a feature we really enjoyed using once we got our new toys, until the PQs stopped providing the info.

Hmm... I just tried it and it worked. I wasn't timing it, but it took less than 10 minutes. When I clicked on the Add To Queue button, it did return me to the top of the page, but scrolling down towards the bottom I did see the 'your query has been added to the queue' message and the GPX was generated shortly thereafter. I have been avoiding the 'new' portions of the site as much as possible, so I have no idea if that could have any bearing on the situation.

In case the volume of posts on this issue gets it noticed, I'll add "not working for me, either." As we sometimes target caches purporting to contain trackables, it would be really nice if this could be fixed.

There's a few pretty neat caches in Hamburg, NY and the surrounding areas, plus the Eternal Flame EarthCache only a few minutes away. But I've never been to Hamburg, Germany.

Based on the image, it looks like we will be caching on DiscWorld.

We've got a caching friend with a geo-dog account. Not sure how often he logs in to the site, though. (The dog, that is.) We've got other friends with trackable pets, mostly dogs. Others have their current dog's name as part of their user account name.

Didn't know that. We're going to hold on to our space for as long as is possible, then.

Any updates on this issue? It's still happening as of yesterday.