Jump to content

Release Notes 6/2/10


Recommended Posts

The hides count has never updated properly, and displaying finds but not hides on that page feels wrong. We could not prioritize fixing the hide count so we removed both until we can. If it's useful to people we'll address it in another release.

I agree that having a broken feature on the site is a bad idea, but i think that just removing the placed count would have been the lesser of two evils here.

 

Most people here dislike the fact that the (correct) found count disappeared. I haven't read many (any?) complaints about the placed data being removed.

Link to post

...IF, I say IF, it's useful to people?...

 

That's my perception anyway.

That's right, it is your perception but not everyone agrees with it. The whole 'Friends' thing is useless and a joke to me. It could go away completely and I'd not miss it let alone even notice that it was gone.

Link to post

...IF, I say IF, it's useful to people?...

 

That's my perception anyway.

That's right, it is your perception but not everyone agrees with it. The whole 'Friends' thing is useless and a joke to me. It could go away completely and I'd not miss it let alone even notice that it was gone.

 

must.....not....make....snarky....comment....must....not....make....snarky.....comment.

 

There, I think I have it under control.

Link to post

IF, I say IF, it's useful to people?

 

Shirley, you jest.

 

Somehow, I'm not sure how, you apparently missed the massive outpouring of users clamoring for the find count to be restored. You know, it's not always WHAT is done, but HOW things are done that reveals management's priorities in regards to customer service. Instead of getting your feelings hurt by user's reactions to your well-intentioned but perhaps misguided changes, a simple, sincere sounding apology and assurance that the users wishes are being listened to would go a long way to mollifying those who are dissatisfied. How about? "Oops, we goofed. Sorry we didn't realise that was so important. We'll get it back within the week."

 

There are 1,094,276 active caches and an estimated 4-5 million geocachers worldwide

 

I don't recall seeing a significant percent of 5 million cachers on the forums over this topic. At most I'd say a couple dozen were being very vocal about the feature removal. Even if it was 1,000 people screaming blue murder that would not even be 1% of cachers.

 

Now to be fair, I very much want to see this restored but give them a break. The forums are populated by a very small percentage of geocachers, and at times we're the noisy bunch.

 

It's broke, there is a perceived need and it'll be fixed in the next release - perhaps. Of course Groundspeak is going to be non-committal here, or if the feature's not ready in the *very next release* then we get to jump up and down and call the programmers liars.

Link to post

and displaying finds but not hides on that page feels wrong.

It feels more wrong not having the find count at all. Without it, the friends page can just be replaced with a bookmark list to their profiles in my browser.

 

If it's useful to people we'll address it in another release.

It is useful to people. No if about it.

 

I'd personally rather have a find count only or the old find/hide with the broken hide than nothing at all.

Link to post

I don't recall seeing a significant percent of 5 million cachers on the forums over this topic. At most I'd say a couple dozen were being very vocal about the feature removal. Even if it was 1,000 people screaming blue murder that would not even be 1% of cachers.

Doesn't matter if it's 1, 1,000, or 1,000,000. They removed something that wasn't broken.

 

Now to be fair, I very much want to see this restored but give them a break. The forums are populated by a very small percentage of geocachers, and at times we're the noisy bunch.

 

It's broke, there is a perceived need and it'll be fixed in the next release - perhaps. Of course Groundspeak is going to be non-committal here, or if the feature's not ready in the *very next release* then we get to jump up and down and call the programmers liars.

It's very easy to put back the way it was and just hide the hide count. As for fixing the hide count, there's two other spots on the site where it's calculated perfectly.

 

Now demanding a date when it's fixed is a little much, but a "Yeah, we'll put it back as soon as we can" would be nice.

 

As a humorous aside:

 

Doctor 1: "The patients left arm has been crushed, what should we do?"

 

Doctor 2: "Amputate both arms, having one arm just feels wrong"

Link to post

