Changes to logging, specifically stopping double logs

4.5k · April 5, 2017

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

Except for in-app tutorials, which they have in the official app. The "problem" is people starting out with geocaching without help from anyone with experience, and without using the official app.

Because it is an app, and yes i am guilty of this, people tend to download and play. They don't read much, if any of the directions because they're sure they can figure it out on the fly. Most apps are easy to use and even if a mistake is made, doesn't cause problems for others. Geocaching is different because there are other people involved who are affected when a person plays the app without knowing anything about the hobby.

Edited April 5, 2017 by Mudfrog

13.7k · April 5, 2017

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

That #2 rule is part of the problem. Whether GS reads the forums or not, the company routinely chooses to keep quiet and ignore its customers. I would say this is what gets the toxicity going a lot of the time.

Both of you have been around long enough to see many instances whenever there's any change, that even when a Lackey's been helpful and cordial, what follows often needs Moderator action.

I personally don't blame 'em one bit.

Many do see responses in sorta safe zones (release notes mostly) , where there's usually a notice to keep the tone pleasant and stay on topic.

I'm most suprised by the phone forums, where people are begging for help, but when a Lackey tries, they're berated by a bunch soon after on off-topic subjects.

1.7k · April 5, 2017

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

Except for in-app tutorials, which they have in the official app. The "problem" is people starting out with geocaching without help from anyone with experience, and without using the official app.

Because it is an app, and yes i am guilty of this, people tend to download and play. They don't read much, if any of the directions because they're sure they can figure it out on the fly. Most apps are easy to use and even if a mistake is made, doesn't cause problems for others. Geocaching is different because there are other people involved who are affected when a person plays the app without knowing anything about the hobby.

Another factor is that in the case of most apps, the APP is the thing!

If it's a normal game app, then the point is to play that game. You'll figure it out.

If it's most other types of utility apps (music-streaming, calendaring, etc.) then the point is that function.

If the case of THIS app, this app only exists as a adjunct to a completely separate activity. An important adjunct, but the point behind the app is not to use the app to find caches and log them; the point is TO FIND CACHES AND LOG THEM.

So, it might not ever occur to most new people that there's anything beyond the app that's not secondary TO the app; that's just how this stuff works for most people. The fact that there's a world behind it just doesn't matter.

This is why, BTW, it would be dangerous indeed to the hobby if you could ever submit a cache listing through the app.

Edited April 5, 2017 by TeamRabbitRun

7.5k · April 5, 2017

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

Yeah, I'm sure nothing will happen, either. I don't think that's why anyone here is discussing it.

But I don't think "toxic" describes the problem. I think the reason they stay away from the forums is they're making these decisions for reasons that wouldn't stand up to public discussion. If they'd just start out by posting justifications that do stand up to public discussion when they announce a change, these threads wouldn't go on as long.

21.9k · April 5, 2017

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

That #2 rule is part of the problem. Whether GS reads the forums or not, the company routinely chooses to keep quiet and ignore its customers. I would say this is what gets the toxicity going a lot of the time.

I can tell you that it was because of this thread that HQ posted in the Announcement forum to clarify what will be happening (and not happening). I can tell you quite specifically that something I observed in this thread as a valid question was passed along to HQ -- by me -- leading to an edited update to the Announcement thread.

I was happy to belp make sure that the community's valid questions were addressed. I do this a lot - not just in this thread. If you still feel neglected and ignored, I could look into mailing you a blankie. No promises, though.

1.3k · April 5, 2017

If you still feel neglected and ignored, I could look into mailing you a blankie. No promises, though.

Ooh, ooh, I'll take a blankie. One of those special platinum-level blankies with rabbits on it. If not, a geocoin will work, too.

15.3k · April 5, 2017

If you still feel neglected and ignored, I could look into mailing you a blankie.

That's no fair! The rest of us who don't feel neglected or ignored should get blankies too!

Or, we should get warm thoughts because you're looking into mailing us blankies too?

Or... nevermind...

:unsure:

4.5k · April 6, 2017

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

