Jump to content

Release Notes (Website and Geocaching® app: Drafts) - April 24, 2017


Recommended Posts

I don't want the website or apps to remain the same because people don't like change.

 

Neither do I. I want it to remain the same because it's better ! Change is always welcome when it brings improvements. The new page looks good, and that's about it. From all other perspectives, it brings less to the table.

 

Maybe the developpers should look into responsive design media queries... It is actually possible (and not so hard) to improve the look and feel for apps / smartphones / tablets... without impacting desktop users. One day, maybe...

Link to comment
It is so much easier and cleaner on my phone now. Also using it on the computer it works just fine.

And there is the problem. It used to work perfectly, now it's "just fine", for some use cases. I don't see why the website needs to be mobile only, when we already have the app.

+1

If the goal is to have the website work better on a phone, then why bother having an app - just have cachers use the website on the phone.

 

IMO, if someone wants to log caches on their phone, then use the app. The photo, fave, NM/NA options, and Drafts were built into the app. Why does the logging experience on the geocaching.com website need to be tailored to phone users? Those of us who choose to log via the website are probably doing so because we don't want to use our phones, so why can't we use a logging page that fits a laptop/desktop environment?

 

I'm really disappointed. I feel like the intent is to steer cachers towards leaving simple logs without many photos. Maybe that is better for GS because they'll have less data to store? I don't know. It's pretty disheartening. :sad:

Link to comment

I put most of my comments about the new logging experience in the more recent Release Notes thread (Release Notes (Website only) - April 27, 2017), so won't repost all of that here. I read this thread after reading and commenting in the 4/27 thread and see that other cachers mentioned the same issues/opinions. Guess I'm not just being picky.

 

Also, please note it may take up to two days for some users of the Geocaching® app for Android to have access to the update that includes this functionality.

I'd like to review the updates to the app, but it appears that 5.2 is still not available in the Google Play Store. Should it be taking this long (4 days)?

Link to comment

I'd like to review the updates to the app, but it appears that 5.2 is still not available in the Google Play Store. Should it be taking this long (4 days)?

 

Thanks for your patience. Google allows us to use staged rollouts to a fraction of users so that we can make sure the release is crash-free before making it available to all Android users. Usually that process only takes a day or two, but this time we had a bump in the road. Our first rollout of 5.2 ended up creating some crashes when we released it to 10% of users. We pulled that release back, made some fixes (twice), and are now doing a staged rollout of 5.2.3.

 

The bad news is that it's taking longer than we expected for you to get the release. The good news is that you won't get a release that crashes.

Link to comment

The log page is a bit slower to bring up than the old one. I measure a pretty consistent 3400ms on the new page vs 2200ms on the old page. It's a bit unsatisfying to see the spinning circle while the page is loading resources or doing some ajaxy thing. Will performance measurements be taken and acted on? Thanks!

 

A bit slower? The numbers you posted show it is 50% slower.

 

I loaded up developer tools in FF and I see a few things worth mentioning.

  • There's a 269KB file at https://www.geocaching.com/images/tlnMasters/topo-tile.svg that is being loaded on the page though I don't see being displayed.
  • There's a reference to HotJar being loaded so I expect they are using hotjar which is a tool that shows the GS team where people are mousing, clicking, scrolling, etc. It can be viewed in aggregate or each individual user's session to track the interaction on the page. That doesn't help the page load time and should be disabled as soon as they have enough data collected, which on the log page should be by Monday morning.
  • The server response time to return the root HTML for the latest log page is almost twice as slow as the page was yesterday, even though yesterday's page payload was larger.
  • The ajax calls are likely checking for new messages

It's as if we went in features, usability and performance from a v4.3 site to a v0.3 site. Maybe the source code was lost and they needed to revert to a 3.5" floppy zip copy from 2003?

 

I posted in the other thread but adding here too: Thanks for letting us know - we've received other reports of this as well. We're looking into this now and will provide a status update as soon as possible.

