+thebruce0 Posted April 11, 2017 Share Posted April 11, 2017 What constitutes "sympathy"? Recognizing that they're being impacted and reconsidering whether the change is really justified. Instead, all we get are people trying to talk them out of what they like. We know you don't like the change (at least, you don't like that/how GS implemented the change). But you haven't demonstrated why it shouldn't be implemented. Oh, brother. Nice illustration of not having any sympathy for the people complaining for pages and pages right here in this thread about losing some well loved caches. Perhaps I should reduce "recognizing" to simply listening to the people being impacted. That's about all I can muster to this one, since we may as well just go back to the beginning of the thread. Quote Link to comment
+Malpas Wanderer Posted April 11, 2017 Share Posted April 11, 2017 This is of course speculation, as that is really all we have here. To me, the issue that needs to be addressed and is actually the reason for the change is the duplicate logging issue, and that issue seems more common with the apps and more frequent lately. Whether due to pressing Submit multiple times, or timeout and automatic resubmission, the result is duplicate logs on the cache listings. I think the solution is mishandled though. It is not so much a matter than a cache shouldn't have multiple found logs for a given account. While rare, there are several examples that do make some sense, such as those brought up in this thread. A better implementation would be to 'not allow multiple found logs with the exact same text'. This way, it could prevent the bug where duplicate logs are posted, but still allow multiple logs if desired, as long as they were each written individually. (Oh, and you can't multiple log with just always TFTC, but I don't think that is really the issue). The most sensible solution to the problem to date. The only failing perhaps is if first log is accepted but not known to the poster. Poster minimally changes text to get it accepetd. Then two logs exist. That was the problem with the early duplicte logs. Second log submitted because acceptance report not seen. Still like the idea though with perhaps a % similarity check/rejection. Quote Link to comment
+dprovan Posted April 11, 2017 Share Posted April 11, 2017 This is of course speculation, as that is really all we have here. To me, the issue that needs to be addressed and is actually the reason for the change is the duplicate logging issue, and that issue seems more common with the apps and more frequent lately. Whether due to pressing Submit multiple times, or timeout and automatic resubmission, the result is duplicate logs on the cache listings. My guess is also that this double find restriction is mainly intended to fix the bug that causes unintentional duplicates. But notice that it doesn't actually fix the problem, it only prevents it for duplicate Find logs. DNFs, for example, will still produce duplicate logs. (Well, at least I assume DNFs have this problem: if they don't, then GS should figure out what keeps them from having this problem and applying it to Finds.) I think the solution is mishandled though. It is not so much a matter than a cache shouldn't have multiple found logs for a given account. While rare, there are several examples that do make some sense, such as those brought up in this thread. A better implementation would be to 'not allow multiple found logs with the exact same text'. This way, it could prevent the bug where duplicate logs are posted, but still allow multiple logs if desired, as long as they were each written individually. This is a pragmatic fix that handles the problem for all log types. Quote Link to comment
+cerberus1 Posted April 12, 2017 Share Posted April 12, 2017 To me, the issue that needs to be addressed and is actually the reason for the change is the duplicate logging issue, and that issue seems more common with the apps and more frequent lately. Whether due to pressing Submit multiple times, or timeout and automatic resubmission, the result is duplicate logs on the cache listings. By the announcement, "Players will no longer be able to log more than 1 (one) Find, Attended, Webcam Photo Taken, or Will Attend per cache". Notice that double and duplicate aren't mentioned (as well as exact same text...). We haven't noticed too many app issues since the kids kinda lost interest within a year after the Intro version, but we thought it a good idea that the site's looking to help us and them a bit. - No more double logs that might have been easily deleted by COs. Just speculation, but instead of the apps, I thought it had more to do with the folks who still insist on multi logging temp caches at events, or log multiple "camping" type events that were frowned on by guidelines. One's even linked to in this thread. Quote Link to comment
+on4bam Posted April 12, 2017 Share Posted April 12, 2017 it only prevents it for duplicate Find logs. DNFs, for example, will still produce duplicate logs. (Well, at least I assume DNFs have this problem: if they don't, then GS should figure out what keeps them from having this problem and applying it to Finds.) Multiple DNF's should be possible as it may take several tries to find a cache. Once found, however, the next time you don't have to "find" it anymore as you know where it is (yes, there are a few exceptions). Quote Link to comment
+egroeg Posted April 12, 2017 Share Posted April 12, 2017 (edited) Wondering out loud... A duplicate log can either be accidental or deliberate. If accidental, then the Test for Duplicate Log Subroutine will eliminate If deliberate, then it is either for a previously "acceptable" cache, like the markers, or for those people that log temps at events. If TPTB were willing to keep the "acceptables", wouldn't a quick test in the logging program take care of this? Such as "If cache="GCxxx" then skip the Test for Duplicate Log Subroutine" Edited April 12, 2017 by egroeg Quote Link to comment
+noncentric Posted April 14, 2017 Share Posted April 14, 2017 I think the solution is mishandled though. It is not so much a matter than a cache shouldn't have multiple found logs for a given account. While rare, there are several examples that do make some sense, such as those brought up in this thread. A better implementation would be to 'not allow multiple found logs with the exact same text'. This way, it could prevent the bug where duplicate logs are posted, but still allow multiple logs if desired, as long as they were each written individually. I'm not sure that unintended duplicate logs will always have the same text. I've only received 1 duplicate log and such a test would not have caught it. First log was 12 words long. Second log, received 8 minutes later, was 14 words long. There were only 2 words shared by both logs. Nice, so Groundspeak is purely a commercial company and it is just fine and dandy to behave like Apple who are renowned for their lack of compatibility and support for older devices. I have no problem with changes, most things do. However some of us like a few things to stay where they are, giving pleasure to many, especially where there has been no good reason supplied. What is next, get rid of puzzles because they are too hard? Multis because too few new players can be bothered with them and might be confused? Correct me if I'm wrong, but that's exactly what the official Groundspeak app does. The app doesn't get rid of puzzles and multis. It just restricts those caches to cachers that are willing to pay for the convenience of finding caches via the app. What constitutes "sympathy"? Recognizing that they're being impacted and reconsidering whether the change is really justified. Instead, all we get are people trying to talk them out of what they like. I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. Quote Link to comment
+lodgebarn Posted April 14, 2017 Share Posted April 14, 2017 I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. I think it quite likely that this was not considered at all until after the discussions started. Quote Link to comment
+noncentric Posted April 14, 2017 Share Posted April 14, 2017 I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. I think it quite likely that this was not considered at all until after the discussions started. The quote that I quoted is the one I was responding to, and that quote did not specify recognizing the impact BEFORE making the announcement. I read it as recognizing the impact. If the poster that I quoted meant that that recognition should've been before the announcement, then my apologies for not reading that between the lines. Quote Link to comment
+dprovan Posted April 14, 2017 Share Posted April 14, 2017 What constitutes "sympathy"? Recognizing that they're being impacted and reconsidering whether the change is really justified. Instead, all we get are people trying to talk them out of what they like. I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. I was speaking of sympathy from people here in this discussion, not from GS. I don't pretend to know what GS is thinking unless they tell me. Quote Link to comment
+Team Microdot Posted April 14, 2017 Share Posted April 14, 2017 What constitutes "sympathy"? Recognizing that they're being impacted and reconsidering whether the change is really justified. Instead, all we get are people trying to talk them out of what they like. I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. I was speaking of sympathy from people here in this discussion, not from GS. I don't pretend to know what GS is thinking unless they tell me. In which case sympathy has been shown here in this thread for the impact on YOSM and brass caps. Quote Link to comment
+noncentric Posted April 14, 2017 Share Posted April 14, 2017 What constitutes "sympathy"? Recognizing that they're being impacted and reconsidering whether the change is really justified. Instead, all we get are people trying to talk them out of what they like. I'm pretty sure that TPTB know/recognize that cachers are being affected by their announced logging restrictions. Their official announcement was updated to clarify that they will not make exceptions for specific caches. I don't believe they would've made that clarification if they weren't aware of the discussions requesting exceptions for specific caches, and if they hadn't considered whether to make exceptions or not. I was speaking of sympathy from people here in this discussion, not from GS. I don't pretend to know what GS is thinking unless they tell me. In which case sympathy has been shown here in this thread for the impact on YOSM and brass caps. +1 I don't agree that "all we get are people trying to talk them out of what they like". There have been multiple cachers that have expressed sympathy that YOSM won't be able to continue as it has. Only a small number of cachers have seemed dismissive of YOSM fans' concerns, although they've posted multiple times in this thread and so maybe that has amplified their tone. Quote Link to comment
+dprovan Posted April 14, 2017 Share Posted April 14, 2017 I don't agree that "all we get are people trying to talk them out of what they like". There have been multiple cachers that have expressed sympathy that YOSM won't be able to continue as it has. Only a small number of cachers have seemed dismissive of YOSM fans' concerns, although they've posted multiple times in this thread and so maybe that has amplified their tone. I apologize if I was hyperbolic, but what I'm not seeing is any tendency to appreciate the other side to the point reconsidering the basic premise that multiple find logs must be prevented. To me, all those people saying, "Gee, you can still have fun by just posting notes" are being dismissive, but I suspect you would class them as being sympathetic. Quote Link to comment
+Team Microdot Posted April 14, 2017 Share Posted April 14, 2017 I don't agree that "all we get are people trying to talk them out of what they like". There have been multiple cachers that have expressed sympathy that YOSM won't be able to continue as it has. Only a small number of cachers have seemed dismissive of YOSM fans' concerns, although they've posted multiple times in this thread and so maybe that has amplified their tone. I apologize if I was hyperbolic, but what I'm not seeing is any tendency to appreciate the other side to the point reconsidering the basic premise that multiple find logs must be prevented. To me, all those people saying, "Gee, you can still have fun by just posting notes" are being dismissive, but I suspect you would class them as being sympathetic. I've known some here to be a lot more dismissive in their posting style Quote Link to comment
+bflentje Posted April 14, 2017 Share Posted April 14, 2017 Wondering out loud... A duplicate log can either be accidental or deliberate. If accidental, then the Test for Duplicate Log Subroutine will eliminate If deliberate, then it is either for a previously "acceptable" cache, like the markers, or for those people that log temps at events. If TPTB were willing to keep the "acceptables", wouldn't a quick test in the logging program take care of this? Such as "If cache="GCxxx" then skip the Test for Duplicate Log Subroutine" You wouldn't ever want to hard code a GC # into the code. Instead you create a new table in the database that contains the exceptions.. then it would be like.. If cache not in (select caches from exceptions).. :ph34r: Quote Link to comment
+WearyTraveler Posted April 16, 2017 Share Posted April 16, 2017 If it ain't broke don't fix it But this was broke, and now they're fixing it +1 I do not agree that disallowing NM and DNF logs for cache owners is fixing something which was broken. Why shouldn't a CO log a DNF followed by some other log type if they could not find the cache? Or log a NM if they realized that a cache needs maintenance to be done later? Next time they disallow DNF logs once one has previously logged a find. (I have done that several times.) It seems that more and more Find is seen as a way to increase a score counter. If a newer community member cannot be expected to read logs and understand that it can happen that a CO logs a NM or a DNF, they rather should invest some time to read about geocaching than the COs should be forced to change their logging style. My impression was that they're going to fix / disallow multiple "found it" and "attended" logs on a single cache. I didn't think it would effect anyone's ability to put multiple needs maintenance or DNFs (I post a dnf every time I unsuccessfully search for a cache, not just the first time I can't find it). Or am I reading something wrong? Quote Link to comment
+WearyTraveler Posted April 16, 2017 Share Posted April 16, 2017 Wondering out loud... A duplicate log can either be accidental or deliberate. If accidental, then the Test for Duplicate Log Subroutine will eliminate If deliberate, then it is either for a previously "acceptable" cache, like the markers, or for those people that log temps at events. If TPTB were willing to keep the "acceptables", wouldn't a quick test in the logging program take care of this? Such as "If cache="GCxxx" then skip the Test for Duplicate Log Subroutine" You wouldn't ever want to hard code a GC # into the code. Instead you create a new table in the database that contains the exceptions.. then it would be like.. If cache not in (select caches from exceptions).. :ph34r: I've done just a little programming and it seems pretty easy to implement an exceptions list / subroutine. But we see the fun we're having with the new caching app... Quote Link to comment
+WearyTraveler Posted April 16, 2017 Share Posted April 16, 2017 Just a quick / additional data point. There was a WearyTraveler Travel Bug Visit hotel in Reston, Va that moved from its original position a while ago. I found it in its initial location, then when it was moved, I had to search / find it all over again. Hence - 2 found logs for me. I know that it's a rare occasion when a cache is moved, but it happens. Quote Link to comment
+Team Microdot Posted April 16, 2017 Share Posted April 16, 2017 Wondering out loud... A duplicate log can either be accidental or deliberate. If accidental, then the Test for Duplicate Log Subroutine will eliminate If deliberate, then it is either for a previously "acceptable" cache, like the markers, or for those people that log temps at events. If TPTB were willing to keep the "acceptables", wouldn't a quick test in the logging program take care of this? Such as "If cache="GCxxx" then skip the Test for Duplicate Log Subroutine" You wouldn't ever want to hard code a GC # into the code. Instead you create a new table in the database that contains the exceptions.. then it would be like.. If cache not in (select caches from exceptions).. :ph34r: I've done just a little programming and it seems pretty easy to implement an exceptions list / subroutine. But we see the fun we're having with the new caching app... The more I check out the new app the more confused I am about how whoever wrote it could come up with something so diametrically opposed to intuitive. Quote Link to comment
+Harry Dolphin Posted April 16, 2017 Share Posted April 16, 2017 Wondering out loud... A duplicate log can either be accidental or deliberate. If accidental, then the Test for Duplicate Log Subroutine will eliminate If deliberate, then it is either for a previously "acceptable" cache, like the markers, or for those people that log temps at events. If TPTB were willing to keep the "acceptables", wouldn't a quick test in the logging program take care of this? Such as "If cache="GCxxx" then skip the Test for Duplicate Log Subroutine" You wouldn't ever want to hard code a GC # into the code. Instead you create a new table in the database that contains the exceptions.. then it would be like.. If cache not in (select caches from exceptions).. :ph34r: I've done just a little programming and it seems pretty easy to implement an exceptions list / subroutine. But we see the fun we're having with the new caching app... Wow! What an excellent and easy way to permit/grandfather those two old and excellent caches! Go for it, GS. Quote Link to comment
+cerberus1 Posted April 16, 2017 Share Posted April 16, 2017 Just a quick / additional data point. There was a WearyTraveler Travel Bug Visit hotel in Reston, Va that moved from its original position a while ago. I found it in its initial location, then when it was moved, I had to search / find it all over again. Hence - 2 found logs for me. Curious, what point? If a cache had the same GC number, it's the same cache. Why not a Write Note if grabbing/dropping/swapping trackables like the Guidelines suggest? This isn't something new... Quote Link to comment
+narcissa Posted April 17, 2017 Share Posted April 17, 2017 Just a quick / additional data point. There was a WearyTraveler Travel Bug Visit hotel in Reston, Va that moved from its original position a while ago. I found it in its initial location, then when it was moved, I had to search / find it all over again. Hence - 2 found logs for me. Curious, what point? If a cache had the same GC number, it's the same cache. Why not a Write Note if grabbing/dropping/swapping trackables like the Guidelines suggest? This isn't something new... Just noticed that this user thinks logging two separate logs on his own cache is okay but other people finding a cache as a group is bad. Always kind of neat to see how different groups of cachers develop totally unique sets of rules and ethics. But yeah, seems like most experienced cachers would use a note in this scenario. I don't see that it really matters, but it is a bit odd. Quote Link to comment
+MartyBartfast Posted April 17, 2017 Share Posted April 17, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... 1 Quote Link to comment
+cerberus1 Posted April 17, 2017 Share Posted April 17, 2017 Okay, the other 2/3rds reminded me... This is one I never heard of before, thought it's possible just never noticed. In conversation last week, one attending many events (including most Megas) since '05 was upset that, "Events get Groundspeak support based on the number of people attending. When people who cache as a family under a team name log a will attend for each member of their family attending then they are giving an accurate and true account of who will be at the event and the event gets proper level of support. With this new rule, the count is jeopardized, the support is compromised and the event suffers". We always used the one account (though we have two) and simply mentioned that "we're" attending at most events (locals know it's two...) , and leave a "two of us" if outta the area. Mega events, we order two of whatever level for "stuff", so figured that was their "true count". Anyone else multi-log in their entire family to keep "an accurate count" ? Quote Link to comment
+WearyTraveler Posted April 17, 2017 Share Posted April 17, 2017 Just a quick / additional data point. There was a WearyTraveler Travel Bug Visit hotel in Reston, Va that moved from its original position a while ago. I found it in its initial location, then when it was moved, I had to search / find it all over again. Hence - 2 found logs for me. Curious, what point? If a cache had the same GC number, it's the same cache. Why not a Write Note if grabbing/dropping/swapping trackables like the Guidelines suggest? This isn't something new... My auto replace screwed up this post. It wasnt my Tb hotel. It was someone else's. My autoreplace changed "tb" to "WearyTraveler Travel Bug Visit". Sometimes I don't catch that... :-/ My original point is that regardless of the cache code, ve to a different location in the park resulted in a new search and a second find... Quote Link to comment
+WearyTraveler Posted April 17, 2017 Share Posted April 17, 2017 Just a quick / additional data point. There was a WearyTraveler Travel Bug Visit hotel in Reston, Va that moved from its original position a while ago. I found it in its initial location, then when it was moved, I had to search / find it all over again. Hence - 2 found logs for me. Curious, what point? If a cache had the same GC number, it's the same cache. Why not a Write Note if grabbing/dropping/swapping trackables like the Guidelines suggest? This isn't something new... Also - I traveled extensively back then. I logged a "write note" and listed bugs in and out. So, no, I'm not advocating a "found" log for a visit. My initial post wasn't to advocate Willy nilly double posting of finds. It was to point out an instance where a cache can be found more than once... Quote Link to comment
+WearyTraveler Posted April 17, 2017 Share Posted April 17, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Thank you. Quote Link to comment
+WearyTraveler Posted April 17, 2017 Share Posted April 17, 2017 Okay, the other 2/3rds reminded me... This is one I never heard of before, thought it's possible just never noticed. In conversation last week, one attending many events (including most Megas) since '05 was upset that, "Events get Groundspeak support based on the number of people attending. When people who cache as a family under a team name log a will attend for each member of their family attending then they are giving an accurate and true account of who will be at the event and the event gets proper level of support. With this new rule, the count is jeopardized, the support is compromised and the event suffers". We always used the one account (though we have two) and simply mentioned that "we're" attending at most events (locals know it's two...) , and leave a "two of us" if outta the area. Mega events, we order two of whatever level for "stuff", so figured that was their "true count". Anyone else multi-log in their entire family to keep "an accurate count" ? Probably not many people know that more attendees equals more support (may be intuitive, but...). I know a lot of teams log finds wi a team account - but wouldn't your issue be resolved by each of you logging individually for events and as a team for caches? Quote Link to comment
+cerberus1 Posted April 17, 2017 Share Posted April 17, 2017 Okay, the other 2/3rds reminded me... This is one I never heard of before, thought it's possible just never noticed. In conversation last week, one attending many events (including most Megas) since '05 was upset that, "Events get Groundspeak support based on the number of people attending. When people who cache as a family under a team name log a will attend for each member of their family attending then they are giving an accurate and true account of who will be at the event and the event gets proper level of support. With this new rule, the count is jeopardized, the support is compromised and the event suffers". We always used the one account (though we have two) and simply mentioned that "we're" attending at most events (locals know it's two...) , and leave a "two of us" if outta the area. Mega events, we order two of whatever level for "stuff", so figured that was their "true count". Anyone else multi-log in their entire family to keep "an accurate count" ? Probably not many people know that more attendees equals more support (may be intuitive, but...). I know a lot of teams log finds wi a team account - but wouldn't your issue be resolved by each of you logging individually for events and as a team for caches? I don't believe I have an issue, and there shouldn't be a language barrior... I was referring to another who thinks folks multi-log their account several times to include all family member attending an event, when guidelines say " let the event host know how many people you're bringing". May be why "Will Attend" was included in that "Players will no longer be able to log more than 1 (one) Find, Attended, Webcam Photo Taken, or Will Attend per cache". Quote Link to comment
+narcissa Posted April 17, 2017 Share Posted April 17, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. Quote Link to comment
+Team Hugs Posted April 17, 2017 Share Posted April 17, 2017 I've done just a little programming and it seems pretty easy to implement an exceptions list / subroutine. "Gee, I have no direct knowledge of the programs that HQ uses to run the website, maintain the master database, support the partner API, and run the officially-sponsored app. I have no idea what impact this change might have on those intricate systems. But I've done a little programming, and it seems pretty easy to me, so what could possibly go wrong?" Quote Link to comment
+fuzziebear3 Posted April 17, 2017 Share Posted April 17, 2017 While it might (or might not) be easy to code an exception list, is it really a good solution? It would lead to more appeals and more work as to why this cache or that cache should or should not be on the exception list, and someone has to then maintain the list. Right now, these are the possible exceptions I can name off the top of my head: Brass Caps and YOSM Traveling caches Events that are recycled Monthly challenge type caches that can be achieved multiple times Quote Link to comment
+MartyBartfast Posted April 17, 2017 Share Posted April 17, 2017 ... and someone has to then maintain the list. ... Not really, if they were going to do it then they would only grandfather in existing caches, so they would create the list right now and it would remain static, no newly created caches would be allowed to be logged multiple times. (I don't expect for one minute they will, so this is just hypothetical) Quote Link to comment
+cerberus1 Posted April 17, 2017 Share Posted April 17, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Quote Link to comment
+thebruce0 Posted April 17, 2017 Share Posted April 17, 2017 Right, conceptually it's not hard to imagine. But there are 2 feasibility issues the company has to consider were they to grandfather this functionality: 1) Additional development cost/time/testing 2) Ongoing perpetual strain (as little as it may be) on the database for a feature that is effectively obsolete, yet maintained (an additional cross-reference table in queries to retain capability of an old functionality), until some arbitrary point in the future (if at all) when grandfathered features are removed. Quote Link to comment
+dprovan Posted April 17, 2017 Share Posted April 17, 2017 Right, conceptually it's not hard to imagine. But there are 2 feasibility issues the company has to consider were they to grandfather this functionality: 1) Additional development cost/time/testing 2) Ongoing perpetual strain (as little as it may be) on the database for a feature that is effectively obsolete, yet maintained (an additional cross-reference table in queries to retain capability of an old functionality), until some arbitrary point in the future (if at all) when grandfathered features are removed. This is very true, but I suspect there's a third consideration that's even more important to GS: exceptions are conceptually ugly and, in fact, require actual user-support effort to explain over and over why they aren't allowed in new caches. In a huge, very popular case like Virtual Caches, they decided to bite the bullet (although I suspect they regret that decision, too), but there are so few of these exceptional caches that are routinely found multiple times, I'd guess GS would consider this cost to be way more than the caches are worth even before considering the implementation overhead you've described. Indeed, I have to suspect this might have been one of the reasons for adding the no duplicate log rule to begin with, since the rule neatly gets rid of a couple caches that shouldn't really have existed in the first place. I wouldn't like that being the reason, but I can see the logic behind it if it was part of the thinking. Quote Link to comment
+thebruce0 Posted April 17, 2017 Share Posted April 17, 2017 Agreed. ..wait whut? Quote Link to comment
+narcissa Posted April 17, 2017 Share Posted April 17, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Okay, now I am confused. If we're talking about multiple found logs on the same cache, that does still strike me as an odd, yet harmless thing to do. It's especially odd given other elements of this person's personal caching ethic, but people arrive at these things from different directions. Quote Link to comment
+paleolith Posted April 18, 2017 Share Posted April 18, 2017 The more I check out the new app the more confused I am about how whoever wrote it could come up with something so diametrically opposed to intuitive. This at least has an easy answer. Several coordinating answers actually. Programmers don't see things the way users do, yet programmers design and write software with interfaces based on what they themselves understand and like. They do so without testing on Real Users. They do so without involving User Experience (UX) professionals, or even the more narrowly defined User Interface (UI) specialists. Even experienced designers need to test on Real Users rather than trusting their own beliefs about what will work. For a good collection of articles, see https://www.nngroup.com/articles/ GC does not have a record of doing sufficient user testing. I won't claim they don't do any, simply because I have no knowledge of their internal processes. But we've seen many cases where the both the initial design and the final product show many signs of inadequate Real User testing. On the other hand, what we on the forums think is equally suspect. We are the 1%, or more likely the 0.01%. We do not represent the bulk of Real Users either. Even allowing for the expected high rate of lurkers, far more than 99% of GC users never visit these forums. Edward Quote Link to comment
+Team Microdot Posted April 18, 2017 Share Posted April 18, 2017 On the other hand, what we on the forums think is equally suspect. We are the 1%, or more likely the 0.01%. We do not represent the bulk of Real Users either. Edward Speak for yourself. Quote Link to comment
+cerberus1 Posted April 18, 2017 Share Posted April 18, 2017 The more I check out the new app the more confused I am about how whoever wrote it could come up with something so diametrically opposed to intuitive. This at least has an easy answer. Several coordinating answers actually. Programmers don't see things the way users do, yet programmers design and write software with interfaces based on what they themselves understand and like. They do so without testing on Real Users. They do so without involving User Experience (UX) professionals, or even the more narrowly defined User Interface (UI) specialists. Even experienced designers need to test on Real Users rather than trusting their own beliefs about what will work. For a good collection of articles, see https://www.nngroup.com/articles/ GC does not have a record of doing sufficient user testing. I won't claim they don't do any, simply because I have no knowledge of their internal processes. But we've seen many cases where the both the initial design and the final product show many signs of inadequate Real User testing. On the other hand, what we on the forums think is equally suspect. We are the 1%, or more likely the 0.01%. We do not represent the bulk of Real Users either. Even allowing for the expected high rate of lurkers, far more than 99% of GC users never visit these forums. Edward First, I'd like to +1 Team Microdot's post... You don't think that senior staff at Groundspeak are "Real Users"? - Those same senior staff members who kinda started this game/hobby? Quote Link to comment
+WearyTraveler Posted April 18, 2017 Share Posted April 18, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Okay, now I am confused. If we're talking about multiple found logs on the same cache, that does still strike me as an odd, yet harmless thing to do. It's especially odd given other elements of this person's personal caching ethic, but people arrive at these things from different directions. Not sure if the comment was directed at me. And not sure of the ethics meaning. However, I don't log finds for my caches. Other than "attended" once at my own events. I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. I by no means advocate multiple found logs for the same cache in the same cords. I've never seen a "moving cache" so I've no opinion on logging those once or multiple times. Quote Link to comment
+narcissa Posted April 19, 2017 Share Posted April 19, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Okay, now I am confused. If we're talking about multiple found logs on the same cache, that does still strike me as an odd, yet harmless thing to do. It's especially odd given other elements of this person's personal caching ethic, but people arrive at these things from different directions. Not sure if the comment was directed at me. And not sure of the ethics meaning. However, I don't log finds for my caches. Other than "attended" once at my own events. I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. I by no means advocate multiple found logs for the same cache in the same cords. I've never seen a "moving cache" so I've no opinion on logging those once or multiple times. Yeah, the second point is fairly unconventional, though harmless (and soon to be impossible with the imminent changes). Just strikes me as a funny quirk because this user account posted something similarly unconventional elsewhere. Quote Link to comment
+WearyTraveler Posted April 19, 2017 Share Posted April 19, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Okay, now I am confused. If we're talking about multiple found logs on the same cache, that does still strike me as an odd, yet harmless thing to do. It's especially odd given other elements of this person's personal caching ethic, but people arrive at these things from different directions. Not sure if the comment was directed at me. And not sure of the ethics meaning. However, I don't log finds for my caches. Other than "attended" once at my own events. I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. I by no means advocate multiple found logs for the same cache in the same cords. I've never seen a "moving cache" so I've no opinion on logging those once or multiple times. Yeah, the second point is fairly unconventional, though harmless (and soon to be impossible with the imminent changes). Just strikes me as a funny quirk because this user account posted something similarly unconventional elsewhere. Please elaborate.. Quote Link to comment
+J Grouchy Posted April 19, 2017 Share Posted April 19, 2017 I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. Whatever for? If it's "far enough away to require a search," perhaps it should have been archived and published as a new cache. Quote Link to comment
+narcissa Posted April 19, 2017 Share Posted April 19, 2017 Just noticed that this user thinks logging two separate logs on his own cache is okay ... Don't think it's their cache, their TB visited someone else's TB hotel twice..... Okay, that seems to make more sense. No mention from me of logging their own cache, but in this post you were somehow missed . Seriously though, does it make sense to log another Found IT on the same cache, when simply accessing trackables? Further, I get it if repeated Found It logs were on a "moving cache" type, but guess I don't get (following guidelines...) logging a second time just because a cache (with the same GC#...) was moved. Okay, now I am confused. If we're talking about multiple found logs on the same cache, that does still strike me as an odd, yet harmless thing to do. It's especially odd given other elements of this person's personal caching ethic, but people arrive at these things from different directions. Not sure if the comment was directed at me. And not sure of the ethics meaning. However, I don't log finds for my caches. Other than "attended" once at my own events. I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. I by no means advocate multiple found logs for the same cache in the same cords. I've never seen a "moving cache" so I've no opinion on logging those once or multiple times. Yeah, the second point is fairly unconventional, though harmless (and soon to be impossible with the imminent changes). Just strikes me as a funny quirk because this user account posted something similarly unconventional elsewhere. Please elaborate.. I don't really know what there is to elaborate on. Most experienced cachers wouldn't log a second find in that circumstance, so that makes it a bit unconventional as a personal caching rule or ethic. I don't personally have a problem with it, or with any of the instances of double-logging that are going to be eliminated by the changes. It's just interesting to see variations in people's thinking, that's all. Also interesting because I'm sure someone will be along shortly to shout about how very deeply wrong it is to log it a second time, even though it doesn't actually matter. Quote Link to comment
+WearyTraveler Posted April 19, 2017 Share Posted April 19, 2017 I do advocate logging a second found when the cache is moved to another location - while it was in the same park, it was still far enough away to require a search, so it was actually found twice. Whatever for? If it's "far enough away to require a search," perhaps it should have been archived and published as a new cache. I agree with you on that point. However, I neither owned the cache or was part of the powers that be. I did nothing more than find the same GC code in 2 different containers at 2 different spots. I had 2 choices - find it again so I could move bugs globally, or look for a much less convenient TB hotel in another city somewhere. All I did in my initial post was to point out an actual instance where a 2nd found log seems legit. This resulted in a flurry of BS and even my caching "ethics" being called into question... Come on... Quote Link to comment
+on4bam Posted April 19, 2017 Share Posted April 19, 2017 I had 2 choices - find it again so I could move bugs globally, or look for a much less convenient TB hotel in another city somewhere. Or you could have done what many others do/did. Post a note dropping/retrieving the TB(s). Quote Link to comment
+WearyTraveler Posted April 19, 2017 Share Posted April 19, 2017 I had 2 choices - find it again so I could move bugs globally, or look for a much less convenient TB hotel in another city somewhere. Or you could have done what many others do/did. Post a note dropping/retrieving the TB(s). Which I did, dozens of times. 2 finds and dozens of write notes... You'd think I kicked a puppy by stating an instance of where a double log seems legit. Quote Link to comment
+Team Microdot Posted April 19, 2017 Share Posted April 19, 2017 I had 2 choices - find it again so I could move bugs globally, or look for a much less convenient TB hotel in another city somewhere. Or you could have done what many others do/did. Post a note dropping/retrieving the TB(s). You'd think I kicked a puppy by stating an instance of where a double log seems legit. I expect some people just find the idea a bit lame under the circumstances you've described - a bit like the suggestion that anyone holding an opinion which differs from your own is overly emotional Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.