Jump to content
Sign in to follow this  
Followers 3
SCS Team

Suggestion : Blocking Date for Attended Event

Recommended Posts

hi,

When we log or edit an Attended event we have the opportunity to choose the date on which to do it, so to fool us in that date.
My suggestion would be that this date be put automatically when it is about an event with impossibility to modify it.
This would prevent us from making a mistake when logging or editing a Event log.
In advance thank you for reading me
Géocordialement
SCS Team

  • Upvote 2

Share this post


Link to post

That does sound like a simple and usedful tweak , although I've never found it diffcult to set the attended date myself (and often use GSAK which picks up the date & time when I pressed the GPS button to mark the attended/found from my GPS memory and automatically applies it to the log. Yet another reason to love GSAK ! )

 

However, I wonder if it would be difficult to implement this idea on the website and appp. because of the other log types available for events?  Those will attends, write notes and E.O. announcements typically need a different date to that of the event , setting an automatic default date for only one selected log type may not be something that is possible.

Share this post


Link to post

I always found it strange that you can log an event (by mistake or intentionally) on a different date than the said event.

Share this post


Link to post
4 hours ago, SCS Team said:

When we log or edit an Attended event we have the opportunity to choose the date on which to do it, so to fool us in that date.
My suggestion would be that this date be put automatically when it is about an event with impossibility to modify it.
This would prevent us from making a mistake when logging or editing a Event log.

 

I might be understanding this incorrectly, but we've attended events that changed to the next day/weekend if weather or other circumstance forced it to.

Will attend, notes, and attended are already on separate dates.

Curious, do you really log events in error often enough that you feel the "system" needs to change ?

Share this post


Link to post
41 minutes ago, cerberus1 said:

Curious, do you really log events in error often enough that you feel the "system" needs to change ?


I have only once logged the wrong date on an event; I logged the next day and the server date had moved forward.

 

I find it very odd that others will log events with dates that are days or even weeks off.  I see it all the time.  So perhaps this is less of a "please change this so I stop making mistakes" request and more of a "please stop these other chuckleheads from doing this over and over, I can't stand it anymore" request.

Share this post


Link to post

The idea breaks down with multi-day events.  I've hosted 3-day camping events, for example.  Official date is, say, Day 2, but someone pops in on Day 3 to say hello.

 

Groundspeak would have to add a field to the database for an admittedly rare use case.  Ain't gonna happen.

 

Besides, why do we need more rules?  Free-form is more flexible for the unexpected and un-thought-of.  (For example: block logging of finds "tomorrow", and the forums will light up with Australians and Kiwis.  Oh yeah, the date line...)

 

Edited by Viajero Perdido
  • Upvote 3

Share this post


Link to post
5 hours ago, hzoi said:

I find it very odd that others will log events with dates that are days or even weeks off.  I see it all the time.

I do too. I've always suspected that it's people using the official app, which doesn't provide an option to select the date and instead forces logs to use the current date. These people are catching up on their logging on a later date and the logs use that day's date. The fix would be to allow date selection in the app. This seems like such a fundamental function and has been pointed out countless times, so I have no idea why they've never put it in.

  • Upvote 2

Share this post


Link to post
48 minutes ago, The A-Team said:

These people are catching up on their logging on a later date and the logs use that day's date.

Part of the problem is that when you backdate a log (for whatever purpose) on the website, the selected date remains sticky. Then after you post the back-dated log, while still logged into the website, you attempt to post a current log, the default date is whatever date you last chose. That has happened to me several times, requiring me to go back and edit the date on all the logs that were dated incorrectly. It usually happens when I am traveling and don't have time to post proper logs. I might find a cache on day one, then a handful of caches on the last day before I get home. If I don't watch my logging process closely, the dates for all the caches will be for day one, because I wrongly assume that after the first cache, the date will default to today's date. But it doesn't.

Share this post


Link to post
1 hour ago, Team Christiansen said:

Part of the problem is that when you backdate a log (for whatever purpose) on the website, the selected date remains sticky. Then after you post the back-dated log, while still logged into the website, you attempt to post a current log, the default date is whatever date you last chose.

I always saw that as a feature. I could log a Find from last Monday (selecting the date), and then log more Finds from last Monday without having to select the date for each one. Then I could log a Find from last Tuesday (selecting the date), and then log more Finds from last Tuesday without having to select the date for each one. And so on.

 

Of course, I haven't used that feature in a while, just because I've been logging almost exclusively with field notes drafts for years.

Share this post


Link to post

Yes, the sticky date is a very useful feature to me, .

Share this post


Link to post
On 9/19/2018 at 2:06 PM, Team Christiansen said:

Part of the problem is that when you backdate a log (for whatever purpose) on the website, the selected date remains sticky.

Then - 

On 9/19/2018 at 3:28 PM, niraD said:

I always saw that as a feature.

 

The same behavior is either a plus or a minus, liked or not liked, good or bad, depending on the user/cacher.  You'll never satisfy everyone! (Reference the plethora of posts on the effect of DNF's on the CHS and when we should or should not log DNf's)

 

I just use the app on my phone to make a quick note at each find, and then write full logs later from my drafts, which retain the date and time of the "find".  So far I've been fortunate to make my posted logs within a day or two of the cache finds.

Edited by CAVinoGal
Post sent before I finished writing it!

Share this post


Link to post
On 9/19/2018 at 10:06 PM, The A-Team said:
On 9/19/2018 at 4:06 PM, hzoi said:

I find it very odd that others will log events with dates that are days or even weeks off.  I see it all the time.

I do too. I've always suspected that it's people using the official app, which doesn't provide an option to select the date and instead forces logs to use the current date. These people are catching up on their logging on a later date and the logs use that day's date. The fix would be to allow date selection in the app. This seems like such a fundamental function and has been pointed out countless times, so I have no idea why they've never put it in.

 

I don't use the app to log, so I'd never noticed that.  That makes sense.  Thanks.

Share this post


Link to post
On 9/19/2018 at 12:48 PM, Viajero Perdido said:

The idea breaks down with multi-day events.  I've hosted 3-day camping events, for example.  Official date is, say, Day 2, but someone pops in on Day 3 to say hello.

 

Groundspeak would have to add a field to the database for an admittedly rare use case.  Ain't gonna happen.

 

Besides, why do we need more rules?  Free-form is more flexible for the unexpected and un-thought-of.  (For example: block logging of finds "tomorrow", and the forums will light up with Australians and Kiwis.  Oh yeah, the date line...)

 

 

What if the log date was set to default to the date of the event, but still allow users to change the date? If the date is different than the event, it could put an alert next to the date stating such.

 

User goes to log event. GC.com sees it's an event and pulls the date of the event (not necessarily today's date) into the date field of the log. User changes date, so page displays "This is not the date of the event." in red text, maybe with an icon to click that opens a popup box with more information. If date is changed back to "correct" date, alert goes away.

  • Upvote 2

Share this post


Link to post
17 hours ago, yawetag said:

 

What if the log date was set to default to the date of the event, but still allow users to change the date? If the date is different than the event, it could put an alert next to the date stating such.

 

User goes to log event. GC.com sees it's an event and pulls the date of the event (not necessarily today's date) into the date field of the log. User changes date, so page displays "This is not the date of the event." in red text, maybe with an icon to click that opens a popup box with more information. If date is changed back to "correct" date, alert goes away.

 

That sounds like a reasonable compromise.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 3

×
×
  • Create New...