Jump to content

New NM/NA system - can I still filter out caches with NMs?


L0ne.R
Followers 6

Recommended Posts

I'm breaking out into a cold sweat. It was bad enough finding so many unmaintained caches after setting PQs to filter out caches with a 'red wrench' (an NM log). Now does the new logging system where the NM is not a separate log, does it render the 'red wrench' moot?

Here's a screenshot of the new logging system:

 

fa1f28e9-a139-4601-ab51-bf727babffbd.png

Link to comment

I'm breaking out into a cold sweat. It was bad enough finding so many unmaintained caches after setting PQs to filter out caches with a 'red wrench' (an NM log). Now does the new logging system where the NM is not a separate log, does it render the 'red wrench' moot?

Here's a screenshot of the new logging system:

 

fa1f28e9-a139-4601-ab51-bf727babffbd.png

 

Go ahead and log a Find with Needs maintenance on one of my caches and let's see what happens.

 

Edited: typo

Edited by NanCycle
Link to comment

NanCycle looks like you'll have to OM my NM. Thanks again for making the sacrifice. :)

 

Editting to add: I forgot to screenshot the red wrench, but it's currently there until NC posts an OM.

 

Sure, I expected to have to OM it. All done and back to normal. Thanks for asking a question I'm sure others have wondered about, and some of us hadn't even considered yet.

Link to comment

Thanks for doing this experiment and sharing the results with the community!

 

And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)

Link to comment

Phew....it still works as it use to. A red wrench attribute was applied. Thank you for allowing me to test it on one of your caches. Here's a screenshot:

 

c780c484-c569-4071-a5f7-931a03163cdb.png

 

What does it do when a user selects, Needs Maintenance, and "Other" or "Cache should be Archived"? "Other" could mean many things, from the log is too wet to sign, to a link need in a puzzle cache no longer works.

Link to comment
And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.
Link to comment
And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

 

Yeah, I would have rather the wrench be integrated into the other log and perhaps some add-on descriptive note at the bottom explaining the maintenance issue. They got halfway there...

Link to comment
And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

If the person knows how to go back and edit the canned message, and if the person thinks about going back to edit the canned message. After they get past those two blocks, you get to "bothers to go back".

 

By the way, you mention the CO and anyone watching, but I assume the notification the reviewers get will also be that pre-edit message.

 

Yeah, I would have rather the wrench be integrated into the other log and perhaps some add-on descriptive note at the bottom explaining the maintenance issue. They got halfway there...

Halfway where? What you're describing was what the old system had. There's no significant advantage to combining the two different logs into a single log with two parts.

Link to comment

While it will be a problem in that this new system encourages less information, as a finder you can still do it "the old way".

 

1. Leave your find it log

2. Leave a "Write Note" describing the problem while checking Needs Maintenance.

 

This generates three logs instead of two, but what are you going to do when someone at GS is obsessed with streamlining the web interface for mobile usage.

 

With these changes, I expect that the app may be dropping its custom controls for logging, replacing them with a web view that calls the same html source as the website does for logging a find.

Edited by fbingha
Link to comment
And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

If the person knows how to go back and edit the canned message, and if the person thinks about going back to edit the canned message. After they get past those two blocks, you get to "bothers to go back".

 

By the way, you mention the CO and anyone watching, but I assume the notification the reviewers get will also be that pre-edit message.

I can see how you would reasonably make that assumption. But, I assure you, that is not how the system works. When I learn of the "Needs Archived" log, I will be reading its current text, not the original (canned) text. Using my daughter's account and one of the caches owned by my player account, I just tested it to be certain.

 

Like you said, though, I worry whether people will bother to edit the canned text. It will take me more time to decide how to act on requests when fewer details are given.

Link to comment
And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

If the person knows how to go back and edit the canned message, and if the person thinks about going back to edit the canned message. After they get past those two blocks, you get to "bothers to go back".

 

