Improving Moveable Caches

Discussion about the Geocaching Australia web site
User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 9:11 am

Found + Moved doubles my logging requirement if I find and move it in the same day before heading home. Not going to happen.

Please consider "how" we would detect whether you need to make a second log. Logs can come through in many orders. Some of which are backdated. e.g. A Moved followed by a found. The system keeps the log date as well as the actual date / time the log is entered to the system. So if the logs come through out of order, it's not possible to determine their order if they are logged for the same date.

Adding to the confusion will be people who make a found, then change it to a note (so they don't get a 2nd smiley face), then what? Moved without being found? Then of course, people can just log a note (to avoid the 2nd find). They have taken it. So a "found and taken" doesn't work. You would also need a "noted and taken" and a "noted and left behind". What do you do when people make a note, then someone else makes a note, then someone does something else. Then it gets a "needs maintenance" and "maintained". It's not hard to get 4 logs, none of which are found or moved. The last 4 logs are neither found nor moved. The ONLY way to decide where the cache is will be to ... read the logs.

We are getting into some very complex solution definition for what is essentially a trivial issue. The way to get around the trivial issue is to ... read the last log and decide whether it's there or not. Remember, even though we may invest time getting the issue from 80% accurate to 90% accurate, the cache will move between the time you looked at the site (downloaded file, etc) and when you get there.

I know I sound like a broken record and like I'm not willing to solve the problem. What I want to avoid ( by looking at all of the technical challenges ) is to not introduce something that makes logging more complex, annoys people at logging time and STILL find that there are people bitching and complaining about the remaining 10% that they need to look at to determine where the cache is.

Realistically, how many caches did you have to look at to determine where they were? Every one? 50%? 20%? How many did you just go look for because you hoped they may still be there? i.e. How big is the problem? There were 494 frogs in the game, a non-trivial number, but will get bigger as the games progress. There were some 7,000 moves logged. There were some 10,000 finds logged. That means there were some 3,000 finds that either did not move the cache or were used in a "found + moved" scenario. By changing the logging structure 30% of the logs would be impacted by having to log more than one log against the cache. 30% is a hell of a big number in terms of user impact. What I also consider if that if we make the system "foolproof" to the 99% accurate (without having to read logs), how many people will stop with moving caches because the logging is too onerous? People like to find and move caches. Not spend a significant amount of time typing up found and moved logs. Short logs is evidence of that. So adding mandatory logging structures will decrease the fun and enjoyment of people who are finding and moving, to benefit a few who want the system to feed them the location.

Again, not trying to be obstructionist, but for every scenario you can think of to "fix the issue" there are people who WILL NOT follow the logging process AND the system (used normally) will lose track of the status of the cache and its location.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 02 February 12 9:42 am

hmm perhaps we a looking at this wrong perhaps these "Movable caches" should not be treated like caches and more like.. errr Trackables.
I think the problem is we are trying to push this round peg into a square hole.

And as far as the argument of just "read the logs it" is that is not 100% reliable so we need to improve that hence the debate.

If this "Grabbed" method as worked for trackables then why not Movables.

Solution 1. convert Movables to Trackables or Swaggies??
Solution 2. Add Grabbed log type for Movable Caches.

User avatar
blossom*
3000 or more caches found
3000 or more caches found
Posts: 1589
Joined: 25 February 09 1:59 pm
Location: West Ryde

Re: Improving Moveable Caches

Post by blossom* » 02 February 12 9:55 am

No, the whole idea of a Moveable Cache is that it is a cache and it can move. Except when there is a game on, they work pretty well. Of course you know they're moveable and have to check the last log but that's the nature of a moveable cache.

If you wanted the game to be about trackables, next year (well, the end of this year really) we could vote on having a moveable cache or a Swaggie race instead.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 10:14 am

Trackables do not go out in GPX files, so the log types are the additional (and non-trivial) difference.

Reading the logs is not reliable, of course not.
Adding complexity is not reliable either. Then you have to deal with added logging and people changing log types and entering co-ords in the middle of the ocean and a status which goes from "available" to "unavailable" and you STILL have to read the logs.

It's the same as a trackable. The cache listing says it's in there. You get there and half the time, it's not. Stuff that moves around cannot be tracked. With a trackable you are also GRABBING it OUT of a cache. With a moving cache, you are taking the WHOLE thing. So there is no need to "check it out before you can check it in".

During the game, how many caches did you have to read the logs for? How many turned out to be there vs. not there because the log did not explain where the cache was? If you're looking at a dozen caches in an area, how hard is it to read the last logs for the caches?

Now, we compare to enforced logging doubling the logs needed for moving a cache. Remember 3,000 logs during the game would need to be "double logged". i.e. 30% of the found logs. We add complexity to the people playing the game in their logging. We make the "task of logging so much more difficult".

Some of you (not you specifically, but the generic you) are simply not looking at the impact from outside your own perspective. You are saying "how do I make it easier for ME to determine where the cache is" vs. "what's the best compromise for EVERYONE across the WHOLE gamut of look, find, log, move, etc". Forcing me to log a "found" and then "moved" will stop me playing the game. Not an exaggeration. I do not enjoy typing up my logs and I'll be buggered if I'm going to log TWICE as many as now, just to make it easier for you. If I want to look at this from MY perspective, I would never have had a moved type. It would have all be done on the found types. One log, all done.

If I look at this from the perspective of a n00b. They don't get moving caches to start with, so forcing them to follow a set of complex logging structures will stop them playing as well. We want to make GCA as easy as we can for everyone. That means a compromise between simplicity and complexity.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 10:16 am

I will never run a game with trackables again. Too hard to work out what is where, how far it went, who has it now, who logged it incorrectly, etc. Simply not going to happen.

User avatar
rogerw3
8000 or more caches found
8000 or more caches found
Posts: 683
Joined: 26 July 09 11:11 am
Location: Lithgow

Re: Improving Moveable Caches

Post by rogerw3 » 02 February 12 10:23 am

Please keep the moveables as moveables, and yes I do know that sometimes you will get to GZ only to find that the cache has... well... moved, that is the whole point of it.

Yes it would be nice if people made it clear in the find log whether they have taken the cache or left it in place, but really how often is this ambiguous, in my experience once or twice in the last 2 months.

I can only repeat what I have said before "If it ain't broke, don't fix it!".

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 02 February 12 10:27 am

caughtatwork wrote: If I look at this from the perspective of a n00b. They don't get moving caches to start with, so forcing them to follow a set of complex logging structures will stop them playing as well. We want to make GCA as easy as we can for everyone. That means a compromise between simplicity and complexity.
I hardly think the concept of Grab vs find is complex. I suspect a 4 YO could understand this simple structure.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 10:34 am

Does grab add a smiley?
Do I need to find to get the smiley, then grab?
Does it matter if I grab then find vs. find then grab?
What do YOU do when you see a find and no grab? Look for it? Then discover the grab was logged after you left the house?
What is GSAK going to do with a grab?
What is any smart phone app going to do with a grab.
Please tell me.

There's 5 questions. It's not simple. Even I don't know the answers and I write the code.

Again, not purposely trying to be difficult, trying get people to understand this is very complex and "find / grab / move" is not a silver bullet.

User avatar
gmj3191
7500 or more caches found
7500 or more caches found
Posts: 1316
Joined: 22 April 03 12:37 am
Location: Sandringham, Vic Garmin Oregon 650

Re: Improving Moveable Caches

Post by gmj3191 » 02 February 12 10:47 am

I think there are are answers to those questions, but then we get to a situation where the cache is not there when you search because the grabber has not yet logged the grab.

I think it's fine the way it is and adding this complexity will give minimal benefits.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 02 February 12 2:29 pm

Does grab add a smiley? No
Do I need to find to get the smiley, then grab? of course
Does it matter if I grab then find vs. find then grab? No
What do YOU do when you see a find and no grab? Look for it? Then discover the grab was logged after you left the house? Find AKA discover, rush out and search
What is GSAK going to do with a grab? See previous post
What is any smart phone app going to do with a grab. see previous post
Please tell me. done

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 5:32 pm

So we're forcing 3 logs.
Find
Grab
Move

Whereas right now I do one log for Find and Move.
How is three times the work an improvement?

User avatar
gmj3191
7500 or more caches found
7500 or more caches found
Posts: 1316
Joined: 22 April 03 12:37 am
Location: Sandringham, Vic Garmin Oregon 650

Re: Improving Moveable Caches

Post by gmj3191 » 02 February 12 5:52 pm

caughtatwork wrote:So we're forcing 3 logs.
Find
Grab
Move

Whereas right now I do one log for Find and Move.
How is three times the work an improvement?
Don't we two logs now, a Find, then a Move when it's relocated?

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 02 February 12 6:20 pm

Don't have to. You can move the cache with a Find log by adding in the new co-ords.

Laighside Legends
10000 or more caches found
10000 or more caches found
Posts: 1304
Joined: 05 October 10 10:20 pm
Location: Australia

Re: Improving Moveable Caches

Post by Laighside Legends » 02 February 12 6:51 pm

I don't think changing the logging/adding a log is the answer - People will get it wrong and you still won't know where it is...

How about we say 'its there to find' if the last log was a 'moved' or 'found' with coords
and say 'see logs for location' if anything else

It wouldn't get 100% of the ones that are ready to be found but it would get a reasonable number...

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 02 February 12 7:06 pm

caughtatwork wrote:So we're forcing 3 logs.
Find
Grab
Move

Whereas right now I do one log for Find and Move.
How is three times the work an improvement?
the improvement ,as above

Post Reply