Release Notes (Website only, Drafts page) - June 22, 2017

[+Geocaching HQ 354]

Release Notes (Website only) - June 22, 2017

With this release we have updated the Drafts page on Geocaching.com.

• The page design is updated and refreshed.
• The "Upload drafts" and "Drafts" pages are combined into one Drafts hub.
• Sort drafts by date.
• Preview log text from Drafts hub before posting to the cache details page.
• Drafted logs in the Drafts hub are listed in the time zone of the cache.
• Timestamps are back. To view, hover over the date in the Drafts hub list.
• Single delete and Delete all functionality .
• Automatic prevention of duplicate draft creation on upload.

Lastly, players can opt-out of the new page during a transition period.

Nadja from HQ’s Product Team is watching the thread to answer questions whenever possible.

Any posts in this thread should relate to features in this release. Please direct unrelated comments to other appropriate threads. Thanks!

[+baer2006 788]

In my first test, the new page didn't upload the field notes file from my GPS device (Garmin eTrex 30x)!

 

I clicked on the "Upload drafts" link on the new page, selected the "geocache_visits.txt" file from my Garmin, and got a red error message saying ""geocache_visits.txt" is not in the correct format." Not good ! Then I "opted out" to get to the old page, tried to upload the same file from there ... and it worked! So it's not a corrupted field notes file. As a further test, I created a copy of the file, and stripped it down to a single line (the last one). Then everything worked as expected, and the new upload function could read the file. So apparently one or more entries in the file were the problem. I investigated, and found indeed two lines which lead to the error. By knowing the root cause of the problem, it's easy for me to circumvent it in the future.

 

And now it gets a little bit complicated, because on one hand I'd like to share my findings so that others, who run into the same problem, know what to do. On the other hand, to do so I may have to violate the posting guidelines of this forum. I'm going to post it anyway, and see what happens .

 

The quintessence is, that the new parser fails, if the waypoint identifier of a line doesn't begin with "GC". But occasionally I use other listing platforms as well, which also support Garmin field notes, but which of course use cache IDs with different prefixes. So I'll have to manually remove the "bad" entries from the field notes file before trying to load it on the geocaching.com website. Not a big deal, once you know what to do.

 

Regards

baer2006

[+noncentric 810]

Regarding items announced in the OP:

• The page design is updated and refreshed.
  I'm not a big fan of the page design, but am also not surprised that it's happened. As with other page redesigns, I feel that the Drafts redesign has too much whitespace. And also, the darker grey against a lighter grey background can be difficult to read.
   
  
• The "Upload drafts" and "Drafts" pages are combined into one Drafts hub.
  I like the change to the upload process. My only comment here would be to somehow emphasize that the "Upload drafts" text can be selected to initiate an action. Maybe put a line border around the text?
   
  
• Sort drafts by date.
  This is a nice feature, especially as it seems to be sticky.
   
  
• Preview log text from Drafts hub before posting to the cache details page.
  I liked seeing this for drafts in the app and appreciate seeing it on the website, however - it truncates the text more than seems necessary (see image below). The truncation point doesn't adjust based on browser window size. I'd like to see the text wrap, or else move the truncation point further than 50 chars. Perhaps 100 chars.
  

  

  
   
  

• Drafted logs in the Drafts hub are listed in the time zone of the cache.
  This is a nice feature and am glad to see it.
   
  
• Timestamps are back. To view, hover over the date in the Drafts hub list.
  I'm glad to see timestamps are back, but would prefer they be shown by default. Not sure why they show only on hover. Please have the timestamps be shown automatically.
   
  
• Single delete and Delete all functionality .
  Seems fine to me, as I don't delete drafts often. However, I can see the removal of multi-select checkboxes being problematic for users that need to delete several drafts at once. Not sure how often this happens though, especially considering the next bullet.
   
  
• Automatic prevention of duplicate draft creation on upload.
  I like this feature much better than the 'Ignore logs before' functionality. It seems to recognize duplicates based on unique cache+date+time+log type.

 

A few things that weren't mentioned:

• The type of log is presented only as text, without the prominent icon (smiley, frowney, red wrench, etc).
  I'm not a fan of this. I try to post DNF's and NM's right away, saving the Found It's for later when I have a bigger block of free time. Without the icons, it's tougher for me to quickly spot which of the Drafts are for a DNF or NM log. Please incorporate the log type icons into the Drafts page.
   
  
• The page does not load all Drafts at once, but instead loads on demand.
  I'm not a big fan of this. I freaked out when I first went to the page because I thought a bunch of my Drafts were missing, but then I saw the green spinner.
   
  
• Clicking on an entry opens a new browser tab to compose the Draft, but there's no longer a link to open the cache page.
  Please include a link to the cache page itself. Personally, I like to review the cache page before composing my log - to remind myself of the cache, to see if the pictures I plan to post are similar to what's already in the cache's Gallery, and to review other logs that have been added since my visit. I want to review the cache page before I submit my log, not after I submit it. Please add a link to the cache page on the Drafts page - bonus if it's added as a GC Code, since I'd like to see the GC Code next to each entry.
  Yes, I can click on the cache name from the compose page - but that won't be clear to some cachers, especially since the "Cache Name by Cache Owner" text is not obviously clickable on the new logging page.
   
  
• The URL for the drafts page has been changed.
  How long will the ".../my/fieldnotes" page automatically redirect "to .../account/drafts"? Those of us that bookmark the page will need to update our bookmarks once we realize that the URL has changed.
   
  
• The page label in the Play drop-down menu has been changed from "Drafts (field notes)" to just "Drafts".
  I still feel like 'Drafts' could be confusing to folks that are unfamiliar, since they may think they can find unpublished caches in 'Drafts' - like when a partially composed email is stored in a Drafts folder. "Draft Logs" would probably be more clear, but seems that ship has sailed.
  

 

------------------------------------------------------

Overall, this seems like a good update for the Drafts page. Some new things I'd like to see to enhance this page, besides what I've already mentioned above:

(1) Displaying the number of pending Drafts on the page. We can see how many Drafts we have on the Dashboard page, but I'd like to see that number on the Drafts page as well.

(2) Adding the GC Code for the cache, but without making each entry any taller. No new line of text just for the GC Code.

[+Team DEMP 130]

Ran a quick test on an * iPad * ...