By the way, you mention the CO and anyone watching, but I assume the notification the reviewers get will also be that pre-edit message.

I can see how you would reasonably make that assumption. But, I assure you, that is not how the system works. When I learn of the "Needs Archived" log, I will be reading its current text, not the original (canned) text. Using my daughter's account and one of the caches owned by my player account, I just tested it to be certain.

 

Like you said, though, I worry whether people will bother to edit the canned text. It will take me more time to decide how to act on requests when fewer details are given.

 

As we're in testing mode, I wrote a note for GCM2FW. I chose "Other" as the explanation of the NM.

Link to comment

I use cachly for logging while on the road. When I find a cache that NM I currently have to log a NM and a found log. But I put the details (full log, wet log, broken container etc...) in the logs so that CO and future finders will know what I found.

This new method of allowing a single found / NM seems pretty good to me, as long as finders put details in the log.

 

Where I see a slight fly in the ointment is that a finder can click NM in the found log and not put any details about what's wrong. I know that with previous separate logging they can do the same, but previous method made you put _something_...

Link to comment

Where I see a slight fly in the ointment is that a finder can click NM in the found log and not put any details about what's wrong.

This isn't just a slight fly, it's a major problem. The interface explicitly reduces reporting problems to clicking a checkbox. There's no reason to even expect people to think they need to explain what's wrong in their find log. The interface makes it simple to file an NM for precisely the people that need to have their hands held the most when filing an NM.

 

This approach only works for people that are already aware that they're reporting a problem and need to explain it, and those people that will know full well how to file an NM by clicking the mouse another time or two. It's just gravy -- in my mind -- that switching to the second task of filing an NM log might cause them to switch from thinking about the problem from the point of view of their experience and consider it from the point of view of the CO that they're filing the NM for.

Edited by dprovan
Link to comment

Perhaps if they made a drop down list when the finder selected NM? And made the finder select one with a text block for "other"

How is that better than just entering a second log? It's the same amount of effort.

 

The thing that really irks me about this is that when I started geocaching, the separate NM seemed a little unexpected, but after I had some experience, I realized it was a very clever way to handle NMs: easy enough to find and understand for anyone thinking that they want to officially report a problem, and then when the feature was found, the problem reported is immediately put into a "report problem" mode that makes them think about the problem they're reporting. I was very impressed that someone who had really thought NM reporting through designed the system with the perfect balance of ease of use and functionality.

 

But some people don't really get it, so they write up their find logs, perhaps noting in passing some issue, and then want to make that a problem report after they wrote it up as an experience report. These people complained because it was So Much Work to post a second log with NM set and saying "see found log" (assuming it doesn't occur to them that they really could describe the problem better when they were focused on it). So to satisfy those people that didn't quite get it, then entire system who's thoughtfulness and efficiency impressed me so much is dismantled because, apparently, no one at GS remembers why it was invented.

 

And then people keep suggesting ways to add back features that were lost through changing the approach, and we end up with an example such as this where a suggestion takes the entire process back to being just exactly as much effort as it was originally, yet with this essential element eliminated so there's no longer any recognition of the idea that reporting a problem is an entirely different action that deserves its own explicitly entered log.

Link to comment

Perhaps if they made a drop down list when the finder selected NM? And made the finder select one with a text block for "other"

How is that better than just entering a second log? It's the same amount of effort.

 

The thing that really irks me about this is that when I started geocaching, the separate NM seemed a little unexpected, but after I had some experience, I realized it was a very clever way to handle NMs: easy enough to find and understand for anyone thinking that they want to officially report a problem, and then when the feature was found, the problem reported is immediately put into a "report problem" mode that makes them think about the problem they're reporting. I was very impressed that someone who had really thought NM reporting through designed the system with the perfect balance of ease of use and functionality.

 