That #2 rule is part of the problem. Whether GS reads the forums or not, the company routinely chooses to keep quiet and ignore its customers. I would say this is what gets the toxicity going a lot of the time.

I can tell you that it was because of this thread that HQ posted in the Announcement forum to clarify what will be happening (and not happening). I can tell you quite specifically that something I observed in this thread as a valid question was passed along to HQ -- by me -- leading to an edited update to the Announcement thread.

I was happy to belp make sure that the community's valid questions were addressed. I do this a lot - not just in this thread. If you still feel neglected and ignored, I could look into mailing you a blankie. No promises, though.

I've seen this happen too many times. Groundspeak makes an unwanted or unneeded change and then stands firm on their decision, no matter the negatives it brings about or what their customers say. The vast majority of the time, the change stays with not a word from Groundspeak. Hopefully this time will be different with GS taking another look at this issue to possibly offer a more reasonable way of initiating it.

p.s. Is by any chance, the blankie trackable? :lol:

2.2k · April 6, 2017

The argument that people can still find the cache but then log a note on it seems silly. Let's face it, not many of us would want to go out and find a cache and then not be able to log it as found. I can guarantee that most would not like it and geocaching popularity would suffer.

I couldn't believe when the official response I got from Groundspeak HQ was to "Log a Note".

If they think that's the case, then every log type should be removed and replaced with nothing but Notes. Get's rid of the whole multiple finds "problem".

2.2k · April 6, 2017

Like someone else said, seems like it could be made to accept logging...or to read 'Notes' rather than 'Found it' logs. It's all about the willingness to make it so being greater than the desire to continue complaining about this update to the system.

And what happens when someone wants to write a Note about an experience that did not result in a Find? I've had many brass capping adventures that resulted in me being several kms from the cache site.

2.2k · April 6, 2017

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

That #2 rule is part of the problem. Whether GS reads the forums or not, the company routinely chooses to keep quiet and ignore its customers. I would say this is what gets the toxicity going a lot of the time.

Yep.

Several of us have written to Groundspeak and all we got back were canned responses.

Unfortunately, we cannot give an exception for any caches in regards to the new logging rules. As you probably know, it is incorrectly listed as a virtual and is really a locationless cache. If it had been listed correctly, it would have been archived long ago with all of the other locationless caches. It has had a very long life.

Fortunately for the fans of the cache, it is not being archived. None of the existing logs will be changed or removed. People who have already logged finds on it can continue to enjoy hunting for it in each new location, but log their visit and tell about their experience with a note instead of a find. Newer geocachers that have not yet attempted it, will be able to log their first find on the listing, and continue to log visits via a note. None of the fun experience needs to change.

My response was to first point out that a cache like GC43F3 has never been anything like a Locationless. You can't just go out and find any Brass Cap and call it a Find. And, posting a Find on a Brass Cap doesn't mean it is now ineligible for other cachers to find that same cap. Maybe Groundspeak is so focused on the new user experience that they forget some of us have actually been around long enough to have actually found Locationless caches?

I also asked two simple questions:

- If logging a Note is just as much fun as logging a Find, why not do away with logs of all types and just have everyone use Notes?

- Is this a case of "they can't" make an exception or "they won't" make an exception. Two very different things.

1.4k · April 6, 2017

There is one way that the YOSM issue could be fixed, but it would involve Groundspeak giving special dispensation for it to happen. Break the multi-travelling-virtual-locationless cache into as many simple virtual caches as are needed (about 700 if I am not mistaken). I know that new virtual caches are not allowed and there is no way that the CO could submit them, but if Groundspeak could be persuaded that these are not "new" virtuals, but are components of an existing virtual, then they could write a simple quick-and-dirty program to add the new caches straight into the database. The YOSM organisers would have to supply a list of (at least) coordinates and cache names.

It wouldn't be a perfect solution, but at least it would allow people who hunt these things to log their finds as finds and would fit with the one-cache-one-find approach.

All it now needs is for TPTB to give it the go-ahead (unlikely as that may be)

3.5k · April 6, 2017