1) sort option showing newest and oldest doesn't change what is displayed in the drop down if only 1 draft is shown on the page. Because it didn't change it appeared not to be working. I uploaded a 2nd test log so 2 were listed and changing the sort was retained and displayed as selected.

 

2) time of draft log shows on draft listing page. It also doesn't show am/pm but might show in 24 hr time, but I won't be able to see for a few hours.

 

3) no time is shown on the draft compose page.

 

Edited June 23, 2017 by Team DEMP

[+GeoJaxx 8]

I have tested from my Oragon 450 and when I loaded from the new page I had the error message 'geocache_visits.txt is not in the correct format'. I then reverted to the original page and loaded the same field notes and they have loaded correctly so it is not a problem with the file on my GPS.

 

I also notice that the instructions for GPS users on where to find the visits file is no longer displayed although from a phone it is quite detailed - this should be included in the instruction ie. plug in via a USB , go to device directory and select visits (i.e Garmin - visits.txt/ magellan - newslog.txt or logs.txt) Not a problem for those that have previously loaded from a GPS but the instruction you give on the new page does not explain the process for a new user or an occasional user that has forgotten.

edit - I have just seen there is a link on how to upload which gives instructions

Edited June 23, 2017 by GeoJaxx

[+Twentse Mug 33]

I would like to report a bug.

 

When you go to your log there is a possibility to upload a picture. Then you get in a screen with title "Upload a Geocache Log Image". Under "File" in bold there is button with text "Browse". On the right hand side of the button there is text with default "No file selected". The colour of that text is now the same as the colour of text in the browser menu, in my case Firefox. The rest of all text-items on the page is black.

In my case my text colour in the browser-menu is yellow (on black background). In the screen I see "No file selected" as yellow on white which makes it unreadable. I suggest to set the text colour of this item also to black, the same as the other text items in this page/screen.

Edited June 23, 2017 by Twentse Mug

[+LivingInNarnia 16]

Thank you for the thorough and helpful feedback! Our team is reading and discussing every response. We’re looking into the reported bugs first and we will get back to you as soon as we have updates.

[+The A-Team 1861]

The quintessence is, that the new parser fails, if the waypoint identifier of a line doesn't begin with "GC". But occasionally I use other listing platforms as well, which also support Garmin field notes, but which of course use cache IDs with different prefixes.

In addition to other listing platforms, there are also geocaching.com-related "findable objects" that could cause similar issues. Some examples include Benchmarks (various prefixes), Waymarks (WM), and Lab caches (GSAK creates identifiers with an LB prefix).

 

The best way to handle things would be for the parser to import any line with a GC code and accept-but-silently-discard any others.

[+The A-Team 1861]

• The page design is updated and refreshed.
  I'm not a big fan of the page design, but am also not surprised that it's happened. As with other page redesigns, I feel that the Drafts redesign has too much whitespace. And also, the darker grey against a lighter grey background can be difficult to read.
  

Agreed. The trend in most recent changes towards excessive whitespace and 50 shades of grey is difficult to understand. Usability issues have been brought up a number of times, but this design continues to be used on new projects. Efficient-use-of-space and black are not enemies to be avoided at all costs; they're allies that should be embraced.

 

• Sort drafts by date.

I assume the sorting will be based on UTC, correct? I'll soon be leaving on a driving trip where I'll be finding a number of caches close to time zone boundaries, so there's the possibility that the local time may jump backwards between successive logs. As long as the sorting uses the UTC, then this should sort fine.

 

• Drafted logs in the Drafts hub are listed in the time zone of the cache.
  This is a nice feature and am glad to see it.

Even nicer would be to additionally show the time zone abbreviation (see my previous comment), but I can live without it.

 

• Timestamps are back. To view, hover over the date in the Drafts hub list.
  I'm glad to see timestamps are back, but would prefer they be shown by default. Not sure why they show only on hover. Please have the timestamps be shown automatically.

Agreed. I don't understand why we should need to hover to display the time when it displays in a spot reserved just for that attribute. What's the reasoning behind hiding it? If the reason is "decluttering", it's a pretty weak reason because it removes useful information for very minimal gain. Example use case #1: let's say I took a photo at 10:18. I'd like to at-a-glance scan down the list of drafts and see that I logged caches at 10:16 and 10:25 so I can easily determine which log I should attach the photo to. Example use case #2: let's say that I forgot to log a cache just before lunch in the middle of my caching day, but I later realize my mistake and log it a few hours later after finding some other caches. By having the times visible, I can scan down and more-easily identify between which logs I should submit the wayward log.

[+LivingInNarnia 16]

In my first test, the new page didn't upload the field notes file from my GPS device (Garmin eTrex 30x)!

 

I clicked on the "Upload drafts" link on the new page, selected the "geocache_visits.txt" file from my Garmin, and got a red error message saying ""geocache_visits.txt" is not in the correct format." Not good ! Then I "opted out" to get to the old page, tried to upload the same file from there ... and it worked! So it's not a corrupted field notes file. As a further test, I created a copy of the file, and stripped it down to a single line (the last one). Then everything worked as expected, and the new upload function could read the file. So apparently one or more entries in the file were the problem. I investigated, and found indeed two lines which lead to the error. By knowing the root cause of the problem, it's easy for me to circumvent it in the future.

 

And now it gets a little bit complicated, because on one hand I'd like to share my findings so that others, who run into the same problem, know what to do. On the other hand, to do so I may have to violate the posting guidelines of this forum. I'm going to post it anyway, and see what happens .

 

The quintessence is, that the new parser fails, if the waypoint identifier of a line doesn't begin with "GC". But occasionally I use other listing platforms as well, which also support Garmin field notes, but which of course use cache IDs with different prefixes. So I'll have to manually remove the "bad" entries from the field notes file before trying to load it on the geocaching.com website. Not a big deal, once you know what to do.

 

Regards

baer2006

 

Hi baer2006 -

 

Thanks for sharing this feedback about the upload failing. Would you mind sharing the text file that was having the issue? (If you have more than one example even better, it will help the devs figure out the issue faster) thank you!

[+ZillaCloud 0]

I am also having trouble uploading my Geocaching Drafts from my Garmin Etrex 10 using the new drafts page. I uploaded the geocache_visits.txt file and it told me it was not in the proper format. I went to the old drafts page and then it worked fine.

 