But some people don't really get it, so they write up their find logs, perhaps noting in passing some issue, and then want to make that a problem report after they wrote it up as an experience report. These people complained because it was So Much Work to post a second log with NM set and saying "see found log" (assuming it doesn't occur to them that they really could describe the problem better when they were focused on it). So to satisfy those people that didn't quite get it, then entire system who's thoughtfulness and efficiency impressed me so much is dismantled because, apparently, no one at GS remembers why it was invented.

 

And then people keep suggesting ways to add back features that were lost through changing the approach, and we end up with an example such as this where a suggestion takes the entire process back to being just exactly as much effort as it was originally, yet with this essential element eliminated so there's no longer any recognition of the idea that reporting a problem is an entirely different action that deserves its own explicitly entered log.

 

I wasn't inferring better or worse... my suggestion was related to the thread about finders clicking NM and not explaining. Having the NM logger have to either select a canned "issue" or be forced to add some text (other) would at least give the CO some inkling as to why a NM was posted.

 

My comments weren't for experienced cachers who already know the ropes. I never log a NM with out at least explaining what I see that NM on the cache. Yes - I'm guilty occasionally of putting the details in the found log and referencing it in the NM. But either way, my CO knows why I think it NM...

 

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Link to comment

I wasn't inferring better or worse...

I was only taking your comment as a typical example: with GS having taken the left turn that completely destroys the basic advantages of the NM message, you were just one of a few people suggesting improvements to undo some of the damage, but those suggestions, while well intentioned, end up entrenching the basic mistake.

 

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Part of what I'm getting at is that this new approach is no worse in a few cases -- for some NM filers and for some COs -- but the change in approach is strategically bad and significantly worse for other cases. So, specifically, you will do just as well with a vacuous NM or a detailed NM, so either is fine, but we mustn't use your example to cloud the fact that for no COs is a vacuous NM better, and for some COs -- as you point out -- it's much worse. And, similarly, some seekers will write sufficient find or DNF logs so that taking on a NM flag will be ok, but for no seekers will that NM attachment be a better way of expressing the situation -- after all, their manually added "see find log", while also vacuous, still provides more information than these automatic NMs convey -- and for other seekers, they'll click the button to report the problem without actually saying anything in the find log about what the problem is.

Link to comment

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Some of my caches require a long hike through rugged terrain and/or a kayak paddle, so getting out to check on them can take the best part of a day. With NMs now saying only "This geocacher has reported a problem with this cache", how am I supposed to know in advance what I'll need to do at GZ? I could build a whole new cache and cart it out there only to find the problem is a broken pencil.

Link to comment

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Some of my caches require a long hike through rugged terrain and/or a kayak paddle, so getting out to check on them can take the best part of a day. With NMs now saying only "This geocacher has reported a problem with this cache", how am I supposed to know in advance what I'll need to do at GZ? I could build a whole new cache and cart it out there only to find the problem is a broken pencil.

I posted a NM "Other" yesterday as there was not a category that fitted. Once done it was just a simple matter of going to the cache page and doing a normal edit to fill in the details. No biggy.

BTW, the cache problem was that it was listed as a small when it was truely a micro and given where, and the way it is hidden, seekers would (and have) spent a lot of time looking in the wrong places. The NM was therefore meant for the CO to amend (i.e. maintain) the cache listing.

Link to comment

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Some of my caches require a long hike through rugged terrain and/or a kayak paddle, so getting out to check on them can take the best part of a day. With NMs now saying only "This geocacher has reported a problem with this cache", how am I supposed to know in advance what I'll need to do at GZ? I could build a whole new cache and cart it out there only to find the problem is a broken pencil.

I posted a NM "Other" yesterday as there was not a category that fitted. Once done it was just a simple matter of going to the cache page and doing a normal edit to fill in the details. No biggy.

BTW, the cache problem was that it was listed as a small when it was truely a micro and given where, and the way it is hidden, seekers would (and have) spent a lot of time looking in the wrong places. The NM was therefore meant for the CO to amend (i.e. maintain) the cache listing.

Except the email the CO gets will just be "This geocacher has reported a problem with this cache", they won't get your edited version unless they go and look at the logs on the cache page.