There is one way that the YOSM issue could be fixed, but it would involve Groundspeak giving special dispensation for it to happen. Break the multi-travelling-virtual-locationless cache into as many simple virtual caches as are needed (about 700 if I am not mistaken). I know that new virtual caches are not allowed and there is no way that the CO could submit them, but if Groundspeak could be persuaded that these are not "new" virtuals, but are components of an existing virtual, then they could write a simple quick-and-dirty program to add the new caches straight into the database. The YOSM organisers would have to supply a list of (at least) coordinates and cache names.

It wouldn't be a perfect solution, but at least it would allow people who hunt these things to log their finds as finds and would fit with the one-cache-one-find approach.

All it now needs is for TPTB to give it the go-ahead (unlikely as that may be)

But wouldn't that mean that new locations could not be added, or would you expect TPTB to create a new virtual for each new location that OFTH creates in the future?

7.5k · April 6, 2017

I couldn't believe when the official response I got from Groundspeak HQ was to "Log a Note".

If they think that's the case, then every log type should be removed and replaced with nothing but Notes. Get's rid of the whole multiple finds "problem".

The funny part is that making the only log type the Note wouldn't solve the problem, it would just change the multiple Find problem into a multiple Note problem.

3.5k · April 6, 2017

Like someone else said, seems like it could be made to accept logging...or to read 'Notes' rather than 'Found it' logs. It's all about the willingness to make it so being greater than the desire to continue complaining about this update to the system.

And what happens when someone wants to write a Note about an experience that did not result in a Find? I've had many brass capping adventures that resulted in me being several kms from the cache site.

As niraD mentioned in his reply to J Grouchy, cachers could include a specific string in their Note logs to have those Note logs be counted by the YOSM site. Similar to how including a specific string in FTF logs enables Project-GC to count those logs in their FTF stats.

Of course, that would require some re-programming of the YOSM site, but I'm sure there are YOSM fans with enough technical know-how to help accomplish it.

April 6, 2017

Of course, that would require some re-programming of the YOSM site, but I'm sure there are YOSM fans with enough technical know-how to help accomplish it.

The YOSM site already require tags in the find logs to identify which monument is being logged. I guess it's as easy as just starting to read notes as well, maybe with a simple extra tag to make sure only valid second finds are registered.

1.4k · April 6, 2017

There is one way that the YOSM issue could be fixed, but it would involve Groundspeak giving special dispensation for it to happen. Break the multi-travelling-virtual-locationless cache into as many simple virtual caches as are needed (about 700 if I am not mistaken). I know that new virtual caches are not allowed and there is no way that the CO could submit them, but if Groundspeak could be persuaded that these are not "new" virtuals, but are components of an existing virtual, then they could write a simple quick-and-dirty program to add the new caches straight into the database. The YOSM organisers would have to supply a list of (at least) coordinates and cache names.

It wouldn't be a perfect solution, but at least it would allow people who hunt these things to log their finds as finds and would fit with the one-cache-one-find approach.

All it now needs is for TPTB to give it the go-ahead (unlikely as that may be)

But wouldn't that mean that new locations could not be added, or would you expect TPTB to create a new virtual for each new location that OFTH creates in the future?

No. The YOSM organisers would have to provide a one-time definitive list.

As I said, it isn't a perfect solution, but it would solve most of the issues.

Of course, it is probably academic, but I can hope.

3.5k · April 6, 2017

There is one way that the YOSM issue could be fixed, but it would involve Groundspeak giving special dispensation for it to happen. Break the multi-travelling-virtual-locationless cache into as many simple virtual caches as are needed (about 700 if I am not mistaken). I know that new virtual caches are not allowed and there is no way that the CO could submit them, but if Groundspeak could be persuaded that these are not "new" virtuals, but are components of an existing virtual, then they could write a simple quick-and-dirty program to add the new caches straight into the database. The YOSM organisers would have to supply a list of (at least) coordinates and cache names.

It wouldn't be a perfect solution, but at least it would allow people who hunt these things to log their finds as finds and would fit with the one-cache-one-find approach.

All it now needs is for TPTB to give it the go-ahead (unlikely as that may be)

