New idea: disable 'took it too.....'

[+#Tenzin]

I have read a lot about "visted logs" or "took it too .... ".

Now I didn 't see this idea exactly, so I posted it over here to hear people's opionions.

And hopefully Groundspeak even realizes it!

 

I have on my TB pages (in blue):

###

Plz. no "visited logs", then the journey of the TB is more clear.

Thank you.

 

Now somethimes I do get a "took it too .... " log.

 

My idea:

I would like to see a function where I can choose if I want to 'allow' or 'don't allow' "took it too...." logs.

 

It also could be made that if a Cacher picks it up, and then writes a 'took it too...." log the thing is not shown on the page.

Or maybe even better, disable the complete "visited" button for that specific Trackable.

 

I think this idea will help many Cachers alot.

 

EDIT:

I am aware there is another topic about these "took it too...." logs.

But this idea is more about that they don't get to exist in the first place.

If they don't exist we don't need to delete them, so this idea is different.

Edited January 2, 2014 by #Tenzin

[+niraD]

This has been proposed before:

[FEATURE]Ability to turn off 'visited' option for owned TBs/Coins

 

The "visited" log type was added because people requested it:

dipping trackables

An idea for a new Travel Bug action: Allow TBs to "visit" a cache

Trackable feature request- Visited cache Log Option: the ability to log that a trackable visited a cache wihtout staying

Dipping...: Automatic would be cool

"Yo-Yo" trackables in/out of caches: An easier way to log trackables in and right back out.

 

If you block/eliminate "visited" logs, then people will go back to dropping and then immediately retrieving the trackables.

 

And if "visited" logs are blocked for some trackables, but not for others, then Groundspeak will get a lot of complaints from users who don't understand why "visited" logs are "broken" for certain trackables.

 

I think a better idea is to let people who don't want to see "visited" logs filter them out.

[+Harry Dolphin]

If you block/eliminate "visited" logs, then people will go back to dropping and then immediately retrieving the trackables.

 

And if "visited" logs are blocked for some trackables, but not for others, then Groundspeak will get a lot of complaints from users who don't understand why "visited" logs are "broken" for certain trackables.

 

I think a better idea is to let people who don't want to see "visited" logs filter them out.

 

No. I very much doubt that the local cacher who visits 50 travel bugs to every cache will resort to drop and retrieve. If it ain't easy, it will not be done. Even if they're just visiting my trackable which states "Do not visit me to caches", they are not going to drop and retrieve from the 150 caches they visited. Far too much effort.

 

If my trackables do not wish to 'visit' caches, I should have the opportunity to prohibit that. Or else I will have to continue deleting all of those visits. Yes people asked for it, but GS did not consider all of the ramifications. Let people complain if hey cannot read.

As to 'filtering' out visits. Yes! I would like that as well. Who wants to read through all that meaningless blather on a cache page?!?

I thank OP for the suggestion to filter such logs. But we also do need the ability to prevent trackables which do not want to 'visit' from being 'visited' to caches.

[+niraD]

I very much doubt that the local cacher who visits 50 travel bugs to every cache will resort to drop and retrieve. If it ain't easy, it will not be done. Even if they're just visiting my trackable which states "Do not visit me to caches", they are not going to drop and retrieve from the 150 caches they visited. Far too much effort.

Yeah, because everyone posts all their logs manually, and there is no third-party software that facilitates automated logging of any kind.

[+JesandTodd]

 

If you block/eliminate "visited" logs, then people will go back to dropping and then immediately retrieving the trackables.

 

 

Take notice of the word I bolded. This is what happened before. And this is what will happen again. Imagine 2 emails for each drop now. Imagine.

 

WE asked GS for the visit function, and they gave it to us.

 

If the filter option doesn't pan out...then may I suggest people simply 'ignore' the visited logs? It's really not that hard. Be happy your bug is alive and moving. Nobody cares how a webpage looks anyway.

 

 

Eta: eating-chips-n-salsa-iPad-spelling

Edited January 3, 2014 by JesandTodd

[nostra-dumass]

Would you like the option to not accept 'TFTC' logs on your caches, too.

 

Perhaps a minimum log length of 200 characters, and a picture also?

[nostra-dumass]

Be happy your bug is alive and moving. Nobody cares how a webpage looks anyway.

 

 

There ya go.

Some people are just not happy if there is no reason for their undies to be in a bundle.

[+dprovan]

Perhaps a minimum log length of 200 characters, and a picture also?

You might be on to something. For the vacuous visit logs, a minimum log length of 1 character would do the trick: don't add an option to block visits altogether, but add an option that forces them to add text to the visit log. Conveniently, since I always have to go track down the visit log and edit it manually, that would make my life easier as a TB logger, too.

 

Yeah, I'm just dreaming. It would be hard to implement, and many people would just type (or teach their computers to automatically supply) ".". I don't like all the vacuous visit logs, either, but they don't bother me enough for me to want to eliminate this useful feature. Besides, more often than not, it's on other people's TBs that they get in my way, so I'd much rather be able to filter them out from all TBs rather than only suppressing them on the TBs that I own. But, to be honest, I'd rather they work on other features.

[team tisri]

 

If you block/eliminate "visited" logs, then people will go back to dropping and then immediately retrieving the trackables.

 

 

Take notice of the word I bolded. This is what happened before. And this is what will happen again. Imagine 2 emails for each drop now. Imagine.

 

WE asked GS for the visit function, and they gave it to us.

 

If the filter option doesn't pan out...then may I suggest people simply 'ignore' the visited logs? It's really not that hard. Be happy your bug is alive and moving. Nobody cares how a webpage looks anyway.

 

Eta: eating-chips-n-salsa-iPad-spelling

 

Honestly I can't see people bothering to log bugs into caches and then log them all out again. Each one needs to be done individually, each one needs the tracking code entered. It's vastly more effort than just choosing "visited" on each bug when you write the log.

 

Perhaps the best option would be to allow the "visited" log but require the tracking number each time. That would confirm you still have the bug and also make it represent enough effort that people wouldn't just dip every bug into every cache they visit but if, say, a bug wanted to visit all 50 states someone might make the effort to "visit" a cache in North Carolina if they were driving from Virginia to South Carolina.

[cezanne]

Perhaps the best option would be to allow the "visited" log but require the tracking number each time. That would confirm you still have the bug and also make it represent enough effort that people wouldn't just dip every bug into every cache they visit but if, say, a bug wanted to visit all 50 states someone might make the effort to "visit" a cache in North Carolina if they were driving from Virginia to South Carolina.

 

On the other hand having to type in the code again will also discourage many of those who use the visit logs only in appropriate special cases. I hate having to decipher the codes and if I had to do it more than once, this would be a further reason for considering not to take along trackables any longer. Sometimes I need 3 and more attempts until I get the code right - the symbols are sometimes so hard to read for me also when I get off my glasses. Moreover, I'm often writing logs when I'm not at home and do not have the trackables near me while logging.

 

Personally, I think filtering out certain logs would be the much nicer option than making logging trackables more inconvenient.

 

Cezanne

[+thebruce0]

Honestly, I think the only feasible option is to allow filtering of what logs you see on the trackable page. As a viewer, not the owner. Like on a cache listing showing the count of each log type, on a TB page just allow the option to not show visited logs. Your setting could be saved so you don't have to keep disabling it if you really don't want to see visited logs on trackable pages.

 

On that note, I still wish cache listing would you let you filter out the logs you don't want to see

[team tisri]

Perhaps the best option would be to allow the "visited" log but require the tracking number each time. That would confirm you still have the bug and also make it represent enough effort that people wouldn't just dip every bug into every cache they visit but if, say, a bug wanted to visit all 50 states someone might make the effort to "visit" a cache in North Carolina if they were driving from Virginia to South Carolina.

 

On the other hand having to type in the code again will also discourage many of those who use the visit logs only in appropriate special cases. I hate having to decipher the codes and if I had to do it more than once, this would be a further reason for considering not to take along trackables any longer. Sometimes I need 3 and more attempts until I get the code right - the symbols are sometimes so hard to read for me also when I get off my glasses. Moreover, I'm often writing logs when I'm not at home and do not have the trackables near me while logging.

 

Personally, I think filtering out certain logs would be the much nicer option than making logging trackables more inconvenient.

 

Cezanne

 

It would still be easier to log a "took it to" than a "dropped off" and a "retrieve". Entering the code would mean you had to do something specific, with the specific intention people wouldn't do it so often.

 

Ultimately I think the decision is going to have to be between a free-for-all where the default seems to be that at least some users dip every single trackable they have into every single cache they find, and a controlled environment where there is some restriction/inconvenience involved in a "visited" log.

 

Filtering is fine in theory but messes up the maps as well - if you want to see where the bug has been it's pointless to hide the "visited" logs when the map shows a meandering route that doesn't correspond to the logs on display.

[+thebruce0]

Filtering is fine in theory but messes up the maps as well - if you want to see where the bug has been it's pointless to hide the "visited" logs when the map shows a meandering route that doesn't correspond to the logs on display.

I don't think people are worried about visited points on the map. It's just the pages and pages of blank visited logs in the list. Unimportant, and generally uninteresting, to those who don't wish to see them. Location on the map is FAR more relevant for visited logs.

Just allow hiding visited logs in the log history list... that would be sufficient.

[cezanne]

It would still be easier to log a "took it to" than a "dropped off" and a "retrieve".

 

No, currently neither for a "drop off log" nor for a "visit log" you have to enter the code - only for the retrieve.

I would not be willing to undergo the same pain twice and I never note down trackable codes.

 

Entering the code would mean you had to do something specific, with the specific intention people wouldn't do it so often.

 

But the "something specific" you ask for also bothers those who are not using such logs often.

For example, if I happen to find a GC that wants to visit nice puzzle caches and the only nice puzzle caches I visit are too small or not safe enough I typically will have the GC visit one of those unsuitable caches and then drop it off it a safe cache that is not a puzzle cache.

 

The more constraints are involved, the less likely I will be willing to undergo the pain of taking along trackables.

 

Filtering is fine in theory but messes up the maps as well - if you want to see where the bug has been it's pointless to hide the "visited" logs when the map shows a meandering route that doesn't correspond to the logs on display.

 

The maps for trackables are so bad anyway that I never use them. It would suffice for me to filter away visit logs and to be able to only list trackables that have really been in a cache when I look at past trackables (they will not implement that, but it would not be hard to do).

 

Moreover, showing the visit logs on maps can make sense as not all visit logs are just automatic logs. In former times some cachers happened to bring trackables to caches, take photos there and take them to the next cache (by dropping the TB off and retrieving it immediately afterwards). Back then it was not to uncommon to meet a sequence of stories and photos about what the trackable experienced. Nowadays the equivalent of this would have to be achieved by visit logs. Of course in a TB race such actions are not intended as they will have an influence on the race. For trackables outside of races, real visit logs accompanied with stories (and in several cases also without stories) can make a lot of sense - the issue is just that those logs have become rare, but that's a different issue.

 

 

Cezanne

Edited January 8, 2014 by cezanne

[team tisri]

It would still be easier to log a "took it to" than a "dropped off" and a "retrieve".

 

No, currently neither for a "drop off log" nor for a "visit log" you have to enter the code - only for the retrieve.

I would not be willing to undergo the same pain twice and I never note down trackable codes.

 

That's my point, adding a requirement to post the code for a "visit" still leaves it representing less work than a "drop off" and a "retrieve" against the same cache. Especially if GS can come up with a halfway decent user interface for it.

 

Entering the code would mean you had to do something specific, with the specific intention people wouldn't do it so often.

 

But the "something specific" you ask for also bothers those who are not using such logs often.

For example, if I happen to find a GC that wants to visit nice puzzle caches and the only nice puzzle caches I visit are too small or not safe enough I typically will have the GC visit one of those unsuitable caches and then drop it off it a safe cache that is not a puzzle cache.

 

The more constraints are involved, the less likely I will be willing to undergo the pain of taking along trackables.

 

The whole idea is to put a small task in the way of a "visit" log so that people who don't use them very often don't have a lot of trouble but it discourages people from dipping every TB in their inventory into every cache they find.

 

Filtering is fine in theory but messes up the maps as well - if you want to see where the bug has been it's pointless to hide the "visited" logs when the map shows a meandering route that doesn't correspond to the logs on display.

 

The maps for trackables are so bad anyway that I never use them. It would suffice for me to filter away visit logs and to be able to only list trackables that have really been in a cache when I look at past trackables (they will not implement that, but it would not be hard to do).

 

Moreover, showing the visit logs on maps can make sense as not all visit logs are just automatic logs. In former times some cachers happened to bring trackables to caches, take photos there and take them to the next cache (by dropping the TB off and retrieving it immediately afterwards). Back then it was not to uncommon to meet a sequence of stories and photos about what the trackable experienced. Nowadays the equivalent of this would have to be achieved by visit logs. Of course in a TB race such actions are not intended as they will have an influence on the race. For trackables outside of races, real visit logs accompanied with stories (and in several cases also without stories) can make a lot of sense - the issue is just that those logs have become rare, but that's a different issue.

 

Cezanne

 

I must admit if endless points on a map aren't an issue I struggle to see why pages of "visited" logs are. Perhaps the solution is to put more logs on a page?

 

As you say it's rare to find anything meaningful in a TB log these days but as you also say, that's another issue.

[cezanne]

That's my point, adding a requirement to post the code for a "visit" still leaves it representing less work than a "drop off" and a "retrieve" against the same cache. Especially if GS can come up with a halfway decent user interface for it.

 

Only if the work for a "drop off" is also increased by requiring the trackable code for each action.

The annoying part is deciphering the code and having to enter it, not the number of clicks.

 

The whole idea is to put a small task in the way of a "visit" log so that people who don't use them very often don't have a lot of trouble but it discourages people from dipping every TB in their inventory into every cache they find.

 

As I said, it would me make reconsider my decision to take along trackables.

 

I do not always manage to find a suitable cache within 2 weeks. If I fail, I like to use the visit log to minimize the probability to get a mail by the TB owner that reminds me to drop off the trackable.

 

 

I must admit if endless points on a map aren't an issue I struggle to see why pages of "visited" logs are. Perhaps the solution is to put more logs on a page?

 

I like to see what others have written about a trackable. For example, if it is in a bad condition, I'm going to report that, but only if not 10 people before have reported on the same thing. Most of the visit logs do not contain information. So it has some value only to look at retrieve logs.

 

I have never made use of the maps, not even back in those times where most TB logs had some meaningful contents.

 

Cezanne

[+thebruce0]

I must admit if endless points on a map aren't an issue I struggle to see why pages of "visited" logs are. Perhaps the solution is to put more logs on a page?

"Endless" points on a map showing a route display more meaningful information than a repetitive series of text blocks in a list that just say "took it to".

 

If the visited log is empty, why show every.single.log? Why not even perhaps just compress all visited logs into a collapsed block you can expand if you want.

 

So you've got this example log history, newest to oldest:

* UserB retrieved from CacheZ --- "Here is my interesting log! I'm going to the destination shortly and will drop it off there."

* UserA dropped it in CacheZ

* Visited [Note: these logs are empty; click to expand and view visited locations]

* UserA took it to CacheY --- "Here is my interesting log with pics!"

* UserA retrieved it from CacheX

* ...etc

 

At the very least, a single option on the listing: "Hide empty Visited logs [X]"

Change nothing on the map. Just the log list. (and yes I added 'empty' there because it is possible to add content to visited logs, as per the example above; I've done it when I've intentionally visited a TB to a cache that was relevant to its mission)

 

Personally, I don't care if someone really really wants to 'visit' a trackable of mine in a whole bunch of caches, physically or not. It's not as important to me. But when viewing a trackable page (or even viewing my own) I may not want to see stretches of what are effectively uninformative/uninteresting waypoints in text form taking up large swaths of a list of logs I'd otherwise like to see.

On a map? Yes, I would like to see them - because the intent of the map is to show the series of cache waypoints in a traveling sequential route, not to display log text for reading. The log history listing is the latter. Empty logs are irrelevant to that text history. But, having the option to view those (since they do mention cache names, distance, and some other info) should still remain.

Edited January 8, 2014 by thebruce0

[+dprovan]

I don't think people are worried about visited points on the map. It's just the pages and pages of blank visited logs in the list.

Well, actually I don't care for a big blob of hundreds of visits in one little tiny area on the map. And since I often look at the map simply to get all the logs on a single page, there's not all that much difference between being on the map and being in the list as far as I'm concerned.

 

And this makes me think of another thing: one of the things that I don't care for about the legions of pointless visits is that each and every one adds that trackable to the list of trackables that have been in the those caches. I'm guessing I'm one of the few people that considers that an additional problem.

[+niraD]

Once upon a time, posting a Retrieve log for a TB or geocoin required entering the tracking code twice: once to search for the trackable itself, and once to post the Retrieve log.

 

And behold, the great Oily Simian arrived to enter the tracking code automatically, and many of those who log trackables no longer needed to enter the tracking code twice.

 

And behold, the great Talking Earth created a new feature that entered the tracking code automatically for everyone, and the great Oily Simian retired from his tracking code duties.

 

But the great Oily Simian is not dead. He merely sleeps, until those who log trackables need his services once again.

[cezanne]

Once upon a time, posting a Retrieve log for a TB or geocoin required entering the tracking code twice: once to search for the trackable itself, and once to post the Retrieve log.

 

But back then there were more TBs and less tiny GCs or GCs in strange colours where the code is so hard to read.

 

Cezanne

[+thebruce0]

Well, actually I don't care for a big blob of hundreds of visits in one little tiny area on the map. And since I often look at the map simply to get all the logs on a single page, there's not all that much difference between being on the map and being in the list as far as I'm concerned.

But how then would you distinguish between 'relevant' visitation and irrelevant? The issue you raise about the map is valid, imo, but the solution isn't removal visitation logs. This is more an issue of proximity; that perhaps a form of waypoint clustering (a featured used various places that Google maps supports) would alleviate. Take the average centerpoint for clusters of waypoints within a maximum radius of each other. While that can get complex to calculate, I think that addresses the extraneous waypoints on the map more appropriately.

 

Point being,

Map: Main purpose? View the linear geographic path traveled by the TB around the globe. This path can't be broken or the resulting information is no longer accurate. Problem: Waypoints (of any kind - not just visitation) that cluster excessively and bulk up in small regions. Solution? Based on similarity, treat clusters of waypoints as a single average waypoint for map viewing, so the trip itself can remain unbroken. (Better: make such clustering a view option)

Log history: Main purpose? Read the content of logs posted by users as they perform actions with the TB. Logs may be detailed or empty, and automatic logging of visitations is by default empty, the information displayed really being only names and distance traveled. Problem: Empty logs (of any kind) posted sequentially create long sections of uninteresting and less informative reading that can be tedious to 'skip'. Solution? Based on unique/custom text or log content, treat series of empty logs as a single grouped block that can be expanded if desired. For series of 100's of empty logs, this would work wonders. (Better: make such filtering a view option)

 

And this makes me think of another thing: one of the things that I don't care for about the legions of pointless visits is that each and every one adds that trackable to the list of trackables that have been in the those caches. I'm guessing I'm one of the few people that considers that an additional problem.

Oh never considered that. I think I've only looked at that portion of a cache listing once or twice since starting here But I agree that technically, there's no reason to think that a 'visit' means the TB was actually there. OTOH, there's no reason to think otherwise either.

But I'd support a change that would separate TBs that only "visited" from TBs that had at any point physically been 'possessed' by the cache (ie also an event) - that is, left by one cacher and retrieved by another. That, to me, would be the most interesting property to distinguish from the list of TBs there.

Edited January 8, 2014 by thebruce0

[cezanne]

And this makes me think of another thing: one of the things that I don't care for about the legions of pointless visits is that each and every one adds that trackable to the list of trackables that have been in the those caches. I'm guessing I'm one of the few people that considers that an additional problem.

 

These lists have become pointless anyway in my area as so many cachers log visit logs for all their owned personal trackables for all caches they visit.

 

In order to attack this issue, one simply would need to offer an option to display only those trackables that have been dropped off into a cache. That could be implemented easily.

 

Cezanne

[+#Tenzin]

I think the idea to fill in a Trackable number when you do a "too it to.... " log is also a good idea.

Then at least you have to do effort for it, and then you wouldn't have 200+ automatic "visit" logs.

I like that idea as well.

[cezanne]

I think the idea to fill in a Trackable number when you do a "too it to.... " log is also a good idea.

Then at least you have to do effort for it, and then you wouldn't have 200+ automatic "visit" logs.

I like that idea as well.

 

I'm convinced with such a change you would punish cachers like me who use the visit log in only very few cases, but are doing all the logging manually.

For those who apply mass logging, soon automatic helper systems will show up and nothing will change for them. It's pretty much similar to mass discovery

logs after events.

 

By the way: I wonder whether there also exist systems where the overall mileage of trackables moved along by a single cacher is recorded.

I do know that the number of TBs and GCs discovered or moved along is part of several scoring systems, but I'm not yet aware of a score where what

I mentioned above plays a role. If such a thing exists, then definitely it will encourage numerous cachers to use as many visit logs as possible.

 

The mass, numbers and award trend has ruined geocaching.

 

Cezanne

Edited January 9, 2014 by cezanne

[+thebruce0]

By the way: I wonder whether there also exist systems where the overall mileage of trackables moved along by a single cacher is recorded.

I do know that the number of TBs and GCs discovered or moved along is part of several scoring systems, but I'm not yet aware of a score where what

I mentioned above plays a role. If such a thing exists, then definitely it will encourage numerous cachers to use as many visit logs as possible.

That would be interesting. Not hard to do, if you can download a catalog of your profile's TB logs. A simple algorithm can determine the distance between each 'retrieved/grabbed' across waypoints to the 'dropped/grabbed(from)' end.

However, it would also be VERY easy 'cheat', as all one would need to do would be visit it in a distant cache to skew the results.

 

However, I could foresee a challenge getting published with the requirement that all TB waypoints used towards your qualification must be caches for which you also posted a find. But then, if you remove certain waypoints from the log history, the pre-calculated distance count is messed up; you'd need another system to provide the total of distances between select TB waypoints. I think most people only have a grab and drop for most TBs they've possessed anyway.

 

So, it might be a high D challenge But there are challenge caches requiring mathematical calculations - that's not disallowed. A GSAK macro could do the calculations if you provide it the GC codes of valid trip waypoints. Heck, the Geocaching Map Extension add-on script itself has a feature to measure a route between waypoints on the map.

Alternately, you could do it manually relatively simply in GSAK, TB by TB, by setting the start cache as centerpoint, and noting the distance to the next cache in its trip, set that as centerpoint, rinse and repeat. hmm... This could be an interesting challenge. (so of course, I bet it's already been made!)

Edited January 9, 2014 by thebruce0

[+dprovan]

These lists have become pointless anyway in my area as so many cachers log visit logs for all their owned personal trackables for all caches they visit.

Part of my point is that vacuous visits can have a negative impact even when the owner likes them, or even when the owner is the one doing them.

 

In order to attack this issue, one simply would need to offer an option to display only those trackables that have been dropped off into a cache. That could be implemented easily.

Yeah, very similar to the feature we're discussing for the TB logs where visits can be filtered out if desired by the viewer.

 

Although I still don't consider any of this serious enough that I'd want to take development resources away from other projects. At this point, I'm more interested in raising awareness about the negative side effects of their visits, no matter what's motivating them.

[dian11]

I agree you

[+Twentse Mug]

Many good ideas here. I have 240 trackables running around and deleting all these took it to logs (despite text on my tb page not to use the visit option) costs so much wasted time. The visit option itself is nice to have because you can use for trackers like cars, rucksacks etc that people carry around as sort of personal trademark. I would love to have the option on/off for using the visit option on my trackables.

 

Besides that, the TB system as a whole could use an update too.

[team tisri]

I must admit if endless points on a map aren't an issue I struggle to see why pages of "visited" logs are. Perhaps the solution is to put more logs on a page?

"Endless" points on a map showing a route display more meaningful information than a repetitive series of text blocks in a list that just say "took it to".

 

I have to disagree there, when so much of the time all it shows is the meanderings of a cacher who picked up the bug some time ago, who may or may not have actually "taken it to" the caches in question.

 

It's a bit silly to think of, for example, the travel bug that's currently sitting on my desk, being "taken to" a whole load of caches when it spent the entire time on my desk. All the exercise ends up doing is letting cacher after cacher plot a trace on the map of where they happened to go while they had the bug.

 

If the visited log is empty, why show every.single.log? Why not even perhaps just compress all visited logs into a collapsed block you can expand if you want.

 

So you've got this example log history, newest to oldest:

* UserB retrieved from CacheZ --- "Here is my interesting log! I'm going to the destination shortly and will drop it off there."

* UserA dropped it in CacheZ

* Visited [Note: these logs are empty; click to expand and view visited locations]

* UserA took it to CacheY --- "Here is my interesting log with pics!"

* UserA retrieved it from CacheX

* ...etc

 

At the very least, a single option on the listing: "Hide empty Visited logs [X]"

Change nothing on the map. Just the log list. (and yes I added 'empty' there because it is possible to add content to visited logs, as per the example above; I've done it when I've intentionally visited a TB to a cache that was relevant to its mission)

 

Personally, I don't care if someone really really wants to 'visit' a trackable of mine in a whole bunch of caches, physically or not. It's not as important to me. But when viewing a trackable page (or even viewing my own) I may not want to see stretches of what are effectively uninformative/uninteresting waypoints in text form taking up large swaths of a list of logs I'd otherwise like to see.

On a map? Yes, I would like to see them - because the intent of the map is to show the series of cache waypoints in a traveling sequential route, not to display log text for reading. The log history listing is the latter. Empty logs are irrelevant to that text history. But, having the option to view those (since they do mention cache names, distance, and some other info) should still remain.

 

If Groundspeak are going to do any work on the interface (and that in itself is quite a big if) I'd rather they made it easier to write some text in the log when dropping off a bug or, better still, implemented the option suggested some two years ago to let people tag trackables as potentially missing when they aren't in a cache.

[team tisri]

That's my point, adding a requirement to post the code for a "visit" still leaves it representing less work than a "drop off" and a "retrieve" against the same cache. Especially if GS can come up with a halfway decent user interface for it.

 

Only if the work for a "drop off" is also increased by requiring the trackable code for each action.

The annoying part is deciphering the code and having to enter it, not the number of clicks.

 

The whole idea is to put a small task in the way of a "visit" log so that people who don't use them very often don't have a lot of trouble but it discourages people from dipping every TB in their inventory into every cache they find.

 

As I said, it would me make reconsider my decision to take along trackables.

 

I do not always manage to find a suitable cache within 2 weeks. If I fail, I like to use the visit log to minimize the probability to get a mail by the TB owner that reminds me to drop off the trackable.

 

I've never had TB owners chasing me after two weeks. That might be an ideal situation but I've yet to find a TB owner who seriously thinks it represents anything of a commitment at all. It's far from rare for me to keep a TB for more than two weeks, partly because I don't cache as much as I once did and partly because where I live most of the caches are film pots and keysafes.

 

 

I must admit if endless points on a map aren't an issue I struggle to see why pages of "visited" logs are. Perhaps the solution is to put more logs on a page?

 

I like to see what others have written about a trackable. For example, if it is in a bad condition, I'm going to report that, but only if not 10 people before have reported on the same thing. Most of the visit logs do not contain information. So it has some value only to look at retrieve logs.

 

I have never made use of the maps, not even back in those times where most TB logs had some meaningful contents.

 

Cezanne

 

The only log types that make it easy to write any text are the "picked up" and "grabbed from" types. If you want to write text on a "visited" or "dropped off" log you have to log the cache, then visit the log against the TB, then edit it. It's a clunky interface if ever there were one. I'd rather see resources spent on streamlining that process so it's easier to write something when you dip or drop off a bug.

 

Of course, as you say in another post, once automation catches up it all becomes academic anyway.

[+JesandTodd]

...I have 240 trackables running around and deleting all these took it to logs (despite text on my tb page not to use the visit option) costs so much wasted time..,,

 

Was it worth it?

I mean, really? Taking time away from your life to delete pages and pages and pages of logs on a meaningless webpage that few people see?

 

It's a webpage. You seriously wasted time cleaning up a webpage?

[+thebruce0]

"Endless" points on a map showing a route display more meaningful information than a repetitive series of text blocks in a list that just say "took it to".

I have to disagree there, when so much of the time all it shows is the meanderings of a cacher who picked up the bug some time ago, who may or may not have actually "taken it to" the caches in question.

That's not an issue with the map view of waypoints though, that's an issue of log types - which at this point 'visit' means one of two things: Was physically at that location, or the holder was at the location (well, and the bad form possibility of neither since someone can just post a visit log to any cache).

 

The point of the map is to show the route it's taken, under the presumption that all waypoints in the TB list are physical waypoints in its journey. Removing select waypoints makes that intention meaningless, and causes a lot more work on the calculation end. A better solution I would say is to deal with TB log types, and designate a certain log type as irrelevant to its physical journey in some way. Right now, every waypoint is presumed to be.

 

If Groundspeak are going to do any work on the interface (and that in itself is quite a big if)

Very hopeful indeed, and more unlikely than likely =/ (at least in the short term)

 

I'd rather they made it easier to write some text in the log when dropping off a bug or, better still, implemented the option suggested some two years ago to let people tag trackables as potentially missing when they aren't in a cache.

Providing text with the drop off/visit log would be a huge plus. One wonders why that wasn't included in the first place.

[+thebruce0]

I mean, really? Taking time away from your life to delete pages and pages and pages of logs on a meaningless webpage that few people see?

Well, you're placing subjective value on an element of caching that has a wide range of appreciation. Some people really, really put value in their trackables and its page content. For those people, pages and pages of empty logs that they feel are irrelevant and space wasting is certainly something they'd want to easily 'clean up'. I can completely understand that position, though I personally don't hold to it...

[+JesandTodd]

I keep in touch with most of the bugs I've handled.

I hate going through pages and pages and pages of empty 'visited' logs too.

 

To spend tons of time deleting those pages, and then to complain about doing it....is the part I don't get.

 

Let it go! So page 20-24 on your bugs page are visited logs? And? It's ones choice to be overly anal about small stuff...but don't complain about being so.

 

I like the 'filtering' idea. But when I visit bugs (which I rarely do) I usually load a photo too.

Luckily, I can see the bugs goals when I'm at GZ. Even though I almost never visit bugs , if i saw a bug page dictate tonot have visits, I wouldn't pick it up.

[+Twentse Mug]

TheBruce0 has perfectly stated my thougts. I have many TB's running because I love to watch the travels they make. I find it exciting as it is like a sort of lottery where a TB will be going next move. And I want to have 'clean sheets', that is real travels that these TB's make. I use geotribes to see where they are and I wish that Groundspeak had built in Geotribes or a similar thing.

[+#Tenzin]

TheBruce0 has perfectly stated my thougts. I have many TB's running because I love to watch the travels they make. I find it exciting as it is like a sort of lottery where a TB will be going next move. And I want to have 'clean sheets', that is real travels that these TB's make. I use geotribes to see where they are and I wish that Groundspeak had built in Geotribes or a similar thing.

 

I use GeoTribes as well. Great website, and you get an easy overview of where you Trackables have been and how many "hops" they made.

 

Looking at all the comments on my topic I have to agree that the whole TB thing could use a update. Also for the things from the "ghost-Trackables" in caches. Hopefully one day they upgrade the TB's.

[+Walts Hunting]

Not really a NEW idea. Been proposed many times. This will be a several page discussion with no results. Just have to learn to,live with it.

[+thebruce0]

Not really a NEW idea. Been proposed many times.

Welcome to the forums.

 

This will be a several page discussion

Welcome to the forums. Well, actually this one was is going pretty slow compared to some others, except for the occasional bump.

 

with no results.

Welcome to the forums. Well, no website update related to it yet, and no direct response regarding any work being done right now, or whether it's in the queue for the future. Which it might be.

 

Just have to learn to,live with it.

Welcome to the forums.

 

No harm discussing. But if there are other threads discussing a topic (almost guaranteed), better to provide links to them.

 

ETA: Not being facetious, just chuckling with you at the truth of the matter.

Edited January 20, 2014 by thebruce0

[+Harry Dolphin]

I keep in touch with most of the bugs I've handled.

I hate going through pages and pages and pages of empty 'visited' logs too.

 

To spend tons of time deleting those pages, and then to complain about doing it....is the part I don't get.

 

Let it go! So page 20-24 on your bugs page are visited logs? And? It's ones choice to be overly anal about small stuff...but don't complain about being so.

 

I like the 'filtering' idea. But when I visit bugs (which I rarely do) I usually load a photo too.

Luckily, I can see the bugs goals when I'm at GZ. Even though I almost never visit bugs , if i saw a bug page dictate tonot have visits, I wouldn't pick it up.

 

I'm not sure why you think being insulting by calling someone 'anal' is being helpful.

"Don't complain"? Why not? Yes, geocachers had asked for a simpler way. Obviously, to some of us, it is a complete failure.

My trackables do not want to 'visit' caches. Yet, geocachers do it anyway. 240 'visits' over four months? No thanks. Yes. I will continue to delete the visits, and complain about it!

The fora are for offering help, or opposing ideas, not for insulting other geocachers.

I thank the OP for his suggestion!

[nostra-dumass]

I envy the cachers with no greater issue of concern than visited logs on their trackables.

 

A wart on a flea's toenail.

 

Feel free to run around like your hair is on fire.

[+JesandTodd]

I envy the cachers with no greater issue of concern than visited logs on their trackables.

 

A wart on a flea's toenail.

 

Feel free to run around like your hair is on fire.

 

Lol. I pity them...