I don't recall seeing a significant percent of 5 million cachers on the forums over this topic. At most I'd say a couple dozen were being very vocal about the feature removal. Even if it was 1,000 people screaming blue murder that would not even be 1% of cachers.

Doesn't matter if it's 1, 1,000, or 1,000,000. They removed something that wasn't broken.

 

Now to be fair, I very much want to see this restored but give them a break. The forums are populated by a very small percentage of geocachers, and at times we're the noisy bunch.

 

It's broke, there is a perceived need and it'll be fixed in the next release - perhaps. Of course Groundspeak is going to be non-committal here, or if the feature's not ready in the *very next release* then we get to jump up and down and call the programmers liars.

It's very easy to put back the way it was and just hide the hide count. As for fixing the hide count, there's two other spots on the site where it's calculated perfectly.

 

Now demanding a date when it's fixed is a little much, but a "Yeah, we'll put it back as soon as we can" would be nice.

 

Oh I agree it should be put back, I'm just tossing some water on the notion that this is upsetting the majority of their customer base and should be at the top of their priority list.

 

The one thing the release notes should be demonstrating here is that Groundspeak has the ability to work on more than one thing, and that tasks are being prioritized. I've seen there are some major logging issues with trackables after the update -- I'd want that fixed before a banner that shows my friend's counts is fixed.

 

It DID get acknowledged a few posts back and all the (noisy forum posting) community did was jump on the guy who posted with more complaints about timing and wall-of-silence. We want Raine and Moun10Bike and co to come into the discussions, perhaps not flaming them every time they show up would be a good start.

 

 

As a humorous aside:

 

Doctor 1: "The patients left arm has been crushed, what should we do?"

 

Doctor 2: "Amputate both arms, having one arm just feels wrong"

 

Doctor 3: Um, that patient died three hours ago, could you help me out with this guy with the gunshot wound?

Link to post

Oh I agree it should be put back, I'm just tossing some water on the notion that this is upsetting the majority of their customer base and should be at the top of their priority list.

I agree that it shouldn't be high up on their priority list. But when when fixing bugs, sometimes lower priority items get fixed if they're easy or quick to do:

 

"How long to restore the code that was deleted?" "Two minutes" "Do it, then get back to that priority bug"

 

The one thing the release notes should be demonstrating here is that Groundspeak has the ability to work on more than one thing, and that tasks are being prioritized. I've seen there are some major logging issues with trackables after the update -- I'd want that fixed before a banner that shows my friend's counts is fixed.

Again, there's a difference between fixing the hide count and just undeleting the old code. Fixing the hide count should take a back seat to the other major problems.

 

It DID get acknowledged a few posts back and all the (noisy forum posting) community did was jump on the guy who posted with more complaints about timing and wall-of-silence. We want Raine and Moun10Bike and co to come into the discussions, perhaps not flaming them every time they show up would be a good start.

I must have not seen it amidst all the complaining. Some people are just a little too harsh with the complaints. I appreciate everything that Raine and Moun10Bike (and others) do. But I tend not to let excuses slide.

 

Doctor 3: Um, that patient died three hours ago, could you help me out with this guy with the gunshot wound?

Nope. The gunshot victim arrived after they did the amputation. They unnecessarily removed the find count before any of these new bugs appeared.

 

But, yes, now the gunshot victim should get priority over reattaching the right arm back on the poor amputee.

Link to post

Oh I agree it should be put back, I'm just tossing some water on the notion that this is upsetting the majority of their customer base and should be at the top of their priority list.

I agree that it shouldn't be high up on their priority list. But when when fixing bugs, sometimes lower priority items get fixed if they're easy or quick to do:

 

"How long to restore the code that was deleted?" "Two minutes" "Do it, then get back to that priority bug"

 

The one thing the release notes should be demonstrating here is that Groundspeak has the ability to work on more than one thing, and that tasks are being prioritized. I've seen there are some major logging issues with trackables after the update -- I'd want that fixed before a banner that shows my friend's counts is fixed.