But wouldn't that mean that new locations could not be added, or would you expect TPTB to create a new virtual for each new location that OFTH creates in the future?

No. The YOSM organisers would have to provide a one-time definitive list.

As I said, it isn't a perfect solution, but it would solve most of the issues.

Of course, it is probably academic, but I can hope.

Ah, but I thought OFTH was adding new locations every week or so. Your proposal would also end up changing the process of how this cache works and OFTH would have to verify accessibility of all the markers before submitting the 'definitive list', or else markers could be missed and never have the chance to be added again. Or if a currently inaccessible marker becomes accessible later, then it will forever be excluded from the YOSM site because it wasn't accessible when the 'definitive list' was submitted.

I think we can both agree that it's unlikely such a solution would be implemented. Seems to me that the Write Note log + special tagging is the most feasible way to let YOSM hunters continue tracking their activity on the YOSM page stats and leaderboard. Of course, they wouldn't get multiple smileys on geocaching.com.

14k · April 6, 2017

- Is this a case of "they can't" make an exception or "they won't" make an exception. Two very different things.

Those are also different from "they shouldn't" make an exception. I'm sure has it's reasons why they shouldn't make an exception even if, technically, they could. For those reason, they won't make an exception.

4.5k · April 6, 2017

- Is this a case of "they can't" make an exception or "they won't" make an exception. Two very different things.

Those are also different from "they shouldn't" make an exception. I'm sure has it's reasons why they shouldn't make an exception even if, technically, they could. For those reason, they won't make an exception.

Caches like these have been exceptions for a long time. For whatever reason, Groundspeak decided years ago not to allow any newer versions of them to be published. Like virtuals, those already in existence became "grandfathered" in. Now GS's idea is to just shut it all down without regards to what many people think. Over the years, GS has taken away virtuals, locationless, challenge, and now, these types of caches. I just don't understand the push to kill off the interesting and creative in favor of the routine and mundane.

7.5k · April 6, 2017

- If logging a Note is just as much fun as logging a Find, why not do away with logs of all types and just have everyone use Notes?

Can't filter out caches we've found if everything was a note.

April 6, 2017

Mrs ofth just found this on the Help section:

3.11. Grandfathered Geocaches

What does "grandfathered" mean?

In geocaching terms, the word "grandfathered" means to grant a special exception. More clearly, to "grandfather" something is to allow certain situations to exist based on an older rule (this is the "grandfather clause") even though a new rule is currently in place.

For example, geocache types like Virtual Geocaches and Webcams are no longer accepted as new listings today, but those that already exist remain as "grandfathered" geocaches as long as they continue to be maintained by their owners and are good for the game. Even grandfathered caches should continue to be good examples of geocaching. If they aren't, they are eligible to be archived regardless of their grandfathered status.

9k · April 6, 2017

In most cases, a grandfathering takes place if the work required to grandfather a listing isn't significant - such as a rule of practice, or allowing an existing data type to exist (ie cache types). In this case, if the change to the API across the board is one that sets certain log types only applicable to a strict set of parameters, then making an exception means building in an additional lookup or reference and explicitly including the ability to override the norm in order accomodate the grandfathering.

YOSM as a Virtual is grandfathered. The Virtual type remains available and loggable - the limitation was that Virtuals can't be published any more (which I'm sure was a big issue then as well - it still is today by those who want to publish more).

YOSM as multi-loggable Virtual won't be grandfathered. The Virtual cache can remain active as grandfathered and loggable - but the limitation was that caches fundamentally can now only have 1 Find log. To programmatically "Grandfather" the multi-logging capability is more complex than to allow a type to continue to exist (the restricted publish capability didn't affect their continued existence).

If supporters can somehow promote the benefits of keeping it around for its value to the game as a whole and the community above and beyond the necessary technical work to allow grandfathering of multi-loggable caches in the eyes of the Groundspeak PTB, then they might change their mind and set out to do the technical work. (And I'm sure it's not that it can't be done - I can easily imagine how it can be, as I'm sure could most programmers)