Don't see an option to upload my file here but here are the contents:

 

GC76N27,2017-06-24T11:16Z,Unattempted,"BECON"

 

GC73GEE,2017-06-24T11:31Z,Found it,"DINGWOODCOINFORLASERPOINTER PTDROP FP THINKUSEDBAT"

 

GC1K8T0,2017-06-24T11:56Z,Found it,"OLDLNL TBCARDROP NOSPOILERPICNEARBYLOG"

 

GC6HHR6,2017-06-24T12:27Z,Found it,"LAYINGOUT BISONOPENLOGINSIDE REHIDSEEPICS"

 

GC6ZAJ3,2017-06-24T12:54Z,Unattempted,""

 

GC6YDKN,2017-06-24T13:55Z,Found it,"POLE"

 

GC6YTD0,2017-06-24T14:12Z,Found it,"BISONPINE"

 

GC1FXP4,2017-06-24T14:31Z,Found it,"SMLLLNLGOLDCOIN COOLNEWAREA"

[+GeoJaxx 8]

Has anybody successfully loaded from a GPS to the new drafts page without the error message saying that it is not in the correct format?

[+MartyBartfast 795]

Has anybody successfully loaded from a GPS to the new drafts page without the error message saying that it is not in the correct format?

 

The same drafts file that I successfully uploaded and logged on June 17th now won't open, saying it's not in the correct format (from an Etrex 30).

[+baer2006 788]

Hi baer2006 -

 

Thanks for sharing this feedback about the upload failing. Would you mind sharing the text file that was having the issue? (If you have more than one example even better, it will help the devs figure out the issue faster) thank you!

Sorry for the late reply, but here we go ...

 

I uploaded the field notes file to my private webspace, link is http://www.parsch-online.de/temp/geocache_visits.txt. But as I said in my original posting, the culprit is the two lines starting with "OC". As soon as I remove these two lines, the file is loaded without problems. I assume, the new parser expects the waypoint to start with GC and nothing else. The old parser behaved better (from a user's point of view) by simply ignoring such lines.

[+nwpvr 1]

Here a link to my today's file from my Oregon 650. Same result.. 'geocache_visits.txt is not in the correct format'.

 

https://we.tl/EIJo66yki7

 

This link wil work for a few day's. Don't hestitate to contact me for the file if the link is not working anymore.

[+Sir-Lancelot 0]

 

• Automatic prevention of duplicate draft creation on upload.
  

I don't believe this functionality is working correctly. My field notes are now sitting in the region of 2,020. To offer some kind of explenation as to whats happened;

Last Friday I uploaded my field notes. I had around 400 to log.

During the week I found 27 caches.

I uploaded my field notes yesterday using the new page and didn't check the amount I had to log. Today I checked it and I have 2,020 to log. All of the logs I had field notes waiting for are now duplicated, whilst ones where I had already logged the cache have now reappeared.

 

It seems the system has decided to upload the whole file. As it would if I had 'Ignore logs from before xx/xx/xxxx' box checked on the old field notes page. However there is no such option so it can't be a mistake I've made.

 

Is there a quick way I can get this mistake rectified? I know that the system will tell me if I try to log a found on a cache I've already found, however with the logging page taking up to 30 seconds to load I realy can't wait that long for all 1,500 (or so) caches.

 

 

Also having done some more poking around I don't believe timestamps are working correctly.

As you can see the cache was found at 1242 according to my geocache_visits file. Not the 0642 as the website claims, this obviously has an impact on the dates some of the caches appear in my field notes. The cache is in the london time zone as is the setting for my home timezone. so I'm not sure where this 6 hour difference has come in!

Edited June 25, 2017 by Sir-Lancelot

[+baer2006 788]

Here a link to my today's file from my Oregon 650. Same result.. 'geocache_visits.txt is not in the correct format'.

 

https://we.tl/EIJo66yki7

 

This link wil work for a few day's. Don't hestitate to contact me for the file if the link is not working anymore.

The problem is the line with the log type "Unattempted". You get this on a Garmin device, if you end the navigation to the cache with the (pseudo-)log type of "Unattempted". Until now I didn't even know that this generates a field log entry, because the old parser simply ignores any lines with unknown data (be it non-existing waypoints or non-existing log types).

[+monsterbox 51]

Here a link to my today's file from my Oregon 650. Same result.. 'geocache_visits.txt is not in the correct format'.

 

https://we.tl/EIJo66yki7

 

This link wil work for a few day's. Don't hestitate to contact me for the file if the link is not working anymore.

The problem is the line with the log type "Unattempted". You get this on a Garmin device, if you end the navigation to the cache with the (pseudo-)log type of "Unattempted". Until now I didn't even know that this generates a field log entry, because the old parser simply ignores any lines with unknown data (be it non-existing waypoints or non-existing log types).

 

And this now would lead to the point that the error handling simply is wrong. Instead of ignoring each of them you get that error message. I would simply just check that part of the code first!

[+The A-Team 1861]

Here a link to my today's file from my Oregon 650. Same result.. 'geocache_visits.txt is not in the correct format'.

 

https://we.tl/EIJo66yki7

 

This link wil work for a few day's. Don't hestitate to contact me for the file if the link is not working anymore.

The problem is the line with the log type "Unattempted". You get this on a Garmin device, if you end the navigation to the cache with the (pseudo-)log type of "Unattempted". Until now I didn't even know that this generates a field log entry, because the old parser simply ignores any lines with unknown data (be it non-existing waypoints or non-existing log types).

And this now would lead to the point that the error handling simply is wrong. Instead of ignoring each of them you get that error message. I would simply just check that part of the code first!

It seems like the problem is that there isn't any graceful error handling at all. The parser seems to have been designed to expect a very strict format and will completely fail as soon as it encounters something that doesn't fit this strict format. Strangely, the old parser has always done a good job of gracefully handling these edge cases, so I'm not sure why the same logic wasn't carried over to the new parser.

 

I just got the same error as others here and I know I have some non-GC prefixes and some "Unattempted", so those are likely the problem for me. Thankfully we still have the option to opt out and use the old parser until the problems get fixed, because it still gracefully accepts and discards records that aren't "valid".

[+noncentric 810]

Has anybody successfully loaded from a GPS to the new drafts page without the error message saying that it is not in the correct format?