Link to comment

All my active caches are close to my home (<10 miles) so I drive by them almost daily or at least weekly. If there's a NM on one of mine, even without details, I can take a quick look. Other COs live much farther and aren't able to take a look for an unexplained NM...

Some of my caches require a long hike through rugged terrain and/or a kayak paddle, so getting out to check on them can take the best part of a day. With NMs now saying only "This geocacher has reported a problem with this cache", how am I supposed to know in advance what I'll need to do at GZ? I could build a whole new cache and cart it out there only to find the problem is a broken pencil.

I posted a NM "Other" yesterday as there was not a category that fitted. Once done it was just a simple matter of going to the cache page and doing a normal edit to fill in the details. No biggy.

BTW, the cache problem was that it was listed as a small when it was truely a micro and given where, and the way it is hidden, seekers would (and have) spent a lot of time looking in the wrong places. The NM was therefore meant for the CO to amend (i.e. maintain) the cache listing.

Except the email the CO gets will just be "This geocacher has reported a problem with this cache", they won't get your edited version unless they go and look at the logs on the cache page.

Which is what I normally do with any email notification.

Link to comment

I posted a NM "Other" yesterday as there was not a category that fitted. Once done it was just a simple matter of going to the cache page and doing a normal edit to fill in the details. No biggy.

BTW, the cache problem was that it was listed as a small when it was truely a micro and given where, and the way it is hidden, seekers would (and have) spent a lot of time looking in the wrong places. The NM was therefore meant for the CO to amend (i.e. maintain) the cache listing.

 

If we have to do those 2 steps, it's no more efficient than the legacy logging page AND the cacher posting the NM needs to know to go do that. In addition, the alert received by the CO is only the generic message. In the end... less efficient & less consistent.

Link to comment

While the ability to log a NM and a found in the same operation is new and we're talking about newbies not knowing how to log a NM, I'm sure that there were newbies that didn't know how to do it in 2 steps. Or were not inclined to go back and log the separate NM after the find.

 

While it's true that they're newbies, I'm confident that if they wanted to learn, they would. If they weren't inclined to learn or were too lazy to make the second log, well....

 

I look at the new ability to log a find and in the same log, send a NM to the CO as pretty convenient and I'm sure that more caches that NM will get NMs. How appropriate these NMs will be, that remains to be seen. But I know that myself (at least) and hopefully other experienced cachers would welcome and use this method.

 

For those newbies that don't know, perhaps an attitudeless note to them might help them learn - something like: "hey, I noticed you logged the NM without an explanation, and I know the help pages aren't clear, so if you don't mind, please include an explanation yadda yadda..." or some such.

 

If the directions on the help page are hard to find or understand, or the newbie is just plain lazy, one of the few options we have is to try to school them without alienating them. Hell, we can even send them a link to the instructions or this forum.

 

I'm confident that while we may not like them, the recent changes are probably here to stay. We can live with them, suggest changes, or stop caching.

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

Now THAT's going to cause more confusion than I though with the new change...

 

I can't think of a scenario where the different Nm date would be good to do. Can anyone else?

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

I haven't cached since this was implemented so I haven't logged anything. When you selected NM and then "may be missing" did it give you any opportunity to add detail? If not, and all that happened was the canned message in the post, then I don't think that the change is as convenient - unless we know and document in the found log, what we would have posted in the NM log.

The learning curve just got a bit hairier,,,

Link to comment

Also - think of a popular cache with several finds during the week. If all 5 finders determine that the broken container needs a NM, but look online and see no NM log, the CO could conceivably get a string of NMs depending on when the finds get uploaded...

 

And if the CO goes out and fixes it after the first, the others may be posted incorrectly after the owner maintenance was accomplished. Now THAT would be confusing. To all.

Sure, fixable by the CO, but not without a whole lot of communication and log editing and deletion. The CO would need to make sure that none of the "new" NM are legitimately new post-OM.