Again, there's a difference between fixing the hide count and just undeleting the old code. Fixing the hide count should take a back seat to the other major problems.

 

It DID get acknowledged a few posts back and all the (noisy forum posting) community did was jump on the guy who posted with more complaints about timing and wall-of-silence. We want Raine and Moun10Bike and co to come into the discussions, perhaps not flaming them every time they show up would be a good start.

I must have not seen it amidst all the complaining. Some people are just a little too harsh with the complaints. I appreciate everything that Raine and Moun10Bike (and others) do. But I tend not to let excuses slide.

 

...

 

The hides count has never updated properly, and displaying finds but not hides on that page feels wrong. We could not prioritize fixing the hide count so we removed both until we can. If it's useful to people we'll address it in another release.

 

So what we have here, it that OpinioNate acknowledged the issue and spelled out it was a (lack of) priority issue. Restoring two lines of code assumes that the build process lets them do that. Judging by the way the site is updated once a month instead of a bit here and there suggests it's a bit of work to do a roll-back ... as in the roll-back would be undo everything that happened in the last update.

 

Much easier to tweak the code (prolly two minutes) and merge it in with the next scheduled update. I'm much happier with these "the site will be down on Thursday from 2pm to 4pm" updates than I was in the past with the random "the site is down .... no it's back ... no it's down again I NEED MY PQs!!!!!". Let due process (and bug checks) run their course.

 

I also need to mention that Groundspeak isn't necessarily telling us what the priorities are that are ahead of it. Could be that Pocket Queries were about to blow up and they said nevermind the find count - we need to get this other fix in ASAP.....

 

EDIT: Clarity in sentence one fixed.

Edited by northernpenguin
Link to post

lazy man's way of fixing the hide/found count on the friends page: remove the textual counts (as already happened) and replace them with an <img> tag to the user's stat bar. voila, problem solved. :)

Link to post

The hides count has never updated properly, and displaying finds but not hides on that page feels wrong. We could not prioritize fixing the hide count so we removed both until we can. If it's useful to people we'll address it in another release.

So what we have here, it that OpinioNate acknowledged the issue and spelled out it was a (lack of) priority issue.

Huh? It was not a priority to fix the hide count, yet they found the time to remove both the find and hide counts. That just blew you're argument out of the water. If the hide count wasn't a priority, then they should have left it alone like everything else that wasn't a priority.

 

Much easier to tweak the code (prolly two minutes) and merge it in with the next scheduled update.

Yes, it should be in the next scheduled update. I'm not suggesting it should be a hotfix as that should be done only if something is seriously wrong with the site.

 

I'm much happier with these "the site will be down on Thursday from 2pm to 4pm" updates than I was in the past with the random "the site is down .... no it's back ... no it's down again I NEED MY PQs!!!!!". Let due process (and bug checks) run their course.

Yes, much better this way.

Link to post

lazy man's way of fixing the hide/found count on the friends page: remove the textual counts (as already happened) and replace them with an <img> tag to the user's stat bar. voila, problem solved. :)

Ugh, no! While I realize you were joking, I just want to nip this idea in the bud.

 

Lil Devil's Friends List Enhancement script needs the text counts for one of it's major features so it's not "problem solved".

Link to post

So what we have here, it that OpinioNate acknowledged the issue and spelled out it was a (lack of) priority issue.

Huh? It was not a priority to fix the hide count, yet they found the time to remove both the find and hide counts. That just blew you're argument out of the water. If the hide count wasn't a priority, then they should have left it alone like everything else that wasn't a priority.

 

Again, assumes everything worked with the old code in place. They said they noticed a bug in the find and hide counts, and removed it. Could be they didn't think anyone was using it. Could be that it was about to cause a breach in the warp core. They may have broken it more with the updates for, say, Lost'n'Found nominations - and rather than say "we wanted to push L'n'F so we disabled that" ... the lawyers (or people in charge) may have told them to remove the old offending code for now.

 