Yes - I just uploaded field notes from my eTrex 20. About 150 caches uploaded without issue. After uploading, then I added a couple more rows to the geocache_visits.txt file on my eTrex and re-uploaded. Only the 2 new rows uploaded.

All of the cache id's in my geocache_visits.txt file started with "GC" and logs were either "Found It" or "Didn't Find It", which appears to why my field uploaded without issue.

[+noncentric 810]

Now that I've used the new Upload feature with a real file, I have some additional feedback:

 

(1) As others have noted, there are issues with geocache_visits.txt records that have "Unattempted" as the log type, so that should be fixed. I'd suggest creating 'Write Note' logs for 'unattempted' field note records. ETA: Retracting my suggestion. It's not a good one.

(2) The timestamps for field notes uploaded via the new upload process are incorrect. If I 'opt out' and re-upload the same field note records via the old upload process, then the timestamps are correct.

 

For example, field notes file shows 2017-06-25T22:35Z

-- new upload process, timestamp shown on new field notes page is 08:35 (-14 hours from UTC)

-- old upload process, timestamp shown on new field notes page is 15:35 (-7 hours from UTC)

The latter is correct. I found the cache at 3:35pm.

 

(3) The new upload process loads unique records, which is great. But, that uniqueness only works for 'pending' field note records. If I don't clear out the geocache_visits.txt file, then previous field notes will be uploaded again after I submit logs for field notes.

 

For example, if I upload a 'Found It' field note for Cache-A on 6/15, then that same 'Found It' won't be uploaded again later.

However, if I submit the 6/15 'Found It' log and then upload the geocache_visits.txt file next month, then that 6/15 'Found It' field note will post again. Since the 6/15 'Found It' log is no longer one of my 'Drafts.

With the old upload process, field notes that have already been submitted would not be re-uploaded because of the 'Ignore logs before..." function. With the new functionality, cachers will have to actively clear out the geocache_visits.txt file to avoid re-uploading field note records for drafts that they've submitted as final logs.

 

------------------

Please consider adding the following:

-- After uploading via the new upload process, please include the number of uploaded records in the success message. This was a helpful aspect of the old upload process.

Edited June 27, 2017 by noncentric

[+The A-Team 1861]

(1) As others have noted, there are issues with geocache_visits.txt records that have "Unattempted" as the log type, so that should be fixed. I'd suggest creating 'Write Note' logs for 'unattempted' field note records.

I think it would be better to treat it the same way as before and ignore it. That "log type" is just a way to cancel out a previous field note on the unit while in the field and doesn't carry any meaning on its own.

 

Ideally, the upload function should use these records in the same way. If it parses a find or DNF and then later an Unattempted for the same GC code, the earlier find/DNF field note could be removed from the Drafts page. Cachers may have gotten used to the upload page ignoring these records, though, so changing the behaviour may not go over well.

[+LivingInNarnia 16]

Hi baer2006 -

 

Thanks for sharing this feedback about the upload failing. Would you mind sharing the text file that was having the issue? (If you have more than one example even better, it will help the devs figure out the issue faster) thank you!

Sorry for the late reply, but here we go ...

 

I uploaded the field notes file to my private webspace, link is http://www.parsch-online.de/temp/geocache_visits.txt. But as I said in my original posting, the culprit is the two lines starting with "OC". As soon as I remove these two lines, the file is loaded without problems. I assume, the new parser expects the waypoint to start with GC and nothing else. The old parser behaved better (from a user's point of view) by simply ignoring such lines.

 

Thank you! We've received a few comments about uploads having issues; we're looking into it and will let you know when resolved.

[+LivingInNarnia 16]

Hi baer2006 -

 

Thanks for sharing this feedback about the upload failing. Would you mind sharing the text file that was having the issue? (If you have more than one example even better, it will help the devs figure out the issue faster) thank you!

Sorry for the late reply, but here we go ...

 

I uploaded the field notes file to my private webspace, link is http://www.parsch-online.de/temp/geocache_visits.txt. But as I said in my original posting, the culprit is the two lines starting with "OC". As soon as I remove these two lines, the file is loaded without problems. I assume, the new parser expects the waypoint to start with GC and nothing else. The old parser behaved better (from a user's point of view) by simply ignoring such lines.

 

Thank you! We've received a few comments about uploads having issues; we're looking into it and will let you know when resolved.

 

This should be resolved now, please let me know if you continue to have issues.

[+LivingInNarnia 16]

Here a link to my today's file from my Oregon 650. Same result.. 'geocache_visits.txt is not in the correct format'.

 

https://we.tl/EIJo66yki7

 

This link wil work for a few day's. Don't hestitate to contact me for the file if the link is not working anymore.

 

This should be resolved now, please let me know if you continue to have issues. Thank you for sharing!

[+technetium 13]

I don't know if this has occurred in this release or whether it's a bug or intended as a "feature", but when I tried to update my bio, your server timed out and aborted the upload. A reload of https://www.geocaching.com/account/settings/profile showed the content was empty. When I tried to put the profile info I had saved (and I was able to upload in the previous version) the server timed out again. This happened both on Firefox and Opera.

 

When I tried to upload just one line of bio, it succeeded.

 

Please, make the system again capable of uploading a large bio.

 

Tc

Edited June 26, 2017 by technetium

[+technetium 13]

Update: I just managed to restore my bio. So I suspect the many American users plus the "new and impoved* code" creates such a load the servers cannot handle the load. So my solution for now is: Make only updates to my profile when America sleeps and hope someone with API acces will create a decent user interface to the Groundspeak database.

 

* For the people who don't git it: This is irony

 

Tc

[+noncentric 810]

• The type of log is presented only as text, without the prominent icon (smiley, frowney, red wrench, etc).
  I'm not a fan of this. I try to post DNF's and NM's right away, saving the Found It's for later when I have a bigger block of free time. Without the icons, it's tougher for me to quickly spot which of the Drafts are for a DNF or NM log. Please incorporate the log type icons into the Drafts page.
   
  
• The page does not load all Drafts at once, but instead loads on demand.
  I'm not a big fan of this. I freaked out when I first went to the page because I thought a bunch of my Drafts were missing, but then I saw the green spinner.

After using the new Drafts page a bit more, I've decided to Opt Out and go back to the old Drafts page - primarily because of the two bulleted items I noted in the quote above.

 