Link to comment

While the ability to log a NM and a found in the same operation is new and we're talking about newbies not knowing how to log a NM, I'm sure that there were newbies that didn't know how to do it in 2 steps. Or were not inclined to go back and log the separate NM after the find.

I have no problem discouraging NMs by people with so little experienced that they can't find the NM log type. People with more experience will show up and recognize the problem -- or not -- soon enough.

 

I look at the new ability to log a find and in the same log, send a NM to the CO as pretty convenient and I'm sure that more caches that NM will get NMs. How appropriate these NMs will be, that remains to be seen. But I know that myself (at least) and hopefully other experienced cachers would welcome and use this method.

Is it really that much more convenient? I know that's what everyone that's ever asked for this feature has claimed, but now that we have it, is it really any fewer mouseclicks? Besides, do you file NMs so frequently that maximum convenience is an issue?

 

For those newbies that don't know, perhaps an attitudeless note to them might help them learn - something like: "hey, I noticed you logged the NM without an explanation, and I know the help pages aren't clear, so if you don't mind, please include an explanation yadda yadda..." or some such.

I'm entirely unimpressed with the idea that we can, with lots of work, eventually train everyone to use the new system right when the old system basically lays out how to do it right.

 

I'm confident that while we may not like them, the recent changes are probably here to stay. We can live with them, suggest changes, or stop caching.

This change is almost certainly here to stay. That doesn't make it any less misguided.

 

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.scenario?

Maybe I'm misremembering, but I thought it had always been this way, even with the old form when logging an explicit NM through the website. I've been caught by this a few times, although, I have to admit, it might only have been on NAs. In the end, I decided there was a certain logic to it: the act of calling for maintenance really is happening when you post the log even when that's not the same day you visited the cache. And, on the other hand, if you meant to post the NM for today, but for one reason or another the system guessed you meant that past date, that would be even more confusing than the opposite problem of the two dates being different even though they were talking about the same event.

 

Although this made a heck of a lot more sense when the NM was being explicitly entered. Now we're going to have an automated, vacuous NM posted that makes absolutely no sense on its own being dated -- and listed -- a week after the find log that's supposed to have a description of the problem, with who knows how many other logs in between.

Link to comment

In the old method, NM and NA were separate logs just like the finds, and made you at least type in some text. So, if one was inclined to explain the NM / NA there was the ability. It appears that this is not the case with the new NM / canned text goes up and the logger needs to manually edit the initial log - inconvenient - and unless the logger really cares and wants to "do the right thing" it's not going to be done reliably.

 

The new method - going back and finding your log - is much less convenient than I initially thought. It's easier to make 2 logs - a find and a NM than to make the find, then go find the log and edit it. Just my opinion.

 

And yes, I log numerous NMs. If I find a soaked log, broken container, full log, etc... that I can't fix on the fly, I make the NM to allow the CO (and maybe subsequent finders) the ability to fix it. I don't just NM unless I can't remedy on the fly...

 

But there are a bunch of caches out there in crappy condition. And many novice cachers will just shrug and let them be.

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

I haven't cached since this was implemented so I haven't logged anything. When you selected NM and then "may be missing" did it give you any opportunity to add detail? If not, and all that happened was the canned message in the post, then I don't think that the change is as convenient - unless we know and document in the found log, what we would have posted in the NM log.

The learning curve just got a bit hairier,,,

 

No option to add detail.

 

This was a pretty rare scenario where I felt that "may be missing" was actually an appropriate thing to log, given that the guardrail was recently obliterated in a vehicle collision.

 

I log from field notes, so I guess from now on I'll just have to mention the maintenance issue in the found log and hope that's enough. I'm not changing my process to edit logs.

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

Now THAT's going to cause more confusion than I though with the new change...

 

I can't think of a scenario where the different Nm date would be good to do. Can anyone else?

