When I first started caching, travel bugs didn’t even exist, but they were in the making. I remember thinking that they were a good idea at the time and ordered four of them right away when they came out. At that point in time, 
I didn’t know what I wanted to do with them, but decided that one of them would be my personal bug that I would take with me to every cache. I would virtually log it into each cache so I could keep track of mileage for myself when I was caching. It was also nice because it has every log that I’ve written for each and every cache that I’ve found. I’d copy and paste the log I’d write for the cache and then paste it into my retrieval log for the travel bug. I decided to call the travel bug, A Walk With Webfoot, not particularly because I walked to every cache, most I did drive to, but I wanted it to convey the message that geocaching was a walking activity, that you should get out and enjoy the outdoors.
If you clicked on the link above, you probably noticed that the travel bug page takes an incredibly long time to load. I started noticing this several months ago. I even wrote emails to friends asking them to check it out and they all agreed that it was loading slowly. It seemed like all other pages at GC.com loaded quickly, with the exception of that particular page, so it seemed like I couldn’t even blame the hamsters that were running the servers at GC.com.
I have a system worked around, so I never have to worry about how long the page takes to load when I’m logging caches. When I log a cache, I click on the “Log your find” link, then use another tab to then click on the Walk With Webfoot page. While I’m writing my cache log, the Walk With Webfoot page loads. It’s loaded by the time I’ve finished writing the cache log and clicked the submit button, so then I just toggle to the travel bug page and then retrieve the travel bug from the cache page and repeat the process for the caches. It hasn’t been a problem thus far, but I wanted to know from the Powers that Be at GC.com what was up and why it was taking so long for that particular page to load, so I sent a trouble ticket to Groundspeak.
A couple of weeks passed and I’d long since forgotten about the trouble ticket when I got a response from Groundspeak.
“Trackable pages were never intended to be used as personal log pages. Because it is being used in a manner for which it was not designed, it will take longer and longer to load, the more content it takes on. There may be others with more entries, but yours is one of the largest for total data size.
Eric
Groundspeak, Inc.”
Is this his polite way of saying I’m verbose?
But then, I started thinking to myself, wait a minute. This is a travel bug. It's designed to travel from cache to cache, having cachers find it and write on the page about it. Groundspeak has on one of their pages the following information about travel bugs. “A Travel Bug is a trackable item that moves from place to place, picking up stories along the way. Here you can add your own story, or live vicariously through each bug's adventures.” 
So why is a personal log page different than a regular travel bug? If a travel bug ended up in a cache and then was taken by the next cacher who then wrote a story about it and then dropped it in another cache and it happened again and again, wouldn’t that cause that particular bug’s page to load more slowly? Of course it would. So I guess the next question is, did Groundspeak not anticipate travel bugs having lots of entries, or were they just expecting travel bugs to disappear quickly?
Now, I know most people will read this and say, “but your page has a lot more entries.” Yes it does, but if it’s a travel bug, shouldn’t Groundspeak have anticipated a travel bug possibly having a lot of entries? I mean, isn’t that what they were supposed to do, travel from place to place, picking up stories? It’s a puzzlement, that’s for sure and it’s just been on my mind recently.
I’m planning on retiring A Walk With Webfoot when I get to 2000 cache finds. I have a geocoin all picked out to continue my caching trek. Until then, I’ll continue to use my logging method described above.
All pictures have been main pictures from A Walk With Webfoot at different points in time.
4 comments:
This is just bad programming on groundspeak's part. They are apparently retrieving the entire log set whenever you load any page of results there, causing the slow load times.
A properly programmed web application should load that very quickly since you are only actually displaying about 10 logs at a time.
Getting the count of all your logs should not take long either.
Hopefully they will resolve this for 'v2.0' of the site.
But they can't 'blame the user' for this one.
I can remember at one time when all the logs were displayed on one page. That was resolved when they pared it down to 10 logs per page and now I believe it's only five logs - well, five drops and five retrievals, so that could be considered 10.
I do agree with you that it shouldn't cause the delay if it's only retrieving the first 10 as opposed to the entire set. Let's hope that 'v2.0' fixes that particular bug.
I recommend you not retire the travel bug at 2000 finds. So few things last these days. If I had started something from the beginning, I would want it to last. Most folks are not looking at your TB page; it is just for you.
Very nice, they tell you you're doing it wrong and hope you'll go away. I have a personal bug too, A coin I got as an FTF prize. I don't know why I never thought to past the log comment into it. That's a good idea. I always just put "1 of 4 in urban Temecula" Consider your idea replicated.
Geocaching With Team Hick@Heart
Post a Comment