I currently have almost 200 field notes to go through, so searching for a specific draft in the list was very difficult with the partial loading. The old drafts page loaded the ~200 records within 3 seconds. Loading ~200 with the new drafts page requires repeated pressing of 'page down' or 'end' keys and much longer than 3 seconds.

[+GeoJaxx 8]

My file is now loading correctly without the error message but I have opted out as do not like the new format for the following reasons

 

1. As with all the new pages there is too much white space

2 large font means having to scroll down to see all the caches

3. Took too long to load (only load a few at a time)

4. It loaded old field notes - the original version has a 'before date' setting to stop this happening if they are still on the GPS

5. No icon to show the type of log which means can't see at a glance if it is find or DNF etc.

 

However the one feature that I do like is that you can view the text without clicking on compose log - but this is not enough to make me use this version compared to all the negative points.

[+thebruce0 2485]

• The type of log is presented only as text, without the prominent icon (smiley, frowney, red wrench, etc).
  I'm not a fan of this. I try to post DNF's and NM's right away, saving the Found It's for later when I have a bigger block of free time. Without the icons, it's tougher for me to quickly spot which of the Drafts are for a DNF or NM log. Please incorporate the log type icons into the Drafts page.
• The page does not load all Drafts at once, but instead loads on demand.
  I'm not a big fan of this. I freaked out when I first went to the page because I thought a bunch of my Drafts were missing, but then I saw the green spinner.

After using the new Drafts page a bit more, I've decided to Opt Out and go back to the old Drafts page - primarily because of the two bulleted items I noted in the quote above.

 

I currently have almost 200 field notes to go through, so searching for a specific draft in the list was very difficult with the partial loading. The old drafts page loaded the ~200 records within 3 seconds. Loading ~200 with the new drafts page requires repeated pressing of 'page down' or 'end' keys and much longer than 3 seconds.

Agreed. And with Geojaxx.

 

One answer, if there's no budge room foor lazy loading the list, would be to provide a "Load All" button at the top so one click will return the remainder and full list of field notes. (I'll never stop using that term =P)

 

whitespacewhitespacewhitepacewhitespacewhitespacewhitepace!

 

Also, still no link to the cache listing - I end up opening the compose page in a new tab, then the listing in a sub-tab after that one since that has the cache listing link (which is still strangely visibly blending with the "by CacheOwner" text and link).

 

It still feels like someone at HQ is designing for mobile first, with very little, if any, leeway for an optimal/friendly desktop experience. =/ It's disconcerting.

 

ETA: also, man, this forum thing with paragraph and line-spacing weirdness is really getting on my nerves!

Edited June 27, 2017 by thebruce0

[+LivingInNarnia 16]

To clarify some of the complexity, and hopefully answer some questions, around uploading and deleting with the new and old drafts system, I’m attempting to provide an overview below Please let us know if there are any additional questions.

 

How the old system detects duplicates: Keeps track of the greatest visit date (typically, the most recent; could be a future date) of any upload drafts on the account; gives the user the option to only upload logs with a visit date greater than that date. (If user unchecks “ignore logs” then you can upload those.)

 

How the old system handles failing / invalid records : Any bad records in the file will cause the erroneous record as well as any following ones to be ignored.

 

How the old system handles deleting records: The option to “clear all drafts” completely removes all drafts from the system for the user and clears the “greatest visit date” resulting in all drafts to be uploadable again whether or not they were “deleted” or “converted to a log”. “Bulk Delete” and single delete, will delete the records however they could be uploaded again if the “ignore logs” is unchecked.

 

How the new system detects duplicates: The “Upload drafts” functionality from the new page detects duplicates based on the combined values of the Geocache Reference Code (GC Code), the date/time of the visit as well as the log type. Any drafts previously uploaded to the system (via the legacy drafts page or the new drafts page) will be ignored if the draft was subsequently deleted or promoted to a log. The only exception to this rule is if records were deleted via “clear all drafts” on the old page as we then no longer have any records of those drafts having ever existed.

 

How the new system handles failing/invalid records: If the first record in the file is valid, then any following invalid records in that file will be skipped (bad GC code, bad format, etc). If the first record in the file is invalid, then the user will receive an incorrect file warning with the name of the file.

 

How the new system handles deleting records: Users have the option to “Delete All” or delete individual records. These files cannot be uploaded again on the new logging page.

 

Why we moved to a new system: Now that we are handling drafts from mobile and web, this new way of handling duplicates is more robust. It allows us to not just rely on date to determine duplicate logs but also GC code and log type. TL;DR we can identify duplicates more accurately.

[+The A-Team 1861]

How the old system handles failing / invalid records : Any bad records in the file will cause the erroneous record as well as any following ones to be ignored.

It depends on how you define "invalid". I've seen the behaviour you described when I've done a silly thing like putting a " in a field note comment on my Garmin, which understandably causes the parsing to fail. However, I know I still have some non-GC codes and "Unattempted" records in my geocache_visits.txt file, and the old parser was and still is happy with simply ignoring those records and continuing on.

 

How the new system handles failing/invalid records: If the first record in the file is valid, then any following invalid records in that file will be skipped (bad GC code, bad format, etc). If the first record in the file is invalid, then the user will receive an incorrect file warning with the name of the file.

This isn't how it worked for me on Sunday. I'll double-check when I get home, but I'm pretty confident the first record in my file is valid, and the site still didn't accept my file. Was there an issue that has since been fixed?

[+LivingInNarnia 16]

How the old system handles failing / invalid records : Any bad records in the file will cause the erroneous record as well as any following ones to be ignored.

It depends on how you define "invalid". I've seen the behaviour you described when I've done a silly thing like putting a " in a field note comment on my Garmin, which understandably causes the parsing to fail. However, I know I still have some non-GC codes and "Unattempted" records in my geocache_visits.txt file, and the old parser was and still is happy with simply ignoring those records and continuing on.

 

How the new system handles failing/invalid records: If the first record in the file is valid, then any following invalid records in that file will be skipped (bad GC code, bad format, etc). If the first record in the file is invalid, then the user will receive an incorrect file warning with the name of the file.

This isn't how it worked for me on Sunday. I'll double-check when I get home, but I'm pretty confident the first record in my file is valid, and the site still didn't accept my file. Was there an issue that has since been fixed?

 

re the new system handling failing/invalid records: Correct, we made an update earlier this week to make this fix!

[+Sir-Lancelot 0]

How the new system detects duplicates: The “Upload drafts” functionality from the new page detects duplicates based on the combined values of the Geocache Reference Code (GC Code), the date/time of the visit as well as the log type. Any drafts previously uploaded to the system (via the legacy drafts page or the new drafts page) will be ignored if the draft was subsequently deleted or promoted to a log. The only exception to this rule is if records were deleted via “clear all drafts” on the old page as we then no longer have any records of those drafts having ever existed.

 

I don't believe this is working. I uploaded a field note last week and then turned it into a log, today I thought I would try to see what would happen so I uploaded it again. Needless to say another field note appeared. If the logic you are describing is working correctly surely it shouldn't of appeared in my field notes?

 

The cache in question is GC5M5KX and I'm uploading it using the following line;

GC5M5KX,2017-06-24T14:07Z,Found it,""

Edited July 1, 2017 by Sir-Lancelot

[+Sherminator18 14]

I believe I have found a bug. I uploaded a .txt file into the new Drafts page, but then clicked delete all. When I tried to upload a file again, with the same caches, it wouldn't upload the drafts and gave me an error message saying something along the lines of "there are no drafts to upload"

 

Does this have to do with not being able to log multiple Found it logs on the same cache? Because I never actually logged the caches in my drafts as found.

 

EDIT: Looks like I should read the entire thread before posting. Oops.. but I am putting in my 2 cents that I'm having this issue as well

Edited July 3, 2017 by Sherminator18

[+Sherminator18 14]

So the problem that is currently frustrating me is that I never actually logged the caches as Found. And yet it won't let me upload the drafts for those caches, because it thinks I've already found them, but I haven't, because I used the delete all option to delete all the drafts I had saved. Making this process even more frustrating and time consuming.

[+DragonsWest 30]

I seriously hope the Opt-out can be permament. New logging is a pain.

 

Since I'm travelling I found something else while trying to post some TB drops - I have to load a new page to see logs on a cache - most uncool. How do I get back to seeing this list automatically, if not at least the last 5, please. When you are on a laptop you don't want all this needless encumberance.

[+tomastomas 6]

Noticed today:

 

If I add a Needs Maintenance log together with my Found log, my Found log will have the date from my Field Note (uploaded from my Garmin), like 2017-07-10, but my NM log will have today's date (2017-07-25). 

 

I found the cache and saw the problem at the same time, of course should the NM-log inherit the date from the Found log since it no longer is possible to write a separate NM log (which by itself is wrong way to go, but that's a question for another thread).

 

I can still edit the predefined text of the NM log to something useful to the cache owner, but the date is not possible to edit to the correct date..

Edited July 25, 2017 by tomastomas

[Keystone 3453]

25 minutes ago, tomastomas said:

Noticed today:

If I add a Needs Maintenance log together with my Found log, my Found log will have the date from my Field Note (uploaded from my Garmin), like 2017-07-10, but my NM log will have today's date (2017-07-25). 

I found the cache and saw the problem at the same time, of course should the NM-log inherit the date from the Found log since it no longer is possible to write a separate NM log (which by itself is wrong way to go, but that's a question for another thread).

I can still edit the predefined text of the NM log to something useful to the cache owner, but the date is not possible to edit to the correct date..

If you are behind in logging by a month, think about the impact on the cache owner if you could place a backdated Needs Maintenance or Needs Archived log.  From my perspective as a Reviewer, it would look to me like the owner has ignored the issue for a month, and I might disable their cache page.  It is better to go by the date when the owner became aware of the maintenance issue, because of the NM log, so that is why the current date is used instead of the log date.

[+tomastomas 6]

2 minutes ago, Keystone said:

If you are behind in logging by a month, think about the impact on the cache owner if you could place a backdated Needs Maintenance or Needs Archived log.  From my perspective as a Reviewer, it would look to me like the owner has ignored the issue for a month, and I might disable their cache page.  It is better to go by the date when the owner became aware of the maintenance issue, because of the NM log, so that is why the current date is used instead of the log date.

 

Good point!

 

Another question, for you with perspective as a reviewer. Since I'm now encouraged to write my description of what's wrong with the cache in my Found log, and the NM log only contains the (mostly) non informative predefined texts, wouldn't it be easier to at least find my description of what's wrong with the cache (i.e, my Found log) adjecent to the actual NM log?

[Keystone 3453]

3 minutes ago, tomastomas said:

 

Good point!

 

Another question, for you with perspective as a reviewer. Since I'm now encouraged to write my description of what's wrong with the cache in my Found log, and the NM log only contains the (mostly) non informative predefined texts, wouldn't it be easier to at least find my description of what's wrong with the cache (i.e, my Found log) adjecent to the actual NM log?

From the cache owner's perspective, the distance gap on the cache page between your backdated found log and your current date NM log is overcome by the fact that the owner receives notifications of both logs in their email.

From the reviewer's perspective, the distance gap is overcome through special reviewer-only tools provided to us by Geocaching HQ.  So, don't worry about us!  For the good of the game, I would rather that you took your time and wrote nice logs three weeks later instead of writing TFTC logs from the field.

[+tomastomas 6]

6 minutes ago, Keystone said:

For the good of the game, I would rather that you took your time and wrote nice logs three weeks later instead of writing TFTC logs from the field.

2200+ logs and still not a single TFTC log, I don't intend to start now ;-)

Also, I edit my NM logs so they contain useful information instead of the predefined texts.

[+barefootjeff 3828]

1 minute ago, tomastomas said:

Also, I edit my NM logs so they contain useful information instead of the predefined texts.

I'm not sure that's such a good idea as the email the CO gets will be the original boilerplate text and they won't be made aware of any editing.

[+tomastomas 6]

7 minutes ago, barefootjeff said:

I'm not sure that's such a good idea as the email the CO gets will be the original boilerplate text and they won't be made aware of any editing.

I know, it's not perfect, but it's the best I can do. Yes, the email the CO receives will only contain the predefined text and that I can't do anything about. But at least, everyone (cachers as well as CO) reading the logs on the cache listing page or app will read my edited log which I consider to be more informative than the predefined ones.

[+noncentric 810]

On 7/25/2017 at 2:46 PM, tomastomas said:

I know, it's not perfect, but it's the best I can do. Yes, the email the CO receives will only contain the predefined text and that I can't do anything about. But at least, everyone (cachers as well as CO) reading the logs on the cache listing page or app will read my edited log which I consider to be more informative than the predefined ones.

I am also behind in logging my finds. What I've started doing though is to address DNF/NM/NA logs right away, or at least within a couple days.

• For DNF's - I'll go directly to the DNF entries on the Drafts page (the old version) and submit my DNF logs. Usually within a couple days.
• For NM/NA - I'll go directly to the cache pages for those caches and use the "Log geocache" button. I "opt out" of the new logging experience, which works when logging directly from a cache page, but not when logging via Drafts. Using the 'old' logging page on those caches, I can submit a NM/NA log with an explanation of the issue and then CO will receive it right away with my reasoning in their email.  My 'Found It' logs for these caches get posted in the usual pace when I get to them, but at least the issue is already communicated.

Also - the NM/NA logs have always had the date of when the log was submitted.  That is not something new with the 'new logging experience'. The date for NM/NA logs wasn't editable even with the 'old logging' method.

[+schevka+Stano 0]

The "Drafts" page should be opened on the same list as last logged geocache, not the new (_blank), after the "Back to drafts" button has been pushed.
When multiple caches are logged, all the "Drafts" pages remains open and needs to be closed manually.

[+missionMode 0]

One very important feature missing from the new page (and suddenly broken on the old page) is the checkbox to ignore logs before the last time you uploaded your logs. I switched back to the old page but it doesn't show you the checkbox until after it's already uploaded your entire file of drafts, so it's now too late to have any effect.

[+Team BikeFast 0]

Two comments on Drafts:

1: The comments field from the Garmin GPS is in the visits.txt on the Garmin, but is not shown on the GC.com page after the Drafts are uploaded.  We use this field to record the answers to Earth caches and other notes about caches we need to remember. If we do as some have suggested and delete the visits.txt after every upload to correct the duplicate uploads bug,these notes are gone for ever

 

GC21P4M,2017-08-03T23:01Z,Found it,"Replaced"
GC6KJXP,2017-08-03T23:56Z,Found it,""
GC70GGV,2017-08-04T15:14Z,Found it,""
GC2QAJG,2017-08-04T15:18Z,Found it,""
GC3XEHV,2017-08-04T16:17Z,Found it,""
GC72QAE,2017-08-04T16:19Z,Found it,"Tidal Bore. Burnt Cove Head."

2: We are still having the problem of duplicate uploads. We went out on a day and found a number of caches and uploaded the drafts. The caches were logged to GC.com using the drafts.

This week we marked new caches as found in the Garmin 650 and uploaded the drafts. The completed from last week were also uploaded. We had to individually delete the old drafts. This happens on every upload and we have not seen a fix posted.

On other geocaching related sites - GSAK and Cachley the developer will reply in person within a day or two. On this forum a Lackey just points you to the FAQ that says it works. I have never seen a reply that says "Yes it is broken and here is a tracking number to see when it is fixed"

[+LivingInNarnia 16]

2 hours ago, Team BikeFast said:

Two comments on Drafts:

1: The comments field from the Garmin GPS is in the visits.txt on the Garmin, but is not shown on the GC.com page after the Drafts are uploaded.  We use this field to record the answers to Earth caches and other notes about caches we need to remember. If we do as some have suggested and delete the visits.txt after every upload to correct the duplicate uploads bug,these notes are gone for ever

 

GC21P4M,2017-08-03T23:01Z,Found it,"Replaced"
GC6KJXP,2017-08-03T23:56Z,Found it,""
GC70GGV,2017-08-04T15:14Z,Found it,""
GC2QAJG,2017-08-04T15:18Z,Found it,""
GC3XEHV,2017-08-04T16:17Z,Found it,""
GC72QAE,2017-08-04T16:19Z,Found it,"Tidal Bore. Burnt Cove Head."

2: We are still having the problem of duplicate uploads. We went out on a day and found a number of caches and uploaded the drafts. The caches were logged to GC.com using the drafts.

This week we marked new caches as found in the Garmin 650 and uploaded the drafts. The completed from last week were also uploaded. We had to individually delete the old drafts. This happens on every upload and we have not seen a fix posted.

 

Thanks for the feedback. Could you provide a little more information to help the team understand the potential issue? 

• Would you mind sharing the field note files you uploaded - the file used last week and the file used this week. 
• What is the exact Garmin device you are using?
• Were any files modified at some point? 
• Did you use the old field notes page at any point in your process? Or only the new Drafts page?

Thank you!

[+Team BikeFast 0]

Thanks for the quick reply.

Visits.txt File direct copy and paste from the Garmin 650. No editing on the GPS before or after the upload. 

Downloaded by myself on my laptop using the new Drafts uploader https://www.geocaching.com/account/drafts 

My wife logged both times,  27-07-26 last week and 2017-08-03 to 05 yesterday using the old page https://www.geocaching.com/my/fieldnotes.aspxThe comments did not show on either page. The logs from the older dates were uploaded to the new drafts page. I have been deleting the visits.txt file to work around the broken feature but wanted to try again to see if it was working as advertised.

GC76T3F,2017-07-19T17:58Z,Found it,""
GC6K0TW,2017-07-22T19:45Z,Found it,""
GC6HV34,2017-07-26T14:42Z,Found it,""
GC6VXM1,2017-07-26T16:17Z,Found it,""
GC6YYGK,2017-07-26T16:21Z,Found it,""
GC6VT8F,2017-07-26T16:37Z,Didn't find it,""
GC6MDA5,2017-07-26T16:54Z,Found it,""
GC6MDCN,2017-07-26T16:56Z,Found it,""
GC6MDEB,2017-07-26T17:00Z,Found it,""
GC6MDCH,2017-07-26T17:02Z,Found it,""
GC6MDCW,2017-07-26T17:11Z,Found it,""
GC6MDDQ,2017-07-26T17:12Z,Found it,""
GC6MDD2,2017-07-26T17:15Z,Found it,""
GC6MDD9,2017-07-26T17:17Z,Found it,""
GC6MDDF,2017-07-26T17:23Z,Found it,""
GC6MDE2,2017-07-26T17:28Z,Found it,""
GC2K9RW,2017-07-26T17:41Z,Found it,""
GC6MDEG,2017-07-26T17:43Z,Found it,""
GC6MDF1,2017-07-26T17:50Z,Found it,""
GC6MDEY,2017-07-26T17:52Z,Found it,""
GC6MDEV,2017-07-26T17:54Z,Found it,""
GC6MDEQ,2017-07-26T18:01Z,Found it,""
GC6MDF5,2017-07-26T18:04Z,Found it,""
GC6MDFA,2017-07-26T18:11Z,Found it,""
GC6MDFC,2017-07-26T18:13Z,Found it,""
GC6MDFH,2017-07-26T18:18Z,Found it,""
GC6MDP9,2017-07-26T18:20Z,Found it,""
GC6MDG0,2017-07-26T18:24Z,Found it,""
GC6MDQR,2017-07-26T18:35Z,Found it,""
GC6MDFV,2017-07-26T18:40Z,Found it,""
GC6MDFK,2017-07-26T18:44Z,Found it,""
GC2G4ZD,2017-07-26T18:52Z,Found it,""
GC6MDHF,2017-07-26T18:58Z,Found it,""
GC6MDG8,2017-07-26T19:01Z,Found it,""
GC6MDHZ,2017-07-26T19:05Z,Found it,""
GC6MDHR,2017-07-26T19:13Z,Found it,""
GC6MDKR,2017-07-26T19:14Z,Found it,""
GC6MDKH,2017-07-26T19:16Z,Found it,""
GC6MDJ4,2017-07-26T19:17Z,Found it,""
GC6MDK9,2017-07-26T19:20Z,Found it,""
GC6MDM2,2017-07-26T19:21Z,Found it,""
GC6MDMA,2017-07-26T19:24Z,Found it,""
GC6MDMJ,2017-07-26T19:29Z,Found it,""
GC6MDMQ,2017-07-26T19:30Z,Found it,""
GC6MDMY,2017-07-26T19:33Z,Found it,""
GC75FAE,2017-07-26T20:50Z,Found it,""
GC6ZR9H,2017-07-27T12:26Z,Found it,""
GC705XY,2017-07-27T12:39Z,Found it,""
GC6TMRN,2017-07-27T13:40Z,Found it,""
GC6QW00,2017-07-27T13:40Z,Found it,""
GC6T5G3,2017-07-27T13:45Z,Found it,""
GC6TMRW,2017-07-27T13:47Z,Found it,""
GC6TMTF,2017-07-27T13:51Z,Found it,""
GC5HJ66,2017-07-27T14:03Z,Found it,"In tree"
GC6KCP2,2017-07-27T14:22Z,Found it,""
GC6P2F4,2017-07-27T14:22Z,Found it,""
GC6PZ54,2017-07-27T14:26Z,Found it,""
GC75Q7D,2017-07-27T15:05Z,Found it,""
GC6MDN7,2017-07-27T15:25Z,Found it,""
GC6MDNF,2017-07-27T15:27Z,Found it,""
GC6MDPN,2017-07-27T15:35Z,Found it,""
GC6MDPH,2017-07-27T15:38Z,Found it,""
GC6MDP1,2017-07-27T15:44Z,Found it,""
GC6MDNP,2017-07-27T15:49Z,Found it,""
GC6MDP3,2017-07-27T15:51Z,Found it,""
GC6MDQ7,2017-07-27T15:54Z,Found it,""
GC6MDPE,2017-07-27T15:56Z,Found it,""
GC6MDQJ,2017-07-27T16:02Z,Found it,""
GC6MDPV,2017-07-27T16:11Z,Found it,"Tricky"
GC6MDQE,2017-07-27T16:14Z,Found it,""
GC6MDQ2,2017-07-27T16:18Z,Found it,""
GC6MF27,2017-07-27T16:20Z,Found it,""
GC6ZR9D,2017-07-27T16:55Z,Found it,""
GC6NKW0,2017-07-27T16:58Z,Found it,""
GC6PHDR,2017-07-27T17:05Z,Found it,""
GC7088B,2017-07-27T17:14Z,Found it,""
GC708P6,2017-07-27T17:20Z,Found it,""
GC709QN,2017-07-27T17:27Z,Found it,""
GC705XW,2017-07-27T17:34Z,Found it,""
GC6RE45,2017-07-27T18:26Z,Found it,""
GC48DB5,2017-07-27T18:39Z,Found it,""
GC2WCA6,2017-07-27T18:53Z,Found it,""
GC3YW1N,2017-07-27T19:10Z,Found it,""
GC70909,2017-08-03T15:14Z,Found it,""
GC1Q3V7,2017-08-03T15:16Z,Found it,""
GCN186,2017-08-03T16:36Z,Found it,""
GC740Q5,2017-08-03T21:21Z,Found it,""
GC21B75,2017-08-03T21:27Z,Found it,""
GC6QMCX,2017-08-03T21:56Z,Found it,""
GC6J2G0,2017-08-03T21:59Z,Found it,""
GC19RNE,2017-08-03T22:10Z,Found it,""
GC625AC,2017-08-03T22:32Z,Found it,""
GC18RYX,2017-08-03T22:41Z,Found it,""
GC21P4M,2017-08-03T23:01Z,Found it,"Replaced"
GC6KJXP,2017-08-03T23:56Z,Found it,""
GC70GGV,2017-08-04T15:14Z,Found it,""
GC2QAJG,2017-08-04T15:18Z,Found it,""
GC3XEHV,2017-08-04T16:17Z,Found it,""
GC72QAE,2017-08-04T16:19Z,Found it,"Tidal Bore. Burnt Cove Head."
GC74MAM,2017-08-04T17:53Z,Found it,""
GC6V0WR,2017-08-04T18:19Z,Found it,""
GC6FWCV,2017-08-04T19:06Z,Found it,""
GC38888,2017-08-04T23:04Z,Found it,""
GC1T7G3,2017-08-04T23:05Z,Found it,""
GC6NCM3,2017-08-04T23:05Z,Found it,""
GC6G48D,2017-08-04T23:11Z,Found it,""
GC2FTWD,2017-08-04T23:21Z,Didn't find it,""
GC2FTWQ,2017-08-04T23:25Z,Found it,""
GC6MET1,2017-08-05T20:21Z,Found it,""