Cache "Status" logs (Needs Maintenance, Needs Archived, Enable, Disable, Publish and Archive) have *always* been forced to default to the current date of the log - no backdating has ever been allowed. This prevents funny business caused by manipulating the dates of those log types.

 

Example: Finder A gets into a personal dispute with Owner B this week. A logs a "Needs Maintenance" on B's cache, but backdates their log to January. Then, A logs a "Needs Archived" the next day, saying that B has ignored the maintenance issue for months.

 

One can easily construct other examples that would be confusing to cache owners, reviewers, and/or players.

Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

I haven't cached since this was implemented so I haven't logged anything. When you selected NM and then "may be missing" did it give you any opportunity to add detail? If not, and all that happened was the canned message in the post, then I don't think that the change is as convenient - unless we know and document in the found log, what we would have posted in the NM log.

The learning curve just got a bit hairier,,,

 

No option to add detail.

 

This was a pretty rare scenario where I felt that "may be missing" was actually an appropriate thing to log, given that the guardrail was recently obliterated in a vehicle collision.

 

I log from field notes, so I guess from now on I'll just have to mention the maintenance issue in the found log and hope that's enough. I'm not changing my process to edit logs.

 

On a GRC or LPC I'm ok with suggesting that it may be missing. If it's a tricky one, then I'd think twice about suggesting a GRC was missing. But they're hard to miss... on other caches, I would log a dnf and in the log mention about looking etc...

 

I use cachly in the field and i understand that NM will remain a separate logging action. And - I don't upload in the field. I wait till I get home to turn the shorthand logs into a bit more verbose. So (I hope and believe that) my found and NM logs will go up with the same date and be sequential logs on GC. I rarely use the GC web page to make log entries as I have date time and sequence information on my cachly phone logs. But non cachly app users may have the problem.

Edited by WearyTraveler
Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

Now THAT's going to cause more confusion than I though with the new change...

 

I can't think of a scenario where the different Nm date would be good to do. Can anyone else?

Cache "Status" logs (Needs Maintenance, Needs Archived, Enable, Disable, Publish and Archive) have *always* been forced to default to the current date of the log - no backdating has ever been allowed. This prevents funny business caused by manipulating the dates of those log types.

 

Example: Finder A gets into a personal dispute with Owner B this week. A logs a "Needs Maintenance" on B's cache, but backdates their log to January. Then, A logs a "Needs Archived" the next day, saying that B has ignored the maintenance issue for months.

 

One can easily construct other examples that would be confusing to cache owners, reviewers, and/or players.

 

This makes sense.

 

I am far more concerned about the lack of detail in these status logs, and the canned options that aren't as relevant or useful as they ought to be.

Link to comment

But there are a bunch of caches out there in crappy condition. And many novice cachers will just shrug and let them be.

 

So if we don "fix" caches on the fly for CO's we are just novice cachers by letting them be? :blink:

 

I'm not in the habit of being a crappy cache enabler and fixin' junk the the CO should take care of, and posting a NM is not letting a cache be, it alerts the owner to take care of their geocache listing. :)

  • Upvote 1
Link to comment

I posted a comment on the cachly forum asking about its implementation of the found / Nm update.

They mentioned that it will still post the 2 logs - a found and a NM. But that the found log will be dated on the date that you created the found log, and the NM log will be dated on the date you're uploading it. Basically, if I cache all week, find and NM a cache on Monday, but don't upload till I'm at home on Saturday, the find and my NM will be separated by 5-6 days. On a seldom found cache, that doesn't seem too bad, but on a popular cache, the logs could be a page apart.

 

I haven't tested this out, so I may be spreading bad info. Has anyone tried this scenario?

 

Yes, it looks like that's what happened on a cache I found last weekend.

 

https://www.geocaching.com/geocache/GC2RJHH_micro-sur-la-300?guid=b30ecff1-8b00-471e-8065-5aa620a7a5cf

 

I logged it the following day, so my find log has the correct date of the find, and the NM log has a different date.

 