Either way, nothings going to get fixed before the July 1 update cycle but we know it's at least on the radar, from OpinioNate's post.

Link to post
Lil Devil's Friends List Enhancement script needs the text counts for one of it's major features so it's not "problem solved".

aw c'mon, a little OCR in the script and that problem is solved too :)

Link to post

Again, assumes everything worked with the old code in place. They said they noticed a bug in the find and hide counts, and removed it. Could be they didn't think anyone was using it. Could be that it was about to cause a breach in the warp core. They may have broken it more with the updates for, say, Lost'n'Found nominations - and rather than say "we wanted to push L'n'F so we disabled that" ... the lawyers (or people in charge) may have told them to remove the old offending code for now.

If they lawyers told them not to talk about it then that's a different story.

 

Otherwise it's what they've said in the release notes and on the forums: the hide count was the only thing that was broken. If it was any of the other things you mentioned, all the had to was say that in the forums. "It was a problem with the code, it'll get fixed in the next release".

 

That's what they did with the cache page map problem. They told us it was a code problem and that a new and improved version was coming in the next release. Notice no peep from me about that problem?

Link to post

On a trakable page, the "Tracking History (6669mi)" line the mileage updates but on the list(the log section) below the mileage between placement logs does not.

 

Is this broken now?

 

I tried to 'recalculate mileage' and it use to then show up but doesn't now.

 

We do some caching here to reduce calls to the database. Give it a bit and let us know if you still don't see it.

 

Gave it 2 and half days and this is still happening. Mileage after tracking history updates but the mileage in the log section from placement log to placement log(cache to cache distance) is not showing up. Sometimes it does sometimes it doesn't. Others are mentioning this here starting post #222

 

Bumping up because I feel this got lost in the facebook and friends counts discussion :)

Link to post

Regarding the quick fix and process of rolling out updates...

 

I can't claim to know how GC.com development is managed... I know that websites aren't applications and don't need compiling; perhaps .NET might be an issue, but this is PHP.

 

That said, a problem such as showing a find count on a page - regardless of the rollout of updates - can be fixed in the script itself, live, easily. If it does need to change in the major source code for the next rollout, then that can be done when time permits so that it does get officially rolled out with everything in the next update.

I don't see a need to "rollback" all the recent updates and make re-adjustments from there, then re-rollout the changes, or anything near that complex.

 

If I was GC dev, barring restriction from TPTB, I'd be looking at the source for the page(s) in question, and seeing what can simply be put back into the code or changed to fix it even as a quick temp fix.

 

That said, obviously if there are rules and restrictions about edits to the website, then that process may be barred before even begun. However, I'm sure I've seen updates happen on the website, live, without full down times and rollouts of updates. Specifically, errors, which clearly don't wait until the next major rollout.

 

The dev side of me makes me believe that there is a development version of GC.com for which they make all the bug fixes and feature enhancements, then when the next major update occurs, the 'rollout' occurs due to taking the public site down so the development site can be duplicated without having any public outcry of error messages or missing pages and whatnot during the process. If that's the case, then very small code updates can be done to the public site without major updates or down time.

 

Anyway, this is me just being a web app developer, again trying to get a grasp for the process that GS manages the Geocaching.com website.

 

The process almost confuses me. Almost. But I still question the business practice in managing the bugs/features and major updates...

but anyhow.

Edited by thebruce0
Link to post

Regarding the quick fix and process of rolling out updates...

 

I can't claim to know how GC.com development is managed... I know that websites aren't applications and don't need compiling; perhaps .NET might be an issue, but this is PHP.

 

 

Just a quick note -- the forums are PHP, but the main site (with the Friends Page) is not:

 

 

Otherwise a well worded response that only Groundspeak can really offer insight beyond that....

Link to post

Regarding the quick fix and process of rolling out updates...

 

