Jump to content

Changes to logging, specifically stopping double logs


Recommended Posts

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.

unsure.gif

 

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.

huh.gif

 

That's about all I can muster to this one, since we may as well just go back to the beginning of the thread.

Link to comment

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.

Link to comment

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.

Link to comment

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. :)

Link to comment

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).

Link to comment

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 by egroeg
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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 <_<

Link to comment

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: :ph34r:

Link to comment

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?

Link to comment

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: :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...

Link to comment

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.

Link to comment

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: :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.

Link to comment

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: :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.

Link to comment

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...

Link to comment

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.

Link to comment

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" ?

Link to comment

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...

Link to comment

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...

Link to comment

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?

Link to comment

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". :)

Link to comment

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?"

 

rolleyes.gif

Link to comment

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

Link to comment

...

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)

Link to comment

 

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 . :laughing:

 

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. :)

Link to comment

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.

Link to comment

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.

Link to comment

 

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 . :laughing:

 

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.

Link to comment
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

Link to comment
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?

Link to comment

 

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 . :laughing:

 

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.
     

Link to comment

 

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 . :laughing:

 

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.

Link to comment

 

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 . :laughing:

 

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..

Link to comment

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.

Link to comment

 

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 . :laughing:

 

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.

Link to comment

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...

Link to comment

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.

Link to comment

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 <_<

Link to comment

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
×
×
  • Create New...