But GS has to see more value in doing the necessary work for exceptions than in making a strict cutoff for that capability across the board.

4.6k · April 6, 2017

- If logging a Note is just as much fun as logging a Find, why not do away with logs of all types and just have everyone use Notes?

Can't filter out caches we've found if everything was a note.

Is logging a Find intrinsically funner than logging a Note? :huh:

4.4k · April 6, 2017

Yes.

With a find, you have to prove to the CO - via emailed cap numbers in the case of YOSM et al - that you actually found the survey marker.

With notes, there's no quality control. Greetings from Germany! Could Groundspeak grant authority to delete bogus "notes"? That's a new concept, and I wouldn't count on it.

Edited April 6, 2017 by Viajero Perdido

4.6k · April 6, 2017

Is logging a Find intrinsically funner than logging a Note?

Yes.

With a find, you have to prove to the CO - via emailed cap numbers in the case of YOSM et al - that you actually found the survey marker.

Yes, that does sound like lots of fun :unsure:

And logging a note does of course disable all email client applications and software :unsure:

4.4k · April 6, 2017

You bypassed my point. Notes can pile up as unverified, so why actually climb that mountain?

Sure, it's a slight bother proving your find. So is climbing the mountain. Pulling it off and proving it is where the FUN comes in.

4.6k · April 6, 2017

You bypassed my point. Notes can pile up as unverified, so why actually climb that mountain?

Sure, it's a slight bother proving your find. So is climbing the mountain. Pulling it off and proving it is where the FUN comes in.

You can still do all of those things perfectly well using notes in combination with exactly the same email mechanism you've always used.

The point is, how is one more FUN than the other?

April 6, 2017

...then making an exception means building in an additional lookup or reference and explicitly including the ability to override the norm in order accomodate the grandfathering.

Those exceptions would also need to be coded into every 3rd party app, the website and the official app.

With notes, there's no quality control. Greetings from Germany! Could Groundspeak grant authority to delete bogus "notes"? That's a new concept, and I wouldn't count on it.

Of course there is! Every cache owner can delete notes, just as he/she can delete found it logs.

6.1k · April 6, 2017

...then making an exception means building in an additional lookup or reference and explicitly including the ability to override the norm in order accomodate the grandfathering.

Those exceptions would also need to be coded into every 3rd party app, the website and the official app.

Amlost certainly not.

It would be crazy to expect every app to check whether you've already logged the find before permitting you to log another find. The change to the apps will almost certainly be that if the app logs a find, and Groundspeak detects the previous find, then it will return a new status code in the API which the app has to recognise and display an appropriate error message; therefore as long as Groundspeak permits the find and returns a successful log status to the app then the app doesn't need to handle them any differently to any regular find.

April 6, 2017

Amlost certainly not.

It would be crazy to expect every app to check whether you've already logged the find before permitting you to log another find. The change to the apps will almost certainly be that if the app logs a find, and Groundspeak detects the previous find, then it will return a new status code in the API which the app has to recognise and display an appropriate error message; therefore as long as Groundspeak permits the find and returns a successful log status to the app then the app doesn't need to handle them any differently to any regular find.

This still requires changes in every app. Instead of just checking if the cache is found or not, the app will first have to ask the API, and then allow the user to write the log or not. How do you expect the app to handle that when in offline mode? If a user is allowed to write a log, use an hour to write it, and the is denied publishing because the API returned an error, that user will be mad. If he's not allowed to write the log in the first place, he probably won't be.

I'm just saying that there's a bit more work behind those exceptions than most people here seem to think. It's not as simple as "just adding them".

6.8k · April 6, 2017

You bypassed my point. Notes can pile up as unverified, so why actually climb that mountain?

Sure, it's a slight bother proving your find. So is climbing the mountain. Pulling it off and proving it is where the FUN comes in.

You can still do all of those things perfectly well using notes in combination with exactly the same email mechanism you've always used.

The point is, how is one more FUN than the other?

The way I understand the difference is that right now only logs are allowed as find logs on the YOSM cache that fulfill the requirements. Everyone can write a note and they could e.g.