I haven't cached since this was implemented so I haven't logged anything. When you selected NM and then "may be missing" did it give you any opportunity to add detail? If not, and all that happened was the canned message in the post, then I don't think that the change is as convenient - unless we know and document in the found log, what we would have posted in the NM log.

The learning curve just got a bit hairier,,,

 

No option to add detail.

 

This was a pretty rare scenario where I felt that "may be missing" was actually an appropriate thing to log, given that the guardrail was recently obliterated in a vehicle collision.

 

I log from field notes, so I guess from now on I'll just have to mention the maintenance issue in the found log and hope that's enough. I'm not changing my process to edit logs.

 

On a GRC or LPC I'm ok with suggesting that it may be missing. If it's a tricky one, then I'd think twice about suggesting a GRC was missing. But they're hard to miss... on other caches, I would log a dnf and in the log mention about looking etc...

 

I use cachly in the field and i understand that NM will remain a separate logging action. And - I don't upload in the field. I wait till I get home to turn the shorthand logs into a bit more verbose. So (I hope and believe that) my found and NM logs will go up with the same date and be sequential logs on GC. I rarely use the GC web page to make log entries as I have date time and sequence information on my cachly phone logs. But non cachly app users may have the problem.

 

99% of the time I think it's foolhardy to make any claims about the cache being missing. If I have never found a cache, I don't know if it's hard to miss or not. Maybe I'm just having a ditzy day and I missed it. I will happily NM where needed to point out that several people have had trouble finding a cache, and that maybe we'd all appreciate it if the owner would confirm the cache's presence, but circumstances have to be pretty dire for me to actually come out and suggest the cache is missing. This is something I've learned through experience.

 

In this particular situation, several metres of the guardrail are now twisted wreckage down a steep incline, so I feel I can be forgiven for my hubris if it turns out that the cache is just on the ground somewhere we didn't spot it.

 

The reviewer commenting on this thread made a comment about the dates in another post that makes sense to me.

Link to comment

And yes, I log numerous NMs. If I find a soaked log, broken container, full log, etc... that I can't fix on the fly, I make the NM to allow the CO (and maybe subsequent finders) the ability to fix it. I don't just NM unless I can't remedy on the fly...

I don't doubt you log every appropriate NM, but what would surprise me is if you found that many caches with problems. Surely you find (or don't find) many more caches without thinking they need maintenance, don't you? That's why I was suggesting perhaps it's not that big a deal even if you have to file a second log to explain the problem. I always file NMs and NAs when they should be filed, perhaps more often than some people think I should, but so far this year I've logged 172 finds, about 45 DNFs, but only 6 NMs and no NAs, so it would be really hard for me to even pretend to have wasted any time because NMs are inefficient. I spend a lot more time thinking about whether I should file an NM than it actually takes to file an NM.

Link to comment

If this reads one of the developers, return the original NM logging option and don't change this system, please.

 

Or at least ask for an explanation of NM logos separately.

 

Why?

 

I'm Owner - If it comes NM log to email with log "This geocacher reported that there is a problem with this cache." I must go to web and find what happened. Previously I know it from log NM.

I'm Cacher - If I visited more caches I log it for long time (from PC) (I don't write only TFTC from mobil in terrain). That if I wait with NM log to my FI log - log NM can come for many days since my visit. But the NM log itself I wrote earlier, with old system... In new system it is not possible.

 

If you would like do it better, you may leave link to NM / NA log in logging page, but please in second step - Let people fill the NM/NA log. And leave possibility post NM/NA log separately. This is my point of view.

 

Thanks.

 

Sorry for my bad English

Link to comment

But there are a bunch of caches out there in crappy condition. And many novice cachers will just shrug and let them be.

 

So if we don "fix" caches on the fly for CO's we are just novice cachers by letting them be? :blink:

 

I'm not in the habit of being a crappy cache enabler and fixin' junk the the CO should take care of, and posting a NM is not letting a cache be, it alerts the owner to take care of their geocache listing. :)