I can't claim to know how GC.com development is managed... I know that websites aren't applications and don't need compiling; perhaps .NET might be an issue, but this is PHP.

 

Actually, websites DO need compiling if you're dishing them up from an application server, like Tomcat, JSPs or similar. Tweaks to these sites require a code/test/deploy restart web server cycle.

 

The part that makes me double sure they are using this method is near the end on a page source view:

 

<!-- Server: WEB05; Build: Sprint13_20100602.3 -->

 

Which suggests a code based - generated page to me.

Link to post

To be honest, I don´t like this update

 

Is it possible, to remove the "Lost&Found" Banner ??

It´s too big, too much black toner, no advantage for the cachers.

 

Is it possible to bring back the Hides/Founds on Friends-Page ??

 

What´s advantage of FACEBOOK-Voting ??

I thought it is not allowed in a (Mystery) Listing, that cachers MUST log in in other websites. But for FACEBOOK you have to log in ...

 

Biggi_H

Link to post

Regarding the quick fix and process of rolling out updates...

 

I can't claim to know how GC.com development is managed... I know that websites aren't applications and don't need compiling; perhaps .NET might be an issue, but this is PHP.

Just a quick note -- the forums are PHP, but the main site (with the Friends Page) is not

D'oh, yes, of course, completely forgot I was looking at the forums :)

 

And thus, .NET it is, which leads to my response for the following comment...

 

Actually, websites DO need compiling if you're dishing them up from an application server, like Tomcat, JSPs or similar. Tweaks to these sites require a code/test/deploy restart web server cycle.

 

The part that makes me double sure they are using this method is near the end on a page source view:

<!-- Server: WEB05; Build: Sprint13_20100602.3 -->

Which suggests a code based - generated page to me.

Yes. It's ASPX, .NET, thus effectively a rollout requiring compiling the code to a web production server.

 

Doesn't negate the other points I made though. Might make it harder (.net source code gives me a headache :D ) but the public-facing script can be adjusted, even if it's a patchwork script, to include something as small as a find count. heck, even if it's done with a browser-side ajax call so there doesn't need to be any extra database coding on the page rendering itself.

 

Anyway, getting far too technical now, on an issue that most likely won't get resolved anyway until the next rollout, earliest. *sigh*

Edited by thebruce0
Link to post

Hi!

 

I am still trying to figure out what the big problem is with the "Like" button. Nothing is forcing you to click it, and even if you do only the people who are your friends on facebook can see it anyway. So if you are not friends with someone on Facebook than it makes absolutely no difference because they can't see it.

 

For me the BIG problem is that there will show up links to MY caches on some Facebook pages. And this is what I definitely never ever want to see!

 

Exactly that's the reason why I do want to have the choice to opt out for just MY caches. I don't care if other users want to have that link on their caches as I simply can block all the Facebook crap (what I already did) but I do care what will be shown on MY caches...

 

Bye,

Christian

Edited by monsterbox
Link to post

 

It DID get acknowledged a few posts back and all the (noisy forum posting) community did was jump on the guy who posted with more complaints about timing and wall-of-silence. We want Raine and Moun10Bike and co to come into the discussions, perhaps not flaming them every time they show up would be a good start.

 

I had that same thought.

Link to post

It boggles my mind that OpinioNate has not yet commented on this or even acknowledge the users in this forum requesting this feature be rolled back or repaired.

 

Boggle is fun to say. Boggle boggle boggle.

 

The hides count has never updated properly, and displaying finds but not hides on that page feels wrong. We could not prioritize fixing the hide count so we removed both until we can. If it's useful to people we'll address it in another release.

It boggles my mind that even when Lil Devil posts the old threads from when Groundspeak previously removed just the hide count and then put it back because there was an outcry from users, that they haven't learned anything from that incident. They make decisions based on what the pigs think they should do and ignore the chickens because they're not commited, but this only shows that they don't understand the agile methodology they claim to use. Frankly leaving a broken feature that even only 200 people find useful alone makes more sense to me than spending time to remove the feature entirely. What - you thought you'd save time having to explain to people why the hide count was wrong? Now you have about 200 people angry with Groundspeak asking why the counts aren't there. And based on past experience, they are rightfully worried that the counts will never come back. Leaving bug in place is an incentive to fix it. Removing the buggy feature means you have the option of declaring the bug is "fixed" and never bringing back the feature.

 

It doesn't bother me because I don't care much about my friends find counts, but it does mean if there is some feature I like and it isn't working right, I've no guarantee that instead of fixing it, Groundspeak will use the "make it go away" strategy on it. If you're going to remove some capability, the users deserve a better excuse that "We couldn't prioritize fixing it".

Link to post

There is a broken link in the new template.

 

<a id="ctl00_ContentBody_uxTravelBugList_uxTrackableItemsHistory">View past Trackables</a>

</p>

<p class="NoSpacing">

<a id="ctl00_ContentBody_uxTravelBugList_uxWhatIsATravelBug" title="What is a Travel Bug?" href="../track/faq.aspx">What is a Travel Bug?</a>

 

note the "View past Trackable" link actually exists, but doesn't hyper-reference anything.

Edited by Juicepig
Link to post

There is a broken link in the new template.

 

<a id="ctl00_ContentBody_uxTravelBugList_uxTrackableItemsHistory">View past Trackables</a>

</p>

<p class="NoSpacing">

<a id="ctl00_ContentBody_uxTravelBugList_uxWhatIsATravelBug" title="What is a Travel Bug?" href="../track/faq.aspx">What is a Travel Bug?</a>

 

note the "View past Trackable" link actually exists, but doesn't hyper-reference anything.

Markwelled...

Well, it turns out that until this bug is fixed, there's a way around it. To get the trackable history for a cache that currently has no trackables in it, paste this into your address bar:

 

http://www.geocaching.com/track/search.aspx?wid=(GUID of cache in question)

Edited by DENelson83
Link to post

It doesn't bother me because I don't care much about my friends find counts, but it does mean if there is some feature I like and it isn't working right, I've no guarantee that instead of fixing it, Groundspeak will use the "make it go away" strategy on it. If you're going to remove some capability, the users deserve a better excuse that "We couldn't prioritize fixing it".

 

In a way, this comment reminds me of the last rollout where the PQ results were up'd to 1,000. Part of that rollout included NOT e-mailing the MyFinds PQ. What!? You've been e-mailing it for over 2 years that I'm aware of (I've been caching 2 1/2 years)...why all of a sudden was that feature taken away? :blink:

 

I hate having to visit the website to download the MyFinds PQ...and I continue to keep my PQs to 500 results so I can receive them via e-mail.

 

I know if wasn't part of this 6/2 release...so I certainly shouldn't expect Nate to respond to it...right? :D

Link to post

I didn't seem to get an answer... I'll try this again:

 

Since your upgrade, I can't open a GC.com page without a message window opening up saying,

"This page uses fonts that need to be temporarily installed. This is usually safe. Do you want to allow these fonts to be downloaded?"

Then I need to click yes or no to open the page. ...every single time. Can someone tell me how to remove this annoying message?

 

I don't know enough about computers to fix this and would appreciate some guidance from you guys who created this situation.

 

<snip>

 

Is there still no answer for this flaw? I'm getting really tired of clicking that *&^% ok button everytime I want to view a different GC page.

 

I'm running XP and IE 8.0.6xxxx, with firefox the pop-up doesn't appear, but the font displayed looks really sad.

 

I'm running IE8 with no problem. The only thing that springs to mind is maybe your security settings are too high. Tools > Internet Options > Security Tab - Click on Custom and scroll about a third of the way down to Downloads. Check that "Font Download" is Enabled.

 