try to make fun of the tagging system and post 100 notes with tags to perturb the stats and the cache owner could do absolutely nothing about it. There are rules for found it logs but not for notes.

As to the fun question: I can only speak for myself. I have never logged a brass cap cache but what I do know is that I prefer by far if a long and challenging hiking cache is logged as find only by those who did the hike. Finding my log among the logs of people who have not done the hike would not change my personal experience but would add a bad taste for me. It's like presenting a booklet with control stamps collected along a long hike and getting a certificate as return to showing your booklet - it is not the same as if everyone who claims to have done the hike gets the booklet.

Edited April 6, 2017 by cezanne

6.1k · April 6, 2017

Amlost certainly not.

It would be crazy to expect every app to check whether you've already logged the find before permitting you to log another find. The change to the apps will almost certainly be that if the app logs a find, and Groundspeak detects the previous find, then it will return a new status code in the API which the app has to recognise and display an appropriate error message; therefore as long as Groundspeak permits the find and returns a successful log status to the app then the app doesn't need to handle them any differently to any regular find.

This still requires changes in every app. Instead of just checking if the cache is found or not, the app will first have to ask the API, and then allow the user to write the log or not. How do you expect the app to handle that when in offline mode? If a user is allowed to write a log, use an hour to write it, and the is denied publishing because the API returned an error, that user will be mad. If he's not allowed to write the log in the first place, he probably won't be.

I'm just saying that there's a bit more work behind those exceptions than most people here seem to think. It's not as simple as "just adding them".

So in your scenario every app needs to keep track of all caches you've ever found while you're offline so it can prevent you even starting a duplicate find log? If you're in offline mode how is the app going to know about any finds you might have logged via another app or the website since this particular app was last online ? I bet you that won't be how it works.

April 6, 2017

So in your scenario every app needs to keep track of all caches you've ever found while you're offline so it can prevent you even starting a duplicate find log? If you're in offline mode how is the app going to know about any finds you might have logged via another app or the website since this particular app was last online ? I bet you that won't be how it works.

Fair point. Obviously I didn't think this through completely :anitongue:

But still, they will need to add a new error code. And every app will need to know to read that error code.

I guess most people will want their app to know about their finds, before they start using it. Most people would like that their finds are marked as found when looking at the map/list. So at least part of my previous example still make some sense.

6.8k · April 6, 2017

Of course there is! Every cache owner can delete notes, just as he/she can delete found it logs.

But on what basis if they do not contain insults?

For virtuals and ECs you have ALRs but only for found it logs.

April 6, 2017

But on what basis if they do not contain insults?
For virtuals and ECs you have ALRs but only for found it logs.

I think it's a lot easier to ask Groundspeak for approval to treat notes in the same way as found it logs on those to caches, and let the owner delete notes that haven't sent the correct answers, than to get them to add the exception they've said multiple times that they won't add.

If people want those caches to live on, they need to be creative, see the opportunities. Not just continue to ask for something that's not going to happen.

9k · April 6, 2017

So in your scenario every app needs to keep track of all caches you've ever found while you're offline so it can prevent you even starting a duplicate find log? If you're in offline mode how is the app going to know about any finds you might have logged via another app or the website since this particular app was last online ? I bet you that won't be how it works.

Fair point. Obviously I didn't think this through completely

But still, they will need to add a new error code. And every app will need to know to read that error code.

I guess most people will want their app to know about their finds, before they start using it. Most people would like that their finds are marked as found when looking at the map/list. So at least part of my previous example still make some sense.

If an API is designed well, known errors shouldn't have to be completely hard coded into every app that uses it. At worst an unhandled error should be returned with a generic instructions, at least in the form of a descriptive message. Right now any app using the API can't assume that a Find posting was successful; certainly they handle returned errors, and most likely handle errors that aren't hard-coded into the app. So a failed log upload, for whatever reason, doesn't need custom programming in the apps. It's not the apps this would affect - it's the GS programmers having to code the ability to override the restriction in the logging routine for grandfathering multi-log caches.

5.7k · April 6, 2017