Come on.. that's not what I meant...

 

A novice (generalization) will find a cache in crappy condition and log only the find. Someone has to fix the problem. If the CO doesn't, and I can replace a ripped baggy or broken container, or full log, why wouldn't I? Something about "doing a good turn...". Karma... whatever word you want to put...

 

And if you've been following my posts in this thread, I have no problem whatsoever logging a NM. I've logged 30 NM this year.

 

I've also seen found logs by non novices (>1000 finds) where their found log referenced broken containers or problems with the cache, yet no NM log. As a CO I don't read every found log immediately and something like this could get dropped. I do, however read NM NA etc...

Link to comment

No option to add detail.

 

You can add detail. Simply:

1. Log a note

2. Click the needs maintenance

3. Select the type (such as other)

4. Enter your note, which may just be "." if you wanted to add detail to your NA/NM note

5. Click Post

6. Scroll down and find your NM or NA note

7. Click on "Edit Log"

8. Click the pencil

9. Now put the information in the note you wanted to earlier

10. Submit it

11. Click the cache name to go back to the cache page

12. Find your "write note" message originally created

13. Click "edit log"

14. Click the red trash can

15. Click "Yes"

 

Easy-peasy. Just a few more steps than before.

Link to comment

No option to add detail.

 

You can add detail. Simply:

1. Log a note

2. Click the needs maintenance

3. Select the type (such as other)

4. Enter your note, which may just be "." if you wanted to add detail to your NA/NM note

5. Click Post

6. Scroll down and find your NM or NA note

7. Click on "Edit Log"

8. Click the pencil

9. Now put the information in the note you wanted to earlier

10. Submit it

11. Click the cache name to go back to the cache page

12. Find your "write note" message originally created

13. Click "edit log"

14. Click the red trash can

15. Click "Yes"

 

Easy-peasy. Just a few more steps than before.

 

No thanks. If my details were important, the interface wouldn't be set up like that. I assume from the design that details aren't of interest anymore.

Link to comment

Cache "Status" logs (Needs Maintenance, Needs Archived, Enable, Disable, Publish and Archive) have *always* been forced to default to the current date of the log - no backdating has ever been allowed. This prevents funny business caused by manipulating the dates of those log types.

 

Example: Finder A gets into a personal dispute with Owner B this week. A logs a "Needs Maintenance" on B's cache, but backdates their log to January. Then, A logs a "Needs Archived" the next day, saying that B has ignored the maintenance issue for months.

 

One can easily construct other examples that would be confusing to cache owners, reviewers, and/or players.

I guess this doesn't apply to the API. I've backdated NM logs several times (yes, I did check the recent logs first)...

Link to comment

Phew....it still works as it use to. A red wrench attribute was applied. Thank you for allowing me to test it on one of your caches. Here's a screenshot:

 

c780c484-c569-4071-a5f7-931a03163cdb.png

 

And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

 

Yeah, I would have rather the wrench be integrated into the other log and perhaps some add-on descriptive note at the bottom explaining the maintenance issue. They got halfway there...

 

And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)
Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

If the person knows how to go back and edit the canned message, and if the person thinks about going back to edit the canned message. After they get past those two blocks, you get to "bothers to go back".

 

By the way, you mention the CO and anyone watching, but I assume the notification the reviewers get will also be that pre-edit message.

 

Yeah, I would have rather the wrench be integrated into the other log and perhaps some add-on descriptive note at the bottom explaining the maintenance issue. They got halfway there...

Halfway where? What you're describing was what the old system had. There's no significant advantage to combining the two different logs into a single log with two parts.

 

Halfway there...as in, two parts to one log. Something like this:

 

hRyntfQ.png

 

Significant or not, there's still an advantage to not having to go back and edit a separate log, possibly separated by days if what I'm hearing is correct. One visit, one date, one log with two parts.

Edited by J Grouchy
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 6
×
×
  • Create New...