Link to comment

I have been an enthusiastic geocacher since the day I discovered it. I have a deep respect for the cache owners that work to give us great moments in beautiful places. I use to return my pleasure to them by giving favorites (where are they?) but also by telling stories through my logs, giving a life to the cache with several photos taken on the spot or just around. I make temporary logs on the field, but when I come home, I go to my PC and tell a story. The new page is giving me the impression that GC want to limit all this. There are so many great comments, with all the flaws of this backwards move, on this Forum, and they are all, or nearly, fully against the new page. It is not just a new page, it is a philosophy that is slowly banned without thinking to the users... Change for the sake of change is never productive, at least it produced something,a massive géocachers' reaction. I wish some guys of GC would go to the field, try to understand that geocaching is not a world of simple "TFTC" made for smartphones owners. As said in the past: "this is a giant leap... for dumb kind". Please bury that thing!

Best regards from Paris

Link to comment

App won't even open now with the new update, crashes immediately. Using iPhone 5s v 10.3.1.

 

What I would like to see added is to be able to access personal cache notes from the cache page with the app.

Hi, Did this problem get fixed for you? I use an iPhone 5 also. My geocaching app crashes too. Any advice?

Link to comment

Just logged my first two finds using the new logging experience.

 

1. The actual text entry box is 1/3 the width of my screen (at 0% zoom level) : using the whole available screen space is SOOO last year.

 

2. The text entry is now grey on white, not so easy to see what you're writing : Grey is the new Black.

 

3. I was going to add a smiley to my log, but the help dialog showing the markup options is gone. : Interesting and fun logs are a thing of the past.

 

Yes it's a new experience, but it's a bad one :(

Link to comment

My issues:

 

1) Couldn't get the date to change (no drop-down box to select date, no drop-arrow, nada). This is a clear and obvious error. Just like with the (equally limited) app option, you have to Edit the log to change the date manually after having logged in thru the website. Weird omission; makes no sense.

 

2) Don't like the lack of 'Add coordinates' option. It was solid.

 

Positive:

 

1) I like that the 'Found it' log can't be duplicated any more. That's a nice touch

Link to comment

And the website just keeps getting worse. Its losing functionality everywhere, it gets completely dumbed down and it looks and acts more and more like a phone app which is terrible.

Remind me again why all these changes are being made? Its mostly for the worse with every change they do. It never feels like they think things through at all.

Do they actually want us to pay for premium? Cause it feels more like they are neglecting the users and pushing people out of the game. Im not going to renew when such bad changes like these gets implemented.

Edited by !Lux
Link to comment
What would be better in this setup is if by tapping the NM checkbox a new box would open (much like attaching coordinates did previously), even if pre-populated with text if desired, where the user can explain the maintenance concern in greater detail.
Yep!!!
That's how I would have designed it. But of course, no one asked me.
Link to comment

Please keep in topic and please use respectful language... please.

 

I can only assume this comment refers to my post, because I see it has been deleted.

 

I'm afraid I must stand by my post (which clearly I can't restate here). It was not meant to be disrespectful, and I thought I stated that clearly. I used no inappropriate or disrespectful language. I even used the phrase "I respectfully suggest..."

 

You are advertising open positions at HQ for developers who would be responsible to build features such as this new logging page. Clearly you (HQ) realize you need the talents of those missing developers, or you wouldn't be trying to fill those positions. If you had them, I'd like to hope that this change would have been done differently, in a way that would delight your users, not irritate them.

 

HQ has a persistent problem with ignoring feedback the community gives you. You launch changes to the site that are not well received, you get feedback from your community that is overwhelmingly negative, and yet you continue with the changes. Recent examples that come to mind:

 

- The new Search Page

- The Changes to the Maps

- The phone app

 

Now this.

 

I'm sorry that you found offense in my previous post. It was meant as feedback to a problem that is wider than this one issue (the new logging page). This issue is the just the newest illustration of the problem, and as a member of this community, I still feel it's important to say that.

 