Could Groundspeak grant authority to delete bogus "notes"? That's a new concept, and I wouldn't count on it.

Geocaching HQ only gets involved with found it logs being deleted. A CO can delete all others at their discretion. :anibad:

6.8k · April 6, 2017

But on what basis if they do not contain insults?
For virtuals and ECs you have ALRs but only for found it logs.

I think it's a lot easier to ask Groundspeak for approval to treat notes in the same way as found it logs on those to caches, and let the owner delete notes that haven't sent the correct answers, than to get them to add the exception they've said multiple times that they won't add.

I think both is something which won't happen.

15.3k · April 6, 2017

Geocaching HQ only gets involved with found it logs being deleted. A CO can delete all others at their discretion.

Yep.

Geocaching HQ can only reinstate "Found It" and "Attended" logs on cache pages.

April 6, 2017

If an API is designed well, known errors shouldn't have to be completely hard coded into every app that uses it. At worst an unhandled error should be returned with a generic instructions, at least in the form of a descriptive message. Right now any app using the API can't assume that a Find posting was successful; certainly they handle returned errors, and most likely handle errors that aren't hard-coded into the app. So a failed log upload, for whatever reason, doesn't need custom programming in the apps. It's not the apps this would affect - it's the GS programmers having to code the ability to override the restriction in the logging routine for grandfathering multi-log caches.

Yes, any API app will need to handle errors. But the user experience will be degraded if you're never alerted to problems before after trying to publish the log.

There's a reason Groundspeak sent this notification to the API partners. Every app already need to handle errors, like when you try to log a locked cache. But it's a lot better for the user to be blocked before using time on writing the log, than to get the error message after he's done.

If we look at GSAK, GSAK will immediately alert you if you try to save a log which has more than 4000 characters in it. You can apply your argument there as well. No need to check, just see if the API gives us any error messages. It's a lot better the way it actually work. GSAK alerts me before I'm done writing, so I get the chance to fix it right away.

And if the most important argument is to minimize confusion, all apps need to handle this before trying to publish the log. Otherwise you're just replacing one confusing thing, with another.

9k · April 6, 2017

But on what basis if they do not contain insults?
For virtuals and ECs you have ALRs but only for found it logs.

I think it's a lot easier to ask Groundspeak for approval to treat notes in the same way as found it logs on those to caches, and let the owner delete notes that haven't sent the correct answers, than to get them to add the exception they've said multiple times that they won't add.

I think both is something which won't happen.

I think it would be something Groundspeak wouldn't want to be a part of - resolve it between yourselves.

First, finders are posting notes to a cache page; that means they have no statistical value and are, in the context of GC, simply notes, information.

Second, because of their minimal value, COs have the right to delete notes to their content, whether or not they contain 'questionable' content.

Third, both CO and finder are making use of a third party tool to organize note content, which is entirely out of Groundspeak's hands.

My guess - What would Groundspeak say? Figure it out yourselves.

4.6k · April 6, 2017

If a user is allowed to write a log, use an hour to write it, and the is denied publishing because the API returned an error, that user will be mad.

Mad that the API won't let them submit their found log - or mad that they spent an hour in the field writing a log on a cache that they already found before?

Either way - is that ever going to happen?

Edited April 6, 2017 by Team Microdot

April 6, 2017

If a user is allowed to write a log, use an hour to write it, and the is denied publishing because the API returned an error, that user will be mad.

Mad that the API won't let them submit their found log - or mad that they spent an hour in the field writing a log on a cache that they already found before?

Either way - is that ever going to happen?

Probably both.

I write my logs in GSAK. GSAK use the API. So it doesn't have to be in the field

9k · April 6, 2017

If an API is designed well, known errors shouldn't have to be completely hard coded into every app that uses it. At worst an unhandled error should be returned with a generic instructions, at least in the form of a descriptive message. Right now any app using the API can't assume that a Find posting was successful; certainly they handle returned errors, and most likely handle errors that aren't hard-coded into the app. So a failed log upload, for whatever reason, doesn't need custom programming in the apps. It's not the apps this would affect - it's the GS programmers having to code the ability to override the restriction in the logging routine for grandfathering multi-log caches.

