Placement ban due to Divisiveness?

[+Panther in the Den]

The topic of quality reminds me of when they briefly brought back Virtuals. I don't think it will work here either as it is too subjective.

What about health?

 

Can we agree on what constitutes a healthy cache?

There are tools already to help with keeping caches healthy. I think the primary issue here is quality or maybe the unspoken density.

I disagree but an answer to the question would still be nice.

At the low end = A log dry enough to leave your mark. Doesn't even have to be perfectly dry.

At the upper end = A waterproof container clearly labeled GEOCACHE with a Geocaching datasheet, dry logsheet and pencil.

Edited January 10, 2017 by Panther in the Den

[+Panther in the Den]

The topic of quality reminds me of when they briefly brought back Virtuals. I don't think it will work here either as it is too subjective.

That must have been prior to my joining in 2007, unless you're talking about challenges.

When I started back on April of '04 you could publish virtuals and then they banned them. Brought them back before July with the requirement that they should be have 'quality' which I never determined how that was agreed upon.

 

This is one that squeaked through... https://www.geocaching.com/geocache/GCJZDR_cloud-gate-aka-the-bean

 

Shortly thereafter they were banned altogether with, I believe, the creation of Waymarking.

Edited January 10, 2017 by Panther in the Den

[+Wet Pancake Touring Club]

Here's an off-the-wall idea. What if logging a find had a few more 'survey' questions? As Panther in the Den noted, there are some tools for keeping caches healthy. But, DNF/NM/NA have some drawbacks also. Maybe they could change the logging so that the status could be derived from a small set of questions. I'm not sure what those questions might be, but that has never stopped me from throwing out incomplete ideas before.

 

1. If you make logging more complicated, it stands to reason that you'll discourage people (particularly newbies) from logging anything. Unless they're crafted awfully carefully, the information gathered from the survey questions might not make up for the lost logs. I'm not saying it's not possible, but it's gotta be carefully done.

 

2. As you note, there are already simple feedback mechanisms available: DNF/NM/NA. The fact that even those mechanisms are under-utilized (and, alas, discouraged by some COs) makes me wonder how any other feedback mechanism could work. Maybe we could start by promoting the proper use of the existing tools.

I was thinking more along the lines of a couple of checkboxes when logging a find. It would be something on the logging page, not a separate page or step. It might be that one of the reasons people don't do NM logs is that they require logging the cache a second time, and they just don't want the bother. If we had checkboxes for things such as 'log was full', 'container had water in it', 'cache is a throwdown', etc., these would be reported to the CO. Maybe GS would go so far as to automatically generate a NM log.

[+Team Microdot]

Here's an off-the-wall idea. What if logging a find had a few more 'survey' questions? As Panther in the Den noted, there are some tools for keeping caches healthy. But, DNF/NM/NA have some drawbacks also. Maybe they could change the logging so that the status could be derived from a small set of questions. I'm not sure what those questions might be, but that has never stopped me from throwing out incomplete ideas before.

 

1. If you make logging more complicated, it stands to reason that you'll discourage people (particularly newbies) from logging anything. Unless they're crafted awfully carefully, the information gathered from the survey questions might not make up for the lost logs. I'm not saying it's not possible, but it's gotta be carefully done.

 

2. As you note, there are already simple feedback mechanisms available: DNF/NM/NA. The fact that even those mechanisms are under-utilized (and, alas, discouraged by some COs) makes me wonder how any other feedback mechanism could work. Maybe we could start by promoting the proper use of the existing tools.

I was thinking more along the lines of a couple of checkboxes when logging a find. It would be something on the logging page, not a separate page or step. It might be that one of the reasons people don't do NM logs is that they require logging the cache a second time, and they just don't want the bother. If we had checkboxes for things such as 'log was full', 'container had water in it', 'cache is a throwdown', etc., these would be reported to the CO. Maybe GS would go so far as to automatically generate a NM log.

 

Checkboxes are a really limited way of conveying complex information. The existing system is far more flexible and I think suited to the task.

[+Wet Pancake Touring Club]

Here's an off-the-wall idea. What if logging a find had a few more 'survey' questions? As Panther in the Den noted, there are some tools for keeping caches healthy. But, DNF/NM/NA have some drawbacks also. Maybe they could change the logging so that the status could be derived from a small set of questions. I'm not sure what those questions might be, but that has never stopped me from throwing out incomplete ideas before.

 

1. If you make logging more complicated, it stands to reason that you'll discourage people (particularly newbies) from logging anything. Unless they're crafted awfully carefully, the information gathered from the survey questions might not make up for the lost logs. I'm not saying it's not possible, but it's gotta be carefully done.

 

2. As you note, there are already simple feedback mechanisms available: DNF/NM/NA. The fact that even those mechanisms are under-utilized (and, alas, discouraged by some COs) makes me wonder how any other feedback mechanism could work. Maybe we could start by promoting the proper use of the existing tools.

I was thinking more along the lines of a couple of checkboxes when logging a find. It would be something on the logging page, not a separate page or step. It might be that one of the reasons people don't do NM logs is that they require logging the cache a second time, and they just don't want the bother. If we had checkboxes for things such as 'log was full', 'container had water in it', 'cache is a throwdown', etc., these would be reported to the CO. Maybe GS would go so far as to automatically generate a NM log.

 

Checkboxes are a really limited way of conveying complex information. The existing system is far more flexible and I think suited to the task.

I am not proposing replacing the existing system, but instead augmenting it by calling out a few, very specific, common cache maintenance problems. If it is complex, a separate NM log will be needed. All checking the box would do is send an e-mail to the CO. By the way, I am against these checkboxes automatically generating NM logs. However, GS might chose to implement the checkboxes in this manner, so as to minimally affect other processes that they and reviewers use.

[+L0ne.R]

The topic of quality reminds me of when they briefly brought back Virtuals. I don't think it will work here either as it is too subjective.

What about health?

 

Can we agree on what constitutes a healthy cache?

There are tools already to help with keeping caches healthy. I think the primary issue here is quality or maybe the unspoken density.

I disagree but an answer to the question would still be nice.

At the low end = A log dry enough to leave your mark. Doesn't even have to be perfectly dry.

At the upper end = A waterproof container clearly labeled GEOCACHE with a Geocaching datasheet, dry logsheet and pencil.

 

At the low end = no cache but an active cache listing (that doesn't have an NA and reviewer disable note i.e. destined for archival) so the finder can throwdown their pill bottle, claim that the cache is alive and well, and collect their find.

[+Team Microdot]

The topic of quality reminds me of when they briefly brought back Virtuals. I don't think it will work here either as it is too subjective.

What about health?

 

Can we agree on what constitutes a healthy cache?

There are tools already to help with keeping caches healthy. I think the primary issue here is quality or maybe the unspoken density.

I disagree but an answer to the question would still be nice.

At the low end = A log dry enough to leave your mark. Doesn't even have to be perfectly dry.

At the upper end = A waterproof container clearly labeled GEOCACHE with a Geocaching datasheet, dry logsheet and pencil.

 

At the low end = no cache but an active cache listing (that doesn't have an NA and reviewer disable note i.e. destined for archival) so the finder can throwdown their pill bottle, claim that the cache is alive and well, and collect their find.

 

LMAO

 

Many a true word spoken in jest

[+narcissa]

I was thinking more along the lines of a couple of checkboxes when logging a find. It would be something on the logging page, not a separate page or step. It might be that one of the reasons people don't do NM logs is that they require logging the cache a second time, and they just don't want the bother. If we had checkboxes for things such as 'log was full', 'container had water in it', 'cache is a throwdown', etc., these would be reported to the CO. Maybe GS would go so far as to automatically generate a NM log.

 

When I write a review on TripAdvisor, it sometimes sends me to a page (after I submit the review) that asks basic questions like "Does this restaurant serve Italian food?" or "Is this restaurant suitable for a business meeting?" that I think it uses to augment the listing. I wouldn't be opposed to being asked questions like "Was this cache in good condition when you found it?" or "Is this cache appropriate for children?" but I don't really know how the system should handle that sort of information.

 

One of the issues of the game I am very concerned about is that many power finders are now writing deliberately false logs that they copy and paste into each find, claiming that every cache is in good condition (I noticed this because Earthcache logs tend to stand out when they refer to the container and the logbook). I believe this is a deliberate action by a particular faction of the game, intended to circumvent sincere efforts to weed out poorly-maintained geocaches. If there was a direct way to elicit contradictory feedback from honest geocachers, maybe it would help.

[+thebruce0]

If the additional checkboxes are additions to a log, then log-posting can happen the same way, and apps or the websites can ask a sort of followup question that could set flags/alert the CO. If someone closes the window after posting the log, nothing lost.

I don't see a problem with it. Only downfall? Annoyed finders constantly clicking the checkboxes to get on a CO's nerves if there isn't really any problem. Otherwise assuming they're only checked if true, then the CO is rightly informed of issues needing attention that aren't necessarily worth a full Needs Maintenance log (but a finder can still post one if they feel a wet log is worth a NM, eg).

[+DragonsWest]

If the additional checkboxes are additions to a log, then log-posting can happen the same way, and apps or the websites can ask a sort of followup question that could set flags/alert the CO. If someone closes the window after posting the log, nothing lost.

I don't see a problem with it. Only downfall? Annoyed finders constantly clicking the checkboxes to get on a CO's nerves if there isn't really any problem. Otherwise assuming they're only checked if true, then the CO is rightly informed of issues needing attention that aren't necessarily worth a full Needs Maintenance log (but a finder can still post one if they feel a wet log is worth a NM, eg).

 

Perhaps logging attributes? Check all that apply:

 

Log full

Damaged container

Coords significantly off

Wet/damaged contents

Posted size does not match actual

On private property and I'm in the county jail, come bail me out

[+dprovan]

Perhaps logging attributes? Check all that apply:

I'm glad you provided a list, because it helped me focus on why I don't think these checkboxes are useful. In each case, checking a box is not sufficient information, so the check box gives the log writer the illusion of being helpful without actually being helpful:

 

"Log full": You mean really full, or do you mean it's full but there's room in the margins, or do you mean there's only a slot or two left?

 

"Damaged container": How is it damaged? Describe what you found, because you may not have found the actual container.

 

"Coords significantly off": The Worst! Saying the coordinates are off is completely pointless unless you say what you think the coordinates should be. Besides, you can already attach coordinates, so why would you need a check box?

 

"Wet/damaged contents": Can you be less specific?

 

"Posted size does not match actual": What should the size be?

 

"On private property...": Without any details, it's impossible for the CO to tell whether you have important additional information he needs, or you just think you know something that the CO is already aware of and isn't the problem you think it is.

 

"...and I'm in the county jail, come bail me out": What?! You want that to be a check box? I want to see the story in the log!

 

In short, in every case, the checkbox provides no useful information, and the information that would be useful can (and should) already be put in the log.

[+thebruce0]

I do think the list is too long. But some of the most common complaints that often result in NM, a couple of them can be helpful. If the CO is informed in some manner, so not a public flag that everyone can see, it can be a help for the CO to know which owned caches currently have a reported issue. If it's not an issue, the owner can simply ignore or remove the flag. But especially for people with loads of caches, it can be organizationally helpful.

 

I imagine a cache report, showing say a number of outstanding 'log full' flags (or maybe a more generic 'logbook needs attention'). It might be that a CO ignores them, or keeps them up as a reminder to visit that cache, or clears them out because they don't care about it (but at least they have to actively remove the 'annoyance' which could entice some to actually do some maintenance).

But I think the idea of the feature for finders provides a little bit more agency for helping address the condition of local cache containers, and it provides COs a more streamlined 'nudge', as it were, that they may not get if they ignore the text of Find logs, or there are simply too many to follow and search for known issues.

Finders can ignore the checkboxes, just as COs can ignore the status flags.

 

But yeah, too many options would be excessive; and there could be an endless list of stuff people could suggest as flags. You could write your find log with checkboxes So no, it would definitely need to be limited to a select few, if at all.

[+DragonsWest]

Perhaps logging attributes? Check all that apply:

I'm glad you provided a list, because it helped me focus on why I don't think these checkboxes are useful. In each case, checking a box is not sufficient information, so the check box gives the log writer the illusion of being helpful without actually being helpful:

 

"Log full": You mean really full, or do you mean it's full but there's room in the margins, or do you mean there's only a slot or two left?

 

"Damaged container": How is it damaged? Describe what you found, because you may not have found the actual container.

 

"Coords significantly off": The Worst! Saying the coordinates are off is completely pointless unless you say what you think the coordinates should be. Besides, you can already attach coordinates, so why would you need a check box?

 

"Wet/damaged contents": Can you be less specific?

 

"Posted size does not match actual": What should the size be?

 

"On private property...": Without any details, it's impossible for the CO to tell whether you have important additional information he needs, or you just think you know something that the CO is already aware of and isn't the problem you think it is.

 

"...and I'm in the county jail, come bail me out": What?! You want that to be a check box? I want to see the story in the log!

 

In short, in every case, the checkbox provides no useful information, and the information that would be useful can (and should) already be put in the log.

 

Of course I'm mocking the idea, lightly anyway, but when it comes down to it I read most of the logs on my caches and try to keep track of which ones have Full log, wet log, etc. where finders don't actually leave me a Needs Maint. (or even more helpfully SBA ) so a quick review, before I head out the door is a few wrenches, but not much more helpful information.

 

As a CO with only about 200 hides I think it would be great to have some summary info on my caches, but I can't expect GC to do this as everything has to be a profit/loss decision with them and does anyone realistically think they'll see any gain in coding such attributes or helpful reminders?

 

In the mean time I need to go back through some of the more recent logs to evaluate if someone was just having a bad day or the cache really requires a visit. I do appreciate those kind-hearted people who (like myself) bring along strips of extra log sheet paper to keep our gawdawful caches on life support.

[+Wet Pancake Touring Club]

 

In short, in every case, the checkbox provides no useful information, and the information that would be useful can (and should) already be put in the log.

 

I beg to differ. No useful information to whom? There are a number of people that could be interested. For the checkbox, the CO would get an e-mail letting them know that someone thinks there is an issue with their cache. (This email would be separate from the found it/DNS/write note log e-mail, so that the CO can filter it appropriately.) Is it enough information to act on? Maybe, it would depend on the contents of the log entry that goes with it. At the very least, communications will have started. Maybe we add the checkbox information to the log so that other future seekers know about it. Other watchers on the cache might also be notified, in the event that there are multiple maintainers for the cache. Groundspeak could use it to tweak their 'there may be problems with this cache' automated e-mail algorithm. Reviewers could take it into consideration when doing their routine sweeps for abandoned caches. Heck, if the info is made available to third parties, then project-gc could assign rankings, and BadgeGen could create badges. OK, maybe that last thought went too far.

 

Is the information as complete as everyone would like? Probably not. Is it more than we have now? I think yes. There is nothing to guarantee that the log would contain anything useful either. So, I think we still come out ahead. There have been times when I have deliberately not included details in a NM log. In one case, it was because the cache was a gadget cache that was broken in such a way that the cache still worked, but the broken off piece uncovered the core mechanism of the cache. I did not put anything about the way that it was broken into my NM log, as that would give away the secret after the CO repaired the cache. I did the NM log because it was a very popular cache, and I knew that the CO responded quickly to NM logs. The details were in a private e-mail, so that he could decide whether to build a replacement cache, or attempt a field repair.

 

My idea is not to replace NM. My underlying assumption is that some people don't do NM logs because it is a hassle to go and create a second log. What I am trying to do is streamline that part of the process for them. And, regarding log entry types, I think that the NM and NA logs on a cache are poorly handled. These are usually logged in conjunction with a found it, DNF or write note log. So, why don't we try to streamline the whole logging process. If a logger checks one of the check boxes, the next page asks for more details. Regardless of whether they enter any details, I think we are ahead of where we are currently.

 

If someone chooses not to use the checkboxes, logging takes no more time than it currently does. And even if they do, but don't enter any details, the logger is not impacted. The impact would be to the CO's. They would have to decide how they want to process this new type of e-mail. And they have choices. They could read them, filter them, ignore them, etc. It is under their control. This might take a one time filter setup, or a one time filter setup for each cache.

 

I have no idea what the programming would require. But to me (I am a programmer), it doesn't appear to be great. Little impact to the user community. And a possible improvement in cache quality. How much is subjective, but low risk, low cost, possible improvement in cache quality.

[+thebruce0]

The nice thing, lots of features take just 'a little programming' Unfortunately we don't know the backend system at GS, apart from that they use ASP.NET. That said, with so many little suggestions floated around that each require little programming, I'm sure there's also a layer of decision for how they can be optimized or combined, to minimize cost, and maximize efficiency and user experience; and then the decision makers need to be convinced that it's worth the development. Corporate life. Oh and then there are inevitable bugs and growing pains as issues are weeded out (this tends to happen fairly often as we know). But hey, all we can do is discuss and hone the ideas, and hope some lackey sees merit in them and takes the ideas to the dev team and TPTB.

 

As for the feature, personally I'd recommend against sending an email every time someone posts a log with a checked box. It could very quickly become a spamming annoyance. We don't want active annoyance for any user, but, a passive reminder of outstanding issues with minor UI impact (like the Inbox), allowing the user to 'opt in' and view and deal with them I think would be the better route were the feature to be developed. Perhaps a weekly digest email summary at most.

[+dprovan]

I beg to differ. No useful information to whom? There are a number of people that could be interested. For the checkbox, the CO would get an e-mail letting them know that someone thinks there is an issue with their cache.

If the cache needs maintenance, there's already a log for that where you explain what's wrong instead of just saying "something's wrong!". Posting an NM sends e-mail to the owner. It also sets a flag so other seekers will know there's a problem and can look for the NM log to see what the problem is.

 

The checkbox proposal duplicates the same function, but in a vastly inferior way. So inferior, in fact, that I don't think I'd consider it worth the effort even if NM didn't exist.

[+thebruce0]

If the cache needs maintenance, there's already a log for that where you explain what's wrong instead of just saying "something's wrong!". Posting an NM sends e-mail to the owner. It also sets a flag so other seekers will know there's a problem and can look for the NM log to see what the problem is.

 

The checkbox proposal duplicates the same function, but in a vastly inferior way. So inferior, in fact, that I don't think I'd consider it worth the effort even if NM didn't exist.

 

Whereas I see its value (as a finder and as a CO) specifically apart from the emailing feature. So... yeah, if it emailed, I agree it would duplicate much of the same functionality. I wouldn't personally prefer to see that. But the non-emailling flagged issues with caches that are not (necessarily) NM-log-worthy, yeah, I could see value in that. (some people may, some people may not)

Edited January 11, 2017 by thebruce0

[+Team Microdot]

But the non-emailling flagged issues with caches that are not (necessarily) NM-log-worthy, yeah, I could see value in that. (some people may, some people may not)

 

As a CO I wouldn't say I'm happy to get an NM log / email but it's something I accept and take responsibility for as that's what I signed up for and if ever I decide otherwise I'll archive my caches and free up the spaces for someone else.

 

Issues which are not NM-log-worthy - why should I care?

[+thebruce0]

Then don't But I would. This really is a matter of preference...

I know wet/full logs are often not mentioned, let alone prompting a NM post. This would give finders a chance to easily 'note' that state if they wish; and I wouldn't necessarily want every instance of a 'wet log' report to generate an email or public NM flag on the cache. So I'd value providing the finder a way to give that information, dropped into a passive notification box I can deal with on my time, and unflag if someone else is kind enough to replace the log. But, that would be my justification based on my own preference.

And ultimately, the same process and functionality as currently exists would still be available to finders and owners. Nothing would change in that way. (people may still post NM for wet logs, or owners may simply ignore minor flags and only pay attention to NM logs as exist now).

[+dprovan]

But the non-emailling flagged issues with caches that are not (necessarily) NM-log-worthy, yeah, I could see value in that. (some people may, some people may not)

It makes no sense to me to set a flag if the flag doesn't imply that the problem should be fixed. Besides that showing that the problem just isn't that important to begin with, it means that if the CO doesn't think it's important enough to take any action, then the flag will never be cleared even when whatever problem was being noted eventually is resolved in the course of events.

[+Team Microdot]

Then don't But I would. This really is a matter of preference...

I know wet/full logs are often not mentioned, let alone prompting a NM post. This would give finders a chance to easily 'note' that state if they wish; and I wouldn't necessarily want every instance of a 'wet log' report to generate an email or public NM flag on the cache. So I'd value providing the finder a way to give that information, dropped into a passive notification box I can deal with on my time, and unflag if someone else is kind enough to replace the log. But, that would be my justification based on my own preference.

And ultimately, the same process and functionality as currently exists would still be available to finders and owners. Nothing would change in that way. (people may still post NM for wet logs, or owners may simply ignore minor flags and only pay attention to NM logs as exist now).

 

Bluntly (as is my wont) - seems like a waste of time and effort and unnecessary complication.

 

The only benefit I can see to this is that it might guide those who know no better to report things which they wouldn't ordinarily report because they don't realise it's expected of them, but if this check-box method were put in place personally I would have it instead of the NM log rather than in addition to.

 

I'd have it so that checking a maintenance related box revealed a text box to solicit more details in a similar way to the way I think adding coordinates to a log works.

 

Then I'd ensure that those extra details were appended to the email you receive detailing the Found It / DNF log. The idea of some passive list that you can look it if and when you happen to feel the urge would, for me, take us back toward the waste of time and effort end of the scale.

[+Team Microdot]

But the non-emailling flagged issues with caches that are not (necessarily) NM-log-worthy, yeah, I could see value in that. (some people may, some people may not)

It makes no sense to me to set a flag if the flag doesn't imply that the problem should be fixed. Besides that showing that the problem just isn't that important to begin with, it means that if the CO doesn't think it's important enough to take any action, then the flag will never be cleared even when whatever problem was being noted eventually is resolved in the course of events.

 

^^This

[+thebruce0]

Ok. You don't have to prefer the feature like I would

I'm not convinced that it would be worthless, because your examples really are based on how you would, or would expect others would, use the feature. I don't see a concern that I agree would be a universal problem with it. If it were developed, I would use it exactly as I said I would, because I see value in providing the added ability for finders to flag concerns they may not believe important enough to be worth a public NM flag, and a passive 'attend to these if you can' list that no one has deemed of immediate dire concern, I would find useful.

 

I don't disagree that the NM log can also be used to note such 'minor' issues, but that doesn't have to change.

Of course if GS believes that something like a 'wet log' IS indeed worthy of a public NM alert (which is entirely possible), then forget all I've said

 

.... anyway I just realized this has nothing to do with the OP. So I'll end my input here, unless another thread opens. *shrug*

[+Team Microdot]

I see value in providing the added ability for finders to flag concerns they may not believe important enough to be worth a public NM flag, and a passive 'attend to these if you can' list that no one has deemed of immediate dire concern, I would find useful.

 

.... anyway I just realized this has nothing to do with the OP. So I'll end my input here, unless another thread opens. *shrug*

 

Well, if we return to the general theme of the OP and its connected issues...

 

In a world where I risk CO scorn / abuse for posting a public NM log I might get scared, capitulate and use your suggested well, you know, there is a problem, but I don't want trouble check boxes that the CO will ignore and I'll have to resign myself to the fact that others might waste their time, through lack of the useful information my NM would have provided, searching for a cache that isn't there or isn't fit to be found.

 

What a sad state of affairs. Is that really what we want? Seriously? If it is - we might as well all throw in the towel right now because that's about as far removed from the vision I had of what geocaching was all about as a fresh-faced newbie as we could get.

 

Just thinking about it leaves me feeling depressed.

 

EDIT: Typo

Edited January 11, 2017 by Team Microdot

[+redsox_mark]

 

Of course if GS believes that something like a 'wet log' IS indeed worthy of a public NM alert (which is entirely possible), then forget all I've said

 

In the Help Center , a wet log is one of the examples given for when a NM should be raised.

 

If GS were to add some check boxes it wouldn't bother me, but I think the current logs are enough. I get information on the state of my caches from all logs, including "found". Often someone will mention a "damp but signable" log in their found log; but a wet as pulp log would raise a NM. But that's not consistent. I did some maintenance the last couple of days, and from the logs I could see that the most urgent issues didn't have NM, while some trivial issues did. Nothing I can do about that, each finder uses their judgement.

 

One of the NMs was because, after a few DNFs, I checked and the cache wasn't there, so I replaced it. But it seems the original cache is there, somewhere nearby - just not where I did it. Someone found both and raised a NM for me to remove one. I checked it today, I can't find the second one. It may be there, but I can't find it. I logged OM. I tried.

[+thebruce0]

In a world where I risk CO scorn / abuse for posting a public NM log I might get scared, capitulate and use your suggested well, you know, there is a problem, but I don't want trouble check boxes that the CO will ignore and I'll have to resign myself to the fact that others might waste their time, through lack of the useful information my NM would have provided, searching for a cache that isn't there or isn't fit to be found.

Well, that is the world we live in, and people do that already, not posting NM for fear of scorn.

Also, that would be a problem with the CO, not the player. Also also, the "I don't want trouble check-boxes" at least allow the user to do their part privately and leave the next responsibility up to the CO; to wash their hands of it without drawing potential public shame/scorn, but at least doing more than ignoring the problem entirely from fear. As a CO it would still be no loss to ignore it as they wouldn't have known anyway since the user wouldn't have said anything otherwise. Again, it's only added information, not a change and not a loss, and no public attention is drawn either direction. Still not seeing the problem...

 

If this CO's "divisiveness" problem was related to cache maintenance, then it may be safe to presume that they were either ignoring or deleting NM logs without due maintenance, so their 2500+ hides weren't actually in good condition, and there were .. disagreements because of it. If the CO is willing to do that, then they're likely already of the mindset to either ignore or clear any such notice flags in a feature like these checkboxes. So, no loss there, just ignorance to helpful added information.

 

Plus, imagine the annoyance if the 2500+ owner did receive an email for every log that received a checkmark for minor cache issues. That would be something I'd think more people would actually come to ignore, than a straight-forward page they can choose to view listing owned caches and significance of any issues reported that the CO should consider dealing with before they become maintenance problems that the community will be much more willing to report with NM for others to best be aware of (broken container, bad coordinates, construction, etc).

 

(ETA: Consider, owning 2500+ caches, the page can sort by problem significance, number of reports; so the CO could plan a log replacement day, visiting all the caches that he deems should have new logs. Another day it's tending to a different problem; etc. Just a thought on the concept)

 

*shrug* Has this CO's "divisiveness" problem ever been clarified? I don't recall, and don't think it will (or should) be, as it really was not our concern to begin with given it was a private communication. Even so, I'm definitely not of the mindset that this 'placement restriction' is merely because of placement count, but must be somehow tied to it.

 

In the Help Center , a wet log is one of the examples given for when a NM should be raised.

 

If GS were to add some check boxes it wouldn't bother me, but I think the current logs are enough. I get information on the state of my caches from all logs, including "found". Often someone will mention a "damp but signable" log in their found log; but a wet as pulp log would raise a NM. But that's not consistent. I did some maintenance the last couple of days, and from the logs I could see that the most urgent issues didn't have NM, while some trivial issues did. Nothing I can do about that, each finder uses their judgement.

Yeah, right now pretty much anything that should require owner attention is sufficient for a NM log. But as you said, some may people consider a pulp log immediate NM, some consider it a minor annoyance (they aren't required to log a NM, but have the option). I know plenty of cachers who don't log NM, regardless of the state of the logsheet, and merely mention its state in a found log. In those cases, with one click they'd have the ability to alert the CO without going through the major step of a NM (though others could still choose to post that as a NM). Each finder does indeed use their judgement! And this would give them one more option.

 

I agree, the current logs are sufficient; just not consistently used. I would however not be opposed to such a feature existing, and would certainly make use of it!

 

One of the NMs was because, after a few DNFs, I checked and the cache wasn't there, so I replaced it. But it seems the original cache is there, somewhere nearby - just not where I did it. Someone found both and raised a NM for me to remove one. I checked it today, I can't find the second one. It may be there, but I can't find it. I logged OM. I tried.

Imagine owning 2500+ caches and having that experience with many of them regularly I don't envy this guy; but at the same time, I really don't think that's practical, and can understand the spirit of the action taken even if we don't know the details about why. yeeshk.

Edited January 11, 2017 by thebruce0

[+Team Microdot]

In a world where I risk CO scorn / abuse for posting a public NM log I might get scared, capitulate and use your suggested well, you know, there is a problem, but I don't want trouble check boxes that the CO will ignore and I'll have to resign myself to the fact that others might waste their time, through lack of the useful information my NM would have provided, searching for a cache that isn't there or isn't fit to be found.

Well, that is the world we live in, and people do that already, not posting NM for fear of scorn.

Also, that would be a problem with the CO, not the player. Also also, the "I don't want trouble check-boxes" at least allow the user to do their part privately and leave the next responsibility up to the CO; to wash their hands of it without drawing potential public shame/scorn, but at least doing more than ignoring the problem entirely from fear. As a CO it would still be no loss to ignore it as they wouldn't have known anyway since the user wouldn't have said anything otherwise. Again, it's only added information, not a change and not a loss, and no public attention is drawn either direction. Still not seeing the problem...

 

And that IS the problem - your proposed system - as you've chosen to implement it - is geared TOWARD sweeping issues under the carpet rather than highlighting them in full public view - thus supporting and facilitating the very type of CO who adds fuel to the race to the bottom.

 

What's actually needed are systems which REVERSE the false idea popularised by those who shout loudest that high expectations and demands are somehow 'uncool' and instead turn the tide back toward caching being that really cool concept where the whole community is focused on and geared toward fun, stimulating and uplifting experiences which have nothing to do with junk and where junk peddlers get short shrift.

[+The A-Team]

What's actually needed are systems which REVERSE the false idea popularised by those who shout loudest that high expectations and demands are somehow 'uncool' and instead turn the tide back toward caching being that really cool concept where the whole community is focused on and geared toward fun, stimulating and uplifting experiences which have nothing to do with junk and where junk peddlers get short shrift.

...and now we seem to have come full-circle, because the first line of the supposed Groundspeak communication that triggered this entire discussion reads:

Geocaching HQ has a new focus on geocache quality and health for 2017.

If this is indeed true, I'm looking forward to the emails that will be sent out to everyone educating them about the proper use and value of the DNF, NM and NA log types, and the maintenance responsibilities of COs.

[cezanne]

Often someone will mention a "damp but signable" log in their found log; but a wet as pulp log would raise a NM.

 

This is also what I would do - I always try to say something about the condition in my found it log but use NM only when I really think that a maintenance visit is necessary. The CO is still free to pay a maintenance visit on the basis of my input when they feel like it - they just need to read every log typ which I do anyway.

 

It would seem completely weird to me to log NM for example when the log book is slightly damp e.g. when it is has rained or snowed recently often as then it the log book will almost always be a bit damp due to the process of logging when cachers take things out. When I decide against a NM log it is definitely not because I'm worried about the CO's reaction.

[+thebruce0]

And that IS the problem - your proposed system - as you've chosen to implement it - is geared TOWARD sweeping issues under the carpet rather than highlighting them in full public view - thus supporting and facilitating the very type of CO who adds fuel to the race to the bottom.

Well that seems to be your perspective. The "whole point" is that not everyone uses the system the way it's "intended", and everyone can't be forced to use the system that way. Does that mean the system is broken? *shrug* but it means that a little feature that makes it easier for issues about which people disagree on the importance to be reported can be helpful.

 

What's actually needed are systems which REVERSE the false idea popularised by those who shout loudest that high expectations and demands are somehow 'uncool' and instead turn the tide back toward caching being that really cool concept where the whole community is focused on and geared toward fun, stimulating and uplifting experiences which have nothing to do with junk and where junk peddlers get short shrift.

I don't disagree. In the ideal world, everyone would use and understand the NM as something good and useful, and what objective does and does not warrant the log - not an pushed annoying notification or somehow a public shame to create. Unfortunately that does not seem to be the case...

And, what some people consider "worthy" of a NM, others do not. When those two definitions clash, you either get a CO who wants to know of the minor issue that the finder doesn't think is important so they cann't ensure their cache it top quality, or you get a finder who posts a NM on an imperfection that the CO does not feel is worth a maintenance and consistently deletes the NM logs.

 

Geocaching HQ has a new focus on geocache quality and health for 2017.

If this is indeed true, I'm looking forward to the emails that will be sent out to everyone educating them about the proper use and value of the DNF, NM and NA log types, and the maintenance responsibilities of COs.

Ditto!

(I fear it would unlikely be anything new though )

 

This is also what I would do - I always try to say something about the condition in my found it log but use NM only when I really think that a maintenance visit is necessary. The CO is still free to pay a maintenance visit on the basis of my input when they feel like it - they just need to read every log typ which I do anyway.

 

It would seem completely weird to me to log NM for example when the log book is slightly damp e.g. when it is has rained or snowed recently often as then it the log book will almost always be a bit damp due to the process of logging when cachers take things out. When I decide against a NM log it is definitely not because I'm worried about the CO's reaction.

Exactly.

Edited January 12, 2017 by thebruce0

[+Team Microdot]

And that IS the problem - your proposed system - as you've chosen to implement it - is geared TOWARD sweeping issues under the carpet rather than highlighting them in full public view - thus supporting and facilitating the very type of CO who adds fuel to the race to the bottom.

Well that seems to be your perspective. The "whole point" is that not everyone uses the system the way it's "intended", and everyone can't be forced to use the system that way. Does that mean the system is broken? *shrug* but it means that a little feature that makes it easier for issues about which people disagree on the importance to be reported can be helpful.

 

And you think that adding complexity will improve the situation?

 

I have to say that I'd be very, very surprised if it did.

 

Your statement that people can't be forced to use the system in the way it's intended doesn't automatically become less true because you add complexity in the form of additional mechanisms which produce marginally different results. In my experience complexity decreases people's desire to use things rather than the opposite way around. Plus the outcomes you allude to I think fundamentally do nothing to address the underlying issue.

 

It really is incredibly simple - report the issue, using the single existing mechanism that's provided and perfectly adequate for the purpose - report the facts. Leave deciding how important that information is to the CO - that's their job - not the job of the logger and not the job of some complex automated checklist that needs a flow diagram to explain it.

[cezanne]

It really is incredibly simple - report the issue, using the single existing mechanism that's provided and perfectly adequate for the purpose - report the facts. Leave deciding how important that information is to the CO - that's their job - not the job of the logger

 

I do not agree that there is only a single existing mechanism. It's still up to the cachers to decide whether they consider something they observes as an issue and further as an issue that falls under "needs maintenance" for them. I will continue to mention my observations in my found it logs and to write a NM log only when I feel that the cache *needs* maintenance and not when I report something where some cache owner might decide that they want to visit their cache. They still can do the latter - they just need to read my found it log.

[+Team Microdot]

It really is incredibly simple - report the issue, using the single existing mechanism that's provided and perfectly adequate for the purpose - report the facts. Leave deciding how important that information is to the CO - that's their job - not the job of the logger

 

I do not agree that there is only a single existing mechanism. It's still up to the cachers to decide whether they consider something they observes as an issue and further as an issue that falls under "needs maintenance" for them. I will continue to mention my observations in my found it logs and to write a NM log only when I feel that the cache *needs* maintenance and not when I report something where some cache owner might decide that they want to visit their cache. They still can do the latter - they just need to read my found it log.

 

Fair point - I could choose to report facts in my Found log, or in a DNF log or even a note for that matter.

 

So there are already multiple channels through which cache condition information can be relayed - so adding even more channels would make things even more complex than I had originally thought!

[+L0ne.R]

I think Groundspeak needs to regularly promote Needs Maintenance as an important and useful tool for everyone.

[+narcissa]

I think Groundspeak needs to regularly promote Needs Maintenance as an important and useful tool for everyone.

 

Give people a souvenir for using it.

[+Team Hugs]

Give people a souvenir for using it.

 

Y'know ... once upon a time, I thought about creating a challenge cache which would require the qualifier to log 10 NMs on different caches, in order to reward those people who actually use the tool to help cache owners keep the game strong.

 

And then I realized how easily it could be abused and gave up the idea.

 

I have no idea if it'd even work in the New Era of challenges ...

[+Team Microdot]

Give people a souvenir for using it.

 

Y'know ... once upon a time, I thought about creating a challenge cache which would require the qualifier to log 10 NMs on different caches, in order to reward those people who actually use the tool to help cache owners keep the game strong.

 

And then I realized how easily it could be abused and gave up the idea.

 

I have no idea if it'd even work in the New Era of challenges ...

 

A challenge cache must have a positive focus.

 

The question is - would Groundspeak consider the challenge you thought about as positive????

[+narcissa]

Give people a souvenir for using it.

 

Y'know ... once upon a time, I thought about creating a challenge cache which would require the qualifier to log 10 NMs on different caches, in order to reward those people who actually use the tool to help cache owners keep the game strong.

 

And then I realized how easily it could be abused and gave up the idea.

 

I have no idea if it'd even work in the New Era of challenges ...

 

Yeah, for some people it would have the intended effect, but there would definitely be jerks who just post needless NMs on their next ten finds.

[+niraD]

So with the checkbox system, if I have a cache in a wet/underwater environment with a waterproof log (not just a water-resistant log, but a waterproof log), then should I expect most finders to check the "wet log" checkbox when they post their logs?

 

And if they do check the "wet log" checkbox when they post their logs, will the Needs Maintenance attribute be set automatically, even though the cache is working as designed?

[+Mudfrog]

Checkboxes aren't needed as there is a system already in place. It stands to reason that it's better because it can provide good information to cache owners and other interested parties. On those instances of people not utilizing the system, here again, it comes down to many of them simply not taking the time to learn geocaching basics.

[+Wet Pancake Touring Club]

So with the checkbox system, if I have a cache in a wet/underwater environment with a waterproof log (not just a water-resistant log, but a waterproof log), then should I expect most finders to check the "wet log" checkbox when they post their logs?

 

And if they do check the "wet log" checkbox when they post their logs, will the Needs Maintenance attribute be set automatically, even though the cache is working as designed?

When I first threw out the idea of checkboxes, I wanted their labels to be written so that they had a specific meaning, with little ambiguity. niraD takes the 'wet log' checkbox to the extreme, which points out that we certainly don't want 'wet log' in the label for the checkbox.

 

So, is there phrasing that is not ambiguous, and gives the CO enough information so they can take action? How about "I had a problem signing the log because it was missing or damaged". We will leave full out of it. Something that covers the majority of log problems. The CO is informed that there is a problem with the log. Would the CO really need to know the specific reason? In both cases, the solution is to replace the log.

 

I'm wondering if we can come up with something similar for information regarding the container?

 

As for whether or not the NM attribute is set, I'm still on the fence about that. I'm guessing that it would be easiest to implement it as an automatic NM.

[+Team Microdot]

As for whether or not the NM attribute is set, I'm still on the fence about that. I'm guessing that it would be easiest to implement it as an automatic NM.

 

So.... rather than setting the NM attribute by creating a log, and having a free-form text box in which to describe in detail the precise nature of the reason for setting the NM attribute...

 

we are instead going to have a series of check boxes with short, admittedly inadequate cookie-cutter descriptions which, when checked, set the NM attribute anyway.

 

And this is somehow improvement?

 

Whichever way I look at it, it's a backwards step.

[+colleda]

And that IS the problem - your proposed system - as you've chosen to implement it - is geared TOWARD sweeping issues under the carpet rather than highlighting them in full public view - thus supporting and facilitating the very type of CO who adds fuel to the race to the bottom.

Well that seems to be your perspective. The "whole point" is that not everyone uses the system the way it's "intended", and everyone can't be forced to use the system that way. Does that mean the system is broken? *shrug* but it means that a little feature that makes it easier for issues about which people disagree on the importance to be reported can be helpful.

 

What's actually needed are systems which REVERSE the false idea popularised by those who shout loudest that high expectations and demands are somehow 'uncool' and instead turn the tide back toward caching being that really cool concept where the whole community is focused on and geared toward fun, stimulating and uplifting experiences which have nothing to do with junk and where junk peddlers get short shrift.

I don't disagree. In the ideal world, everyone would use and understand the NM as something good and useful, and what objective does and does not warrant the log - not an pushed annoying notification or somehow a public shame to create. Unfortunately that does not seem to be the case...

And, what some people consider "worthy" of a NM, others do not. When those two definitions clash, you either get a CO who wants to know of the minor issue that the finder doesn't think is important so they cann't ensure their cache it top quality, or you get a finder who posts a NM on an imperfection that the CO does not feel is worth a maintenance and consistently deletes the NM logs.

 

Geocaching HQ has a new focus on geocache quality and health for 2017.

If this is indeed true, I'm looking forward to the emails that will be sent out to everyone educating them about the proper use and value of the DNF, NM and NA log types, and the maintenance responsibilities of COs.

Ditto!

(I fear it would unlikely be anything new though )

 

This is also what I would do - I always try to say something about the condition in my found it log but use NM only when I really think that a maintenance visit is necessary. The CO is still free to pay a maintenance visit on the basis of my input when they feel like it - they just need to read every log typ which I do anyway.

 

It would seem completely weird to me to log NM for example when the log book is slightly damp e.g. when it is has rained or snowed recently often as then it the log book will almost always be a bit damp due to the process of logging when cachers take things out. When I decide against a NM log it is definitely not because I'm worried about the CO's reaction.

Exactly.

I had an example like that this week. The previous cacher said the log was wet, I found it perfectly dry. The container was identical to others I had found that day by the same CO and all logs were dry with no mention of any being wet. It may have been that a previous finder had not closed the container properly. If the finder that mentioned the log being wet had logged a NM it could have meant a wasted trip by the CO to check.

[+thebruce0]

And you think that adding complexity will improve the situation?

How is it more complex?

Every user can do exactly the same thing the same way they've always done it, if they wish.

 

In my experience complexity decreases people's desire to use things rather than the opposite way around. Plus the outcomes you allude to I think fundamentally do nothing to address the underlying issue.

Of course complexity makes things harder to use. ... you do know that things get more complex the more they are capable to doing, yes? The trick is finding a way to provide more functionality while minimizing the barrier to entry. Complexity itself is not a Bad Thing. The ability for someone to understand and make use of th complexity is what's important. Even so, as I said, nothing here would be made more complex.

 

It really is incredibly simple - report the issue, using the single existing mechanism that's provided and perfectly adequate for the purpose - report the facts. Leave deciding how important that information is to the CO - that's their job - not the job of the logger and not the job of some complex automated checklist that needs a flow diagram to explain it.

You're missing the point. Not everyone does it that way. And they can't be forced to do it that way. So a lot is being missed. Status quo right now is that generally speaking it's fine. We can make do. But hey, here's a little bit we can do to help smooth out some of the rough edge that doesn't impact anyone who doesn't want to be impacted.

 

So with the checkbox system, if I have a cache in a wet/underwater environment with a waterproof log (not just a water-resistant log, but a waterproof log), then should I expect most finders to check the "wet log" checkbox when they post their logs?

 

And if they do check the "wet log" checkbox when they post their logs, will the Needs Maintenance attribute be set automatically, even though the cache is working as designed?

I know this is somewhat a jest comment, but I'll bite anyway. Again, in what I envision, it's just a flag, no pestering, no public alert. If someone wants to joke about an underwater cache having a wet log, as a CO I can either ignore those reports or clear it out if I've checked them and feel they're irrelevant. No harm no foul. The NM log wouldn't be posted because they didn't post a NM log.

If they felt the cache needed immediate owner maintenance (for whatever reason they deem sufficient), they'd post a NM log as they usually would. One UI sentence: "Checking a box below will not post a NM log or flag the cache as Requiring Maintenance." Clear as day.

 

On those instances of people not utilizing the system, here again, it comes down to many of them simply not taking the time to learn geocaching basics.

Right... and so we come back to the question of whether it's better to leave status quo, or find another way to do things that can help. Every feature that gets developed intending to 'fix' something has to go through this process.

So once again, I'm not saying this is a big deal... just thinking through benefits and potential concerns. *shrug*

 

niraD takes the 'wet log' checkbox to the extreme, which points out that we certainly don't want 'wet log' in the label for the checkbox.

 

So, is there phrasing that is not ambiguous, and gives the CO enough information so they can take action? How about "I had a problem signing the log because it was missing or damaged". We will leave full out of it. Something that covers the majority of log problems. The CO is informed that there is a problem with the log. Would the CO really need to know the specific reason? In both cases, the solution is to replace the log.

 

I'm wondering if we can come up with something similar for information regarding the container?

 

As for whether or not the NM attribute is set, I'm still on the fence about that. I'm guessing that it would be easiest to implement it as an automatic NM.

=/ hrm. You seem to be looking at it from the other direction; many of those I'd consider worty of a NM. I'd be looking at the checkboxes as not-yet-NM-worthy (eg, things that cachers often (not always) handle themselves for the community, like adding a logsheet), not rather as replacement for important owner-attention-required situations.

In all cases the owner would be informed. Only in cases where public needs to know significant problems (or for whatever reasons a cacher may deem a NM log necessary as it works now) would a NM still be posted by the cacher

 

In short, generally:

NM = Public information about the state of a cache that other cachers may need to know (nothing would change about this process).

Checkboxes = Allowance for minor concerns that may not need immediate addressing that are good for the owner to know but not necessarily other cachers.

Edited January 12, 2017 by thebruce0

[+Team Microdot]

And you think that adding complexity will improve the situation?

How is it more complex?

 

More options = more choices = more complexity.

[+Team Microdot]

=/ hrm. You seem to be looking at it from the other direction; many of those I'd consider worty of a NM. I'd be looking at the checkboxes as not-yet-NM-worthy (eg, things that cachers often (not always) handle themselves for the community, like adding a logsheet), not rather as replacement for important owner-attention-required situations.

In all cases the owner would be informed. Only in cases where public needs to know significant problems (or for whatever reasons a cacher may deem a NM log necessary as it works now) would a NM still be posted by the cacher

 

In short, generally:

NM = Public information about the state of a cache that other cachers may need to know (nothing would change about this process).

Checkboxes = Allowance for minor concerns that may not need immediate addressing that are good for the owner to know but not necessarily other cachers.

 

Anything not NM-worthy can just be written in your regular log. I see no reason to split the 'diary' of the cache into private and public segments. If you've replaced a logbook in someone else's cache rather than post an NM and leave it to the CO to sort out, as a potential finder I'd like to know that.

[+Wet Pancake Touring Club]

I'll throw out a slightly different spin on the checkbox idea. Again, the goal is to improve the quality of caches. The assumption is that if people use the NM process as designed, overall cache quality would improve. However, based on forum discussion, it appears that people are not initiating the process when they should. I wonder why that is, and how can we correct this.

 

Is it because the process and procedure are not well understood? (Procedure and process are different concepts to me.) Well, both take training. Right now, it seems like people have to go and seek out this information. Can we get this information to them when they need it, using a concept called 'just in time training'.

 

Is is because the procedure is cumbersome to use? I believe that it is, because it requires going back and adding a second log entry. Is it possible to streamline the procedure?

 

Is it because the procedure is intimidating to some people? I know that when the system requests confirmation on a NM, it comes across as 'Are you sure you know what you are doing'. Can we make filing a NM log seem more natural?

 

Where does all of this come together? When logging the cache. (Web site or app, both should operate the same way.) Are there changes that could be made to the logging page that would address these reasons?

 

Add a couple of checkboxes of common problems to the logging page. If any of them are checked, take them to a page that explains what should be reported as a maintenance issue. Have a free-form text field where they can explain the problem. When they do that, have the system inform them that the CO has been notified. Behind the scenes, this second page goes into the system as a NM log.

 

It's got training, it is streamlined, and it is a more natural extension of the logging procedure. With the training right on the page when logging, the quality (to the CO) of the contents of the NM log may get better. I think this would also make it easier to program the NM e-mail to include both the Found it/DNF/Write Note log and the NM log, so the CO wouldn't have to go track down the other log.

 

I wouldn't remove the ability to directly create a NM log from the logging page. There may be times that logging a NM without an associated Found it/DNS/Write note log. Also, while it would be possible to do something similar to logging a NA, I don't think we want to go there. Those are much less frequent than NM. But, the NA procedure can be explained as part of the training.

[+Team Microdot]

I'll throw out a slightly different spin on the checkbox idea...

 

This sounds more natural, logical and useful to me.

 

I can imagine a responsive (I think that's the right terminology ) layout for the logging page which reveals appropriate/relevant information gathering sections in response to the user checking certain boxes as they go.

 

In fact I wonder if in the same 'restructuring' the terminology can't be adjusted too, shifting the focus toward cache health rather than just cache malady?

 

Is there any mileage in getting finders to rate the health of a cache so that the CO's of healthy caches are receiving nods of approval for keeping their caches healthy rather than just getting what seems to be received as disapproval when their caches are found in a sub-par state?

 

Could the aggregate of a CO's cache health be rolled up into a rating for the CO themselves such that a CO who keeps the balance of caches owned at a level which ensures that their overall health is always in positive territory and the CO receives positive recognition for that? CO's who over-stretch by placing more caches than they can keep up with end up with a dwindling average health score and prospective finders are able to choose instead to focus on caches and cache owners with positive health scores? Could there even be recognised kudos for CO's who have high health scores?

 

I'm just thinking out loud here so there's every chance I've missed potential pitfalls.

[+thebruce0]

I wouldn't remove the ability to directly create a NM log from the logging page. There may be times that logging a NM without an associated Found it/DNS/Write note log. Also, while it would be possible to do something similar to logging a NA, I don't think we want to go there. Those are much less frequent than NM. But, the NA procedure can be explained as part of the training.

I certainly wouldn't be opposed to connecting the NM and NA ability to the log creation process, with of course additional guiding information and instruction.

But apparently according to Team Microdot that's "more complex" because there are more features and buttons, even though it could be completely ignored and life continue on for everyone as usual if they don't wish to use it. So I'm confused as why he thinks it's "more natural and logical" - based on previous arguments.

 

I was going to say that it doesn't address the issues I pointed out earlier: those who don't want to post a NM at all for some issues - which the CO may not believe to be NM worthy, or by those who do want to post NM logs for issues the CO may not believe are NM worthy. However, it provides that extra training step (for those who read and do more than simply log posting) and a more streamlined movement into the NM or NA posting, which on one hand would be helpful, but I fear GS could also see that as leaning towards a negative experience (like, pointing towards how to report caches rather than provide positive feedback live Favs).

But, if in the past they wanted to lean towards the positive (finding, favs) and make it harder to post issues, that could be part of the new "initiative", focusing on making it easier for reporting problems and putting more weight of responsibility on the COs, despite more reporting traffic, and likely more noise rather than signal. Part of owning will be paying attention to the traffic and filtering signal from noise.

 

However... that would also only be a web-based process, as under the hood nothing would be changing. GS can adjust their user interface on the web, but now they also have to update their mobile app more significantly, and ideally request the 3rd party apps ensure their user experience/process is similar as well.

But that's not a bad thing itself, and if this option is only interface redesign and no database development, it's a more compartmentalized development which is also good.

 

Anything not NM-worthy can just be written in your regular log. I see no reason to split the 'diary' of the cache into private and public segments. If you've replaced a logbook in someone else's cache rather than post an NM and leave it to the CO to sort out, as a potential finder I'd like to know that.

As I already said, status quo we can live with in this context. But that's no reason not to consider ways to smooth some rough edges.

 

More options = more choices = more complexity.

As I already said.

But complexity itself is not bad, otherwise NO application or website would EVER be expanded. The barrier to usability of more features is the issue; not mere count of options and choices. It's more the how, not the what.

 

Is there any mileage in getting finders to rate the health of a cache so that the CO's of healthy caches are receiving nods of approval for keeping their caches healthy rather than just getting what seems to be received as disapproval when their caches are found in a sub-par state?

I think Favorites was Groundspeak's answer to user "ratings" in any form, requested quite often in past years. Even so, guess what, easiest and least impactful implementation of a health rating? Additional options with the log posting. Uh oh, more complex!

 

Could the aggregate of a CO's cache health be rolled up into a rating for the CO themselves such that a CO who keeps the balance of caches owned at a level which ensures that their overall health is always in positive territory and the CO receives positive recognition for that? CO's who over-stretch by placing more caches than they can keep up with end up with a dwindling average health score and prospective finders are able to choose instead to focus on caches and cache owners with positive health scores? Could there even be recognised kudos for CO's who have high health scores?

I don't foresee Groundspeak implementing any form of rate-this-user system. At all. Much too easy for abuse and interpersonal drama headaches. Right now a user can search for the CO and find out how many favorites their caches have, how many disabled or flagged for NM, and I think that would be as far as GS would go on that. Favorites are a positive system; ratings that imply a scale of bad--good open the door for problems.

 

But hey guess what? If caches have health 'flags' as optional tags appended to find logs via "more complex" checkboxes, that's a data statistic that would also be available to Groundspeak would they choose to provide an ownership health summary for any particular cacher/owner (which can include NM stat analysis). I'd only wanted to keep those flags a private thing for the purpose of owner reference but certainly it would be possible to provide such a public 'report' if Groundspeak wanted to provide that.

 

Unfortunately, any suggestion made for adding health ratings in any form is also going to be "more complex" because even the addition of a couple of optional helpful checkboxes is apparently a Bad Thing.

Edited January 13, 2017 by thebruce0

[+Team Microdot]

Unfortunately, any suggestion made for adding health ratings in any form is also going to be "more complex" because even the addition of a couple of optional helpful checkboxes is apparently a Bad Thing.

 

Round and round the garden like a teddy bear

 

My argument that your proposed system is more complex centres on me imaging hitting the site as a newbie user.

 

When I was a newbie user it took me a good while to even understand some of the terminology used - let alone what to do with which bits of interface under which circumstances.

 

If I imagine myself in that situation again and imagine the interface with your additional check-boxes I see more choices to make, more to understand, more complexity, potentially divergent pathways and definitely more opportunities to get it wrong - or just run screaming from the room in the face of interface overload.

 

If there's a way I can make things any clearer for you I don't know what it is.