I agree! Hopefully we won't get put in timeout!!!

Link to comment

 

Maintenance

-I personally like that Needs Maintenance and Needs Archived logs are separate from Found/DNF/Write Note logs. It makes them stand out on the cache page. I'm not sure what these logs will actually look like when added to the cache page, but hopefully they will still stand out to COs and other finders of the cache.

-The options you have for different maintenance that may be required are very few. Not every situation will fit into one of those options. If you are planning on keeping this feature maybe there would be use in adding a some more possible responses.

 

 

I had the opportunity to try this out this morning. Here's what actually happened:

 

- There was an actual second Needs Maintenance log created, just like in the Olden Days.

- I had chosen the "Other" option, because, of course, the situation didn't fit any other response.

- After choosing "Other", there was no prompt the ask me what the Other Information was.

- The circle-i icon/button turned green.

 

- After submitting the log, I went back to the cache page and found my NM log. I don't remember exactly what the text said, but it was something close to "This geocacher has reported that there is a problem with this cache."

- As that was NOT what I wanted to say, I used the "Edit" feature, which brought me to the "old" log edit page, where I was able to correct the text. I was even able to use the formatting toolbar (because, well, it existed) to highlight some important points to my message to the CO.

 

So, it seems that, at present, we can still have some control over the message, it's just a convoluted process.

Note that when you log a find and include NM, the find's log date is the date you create it, and the NM date is the date you actually upload it. Not really a bad thing, but for someone that caches all week and uploads the logs on Saturday, the find and NM logs can be separated by several other find logs.

Link to comment

I agree with almost everything you say here. For those of us who don't have a smartphone because we live where it isn't offered, it really looks like GS is trying to push us away. It seems very apparent to me that the techies have zero interest in anyone who isn't using a smartphone. For me, they have made it so I can't even load caches with my Magellan, using the Firefox browser. I am stuck using Internet Explorer, of all things. Talk about a giant step backwards.

 

Yes - that is the pits.

Link to comment
What would be better in this setup is if by tapping the NM checkbox a new box would open (much like attaching coordinates did previously), even if pre-populated with text if desired, where the user can explain the maintenance concern in greater detail.

Yep!!!

That's how I would have designed it. But of course, no one asked me.

If I were designing this, I would have gotten to this point and said, "Gee, now that it has all the features we need, it's just like what we already have, except the new approach is more complicated. I guess those guys that implemented the original feature knew what they were doing after all. I wonder what else I'm missing that hasn't occurred to me yet." Then I would have gone off to do something useful.

Link to comment

Another couple of observations on the NM/NA method (may have already been mentioned above but...)

 

Suppose I notice that a cache hide that I've previously found has been compromised (e.g. the lamp-post it was attached to has been totalled in an RTA). Previously I would simply log an NM mentioning it. I can't now log a stand alone NM, I now have to write a note describing what's happened and click the NM/Other button, resulting in 2 logs on the cache, one with a meaningful description but no associated action, one with an associated action but no meaningful description. This is neither intuitive, efficient, or sensible.

 

My usual MO for a cache which I DNF and think needs maintenance is I will DNF it, then log an NM. If no action is taken on the NM after a while I will usually NA it with a description as to why I think it should be archived. Again I can't do that and am in the 2 logs for 1 purpose situation again.

 

Suppose someone is on vacation and logs their finds when they get back home, one early find needed maintenance, so when they've logged them the find is dated some time before the NM, that means anyone seeing the NM will have to trawl through previous finds to see the main log in the hope of finding out what the problem is. Also if the CO has performed maintenance on the cache shortly after the find it would then appear that the NM log was placed after the maintenance log, and therefore that the cache still needs maintenance even thought it has already been addressed.

 

 

The NM/NA buttons should open up a dialog requesting a description of the problem; the date of the NM/NA should be the same as the associated main log, or should be changeable. There should also be a facility for logging a standalone NM/NA log without having to create an unnecessary second log type.

Link to comment

Yep, I just posted the same thought in the other release thread:

 

IF they were to continue along this concept, then reporting maintenance should not be relegated to a mere flag. There needs to be indication of where details for the flag can be added - not just canned responses (without the ability to add more detail) - whether that be indicating the main log should contain the reason (which can lead to having to comb through many paragraphs of visit-related experience for the issue, not very optimal) or a separate entry field to provide greater detail about the issue (which could be pre-populated with the canned text, even).

 

Logging a NM separately should still be possible, however. But allowing a visit log (find/dnf/etc) as well as flagging the NM and its details in the same workflow is indeed a more streamlined process I would say.

Link to comment

Another couple of observations on the NM/NA method (may have already been mentioned above but...)

 

Suppose I notice that a cache hide that I've previously found has been compromised (e.g. the lamp-post it was attached to has been totalled in an RTA). Previously I would simply log an NM mentioning it. I can't now log a stand alone NM, I now have to write a note describing what's happened and click the NM/Other button, resulting in 2 logs on the cache, one with a meaningful description but no associated action, one with an associated action but no meaningful description. This is neither intuitive, efficient, or sensible.

 

My usual MO for a cache which I DNF and think needs maintenance is I will DNF it, then log an NM. If no action is taken on the NM after a while I will usually NA it with a description as to why I think it should be archived. Again I can't do that and am in the 2 logs for 1 purpose situation again.

 

Suppose someone is on vacation and logs their finds when they get back home, one early find needed maintenance, so when they've logged them the find is dated some time before the NM, that means anyone seeing the NM will have to trawl through previous finds to see the main log in the hope of finding out what the problem is. Also if the CO has performed maintenance on the cache shortly after the find it would then appear that the NM log was placed after the maintenance log, and therefore that the cache still needs maintenance even thought it has already been addressed.

 

 

The NM/NA buttons should open up a dialog requesting a description of the problem; the date of the NM/NA should be the same as the associated main log, or should be changeable. There should also be a facility for logging a standalone NM/NA log without having to create an unnecessary second log type.

+1

Yes, absolutely agree!

Link to comment

Suppose someone is on vacation and logs their finds when they get back home, one early find needed maintenance, so when they've logged them the find is dated some time before the NM, that means anyone seeing the NM will have to trawl through previous finds to see the main log in the hope of finding out what the problem is. Also if the CO has performed maintenance on the cache shortly after the find it would then appear that the NM log was placed after the maintenance log, and therefore that the cache still needs maintenance even thought it has already been addressed.

 

The NM/NA buttons should open up a dialog requesting a description of the problem; the date of the NM/NA should be the same as the associated main log, or should be changeable.

First off, you couldn't change the date on NM/NA logs before, and I don't think you should now. It was never an issue before.

 

If someone is catching up on logs and found a cache that NM, they should be checking the cache listing to see if the issue has already been dealt with. They shouldn't be blindly submitting an NM log based on their visit from a week or two earlier (or even more).

 

Now, if the maintenance issue still exists and they do submit the NM, it is less useful to have an NM dated today and the detail in their log on some earlier backdated date. Backdating the NM log wouldn't really make things much better, though. It would associate the two logs more closely, but the NM may now be buried underneath a bunch of more recent logs, making it harder to notice.

 

If we can describe the issue in the NM/NA log that's created, then this would pretty much all be a non-issue.

Link to comment

 

First off, you couldn't change the date on NM/NA logs before, and I don't think you should now. It was never an issue before.

 

I don't mean change the date once the NM log has been posted, I mean change the date when writing the NM to the correct date whereas now the NM log is posted automatically by the system and we have no control over the date of the NM log.

Link to comment

If someone is catching up on logs and found a cache that NM, they should be checking the cache listing to see if the issue has already been dealt with. They shouldn't be blindly submitting an NM log based on their visit from a week or two earlier (or even more).

This makes sense in the old system where the NM log is separate. It doesn't make so much sense when reporting a problem is just a checkbox on a find log.

 

First off, you couldn't change the date on NM/NA logs before, and I don't think you should now. It was never an issue before.

I don't mean change the date once the NM log has been posted, I mean change the date when writing the NM to the correct date whereas now the NM log is posted automatically by the system and we have no control over the date of the NM log.

What The A-Team was pointing out is that you've never had any control over the date of the NM log, and that's for good reasons which have not changed.

Link to comment

Hello,

 

there is a new error in the logging windows. last week everythink was ok, and every day an update made a better loggingpage. but after the rollout off the new loggingpage over the logging from a listing there is an error.

 

as well in the loggingscreen if you come from drafts or from a listing.

 

this error is since 2-3 days.

 

See the picture:

 

Sreenshot from drafts loggingscreen from 04/25/2017

6b4f9fa3-6099-456c-91fb-a9a391d7e283.jpg

 

no error all is ok.

 

--

 

Screenshots from today, 05/02/2017

 

from drafts loggingscreen:

61cbcd0e-61b3-45f3-b375-c5ab20cc7865.jpg

 

from listing loggingscreen:

990106a9-4911-4b41-a980-05c6b539c243.jpg

 

ERROR: All icons are missing ! for the NM it shows the text, but for the camera, the favipoints and he dropdown at TBs nothing.

 

If you go over with the mouse, you see the change off the cursor from arrow to finger, if you wait some seconds the tooltip pops up and show the text:

- upload a photo

- favorite this geocache

 

I have some travelbugs in my inventory, but the dropdown arrow is missing, if i click wenn the mousecursor changes to finger the TB menu opens fine.

 

Update request:

1.)

I add a nother request for the better look and feel of the logging page, please show the frame off the dropdown menu, like the logtype menu,

it is only a click/change in the code : from border:none; to border:visible;

 

2.)

It would be nice if you can see next to the Favi icon your remaining favi points

 

3.)

change the font style for the 'by' between the cache name and the owner name for a better separation. (example: no bold or italic)

 

Thanks,

greetings from germany

Wulfman_Do

Link to comment

If someone is catching up on logs and found a cache that NM, they should be checking the cache listing to see if the issue has already been dealt with. They shouldn't be blindly submitting an NM log based on their visit from a week or two earlier (or even more).

This makes sense in the old system where the NM log is separate. It doesn't make so much sense when reporting a problem is just a checkbox on a find log.

I agree with 'The A-Team' on this. Most of my logs are submitted well after the actual find date. I use Field Notes a lot.

 

If I come across a cache that needs maintenance, then I will make an extra effort to submit an NM log right away (or the next day) to describe the problem. For example. Interestingly, I submitted this NM log on 4/9, but now the date says 4/10. Not sure when that changed.

 

If I come across a cache that needs maintenance, but I don't log the NM within a few days - then I may just skip logging an NM at all, especially if others have found the cache since my visit. It might be that the CO stopped by and tidied up the cache, or maybe another cacher gave it some TLC. If I post an NM log today, for a cache I visited 2 weeks ago, then I may be reporting a problem that doesn't actually exist anymore.

 

Regarding the 'just a checkbox on a find log' - reporting an NM via the new logging page still results in 2 separate logs on the cache page (example1, example2). With the old logging method, it was apparent what date would be attached to the NM/NA log, because the "Date Logged:" box would say "Today" and could be previewed on the window where it asks "You are posting a "needs maintenance" log entry. This will add an attribute and alert the owner. Click "yes" to continue." Correct me if I'm wrong, but it's not clear with the new logging page that the NM log will have a different date than the found/dnf/wn log it's associated with.

 

First off, you couldn't change the date on NM/NA logs before, and I don't think you should now. It was never an issue before.