Yes, any API app will need to handle errors. But the user experience will be degraded if you're never alerted to problems before after trying to publish the log.

Yeah but a failed Find could happen for any number of reasons; ie it would only be a "new" concern if a post failed only because of a duplicate Find. I'd think that it would be up to the app developer to choose to add, for their own user experience, a pre-check if a cache has already been found. Even then, likely it would be a notice/reminder "Hey it looks like you've already logged this" rather than an app-restriction. I might start out creating it as a find, then change it to a note; I wouldn't want the app to not provide the option to begin making that log which might be posted as a note.

But anyway... point being, that's all third party UX.

The functionality (or handling the functionality of a failed send after composing) must already be in existence. An app that simply cancels and loses your composed content is just Bad Design.

I would think that notifying the API devs first gives them the ability and option to build that added user friendliness (however they prefer) if they haven't already, since it could happen more often.

But I wouldn't want the app to deny me starting to post a find (unless there was no way to save a draft, or change the log type or something else after composing it in the app, or if a failed send would lose the content).

Note that the notice for devs was about all the log type changes, not just Finds, so it made sense to include the Find log change anyway.

April 6, 2017

Note that the notice for devs was about all the log type changes, not just Finds, so it made sense to include the Find log change anyway.

That's true. And the time zone change was the most important one anyway.

7.5k · April 6, 2017

Yes, accidents happen, but you can't just say "accidents happen, so we'll stop them." You have to actually show that the accidents cause problems that are worse than the other problems your solution cause.

*I* don't have to. Groundspeak has deemed they are worth stopping. They have their reasons. Some people don't like those reasons.

So my original point stands uncontested: no one's given any examples to prove -- or even suggest, really -- that there's an actual problem that this change solves. If you're going to say I'm wrong, at least pretend to be able to back it up with something. It's just duplicitous to start the argument, then turn around and say you don't have to present your side of it.

GS may have its reasons, but we don't know what they are. All they provide in the announcement is vague justifications like streamlining, reduce confusion, and the wonderfully meta "because someone said we should".

...might be the occasional drama...

Reductionist... Hand waving away problems by minimizing the effect on people or the importance of the issues to anyone other than from your own perspective isn't helpful.

Actually, this exactly what I'm saying: there's nothing but hand waving behind the claim that there are any problems that preventing double logs solves.

15.3k · April 6, 2017

So my original point stands uncontested: no one's given any examples to prove -- or even suggest, really -- that there's an actual problem that this change solves. If you're going to say I'm wrong, at least pretend to be able to back it up with something.

For example, you could point to feature requests that mention duplicate logs in some way, such as:

7.5k · April 7, 2017

For example, you could point to feature requests that mention duplicate logs in some way, such as:

Yes, at least!

Some of those complain about a bug that some people -- not GS, by the way -- have suggested will be fixed by this change. I'm not sure the bug will be fixed, but if that's the motive for the change, then GS should say so. Then we could have a discussion about whether there are better ways to fix this bug, like, perhaps, one that doesn't leave the system open to the exact same bug on DNF logs.

Some of those are people saying "duplicate finds are posted and that shouldn't happen" yet, each time, the burden caused by the multiple logs seems trivial, so I remain unconvinced that's enough to justify stopping people that are legitimately using multiple found logs on a cache.

Of course, I appreciate yours the most, since you proposed a solution -- going back to counting caches found and found logs as two separate things -- that makes more sense and avoids killing other people's fun.

I also liked you including the example where even though the OP is complaining about multiple found it logs, he specifically says, "I realise that some caches may be legitimately logged as found more than once, so I'm not suggesting we ban multiple logs in this situation."

3.6k · April 7, 2017

Could Groundspeak grant authority to delete bogus "notes"? That's a new concept, and I wouldn't count on it.

Geocaching HQ only gets involved with found it logs being deleted. A CO can delete all others at their discretion.

Ohhhhhhh.... Drama!!!!

Changes to logging, specifically stopping double logs

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment