Re: Improving Moveable Caches
Posted: 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.
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.