That fixed it, Thanks. It still begs the question of why the specialty font? It doesn't look different from any other website I've been to and I've never seen the font issue arise before.

 

At least changing the settings fixed it.

Link to post

That fixed it, Thanks. It still begs the question of why the specialty font? It doesn't look different from any other website I've been to and I've never seen the font issue arise before.

 

At least changing the settings fixed it.

Sounds like you may be missing some of the basic font sets that most PC have.

Link to post

Most people here dislike the fact that the (correct) found count disappeared. I haven't read many (any?) complaints about the placed data being removed.

True, but there were multiple complaints every month about the "hidden" count being wrong. I answered a lot of them by quoting my same reply over and over again. Link to search results.

Link to post

True, but there were multiple complaints every month about the "hidden" count being wrong. I answered a lot of them by quoting my same reply over and over again. Link to search results.

So why wouldn't just removing the hide count solve your problem?

Because then people would constantly be asking "why can I see my friends' find counts but not their hide counts?"

 

Can't win, no matter what.

Link to post
So why wouldn't just removing the hide count solve your problem?

because then people would start complaining that if there's a found count, there should also be a hidden count! ;):ph34r:

Link to post

because then people would start complaining that if there's a found count, there should also be a hidden count! ;):ph34r:

While you are joking, others have used that argument.

 

There's over a million cache pages with just the find count next to everyone's name and there's no complaints about that.

Link to post

Because then people would constantly be asking "why can I see my friends' find counts but not their hide counts?"

Doubt it. It's more noticeable when something is not right than when it's not there. And the reply for that is: "Code has a bug, it'll be back".

 

Can't win, no matter what.

Yes they can, by fixing the hide count. :ph34r:

 

My theory is that they're trying to filter out archived hides for that one and it's not working properly. The other two spots on the site that display the hide count include archived hides.

Link to post
While you are joking, others have used that argument.

actually i'm not joking, i'm pretty sure that this is what would really happen. i put the smilies because i find that kind of human behaviour pretty funny :ph34r:

 

of course it's not an argument for sanctioning what they did. removing something that was broken instead of fixing it, is not a fix, period.

Link to post
My theory is that they're trying to filter out archived hides for that one and it's not working properly. The other two spots on the site that display the hide count include archived hides.

why would they do that? i would expect the counters on the friends page to be the same as everywhere else, especially in the stat bar. it's working there, so i really don't see the problem of using the same code on the friends page.

 

unless they're worried about performance issues when showing pages of people who have hundreds of "friends". not sure if that's a valid real-life scenario though.

Link to post

of course it's not an argument for sanctioning what they did. removing something that was broken instead of fixing it, is not a fix, period.

They also removed something that wasn't broken. Everyone keeps grouping the find and hide counts as a single feature. They should be treated as two separate features.

Link to post

why would they do that? i would expect the counters on the friends page to be the same as everywhere else, especially in the stat bar. it's working there, so i really don't see the problem of using the same code on the friends page.

I'm just grasping at reasons why the code in that spot is so hard to fix.

 

unless they're worried about performance issues when showing pages of people who have hundreds of "friends". not sure if that's a valid real-life scenario though.

No different that showing a cache page with hundreds of logs. I'd say most cache pages have more logs than people have friends. And the cache pages are viewed much more often than the friends page.

Link to post
login.GIF
In possible fear of inciting a riot the scale of the facebook like option, friend counts or the cache page map problem, I would like to report a difference pre and post June 2. Because really, they're of about the same significance (non life threatening) and there are other ways to work around it.

 

I like using my keyboard and I get used to tab locations of certain fields. Prior to the latest update, when logging in (from home page), I could enter user name, tab, enter password, tab, Remember Me (hitting space bar to toggle check mark on), tab and finally space bar as input for login button.

 

Now that has been altered and jumps around quite a bit, forcing me to actually have to use my mouse (insert sound of angry mob :blink: ). Any chance that could be looked at in the future?

 