I don't mean change the date once the NM log has been posted, I mean change the date when writing the NM to the correct date whereas now the NM log is posted automatically by the system and we have no control over the date of the NM log.

What The A-Team was pointing out is that you've never had any control over the date of the NM log, and that's for good reasons which have not changed.

+1

The NM log date should not be editable. If someone visited my cache 3 weeks ago and found a full log and they're logging a find today, then I don't want their "log is full" NM log to have a date of mid-April.

 

It's entirely possible that a new log sheet had been added since then and it's no longer an issue.

More likely, is that it appears the CO has ignored an issue for 3 weeks, even though they were not alerted to the issue until today. Let's say I get the NM log in my email today, because today is when the NM log was submitted with the Found log. I might go replace the logsheet tomorrow and post my OM tomorrow, but someone looking at the cache page would see that I replaced the logsheet 3 weeks after the NM log.

Link to comment

So sad... How do we revert to a more easily managed logging page like the one we had before? This one is slow, unresponsive and really wastes far too much space on a real computer monitor.

Link to comment

I'd like to review the updates to the app, but it appears that 5.2 is still not available in the Google Play Store. Should it be taking this long (4 days)?

Thanks for your patience. Google allows us to use staged rollouts to a fraction of users so that we can make sure the release is crash-free before making it available to all Android users. Usually that process only takes a day or two, but this time we had a bump in the road. Our first rollout of 5.2 ended up creating some crashes when we released it to 10% of users. We pulled that release back, made some fixes (twice), and are now doing a staged rollout of 5.2.3.

 

The bad news is that it's taking longer than we expected for you to get the release. The good news is that you won't get a release that crashes.

Got the new version a few days ago. No crashing so far. :)

 

-- The visibility of which caches have Drafts is great. It would be great if the symbol was more differentiated from the mystery cache symbol, but I'm not really sure what color would be better. The current symbol does the job.

-- The link to open the cache page from the Drafts list is much appreciated.

-- It's a bit tough to understand how the timestamps have changed, since the timestamps haven't returned to the Drafts webpage. I did notice that a Draft I submitted via the app ended up in the correct order after I uploaded other drafts that I found before/after it from my GPSr, so that's a good sign.

 

Thanks for the continued progress on the app.

Link to comment

Usually I am not the big discussion guy on forums, since I think that most is already said. However, especially after having browsed through most of the recent comments, I break my habit and add my dissatisfaction remarks to the recent changes. To start with:

- I am (premium) cacher from the early hours, and had a lot a fun since 2002, first with the website and then with the (paid) app

- I am myself busy in a hi-tech environment and are definitively not against change

- I have given the new app its time to prove itself since the "closure" of the old one

 

However, I fail to see any improvements in the recent changes on app and website. I am quite fine with the look&feel (I am rather agnostic to that), but I get rather itchy if functionality seems to get lost without any reasonable justification. Just to name a few:

- Calling field notes drafts is ok. However, once you have logged them, they should disappear

- Not having access to the personal cache notes can be a disaster in the field

- Finding coordinates of a cache needs many more taps, and still solved coordinates not visible in main map window

- Not being able to access lists in the app is bad (lists and pocket queries seem to be called the same and handled differently)

- Offline capabilities either not there or well hidden (no clear indication, especially relevant for travel and roaming...)

- Speed / performance seems slower

- Photos caption needs many more clicks (cannot be done together with the first upload of the photo)

- Being able to give favourite points is good, but cannot see how many left

- Photos from logs (gallery of a cache) missing and only accessible through individual logs

 

Could go on for things, but I guess a lot of this is just repeat what others also said.

 

Overall disappointed, and I hope that improvements will come quickly!

Link to comment

Another couple of observations on the NM/NA method (may have already been mentioned above but...)

 

Suppose I notice that a cache hide that I've previously found has been compromised (e.g. the lamp-post it was attached to has been totalled in an RTA). Previously I would simply log an NM mentioning it. I can't now log a stand alone NM, I now have to write a note describing what's happened and click the NM/Other button, resulting in 2 logs on the cache, one with a meaningful description but no associated action, one with an associated action but no meaningful description. This is neither intuitive, efficient, or sensible.

 

My usual MO for a cache which I DNF and think needs maintenance is I will DNF it, then log an NM. If no action is taken on the NM after a while I will usually NA it with a description as to why I think it should be archived. Again I can't do that and am in the 2 logs for 1 purpose situation again.

 

Suppose someone is on vacation and logs their finds when they get back home, one early find needed maintenance, so when they've logged them the find is dated some time before the NM, that means anyone seeing the NM will have to trawl through previous finds to see the main log in the hope of finding out what the problem is. Also if the CO has performed maintenance on the cache shortly after the find it would then appear that the NM log was placed after the maintenance log, and therefore that the cache still needs maintenance even thought it has already been addressed.

 

 

The NM/NA buttons should open up a dialog requesting a description of the problem; the date of the NM/NA should be the same as the associated main log, or should be changeable. There should also be a facility for logging a standalone NM/NA log without having to create an unnecessary second log type.

 

I agree with your statements above. And I hadn't thought about the instance where you've previously found and subsequently needed to NM it...

 

An option would be to write note, and select the NM link. I'm not saying this is a good answer, just that it allows a NM in your scenario. Nope - certainly not intuitive, but better than nothing. And I'm confident that the note's date and the NM date will be separate as well, requiring the CO to grew through possibly numerous logs.

Link to comment

Logging a NM separately should still be possible, however. But allowing a visit log (find/dnf/etc) as well as flagging the NM and its details in the same workflow is indeed a more streamlined process I would say.

 

Agreed - streamlined - provided they change to allow a text block in the NM pop up.

Link to comment

 

Now, if the maintenance issue still exists and they do submit the NM, it is less useful to have an NM dated today and the detail in their log on some earlier backdated date. Backdating the NM log wouldn't really make things much better, though. It would associate the two logs more closely, but the NM may now be buried underneath a bunch of more recent logs, making it harder to notice.

 

If we can describe the issue in the NM/NA log that's created, then this would pretty much all be a non-issue.

Makes sense...

Link to comment

OK, i've tried out the new logpage and decided for me, it's just crap.

 

Sorry for these hard words, but it's simply fact.

That page gives pain to my eyes, compared to the old one.

That page does not give any feature (like the emoticons), compared to the old one.

That page is simply ugly, compared to the old one.

That page scares you off logging your cache visit, compared to the old one.

That page will simply prevent many cachers from publishing their experience od their found caches...

It is much more useful for the cache owner, to receive an individual and precise description of the failure/defect of his cache, instead of a vague message that the cache 'needs some maintainance'...

 

Please return to the old page!

Link to comment

If someone is catching up on logs and found a cache that NM, they should be checking the cache listing to see if the issue has already been dealt with. They shouldn't be blindly submitting an NM log based on their visit from a week or two earlier (or even more).

This makes sense in the old system where the NM log is separate. It doesn't make so much sense when reporting a problem is just a checkbox on a find log.

I agree with 'The A-Team' on this.

I guess I wasn't very clear that I agree with The A-Team, as well. My comment was that the entirely correct idea that people should check for intervening NMs before posting their own NM doesn't make as much sense with the newer logging method.

 

Regarding the 'just a checkbox on a find log' - reporting an NM via the new logging page still results in 2 separate logs on the cache page (example1, example2).

Yes, I understand it results in an actual, though vacuous, NM, but the person posting the log doesn't know that based on the interface.

 

But more importantly, I suspect that this is just the first step in a move towards eliminating the NM log altogether. While I don't really know what GS is thinking, I do know that the people that have asked for this misfeature in the past described it as adding the NM attribute to the find log, not as a way to automatically file two logs at once, and I assume those are the people GS is trying to satisfy with this change.

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