thanks.

Link to post

Mileage after tracking history updates but the mileage in the log section from placement log to placement log(cache to cache distance) is not showing up.

 

This started on June 2, 2010.

Link to post

I am still trying to figure out what the big problem is with the "Like" button. Nothing is forcing you to click it, and even if you do only the people who are your friends on facebook can see it anyway. So if you are not friends with someone on Facebook than it makes absolutely no difference because they can't see it.

 

The big deal for me is I don't like my info being linked all over the internet, especially without my permission.

 

If I WANT my caches linked to facebook, I will link them.

 

As a matter of FACT, I do NOT want my caches linked to facebook or any other social networking site.

 

Color me one of the many unhappy CUSTOMERS of Groundspeak

Link to post
If I WANT my caches linked to facebook, I will link them.

 

As a matter of FACT, I do NOT want my caches linked to facebook or any other social networking site.

then you have to make them PMO, because otherwise, anyone can link to them anywhere they want. FB button or not.

Link to post

The big deal for me is I don't like my info being linked all over the internet, especially without my permission.

 

If I WANT my caches linked to facebook, I will link them.

 

As a matter of FACT, I do NOT want my caches linked to facebook or any other social networking site.

 

Color me one of the many unhappy CUSTOMERS of Groundspeak

 

BUT, unless YOU use the link with YOUR facebook account, then you are still just as anonymous as you have ever been on GC, because anyone that views your cache can only see your username and public profile, just like any other cacher can, and even then, only if they are registered on GC.

 

For me, the link itself is just a bit annoying and as a non-facebook user, I'd like to be able to hide it from MY view. But it poses no threat to your privacy, any more than a link to your cache which a another cacher might place in a blog or forum.

Edited by MnCo
Link to post

hi, the one thing ive noticed that i dont like at all, is the friends list no longer displays the number of caches people have found, it now has location instead so to view how many caches your mate have got u now have to click on them and open up there profile, i used to like just checking my firend list to see who had been caching recently and how many that were now on.

 

I agree. I really liked being able to click on My Friends and see at a glance on that summary page what my friends counts were up to. Any chance that will come back?

 

I really like a lot of the other changes though.

 

Thanks for all the hard work.

Link to post

I, too, was upset about the friends find counts being removed, but I have serious doubts that we are being listened to, so I took my own approach to fixing it, which I'll share here. This may not be practical if you've got tons of friends but if you want to quickly watch 10 cachers or so, it works fine.

 

First, go to your current friends, and make a list of their GUID's which are numbers found on the cacher name link on the friends page.

 

They look like this "http://www.geocaching.com/profile/?guid=cff16fe6-db1a-40b4-bee9-e3205b3151ac".'>http://www.geocaching.com/profile/?guid=cff16fe6-db1a-40b4-bee9-e3205b3151ac". The number you want is to the right of the "=" sign. If you want to see their avatar picture, copy that link address of their picture, and make note of the JPG name after the word "avatar".

 

On your personal profile page, you can place the following HTML, and then you will see the avatar of your friend, and their status box with both their find AND correct number of hides! All you need to do is replace the JPG name with the avatar picture name, and change the two copies of the GUID found in this text with the ones of your friends. This will make the stats bar linkable, so you can go and see exactly what they found..

 

<img src=http://img.geocaching.com/user/avatar/4b61c7b5-01fe-4642-bde6-53c40b829b8e.jpg><a href="http://www.geocaching.com/profile/?guid=cff16fe6-db1a-40b4-bee9-e3205b3151ac" target="_blank"><img src="http://img.geocaching.com/stats/img.aspx?&uid=cff16fe6-db1a-40b4-bee9-e3205b3151ac&bg=1" border="0" ></a>

 

The text that needs to be customized is in bold above.

 

I hope that this is helpful. If you want to see how it looks, feel free to visit my profile page. I'm PORTERA.

 

Enjoy!

Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...